MINUTES 20 Joint Meeting API SC 17 & ISO/TC67/SC4/WG6 Subsea

1

MINUTES 20th Joint Meeting

API SC 17 & ISO/TC67/SC4/WG6 Subsea Production Equipment

Atlanta, Georgia June 14, 2006

1. John Bednar, API SC 17 Chairman, welcomed the group to the meeting at 8:00 AM and outlined various safety and housekeeping issues.

2. A roll call was completed and it was confirmed that there was a quorum

present for this meeting. (Attendee List provided in Attachment A)

3. John Bednar recognized and presented the API Subcommittee Commendation award plaques to William Bakke and John McManus.

4. The agenda was adopted (Attachment B) 5. The minutes from the 19th Joint Meeting, held in Galveston were reviewed

by Gary Hurta and subsequently approved by the attendees.

6. The latest Work Program Listing (Attachment C) was presented and the Action items were reviewed and updated/added as appropriate (Attachment D) throughout the meeting.

7. Task Group Chair/Project Group Leader reports.

a. ISO 13628-1/API RP 17A---Subsea Production Systems---

(Attachment E) i. Action items from yesterday’s working group

1. WG for Flowline connections/connection systems proposed to make recommendation of what/where this should go. Jonathan will put out an e-mail soliciting support. Craig Redding, SW Research, volunteered to lead the work group.

2. WG for Metering System requirements/needs to be identified to ascertain who is working on metering systems and what should SC17 do with regards to metering systems. Action item to leadership team and John Allen to get WG started.

ii. Discussions continued as to whether API 17A should continue its existence as a Recommended Practice or should be written as a specification as the new ISO 13628

2

Part 1 is written today. No resolution was reached during the work session and help has been asked from API for guidance. This is an action item to the SC17 leadership team.

iii. Next meeting of 17A TG will be early Fall 2006. iv. Initial API review/guidance of WG progress will be by the

Leadership Team for the next 6 months to help formulate the plan. Ultimately review/guidance will be carried on by the API TG chairs.

v. Per Ragnar Dahl made presentation of ISO TG report (Attachment F)

1. Publication of 13628-1 occurred in November 2005 and adopted back to API 17A fourth edition, January 2006.

2. DIS ballot for the Amendment on Materials including Annex L to 13628-1 may start July-August with publication late 2006. Five months of comment time will follow. Following resolution of comments will become FDIS.

a. API would then adopt back the Amendment to stay shoulder to shoulder with ISO.

vi. Systems Engineering will be worked further but will be kept only as part of 17A/13628-1. API 17Q will be withdrawn.

vii. All action items from WG meeting need to be published and distributed with these minutes. (Attachments G, G-1, G-2)

viii. Action item on lifting for the 17D/13628-4 TG to compare with what is in 17A/13628-1 and only include in 17D what is not already adequately supplied in 17A. Provide any suggested improvements to 17A/13628-1 content to 17A/13628-1 WG.

ix. Materials & Welding of Manifolds report given by Maarten Simon Thomas. (Attachment H)

1. New Clause 6 and an addendum Annex L were presented.

2. Both are ready for ballot to be included in 17A/13628-1. When 17P is ready the work will be exported to the specification on Manifolds and Templates.

3. Motion made and seconded for SC17 to recommend that this go out to ballot as a DIS for Clause 6 and for Annex L to be included in 13628-1. Motion passed.

4. Materials Study Group recommended making modifications to 17D/13628-4 and 17E/13628-5 materials requirements.

5. Agreed that Annex L is informative even though it contains a fair amount of “shalls”.

x. Definitions

3

1. ISO group, TC184 in SC4, is working on definitions for 13628 suite of documents. They have taken all definitions and have categorized them and will recommend a definition which should be used across all subcommittees. First proposal should be available autumn 2006.

2. SC17 proposes to set up a WG to come up with recommendations for one definition of pressure rating for general use. Glen Cuiper with AKS has volunteered to chair the WG. Jonathan will send e-mail requesting help.

b. ISO 13628-11/API RP 17B, ISO 13628-2/API 17J & ISO 13628-

10/API 17K Flexible Pipe and API RP 17L Ancillary Equipment for Flexible Pipe—No formal report was given. Verbal discussion was made.

i. ISO 13628-2 (API -17J) ---The DIS comments have been resolved & the FDIS should be out by 2nd quarter this year. FDIS ballot ends this month.

ii. ISO 13628-11 (API-17B) --- DIS made in August and the FDIS is waiting on final draft.

iii. Motion made and seconded that SC17 initiate adopt back immediately for 13628-11 in parallel with ISO when FDIS is completed. This is contingent that no changes are made without the approval of the respective API and ISO Committees.

c. ISO 13628-3 (API 17C) ---TFL Systems---See TG Chair report (Attachment I)

i. John Yonkers made report on TG. Document is in maintenance mode only. No comments have been received and no actions required.

ii. John Yonkers is retiring next month and replacement to 17C will be Harold Reeves with BP. His replacement on SC17 is Austin Freeman with Halliburton.

iii. No action items other than to change representative names. d. ISO 13628-4 (API 17D) ---Subsea Wellheads and Trees--- See

TG chair report (Attachment J) i. Gary Hurta gave verbal report. ii. Issuance of the DIS has been waiting on the patent issue

voting response from the five horizontal tree equipment manufacturers. All tree manufacturers have agreed that the (3) example figures and information in Annex K are acceptable from a patent stand point as they exist today.

iii. The new “Normative” Annex L to the document addressing the performance qualifications for subsea drilling and tree hydraulic connectors was not agreed upon and has been

4

pulled out of the document. The Annex may be considered as a RP as part of SC17. Leadership team of SC17 has action to handle the Annex L issue. Note: May be cross fertilization with the flowlines connection/connection system WG.

iv. Recommended that Annex M, Performance reliability calculation method, be put into 17N or leave in 17D as a re-worked section or as an informative annex. Motion made and seconded to take Annex M out totally and given to 17N. Motion was passed to remove the Annex. Information is to be given to 17N with caveat to work this fully with respect to 17D needs.

v. Action to TG -4 team to compare sections on lifting currently in 13628-4 vs. current 13628-1 section on lifting. Only items specifically needed in 13628-4 need to remain. All other lifting be removed from 13628-4 and ensure that it is in 13628-1.

vi. All other comments were resolved. TG is ready to release current draft as a DIS pending resolution of above items.

e. ISO 13628-5 (API 17E)---Umbilicals---See Task Group Chair report (Attachment K)

i. John McManus reported that ISO is reviewing the document for editorial correctness prior to issue as a DIS. This work merges the API Task Groups and the DNV’s JIP efforts. The DIS is proposed to be out in August of this year.

f. ISO 13628-6 (API 17F)---Production Controls---No Report available. Verbal discussion.

i. The Adopt-back ballot simultaneous with the FDIS was completed in March with no negative votes, but with comments raising a problem with the definition of terms and their alignment with other pressure definitions in related documents.

ii. Publication of the ISO document was halted pending resolution of these comments jointly by ISO and API.

iii. After publication of the ISO document, potential editorial errors were brought to the attention of API. The material was reviewed. A portion of the issues will be contained in an API Errata, with the rest sent on to ISO for review and handling.

iv. To be Published by Year-end 2006 with an API Errata. g. ISO 13628-7 (API 17 G)---Completion/Workover Risers—No

report available. Verbal discussion. i. Brian Skeels was absent. The committee had suggested

that the task group re-address the IWOCS issue, along with what other systems they consider should be added to or

5

removed from the document and report back. Action still open

ii. John McManus to discuss with Brian Skeels for proposal on how and where IWOC umbilical should lay.

iii. Additionally, Brian is to propose how Part 7 (17G) will address the pressure barrier issue.

h. ISO 13628-8 &-9 (API 17 H&M)---ROV & ROT Systems--- See Task Group Chair report (Attachment L)

i. ISO 13626-8 (API 17H) has now been published. A new NWI has been raised and passed to combine parts 8 & 9 (17 H & 17 M) into one document which is to be ISO 13628-13

ii. Scope for 13628-13 will be drafted in Atlanta following SC17 meeting.

iii. Action to API to assign API letter for the merged17H & 17M. i. ISO/WD 16389 (API RP 2RD)---Dynamic Risers for Floating

Production---See Task Group Chair report (Attachment M) i. A NWI within ISO is now in place under 13628-12. ii. Working draft is being continually worked on. Goal is to

have revised draft by June 2007 for vote to go to DIS ballot January/February 2008.

j. API 17N---Subsea Reliability and Technical Risk Management--See Task Group Chair report (Attachment N1 & N2)

i. John Allen made TG report. ii. John Strutt is now 100% responsible for producing the

document. iii. The task group has reviewed the current status of the work

and its alignment with the ISO 20815 document. It was reported that ISO 20815 focuses on data gathering.

iv. The draft is ready and has been transmitted to 17N TG members for comment. (Attachment N3 - Draft 4)

v. The TG has applied for additional funds from API to manage a follow up workshop. They have also applied to Deep Star.

1. Workshop will present document and work examples and produce action items/feedback

2. Following this, API 17N will be reissued for global comment

vi. Olav Inderberg will review the 17N document and the existing ISO 20815 document and determine if an ISO NWI should be raised. The ISO group responsible for 20815 will be contacted to ensure they are in agreement.

vii. Motion made and passed for WG to present to ISO a request to raise a new NWI to raise a 13628 number to begin the process.

viii. The proposed API 17N workshops will work the comments section.

6

ix. Motion made and passed that following the raising of the ISO NWI, the SC17 requests ISO to issue the document as a working draft for comment.

k. API 17O---HIPPS---No formal report available. Verbal discussion. i. A preliminary document is ready for the task group’s review.

A working draft should follow soon. l. API 17P---Templates and Manifolds---See Task Group Chair

report (Attachment O) i. TG has been having regular meetings. The next TG meeting

will be held June 22nd. ii. Funding has been requested from API to assist in drafting

the DIS. 1. Understanding that $25,000 has been approved by

API. Contract letting is in progress. iii. Copies of Annex L have been received from the Materials

WG and there are areas of contention which are being resolved.

1. Hopefully comments received as part of the 17A/13628-1 review will also help resolve the 17P issues.

2. Action item for leadership team to ensure Annex L and 17P are not in conflict.

iv. PLETS & PLEMS are currently included and should be widened to include structures to protect trees.

v. Working draft is proposed to be completed end of September 2006 – with help from outside funding.

vi. NWI has been proposed in the ISO system. Borge Brudak, Statoil, is the ISO lead.

m. API 17Q---Systems Engineering---No report available. Verbal discussion

i. API 17Q will be retired. See a. vi above. n. Materials Study Task Group

i. See a. ix above. o. Buoyancy and Insulation Aspects ---No report available. Verbal

discussion i. Dave Wilkinson reported that Mike Given advised that the

existing proposed RP’s are not close to be finalized and not ready for issue.

ii. Action for Dave Wilkinson to follow up with Mike Given to determine way forward.

8. Leadership team to explore ways to get information out to the industry in a timelier manner. Action item given to Jonathan see if existing “poster” or new “flyer” recommendation can be made to the leadership team.

9. HPHT issues, API RP 6HP, is being handled in an ECS Task Group format with SC17 having members and voting representation. Funding

7

request to help write the document and for a JIP for testing has been approved by API and others.

10. Other Business; a. Andrew Wainright had previously recommended that API consider

a SC 17 specification that addresses Powered Winches and Reels for Coiled Product. NWI was not raised. This item should go to 13628-1. 13628-1 TG should consider if guidance should be provided in the next revision of 13628-1.

11. Sunset Committees was discussed by Gary Hurta. These committees are to reply to questions to the various subcommittees. (Attachment P)

a. Action to update Sunset team list by API. 12. 2006 Funding approvals:

a. $25,000 for 17P. Contract letting is in progress (Oct ’06). b. $50,000 to 17N. Funding was not requested in time for ECS review

at the Summer Meeting, but funding subsequently became available and contract letting is in progress (Nov ’06).

13. The NACE Liaison Report is attached (Attachment Q). 14. Next Meeting---Winter 2007. TBA; Summer June 25-29 2007 API Summer

Conference in San Francisco. See the API Meeting Webpage for Registration and Hotel information.

radforda

Text Box

Attachment A

20th Joint Meeting of ISO/TC67/SC4/WG6 and API SC17 Atlanta Hilton Hotel – API Summer Standards Conference

Atlanta, GA

June 14, 2006 – Joint Meeting - 8:00 am 1. Opening of the meeting (Bednar/Inderberg) 2. Roll call/Roster Update (Jordan) 3. Adoption of the proposed agenda (Bednar/Inderberg) 4. Adoption of the minutes from 19th joint meeting (Bednar/Inderberg) 5. Status and action plan update (See Attached Action Items) 6. Task Group/Project Group Reports (See Attached Work Program)

A. Subsea Production Systems (API TG7) • Discussion from Tuesday session

B. Flexible Pipe (API TG1) (Doynov) • ISO 13628-2/API Spec 17J & ISO 13628-11/API RP 17B – report on progress and status of JIP

to update standards • Status of ISO FDIS Ballot & Adopt-back for 17J/-2 & 17B/-11 • 17L - Flexible Pipe Ancillary Equipment JIP – report on progress to date

C. TFL Systems (API TG6) (Yonker) • ISO 13628-3/API RP 17C – Report on ballot to reaffirm

D. Subsea Wellheads/Tree (API TG5) (Frazer/Skeels) • ISO Spec 13628-4 – report on progress of DIS preparation

E. Umbilicals (API TG4) (McManus) • ISO 13628-5/API Spec 17E - report on progress of revision

F. Control Systems (API TG 2) (Neuenkirchen) • ISO 13628-6/API Spec 17F – report on FDIS & Adopt-back ballots

G. Completion/Workover Risers (Skeels) • ISO 13628-7/API RP 17G – report on FDIS & API Adoption ballots • Barrier philosophy for wellbore intervention systems

H. ROV/ROT (API TG3) (White) • ISO 13628-8 and –9/API RP 17H and RP 17M – report on progress of NWI to combine

documents into one standard I. Dynamic Risers (Stanton)

• ISO 16389/API RP 2RD – report on status of revision J. Subsea Reliability RP (Allen)

• Update on RP17N activity K. HIPPS RP (Goggans)

• Update on RP17O activity L. Templates and Manifolds (Whipple)

• Update on 17P activity M. Subsea System Engineering (tbd)

• Update on 17Q activity N. Materials Study Group (Haeberle)

• Update on activity 7. Summary of Discussions of Prior Meetings

• Composite Suite of API/ISO subsea standards and gaps in existing standards (Bednar/Inderberg) • Report on Path Forward for Insulation and Buoyancy Spec and RP (Given)

8. Other Business • Discussion of Sunset Committees Role (Hurta) • 2006/2007 Research Funding Proposals ()

9. Review of Action Items 10. Next meetings – Winter 2007, TBA; Summer 2007, June 25-29 San Francisco, CA

radforda

Text Box

Attachment B

API SC17 (ISO TC67/SC4/WG6), SUBCOMMITTEE ON SUBSEA PRODUCTION SYSTEMS

2006 WORK PROGRAM Revised June 2006 BRIEF DESCRIPTION OF WORK/SCOPE

API Standard

ISO Standard

API Chair ISO Project Leader SC17 Leadership

Team Champion

STATUS

Design and operation of subsea systems

RP 17A 13628-1 Luiz Souza, Petrobras America (TG7)

Per Dahl, Norsk Hydro

Wilkinson Published (Jan 2006)

Flexible pipe RP 17B 10420 Proposed as 13628-11

Krassimir Doynov, ExxonMobil (TG1)

Krassimir Doynov, ExxonMobil

Wilkinson FDIS ballot 2nd quarter ’06.

TFL systems RP 17C 13628-3 TBD (TG6) TBD Hurta API RP17C/ISO 13628-3 published. Reaffirmation ballot passed. No action needed at this time.

Subsea wellhead and tree equipment

Spec 17D 13628-4 Ross Frazer, ATP Vice Chair: Brian Skeels, FMC (TG5)

Ross Frazer, ATP Vice Chair: Brian Skeels, FMC

Hurta Work ongoing. Preparing for DIS submission. Resolution of patent issues in progress regarding horizontal tree issue.

Production control umbilicals

Spec 17E 13628-5 John McManus, Gibson Tube (TG4)

Ron Dee, Shell TBD Currently undergoing editorial checks, expect ISO DIS in 3rd quarter ’06.

Subsea controls Spec 17F 13628-6 John Bodine, Chevron (TG2)

Jens Neuenkirken, Statoil

Bednar ISO FDIS ballot closed March 19 (API TAG ballot March 10). API Adopt-back Ballot closed March 29.

Design & operation of completion/workover risers

RP 17G 13628-7 Brian Skeels, FMC

Anthony Muff, FMC

Hurta FDIS ballot skipped per ISO SC4 Resolution. API adopt-back ballot passed. To be published.

ROV interfaces RP 17H 13628-8 Charles White, DORIS, Inc (TG3)

Eric Luszi, Statoil Hurta ISO 13628-8/API 17H published. NWI passed to combine with 13628-9 to become 13628-13.

Unbonded flexible pipe Spec 17J 13628-2 Krassimir Doynov, Exxon Mobil (TG1)

Krassimir Doynov, Exxon Mobil

Wilkinson ISO DIS comments resolved. FDIS scheduled for 2Q06.

Bonded flexible pipe Spec 17K 13628-10 Krassimir Doynov, ExxonMobil (TG1)


Wilkinson Second Ed Published Nov 2005.

radforda

Text Box

Attachment C

BRIEF DESCRIPTION OF WORK/SCOPE

API Standard

ISO Standard

API Chair ISO Project Leader SC17 Leadership

Team Champion

STATUS

Flexible Pipe Ancillary Equipment (Spec)

Spec 17L1 TBD Krassimir Doynov, ExxonMobil (TG1)


Wilkinson Incorporating comments in working draft.

Flexible Pipe Ancillary Equipment (RP)

RP 17L2 TBD Krassimir Doynov, ExxonMobil (TG1)


Wilkinson Incorporating comments in working draft.

ROT Intervention System

RP 17M 13628-9 Charley White, DORIS Inc.

Eric Luszi, Statoil TBD NWI passed to combine with 13628-8 to become 13628-13.

Dynamic Risers RP2RD 13628-12 Paul Stanton, Technip

Paul Stanton, Technip

Bednar Working draft being prepared.

Subsea Reliability RP 17N TBD John Allen, Vetco-Grey

Olav Inderberg, FMC

TBD Working draft being prepared.

HIPPS 17O TBD Tim Goggans, FMC Tim Goggans, FMC Bednar Document ready for TG review.

Templates and Manifolds

17P TBD Jeff Whipple, Intec TBD Wilkinson Working draft being prepared.

Systems Engineering 17Q TBD (-TBD-) Olav Inderberg, FMC

Wilkinson Decision on continuing this project is pending discussion at next meeting.

Materials Study Group n/a annexes to existing

Tim Haeberle, Vetco-Grey

Ragnar Mollan, Norsk Hydro

Inderberg Generating annex materials for 17A (-1) and 17P

August 2006 1

ISO SC4/WG6 / API SC17 Action Items

June 14, 2006 Joint Meeting

Standard/ Subject

Action Item Last Update Current Status (items in bold are complete)

General Requirements 13628-1 (17A)

2004-14: Form a team to look at the scope of 17A/13628-1 with regard to these items and other new work topics as they relate to the composite suite of subsea standards. Some of the topics to be covered include: • Systems Engineering • Subsea processing • Multiphase pumping • Intelligent wells interfacing • Interaction between flowlines and

subsea structures • Integrated Production Umbilical (IPUs)• Spec breaks • Existing flowline specifications and

their relationship/applications to SC17

3/3/06 – Work session for Tuesday in Atlanta planned. Jonathan Jordan to send notice on Atlanta meeting and request input to L Souza on -1 content May 23-24 ISO Meeting planned for Paris. Olav Inderberg to send notice on Paris meeting. Olav Inderberg to follow-up on possible NWI for an RPIW interfacing

Complete. Will be removed following next meeting

2006- 7 Working group for flowline connections/ connection systems proposed to make recommendation of what and where this should go.

New Action Item 6/14/06 – Jonathan Jordan will put out an e-mail soliciting support. Craig Redding, SW Research, volunteered to lead the work group.

2006- 8 Working group for metering system requirements and needs to be identified to ascertain who is working on metering systems and what should SC17 do with regards to metering systems.

New Action Item 6/14/06 – SC17 Leadership Team with assistance of John Allen to get working group started.

2006- 9 Question as to whether 17A should continue its existence as a Recommended Practice or if it should be written as a specification.

New Action Item 6/14/06 – SC17 Leadership Team to give guidance.

2006- 10 17D work group to compare wording on lifting that is currently in 17A and only provide additional information in 17D which is not adequately supplied in 17A.

New Action Item 6/14/06 – Ongoing

2006- 11 Motion passed for SC17 to recommend that Clause 6 and Annex L go out for ballot to be included in 17A.

New Action Item 6/14/06 – Ongoing

2006- 12 Work Group to be formed to come up with recommendations for one definition of pressure rating for general use

New Action Item 6/14/06 – Glen Cuiper with AKS volunteered to chair the WG.

radforda

Text Box

Attachment D

August 2006 2

Standard/ Subject


Flexible Pipe 13628-2 (17J), 13628-10 (17K), 13628-11 (17B) 17L1, 17L2 (Ancillary Equipment)

2004-6: Olav Inderberg to prepare an ISO NWI based on the 17Ls work for consideration at the June meeting.

6/29/05 - Ongoing 9/30/05 – Ongoing 3/03/06 – Waiting on draft 6/14/06 – Waiting on draft

2004-18: Krassimir Doynov to forward a draft of 17Ls (when draft is deemed ready for widespread release) to be used in the ISO new work item and this should include a proposed title and how it could also include umbilicals.

9/30/05 - Ongoing 3/3/06 – Incorporating comments into draft documents 3/03/06 – Waiting on draft 6/14/06 – Waiting on draft

2006- 13 Motion passed to initiate adopt back immediately for 13628-11/17B in parallel with ISO when FDIS is completed.

New Action Item 6/14/06 – SC17 to initiate adopt back.

TFL 13628-3 (17C)

No outstanding action items

Subsea Wellheads and Trees 13628-4 (17D)

2006- 1 Resolve horizontal tree patent issue.

6/14/06 – All tree manufacturers have agreed that the examples are acceptable from a patent stand point


2006- 14 SC leadership team to address the new Normative Annex L document.

New Action Item 6/14/06 – Ongoing.

2006- 15 Motion passed to delete Annex M as part of 17D and be given to 17N.

New Action Item 6/14/06 – 17D chairman to transfer information to 17N.

Umbilicals 13628-5 (17E)


Control Systems 13628-6 (17F)


Comp./Work-over Risers 13628-7 (17G)

2005-5: Brian Skeels will prepare New Work Item to form a new API task group related IWOCS with ISO participation. This will then be submitted to Olav Inderberg to prepare an ISO New Work Item request before the June API meeting.

9/30/05 - Ongoing 3/3/06 - Brian Skeels to propose an approach on what systems (including IWOCS?) the TG will address and how the documents will be structured by June ‘06 meeting 6/14/06 – Ongoing.

August 2006 3

Standard/ Subject


2006-2: TG to provide a proposal with reference to barrier philosophy for well bore interventions systems.

New Action Item 3/3/06 - Brian Skeels to provide update on barrier discussion at June ’06 meeting 6/14/06 – Ongoing.

2006- 16 John McManus and Brian Skeels to propose how and where the IWOC umbilical goes.


ROVs 13628-8 (17H) ROTs 13628-9 (17M)

2006- 17 API to assign API letter for the merged 17H and 17M..

New Action Item 6/14/06 – API to assign letter.

17N (Subsea Reliability)

2006-3: Determine path forward on publication status

3/6/06 – John Allen to confirm API and Deepstar are aligned on issue of API document. Decide on timing for initiation of ISO NWI. John Allen to provide information to Olav Inderberg for SC4/WG6 meeting in May.


2006- 18 Olav Inderberg will review the 17N document and the existing ISO 20815 document to make judgment if new ISO NWI should be raised.


2006- 19 Motion passed for 17N work group to present request for NWI to raise a 13628 number.

New Action Item 6/14/06 – 17N WG to make request to ISO.

2006- 20 Motion passed that following the raising of the ISO NWI, the SC17 leadership committee to request ISO to issue the document as a working draft for comment.


HIPPS 17O


Templates and Manifolds 17P

2004-23: Olav Inderberg to initiate an ISO NWI on this subject.

3/3/06 – Waiting on working draft prior to NWI

Complete. Will be removed following next meeting.

August 2006 4

Standard/ Subject


2005-7: Jeff Whipple to circulate an electronic draft to 17P members for review. Olav Inderberg will send this draft to interested ISO members. Jonathan Jordan to post on API SC 17 website.

3/3/06 - FTP site created to facilitate TG input


2006-4: Jeff Whipple and Dave Wilkinson to develop proposal requesting API funding for technical writing of draft

3/3/06 – Jonathan Jordan to send RFP form to TG Chairs

. Complete. Will be removed following next meeting.

2006- 21 SC17 Leadership Team to ensure Annex L and 17P are not in conflict


System Engineering 17Q

2005-8: Revisit Systems Engineering in June 2005 and determine if there is a champion. All SC17 members are requested to consider who might be involved with this effort.

3/3/06 – Ongoing 6/14/06 – Systems Engineering will be worked further as part of 17A. 17Q is to be withdrawn. Complete. Will be removed following next meeting.

2006-5: Olav Inderberg to make presentation in Atlanta Meeting on Systems Engineering

3/3/06-Olav to prepare presentation


13628-12 (API RP 2RD) Dynamic Risers


General/ Admin.

2004-25: Leadership team to explore ways to get information out to industry in a more timely manner.

3/3/06 – Verify document status sheet on API website and/or develop dedicated page. Review System Poster in Atlanta

6/14/06 – Jonathan Jordan to see if existing “poster” or new “flyer” recommendation can be made to the leadership team.

2006- 22 The current SC17 Sunset Team listing is outdated. List needs to be updated with current member’s names.

New Action Item 6/14/06 – Jonathan Jordan to update the list.

Permanent Discussion Items

2001-18: John Bednar, Gary Hurta, and Olav Inderberg are to look at the direction that SC17 should be pursuing relative to the composite suite of API 17 Series general and specific documents that address the broad spectrum of subsea hardware.

3/3/06 – To be discussed at Atlanta meeting during -1 and -7 sessions.

6/14/06 – Ongoing.

2003-21: Maintenance of N172. 3/3/06 - Olav Inderberg to provide update on ISO progress on developing hierarchal definition structure at June ’06 Meeting.


August 2006 5

Standard/ Subject


New Work 2003-22: Brian Skeels to develop a plan for dealing with HPHT issues for subsea production system standards, addressing: - what areas should be covered in terms of equipment and procedures; - how this would best be integrated into the SC17 documents e.g. stand alone document versus HPHT Annexes in each existing document; - what else is going on in the industry in this regard e.g. API sponsorship of testing of effects of HT on material properties.

3/3/06: Maintain continued SC17 awareness of issue and provide input relevant to SC17

6/14/06 – Ongoing.

2004-13: Dave Wilkinson, John Bednar, and Andy Radford to determine path forward for Insulation and Buoyancy standards prior to the June meeting.

3/3/06 – Mike Given to provide update/recommendation at June ’06 Meeting.

6/14/06 – Dave Wilkinson to follow up with Mike Given to determine way forward.

2006-6: David Wilkinson to contact Andrew Wainright regarding his proposal for NWI on standardized installation reels for coiled subsea products

3/3/06 - Ongoing 6/14/06 – Ongoing

API SC 17

SUBCOMMITTEE ON SUBSEA PRODUCTION SYSTEMS

API 17A - Design and Operation of Subsea Production Systems – General

Requirements and Recommendations TASK GROUP STATUS

JUNE 14, 2006

radforda

Text Box

Attachment E

API 17P TEMPLATES AND MANIFOLDS STATUS REPORT

-1- 14-Jun-06

TABLE OF CONTENTS

1. INTRODUCTION ..............................................................................................................1-1

2. PREVIOUS REPORTED STATUS..................................................................................2-1

3. MEMBERSHIP ..................................................................................................................3-2

4. UPDATED TARGET DATES FOR DELIVERABLES.................................................4-3

5. MAJOR ISSUES.................................................................................................................5-3

6. ANTICIPATED NEW WORK ITEMS ...........................................................................6-3

7. PLANS FOR FUTURE MEETINGS ...............................................................................7-3

8. RESOURCE NEEDS .........................................................................................................8-3


-1- 14-Jun-06

1. INTRODUCTION

On the March 3 joint ISO/TC67/SC4/WG6 and API SC 17 meeting, the 17A TG was asked to plan a working meeting for the Tuesday June 13th, on the API Summer Standards Meeting, in Atlanta, GA. The objective of the meeting was to look at the scope of 17A/13628-1 with regard to the items that may be considered for inclusion in a next revision of the recommended practice or to be related to the composite suite of subsea standards.

The meeting was held with 24 participants. The ISO 13628-1 Project Leader presented the result of a Materials task group to develop the material requirements in the ISO13628 suite of standards. This work has progressed well and a draft for an official Amendment to ISO 13628-1 Clause 6, Materials and corrosion protection” is now available together with a proposal for a new Annex L "Materials and welding of subsea manifolds". The efforts from the ISO TG to identify items that may be considered for inclusion in a next revision of the recommended practice was used as starting point for the meeting discussions.

A list of items identified during the meeting and reported in the Minutes of Meeting are attached to this report.

An action from the last meeting to discuss if the 17A should remain as a Recommended Practice or to be changed to an API Standard was discussed. No resolution on this at present.

2. PREVIOUS REPORTED STATUS

The previous status was a verbal report that the 17A/13628-1 Revision 4 was issued in January 2006 and the plan for the working meeting to discuss new revisions items to Part 1 was ongoing with the ISO team planning a similar work meeting in Paris on May 23 and 24.


-2- 14-Jun-06

3. MEMBERSHIP

Table 1 shows the current volunteer membership for the API 17A TASK GROUP and Table 3.2 the corresponding ISO group members:

TABLE 3-1: API 17A TASK GROUP MEMBERS Name Company E-mail

Olav Inderberg FMC [email protected] Luiz Souza (Chair) Petrobras America [email protected] David Wilkinson ExxonMobil [email protected] John Bednar BP [email protected] Brian Skeels FMC [email protected] Gary L. Hurta Dril Quip Rolf Nordaunet ABB Steve Dean Agip Giorgio Pastore Agip Alain Creatine Total Mauricio Werneck Petrobras Eric Wehner Cameron John MacManus Gibson Tube

TABLE 3-2: ISO GROUP MEMBERS

Name Company E-mail Per Ragnar Dahl (ISO 13628-1 Leader) Hydro Krassimir Doynov ExxonMobilJohn Yonker HalliburtonRoss Frazer ATP Ron Dee Shell Jens Henrik Neuenkirchen Statoil Antony Muff FMC Tim Marsh Shell Erich Luzi Statoil Paul Stanton Technip


-3- 14-Jun-06

4. UPDATED TARGET DATES FOR DELIVERABLES

No deliverables defined at present.

5. MAJOR ISSUES

No major issues to be resolved at this moment.

6. ANTICIPATED NEW WORK ITEMS

New items may be identified during the review of issues to be incorporated in SC17.

7. PLANS FOR FUTURE MEETINGS

Tentatively the a task group meeting is proposed in fall of 2006 to discuss the path forward to review items identified in the Atlanta working meeting.

8. RESOURCE NEEDS

A board review team is being proposed with chairs of the other SC17 to review the issues being proposed and possible interfaces with their SC17 sections. Interested parties are requested to contact Luiz Souza at [email protected] or +1-(713)-458-7923 or Per Dahl at [email protected] or +47 9172 8832.

ISO/TC67/SC4/WG6 Subsea production systems ISO 13628-1 Design and operation of subsea production systems – Part 1: General recommendations and requirements Task Group status report – June 2006 1. Membership of task group ISO Project leaders; Part 1 project leader: Per Ragnar Dahl, Hydro, Norway Other ISO 13628 project leaders: Krassimir Doynov - ExxonMobil John Yonker -Halliburton Ross Frazer - ATP Ron Dee - Shell Jens Henrik Neuenkirchen - Statoil Antony Muff – FMC Tim Marsh – Shell Erich Luzi – Statoil Paul Stanton – Technip Other task group members; Olav Inderberg – FMC Luiz Souza – Petrobras (API 17 A) David Wilkinson – ExxonMobil John Bednar – BP Bruce Crager – Intech Brian Skeels – FMC Gary L. Hurta – Dril Quip Rolf Nordaunet – ABB Steve Dean / Giorgio Pastore – Agip Alain Creatine – Total Mauricio Werneck – Petrobras Eric Wehner - Cameron John MacManus – Gibson Tube

radforda

Text Box

Attachment F

2. Status of work item ISO 13628-1, second edition was published 2005-11-15. It has been adopted as EN ISO 13628-1, November 2005 without any changes. It has also been adopted as API RP 17A, fourth edition, January 2006 (identical). The joint API SC17 and ISO TC67/SC4/WG6 meeting agreed to create a Materials task group to develop the material requirements in the ISO13628 suite of standards. This work has progressed well and a draft for an official Amendment to ISO 13628-1 Clause 6, Materials and corrosion protection” is now available together with a proposal for a new Annex L "Materials and welding of subsea manifolds". Reference is made to the separate report presented by the Materials task group. 3. Updated target dates for deliverables DIS ballot for the Amendment may start July-August with publication of the Amendment early 2006. 4. Major issues No major issues remains to be solved at this moment. 5. Anticipated new work /new work items Part 1 is the main subsea production systems standard and it needs to be regularly maintained. During the last revision process some comments were left for later considerations. These comments were suffixed with “noted” in the commentary report. The following list present by keywords “noted” issues from the commentary report and some issues that has been defined after the commentary report was closed. - Separate doc for Annex A to be considered - Define drilling loads (work has started by DNV for Standards Norway)

- Include separate paragraph to consider physical interface to subsea processing equipment such as pumps, metering equipment etc.

- Template and manifold (section 5.12 and Annex G) is proposed merged and pulled out into a separate ISO 13628 part 15 to be co-ordinated with the API 17P work.

- Commentaries report Ref NO 052. - Landing speed suggested moved to part 9. - Ref NO 054. Include running clearances - NO 055.Consider suction systems. - Ref US 049. Definition of dropped object protection and trawl resistant

structure. - US 067. Consider special tests for handling systems etc. - US 068. Consider reversibility and repeatability tests - US 076. Commissioning of a subsea processing system

- US 077. Additional information for annex F - US 079. Control valve actuators to be considered - US 099 Ref 6.2.1 This section discusses acid-gas related chemical

corrosion on an "agreed-upon model" basis, while direction is given to correlations for corrosion for oxygen. In section 6.2.1.5, this is related to flow phenomena. This should probably refer to individual standards, rather than these specifics.

- Subsea processing issues - Terminology and definitions to be consistent with the N172 document. - Revisit the system engineering guidelines - Flanges design etc.

In particular, Annex A of this part has become large and voluminous, with mainly tutorial text. One DIS comment suggested that this Annex should be split out of the standard as a stand-alone ISO document. This comment was not accepted at this time, but merits further considerations and should be discussed at future meetings. The initiative to revise the material clause 6 needs to be amalgamated with the standard and further developed as necessary. Future work should also typically examine the need for describing physical interfaces to subsea processing equipment such as separators, sand management systems, pumps, metering equipment etc. In addition, maintenance of Part 1 can also be triggered by changes in the other corresponding parts or by activity on upcoming new work items as e.g. the template and manifolds, system engingeering, HIPPs and other initiatives. 6. Plans for future meetings None. However, in view of comments above, it is suggested that the issues mentioned above be discussed at a task group meeting, late fall/early winter 2006. Interested parties are requested to contact the undersigned at [email protected] or +47 9172 8832. 7. Resource needs (money and/or people) No further need at present. Per Ragnar Dahl, Hydro June 2006

SC17 Working Meeting on 13628-1/17A Atlanta, GA – June 13th 2006

Luiz Souza made opening comments and presented general agenda. (Copy attached) Per Ragnar Dahl gave presentation on ISO comments and recommendations. (Copy attached) It was agreed that the purpose of 13628-1/17A is:

• Primer – and is a primary reason that Annex A should remain in the document and not be split into another document

• Glue which holds the subsections together • Brooding Place to allow an area for discussion until ready to separate as stand

alone or movement into other subsection • Systems perspective • Collection of independent components • Operability as a system – Operation /flow assurance • Interfaces with each other and each subsection of SC17 as well as interfaces with

other outside specification • TG is to decide format/locations (i.e. annexes, body of sections) for system and

interface content Must ensure linkage with interface and give guidance in system approach. Example qualitative vs. quantitative guidance for SCSSV. General requirements (material/marking/colors/lifting/etc.) satisfactory and nothing needs to be added or deleted. Note: check needs to be made with table in Annex K and 17D to ensure all is ok Work Group made following recommendations on the following:

1. Materials: general is captured in clause 6 of -1. Presentation tomorrow will give new clause 6 and Annex L. It will remain in -1 until 17P is ready for publication. Fall-off from 6HP as applies to 17 materials will be noted.

2. Template & manifolds will be kept as separate document. Work already in -1 will be moved to P when P is ready.

3. Light well intervention: no document exists and it is low on the priority wish list for documents. It was agreed to consider someone write a paragraph or two for -1 and keep it as a brooding poing.

4. Sub sea power cable connectors are not covered anywhere. Consideration should be given to include this in -5 or -6. It probably. goes best in -6.

5. Flying leads and connections is briefly touched in -6. It was agreed that this needs to be checked to ensure work is complete enough. It is considered to be insufficient.

6. IPU were discussed and it was agreed there is no push for a new standard but we should consider general guideline information be put in -1.

radforda

Text Box

Attachment G

7. HIPPS is being worked on by API. ISO is in a wait and see mode. Nothing to be done further in -1 at this time.

8. Subsea Reliabity will be discussed in detail tomorrow. 9. Subsea Pig Launching was discussed and it was agreed there is no push for a new

standard but we should consider general guideline information be put in -1. This could possibly be part of -13.

10. Gages and sensor was discussed and it was agreed there is no push for a new standard but we should consider general guideline information be put in -1.

11. Sand detection/leak detection was discussed and it was agreed there is no push for a new standard but we should consider general guideline information be put in -1.

12. Subsea processing was discussed and it was agreed there is no push for a new standard but we should consider general guideline information be put in -1.

13. Flowline connections and connection systems will be discussed tomorrow. It was agreed that this topic was prime for a NWI as a stand alone or combined with templates and manifolds.

14. IWOCS and IWOC umbilicals will be discussed tomorrow. 15. Metering systems: a TG will be put together to identify needs and identify what

other groups are working on this. TG to submit a report on status and what SC17 needs to do.

16. Spec Breaks is in -1 17. Coiled tubing is in -7. 18. Dropped objects is a -1 topic. Propose putting an annex in -1 on dropped object

strategies. Do not put under specific sections. 19. Foundations/suction piles were confirmed to be included in manifolds and

temperature and not -1.

API Summer Standards Conference – Atlanta , GA

Task Group on Subsea Systems (SC17/TG7) Working Meeting – June 13th 2006 1:00-5:00 pm

Meeting Objectives

1) Review the API 17A/ISO 13628-1 with regards to new work topics including :

Systems EngineeringSubsea ProcessingMultiphase PumpingIntelligent Wells InterfaceInteraction between flowlines and subsea structuresIntegrated Production Umbilicals (IPUs)Spec BreaksExisting flowline specifications and their relationship/applications to SC17

radforda

Text Box

Attachment G-1


Meeting Objectives (Cont.)

2) Review the API 17A/ISO 13628-1 with regards to its content and need to remain as Recommended Practice

3) Any ongoing Subsea Matters


Safety Moment

As the summer driving season approaches and the use of outdoor power and sports equipment begins to increase, the American Petroleum Institute and the Petroleum Equipment Institute are reminding motorists how to avoid potential problems with static electricity at the gasoline pump and to follow all safe refueling practices. Motorists may be refilling portable gasoline containers more, with an increase in lawn care and outdoor summer motor-sport activities.

http://api-ec.api.org/media


ISO Task Group status report – June 2006

-Separate doc for Annex A to be considered-Define drilling loads (work has started by DNV for Standards Norway)-Include separate paragraph to consider physical interface to subsea processing equipment such as pumps, metering equipment etc.-Template and manifold (section 5.12 and Annex G) is proposed merged and pulled out into a separate ISO 13628 part 15 to be co-ordinated with the API 17P work.Commentaries report Ref NO 052. -Landing speed suggested moved to part 9.-Ref NO 054. Include running clearances-NO 055.Consider suction systems.-Ref US 049. Definition of dropped object protection and trawl resistant structure.-US 067. Consider special tests for handling systems etc.-US 068. Consider reversibility and repeatability tests-US 076. Commissioning of a subsea processing system-US 077. Additional information for annex F-US 079. Control valve actuators to be considered-US 099 Ref 6.2.1 This section discusses acid-gas related chemical corrosion on an "agreed-upon model" basis, while direction is given to correlations for corrosion for oxygen. In section 6.2.1.5, this is related to flow phenomena. This should probably refer to individual standards, rather than these specifics.-Subsea processing issues-Terminology and definitions to be consistent with the N172 document.-Revisit the system engineering guidelines-Flanges design etc.

Atlanta 13th June 2006

New Revision of ISO 13628 Part 1, General Requirements and Recommendations

radforda

Text Box

Attachment G-2

Date: 2006-05-09 • Page: 2

A Premature Start?

Second edition of ISO 13628-1 was issued November 2005However, several issues raised during the revision process were postponed to next revisionIt was promised that preparation work for a new revision should start immediately after issue of second edition.In addition new items have also emerged.

Date: 2006-05-09 • Page: 3

Materials

New experiences within duplex and HISC materials have instigatedurgent need for revisionAmendment to Part 1 is prepared:

Clause 6 Materials and corrosion protectionNew Annex L Material and welding of subsea manifolds

Propose new Annex L is temporary and informativeTo be removed when new standard (Part 15) has been publishedComments to section 6.2.1 (corrosivity evaluation) to be redirected to Amendment.

Draft documents were submitted 25th May 2006Proposal: Approve amendment for DIS ballot

Date: 2006-05-09 • Page: 4

Annex A

Large and voluminous with mainly tutorial textProposal to split this out of the standard was turned down, but should be further discussedPros and Cons:

Size and readability of standardImportant information necessary for users to obtain common understand of systems and notionsA brooding box for new areas and items for later development to requirements in a standard

Proposal: Provide an index for this Annex, keep it in standard

Date: 2006-05-09 • Page: 5

Drilling loads

Riser loads transferred to wellhead system are described in section 5.6.2.2. However, new drilling and completion methods have lead to extended riser connection times, which require update of guidelines.

Study work for updating of requirements is ongoing at DnV

Revised guidelines and requirements could be added to the standard as a second Amendment.

Date: 2006-05-09 • Page: 6

Drilling loads – DnV preliminary results

The wellhead is significantly being exposed to fatigue riser loadsThe wellhead system is not covered by a code for what method to apply for fatigue calculationsThe wellheads, especially for water depth <~100 m, are highly utilized and stressed.Through ISO 13628-4, is the conductor a pressure vessel? …and hence guidance given to a fatigue assessment.Unknown quality and effect of cement between 30” conductor and 20” casing needs to be addressed.By applying well-known methodology and acceptance criteria, it seems that wellheads and conductors are utilized to a lower margin to failure than what commonly is targeted by industry, and enforced to comply with. (10-4)

Date: 2006-05-09 • Page: 7

Wellhead capacity and fatigue life calculation

Following figure is found both in ISO 13628-1 and ISO 13628-4.

Following figure is found in ISO 13628-7

Requirements for risers are adequate - but methods and guidelines for wellhead and conductor calculations are not given.

Date: 2006-05-09 • Page: 8

Template and Manifold

Proposal to pull out major parts of section 5.12 and Annex G to a future separate standardComment on definition of dropped object protection and trawl compatibilityComment on suction systemsImpact loads – definitions and methodology could be elaboratedInteraction between flowlines and subsea structuresWork on API 17P is ongoing

Propose to launch joint API/ISO work and NWIP for ISO 13628-15Changes to Part 1 to be reviewed when the new standard has reached DIS/FDIS level

Date: 2006-05-09 • Page: 9

Subsea Processing Equipment Comments

Text to be elaborated on these areas:

Physical interfacesControl system interfacesMultiphase pumpingUse of process control valvesCommissioningRelevant standards

Date: 2006-05-09 • Page: 10

Systems Engineering

Section 5.3, 5.5 and annex HEnsure top-dop approach during new developmentsSubsea system part of overall systems

– System responsibility (”transverse systems”)– Overall functional analysis– Interfaces

Incorporation of subsystems and components– Design norms and guiding documents– Definitions and utilisation of physical properties

Operational aspects– Barrier philosophy, ESD/PSD– Fault diagnostics, testability, degraded modes

Proposal: Improve this part of the standard

Date: 2006-05-09 • Page: 11

Miscellaneous comments

Flanges design section 5.11.3.7Spec breaks section 4.3.2Flowline specs relationship section 5.11.3.4/5Landing speed section 5.12.7.3Running clearances section 5.12.7.3Test repeatability/traceability section 7.1.1

Comments need further evaluation

Date: 2006-05-09 • Page: 12

Others

Interface to pipelines and connection systemsInterface to electrical heated pipelinesInterface to smart well completions (ref Part 6)Interface to SCSSV ref ISO 10432Integrated Production Umbilicals

To be further evaluated

Date: 2006-05-09 • Page: 13

Conclusion and Proposal

Sufficient need for revision warrantedPropose that the existing Task Group of Project Leaders for the other ISO 13628/API 17 standards plays the function as a review boardIn addition a smaller Working Group of volunteers should be formed to draft textPropose first WG meeting in early winter 2006

Date: 2006-05-09 • Page: 14

Contact details

Per Ragnar Dahl,Norsk Hydro,N-0246 Oslo, Norway

e-mail: [email protected]

tel.: +47 917 28 832+47 22 53 87 98

mailto:[email protected]

Ragnar Mollan, Hydro (Oslo)Maarten Simon Thomas, Shell (Houston)

Material requirements in ISO 13628 standards -Subsea Materials Task Group.Status report for API SC17-ISO SC4/WG6 meeting, Atlanta June 14 2006.

radforda

Text Box

Attachment H

Date: 2005-01-28 • Page: 2

Subsea Materials Task Group

Results

The Task Group has prepared a draft Amendment to ISO 13628-1 consisting of two parts:

– A new Clause 6 of ISO 13628-1, "Materials and corrosion protection", and

– A new Annex L, "Materials and welding of subsea manifolds".

Date: 2005-01-28 • Page: 3


BasisThe joint API SC17 / ISO TC67/SC4/WG6 meeting, Houston 2005-02-03, agreed to solicit support for creating a materials task group to develop the material requirements in the ISO13628 suite of standards. Industry interest has been overwhelming both in the Us and in Europe.

Background for the proposal:– The industry wants to use the ISO 13628 standards as basis for

contracts for subsea production systems.– The material requirements in the standards need to be further

developed to meet industry and end user needs.– By implementing the materials requirements currently used by the

industry in the standards, the need for material requirements incompany and projects specifications would be reduced. This wouldcreate a more predictable situation for suppliers, manufacturersand contractors.

Date: 2005-01-28 • Page: 4


Mandate1. Propose materials requirements to the 13628 series of standards,

with initial priority on part 1 – General requirements and recommendations.

2. Co-operate with and report to the project leader for ISO 13628, part 1 initially, and subsequently the other ISO 13628 parts’project leaders as relevant.

3. Requirements which are common for most products to be included in part 1. Requirements related to particular products, to be placed in the relevant product standard parts 2-11 of 13628.

4. The schedule for the work to be made initially to suit part 1 and subsequently to suit the revision plan for the product standardsparts 2-11. Temporary use of the product related requirements, until these standards are revised, to be considered.

Date: 2005-01-28 • Page: 5


Meetings held

1. Kick off meeting for the group was held in Houston 6. April 2005, in connection with the annual NACE Corrosion conference.

2. Second meeting held in Lisbon, Portugal.(In connection with Eurocorr 2005, 4. September 2005.)

3. Third meeting 1.-3. November, Oslo, Norway.

4. Fourth meeting 9.-10. March, Houston, Texas.(Week prior to NACE Corrosion Conf., San Diego, California.)

Date: 2005-01-28 • Page: 6


Work process

1. Most of the work has been conducted based upon e-mail correspondence. The work has been split into two groups, one working on Clause 6(“Materials and corrosion protection”) and one on Annex L (“Materials and welding of manifolds”).

2. The work has been based upon latest editions of the ISO 13628 standards, i.e. both issued and draft standards.

3. All relevant standards have been available for the group through ISOLivelink on the Internet. Other documents such as presentations, minutesof meetings, etc. have been made available. The work group has not been able to actively use the internet area for commenting.

4. Drafts have been submitted to the group for comments, the comments have been debated and the consensus conclusions have been implemented. All comments and proposed implementation in the documents have been summarized and submitted to the group members together with revised drafts.

5. The group has 35 members. Contributions have been received from several persons who do not appear on the list of members.

Date: 2005-01-28 • Page: 7

Participants

Date: 2005-01-28 • Page: 8

Participants, cont.

API SC 17


API 17C

RECOMMENDED PRACTION ON TFL (THROUGH FLOWLINE) SYSTEMS

TASK GROUP STATUS

JUNE 14, 2006

radforda

Text Box

Attachment I


-1- 3-Mar-06

TABLE OF CONTENTS

1. INTRODUCTION ..............................................................................................................1-1


3. MEMBERSHIP ..................................................................................................................3-2


5. MAJOR ISSUES.................................................................................................................5-2



8. RESOURCE NEEDS .........................................................................................................8-2


-1- 3-Mar-06

1. INTRODUCTION

The API 17C Task Group has been responsible for the development of the Recommended Practice on TFL Systems. The group is currently in the document maintenance mode and there are no activities taking place at this time.

• …

• …


The standard was reaffirmed in 2005 by SC17 ballot.


-2- 3-Mar-06

3. MEMBERSHIP

Comments:

TABLE 3-1: API 17X TASK GROUP MEMBERS Name Company E-mail John Yonker Halliburton John.,[email protected] Brian Skeels FMC [email protected] Rob Thurman Halliburton [email protected] James Cordner


N/A

5. MAJOR ISSUES

No comments or suggestions for changes, improvements, or updating have been received by the Project Leader. The project leader has contacted three of the members of the original Task Group and none of these has received any comments for changes or suggestions for improvement from those currently using the document.


None.


None.

8. RESOURCE NEEDS

N/A at this point.

API C2 / SC 17


API 17D Subsea Wellheads and Christmas Trees

TASK GROUP STATUS

11 JUNE 2006

radforda

Text Box

Attachment J

API 17D WELLHEADS AND TREES STATUS REPORT

-1- 11 June 2006

TABLE OF CONTENTS

1. INTRODUCTION ................................................................................................................. 1

2. STATUS ................................................................................................................................. 1

3. MEMBERSHIP ..................................................................................................................... 2

4. TARGET DATES FOR DELIVERABLES........................................................................ 3

5. MAJOR ISSUES.................................................................................................................... 3

6. ANTICIPATED NEW WORK ITEMS .............................................................................. 3

7. PLANS FOR FUTURE MEETINGS .................................................................................. 3

8. RESOURCE NEEDS ............................................................................................................ 3


-1- 11 June 2006

1. INTRODUCTION

The API 17D task group’s scope is to develop a second edition of the specification, combining ISO 13628-4 and API 17D into a second edition of 13628-4. Once that ISO document is fully balloted & accepted, it is planned that it will be adopted by API as the second edition of 17-D. Items for consideration for the new edition of the specification include:

• Revised information on gaskets and flanges

• Addressing GLL and HXTs

• Revised mudline equipment definitions

• Updated pressure testing and acceptance criteria

• Sections on material compatibility testing and lifting devices

• Pressure ranges (limit to 15k equipment)

• PSL, material class and temperature class

• Annular monitoring requirements

2. STATUS

In March, we reported on the hoped-for release of the updated specification as a draft international standard (DIS). Representatives of all the manufacturers met with task group leadership on 27 April to review Annex B, Horizontal Trees. The manufacturing community committed to reviewing the Annex and advising API staff (Andy Radford) whether or not they were comfortable with its inclusion in the DIS. The latest draft of the specification was distributed to the entire task group the following week with instructions to review it and submit comments. Advice was included in the distribution that a meeting to resolve the comments would be held on 07 June in Houston.

That meeting was attended by representatives of all the manufacturers and the MMS. Notable outcomes of the meeting were:

• All the subsea tree manufacturers (Cameron, Dril-Quip, FMC, Kvaerner and Vetco) were represented and comfortable with the specification being released with Annex B, Horizontal Trees, in its current form.

• The attendees at the meeting voted unanimously to remove Annex L, Performance verification (qualification) of wellhead connectors, from the document. Furthermore, those present recommended unanimously that this annex be issued under the banner of an API Recommended Practice. It was also suggested that subcommittee 16 members be given the opportunity review the annex since the topic reaches into their expertise.

• It was also unanimously recommended that Annex M, Performance verification (qualification) reliability calculation method, be put into 17N. Having said that, the attendees were comfortable leaving it in 17D/-4 if the SC 17 leadership team desires that route.


-2- 11 June 2006

• All comments were resolved and have been forwarded to API staff (Andy Radford) for delivery to the ISO secretariat. These will be incorporated into the standard prior to its release in DIS format.

3. MEMBERSHIP

The current membership is listed below. The task group leadership is in the process of updating this.

API 17D TASK GROUP MEMBERS (JUNE 2006)

Name Company E-Mail Address

Ross Frazer ATP Oil & Gas [email protected]

Brian Skeels FMC Energy Systems [email protected]

Tom Ames BP [email protected]

Don Wells ConocoPhillips [email protected]

Gary Hurta Dril-Quip [email protected]

Tim Dean Kerr-McGee [email protected]

Sterling Lewis ExxonMobil [email protected]

David Lacaze Shell [email protected]

Sean Thomas Vetco Gray [email protected]

Loren Kowalchuk Master Flo [email protected]

Mike Larkin Cameron [email protected]

Russell Hoshman MMS [email protected]

Tony Ratcliffe ChevronTexaco [email protected]

James Waithman KBR [email protected]

Karl Winter Mariner Energy [email protected]

Erik Opoien Hydro [email protected]

Alain Cretenet Total [email protected]

Tor Geir Wernø Statoil [email protected]

Bhailal Parmer Chevron [email protected]

Finn Kirkemo SeaFlex [email protected]

Ed Knerr Technip [email protected]

Alternates

Chris Bartlett FMC Energy Systems [email protected]

David Morgan Cameron [email protected]

Dave Garnham Cameron [email protected]

Mike Conner MMS [email protected]

Bobby Voss Vetco Gray [email protected]

Frank Gallander ChevronTexaco [email protected]


-3- 11 June 2006

4. TARGET DATES FOR DELIVERABLES

The DIS will be ready for release once all the comment resolutions have been incorporated into the current draft. It is estimated the DIS will be released by the end of August. This is subject to confirmation by the ISO secretariat.

5. MAJOR ISSUES

None at this time.


None at this time.


None at this time. The task group will wait on direction from ISO TAG regarding steps after submittal of the DIS.

8. RESOURCE NEEDS

None at this time.

API C2 / SC 17


API 17E SPECIFICATION for SUBSEA UMBILICALS

REVISION TASK GROUP STATUS

JUNE 14, 2006

radforda

Text Box

Attachment K

API 17E/ISO 13628-5 SUBSEA UMBILICALS

-1- June 14, 2006

1. INTRODUCTION

On June 18, 2003 the NWI was formally sanctioned by SC17 for the API TG to work on a revision of the joint API/ISO document. The API 17E TG began the revision process by correcting or supplementing areas of the document which were deemed weak or incorrect.

In June 2004 a JIP was formed by DNV. The JIP began work on selected items and worked in parallel to the API TG.

In October/November 2004, a NWI was formally submitted by Olav Inderberg to the ISO committee.

2. STATUS

A final merged, API TG & DNV JIP, document was agreed upon in early December 2006. Following final clarifications with the ISO Expert Group, the completed document was sent to Shell Hague to undergo review to ensure ISO editorial correctness. It will then be submitted to the ISO secretariat to issue as a DIS.

3. MEMBERSHIP

Task Group

The working task group is made up of the following personnel:

TABLE 1-1: API 17E TASK GROUP MEMBERS

Name Company e-mail John McManus RathGibson [email protected] Katrina Clausing Shell International Exploration & [email protected] Peter Worman Chevron [email protected] Dave Madden DUCO Inc. [email protected] Fraser Thomson Oceaneering Multiflex [email protected] Teguh Inarsoyo BP [email protected]

Alternate to Katrina Tom Williams Shell International Exploration & [email protected]

Note: Teguh Inarsoyo has recently joined the TG and will support DIS & FDIS clarifications and the next revision effort.


-2- June 14, 2006

Reader/Comment Group

The reader/comment group is made up of the following personnel:

1. Mark Stevenson Chevron 2. Virginia Nelson Chevron 3. Jason Ellis Chevron 4. Dave Wilkinson ExxonMobil 5. Paul Donavan ExxonMobil 6. David Micheleti ExxonMobil 7. Godfried Dekeyser Pioneer Energy 8. Paul Shaw Alpha Petroleum 9. John Respess Marathon Oil 10. Lisbeth Holst Norsk Hydro 11. Sigmund Lunde Norsk Hydro 12. Knut Ivar Ekeberg Nexans Norway AS 13. Kjell Garvik Aker Kvaerner Subsea AS 14. Tim Wooters Cabett 15. John Brown DUCO Ltd. 16. Peter Fellows DUCO Ltd. 17. John Tokaruk Sandvik Steel 18. Dave O’Donnell RathGibson 19. Kurt Jones SeaCAT Corp. 20. Ken Bertram Webco 21. Philippe Roelants Intec Engineering 22. Jim Morrison Pegasus International 23. Steve Mansfield J P Kenny 24. Fraser Gourlay Consultant 25. Vincent Ledoux Technip 26. Jean François Saint Marcoux Paragon Engineering 27. Darrel Evans Stolt Offshore 28. Norb Gorman Oceaneering International 29. Jeremy Woulds/Jim Macklin Cal Dive International 30. Sandy Fraser Subsea 7


-3- June 14, 2006


Table 4-1 shows the new proposed milestone targets:

TABLE 4-1: MILESTONE TARGET DATES

Milestone Targets Proposed Completion Date

Final agreed text merge of API TG and DNV JIP work

December 2005 / Completed

ISO “expert group” review December 2005 / January 2006 Completed

Final clarifications February 2006 / Completed

ISO review for editorial correctness / Shell Hague

March 2006 / June 2006 Completed??

Send updated DIS proposal to SC 4 July 2006 / 1 month

Send to ISO secretariat in Geneva to issue the DIS

August 2006 / 2 months

Publication of ISO DIS September/October 2006

5. MAJOR ISSUES

None at this time.

6. ANTICAPTED NEW WORK ITEMS

Following publication as DIS, a NWI will be prepared to begin next revision process.


Next API TG meeting is July 2006 to discuss timing for next revision. Note: certain items were intentionally omitted in this revision as there was either not enough existing data to corroborate and/or group consensus to include in this revision.

8. RESOURCE NEEDS

None at this time.

API C2 / SC 17


API 17H & 17 M / ISO 13628-8 & ISO 13628-9

ROV & ROT

TASK GROUP STATUS

JUNE 13, 2006

radforda

Text Box

Attachment L


-1- 3-Mar-06

TABLE OF CONTENTS

1. INTRODUCTION ..............................................................................................................1-1


3. MEMBERSHIP ..................................................................................................................3-2


5. MAJOR ISSUES.................................................................................................................5-2



8. RESOURCE NEEDS .........................................................................................................8-3


-1- 3-Mar-06

1. INTRODUCTION

The API 17H and API 17M were adopted in 2004 from ISO 13628-8 and ISO 13628-9 respectively. A new work item has been identified to combine the two standards into one new standard titled ISO 13628-13:

Comments to the previous release of the standards will need to be incorporated into the next revision.


Since the June API SC17 & ISO TC67-SC4-WG6 joint meeting, we have identified an API task group leader and an ISO task group leader.

Comments to both API 17 H & API 17 M, that have been compiled over the past few years have been circulated to the task group members for review.


-2- 3-Mar-06

3. MEMBERSHIP

Membership to the task group has grown with several new members participating. Table 3-1, Table 3-2, and Table 3-3 show the changes in the current volunteer membership for the API 17P RP:

TABLE 3-1: API 17P TASK GROUP MEMBERS - HOUSTON Name Company E-mail Charles White Doris Inc [email protected] Tim Marsh Shell [email protected]

TABLE 3-2: API 17P TASK GROUP MEMBERS - OVERSEAS Name Company E-mail Erich Luzi Statoil [email protected]


Table 4-1 shows the current proposed milestone targets:

TABLE 4-1: MILESTONE TARGET DATES Milestone Targets Proposed Completion Date

First Working Meeting 06/06

5. MAJOR ISSUES

None at this time


None at this time


-3- 3-Mar-06


Meet at the June API SC17 & ISO TC67-SC4-WG6 joint meeting in Atlanta between task group leaders. Continue to correspond by e-mail until the scope of the document has been agreed.

8. RESOURCE NEEDS

Task Group members once a scope and working table of contents has been defined.

Meeting ISO -API Date: 20-02-06 Venue: Vetco Offices, 90 Long Acre London

Agenda

1. Schedule for ISO and API

2. ISO review

3. Review Progress on 17N a. Document 17-01-06 sent out b. Comments and resolutions (History document)

4. API 17N structure: document issues to be resolved

a. content b. length c. detail d. layout e. style

5. API RP 17N in the ISO

a. standard vs. recommended practice

i. Wording ii. Definitions

iii. Focus and degree of alignment b. Timing of API and ISO production

6. Report to Houston 14.00

7. Action Plan

8. Future Developments

radforda

Text Box

Attachment N1

Minutes of meeting – API 17N Present: John Allen (JA) Knut-Edmund Haugen (KH) David Rainford (DJR) John Strutt (JES) Karl Woods (KBW)

Minutes Ref. Discussion item Action /Comment By KH ISO Standard cf. API RP Definition

of normative (mandatory) and informative clauses

The only normative clause in ISO 20 815 is that the project “shall have a plan”

JA Conversion of API to ISO API 17N will not be an annex to ISO 20815. But it could become an ISO. If so API 17N needs to be registered as an ISO candidate

JA

If API does become ISO then we need to decide whether to adopt plan preparation as normative.

To be discussed with subsea ISO committee

JA

JES Liaison between ISO and API All subsequent API drafts to be copied to KH and Henrik Kortner

KBW

KH ISO Schedule: KH Provided time schedule for ISO document: ‘Committee Draft’ req. by 15 March to go to OGP for review. Review over 15 April. Minor revisions can be made (Draft standard) and sent out 1 May (absolute deadline). DIS out in 1 July.

PAP ISO early draft is expected to be completed by15th March. Boreas goal is to create a completed API draft by mid March

Boreas

KH Review ISO and API: Review of ISO 20 815 PAP performed

Purpose of meeting is to compare ISO PAP and API 17N with goal of harmonisation

KH to Send out MOM and latest version of ISO 20815 to BOREAS

KH

Most of the process and phase titles are consistent between PAP ISO (general) and API. The latter being more specifically subsea

JES Risk categorisation table ISO needs an update on project risk categorisation if it has altered in API JES – raised issues of safety critical hardware in relation to risk categorisation.

JES to look at /review risk categorisation in light of recent work

JES

JES KH

Processes and project phases: Table 4.3.2 is the ISO table showing which processes occur during the phases of the project life cycle.

There is no reason why these shouldn’t be the same between ISO and API. Work towards agreed set of processes and phases. There are no obvious conflicts.

ALL

Make sure that the life-cycle is the same unless there is a good reason for it being different

All

KH References to API in ISO. There was some uncertainty regarding decision to exclude reference to API

Check decision made regarding the PAP referencing to the API doc

KH

JES Outline progress on API Section on How to use this RP incomplete still evolving

JES

Waiting input from DJR on qualification of new technology

DJR

New Technology section in API KH recommended keeping it short and referring to other documents.

We still need to clearly define the new tech development projects and processes.

DJR

Work with KH to agree life-cycle stages, risk categorisation and KPs

KH/JES

Notes • Lose anything that is the least bit controversial • ISO ‘Plan’

o Preparation of a Plan is normative o Contents of plan is informative

• ISO need to introduce a planning process which is not currently included in ISO (but is in API)

• Aim to use 17N as an informative ref for PAP ISO (20815) if at all possible o OK in practice but 17N would need to be in existence i.e. formally issued

prior to ISO release (1st July is the deadline for this) o If this doesn’t happen then ISO could reference body such as API o When/if API 17N becomes ISO then ISO20815 could then refer to

ISO17N equivalent o They are essentially stand alone documents that may reference each other. o Try to get API out formally by the 1 May – action on JA to check

possibility of this. • DJR Comments re: documents to be sent via KBW at Boreas

[email protected] • The only normative reference currently in PAP is the data collection standard ISO

14224 • PAP reliability definitions are in line with ISO standards

o API definitions will be aligned with PAP as far as possible but there may be need for some specific non ISO references (Note: although there was a preference for some of the NORSOK

reliability definitions, KH has gone with ISO definitions for ease of acceptance.)

• We need to make sure the when people read the API they are ‘doing the right thing’

o Make sure they are all delivering value and understand that this isn’t replacing quality management but integrates with QM

• ISO PAP – The key process reliability improvement and risk reduction is really describing the practical design and manufacturing actions that should be implemented

• The main points of reference in PAP that have links to API 17N are o risk categorisation table o Key processes table o Project phases o Reliability process model (nuclear vs. structural see ISO circular diagram)

• The main items that need to be aligned, therefore, are: o Risk categorisation table o Key processes o Life cycle phases

• API o Consider removing the section on general principles if it isn’t subsea

specific. If it remains, it must be made clear that it is subsea relevant. o We need to define the technology qualification process. Main problem is

that it is subject sensitive. Hence: o Can only discuss the process and principles – but we don’t yet have a

process. o PAP discusses this in terms of KP6 (but it is limited)

Phases • ISO PAP doesn’t have a FEED phase but it does have a procurement phase • KBW noted that ISO 15663 on LCC does refer to FEED. This may be one of the

justifications for retaining a FEED phase. The other is simply the practice of the subsea industry to use the term FEED phase.

• ISO has taken a different approach namely to define phases as pre-contract and post contract.

• The phase that ISO refers to as concept design has been broken down to Concept design and FEED in the API.

• API should Lose the word appraisal from feasibility and appraisal so that it aligns with ISO

• Drop the term ‘selection’ from API conceptual design and selection phase • API detailed design phase is referred to as engineering phase in ISO PAP.

However, API has good reason for keeping detailed design as it is a well used terminology in the subsea industry.

• PAP ISO has a phase called “procurement” to focus on supply chain management after the engineering phase. API has dropped it as a specific phase as it occurs during detailed design phase. API will however, include “procurement” as part of the supply chain management process

• In the API document we refer to the phase Manufacturing and Assembly. In ISO their equivalent phase is Fabrication, Construction and Testing. It was proposed that API should add the term testing back in to call the phase Manufacturing Assembly and Test. Alternatively ISO could change. The issue of whether to treat Testing as a phase or a process remains to be resolved. However we note that there are different aspects of testing which are implemented at different stages of the phases.

• The PAP ISO has installation and commissioning, API has them as separate stages. It was decided that API would combine installation and commissioning to align.

• Operations OK. Key processes

• ISO was created using an old version of the key processes • API and ISO should aim to have the same top level processes and break out into

more detail where specifically necessary to the subsea industry. • API will Integrate organizing with planning • ISO PAP will include a similar planning phase. • API to create a diagram that will look like Knut’s diagram (nuclear) once the KPs

have been defined and add in the quality paradigm “define-plan-do-check-learn”. • API to redefine “reliability requirements” process to include categorisation, value

analysis and LCC • ISO to switch planning and reliability requ7irements to agree with API (i.e. define

req. and then plan) • API – need to add back management of change (left out by oversight error). • API and ISO resolved to use 12 key processes.

Mark Siegmund telecom

• Summarised comments on API inclusion of FEED • ISO to state that concept design could include FEED • KH – this is OK as we already do this for ‘engineering’ phase. • Contact API regarding the 3 March meeting.

Action plan • Boreas to send out rev 4 by Thursday 2nd of March • KW to send DJR detailed design, TQP and annex 2 sub-documents along with pdf

of entire document. • KH to send ISO doc and last mins to Boreas • Boreas to create reconciliation and alignment doc to send to KH (issue

tomorrow). This will cover o Risk categorisation o KPs o Life cycle

To be aligned by the end of this week.

• Re-work DPDCL model and send out to KH • Remind DJR to send data collection annex (BOREAS)

REFS PAP – Production assurance program ISO (20815) based on Z016 DIS – Draft International Standard

Introduction to API RP 17N

Recommended Practice for the Achievement of Subsea Production

System Reliability

API Recommended Practice 17NPresentation to Joint API/ISO meeting

AtlantaJune 14th

John Allen

radforda

Text Box

Attachment N2

DeepStar / APIAPI RP 17N

Steering Committee

John Allen - Vetco ChairmanMark Siegmund - BP Co-chairDon Wells - ConocoPhillipsEric Waguespack – ChevronLuis Bensimon - KMGCharles Burton - ChevronJean Pierre Signoret - TFEJames Papas – DevonNilo Jorje - Petrobras

Prof. John Strutt – CoordinatorDavid Rainford - Secretary

DeepStar / API RP 17N Committee Participation

• DeepStar

• API

• MMS

• Petroleum Companies

• Manufacturers

• Consultant Companies

Contacts

• Professor John Strutt (Cranfield University) to act as Document Consultant and champion for Reliability, and Interface Management

• David Rainford (BMT Energy) to act as Coordinating Editor and Secretary

• Professor John Strutt is now with Boreas and is now leading this activity (David Rainford has moved to another industry)

Challenges

Where are the interfaces? Subsea, down-hole, topsides, drilling, work-over (API 17A)Implementation Blockers for the upstream oil & gas industry (multiple buyers buying with differing drivers)Demonstrate economic value to the industryUniversal process – all customers, all projects – large, small, complex, simpleDifferent independent initiativesCommon approach be agreed by industry?Alignment to be obtained with proposed ISO Standards

How does Subsea differ?

• Evolving products – deeper, HPHT, seabed

• Low volume high cost of products

• Project based “no standardization”

• Uncertain Operating Environment

• Intervention costs are high

• Regional differences

• High Level of Growth

Objective

• Provide a framework to support Operators, Contractors, and Suppliers • Allow the development and implementation

of a reliability strategy and plan that meets all the stakeholders’ requirements throughout the full life-cycle.

• Culture Change

• Take it to the next level

API RP 17N Organization

API RP 17NSteering Committee

SubCommittee A

SubCommittee B

SubCommittee F

MarketingGroup

SubCommittee D

SubCommittee C

SubCommittee E

SubCommittee G

Reliability&

Interface Mgt

Feasibility&

Concept Mgt

Front End Engineering

Design

Operations

Detail Design Procurement&

Supply Chain

Manufacturing

SIT

Installation

Hook Up&

Commissioning

DeepstarData Collection

Sub Committee A


SubCommittee A

Reliability&

Interface Mgt

MarketingGroup

John Strutt - CU David Rainford – BMT

Rajiv Aggarwal - KBRJohn Allen - VGLuis Bensimon - KMGJim Hale – ShellEinar Molnes - ExproGraham Openshaw - BPHeather Powers - CVXMark Siegmund - BPEric Waguespack - CVX

Sub Committee B


SubCommittee B

Feasibility&

Concept Mgt

Front End Engineering

Design

Operations

MarketingGroup

Graham Openshaw - BP Havard Brandt - DnV

Charlie Burton - UnocalWilson Crichton – IntecTom Choate - IntecRobert Decker – KBRJonathan Deegan - BHPDavid Eggers - CVXJay Harms – BPAlan Hein - CVXChristian Markussen - DnVEinar Molnes - ExproRoger Osborne - DeepseaKen Powell – CameronCharlie Reith – JPK (Aberdeen)Gaurav Sharma - GranherneBarry Snider - IRCGeir-Ove Strand – ExproJohn Upchurch - Technip

Sub Committee C


SubCommittee C

DetailedDesign

MarketingGroup

Frank Wabnitz – FMCI Ed Szymczak - VG

Morris Baldridge - HalliburtonRay Flemming - BPT. Alan Johnson - ParagonTom McCardle - BPBarry Snider - IRC

David Rainford - BMT

Sub Committee D


SubCommittee D

Supply Chain

MarketingGroup

Jim Hosford – CVXJusto Marin – CVX

Sub Committee E


SubCommittee E

Manufacturing&

SIT

MarketingGroup

James Pappas -DevonBill Blizzard – Stress

Miles Becnel – CVXJennifer Bell – CVXPat Broussard – Vetco Gray Charlie Burton – UNOCALJames Campbell – Dril-quipDewey Compton – AKLee Danner – Vetco GrayFrancisco Dezen - CVX Christopher Hey - CVXChristopher Lindsey-Curran – BPTom McCardle - TechnipJohn McManus - GibsonBob Milner – Nat. CouplingUma Mundle – CVXJan Mundorf – OceaneeringKen Powell – CameronRolf Wium – RoxarRoyce Zeigler

Sub Committee F


SubCommittee F

Installation

Hook Up&

Commissioning

MarketingGroup

Neal Prescott - Fluor Vacancy from below?

Wade Abadie – SonsubBob Chin - CDSTim Dean - KMGDarrel Evans - StoltJohn A. Fitzgerald – EEJoseph John - AntaresT. Alan Johnson - ParagonSandor Karpathy - StressSid Mebarkia - CVXDuncan Scott - SS7Dennis Seek – PegasusBarbara Thompson – StoltGordon Wilkinson - McDermottSteve Williams - EM

Sub Committee G – Deepstar Data


SubCommittee G

Deepstar

MarketingGroup

Eric Waguespack - CVXChristopher Lindsey-Curran - BP

John Allen - VGLuis Bensimon - KMGMike Conner - MMSFred Hefren - MMSSreesh Kalvakaalva – TechnipRick Mercier - OTRCMark Siegmund - BPJean-Pierre Signoret - TotalFrank Wabnitz - FMCDon Wells - COPSteve Williams - EM

Ray Ayers - StressHavard Brandt - DnVDavid Rainford - BMT

Coordination Committee


Representatives

MarketingGroup

A: & Advisor: John Strutt - CU A: & Editor: David Rainford – BMT

B: Graham Openshaw - BP B: Havard Brandt – DnV

C: Frank Wabnitz – FMCC: Ed Szymczak – VG

D: Jim Hosford - CVXD: Justo Marin - CVX

E: James Pappas -DevonE: Bill Blizzard – Stress

F: Neal Prescott – FluorF: Vacancy

G: Eric Waguespack - CVXG: Christopher Lindsey-Curran - BP

ISO

• ISO 14224 data and 20815 general (reliability management and technology) committees change convener to HenrikKortner DnV December 04

• JA/Mark Siegmund/David Rainford attended ISO meeting Houston November 05. •Joseph Thorp the host of this meeting suggested that the ISO should have registered this ‘standard’ ISO NWI, to avoid delays due to the phase lag between ISO and API.

•Discussed at joint API/ISO meeting in Galveston. API 17N to be presented as a draft at the next meeting and then ISO will initiate proceedings.

• Joint API/ISO allignment meeting London Feb 06 with Knut Haugen representing Henrik Kortner.

Current and future

• Assembled & Edited by John Strut and David Rainford by May 06.

• Chapter material checked by steering committee and sub committees May 06

• Sent out to subcommittee members by first week June

• Hand to API at 14th. June joint API/ISO meeting in Atlanta to consider for adoption and to canvassed ‘formal’ industry comment (publish) 13th June 06.

Current and future

• Applied for additional funds from API to manage follow up workshop (also possible DeepStar support) and include comments/re edit document.

• Present structure of API 17N and how to use• Workshop work examples• Re structure API from feedback/workshop.• Produce executive summary user guide

• Re issue API 17N for global comment

Copyright ©

RECOMMENDED PRACTICE

SUBSEA PRODUCTION SYSTEM

RELIABILITY & TECHNICAL RISK MANAGEMENT

API RECOMMENDED PRACTICE 17N

FOURTH DRAFT

12TH JUNE 2006

radforda

Text Box

Attachment N3

Copyright ©

API 17N API

API RP 17N Master 2/104

RECORD OF AMENDMENTS

ISSUE DATE CHANGE APPROVED

DRAFT A 13TH JANUARY 2004

ORIGINAL DRAFT OF CONTENTS JOHN ALLEN

DRAFT B 23RD FEBRUARY 2004

REVISED POST JOINT API 17 / ISO MEETING FEB 18TH 2004

JOHN ALLEN

DRAFT 1 19TH DECEMBER 2004

FIRST ISSUE IN INTENDED FORMAT WITH SUBCOMMITTEE INPUT

PRELIMINARY LIMITED CIRCULATION

DRAFT 2A

18TH JANUARY 2005

DRAFT A OF ISSUE 1 FOR SUBCOMMITTEE A DEVELOPMENT AND COMMENT

NA

DRAFT 2A

8TH FEBRUARY 2005

DRAFT A OF ISSUE 2 GROUP CONTENT ADDED GUIDANCE NOTES IN BLUE

NA

DRAFT 2B

6TH MARCH 2005

ISSUED TO SUBCOMMITTEE A FOR REVIEW INCLUDES DATA COLLECTION SECT 14

NA

DRAFT 2 18TH MARCH 2005

ISSUED TO ALL SUBCOMMITTEE PARTICIPANTS TO ASSIST DEVELOPMENT OF THEIR SECTIONS

JOHN ALLEN

DRAFT 3 25TH APRIL 2006

ISSUED TO SUBCOMMITTEE A FOR REVIEW

DRAFT 4 12TH JUNE 2006

ISSUED FOR OFFICIAL DRAFT ADOPTION

Copyright ©

API 17N API


CONTENTS 1 Background ........................................................................................................................................ 7

1.1 Purpose of this Recommended Practice.................................................................................. 7 1.1.1 Scope.................................................................................................................................. 7 1.1.2 Hardware............................................................................................................................ 8 1.1.3 System Interfaces............................................................................................................... 8 1.1.4 New Technology Products ................................................................................................. 8 1.1.5 Subsea Intervention............................................................................................................ 8 1.1.6 Exclusions.......................................................................................................................... 9

2 Terms Definitions and Abbreviations............................................................................................... 10 2.1 Industry Terms and Definitions ............................................................................................ 10

2.1.1 Informative References.................................................................................................... 13 3 General Principles of Reliability and Technical Risk Management ................................................. 16

3.1.1 Strategy goals................................................................................................................... 16 3.1.2 Technical Risk Management............................................................................................ 16 3.1.3 Organization Capability: Key Risk and Reliability Practices .......................................... 18

3.1.3.1 R&M Core Processes and key reliability objectives ................................................... 18 4 How to use this Recommended Practice........................................................................................... 20

4.1 Referencing System.............................................................................................................. 20 4.1.1 Key charts, tables and matrices........................................................................................ 21

4.2 Quick start application of API RP 17N to subsea projects ................................................... 24 4.2.1.1 Scope/Task review ...................................................................................................... 25

5 Qualification of New Technology in Projects .................................................................................. 27 5.1 Objective............................................................................................................................... 27 5.2 Philosophy ............................................................................................................................ 27

5.2.1 Principles of Qualification ............................................................................................... 28 5.2.2 Stress................................................................................................................................ 29 5.2.3 Margin against Failure ..................................................................................................... 29 5.2.4 Reliability Index .............................................................................................................. 29

5.3 Qualification process ............................................................................................................ 31 5.3.1 Basis of Qualification and Initial Plan ............................................................................. 32 5.3.2 System Analysis............................................................................................................... 32 5.3.3 Technology Qualification Specification .......................................................................... 33 5.3.4 Initial Qualification status and TRL................................................................................. 34 5.3.5 Technical Risk analysis.................................................................................................... 35 5.3.6 Required Qualification Status and TRL........................................................................... 36 5.3.7 Items to be qualified ........................................................................................................ 36 5.3.8 Update Technology Qualification Plan............................................................................ 36 5.3.9 Identification and Implementation of Qualification Test ................................................. 37 5.3.10 Achievement of Reliability, Reliability Improvement and Risk reduction ...................... 37 5.3.11 Qualification Reporting ................................................................................................... 37

5.4 Purpose of Testing ................................................................................................................ 38 5.4.1 Purpose of Testing ........................................................................................................... 38 5.4.2 Testing to demonstrate functional performance............................................................... 38

5.4.2.1 Test Conditions ........................................................................................................... 38 5.4.2.2 Test Items.................................................................................................................... 39

5.4.3 Testing to Improve Robustness and Reliability ............................................................... 39 5.4.4 HALT - Highly Accelerated Life Testing........................................................................ 40 5.4.5 Stress Screening in Manufacture and Assembly .............................................................. 40 5.4.6 FAT and SIT .................................................................................................................... 41 5.4.7 Data.................................................................................................................................. 41 5.4.8 Conclusion ....................................................................................................................... 41

6 Implementation of R&M in Field Development Projects................................................................. 42 6.1 Introduction .......................................................................................................................... 42

6.1.1 Generic Reliability Process Flow Chart........................................................................... 42

Copyright ©

API 17N API


6.2 Feasibility ............................................................................................................................. 43 6.2.1 Phase Scope ..................................................................................................................... 43 6.2.2 Description of R&M processes in Feasibility .................................................................. 43 6.2.3 Feasibility R&M Task Description .................................................................................. 44

6.2.3.1 R&M assurance, verification and validation ............................................................... 45 6.3 Concept Design..................................................................................................................... 46

6.3.1 Phase Scope ..................................................................................................................... 46 6.3.2 Description of R&M processes in Concept Design ......................................................... 46 6.3.3 Concept Design R&M Task Descriptions........................................................................ 47

6.3.3.1 R&M assurance, verification and validation ............................................................... 48 6.4 Front end engineering design................................................................................................ 49

6.4.1 Phase Scope ..................................................................................................................... 49 6.4.2 Description of R&M activities in FEED.......................................................................... 49 6.4.3 FEED R&M Task Descriptions ....................................................................................... 50

6.4.3.1 R&M assurance, verification and validation ............................................................... 52 6.5 Detailed Design .................................................................................................................... 53

6.5.1 Phase Scope ..................................................................................................................... 53 6.5.2 Description of R&M activities in Detailed Design .......................................................... 55 6.5.3 Detailed Design R&M Task Descriptions........................................................................ 56

6.5.3.1 R&M assurance, verification and validation ............................................................... 58 6.6 Design for Manufacture And Manufacturing ....................................................................... 59

6.6.1 Phase Scope ..................................................................................................................... 59 6.6.2 Description of R&M activities in Design for Manufacture and Manufacturing .............. 60 6.6.3 Design for Manufacture and Manufacturing R&M Task Descriptions............................ 61

6.6.3.1 R&M assurance, verification and validation ............................................................... 62 6.7 SIT, Installation and Commissioning ................................................................................... 63

6.7.1 Phase Scope ..................................................................................................................... 63 6.7.2 Description of R&M processes in SIT, Installation and Commissioning ........................ 63 6.7.3 SIT, Installation and Commissioning R&M Task Descriptions....................................... 67

6.7.3.1 R&M assurance, verification and validation ............................................................... 69 6.8 Operations............................................................................................................................. 70

6.8.1 Phase Scope ..................................................................................................................... 70 6.8.2 Description of activities in Operations............................................................................. 70 6.8.3 Operations R&M Task Descriptions................................................................................ 71

6.8.3.1 R&M Assurance Verification and Validation ............................................................. 73 7 Annex 1: Process Description........................................................................................................... 74

7.1 Process 1: Definition of R&M Requirements....................................................................... 74 7.1.1 Description....................................................................................................................... 74

7.1.1.1 Feasibility.................................................................................................................... 75 7.1.1.2 Concept Design ........................................................................................................... 75 7.1.1.3 FEED........................................................................................................................... 76

7.1.2 Risk Categorization.......................................................................................................... 77 7.1.3 R&M Value Analysis....................................................................................................... 81 7.1.4 Setting R&M Requirements............................................................................................. 82

7.2 Process 2: Organizing and Planning for R&M ..................................................................... 83 7.2.1 Description....................................................................................................................... 83

7.2.1.1 Planning for R&M ...................................................................................................... 83 7.2.1.2 Organizing for R&M................................................................................................... 85

7.3 Process 3: Design and Manufacture for R&M...................................................................... 87 7.3.1 Description....................................................................................................................... 87

7.3.1.1 Design for R&M ......................................................................................................... 87 7.3.1.2 Manufacture for R&M ................................................................................................ 88

7.4 Process 4: Reliability Assurance........................................................................................... 89 7.4.1 Description....................................................................................................................... 89

7.5 Process 5: Verification and Validation ................................................................................. 90 7.6 Process 6: Project Risk Management.................................................................................... 91

Copyright ©

API 17N API


7.6.1 Description....................................................................................................................... 91 7.6.1.1 Formal Project Risk Analysis...................................................................................... 91 7.6.1.2 Risk review ................................................................................................................. 91

7.7 Process 7: R&M Qualification.............................................................................................. 93 7.7.1 Description....................................................................................................................... 93

7.8 Process 8: Data Management................................................................................................ 95 7.8.1 Description....................................................................................................................... 95 7.8.2 Data Input to Reliability Analysis.................................................................................... 95 7.8.3 Data Collection ................................................................................................................ 95

7.9 Process 9: Supply Chain Management ................................................................................. 97 7.9.1 Description....................................................................................................................... 97 7.9.2 Supplier Capability .......................................................................................................... 97 7.9.3 Contract Strategy ............................................................................................................. 97

7.10 Process 10: Management of Change..................................................................................... 98 7.10.1 Description....................................................................................................................... 98

7.11 Process 11: Risk and R&M Analysis and Modeling............................................................. 99 7.11.1 Description....................................................................................................................... 99

7.12 Process 12: Organizational Learning.................................................................................. 100 7.12.1 Description..................................................................................................................... 100

8 Annex 2: Reliability Data ............................................................................................................... 101 8.1 Objectives ........................................................................................................................... 101

8.1.1 Definition of Success ..................................................................................................... 101 8.2 Assumptions ....................................................................................................................... 101 8.3 Overview ............................................................................................................................ 101 8.4 Scope .................................................................................................................................. 102 8.5 Strategy............................................................................................................................... 102 8.6 Reliability Data Types ........................................................................................................ 103

8.6.1 Equipment suppliers/vendors......................................................................................... 103 8.6.2 Operators........................................................................................................................ 103

8.7 Measurement of Success..................................................................................................... 103 8.7.1 Normal signature............................................................................................................ 103 8.7.2 Removed equipment inspection ..................................................................................... 103 8.7.3 Equipment Log-Book..................................................................................................... 103

Copyright ©

API 17N API


Copyright ©

API 17N API


1 Background This recommended practice provides general guidance and recommendations for the assessment and management of reliability and technical risk for complete subsea production systems throughout the product life cycle from Feasibility to end of field life. The approach is based on experience from other industries that good reliability management practices will lead to improved in service reliability performance and recognizes that project phases, physical attributes (system, sub-system and component, environment) and organizational boundaries must be addressed and any conflicts reconciled. The document is designed to assist the subsea community in managing and achieving optimum system reliability performance, addressing; economic, social and environmental risk criteria. While the need to address reliability is important for all subsea installations it is particularly relevant to subsea challenges of deeper water and harsher environment which has its own specific issues such as the need for:-

• High levels of system availability • Defined failure free operating periods within acceptable probability of achievement • Limited underwater intervention/Maintenance work • Design of Fault tolerant systems

The key goal of this recommended practice is to provide guidance on appropriate management processes and practices which will enable project teams to achieve and enhance system reliability, availability and uptime and minimize technical risk. While accepting that reliability analysis is an important input to reliability decision making it is only one of a number of activities which are critical to reliability achievement. An important focus of this document, then, is its emphasis on management processes and good practices needed for reliability achievement. A further key aspect introduced in this recommended practice is its focus on technical risk and its relationship to reliability and maintainability. For example, reliability requirements should be defined to limit risk exposure to within acceptable levels. Likewise, the provision of resources for reliability effort during the design process should be linked to the level of risk reduction that is necessary to meet the business requirements of the end customer. Subsea applications generally cover installations of all sizes and complexity, from standard solutions in repeat, low risk applications, to complex solutions in high risk applications. To this end, guidance is provided on the level of management effort needed to ensure achievement of acceptable levels of reliability performance consistent with the level of technical risk in the subsea solutions considered.

1.1 PURPOSE OF THIS RECOMMENDED PRACTICE The purpose of this document is to provide a framework which will support Operators, Contractors and Suppliers in the development and implementation of a reliability strategy and the preparation of reliability plans which meets stakeholders’ requirements for reliability and technical risk management throughout the whole lifecycle.

1.1.1 Scope This recommended practice provides guidance on relevant engineering reliability and technical risk management activities that may be performed during subsea projects. Guidance is given on specific reliability tasks that can be carried out at the different stages in the life cycle of a project from initial appraisal through to field operation. Detailed guidance on specific tasks is provided in the annexes to this document. However, these do not go as far as describing procedures for specific analytical tasks and tools as many of these are adequately covered in existing reliability standards.

Copyright ©

API 17N API


1.1.2 Hardware Subsea equipment and hardware to which this recommended practice is applicable are described in API 17A and represent the physical boundaries of API RP 17N. It covers; wellheads, both subsea and mud-line, casing suspension systems and trees, flow-lines, umbilici and end connections, control systems, control lines, single-well structures, templates and manifolds as shown in Figure 1.

Figure 1: Typical elements in a subsea production system (API 17N & ISO13626-1:2005)

1.1.3 System Interfaces System failure modes are frequently associated with the interfaces between systems, sub-systems and components. Reliability and technical risk management should therefore also address the risks posed by hardware interfaces, particularly when these interfaces also represent boundaries between different organizations in the supply chain or teams within the project management organization.

1.1.4 New Technology Products Evolving equipments and new technology, such as subsea processing, electrically actuated trees and other new-technology products should be given particular attention in the reliability program. The section dealing with Technology Development Projects provides some guidance on methods of management for application of novel technology in field development project but a complete description of reliability and technical risk management processes for new technology development projects is outside the scope of this recommended practice.

1.1.5 Subsea Intervention While subsea system definitions are based directly on those defined in API 17A, work-over and intervention tools should also be included in the subsea system assessment where these have a direct bearing on subsea system maintainability and availability.

Copyright ©

API 17N API


1.1.6 Exclusions The following systems are not included in API 17A but have external interfaces/boundaries with those subsea systems which must be managed. These systems will also normally be included within the scope of reliability activities:

• Down-hole and completion components • Reservoir management and drilling activities • Topside interfaces

Copyright ©

API 17N API


2 Terms Definitions and Abbreviations

2.1 INDUSTRY TERMS AND DEFINITIONS The terms and definitions used in this recommended practice have been taken from or are based on a number of existing standards, including; Norsok Z016, IEC300-3-4, API 17, ISO 20815. Availability Availability is the ability of an item to be in a state to perform a required function under given conditions of production, environment and usage, at a given instant of time or during a given time interval, assuming that the required external resources are provided. Common Cause Failure A common cause failure is a simultaneous (or near simultaneous) failure of different items in a system from the same direct (common) cause where those failures are not the immediate consequences of another in the system. Common cause failures are often caused by common environments, common load sources, common design and manufacture features or common energetic events such as fires and explosions etc. Customer A customer is the recipient of a product or service provided by a supplier. Down time Down time is the time interval during which an item is the down-state characterized either by a fault, or by its inability to perform a required function due to other activities e.g. during maintenance. Equipment data Technical, operational, and environmental parameters characterizing the design and use of equipment. Extended Operating Conditions Extended operating conditions are conditions with under which there has been no or very limited previous experience Failure Failure is the termination of the ability of an item to perform a required function. After failure the item has a fault. Failure is an event and is distinguished from a fault which is a state Failure cause Circumstances associated with design, manufacture, installation, use and maintenance, which have caused a failure. Failure Data Data characterizing the occurrence of a failure event. Failure impact (effect) Impact of a failure on the system, on an equipment function, or on the environment. Failure Mechanism A failure mechanism is defined as the physical, chemical, human or other processes which lead to a failure. Most failure mechanisms involve more than one process and occur as a chain of events and processes. Failure Mode A failure mode is the effect by which a failure is observed on the failed item. Failure modes are often used to describe the nature of a failure.

Copyright ©

API 17N API


FMECA FMECA is the acronym for Failure Modes and Effects Criticality Analysis. FMECA is a qualitative analytical procedure for the identification system or component failure modes and their consequences. Fault A fault is the state of an item characterized by its inability to perform a required function. This excludes the deliberate disabling of the item to accommodate planned activities, such as preventive maintenance, or due to lack of external resources. A fault is often the result of a failure of the item itself. However, it might exist without a failure event. FTA FTA is the acronym for Fault Tree Analysis. FTA is a top down analytical procedure for identifying causes of an identified system fault or failures. FTA can be used to identify as system cut sets. HALT HALT is the acronym for Highly Accelerated Life Testing. HALT is a testing method in which hardware products are subjected to increasing individual and combined stresses to identify the stress limits of the product, to identify and understand potential failure mode and, when combined with reliability improvement processes, to increase the robustness of the product. Installation hardware Installation hardware is the system or equipment used to install subsea production hardware on the seabed. Item Any part, component, device, subsystem, functional unit, equipment or system that can be individually considered. Maintainability Maintainability is the ability of an item, under given conditions of operation, environment and usage, to be retained in or restored to a state in which it can perform a required function when maintenance is performed under given conditions and using stated procedures and resources. Maintainability is also used as a measure of maintenance performance. Maintainable item Item, component or assembly of components that is normally the lowest level in the equipment hierarchy during maintenance. Maintenance Maintenance is the process by which equipment is maintained in the working state or is transformed back to the working state from a fault state. Maintenance Data Data characterizing a maintenance action. Maintenance record Set of data which contains all failure, fault, and maintenance information relating to an item. This record may also include maintenance costs, item availability or uptime and any other relevant data Maintenance Man hours Accumulated duration of the individual maintenance times, expressed in hours used by all maintenance personnel for a given type of maintenance action or over a given time interval. MFFOP

Copyright ©

API 17N API


MFFOP is the acronym for Minimum Failure Free Operating Period. MFFOP is the minimum time that a system can operate without the occurrence of a specified failure and where the failure occurrence is to a given level of probability. The term MFFOP is sometimes used refer to minimum maintenance free operating period which is the minimum time that a system can operate without the need for maintenance intervention and where that failure/fault occurrence requiring an intervention is to a given level of probability. Operating Time Time in which an item in performing an intended function or is in service and available to perform an intended function. Organization A Company, Corporation, Firm, Enterprise, Institution or part thereof, whether incorporated or not, public or private, that has its own functions and administration (ISO 8402). Production availability Production availability is the ratio of actual production to planned production, or any other stated reference level, over a period of time. This measure is used in connection with analysis of delimited systems without compensating elements such as substitution from other production systems or down stream storage buffers. Battery limits for example may need to be defined in each case. Qualification Qualification is the process of confirming, by examination and provision of evidence, that new technology meets specified requirements for the intended use. A qualified product should possess an acceptable level of technology readiness. Qualification testing A testing procedure designed to check that a product meets the customer’s specification. RAM analysis RAM analysis is a numerical analysis to assess system availability. Redundancy Existence of more than one means to perform a required function (often by duplicating items). Reliability Reliability is ability of an item to perform a required function, under given conditions of production, environment and usage for a required time interval. When reliability is quantified, the term “ability” is usually interpreted as a probability. Required (intended) function Function or combination of functions, of an item which is considered necessary to provide a given service. RAM RAM is the acronym for reliability, availability and maintainability. R&M R&M means Reliability and Maintainability. In this recommended practice the term R&M is used as short hand to mean all the terms: reliability, maintainability, availability. R&M Requirements R&M requirements are the required minimum level of R&M capability of a system. It should include definitions of failure and requirements for reliability, maintainability, availability and supportability. Package

Copyright ©

API 17N API


A package is a named system, subsystem or defined set of components considered as a single entity for the purpose of a design study. Subsea Production hardware Subsea production hardware is the set of equipment and packages comprising the subsea system which will be installed and operated underwater. System The term system is used to include mechanical, electrical, electronic, hydraulic and other physical entities and includes all the control mechanisms associated with their operation such as firmware and software. System Availability Availability is generally expressed as the proportion of time that the system is in the functioning state. Availability depends on a combination of reliability, maintainability and maintenance supportability considerations. Required external resources other than maintenance resources for that function do not affect availability. Specification (customer) The document in which functional and performance and operating requirements are defined together with request for compliance. Specification (supplier) The document in which functional, performance and operating characteristics and limits of the product are stated. Uncertainty Lack of knowledge about a variable, quantity or parameter, often expressed as a probability. Uncertainty can apply to models used for prediction, to parameters of models and to data. Upstate State of an item in which it can perform a required function, assuming that the external resources are available as required. Uptime Uptime is the time interval during which an item is in the upstate characterized by its ability to perform its required functions, assuming that the external resources, if required, are provided. Validation Validation is the process which substantiates whether a physical entity, a model or data within their domain of applicability, possesses a satisfactory range of accuracy consistent with the intended application of the model. Validation addresses the question “Are we building the right product?” it is particularly relevant to models and the data used for assessing reliability. It can also be addressed to a physical entity in a subsea system when it is often referred to as design validation. Verification Verification is the process which determines the extent to which a procedure, task, physical product or model conforms to its specification (regardless of whether the specification is right or wrong). Verification addresses the question: “Are we building the product right?” Reliability model verification is defined as ensuring that the computer program of the computerized model and its implementation are correct.

2.1.1 Informative References API 17A Recommended Practice 17A, Design and Operation of Subsea

Production Systems API Specification Q1 Specification for Quality Programs for the Petroleum and Natural Gas

Formatted Table

Copyright ©

API 17N API


Industry API Specification 17D Specification for Subsea wellhead and Christmas tree equipment DEF STAN 0042 Part 3 Reliability and Maintainability (R&M) Assurance Guidance Part 3

R&M Case Ford Q1 2002 IEC 1070: 1991 Compliance test procedures for steady state availability IEC 1123: 1991 Reliability testing – Compliance test plans for success ratio IEC 300-1: 1993 Dependability Management – part 1: Dependability program

management IEC 300-2:1995 Dependability Management – part 2 Dependability program elements

and tasks IEC 300-3-1:1991 Dependability Management – part 3 Application guide – section 1:

Analysis techniques for dependability: Guide on methodology IEC 300-3-2:1993 Dependability Management – part 3 Application guide – section 2:

Collection of dependability data from the field IEC 319: 1978 Presentation of reliability data on electronic components (or parts) IEC 409: 1981 Guide for the inclusion of reliability clauses into specifications for

components (or parts) for electronic equipment IEC 50(191): 1990 International Electro-technical Vocabulary (IEV), chapter 191:

Dependability and quality of service IEC 605-1: 1978 Equipment reliability testing – part 1: General requirements IEC 605-6: 1986 Equipment reliability testing – part 6: Tests for the validity of a constant

failure rate assumption IEC 61508 Functional Safety of Electrical / Electronic / Programmable Electronic

Safety-related Systems IEC 61511 Functional Safety: Safety Instrumented Systems for the process industry

sector IEC 706-1: 1982 Guide on maintainability of equipment – part 1- sections one , two and

three: introduction requirements and maintainability program IEC 706-3: 1987 Guide on maintainability of equipment – part 3- sections six and seven

Verification and collection, analysis IEC 706-5: 1994 Guide on maintainability of equipment – part 5- section four:

Diagnostic testing IEC 706-6: 1994 Guide on maintainability of equipment – part 6- section nine: Statistical

methods in maintainability evaluation IEC 863: 1986 Presentation of reliability, maintainability and availability predictions IEC/FDIS 1124 Reliability testing – Compliance test plans for constant failure rate and

constant failure intensity ISO 13626 Petroleum and natural gas industries – Design and operation of subsea

production systems ISO 8402: 1994 Quality Management and Quality Assurance Vocabulary ISO 9000-4: 1993 Quality Management and Quality Assurance Standards – part 4 Guide

to Dependability Program Management ISO 9001-2002 Quality management systems. Requirements ISO14224 Petroleum and natural gas industries – Collection and exchange of

reliability and maintainability data for equipment. NORSOK Z016 Regularity management & reliability technology SAE JA 1000-1 Reliability Program Standard Implementation Guide ISO 15663-2 Petroleum and natural gas industries - Life-cycle costing - Part 2:

Guidance on application of methodology and calculation methods ISO 20815 Petroleum, petrochemical and natural gas industries – Production

assurance and reliability management BS 6079 series Project Management IEC 62198:2001 Project Risk Management – Application Guidelines

Copyright ©

API 17N API


BS 5760 Series Reliability of systems, equipment and components BS IEC 61882:2001 Hazard and operability studies (HAZOP studies). Application guide BS EN 61078:1994 Reliability of systems, equipment and components. Guide to the block

diagram technique Table 1: Informative references

Copyright ©

API 17N API


3 General Principles of Reliability and Technical Risk Management

3.1.1 Strategy goals

Figure 2 Reliability bathtub curve Many Operators are developing reliability strategies as a means of maximizing the value from field development projects. The goal of a reliability strategy can be illustrated using a bathtub curve, such as that shown in Figure 2, in which system breakdown rate is plotted against operational time. Three phases can often be identified, namely early life period, mid life period and wear out phase. The key reliability strategy goals are:

• Remove Expensive early life failures • Remove or minimize foreseeable through life failures • Ensure that equipment does not wear out before end of field life

Early life period: It is usually found that failures are more frequent in the early life of an operating system. While there are many technical reasons for such failures, their root cause can often be traced back to human errors made during design, manufacturing and assembly or Installation phases. Failures that occur in early life have the most significant impact on the economics of the field. Mid life period: After an initial period of a few years, the rate of occurrence of failures often levels out to a lower frequency. Failures which occur in this mid life period, while still undesirable, often have a smaller financial impact and so some failures in, for example, shallow water may be tolerated. For deep water subsea installations, however, the high cost of intervention may render even mid life failures as unacceptable. Wear out period: Eventually, almost all equipment will shows signs of wear and tear and an increasing incidence of failures. It is likely that at this stage it will become uneconomic to repair and maintain hardware and the system will require decommissioning. The point in time where this occurs is the design life of the system which often coincides with the life of the reservoir.

3.1.2 Technical Risk Management It is the primary goal of technical risk management to assess and manage technical risks to the installation, such that the value of the field is maximized. The key to maximizing value is the identification of failure modes and their consequences at the earliest possible stage in the design life cycle and taking appropriate actions to avoid the failure mode (if that is feasible), to reduce its probability of occurrence or to reduce the consequences of failure.

Bre

akdo

wn

rate

Early Life Failures Random Failures

Wear out Failures

Past

Strategy Goal

Remove expensive early life failures

Remove or minimise foreseeable through life failures & extend anticipated field life

Decommission before wear –out

Operational period

Bre

akdo

wn

rate

Early Life Failures Random Failures

Wear out Failures

Past

Strategy Goal

Remove expensive early life failures

Remove or minimise foreseeable through life failures & extend anticipated field life

Decommission before wear –out

Operational period

Copyright ©

API 17N API


The level of effort involved in risk management should be commensurate with the level of risk involved. Failures which occur frequently and have major cost impact should be given the highest priority. Failure modes are directly linked to design function and performance requirements. For every function there is at least one and usually several deviations from intent (failure to function). For example; tree valves must be able to contain pressurized fluids, close on command and open on command and act as a barrier to flow. Thus gate valve failure modes include; leakage to the environment, leakage in the closed position, failure to close on command and failure to open on command. The frequency of failure is dependent on the mechanism of failure. For each failure mode there may be a number of different underlying mechanisms. Most failure mechanisms are directly linked to errors such as design errors or manufacturing errors, or to defects or damage introduced during manufacturing and assembly, etc. Reliability improvements require action at the level of failure mechanism. When these failure modes are created and when they are discovered is highly significant. Figure 3 illustrates the principle.

Figure 3: Creation and discovery of failure modes

• Failure modes are created as a direct consequence of design and manufacture • Failure modes are found by reliability and risk management effort during design • Failure modes discovered late are costly to fix • Failure modes discovered when hardware is being built are more expensive to fix • Failure modes discovered in operation (i.e. realized failures) are the most expensive to fix.

One way of reducing R&M management costs and improving reliability is to put more effort into the early identification of failure modes and mechanisms. Some organizations refer to this as “front loading” the design effort (Figure 4).

Figure 4: Reduce time to discovery

• The key goal is to reduce the time between failure mode creation and failure mode discovery.

time

Failure Modes

Discovered

Failure Modes Created

Num

ber o

f fai

lure

s at

tim

e t

Cost of fixing failures and faults found

ConceptDesign

FEED DetailDesign

ManufactureConstruct

Install and Operate

Reduced Early and through life failures

time

Failure Modes

Discovered


Num

ber o

f fai

lure

s at

tim

e t


ConceptDesign

FEED DetailDesign


Install and Operate

Reduced Early and through life failures

time

Failure Modes

Discovered


Num

ber o

f fai

lure

s at

tim

e t


ConceptDesign

FEED DetailDesign


Install and Operate

Expensive Early life failures

Reduce thistime

time

Failure Modes

Discovered


Num

ber o

f fai

lure

s at

tim

e t


ConceptDesign

FEED DetailDesign


Install and Operate


Reduce thistime

time

Failure Modes

Discovered


Num

ber o

f fai

lure

s at

tim

e t


ConceptDesign

FEED DetailDesign


Install and Operate


Reduce thistime

Copyright ©

API 17N API


• The ideal is simultaneous creation and discovery but some failure modes and mechanisms may be more difficult to identify than others.

• Take action early to reduce the probability of failure mode occurrence. Failure modes identified early are cheaper to fix.

3.1.3 Organization Capability: Key Risk and Reliability Practices One of the most fundamental requirements in design and manufacture is to create systems that work, not just once, but continuously for the whole life of the system. The means by which this is accomplished is defined by the combined management practices of the organizations which work together to design manufacture, install and operate the system. A number of key management processes or key practices have been found to be important in developing organizational capability in the achievement of reliability (see Figure 5). The overall process that delivers the reliable system is built on these organizational practices and is the fundamental principle behind this recommended practice.

3.1.3.1 R&M Core Processes and key reliability objectives The reliability strategy in this recommended practice is essentially based on four core R&M processes which can be considered the key reliability objectives, namely: KP1 Definition of R&M Requirements KP2 Organizing and Planning for R&M KP3 Design and Manufacture to achieve R&M goals KP4 R&M Assurance In order to deliver the four reliability objectives, the project team will need to implement a number of supporting management processes and practices. These may already exist in some form within the operator, supplier or contracting organizations but may need to be adapted to provide a reliability focus.

Definition of R&M Requirements

R&M AssuranceOrganizing and Planning for R&M

Risk & Reliability Analysis in Design

Data Management

Reliability and Qualification

Project Risk Management

Supply Chain Management

Management of Change

Verification and Validation

Design and Manufacture for R&M

Organizational Learning

Figure 5: Organizational reliability capability and the structure of the reliability strategy processes The resources and management effort required to implement these tasks must be identified and matched to the projects needs. This will depend on various factors such as the degree of overall project and individual package risk. Typical supporting practices and activities that may need to be addressed are shown in Figure 5 and include:

Copyright ©

API 17N API


Implement Assurance and Management KP5 Verification and Validation KP6 Project Risk Management KP7 Reliability and Qualification testing KP8 Data Management KP9 Supply Chain Management KP10 Management of Change KP11 Risk and Reliability Analysis in design Long term Investment KP12 Organizational Learning

Copyright ©

API 17N API


4 How to use this Recommended Practice The layout of the RP has been designed to facilitate the implementation of reliability programs in subsea projects. Sections 1, 2, 3 and 4 describe the background to the recommended practice and covers; the scope, technical definitions, the purpose of the recommended practice and how to use this recommended practice respectively. It also includes a general description of the principles of reliability engineering and technical risk management in subsea projects. Section 5 provides guidance on Qualification processes and R&M activities specific to the introduction of new technology both in product development and in field development projects. Section 6 provides an outline of the key processes required to implement a reliability strategy in subsea field development projects and provides guidance on R&M and technical risk management activities to be applied at the different stages in the life cycle of a project. To that end, section 6 is broken down into the typical project phases observed throughout a subsea project. Each project phase lists the generic engineering activities undertaken throughout a subsea project to which key R&M tasks have been aligned. Section 7 is Annex 1, describing each of the key processes in detail. Section 8 (Annex 2) discusses the collection of R&M data.

4.1 REFERENCING SYSTEM Table 2 lists the 12 key processes which form the basis of this recommended practice. Column KP in Table 2 is the numbering system employed throughout this RP for the generic key process (e.g. R&M assurance is KP4). The project phase notation and reference to the relevant section in this RP is listed in Table 3.

Key Process Generic Process Title

KP1 Definition of R&M Requirements KP2 Organizing and Planning for R&M KP3 Design and Manufacture for R&M KP4 R&M Assurance KP5 Verification and Validation KP6 Project Risk Management KP7 Reliability and Qualification Testing KP8 Data Management KP9 Supply Chain Management

KP10 Management of Change KP11 Risk and Reliability Analysis in design KP12 Organizational Learning

Table 2: Generic key Processes

Copyright ©

API 17N API


Table 3: Project phase notation Table 4 recommends the level of detail at which the reliability effort should focus for each planning and design project phases. For example during Feasibility the level of hardware definition will be quite limited and so R&M and technical risk assessment issues will tend to address technical risks associated with high level project variables such as; location, water depth, field size and reservoir conditions (pressure, temperature, composition) etc. During detail design, on the other hand, risk and reliability assessments will require a range of attention from overall package level down to component level. Recommended reliability engineering detail Project phase Project level Feasibility and Appraisal A High level System Options Conceptual design and selection C Down to major package and system level FEED F Down to sub system and Component Level Detail Design D Table 4: System Indenture Focus

4.1.1 Key charts, tables and matrices Each project phase discussed in section 6 includes a number of flowcharts, tables and matrices, which are fundamental to the construction of the R&M task plan (as indicated below). These are described below.

R&

M re

quire

men

tsO

rgan

izin

g an

d Pl

anni

ng fo

r R&

MD

esig

n an

d M

anuf

actu

re fo

r R&

MR

&M

Ass

uran

ceVe

rific

atio

n an

d Va

lidat

ion

Proj

ect R

isk

Man

agem

ent

Rel

iabi

lity

and

qual

ifica

tion

test

ing

Dat

a M

anag

emen

tSu

pply

Cha

in M

anag

emen

tM

anag

emen

t of C

hang

eR

isk

and

Rel

iabi

lity

Ana

lysi

s O

rgan

isat

iona

l Lea

rnin

g

Key EngineeringTasks Resp. ID Key Reliability Tasks 1 2 3 4 5 6 7 8 9 10 11 12Establish reserves and risk (economic evaluation)

Op A1 Project Risk ReviewO C X C I

Identify technical development risks Op A2 Categorize project X O C IOp A3 Preliminary reliability assessment C XOp A4 Project Value Analysis X O C COp A5 Define R&M goals X O C

Develop initial exploitation plan Op A6 Define R&M organization X O I

Outline technical solutions

Figure 6: Task-Process matrix example Figure 6 is a task-process matrix. Its primary function is to align R&M tasks to existing engineering activity and explain the joined up management of the R&M tasks and processes. The contents of the task-process matrix are explained below:

Section Field Development Project Phase Phase Notation

Phase Objective

6.2 Feasibility A Appraise the feasibility of exploitation 6.3 Concept Design C Identify what could work and select the best

choice 6.4 Front End Engineering Design F Define how it will work in principle 6.5 Detail Design D Make it work in principle 6.6 Design for Manufacture and

Manufacture M Build it

6.7 SIT, Installation and Commissioning S Check that it will work in practice 6.8 Operations P Keep it working

Formatted Table

Copyright ©

API 17N API


Column 1 – Key Engineering Tasks Lists the generic engineering tasks for the project phase. Column 2 – Responsibility Identifies who has responsibility for the task; the supplier (S) or the operator (Op) Column 3 – Reliability Task Identifier Alphabetic letter refers to project phase, refer to Table 2, plus a unique numerical identifier. Column 4 – Key Reliability Task Lists the risk and reliability activities associated with each engineering task. Column 5 to 16- Mapping reference to the reliability key processes Good reliability management practice demands that R&M tasks performed within a given process must be linked to other key processes. For example, almost all activities will need some level of verification and most analytical tasks or testing tasks will benefit from some form of validation. Likewise the output from many of the R&M processes will inform the Reliability assurance process. In order to address the integration of reliability management, a matrix is included to indicate the relationship between the reliability tasks and the key reliability processes. The form of the relationship is defined by the following code: X - Indicates the one parent key process for each R&M task C - Complementary process to the task or is a standard part of the task. I - The process inputs to a task O - Process receives data from the task output. For example (Figure 6), the parent key process of value analysis is the Definition of R&M Requirements (KP1 = X). It requires a system model and so is complemented by the Risk and Reliability Analysis in Design key process (KP11 = C) and must be verified/validated (KP5 = C). This outputs information to the R&M assurance document (KP4 = O).

Copyright ©

API 17N API


Figure 7: Example task flow chart (taken from Feasibility phase) Figure 7 is an example task flow chart, which serves to advise the user as to the logical progression of the R&M tasks throughout the project phase (black lines). It also indicates the flow of information to the R&M assurance document (grey lines).

A-D

Project Risk Review

A1/KP6/7.6

Identify and review the perceived R&M risks of the potential field development. This may be supported by a review of historical lessons learnt, should information on past relevant projects be available.

A-D

Categorize project

A2/KP1/7.1.2

Categorize the project based on the environment and reservoir characteristics and the impact this has on the experience of the project management team and perceived technology stretch or requirement for new technology. Categorization may benefit from a review of past relevant projects.

Table 5: example task worksheet guide Table 5 shows part of a task worksheet guide used for each phase, which is used to facilitate the construction of the detailed plan. In the worksheet the tasks for each project phase is listed; guidance is given on the R&M tasks which contribute to the parent key process. The level of effort and detail involved in each task will depend upon the level of risk in the project or hardware involved. Four categories of risk have been defined (see Annex 1) ranging from ‘A’, for high risk projects using new technology down to ‘D’ for low risk projects using field proven hardware. Some tasks are recommended for all categories of risk, whereas others need to be adapted to be commensurate with the level of risk. The guidance on these tasks varies depending on the risk category and separate descriptions are provided for each category. The notation in the bottom left relates the task (e.g. A2) to the parent key process (KP1) and provides reference

Copyright ©

API 17N API


to the annex of this recommended practice (7.1.2) for guidance on the specific application of the key process.

4.2 QUICK START APPLICATION OF API RP 17N TO SUBSEA PROJECTS One of the most useful applications of API RP 17N is in developing a reliability plan for implementation in a subsea project. The framework for application of this recommended practice to a specific project phase is suggested in (Figure 8) and is explained below:

1. Construct Engineering Plan

2. Identify relevant R&M tasks

3. Categorization

4. Scope/Task review

5. Create plan

5b. Order task list

6a. Create detailed work sheet

6b. Link to other processes

7. Implement tasks

Project activities

API task-process matrix

A, B, C, D

API Annex 1

API task flow chart

Task worksheet guidesRisk category

API task-process matrix

API Annex 1

Det

aile

dpl

anO

utlin

e pl

an

5a. Get task list

Figure 8: R&M strategy plan construction process

Copyright ©

API 17N API


1 Construct a plan of engineering tasks for that project phase as per normal company practice.

2 For each engineering task on the plan, identify the corresponding engineering task listed on the task-

process matrix and determine the aligned R&M tasks. This step uses columns 1 and 4 in the task-process matrix.

3 Perform the categorization task at the relevant level of project management/engineering detail.

4 Review the scope of the project in conjunction with the risk categorization and the generated R&M task list to identify if there are any R&M tasks missing (see below for more detail on this analysis).

5.a Add the missing R&M tasks identified in step 4 to the list generated in step 3 to create a complete list of the R&M tasks to be undertaken in this project phase.

5.b Use the task flow chart presented in the relevant project phase section of this recommended practice to logically order the R&M tasks to be undertaken. This completes the generation of the outline plan of R&M tasks. For lower risk categories, this plan may be sufficient and the strategy can progress to step 7. For higher risk projects or if the plan is being created for the completion of tasks by a third party (as defined according to column 2 in the task process matrix), then the more detailed worksheets may be required according to steps 6a/b.

6a Detailed R&M task worksheets should be constructed stating the nature of the task required given the project risk categorization. This is achieved with consultation with the task worksheets guides located in the relevant project phase section (e.g. Table 5).

6b Use columns 5-16 of the task-process matrix to better plan the R&M tasks and link them to the other key processes.

7 Implement the plan of R&M tasks determine in the previous steps. Reference should be made to Annex 1 of this recommended practice for guidance on their implementation.

4.2.1.1 Scope/Task review Note that the step 4 (above) is a crucial for the correct implementation of the R&M strategy. This step is used to align the R&M tasks to the technical risk category of the project and is especially useful if no engineering task indicated in the company plan is adequately represented in the task to process matrix. The review is implemented to address the questions:

• Given the project scope/risk what R&M tasks should the company be doing? • What R&M tasks are missing? • Are the R&M tasks aligned to the engineering tasks?

To support the assessment, the scope of the project should first be reviewed in the context of the technical risk categorization. This will drive the decision making process regarding the level of reliability activity and the effort with which they are performed. For example, a Category ‘D’ project is, by definition, a repeat of a project that delivered the required R&M performance. In this situation, the project plan may only require that the project is delivered according to the same processes already observed. That is, it may not be necessary to perform, say, reliability value analysis as a real project has been shown to deliver acceptable value. Alternatively, the project may be of marginal economic value and so requires a reliability stretch (Category ‘B’), in which case the project manager may wish to conduct reliability value analysis to identify where some extra economic value can be generated.

Copyright ©

API 17N API


The identification of key R&M tasks and the alignment of reliability effort should, where practicable, observe the reliability process flow as observed in Figure 9. By reviewing those key processes in Annex 1 the user can ascertain the types of activity required for that project phase.

Definition of R&M Requirements

Planning and Organizing of R&M

Risk and Reliability Analysis

Design and Manufacture for R&M

R&M Assurance

Verification and Validation

Figure 9: Generic reliability strategy process flow chart

Copyright ©

API 17N API


5 Qualification of New Technology in Projects Technology development projects involve taking ideas and developing the technology to a level at which it can be applied in a field development. This section describes how new technology can be introduced to a field development project or how the readiness for use of a new technology may evolve in a product development project. While the basic philosophy is the same in both cases, the timescale and degree of acceptable risk may be different in each. The process by which new technology is introduced is called qualification. The qualification of new technology in this RP is based on the concept of Technology Readiness Level (TRL), an approach originally developed by NASA to qualify equipment for flight in space. The objectives, principles and philosophy of qualification and TRL are outlined below.

5.1 OBJECTIVE It is generally found that as the product evolves through the various stages of product development the uncertainties on the required metrics decreases as shown in Figure 10 and qualification is achieved when the acceptance percentile crosses the target level for the required metric. The objectives of the technology qualification process are:

• To provide a structured methodology for managing risk of failure in technology development projects and field development projects

• To demonstrate the extent to which new technology is ready for use in field development projects

• To demonstrate the extent to which existing technology is ready for use in new applications or under extended operating conditions.

• To increase confidence in the achievement of functional and performance requirements when new technology is applied in projects.

5.2 PHILOSOPHY The qualification process is based on good technical risk management practices and the concept of technology readiness as outlined below.

Systems incorporating new technology or using existing technology in new environments constitute greater risk to the operator in terms of reduced reliability. These risks must be carefully managed during development projects to achieve a robust and reliable product. The level of effort required to reduce the risk depends on the extent to which a given technology is “ready” for use in a particular application and the preparedness of the operator (user) to implement appropriate qualification procedures for such applications.

The main principles are as follows:

1. A systematic approach: It is recommended that a systematic approach to technical risk/reliability assessment be adopted. This should include:

a. Definition of technology requirements (includes risk and reliability requirements) b. Identification of technology failure modes and mechanisms

Target

Concept Design Prototype manufacturing

Qualification phases

Compliancewith target

Upper limitUncertaintyDistribution

AcceptancePercentile

Lower limit

Testing Pilot

Req

uire

men

t M

etric

Target






Lower limit

Testing Pilot

Target






Lower limit

Testing Pilot

Req

uire

men

t M

etric

Figure 10: Qualification Progress through a project

Copyright ©

API 17N API


c. Assessment of failure criticality (risk consequences) to determine relevance d. Actions taken to reduce risk and uncertainties associated with

i. Technology itself (internal) ii. Operating characteristics and Environment (external)

2. Proportionate qualification effort: The level of effort should be commensurate with the level of uncertainty associated with the operating regime, the environment, technology performance and failure criticality.

a. A greater the uncertainty in the operating environment or the performance of the new technology device will require a higher margin against failure, more robust qualification methods and a greater weight of evidence of performance achievement.

b. The greater the consequence of failure the greater the confidence of reliable performance required for the application and the greater the level of effort in qualification required.

3. Screening: Qualification should be used as a means of screening technology for projects. a. Projects where a low level of business risk is demanded should aim to deploy technology

which has already achieved a high level of technical readiness. b. Hardware packages requiring use of technology with low levels of technology readiness

(see TRL definitions table) will be categorized as high risk projects packages. 4. Virtual testing: Theoretical analyses (using for example physics of failure models) may, in some

cases, be used as a “virtual test” tool to document fulfillment of a specification or a margin against failure. Where this is adopted, theoretical analyses should be formally validated by independent assessment or by test methods.

5. Test Omission: The omission of a qualification test, whether physical or virtual should be justified on a “balance of risks” basis. For example, it may be acceptable to omit a test if it can be shown that the cost of performing the test exceeds the risk reduction benefit from the test when the risk reduction is translated into financial terms.

6. Quality Assurance and Control: The QA/QC system employed during manufacture, assembly, Installation, Start-up and Commissioning of systems which include new technology should be considered an integral part of the qualification process.

5.2.1 Principles of Qualification The following principles apply in the qualification process:

1. A system which incorporates new technology will require evidence that it is ready for use by an operator in a given environment.

2. A system previously accepted as “ready for use” in a particular environment will require additional evidence of readiness if the system is to be used in a more challenging environment such as a field in deeper water than the technology has previously been deployed in.

3. All specifications and functional requirements should be clearly defined, quantified and documented and have the agreement of all stakeholders.

4. A rigorous technical risk assessment should be conducted for the technology. Ideally this should include; identification of failure modes, operational hazards, human factors, etc. and quantification of consequences. Risk assessment tools may be used to determine the consequence and likelihood of failure. Risks that are not identified pose a significant threat to the successful implementation of the technology.

5. The acceptable margin against failure (see safety margin below) should be established based on recognized methods, standards, or on combinations of all uncertainties used in the data, operation, calculations and tests.

6. The qualification efforts (analysis, testing, previous experience, etc.) for each technology failure mode should be documented (for traceability) along with the established margin to

Copyright ©

API 17N API


failure. Gap analysis should be conducted to determine if any failure modes have not been adequately qualified.

7. When experience is used as proof of fulfillment of the specifications, the evidence should be collated and validated. The experience must be in the relevant operating regime for it to be valid.

8. The limiting material and functional parameters to be used in the analysis shall be identified through tests or reference to recognized literature.

5.2.2 Stress When products are operated in real environments, they will be exposed to various stresses which drive the failure mechanisms. These may take different forms. In this RP the term stress implies and includes:

• Mechanical load (static, cyclic, axial, multi-axial, tensile, compressive, etc.) • Pressure and pressure induced stress • Temperature and thermally induced stress (e.g. softening, thermal fatigue, etc) • Chemical environment (e.g. concentrations of specific chemicals)

In some cases it may be more convenient to think of stress in terms of: • Degradation rate (crack propagation rate, corrosion rate, erosion rate, wear rate etc) • Defect size (crack size, pit depth etc.)

5.2.3 Margin against Failure The level of tolerable stresses should be measured to determine the safety margin between operating stress and limiting stress. Safety Margin (M) is defined as the differences between the operating (destruct) limit and the mean operating condition. Where the actual operating stress is uncertain or the stress limit is

uncertain the Safety margin is defined as the difference between the means of the actual stress and the stress tolerance limit as shown in Figure 11. Two limits should be defined; the operating limit and the destruct limit. Operating Limit: The operating limit may be considered as either

• Reversible failure limit • Risk tolerability limit

In the reversible failure limit an actual failure occurs if /when the stress exceeds the limit but the system state is reversible, i.e. the product can be brought back to the working state by reducing the stress.

The risk tolerance limit does not represent a failure state but is the level of stress beyond which the operator is not prepared to operate the equipment. In this case, the operator may choose to set a high or low stress limit to reflect the level of risk that is acceptable to the operator. Destruct limit: Exceeding the destruct limit will cause an irreversible shift of state from the working state to the failed state. Some stress variables may possess only a single upper limit, others may be two sided. Pressure stress variable for example, may be two sided for seals. A seal leak may occur at pressure below the lower operability limit or above the upper operability limit.

5.2.4 Reliability Index Where the actual operating stress is uncertain or the stress limit is uncertain a useful metric is the reliability index, RI defined as:

Product Operating Range

stress

UpperDestruct

Limit

LowerDestruct

Limit

UpperOperating

Limit

LowerOperating

Limit

Operatingmargin

Destruct Margin Destruct Margin

Operatingmargin

Product Operating Range

stress

UpperDestruct

Limit

LowerDestruct

Limit

UpperOperating

Limit

LowerOperating

Limit

Operatingmargin

Destruct Margin Destruct Margin

Operatingmargin

Figure 11: Stress Margin Concept

Copyright ©

API 17N API


σσσσ 2222

LXLX

mm MLXRI−

=−

−=

Where Xm and Lm are the mean values of the applied stress and stress limit, σX and σL are the standard deviations of stress X and limiting stress L respectively and M is the safety margin, defined as the difference between the means of the actual stress and the stress tolerance limit. Reliability and robustness improvements are achieved by designing technology in which the margins are as large as possible. Where there is a high degree of uncertainty either on the stress limits or on the operating stress itself, a greater margin of safety is needed to provide an acceptable reliability index. Where the stress and limit distributions are known to exist but numerical data is unavailable. Experience and expert judgment may be used to place estimates on the mean and standard deviation and hence on the reliability index.

Copyright ©

API 17N API


5.3 QUALIFICATION PROCESS The qualification process described below has been developed to create a formal link with technical risk management and reliability strategy. The process, illustrated in Figure 12, shows the steps recommended for performing qualification tasks and how these are related to reliability and technical risk management. The key steps in the process are outlined below.

System AnalysisParts Tree

Initial qualification status and TRL

Required qualification status and TRL

Identify items requiring qualification to meet required standard

Determine function, performance and reliability requirements for all elements below the

qualification standard.

Report results of qualification and reliability demonstration

Identify existing test or design new test programme using FMECA and RCA tools

Implement reliability improvement and risk reduction follow up actions

Implement Qualification Test

Project Technology requirements

Reliability Assurance


Testing

Organizing and Planning for Reliability

Design and Manufacture for

R&M

Reliability Categorisation

Update Reliability Category

Basis of Qualificationand initial qualification plan

Assess Performance in Test Improvement loop

DEVELOPMENT PROJECT

PackageR&M Requirements

Reliability Modelling and

Analysis

Technical Risk Analysis

Update Reliability Category

Update Qualification Plan

Figure 12: Qualification process

Copyright ©

API 17N API


5.3.1 Basis of Qualification and Initial Plan The first activity in the qualification process should be to define the basis of qualification. This should include:

• Qualification Specification covering o Scope o Purpose

• Outline plan of initial qualification activities • Any cost or scheduling constraints

The qualification process will generally be triggered by a project requirement and project risk category and may be required for the following reasons:

• To develop new technology: The need for new technology may have been revealed as part of a forward look at future requirements and technology portfolio needs, leading to a technology development project. In this case it is recommended that the qualification process is used to progress the readiness of the technology for future application. In some cases this will be the initiation of a development program still be at the concept and R&D stage.

• To implement new technology: For a field development project, the qualification objective may be to take a partially developed technology e.g. with a low TRL to the required level of technology readiness. The risk categorization process will generally indicate if or where any “new technology qualification” is required. Typically, this will only apply for Cat “A” or Cat “B” projects and packages.

• Implement existing technology in extended environment: For some projects there will be a requirement to implement known technologies in new applications or environments (deep water). In this case, the technologies may well be field-proven for less aggressive conditions but will require qualification for new conditions. Again risk categorization will generally indicate if this is necessary and will typically apply to Cat “A” or Cat “B” projects and packages.

• To identify new technology elements in existing hardware: There is almost always some degree of evolution in the design and manufacture of products over time, to create more cost effective manufacturing practices or introduce new sub-suppliers. These manufacturing process changes may adversely impact on product reliability performance and in some cases the 1st tier supplier or operator may be unaware of the changes made. In such cases implementation of the qualification process may be used as a means of identification of change and assurance that hardware meets the required level of technology readiness.

These inputs will provide the basis for the initial qualification plans which should aim to identify the items requiring qualification and the information needed to determine the qualification tests to be performed on those items. The key initial tasks are:

• Systems assessment to identify all hardware items in the package, their interactions, dependencies and interfaces. Then for all hardware items identified in the system

o Define technology qualification specification o Identify the existing TRL o Determine required TRL.

• Technical Risk and Reliability Analysis: It is recommended that these activities are supported by systems reliability analysis methods, technical risk assessment and consequence criticality assessment to determine relevance as outlined below.

5.3.2 System Analysis It is recommended that a systems analysis is performed on all packages within the scope of the investigation. The main task is to perform a system breakdown (called a family tree or a systems parts tree) in which the package to be investigated is broken down into systems, subsystems, components and parts. This should reflect the physical system/package and unique identifiers should be used to ensure traceability and unambiguous component/part identification. The systems analysis parts tree has two goals:

Copyright ©

API 17N API


• To identify the elements (parts, components, subsystems etc.) within the tree which are to be included in the qualification program. Specific tree nodes should be identified as study nodes.

• To capture key properties, interfaces and operating conditions. This will help to identify qualification test methods to be used

The lowest indenture level to which this breakdown should be performed will vary, depending on the degree of interaction and dependency between parts, components, subsystems and systems. In addition to the system parts tree it is recommended that three further studies be included as part of the systems analysis.

• FMECA: A failure modes and criticality analysis will build on the system breakdown and support the system analysis task and the qualification process by identification of failure consequences of individual components in the system and by listing the failure mechanisms and root causes of failure. The latter is an important input to the identification or development of qualification test methods. The FMECA tool can therefore be used at different stages throughout the qualification process. It should be noted that the FMECA tool is not ideal for identification of system failure modes and that systems reliability analysis tools are more appropriate for this task.

• System reliability analysis: this should be performed as a means of modeling and understanding system failure modes. System cut sets should be identified to identify relationship between component failure modes and system failure modes. Various techniques, including; reliability block diagrams, fault tree analysis and event tree analysis can be useful in investigating dependency.

• Common cause failure analysis (CCF): this is a technique where there is specific search for conditions or elements which when failed cause other hardware elements to fail. There are various dependencies that may be investigated

o Hardware interactions: e.g. failure of one component in one system causing multiple failure events in the same or different subsystems or at different hierarchies.

o Environmental interactions: e.g. corrosion causing failure of many components o Vibrations or shock loads: causing multiple fatigue or stress failures in multiple

components. o Human factors: Human error in design, manufacture or assembly causing multiple

failures CCF is supported by systems reliability analysis and by FMECA. While the above systems reliability methods are important and relevant to any hardware regardless of maturity, these issues are especially important in new technology as many of the problems identified in the analysis may not have been addressed during earlier design stages and prototype manufacture. The above mentioned technical risk and reliability assessments are important in the qualification process. It drives the rest of the qualification process. In particular for new technology, generic reliability data is probably not available. It is therefore necessary to determine the reliability based on understanding of the mechanisms leading to the potential failure modes. It is impossible to plan an adequate qualification procedure unless the potential failure modes have been identified and are understood.

5.3.3 Technology Qualification Specification In this step, a functional and performance specification is provided for each item or group of items selected for the qualification study. In the case of new technology this task is particularly important as it may be the first time it has been performed. For qualifying existing technology in new environments, a functional specification appropriate to an earlier application may be available to support this activity and can be updated for the particular application. Typical qualification factors to be specified include evidence of meeting:

• function and performance requirements • Reliability, maintainability and availability requirements

Copyright ©

API 17N API


• Intervention requirements • Qualification acceptance criteria • Requirements for documentation

o collated evidence, from physical tests virtual tests and models historical experience data and expert opinion)

o types of test o Qualification plans

• Proof of constructability • Proof of maintainability • Proof of Installability • Proof of lifetime/robustness

These factors play an important role in deciding on the type and nature of the qualification tests to be performed.

5.3.4 Initial Qualification status and TRL The concept of technology readiness level (TRL) is used to determine the qualification requirements. The definition of TRL in this RP has been adapted from work performed by the Seafloor Processing Community (SPC). TRL indicates how far the processes in a technology qualification program for a particular technology have progressed. It can only be used with reference to a specific set of operating regime parameters and environmental conditions. If the operating regime or the planned environment changes, then the TRL may need to be downgraded for more demanding conditions or it might be upgraded for less demanding conditions against which technology performance has already been evaluated. Eight technology readiness levels have been defined ranging from minimum of 0, corresponding to an unproven idea, to a maximum of 7, corresponding to proven technology. These are shown in Table 6 below: A candidate new technology might enter the TRL scale at any point depending on how its maturity has been initially assessed. Thereafter as part of a field or technology development program its increasing maturity as it progresses through the qualification process can be recognized by higher TRL numbers. Qualification to a particular TRL level will always be associated with specific operational and environmental constraints. If the constraints are violated then the qualification is invalid.

TRL Development stage Description

0 Unproven Idea Paper Concept; No analysis or testing completed 1 Analytically Proven

Concept Functionality proven by analysis or reference to common features of existing technology

2 Physically Proven Concept

Concept Design or novel features of design validated by model or dummy testing in a laboratory environment.

3 Prototype Tested Full scale prototype built and put through (generic) product qualification program (project ready)

4 Environment Tested Full scale prototype (or production unit) built and put through product qualification program in (simulated or actual) intended environment

5 System Integration Tested

Full scale prototype (or production unit) built and integrated into intended operating system with full interface and functional test

6

System Installed

Full scale prototype (or production unit) built and integrated into intended operating system with full interface and functional test program in (simulated or actual ) intended environment (or production unit installed and operating < 3 years)

7 Proven Technology Production unit integrated into intended operating system and installed and operating for > 3 years

Table 6: Definition of TRL

Copyright ©

API 17N API


A stress - part matrix is a useful tool to support the identification of qualification status and initial TRL. An example matrix is shown in Figure 13 below for a gate valve. In the initial qualification status assessment, the initial TRL score is inserted into each cell and from this an initial assessment can be made of vulnerable items

Body Bonnet Seat Sealing

Seat to Body

Sealing

Body Bonnet Joint

Stem Sealing

Actuating (Hydraulic)

Cylinder

Piston Sealing

Disc Spring

Compensation

System

Visual Position Indicator

ROV Override

Pressure InternalExternalmax differential

Temperature MaxMin

Service FluidsSandContinuous Intermittent

Design PhilosophyGeometryExternal Interfaces

Materials Subsea

Carbon steel

22% Cr25% Cr625 CladTC Hard facingOther

External Coating

Paint

Insulation MaterialApplicationPainting

Certification

Qualification Stress Factor Component: Gate Valve

Operational Service

Figure 13: Qualification Status Matrix

5.3.5 Technical Risk analysis Technical risk assessment plays an important role in defining the nature of the evidence required to qualify equipment for a given application and therefore on the type of qualification test to be performed. FMECA: The most relevant tool for qualification is hardware failure modes and effects criticality analysis. The technique of FMECA is described in various technical reliability standards which are readily adaptable to meet the requirements of the qualification method specified here. Examples of considerations to include in the qualification FMECA are listed below:

• List all components with unique identifiers for all elements included in the qualification study • List function and performance requirements for all elements • Identify failure modes for each function and performance requirement, e.g.

o Internal and external failure modes (technology, operation, environment) o Interface failure modes o Manufacturing, assembly, transportation and installation failure modes

• Assess frequency of the failure mode (use frequency category for semi-quantitative assessments) • List failure mechanisms for each failure mode (there may be more than one mechanism for each

failure mode • Assess likelihood (frequency) of mechanism • Assess consequence criticality of each failure mode • Create FMECA risk matrix of appropriate size to assess frequency and consequence • For each element

o Assess the current qualification status (TRL) o Assess the required qualification status (TRL)

• Define or specify the qualification method to be used to address the failure mechanisms for the components to be qualified

Copyright ©

API 17N API


The required TRL and qualification method/specification

5.3.6 Required Qualification Status and TRL The required TRL will depend on a number of issues including, whether it is a technology development project or a field development and if the latter, it will be sensitive to the Operator’s field development strategy and the operating conditions. In theory a technology development project may take a product’s technology readiness to TRL 6. In practice, however, cost constraints on R&D budgets may prevent large scale testing and it is more likely that product development will go no further than TRL 4 leaving further qualification to field development projects. For field development projects, it is recommended that the required TRL is based on the risk category for hardware and project. For example, Cat ‘C’ and ‘D’ projects and packages should be required to meet the highest level of qualification TRL 7. Whereas, for new technology or for existing technology in extended environments, which correspond to Category ‘A’ and Category ‘B’ projects, it is impossible, by definition, to achieve TRL7 (field proven) status before operation. It is recommended, therefore that in these cases TRL 6 is the minimum required TRL. While in theory it is possible to qualify hardware for a field development project from an initial TRL below 4, it is unlikely to be cost effective and may require more time to qualify than is available in the projects schedule. Category ‘A’ and ‘B’ projects may therefore be required to raise equipment from as low as TRL 4 to TRL6 (see Figure 14).

ABCD

0 1 2 3 4 5 6 7

TRL qualification activities required for this project TRL qualification activities performed in prior projectsTRL actvities performed in suppliers R&D programmeAcceptable TRL for given category

Technology Development

TRL

Field Development

API T

echn

ical

R

isk

Cat

egor

y

Figure 14: Qualification Requirements

5.3.7 Items to be qualified The items to be qualified will be those items with an initial level of qualification below that required. When developing new technology hardware or when implementing new technology in field development projects, study nodes involving new items will be relatively easy to identify. However, when the purpose of the qualification process is to qualify hardware for changed application or extended environment or when checking qualification status of field proven hardware, the task of identifying “changed/new elements” or items influenced by changed conditions and environments may require more detailed review.

5.3.8 Update Technology Qualification Plan Once the items to be qualified have been identified and their qualification requirements understood, the next step is to update the initial qualification plan to include:

• Identification of tests to be performed whether physical test, analytical or experience • Implementation of tests • Assessment of tests results and identification of design or manufacturing changes or

improvements

Copyright ©

API 17N API


• Qualification reporting The plan should also include:

• A clear statement of the qualification goals • A statement of agreed Acceptance Criteria • A summary of the cost-benefit analysis justifying the level of qualification effort against the

probability and consequence of a failure.

5.3.9 Identification and Implementation of Qualification Test Identification of Qualification tasks: The tests that need to be performed will depend to a large extent on the functional and performance requirements and the failure mechanism. In some cases there will be existing standards for tests which can be identified. In other cases, special tests may need to be designed. Implementation of Qualification tasks: These activities represent the major costs of the qualification process. The most difficult qualification task is usually obtaining quantitative information; i.e. to perform qualification tasks the results from which provide evidence for a documented margin to failure.

5.3.10 Achievement of Reliability, Reliability Improvement and Risk reduction Assessment: The Performance Assessment is made to quantify the overall reliability of the technology and confirm that the functional requirements laid down in the Technology Specification are met. If one or more of the tests do not meet the acceptance criteria then the design or operating envelop of the technology must be refined and a new iteration of the qualification process must be performed. A reasonable margin towards failure should be calculated for each failure mode. The reliability of the system can be inferred through this margin. Although a technology may be convincingly proven fit for service without using reliability measures, a quantified reliability of the technology provides considerably more confidence in the technology. The qualification process can be run throughout the development of the technology, or be started at any time in the development. Figure 10 illustrates that the probability of failure at the target level of reliability is reduced through the qualification work until the residual uncertainty is acceptable. A qualitative approach can be practical to use in the early development phase (conceptual). Quantitative measures are relevant in the later development phase.

5.3.11 Qualification Reporting It is recommended that the activities performed during the Technology Qualification Process are formally documented to provide traceability during the project and to maintain an audit trail. It is recommended that the Qualification report includes the following headings:

1. Summary and Recommendation 2. Technical System Description. 3. System Analysis 4. Qualification Requirements. 5. Qualification Plan 6. TRL prior to execution of the Qualification Program 7. TRL requirements 8. Execution of the Qualification Program 9. TRL achieved after the Qualification Program 10. Results and evidence of achieved TRL. 11. Achievements and Expected R&M performances. 12. Cost and time estimates for further work to increase TRL to the next level up 13. Limitations on Use. 14. Conclusions and Recommendations. 15. References.

Copyright ©

API 17N API


5.4 PURPOSE OF TESTING

5.4.1 Purpose of Testing Great care must be taken to verify the appropriateness and applicability of all “tests”. There are many reasons to undertake testing:

• To gain insight into performance influencing mechanisms (e.g. model basin) • To show that an item meets a functional requirement • To reveal hidden failure modes (e.g. repeated operation tests) • To test specific vulnerabilities (e.g. shock and vibration) • To screen out early life failure mechanisms • To determine the time or number of cycles to failure (e.g. fatigue testing) • To reduce the uncertainty with respect to all the above associated with the environmental

conditions and operating regimes (e.g. by climatic chamber testing)

5.4.2 Testing to demonstrate functional performance In the oil and gas sector, functional testing is the most common approach. The functional test logic is illustrated in Figure 15. However, this form of testing has limited impact on reliability improvement. Sometimes the test method will have been predefined in a standard (e.g. an API standard) or it may be a company standard. The design of the test program must be based on a detailed understanding of the failure mechanisms expected for the operating conditions to which the product will be exposed.

Figure 15: Functional test logic

5.4.2.1 Test Conditions For testing to be realistic it is important that the environmental and operating conditions are equivalent to those found in service. Sometimes the test program will be broken into a sequence of specific tests targeting known or possible failure modes and replicating or exaggerating conditions likely to cause them. Extremes of temperature, highly corrosive atmospheres, dust and humidity are examples. In some instances it might be necessary or more appropriate to accelerate the test by applying higher stresses. This technique is employed in accelerated life testing and accelerated stress screening.

Select product Result?

Report and document results

Pass

Fail Identify Fault

Design Qualification Test

Implement testImplement test

Product delivery

Fix fault Retest?

Yes

No

verificationverification

validation

verification

Copyright ©

API 17N API


5.4.2.2 Test Items Tests may be performed on models or on the hardware product itself. The strategy adopted will depend on the stage of development and has an impact on the TRL. Tests may be performed on:

• Physical models • Computer models (analytical models) • Full scale Prototype units • Full scale Production units

5.4.2.2.1 Physical Models Physical models are a realistic physical representation of the eventual hardware. It may vary in size and functionality but usually has the advantage that nature is correctly taken into account in the way the model behaves. If in devising a test a key factor of nature is omitted this will be revealed in the behavior of the model. An important issue with physical models is scaling. For example there may be concerns over the extent to which a reduced scale model correctly replicates the real world behavior. This situation applies particularly in tests involving fluid flow to model erosion effects, for example.

5.4.2.2.2 Computer Models Computer models can sometimes be used when it is not possible, or when it is very expensive to use physical or full-scale models. The key issue for numerical models is the extent to which the computer program models reality. Thus, when analytical or computer models are used it is important to implement a validation process to confirm that models are in reasonable compliance with the real world situation. For this reason numerical models are typically used first only when sufficient experience and confidence has been gained that they are representative. Numerical models are prone to human and intellectual errors such as forgetting to “switch on gravity” in an earthquake model! A typical approach to validation is to use a physical model first, then create a numerical model of that physical model and ensure that the numerical model properly replicates the physical model. Thereafter, the numerical model can be used to investigate the effects of change more simply and quickly than rebuilding the physical model. This combined approach gives the benefits of both techniques.

5.4.2.2.3 Full Scale Prototype and Production units The most realistic trials are those involving full scale prototypes or full scale production units. Full scale Prototypes are more common in technology development trials whereas trials involving full scale production units are common in field development projects. An important distinction between these two methods is that the prototype may have been manufactured specifically for the test and by a different route from a production unit and so results of qualification trials on prototypes may be quite different from those of production units. Full scale trials should be the final confirmation that all product behaviors and performances are as predicted or required. The risk of failure (of the test) should have been mitigated by previous analysis and where necessary testing of specific features or components in a laboratory. For example, if vibration is a feature of the real environment, the system should be subjected to vibration testing in the laboratory to ensure it can survive the magnitude and duration of such vibration in the field. If there is uncertainty about the frequency and amplitude of such vibration of the field, this would lead to measurements being made prior to doing such tests and certainly before a field trial.

5.4.3 Testing to Improve Robustness and Reliability When the goal is to improve the robustness and reliability, the product development team should design a test program intended to cause failure. The test logic in this case is shown in Figure 16. This approach is sometimes called step stress testing. When tests are designed to cause failure the test:

1. Either creates a new failure mode or confirms an existing failure mode. The subsequent failure analysis then provides a learning opportunity which improves understanding of the failure modes and mechanisms leading to better targeted mitigation.

2. Improves understanding of the operating “stress” limits. The term stress here includes mechanical stresses in all its forms as well as temperature, pressure, chemical etc.

Copyright ©

API 17N API


3. Feedback from the failure analysis enables design improvements leading to higher operability and failure limits making the product made more robust and reliable.

The selected stress increases (stress increment loop) until a failure occurs. At this point the product is given a failure analysis to identify the cause of the failure. The flaw/design fault is then corrected or removed and the design improved if an improvement is possible (improvement loop). If an improvement can be implemented, testing continues until the next failure. This process continues until it is not possible or undesirable to improve the reliability further at which point the capability limit is noted. This approach is most practicable for technology development projects, when prototype has been developed TRL stages 3–5.

Figure 16: Step Stress testing and HALT logic

5.4.4 HALT - Highly Accelerated Life Testing HALT is a variant of step stress testing involving both stresses applied singly and in combination (e.g. temperature, vibration and humidity) HALT is most commonly used to improve the robustness of electronic packages but the approach has generic applicability. The purpose of HALT is to replicate the effects of the real world in a short timescale to gain confidence that the system will survive in operation. One of the key issues is the extent to which the acceleration processes are realistic. For example corrosion, as a chemical process is particularly problematic. Corrosion can be speeded up by increasing temperature, humidity, salinity and flow etc. but interpretation requires that the corrosion process must be well understood. For example; if a failure mode is caused by erosion, speeding up the flow or increasing the particle count for the erosive material may induce a failure more quickly but if the higher flow produces a different flow pattern and different erosion rate the test may not be valid. Despite some of these fundamental issues accelerated life testing can be used to improve robustness and reliability during product development.

5.4.5 Stress Screening in Manufacture and Assembly Stress screening is a processing step performed at the end of manufacture and assembly. Its purpose is to precipitate and discover faults and flaws introduced primarily in manufacture and to a lesser extent, those remaining in design that have not been removed by previously applied design test methods (e.g. HALT). When the stress applied are extreme combinations of stresses this is called highly accelerated stress screening. HASS builds on testing methods such as HALT performed during the earlier stages of product development. However, whereas HALT is used to identify errors and faults in design, stress screening

Select product fail?

No

Yes

Implement product Reliability improvement Improve? Improvement strategyYes

Note the capability limit

No

Improvement Loop

Failure analysis

Yes

Stress Increment

Loop

Next development

Design test rig and test programme

Impose testing environment

Impose testing environment

Increase severity of the test

Increase severity of the test

Copyright ©

API 17N API


5.4.6 FAT and SIT Factory Acceptance Testing and System Integration Testing are important tests carried out during field development projects. These tests are necessary to provide confidence that items have been correctly manufactured in the factory (e.g. to appropriate tolerance), that some primary functional requirements are being met and that subsystems and components (in the field) can be correctly interfaced and logical connections are made. These tests provide confidence that all intermediate steps and processes have been completed without compromising the systems function and integrity. However, FAT and SIT are limited in terms of assessing reliability and robustness. Neither Factory Acceptance Testing nor System Integration Testing will reveal any faults or flaws which require some operating time for the failure mechanism to take effect. Thus a human error in materials selection leading to failure by stress corrosion cracking may not be picked up by FAT or SIT.

5.4.7 Data The engineering analysis and testing described above are sources of data to be used in evaluating the qualification status of the system(s) under scrutiny. However, potentially the most valuable data is that obtained from current usage of analogous or elements of the new technology. It is critically important to validate and verify any and all such field operating data. Too often reference is made to other projects which have not actually commenced operations, leading to a hidden presumption of adequacy of design, implementation, installation and operation where no such evidence exists. Typical verification questions include: • Commissioning date • Actual (rather than design) operating regime and environmental conditions • Actual achieved performance parameters • Lessons learned • Remedial actions

5.4.8 Conclusion Testing should form part of a coherent strategy to build confidence in the function and long-term performance of a particular system or subsystem or component. The need for testing depends on previous experience and the degree of risk. Sometimes testing is a quick and inexpensive way to gain insight, more usually it is to confirm a proper understanding of the physics, ultimately it is to prove that everything works right and will continue to do so for the desired period. Testing is not a shortcut which avoids the need for analysis, good design, careful manufacture and attention to detail procedures during Installation and operation.

Copyright ©

API 17N API


6 Implementation of R&M in Field Development Projects 6.1 INTRODUCTION There are various phases to a field development project that take it from Feasibility (A) through to Operations (P). The nature of the reliability activities and the level of reliability effort will vary with the project phase and should be aligned to meeting the objectives. Advice on the reliability program to be applied at each phase is provided in the following sections.

6.1.1 Generic Reliability Process Flow Chart

Text TextCategorizationPlanning for R&M

Setting R&M Requirements

R&M Modelling and Analysis

Design & Manufacture

for R&M

Engineering Activities

Integration


Testing

Figure 17: Generic reliability process flow chart Figure 17 shows the general flow of the core reliability processes in a project. Each phase will involve certain project engineering and design activities. The nature of these activities is dependent on the project phase and the engineering requirements. The R&M activities need to be aligned to meet the engineering requirements and should support the engineering tasks performed. Typically the initial task in all phases, in any reliability program, will be to create a plan as defined in section 4.1.2. The plan will reflect the R&M objectives and the level of risk in the project and the value to be gained from investing effort in R&M activities. The purpose of the reliability engineering and risk management activities is to influence the design and manufacture of product such that the R&M requirements can be met. However, deciding what design and manufacturing actions to take to meet specified R&M requirements will depend on the inherent technical risk. Designing to deliver the R&M requirements is supported by the qualification of technologies and analysis of reliability and technical risk; the remaining R&M processes are performed in support of these core processes. The following project phase sections describe the integration of the core and associated R&M processes into a generic set of project engineering tasks.

Copyright ©

API 17N API


6.2 FEASIBILITY

6.2.1 Phase Scope R&M should first be considered during the Feasibility (A) phase of a project. The key goal in this phase is to ensure that the project is feasible and that it meets the business strategy defined by the operator. Reliability is not a major consideration at this stage, but there are a number of important R&M activities which, although not involving large resources, are still important.

6.2.2 Description of R&M processes in Feasibility

R&

M re

quire

men

tsO

rgan

izin

g an

d Pl

anni

ng fo

r R&

MD

esig

n an

d M

anuf

actu

re fo

r R&

MR

&M

Ass

uran

ceVe

rific

atio

n an

d Va

lidat

ion

Proj

ect R

isk

Man

agem

ent

Rel

iabi

lity

and

qual

ifica

tion

test

ing

Dat

a M

anag

emen

tSu

pply

Cha

in M

anag

emen

tM

anag

emen

t of C

hang

eR

isk

and

Rel

iabi

lity

Ana

lysi

s O

rgan

isat

iona

l Lea

rnin

g

Key EngineeringTasks Resp. ID Key Reliability Tasks 1 2 3 4 5 6 7 8 9 10 11 12Establish reserves and risk (economic evaluation)

Op A1 Project Risk ReviewO C X C C I

Identify technical development risks Op A2 Categorize project X O C I IOp A3 Preliminary reliability assessment O C X IOp A4 Project Value Analysis X O C C IOp A5 Define R&M goals X O C I

Develop initial exploitation planOp A6 Define R&M organization and

inititate plan X O C I

Outline technical solutions

The primary R&M deliverable from this phase is the determination of the high level R&M goals required to deliver an economically viable project. In addition, a reliability lead should be identified to guide and manage the R&M activity throughout the project and the reliability assurance program should be initiated. The definition of the R&M requirements starts by categorizing the project as a whole. At this stage the project categorization will be driven by the environmental conditions and reservoir characteristics and the impacts that these have on the best available technology and the experience of the asset management team. Project categorization can be facilitated by a project risk assessment and lessons learnt review. Subsequent project reliability activities and associated resources are broadly dependent on whether the project is Category ‘A/B’ or ‘C/D’. A number of different exploitation concepts may be considered during this phase and their feasibility may be evaluated through some high level reliability assessments or financial value analysis if they are particularly marginal or high risk.

Copyright ©

API 17N API


6.2.3 Feasibility R&M Task Description

Figure 18: Feasibility Process Flow Chart

A-D

Project Risk Review

A1/KP6/7.6

Identify and review the perceived R&M risks of the potential field development. This may be supported by a review of historical lessons learnt, should information on past relevant projects be available.

A-D

Categorize project

A2/KP1/7.1.2

Categorize the project based on the environment and reservoir characteristics and the impact this has on the experience of the project management team and perceived technology stretch or requirement for new technology. Categorization may benefit from a review of past relevant projects.

A/B

Perform a preliminary high level project FMECA (or any other suitable risk identification/assessment practice) to examine the feasibility of proposed concepts.

Preliminary reliability assessment

C/D A3/KP11/7.11

Only required for marginal developments; perform a preliminary high level project FMECA (or any other suitable risk identification/assessment practice) to examine the feasibility of proposed concepts.

A/B

In conjunction with the economic appraisal of the field, consider the impact of high level project reliability/availability objectives on the financial feasibility of the field. Project value analysis may require some high level system modeling, supported from risk or reliability practices.

Project Value Analysis

C/D Not applicable unless marginal field. A4/KP1/7.1.3

A/B Define R&M goals

Determine the key project R&M metrics required to suitably measure the R&M performance throughout the project. Highlight high level R&M objectives required to deliver financial value.

Copyright ©

API 17N API


C/D A5/KP1/7.1.4

Review applicability of similar past project reliability achievements and identify key R&M metrics.

A/B

Identify/Select a reliability champion to manage the reliability activities throughout the project. The reliability champion should initiate the reliability plan and identify the level of the effort required for the next project phase.

Define R&M organization and initiate plan

C/D Identify/Select a reliability lead for the project. The reliability lead should identify the reliability effort required and identify the source of reliability assurance from previous relevant projects for lower risk projects.

A6/KP2/7.2.1.2

6.2.3.1 R&M assurance, verification and validation The reliability champion/lead should construct the reliability assurance document and collate the necessary information generated throughout the Feasibility stage. Prior to inclusion within the R&M assurance document, the information collated throughout the Feasibility stage should also be verified and/or validated by some authority independent of the project. Items for verification include the project categorization, risk analyses and any value analysis. The selected R&M metrics should be validated for robustness in the decision making process. The assurance document should include the following:

• Project risk categorization • Any initial reliability and/or reliability value assessments or analyses • The concept selection decision making metrics

Copyright ©

API 17N API


6.3 CONCEPT DESIGN

6.3.1 Phase Scope The Concept Design phase (C) addresses the gross comparison of any number of feasible development concepts and the eventual selection of one preferred design option. Activities conducted during Concept Design focus on the high level systems.

6.3.2 Description of R&M processes in Concept Design

R&

M re

quire

men

tsO

rgan

izin

g an

d Pl

anni

ng fo

r R&

MD

esig

n an

d M

anuf

actu

re fo

r R&

MR

&M

Ass

uran

ceVe

rific

atio

n an

d Va

lidat

ion

Proj

ect R

isk

Man

agem

ent

Rel

iabi

lity

and

qual

ifica

tion

test

ing

Dat

a M

anag

emen

tSu

pply

Cha

in M

anag

emen

tM

anag

emen

t of C

hang

eR

isk

and

Rel

iabi

lity

Ana

lysi

s O

rgan

isat

iona

l Lea

rnin

g

Key EngineeringTasks Resp. ID Key Reliability Tasks 1 2 3 4 5 6 7 8 9 10 11 12Define project Plans Op C1 Define initial R&M organization

and Plan C X O C

Identify technical solutions Op C2 Assess R&M of each option I O C I XOp C3 Categorize options X O C I C IOp C4 Value Analysis of options X O C I C

Create statement of requirements and basis of design

Op C5 Define and include R&M requirements X O C C

Review and select Options

When identifying the options under consideration, the system requirements should be defined to meet the business objectives of the project; this will include some high level definition of the reliability and/or maintainability of each option. The ability to achieve these requirements will depend on the inherent technical and financial risks of the concept and these should be reviewed to support the concept selection decision making process. This review strategy should be planned and reliability task ownership assigned to each of the major technical solutions and their respective systems. The review process should begin with a categorization of each of the proposed options which at this stage will be driven by the environmental considerations and high level system architecture. This may then be supplemented with high level reliability modeling and analysis of the conceptual design drawings which may then drive target categories for the technology and reliability stretch. The concept selection decision making process should be supported by value analysis to identify the cost beneficial options and those with the potential for value addition. Having determined the preferred conceptual design the statement of requirements and basis of design are created; these should include the system R&M requirements to deliver project value and any risk category targets for the individual packages which are part of the selected option.

Copyright ©

API 17N API


6.3.3 Concept Design R&M Task Descriptions

Figure 19: Concept process flow chart

A-D

Define initial R&M organization and Plan

C1/KP2/7.2

Plan the option review process and define the option selection decision making process and selection criteria. Assign reliability task ownership to each of the technical concepts. The definition of the decision making process may be supported by a review of past relevant projects or internal standards. Note that any re-categorization of an option may necessitate an update or revision of the decision making process.

A-D

Assess R&M of each option

C2/KP3/7.3.1.1

For each option, deploy suitable modeling and analysis resources to assess the effect of system failure modes and the R&M strategy on the specified performance metric. The assessment methodology may be based on design for reliability concepts and may receive feedback from the value analysis task necessitating re-assessment of the concept with the application of further design for reliability philosophies.

A-D

Categorize options

C3/KP1/7.1.2

Categorize the conceptual options based on the identified operating environment and the high level system architecture/complexity. Given these two identified categorization factors, both the technology and reliability stretch categorization factors should then be allocated from the output from the option R&M analysis. The categorization of each option may be supported by a review of previous relevant projects; note that this means that all of the options may not have the same categorization.

A-C

Value Analysis of options

Assess the cost benefit of the identified options and strategies; this will require some high level system modeling. The relevance of the data used within the models should be assessed prior to application to higher risk projects. Outputs from this task may feedback to the R&M assessment task and potentially necessitate the deployment of design for reliability methods. The value analysis may also highlight scope for further assessment during FEED.

C4/KP1/7.1.3

D Assess the cost benefit of the available category 'D' options and strategies; suitable or generic data should be available if a high level system model is required. Only applicable if there are multiple category 'D' options or category 'D' options competing with higher risk category options.

A/B

Use analytical tools to define the system availability requirements and the reliability/maintainability trade-off. Target low technology and reliability stretch risk categories where applicable. Include requirements in SOR and target categories in BOD.

Define and include R&M requirements

C Set requirements to exceed past relevant projects' R&M performance. Target categories should include an aspiration not to exceed target by more than one category. Include requirements in SOR and target categories in BOD.

C5/KP1/7.1.4

D Set requirements to achieve past relevant projects' R&M performance. Target categories should include an aspiration to maintain 'D' classification. Include requirements in SOR and target categories in BOD.

Copyright ©

API 17N API


6.3.3.1 R&M assurance, verification and validation The assurance document should reflect the plan for the decision making process; this can be applied as the template for the R&M assurance document. It is important therefore that the decision making process has been suitably validated to ensure delivery of the decision making metric. The output of each of the tasks undertaken to inform the decision making process should be verified by independent review. The R&M assurance document should be updated with:

• The assessment plan, including the decision making process • A summary of, or reference to, the options that were assessed, including the respective risk

categories and the associated value analysis and high level systems modeling • The identified R&M requirements of the selected option and target risk categories for the

component packages. • The initial plan for the activities required in FEED

Copyright ©

API 17N API


6.4 FRONT END ENGINEERING DESIGN

6.4.1 Phase Scope During Front End Engineering Design, or FEED, (F) the engineers define how the selected system will work and the system packages needed to make it work. FEED involves a number of design activities undertaken by the operator, or engineering house on behalf of the operator, to determine the overall subsea system design configuration and the specific functional requirements for the basic equipment packages. In doing this the FEED team will refer to both the statements of requirements, which defines the overall technical requirements of the project and to the basis of design of design document, which records the physical parameters which are relevant to the design. It is also important to address a number of reliability activities during FEED and the level of organizational capability of potential package and equipment suppliers. The reliability output from the FEED stage is a set of specifications for the various packages which will ensure that the packages and their integration as a system will meet the specified R&M requirements.

6.4.2 Description of R&M activities in FEED

R&

M re

quire

men

ts

Org

aniz

ing

and

Plan

ning

for R

&M

Des

ign

and

Man

ufac

ture

for R

&M

R&

M A

ssur

ance

Verif

icat

ion

and

Valid

atio

n

Proj

ect R

isk

Man

agem

ent

Rel

iabi

lity

and

qual

ifica

tion

test

ing

Dat

a M

anag

emen

t

Supp

ly C

hain

Man

agem

ent

Man

agem

ent o

f Cha

nge

Ris

k an

d R

elia

bilit

y A

naly

sis

Org

anis

atio

nal L

earn

ing

Key EngineeringTasks Resp. ID Key Reliability Tasks 1 2 3 4 5 6 7 8 9 10 11 12Op F1 Project Risk Analysis C X C I

Op F2 Identify R&M approach X O C IOp F3 Develop project R&M Plan X O COp F4 High level system RAM Analysis O C I XOp F5 R&M Value analysis X O C I COp F6 Design for R&M (reliability

options)C X O C C C

Op F7 Categorization X I O C I C I ICheck design feasibility Op F8 Identify qualification status and

planI O C X I

Define Reliability Maintainability and Intervention strategy

Op F9 Allocate R&M requirements to packages

X I O C O C I

Review and assess risks to each package Op F10 Package Risk and Reliability analysis

I I O C I X

Create package technical/function specifications

Op F11 Incude package R&M specification

X O C I O

Develop Contract Strategy Op F12 Evaluate supplier reliability capability

I O C X I I

Review project risks and update project Schedule

System architecture design

Front end engineering design is commenced with a review of the project risks in light of the BOD and SOR created during concept selection. Given the defined aspirations of the technology and reliability stretch risk categories, the R&M effort can be defined and resources allocated. In creating the functional specification, the system architecture must first be defined in more detail at package level. The risk category of the individual packages should then be assessed and any previously identified target categories should be confirmed or redefined. The package risk category should then be used to plan and specify the resources required for the reliability tasks. A system level RAM analysis should then be initiated to check the capability of the overall system to deliver the project requirements. Low risk packages (C or D) maybe modeled at high level (A or B) but

Copyright ©

API 17N API


high risk packages may require more detailed modeling. If system reliability improvements are required, then value analysis techniques should be deployed to identify the optimum value package or architecture reliability changes and the associated expected resource requirements. These identified improvements can be implemented through design for R&M philosophies and should subsequently be subject to further RAM and value analysis. The output of the RAM analysis and resultant actions of the design for R&M should direct either the confirmation of the previously identified package risk categories (including the aspired technology and reliability stretch targets) or the re-categorization of the packages. It is at this point that the qualification status (TRL, see Section 5 of this RP) of each of the available packages should be determined along in light of the allocated R&M requirements. Reviewing the TRL and allocated reliability will facilitate determining if any package re-categorization is required. For high risk categories or lower TRL packages, extra reliability effort may be necessary due to the high uncertainty of the R&M performance. The package categorization should then be used to update/confirm the overall system risk category. The creation of the technical/functional specification for inclusion within the invitation to tender should include three R&M clauses for each of the packages; the R&M requirement, technology and reliability stretch risk categorization target and an expectation of the demonstration of conformance of the requirements and targets. The ability to achieve and demonstrate conformance will depend on the reliability capability of the supplier. Any tender pre-qualification/qualification process should include a supplier reliability capability assessment; see Annex 1, alongside the QA and HSE assessments.

6.4.3 FEED R&M Task Descriptions

Figure 20: FEED process flow chart

Copyright ©

API 17N API


A-D

Project Risk Analysis

F1/KP6/7.6

Review the project schedule and project risk given the statement of requirements and basis of design.

A-D

Package categorization

F7/KP1/7.1.2

Evaluate the individual package risk categorization based upon the operating environment and identified system architecture. The output from the subsequent RAM and value analysis and consequent design for R&M actions may require a re-categorization of the system. Categorization should be supported with a review of previous relevant projects. Feedback and re-categorization should also be incorporated into lessons learnt.

A-D

Identify R&M approach

F2/KP2/7.2.1.1

Identify the scope of the R&M activities required given the project risk. Note that if the system risk category or a package risk category changes, then the scope of activities may also change.

A-D

Develop project R&M Plan

F3/KP2/7.2.1.1

Plan and resource the R&M activities identified. Sufficient time should be allocated for each of the identified R&M activities. The plan may need reviewing and updating should any of the planned analyses indicate a change in risk category. Assign ownership to each of the R&M processes planned for FEED together with person responsible for overall reliability (typically subsea delivery manager). In FEED responsibility for ensuring that package R&M processes are implemented normally rests with the package lead engineers. The organizational structure may change as FEED progresses.

A-D

High level system RAM Analysis

F4/KP11/7.11

Construct and execute a system RAM analysis model capable of incorporating package level R&M data. Identify areas of sensitivity to project R&M requirements. The level of detail of the model should be aligned with the risk category of the system.

A-C

R&M Value analysis

Identify and rank the most cost beneficial R&M improvement strategies. Determine the resources available for the identified reliability improvement.

F5/KP1/7.1.3 D N/A

A-C

Design for R&M (reliability options)

Areas within the system architecture that require reliability improvement should be address with design for R&M philosophies. For systems of lower risk or requiring marginal reliability improvements, simple architectural changes may suffice (e.g. increase redundancy). For higher risk or substantial reliability improvement requirements, more complex logical architectures may be required. Design for R&M should also account the ease of access for intervention in consideration of the maintainability strategy. As part of the change management practice, any system alterations resulting from design for R&M should be re-evaluated in terms of the system risk categorization and RAM/value analysis.

F6/KP3/7.3.1.1 D N/A

A-C

Package re-categorization

The initial package categorization will have been based upon the operating environment and the initial layout. After allocating the system requirement to packages, each package can be re-categorized based on the identified required technology and the required (if any) reliability stretch. Categorization should be supported with a review of previous relevant projects. Feedback and re-categorization should also be incorporated into lessons learnt.

F7/KP1/7.1.2 D Use the availability of relevant historical data to verify the categorization.

A/B

Identify qualification status and enter package into suitable technology qualification program. The qualification plan should include the reliability analyses required throughout the qualification process (i.e. those activities required up to and including TRL=7). If this task is undertaken in conjunction with a supplier then their qualification statement must be supported with appropriate documentation to the end user.

Identify qualification status and plan

C Check that perceived category 'C' packages are at least TRL=6

F8/KP7/7.7. D Check that all packages included within the design are TRL=7

Copyright ©

API 17N API


A/B

Identify the failure modes (including common cause) of each package (e.g. by FMECA). Estimate/Determine the probability of occurrence of each of the failure modes and implement within the system RAM analysis model. Rank the importance of each of the failure modes based on the risk and uncertainty of risk.

Package Risk and Reliability analysis

C Identify the failure modes (including common cause) of each of the packages. Assess the probability of occurrence for each of the failure modes and rank their importance (e.g. by package level FMECA). The RAM model should be populated with the failure data collated here and the system re-assessed.

F10/KP11/7.11

D Identify the failure modes (including common cause) and importance of each of the system packages. This information should be available from past projects and may verify the categorization. The RAM model should be populated with the failure data collated here and the system re-assessed.

A-C

Allocate R&M requirements to packages

Implement suitable requirement allocation techniques to achieve the R&M and project value requirements where appropriate.

F9/KP1/7.1.4 D Base target R&M requirement on the performance of previous relevant projects.

A R&M specification clause, within the ITT, should include the R&M requirements and an expectation of evidence indicating conformance to the requirement. Specification should also include evidence that the technology has passed through the relevant stages of the qualification procedure.

B/C

Include package R&M specification

R&M specification clause, within the ITT, should include the R&M requirements and an expectation of evidence indicating conformance to the requirement. The specification should also include the target technology and reliability stretch category and request evidence of conformance to this target. Where appropriate, the specification should also request evidence of conformance to the qualification process.

F11/KP1/7.1

D Package requirements should be including within the ITT along with an aspiration to maintain category 'D' classification. The specification should also include a request for evidence that the risk category has not changed and the R&M requirement achieved.

A/B

The ITT should include a description of the supplier selection decision making process and the criteria upon which the selection decision will be informed.

Evaluate supplier reliability capability

C The ITT should include a clause stating the expectation of the supplier to improve the manufacturing process and provide evidence of such improvements.

F12/KP9/7.9 D Review performance of supplier from previous relevant projects

6.4.3.1 R&M assurance, verification and validation There are numerous tasks and analytical techniques that need verification and/or validation, by third party, before the assurance document can be fully compiled. All reliability/RAM/value analysis tools/models should be verified and the input data validated. The supplier selection decision making metric should be validated and the decision making process verified before inclusion in the ITT and assurance document. The reliability assurance document should be updated to include, or refer to, the following:

• Updated system and package risk category • Current package TRL and an outline of the qualification plan • Output from the RAM and R&M value analyses • Design review statement indicating the design improvement recommendations for achieving the

R&M requirements • Package reliability specification • Supplier selection decision making process

Copyright ©

API 17N API


6.5 DETAILED DESIGN

6.5.1 Phase Scope After the award of the contract, it is the supplier’s responsibility to detail the package architecture to deliver the functional and technical requirements included within the ITT. The Detailed Design phase (D) typically takes place within the hardware suppliers’ design organization but could be carried out by a specialist engineering firm. It is the process of converting information about the operator’s needs and requirements into the complete engineering definition of the system/product to ensure proper manufacture, installation and operation so that the inherent reliability and the design intent can be realized. Detailed Design is a major transition from the operator to the supplier and often the first direct involvement of the supplier in the field development process. It is essential for a smooth transition and successful design that clear, unambiguous and complete specifications are provided by the operator to the supplier.

Copyright ©

API 17N API


Det

aile

d D

esig

nLa

yout

Des

ign/

Gen

eral

A

rran

gem

ent

Con

cept

ual D

esig

n

Cus

tom

er S

peci

ficat

ion/

DB

D(s

ee in

put i

nIn

put/O

utpu

t Mod

el)

Spe

cific

atio

n R

evie

w/C

larif

icat

ion

Det

aile

d D

esig

n S

peci

ficat

ion

Iden

tific

atio

n of

Opt

ions

•Exi

stin

g so

lutio

ns (C

/D)

•Mod

ified

sol

utio

ns (B

)•N

ew s

olut

ions

(A)

Cus

tom

erac

cept

ance

Spec

ifica

tion

Free

ze

Spe

cific

atio

ncl

ear

Ris

k/re

war

d As

sess

men

t(h

igh

leve

l scr

een)

Con

cept

Sel

ectio

nba

sed

on e

valu

atio

n an

d ris

k ac

cept

ance

crit

eria

Pre

limin

ary

Eng

inee

ring

Exe

cutio

n Pl

an

Det

ailin

g C

once

pt

FME

CA

for t

ype

A &

B eq

uipm

ent/F

ME

CA

Rev

iew

for

type

C &

D e

quip

men

t

Ris

k M

itiga

tion

and

Qua

lific

atio

n P

lan

Upd

ate

Engi

neer

ing

Exe

cutio

n Pl

an

Stre

ss A

naly

sis

Des

ign

Cal

cula

tions

FEA

Ther

mal

Ana

lysi

s

Mat

eria

l Sel

ectio

n

Sour

cing

Rev

iew

, inc

ludi

ng

sub-

supp

lier c

apab

ility

eval

uatio

n

Man

ufac

turin

g R

evie

w

FTA

/RB

DA

(A o

nly)

FME

CA

Upd

ate/

Follo

w-u

p ag

ains

t Ris

k M

itiga

tion

Pla

n

Layo

utD

esig

nAp

prov

al

Ass

embl

y Pr

oced

ures

Fact

ory

Acc

epta

nce

Test

ing

(FA

T) P

roce

dure

(HAZ

ID)

Inst

alla

tion

Pro

cedu

reH

AZI

D/H

AZO

P

Ope

ratin

g Pr

oced

ures

Rel

iabi

lity

Dem

onst

ratio

n R

egis

ter

Man

ufac

turin

g S

peci

ficat

ions

in

clud

ing

QA

/QC

re

quire

men

ts

Det

aile

dD

esig

nA

ppro

val

FTA

/RBD

A U

pdat

e(A

onl

y)

FMEC

A U

pdat

e/Fo

llow

-up

agai

nst R

isk

Miti

gatio

n Pl

an

Des

ign

Free

zeLa

yout

Fre

eze

Out

put

(see

out

put i

nIn

put/O

utpu

t Mod

el)

Activ

ities

in th

is b

ox a

rein

no

parti

cula

r ord

er.

Challenge specification

Env

ironm

ent

Ope

ratio

nsIn

stal

latio

nsTe

stin

gS

afet

yH

andl

ing

Less

ons

Lear

ned

Expl

ain

timin

g of

de

sign

free

zes

rela

tive

to w

ritin

g of

pr

oced

ures

: it u

sed

to

be th

at th

e pr

oced

ures

wer

e w

ritte

n w

ell a

fter t

he

desi

gn. P

oint

her

e is

to

dev

elop

them

to

geth

er w

ith th

e de

sign

to in

fluen

ce

the

desi

gn.

MO

C P

roce

ss fo

r Det

aile

d D

esig

n st

arts

with

Spe

cific

atio

n Fr

eezeM

ater

ial S

elec

tion

for

Long

Lea

d Ite

ms

Des

ign

Rev

iew

s

Ope

ratio

ns R

evie

wM

aint

enan

ce P

roce

dure

s

Rev

isit

Con

stru

ctab

ility

Crit

eria

Rev

iew

(Har

dwar

e) In

terfa

ce

Man

agem

ent

BO

M &

Dra

win

gs

Des

ign

Val

idat

ion/

Qua

lific

atio

n Te

stin

g of

‘Com

pone

nts’

Det

aile

d D

esig

nLa

yout

Des

ign/

Gen

eral

A

rran

gem

ent

Con

cept

ual D

esig

n

Cus

tom

er S

peci

ficat

ion/

DB

D(s

ee in

put i

nIn

put/O

utpu

t Mod

el)

Spe

cific

atio

n R

evie

w/C

larif

icat

ion

Det

aile

d D

esig

n S

peci

ficat

ion

Iden

tific

atio

n of

Opt

ions

•Exi

stin

g so

lutio

ns (C

/D)

•Mod

ified

sol

utio

ns (B

)•N

ew s

olut

ions

(A)

Cus

tom

erac

cept

ance

Spec

ifica

tion

Free

ze

Spe

cific

atio

ncl

ear

Ris

k/re

war

d As

sess

men

t(h

igh

leve

l scr

een)

Con

cept

Sel

ectio

nba

sed

on e

valu

atio

n an

d ris

k ac

cept

ance

crit

eria

Pre

limin

ary

Eng

inee

ring

Exe

cutio

n Pl

an

Det

ailin

g C

once

pt

FME

CA

for t

ype

A &

B eq

uipm

ent/F

ME

CA

Rev

iew

for

type

C &

D e

quip

men

t

Ris

k M

itiga

tion

and

Qua

lific

atio

n P

lan

Upd

ate

Engi

neer

ing

Exe

cutio

n Pl

an

Stre

ss A

naly

sis

Des

ign

Cal

cula

tions

FEA

Ther

mal

Ana

lysi

s

Mat

eria

l Sel

ectio

n

Sour

cing

Rev

iew

, inc

ludi

ng

sub-

supp

lier c

apab

ility

eval

uatio

n

Man

ufac

turin

g R

evie

w

FTA

/RB

DA

(A o

nly)

FME

CA

Upd

ate/

Follo

w-u

p ag

ains

t Ris

k M

itiga

tion

Pla

n

Layo

utD

esig

nAp

prov

al

Ass

embl

y Pr

oced

ures

Fact

ory

Acc

epta

nce

Test

ing

(FA

T) P

roce

dure

(HAZ

ID)

Inst

alla

tion

Pro

cedu

reH

AZI

D/H

AZO

P

Ope

ratin

g Pr

oced

ures

Rel

iabi

lity

Dem

onst

ratio

n R

egis

ter

Man

ufac

turin

g S

peci

ficat

ions

in

clud

ing

QA

/QC

re

quire

men

ts

Det

aile

dD

esig

nA

ppro

val

FTA

/RBD

A U

pdat

e(A

onl

y)

FMEC

A U

pdat

e/Fo

llow

-up

agai

nst R

isk

Miti

gatio

n Pl

an

Des

ign

Free

zeLa

yout

Fre

eze

Out

put

(see

out

put i

nIn

put/O

utpu

t Mod

el)

Activ

ities

in th

is b

ox a

rein

no

parti

cula

r ord

er.

Challenge specification

Env

ironm

ent

Ope

ratio

nsIn

stal

latio

nsTe

stin

gS

afet

yH

andl

ing

Less

ons

Lear

ned

Expl

ain

timin

g of

de

sign

free

zes

rela

tive

to w

ritin

g of

pr

oced

ures

: it u

sed

to

be th

at th

e pr

oced

ures

wer

e w

ritte

n w

ell a

fter t

he

desi

gn. P

oint

her

e is

to

dev

elop

them

to

geth

er w

ith th

e de

sign

to in

fluen

ce

the

desi

gn.

MO

C P

roce

ss fo

r Det

aile

d D

esig

n st

arts

with

Spe

cific

atio

n Fr

eezeM

ater

ial S

elec

tion

for

Long

Lea

d Ite

ms

Des

ign

Rev

iew

s

Ope

ratio

ns R

evie

wM

aint

enan

ce P

roce

dure

s

Rev

isit

Con

stru

ctab

ility

Crit

eria

Rev

iew

(Har

dwar

e) In

terfa

ce

Man

agem

ent

BO

M &

Dra

win

gs

Des

ign

Val

idat

ion/

Qua

lific

atio

n Te

stin

g of

‘Com

pone

nts’

Copyright ©

API 17N API


6.5.2 Description of R&M activities in Detailed Design

R&

M re

quire

men

ts

Org

aniz

ing

and

Plan

ning

for R

&M

Des

ign

and

Man

ufac

ture

for R

&M

R&

M A

ssur

ance

Verif

icat

ion

and

Valid

atio

n

Proj

ect R

isk

Man

agem

ent

Rel

iabi

lity

and

qual

ifica

tion

test

ing

Dat

a M

anag

emen

t

Supp

ly C

hain

Man

agem

ent

Man

agem

ent o

f Cha

nge

Ris

k an

d R

elia

bilit

y A

naly

sis

Org

anis

atio

nal L

earn

ing

Key EngineeringTasks Resp. ID Key Reliability Tasks 1 2 3 4 5 6 7 8 9 10 11 12Technical / Functional Specification Agreement S D1 Review Package R&M

Requirements X

S D2 Component Categorization X I I O C I I IQualification of new technologies / newenvironment

S D3 Define Qualification Plan and TRL I O C X I

Client Review of supplier documents andWitness of supplier manufacturing process

Op D4 Check monitoring plan is consistent with R&M objectives X O C I I I

Detailed Design Specification S D5 Update R&M requirements X O C C C IPreliminary Engineering and materials selection

S D6 Design FMECA O C I X I

Design Analysis (stress analysis, FEA, etc) S D7 Implement Reliability analysis techniques where required O C I X

Detailed Engineering S D8 Process FMECA O C I I X IS D9 Interface risk assessment O C I XS D10 Review FMECA output vs.

overall package R&M requirements (improve design)

I X O C I I

S D11 Allocate R&M Requirements to package components X O C O C I

S D12 Detailed RAM analysis O O C I X As part of the agreement of the functional/technical specification, the R&M requirements for each package should be reviewed and components categorized. This categorization activity will facilitate the definition of the qualification requirements for each of the components within the package. Note that for category ‘D’ packages/components the technology readiness level will be 7 as they will have entered a state of technology maturity. As part of the assurance process it is important that the operator and supplier engage in dialogue to ensure that the supplier’s R&M plan is aligned with the requirements established in the ITT. The situation may arise where the supplier cannot meet the operator’s specification quoted in the ITT. In this case, the supplier may provide a detailed design specification highlighting the deliverable R&M performance given the supply chain efficiency. The operator should review these changes with regard to the impact on the project deliverables. The engineering design may evolve through the observation of punctuated design analysis and reviews; the preliminary design should include a FMECA, which may highlight the need for design for reliability concepts at the package architecture level. In addition to the standard engineering design analysis, reliability analysis should be undertaken during Detailed Design to examine potential failure mechanisms. Examples of the types of analysis available include:

• Fault tree analysis • Event tree analysis • Root cause analysis • Common cause failure analysis for parallel or redundant systems • Physics of failure techniques to assess areas of reliability stretch or support the material decision

making process. During the detailed engineering task the manufacturability should be considered; this will include a Process FMECA, which will highlight any high level manufacturability issues that should be addressed before the

Copyright ©

API 17N API


design freeze. It is important to consider the reliability of the interfaces between the packages and their constituent components as this is often a source of unreliability. During Detailed Design it is also important to consider how the equipment will be installed, both in terms of required hardware and processes, and how it will be operated. The potential for human error or design overload needs to be designed out where possible and representatives from installation, commissioning and startup should be part of design review teams. It is important to consider the reliability of the installation equipment and procedures in relation to the impact on both scheduling and reliability of the installed system. Before the design is frozen, an important aspect of the reliability work is to update the RAM model with detailed package architecture and allocated component reliability data to confirm that the R&M requirements will be met by the design. The updated analysis can also be used to confirm that the spares and vessel availability during Operations is adequate to meet availability targets.

6.5.3 Detailed Design R&M Task Descriptions

Figure 21: Detailed Design process flow chart

A Cat ‘A’ packages require thorough examination of the performance metrics to identify where achievement of reliability performance e.g. specified M/FFOP requires introduction of new technology or transfer from another application.

B Cat ‘B’ packages require assessment to identify where achievement of reliability performance e.g. specified M/FFOP requires design modification or redesign.

Review Package R&M Requirements

C Cat ‘C’ packages will need to identify where achievement of reliability performance e.g. specified M/FFOP is likely to require adjustment to the manufacturing processes (implementation of design intent)

D1/KP1/7.1.4

D Cat ‘D’ packages simply require assessment to ensure the reliability requirements are realistically within the normal acceptable limits (i.e. no inadvertent changes to operating regime or environmental conditions have introduced more onerous requirements)

Copyright ©

API 17N API


A-D

Component Categorization

D2/KP1/7.1.2

Although the package may have been given a particular category it is important to consider sub-systems and components in their own right and recognize more onerous categories applicable to sub-levels of indenture when necessary. This should drop out of the review of R&M requirements (Action D1 above). Allocation may necessitate component re-categorization if the technology change or reliability stretch is discovered to be more than that expected in comparison to the risk category target stated in the ITT. The TRL and plan should be reviewed in the light of any re-categorization. The categorization process may be facilitated with a project risk review and a review of previous relevant project lessons learnt.

A/B

For higher risk category packages/components planning needs to allow for the design, review, manufacture and comprehensive tests needed to take the technology from its current TRL to the target value. Definition of TRL and qualification plan can be supported by reviewing relevant historical qualification plans.

Define Qualification Plan and TRL

C Check that the packages/components are at least TRL=7. Definition of TRL and qualification plan can be supported by reviewing relevant historical qualification plans.

D3/KP7/7.7 D N/A

A For Cat ‘A’ packages planning needs to allow for the design, review, manufacture and comprehensive tests needed to take the technology from its current TRL to the target value.

B For Cat ‘B’ packages planning needs to allow for the design and review processes together with specific tests to address design changes introduced over base design. Laboratory and field trials may be required to confirm suitability for significantly more onerous environmental conditions.

Check monitoring plan is consistent with R&M objectives

C For Cat ‘C’ packages planning should allow for implementation and confirmation of manufacturing improvements through physical checks of features subject to the manufacturing changes.

D4/KP2/7.2.1.1 D For Cat ‘D’ packages planning for documentation checks will usually suffice.

A-C

Update R&M Requirements

Only applicable if the supplier cannot meet the operator’s FEED specification exactly. Review the supplier’s new specification; direct specific regard to the effect of the changes on the high level project requirements and the management of the supply chain. Implement management of change protocols where necessary.

D5/KP1/7.1.4 D N/A

A-C

Design FMECA

The task of developing a Design FMECA is the same irrespective of package/component categorization; however, the work should be prioritized by categorization as the highest risk will be associated with Category ‘A’ and least with Category 'C'.

D6/KP11/Annex D Verify unchanged design with a review of past relevant Design FMECA

A/B Implement suitable reliability analysis techniques to inform design for reliability process and material selection.

Implement reliability analysis techniques where Required

C Assess impact of reliability stretch on package reliability

D7/KP11/7.11 D N/A

A/B

The task of developing a Process FMECA is the same irrespective of package/component categorization; however, the work should be prioritized by categorization as the highest risk will be associated with Category 'A/B' packages. The supplier should also consider the impact of their supply chain on the process.

Process FMECA

C Focus Process FMECA on the areas of required process improvement. Check that the supply chain is unchanged.

D8/KP11/7.11 D Review past project Process FMECA to verify that production process and supply

chain is unchanged. A-C

Interface risk assessment

The interface risk assessment is the same irrespective of project/package/component categorization, however, the work should be prioritized by categorization of components or systems at the interface in the sequence AA, AB, AC, AD, BB, BC, BD, CC, CD to identify the potentially most serious risks earliest and giving most opportunity to develop suitable mitigation.

Copyright ©

API 17N API


D9/KP11/7.11 D Relevant and necessary data should be available from past projects.

A-D

Review FMECA output vs. overall package R&M requirements (improve design)

D10/KP3/7.3.1.1

The task of reviewing the FMECA is the same irrespective of package/component categorization; however, the work should be prioritized by categorization as the highest risk will be associated with Category ‘A’ and least with Category ‘D’. Areas within the package architecture that require reliability improvement should be addressed with design for R&M philosophies. For systems of lower risk or requiring marginal reliability improvements, simple architectural changes may suffice (e.g. increase redundancy). For higher risk or substantial reliability improvement requirements, more complex logical architectures may be required.

A-C

Allocate R&M Requirements to Package Components

If it is the supplier's practice to supply a detailed specification of the packages to demonstrate conformance to the functional requirement, then the R&M requirements may be allocated down to component level. A suitable reliability allocation technique should be implemented. The allocation process may necessitate the re-categorization of the components.

D11/KP1/7.1.4 D Reference to relevant previous packages should be sufficient.

A-D

Detailed system RAM Analysis

D12/KP11/7.11

Update system RAM analysis model capable with component level R&M data to confirm R&M requirements can be met and that spares/vessel availability during Operations will meet availability requirements.

6.5.3.1 R&M assurance, verification and validation All analysis activities and input data should be verified and validated, respectively, before inclusion within the assurance document. The R&M assurance document should be updated and expanded to include or make reference to the following:

• Qualification status, component risk category and outline qualification plan • Design review statement indicating the design improvement recommendations for achieving the

R&M requirements along with a package specification addressing design and manufacturing issues

• Review of the reliability analyses • Results from RAM analysis confirming R&M requirements can be realized by the design.

Copyright ©

API 17N API


6.6 DESIGN FOR MANUFACTURE AND MANUFACTURING

6.6.1 Phase Scope In this phase (M) of a project the design engineering teams within supplier organizations convert design specification and other design inputs provided by the client operators and convert them into manufacturing and testing instructions to be followed by manufacturing departments of the supplier or their sub-contractors. The key R&M issue for this phase of the production process is the need to ensure that the reliability potential designed into the system is not compromised by defects and faults introduced into the engineering packages during the manufacturing and assembly process. Where there is a supply chain involved, the 1st tier supplier must pay particular attention to the management of reliability throughout the whole supply chain as it is often found that defects can originate in components bought in from 2nd and 3rd tier suppliers. The purpose of the reliability process in this phase of the project is to:

• Correctly identify all reliability features requested in the design phase that need to be included in manufacturing and testing instructions.

• Ensure that any manufacturing and testing risk mitigation strategies identified in the project risk review are followed through in the manufacturing and QA processes.

• Verify that assurance processes e.g. QA process are capable of verifying reliability features during testing and after manufacturing.

• Identify key data and learning from manufacturing and testing processes that needs to be gathered to inform future design for reliability activities, and verify a defined process exists and is followed to collect, collate and distribute the data correctly within the organization.

• Ensure changes that are proposed as a result of the manufacturing and testing process are captured by an active change management process which includes consideration and documentation of any reliability impact before being accepted for implementation.

Copyright ©

API 17N API


6.6.2 Description of R&M activities in Design for Manufacture and Manufacturing

R&

M re

quire

men

ts

Org

aniz

ing

and

Plan

ning

for R

&M

Des

ign

and

Man

ufac

ture

for R

&M

R&

M A

ssur

ance

Verif

icat

ion

and

Valid

atio

n

Proj

ect R

isk

Man

agem

ent

Rel

iabi

lity

and

qual

ifica

tion

test

ing

Dat

a M

anag

emen

t

Supp

ly C

hain

Man

agem

ent

Man

agem

ent o

f Cha

nge

Ris

k an

d R

elia

bilit

y A

naly

sis

Org

anis

atio

nal L

earn

ing

Key EngineeringTasks Resp. ID Key Reliability Tasks 1 2 3 4 5 6 7 8 9 10 11 12S M1 Implement process FMECA and

other reliability analysis recommendations

X O C I

S M2 Check Manufacturing acceptance criteria are consistent with reliability analysis / FMECA assumptions

I O X I I I I O

Non conformance assessment S M3 Review all non-conformances against relevant FMECA and other reliability process output

O C X C I O

S M4 Implement Design FMECA and Process FMECA

d ti

I O C I X

S M5 Check Assembly acceptance criteria are consistent with R&M Requirements

I I O X I I I I O

QA Plan (definition of what you are going to do)

S M6 Implement Design and Process FMECA Recommendations into QA Plan

X O C I I

QA traceability - contents of manufacturing data book (evidence and records)

S M7 Implement Design and Process FMECA Recommendations into traceability Plan

X O C I I

S M8 Define Test in accordance with design and process FMECA reccommendations

O C X I

S M9 Check FAT acceptance criteria are consistent with R&M requirements

I O X O

Final close out of all design / manufacturing issues

S M10 Check that all actions affecting R&M performance have been closed out

I O X I I

FAT procedure and acceptance criteria

Create Manufacturing Specification including review (BoM , manuf dwgs, weld specs, material specs, coating specs etc) including acceptance criteria (also includes all relevant reviews)

Define Assembly procedure and acceptance criteria

Before the commencement of manufacturing and assembly, the manufacturing specification is first created to provide the complete guidance required for manufacturing and assembly. It is vital therefore, that all specific R&M risks highlighted throughout the project planning/design phases are suitable accounted for within this specification. Pre-existing quality assurance processes may predominate this phase. Whilst quality assurance processes may address form and fit failures, it cannot guarantee reliability. The quality assurance plan should be updated to address any specific reliability and maintainability risks that have been identified during the previous project phases. Specifically, the factory acceptance test should be extended to incorporate a reliability acceptance test designed to screen out any latent failures that would otherwise manifest as early life failures. Note that the actions are essentially the same for risk categories ‘A-C’. The extent to which the activities are performed is different due to the scale of risk; this should have already been defined/determined during earlier project phases (i.e. category ‘A’ projects may have identified more risks than a category ‘C’ and hence demand more time and effort).

Copyright ©

API 17N API


6.6.3 Design for Manufacture and Manufacturing R&M Task Descriptions

Plan

QA Plan

Categorization

R&M Assurance Document

Manufacture gate

Implement Process FMECA

recommendations

Traceability Plan

Define FAT

Check Manufacturing acceptance criteria

Check Assembly acceptance criteria

Check FAT acceptance criteria

Non conformance assessment Close out

Figure 22: Design for manufacture and manufacture process flow chart

A-C

Implement process FMECA and other reliability analyses recommendations

Areas where the component manufacturing process is perceived to have an undesirable impact on the package reliability (from Process FMECA) should be addressed when defining the manufacturing procedure within the manufacturing specification. This may include the development/specification of a robust manufacturing process. Physics of failure recommendations may support the material specifications.

M1/KP3/7.3.1.2 D N/A

A-C

Check Manufacturing acceptance criteria are consistent with reliability analysis / FMECA assumptions

Validate the manufacturing specification to ensure that all of the R&M risks highlighted during past project phase analyses have been suitably accounted for.

M2/KP1/7.1.4 D Ensure consistency of manufacturing specification with past relevant projects.

A-C

Review all non-conformances against relevant FMECA and other reliability process output

Any non-conformances identified during the acceptance tests should be reviewed to determine the root cause. For those non-conformances highlighted during the Process FMECA, the frequency should be updated accordingly. For those non-conformances that remained unidentified after the Process FMECA or reliability analyses, root cause analysis should be implemented. Conclusions and recommendations resulting from the non-conformance review may necessitate manufacturing/assembly modification(s).

M3/KP7/7.7 D Non-conformance reviews can be cross referenced to previous relevant manufacturing

processes. Process FMECAs should have considered all possible non-conformances. Implement Design A-C Areas where the component assembly process is perceived to have an undesirable

Copyright ©

API 17N API


FMECA and Process FMECA recommendations

impact on the package reliability (from Process FMECA) should be addressed when defining the assembly procedure.

M4/KP3/7.3.1.2 D N/A

A-C

Check Assembly acceptance criteria are consistent with R&M Requirements

Validate the tolerances on the assembly acceptance criteria to ensure a robust assembly process.

M5/KP1/7.1.4 D Ensure consistency of assembly acceptance criteria with past relevant projects.

A-C

Implement Design and Process FMECA Recommendations into QA Plan

Although quality does not guarantee reliability, the QA plan should include those recommendations from the Design and Process FMECAs where concerns of reliability are directly influenced by quality issues.

M6/KP2/7.2.1.1 D QA plan should be defined in accordance with previous relevant projects

A-C

Implement Design and Process FMECA Recommendations into traceability Plan

The QA traceability plan should be updated accordingly to include the Design and Process FMECA recommendations reflected in task M6.

M7/KP2/7.2.1.1 D QA traceability plan should be defined in accordance with previous relevant projects

A-C

Define Test in accordance with design and process FMECA recommendations

The factory acceptance tests should be defined to consider any risks highlighted in the process FMECA regarding fit and form failure. For high risk categories, the test should be defined as a manufacturing process screening test in preference to monitoring. If the risk categorization is determined by technology, reliability stretch or the operating envelope, then the reliability acceptance testing should be defined in accordance with HASS, ESS or Burn-in procedures. For maintainability strategies, the FAT should consider risks highlighted in the Design FMECA regarding interfacing during intervention activities.

M8/KP7/7.7. D FAT should be defined in accordance with past relevant manufacturing processes.

A-C

Check FAT acceptance criteria are consistent with R&M requirements

The FAT procedure should be validated and verified to ensure that the acceptance criteria are sufficiently robust to minimize the probability type I and type II errors.

M9/KP1/7.1.4 D Ensure consistency of FAT acceptance criteria with past relevant projects.

A-D

Check that all actions affecting R&M performance have been closed out

M10/K2P/7.2.1.1

Review the process FMECA recommendations and ensure that all R&M delivery risks have been suitably accounted within the manufacturing and assembly phase.

6.6.3.1 R&M assurance, verification and validation Most of the R&M activities recommended during manufacturing are validation/verification activities undertaken to ensure the robustness of the manufacturing process; these are described in the task worksheet above. The assurance document should be updated and expanded to include;

• Any changes to the QA plan, traceability plan or FAT given the recommendations from the FMECA and other reliability analysis output.

• Review of the analysis of the identified non-conformances.

Copyright ©

API 17N API


6.7 SIT, INSTALLATION AND COMMISSIONING

6.7.1 Phase Scope This is a key phase (S) performed after manufacture and assembly and before system start up and operation. It comprises three distinct activities, namely:

• Systems Integration Testing (SIT) • System Installation • System Commissioning

These are shown in Figure 23 as part of a flow chart of the overall process.

Figure 23: SIT, Installation and Commissioning Flow chart Installation and hook up tasks are generally carried out by an installation contractor. Commissioning is usually performed by the Operator but the commissioning team is often separate to the operations team who are normally responsible for startup. Most SIT is carried out by the installation team but some limited initial dry SIT may be conducted by a manufacturer prior to hardware shipment. The purpose of the R&M activities associated with this phase are to verify the interfaces and functionality of the overall system through SIT, to assess the reliability of the installation hardware in relation to functionality and availability, and to assess the reliability of the installation and commissioning procedures in relation to impact of the procedures, through over loads, human error or otherwise, on the reliability of the installed hardware.

6.7.2 Description of R&M processes in SIT, Installation and Commissioning The goals of systems integration testing are to:

• Bring together the packages, subsystems and components of the overall system

Copyright ©

API 17N API


• Find and fix defects that were not or could not be found earlier • Ensure that the functional requirements of the system can be met • Deliver a product which meets the customer’s quality and reliability expectations.

In bringing together the packages, subsystems and components of the overall system the goal is to ensure that all the subsystems fit together as designed and function correctly. Key areas of deviation from design intent relate to form, function, quality& reliability:

• Form: do the components and subsystems physically fit together as designed? • Function: does the system as a whole function as it is supposed to? • Quality & Reliability: will it perform in the specified environmental conditions

Many of the interfacing issues and problem areas should have been already identified and addressed through technical risk assessment of the systems and system interfaces performed during FEED and Detailed Design. However, many early life failures and delays are associated with failures at interfaces (fail to fit or fail to function) between sub-systems and components that are revealed only when tested. The probability of connection/interface failure is generally highest when the components/subsystems to be connected are manufactured at different locations or by different organizations. Thus close attention to supply chain management of the reliability and contracting relationships are crucially important. The R&M focus for the Installation and Commissioning phase is two fold:

1. Reliability of the installation hardware (hardware used to install the subsea system) o Installation hardware functionality o Project schedule impact from installation hardware availability

2. Impact of Installation, hook up and Commissioning processes on

o Subsea system hardware reliability o Project schedule o Installation and commissioning costs

Failure of installation hardware, incorrect procedures (leading to equipment overloads) and human or organizational failures (human errors) made during hardware installation can have a significant impact on the reliability of subsea hardware being installed and on project schedule and cost. Since subsea installation programs may involve large vessels, the financial impact of such failures is often large. It is important therefore to identify and assess the risks involved as early as possible. The most important reliability activities will be:

• Hardware failure modes and effects criticality analysis (FMECA) on the installation hardware • Risk assessment of the installation and commissioning procedures and appropriate follow up

actions. Operators may gain value from involving installation contractors in the assessment of risk and reliability during detail design and manufacturing phases of projects. The relationship between the scheduled installation and commissioning tasks and the key reliability processes is summarized in the table below.

Copyright ©

API 17N API


R&

M re

quire

men

ts

Org

aniz

ing

and

Plan

ning

for R

&M

Des

ign

and

Man

ufac

ture

for R

&M

R&

M A

ssur

ance

Verif

icat

ion

and

Valid

atio

n

Proj

ect R

isk

Man

agem

ent

Rel

iabi

lity

and

qual

ifica

tion

test

ing

Dat

a M

anag

emen

t

Supp

ly C

hain

Man

agem

ent

Man

agem

ent o

f Cha

nge

Ris

k an

d R

elia

bilit

y A

naly

sis

Org

anis

atio

nal L

earn

ing

Key EngineeringTasks Resp. ID Key Reliability Tasks 1 2 3 4 5 6 7 8 9 10 11 12Installation and pre-installation testing

Op S1 Categorize installation at high level (define R&M requirements for installation and testing)

X O O C I I

Op S2 Define initial R&M organization and plan for installation I X O C I

Select and contract equipment and vessels Op S3 Contractor/supplier R&M capability assessment, incorporate any relevant R&M requirements into supplier contracts.

C O C X I I

Define installation testing (SIT) requirements and scope (include in technical / functional specification - FEED); recommended to base closely on actual installation procedures

Op S4 Undertake detailed categorisation and installation FMECA/risk review to establish testing needs based on uncertainty of installation operations (e.g. need for land SIT, or shallow water testing or even trial field deployment)

X O C I O I X I

Op S5 Implement Installation process FMECA recommendations (and any outstanding from design reliability processes and installation test lessons).

X O C C

Op S6 Check acceptance criteria are consistent with R&M Requirements

I O X

Op S7 Implement Installation process FMECA recommendations (and any outstanding from design reliability processes).

X O C I


O X

Op S9 Ensure change control procedures in place C X

Op S10 Review all non-conformances against relevant FMECA and other reliability process requirements.

I I O C X O

Undertake testing Op S11 Feedback lessons learnt O XPost Test punch list Op S12 Verify all tasks complete I XReview Installation Procedures (consider undertaking a paper trial run or simulation of procedure)

Op S13 Validation and verification of equipment and procedures I O X

Undertake Installation Op S11 Feedback lessons learnt C XPost installation punch list Op S12 Verify all tasks complete I O X

Define non-conformance resolution process

Develop installation procedures and acceptance criteria

Develop overall plan and schedule

Define Installation test procedures (SIT; shallow water, field trials etc) and acceptance criteria

Copyright ©

API 17N API


R&

M re

quire

men

ts

Org

aniz

ing

and

Plan

ning

for R

&M

Des

ign

and

Man

ufac

ture

for R

&M

R&

M A

ssur

ance

Verif

icat

ion

and

Valid

atio

n

Proj

ect R

isk

Man

agem

ent

Rel

iabi

lity

and

qual

ifica

tion

test

ing

Dat

a M

anag

emen

t

Supp

ly C

hain

Man

agem

ent

Man

agem

ent o

f Cha

nge

Ris

k an

d R

elia

bilit

y A

naly

sis

Org

anis

atio

nal L

earn

ing

Key EngineeringTasks Resp. ID Key Reliability Tasks 1 2 3 4 5 6 7 8 9 10 11 12

Op S16 Categorize commisioning at a high level (define R&M requirements for installation and testing)

X O O C I I

Op S17 Commisioning Process FMECA or commisioning risk review

O C I I X I

Op S18 Define initial R&M organization and plan for commisioning

I X O C

Op S19 Implement any outstanding actions from project risk and reliability processes and installation lessons learnt.

I X O C I I


I O X O

Review commisioning procedures (consider undertaking a paper trial run or simulation of procedure)

Op S13 Validation and verification of equipment and procedures

I O X

Undertake Commisioning Op S11 Feedback lessons learnt C XPost commisioning punch list Op S12 Verify all tasks complete I O X

Commissioning

Develop commisioning procedures and acceptance criteria

Develop overall plan and schedule

One activity that will help to manage the above risk is a technical risk assessment of systems and interfaces using an appropriate tool (e.g. System and Interface FMECA (SI-FMECA). Risk assessment should be used to identify how the various components and subsystems might fail e.g. through loss of physical, electrical, hydraulic or optical connection or incorrect system logic. Many of the problem areas will have been identified and acted on when the SI-FMECA is carried out. SIT could then be used to validate that the SI-FMECA actions have been implemented as well as reveal faults and defects that have not been picked up or followed up following SI-FMECA. It is generally not possible to include every single package in a SIT and it is often necessary to break it down into manageable tests.

• System Tests from one contractor/supplier and their sub contractors • Integration tests where equipment from different package suppliers are brought together for testing

In defining a SIT it is necessary to specify;

1. Equipment/subsystems to be tested 2. Nature of the test 3. Timing of tests

Functional block testing Topside – subsea hardware integration Topside – subsea software integration

Copyright ©

API 17N API


6.7.3 SIT, Installation and Commissioning R&M Task Descriptions

Define requirements

Categorization


Define plan and organization

Reliability risk review / assessment

Implement recommendations

Check acceptance criteria

Review non conformance

Feedback to lessons learnt

Validate/verify equipment & procedures

Verify all tasks complete

Figure 24: SIT, Installation and Commissioning process flow chart

A-D

Categorize Installation at a high level

S1/KP1/7.1.2

Select installation category that applies to the planned installation as a indicator of risk based on novelty of the installation procedure.

A-D Identify ownership of reliability tasks during SIT

Update R&M organization

S2/KP2/7.2.1.2

A-C

Check acceptance criteria are consistent with R&M Requirements

Validate the test specification to ensure that all of the R&M risks highlighted during past project phase analyses have been suitably accounted for.

S6/KP5/7.5 D Ensure consistency of test specification with past relevant projects.

A-D It is very important that comprehensive change control procedures are in place and that all changes, however small, are adequately documented and all relevant parties informed. It is often minor changes that result in early life failures.

Ensure change control procedures in place

S9/KP10/7.10

Feedback lessons learnt

A-D It is very important that all lessons learnt, both in relation to success or to unexpected failures, are recorded and fed back for organizational learning

Copyright ©

API 17N API


S11/KP12/7.12

A-D Use check lists to verify that all tasks have been undertaken and completed correctly

Verify all tasks complete

S12/KP5/7.5

A-D Categorize Installation at a high level based on environment, location and requirements for technology and reliability stretch

Categorize Installation

S1/KP1/7.1.2

A-C

Identify/Select a reliability lead for the reliability activities throughout Installation. Define outline plan to include procedural reviews and testing.

Define initial R&M organization and plan for Installation

S2/KP2/7.2 D Identify/Select a reliability lead for Installation. For Cat ‘D’ project packages

planning for documentation checks will usually suffice. A/B

The ITT should include a description of the contractor/supplier selection decision making process and the criteria upon which the selection decision will be informed.

Contractor/supplier R&M capability

C The ITT should include a clause stating the expectation of the contractor/supplier to improve procedures/manufacturing processes and provide evidence of such improvements.

S3/KP9/7.9 D Review performance of contractor/supplier from previous relevant projects

A-C

Categorize equipment and procedures

Both equipment and procedures to be categorized with particular regard to environment, technology and people.

S4/KP1/7.1.2 D Use the availability of relevant historical data to verify the categorization.

A For Cat ‘A’ equipment/procedures planning needs to allow for the design, review, manufacture and comprehensive tests needed to take the technology from its current TRL to the target value.

B For Cat ‘B’ equipment/procedures planning needs to allow for the design and review processes together with specific tests to address design changes introduced over base design. Laboratory and field trials may be required to confirm suitability for significantly more onerous environmental conditions.

Update plan

C For Cat ‘C’ equipment/procedures planning should allow for implementation and confirmation of improvements through physical checks of features subject to the manufacturing changes and trials to check enhanced processes.

S2/KP2/7.2.1.1 D For Cat ‘D’ project packages planning for documentation checks will usually

suffice. A-C

Installation Hardware Design FMECA

The task of developing a Design FMECA is the same irrespective of equipment categorization; however, the work should be prioritized by categorization as the highest risk will be associated with Category 'A' and least with Category 'C'.

S4/KP11/7.11 D Verify unchanged design with a review of past relevant Design FMECA

A/B

The task of developing a Process FMECA is the same irrespective of process categorization; however, the work should be prioritized by categorization as the highest risk will be associated with Category 'A/B' processes.

Installation Process FMECA

C Focus Process FMECA on the areas of required process improvement.

S4/KP11/7.11 D Review past project Process FMECA to verify that installation process is

Copyright ©

API 17N API


unchanged.

A-C Validate/verify installation processes and verify equipment to be used to install system functions as specified.

Validation and verification of equipment and procedures

S13/KP5/7.5 D Verify unchanged design with standard test.

A-D Categorize commissioning procedures with particular regard to system complexity

Categorize commissioning procedures

S16/KP1/7.1.2

A-C

Identify/Select a reliability lead for the reliability activities throughout Commissioning. Define outline plan to include procedural reviews.

Define R&M organization and plan for Commissioning

S18/KP2/7.2 D Identify/Select a reliability lead for Commissioning. For Cat D project packages

planning for documentation checks will usually suffice. A/B

The task of developing a Process FMECA is the same irrespective of process categorization; however, the work should be prioritized by categorization as the highest risk will be associated with Category 'A/B' processes.

Commissioning Process FMECA

C Focus Process FMECA on the areas of required process improvement.

S17/KP11/7.11 D Review past project Process FMECA to verify that installation process is

unchanged.

6.7.3.1 R&M assurance, verification and validation The assurance document should be updated and expanded to include or make reference to;

• Installation equipment risk category • Installation and commissioning procedures risk category • Any changes to procedures given the recommendations from the FMECAs • Results of SIT and installation trials. • Review of the analysis of the identified non-conformances • Confirmation of punch list verification.

Copyright ©

API 17N API


6.8 OPERATIONS

6.8.1 Phase Scope Full transfer to operations team from Operator project team occurs here. Previous stakeholders are now offline but may be on call (depending on support contract). It is important that the operational team understand all the design assumptions which might impact on system operations and maintenance activities in service. Any misunderstanding of design assumptions may compromise reliability and increase likelihood of early life failures. During Operations, the field infrastructure should be maintained to deliver the R&M requirements defined during the project design phases.

6.8.2 Description of activities in Operations

R&

M re

quire

men

ts

Org

aniz

ing

and

Plan

ning

for R

&M

Des

ign

and

Man

ufac

ture

for R

&M

R&

M A

ssur

ance

Verif

icat

ion

and

Valid

atio

n

Proj

ect R

isk

Man

agem

ent

Rel

iabi

lity

and

qual

ifica

tion

test

ing

Dat

a M

anag

emen

t

Supp

ly C

hain

Man

agem

ent

Man

agem

ent o

f Cha

nge

Ris

k an

d R

elia

bilit

y A

naly

sis

Org

anis

atio

nal L

earn

ing

Key EngineeringTasks Resp. ID Key Reliability Tasks 1 2 3 4 5 6 7 8 9 10 11 12Start up Procedure Op P1 Start-up Risk assessment C I X IOperations Procedure Op P2 Plan data collection strategy X O C C I

Op P3 Collect R&M data C XOperators feedback to supplier Op P4 Validate R&M requirements I O X C O

Op P5 Qualify packages/components I O X C OOp P6 Re-categorize packages /

components X O C O

Maintenance intervention procedure and acceptance criteria

Op P7 Failure data collection and analysis O C X X O

Op P8 Intervention risk assessment C I I I X I

Field upgrades and expansionOp P9 Implement R&M Strategy as mini-

project C C C C C C C C C C C C The Operations phase is initiated by the start-up procedure which should be defined, reviewed and implemented. The review should be supported with a risk assessment to identify any potential project reliability risks. Data collection may be considered the primary R&M activity conducted throughout the Operations phase; it is vital, therefore, that the data collection strategy is defined and planned prior to the commencement of Operations. The data collection strategy will be dependent on the type of data being collected and the database to which the data is submitted. Note that for continuous monitoring or automated data collection systems, this strategy will have to be addressed during the earlier design phases. The collection of data throughout the Operations phase will allow for the close out of many processes initiated/conducted throughout the previous project phases;

• Package/component qualification: A new application of technology can only attain the highest technology readiness level after a certain period of successful operation. Through the collection of necessary and relevant R&M data, the new technology application can be qualified as fit for purpose for that specific environment and/or application.

• Risk Categorization: R&M data should be submitted to lessons learnt database such that when similar projects arise in the future they can be correctly categorized at a lower risk where applicable. This assumes an acceptable level of ‘successful’ asset management to qualify future similar technical risks at a lower risk category.

Copyright ©

API 17N API


• Organizational learning: R&M predictions made throughout the project should be validated against real R&M data collected throughout the Operations phase. This will enable the verification of the forecasting techniques and, therefore, the increase the confidence of the decision making support processes. Collection of failure data should also support organizational learning processes both in terms of the supplier and operator. The supplier should consider false positive and negative error types in the failure mode prediction activities and the operator should review operational root causes of failure.

Upon the realization of failure intervention may be required; the intervention strategy should observe a definition of requirements and a planning and organizing phase before the implementation of the intervention. The requirements and planning phases should be supported by value based decision making to determine the technology and R&M requirements of the repaired/replaced item. The opportunity may arise at some point during the operational phase for the upgrade or expansion of the field development. If this occurs then the upgrade/expansion should be considered a project in its own right; observing project phases from Feasibility to Installation and eventual operation. The implementation of the R&M strategy for upgrade/expansion projects should, therefore, follow the guidance provided within this recommended practice. Careful consideration should be directed towards the risk categorization of the project. If the hardware is the same as that originally installed then the operator should account for the assurance of it being field proven before categorizing the project at a lower risk category.

6.8.3 Operations R&M Task Descriptions

Plan data collection strategy

Categorization


Start-up risk assessment

Collect failure data

Collect R&M data

Intervention risk assessment

Intervention required

Qualification

Verification and validation

Re-categorization

Failure analysis

Figure 25: Operations process flow chart

Copyright ©

API 17N API


A-C

Start-up Risk assessment

The start-up procedure should be reviewed by formal risk assessment techniques to determine any potential risks to the project reliability. This may be in the form of a FMECA or HAZOP and may be facilitated by a review of past relevant projects.

P1/KP11/7.11 D Reference to a previous start-up risk assessment should be sufficient to identify any

potential risk to system reliability. A-D

Plan data collection strategy

P2/KP2/7.2.1.1

Prior to start up and operations the strategy for the collection of reliability data should be planned. The strategy should enable the collection of data from monitoring, inspection and intervention activities and feedback of information to relevant databases. Note that for automated (continuous) monitoring strategies, the plan will have to be developed during an earlier project phase for incorporation within the design.

A-D

Collect R&M data

P3/KP8/7.8(OR 8.0)

Data should be collected in accordance with the planned R&M data collection strategy. The collection may be broadly grouped into two sections; early life operability and trough life operations. The distinction of early life operability should be made given the financial consequences of early life failures.

A-D

Validate R&M Requirements

P4/KP5/7.5

Data collected during operations should be used to validate the R&M predictions made during the project planning phases and to verify the method by which the predictions were made. The verification/validation process and its outputs should be included within the final R&M assurance document. This is an important task relating to the organization's learning capability and reveals a level of confidence in the forecasting ability of the tools implemented throughout the project.

A-C

Qualify packages / components

Technology readiness level 9 is only achieved (for that condition/application) after a specified period of successful operations. The collection of data throughout the operating period will enable the qualification of the packages / components to TRL=9.

P5/KP7/7.7 D N/A

A-C

Re-categorize packages / components

In the same respect that technology is qualified after a period of successful operation, so the project/package/component risk categorization will tend towards 'D' given successful management of the installation. A period of 'successful management' of the asset should be defined such that the conditions under which the project was planned and executed can be considered of lower risk category should those conditions be realized in another project. This qualifier, and achievement of the qualifier, should be recorded within the lessons learnt database along with the relevant conditions.

P6/KP1/7.1.2 D A Review of the continued applicability of category ‘D’ status for packages /

components should be undertaken. A-D

Failure data collection and analysis

P7/KP8/7.8(OR 8.0)

Particular attention should be directed towards the collection and analysis of failure data. Upon observation of failure(s), the following data should be recorded (annex 1 provides a comprehensive list of the recommended information to be recorded upon realization of a failure); the failed item, the failure mode, the operating conditions and the relative operating life time. Note that the latter may not be the total operating lifetime of the system. A value judgment should be made regarding the implementation of root cause analysis techniques; this may be particularly relevant upon observation of failures during the early life operability period. Records of observed failures should be fed back to the equipment supplier and lessons learnt database.

A-C

Intervention risk assessment

Any maintenance intervention should be subject to a formal risk assessment procedure driven by the technical risk categorization and facilitated by a review of previous relevant lessons learnt. The risk review should identify and address those activities that may compromise the reliability of the equipment to be installed, the reliability of those items interfacing with the installed item and the system reliability. The system restoration process should be determined on a value basis in conjunction with the failure data analysis to assess whether or not the replacement item should be like for like or an up/down grade to ensure that no alterations to the original configuration compromise the R&M value of the installation.

P8/KP11/7.11

D Reference to a previous intervention risk assessment should be sufficient to identify any potential risk to system reliability.

Implement R&M A-D Although not technically a task, it is recommended that any field upgrades or

Copyright ©

API 17N API


Strategy as mini-project

P9/KPALL/5

expansions follow the R&M strategy described within this RP. Note that the risk categorization of the upgrade or expansion will be dependent on the extent to which the asset has been successfully managed. It is recommended that careful consideration be directed towards asset management in the local conditions before assigning the initial risk categorization.

6.8.3.1 R&M Assurance Verification and Validation The collection of real R&M data throughout the project should be reviewed to validate the R&M forecasts and verify the process activities driving the forecasts. The R&M assurance document should be updated and closed out by including the following data;

• Description of the operating system and conditions • Report (and analysis where applicable) of the recorded failures • A report of the validation of the R&M predictions and the verification of those process activities

driving the forecast • Re-qualification of the components/packages • Qualification of re-categorization for future projects/applications

Copyright ©

API 17N API


7 Annex 1: Process Description 7.1 PROCESS 1: DEFINITION OF R&M REQUIREMENTS

7.1.1 Description The definition of R&M requirements is important because it initiates all the other reliability processes described in this RP. Some R&M requirements are needed to initiate the R&M plan and ensure that the project is congruent with overall business performance requirements including financial, environmental, health and safety goals and initiates the process of designing and manufacturing for reliability and maintainability. There are three Key tasks that are relevant to this process and they are linked through the definition of R&M requirements process. They are:

1. Risk Categorization 2. Reliability Value Analysis 3. Defining reliability and maintainability requirements

a. Hardware requirements b. Management requirements

R&M requirements tasks are performed at all project stages and example flow diagrams for the activity are shown in Figure A 1 for the three phases; Feasibility, Concept Design and FEED. The subtasks for risk categorization, reliability value analysis and define R&M requirements are described in sections 7.1.2, 7.1.3 and 7.1.4, respectively.

System Analysis & breakdown

Option Risk Categorization

For each option define system failure logic

Define Field production

profile

Run RAM Analysis

Input failure & logistics data

Option value Analysis

Select best Value Option

Optimise Value Availability

characteristics

ModifyarchitectureDesign for

R&M

Input financial data

Develop Field Development

Options

Categorize Project Risk

Identify high level R&M Strategies

Develop Exploitation Strategies

Project Value Analysis

Define High level R&M Goals

Update to options

FEASIBILITY PHASE CONCEPT PHASE

System Analysis & breakdown

Develop Field Architecture

Package risk Categorization

Define System Failure Logic

Define Field production

profile

Run RAM Analysis

Input failure & logistics data

Development Value Analysis

Output R&M Requirements

Optimise Value Availability

characteristics

Modify architecture, R&M and logistics values

(Design for R&M)

Input financial data

UpdatePackage

risk

FEED

Update R&M Goals

Figure A 1: R&M Requirements Process Flow Chart for Feasibility, Concept Design and FEED

Copyright ©

API 17N API


7.1.1.1 Feasibility Categorize Project Risk: During the Feasibility phase of the project, attention will initially focus on the general R&M approach to be taken in the project. The first step, therefore, will be to perform a project risk categorization. This will primarily focus on environmental, reservoir and project risk issues and will indicate in general terms the need for R&M activities in the later stages of the project. High level R&M Strategy: The next step is to understand the R&M strategy and goals that might be taken. For example, should the project drive for a reliability strategy (which will be more appropriate for a deep water project) or a maintainability strategy (which would be more appropriate for locations where intervention is less expensive)? The value of the strategy would then be examined. Project Value analysis: One approach would be to define a production availability range and a range of expected intervention costs by reviewing the levels achieved in similar field development projects and reviewing the value. This may be performed qualitatively or quantitatively using simple high level spread sheet cash flow analysis for field economics with estimates for availability, typical CAPEX and OPEX. It is recommended that uncertainty analysis is included in the analysis for all R&M model variables at this stage. Define R&M requirements: Decisions should be made to define the overall R&M strategy and approach to be adopted. This should be used to inform the reliability plans. Broad target ranges may be provided for the level of availability that may need to be achieved (to be updated in later phases) with general objectives to create high reliability or maintainability options and to minimize costs.

7.1.1.2 Concept Design System breakdown: During Concept development the main engineering task is to create options for field exploitation. This can be considered a design competition to find the development solution with the best value. As each concept evolves the various high level packages to be implemented will be identified. These can be listed as a tree breakdown structure. Option Categorization: The next step is to categorize the various options these can be regarded as aspirations expectations or as requirements. It should be recognised however, that an aspiration for the options to conform to a particular risk category is no more than an aspiration or an expectation as it is likely that some of the packages may have to be updated to a different risk categories in later project phases. This may have implications for the project management (resources and costs) if an option, initially categorised as ‘C or D’ is subsequently found to include Category ‘A or B’ packages. Some degree of flexibility in budget and resources must be allowed for in R&M planning to accommodate these changes should they be realised. Define system Failure Logic: Analysis is required to model and understand the system failure logic. Various tools may be considered for this including; reliability block diagrams, fault tree analysis, event tree analysis. This should also include the identification of historical failure data to be used. Run RAM Analysis: The RAM model is essentially a production availability simulation employing Monte Carlo Simulation techniques. It is recommended that a high level availability simulation be performed for all options regardless of overall option risk category. A systems availability simulation or calculation may be used as an alternative, however, the latter would not include estimates of production losses, which is critically important to decision making on R&M strategy. Hence the two inputs R&M and logistics data and production profile data. Option Value analysis: Option value analyses are cash flow calculations for each option in which the output from RAM analysis can be used to make informed estimates, specific to a given option, of the OPEX related to hardware failures. This activity enables the team to see the connection between reliability and maintainability specification and financial value (usually defined as NPV). At this stage the availability and value achieved for the best value option can be compared with that obtained in the high level value analysis study performed in the Feasibility stage. This will then determine the extent to which the availability and reliability values for packages will need to increase. Optimize Value-Availability characteristics: The Option value analysis model, once created, enables the team to investigate the relationship between R&M specification and financial value. At this stage the design team may which to make “what-if” sensitivity changes to the option architectures to squeeze the best value from the option.

Copyright ©

API 17N API


Select best value option: This is a straight forward value comparison between the various options. It is assumed in most cases that the option with the highest NPV will be the one selected to progress to FEED. It should be noted that the reliability and value determined here for the option selected may change as the design matures through FEED and Detailed Design. It is therefore important to ensure that the R&M requirements specified in the Feasibility phase, still reflect the goals of the project and update them if necessary.

7.1.1.3 FEED In FEED the design team develops the selected concept into a fully defined system of hardware packages. The focus of the R&M process is therefore to determine the R&M requirements for each package. The process in FEED is similar to that in Concept Design. System breakdown: This is the same activity as that for Concept Design but at a greater level of package detail. Package Categorization: Each package is categorized to determine the level of reliability effort required during in FEED. Note: system R&M modeling effort is recommended regardless of the risk category identified for the constituent packages since even if all the hardware is Category ‘D’, the systems models will be useful for investigating maintenance intervention strategy. Define system Failure Logic: The system failure model for the option selected at the end of Concept Design should be further developed to include blocks corresponding to all the packages to be defined in FEED. The model and all input data should be validated. Run RAM Analysis: The RAM model is run for the updated system to generate data on system failure modes, frequencies, uptimes, down times and production losses. RAM analysis Model Input data

1. C and D category packages: Packages with this level of categorization will, by definition, have appropriate reliability data available. The reliability inputs can be obtained from standard reliability databases, such as OREDA, which publish historically derived failure frequencies for typical components.

2. A and B category packages: By definition historical failure frequencies for Category ‘A and B’ packages will be either unavailable or inappropriate. Additional R&M work will be required to estimate an initial value to input into the RAM analysis model. This may involve further analysis using other models and data e.g. system reliability models, structural reliability models, physics of failure models or test data. Reliability Consultants may be required to advise on this activity.

Development Value analysis: Cash flow calculations are performed for the field development using relevant financial data and the output from RAM analysis to estimate income, OPEX, CAPEX and cash flow. From this the field value (NPV) is determined. Optimize Value-Availability characteristics: The Option value analysis model once created enables the team to investigate the relationship between R&M specification and financial value. At this stage the design team may make changes to the input data, or to system architecture to investigate the relationships between the input R&M, logistics and cost data and the overall value of the development. The tool enables the team to find optimal R&M values. The level of activity at this stage will depend on the package categories. Modelling approach

1. Cat C and D Fields. For Field developments comprising only Category ‘C and D’ items, historical data can be used as input, however, the value or RAM model can be used to investigate maintenance and spares strategy and intervention logistics strategy.

2. CAT A and D Fields: For field developments which include some Category ‘B or A’ packages, the initial data inputs will be a mix of historical data (for C and D packages) and initial estimates of reliability for A and B packages). The Value and the RAM model can then be used to investigate how changes in R&M of A and B packages and intervention logistics will influence field value.

Copyright ©

API 17N API


During this activity the availability and values achieved can be compared with that obtained in the earlier high level value analysis study performed in the Feasibility stage. This will influence the extent to which the availability and reliability values for each package will need to increase. Output R&M options: The model input data which gives the best value can be used as the basis for the R&M requirements. These requirements should be checked and validated before submission to package suppliers.

7.1.2 Risk Categorization This is one of the first and most important tasks to be performed in a field development project. It is first performed when a new project phase is initiated and is continually updated throughout the project life cycle. It is essentially a qualitative risk review used to relate the level of risk in the project and hardware packages to the reliability effort in the project. It is the critical task in defining the scope of reliability work especially in FEED and is recommended for all projects regardless of scale, complexity and technology. Risk categorization is based on the matrix shown in Table A 2. There are four risk categories A, B, C and D (rows in Table A 2) and there are five change risk factors (column headings in Table A 2), labelled as Reliability, Technology, Environment, Architecture and Organization. The specific meanings of the change risk factors are defined as 1 Reliability The extent to which reliability must be stretched to meet the overall aspirations and

goals of the project 2 Technology The extent to which new technology has been or is planned to be introduced to

exploit the field 3 Environment The extent to which the operating envelope will stretch reliability, technology,

architecture and organizational complexity 4 Architecture The extent to which the field development system architecture has changed or is

planned to change 5 Organisation The extent to which the organization complexity has changed or is planned to change The scope and interpretation of the categorization process changes as the project progresses through the various life cycle phases. These changes in perspective are outlined below in Table A 1. Life cycle Phase

Focus Perspective Description

Feasibility Project

Aspiration or Requirement

Project is categorised largely on the Envelope factor Information available at this stage is largely limited to knowledge of the environmental conditions, field location and reservoir characteristics. Technology, reliability, system architecture and organisation complexity risk categories at this stage are largely undefined (note 1)

Select Option

Aspiration or Requirement

Options are categorised on all five change risk factors. At this stage the technology is largely undefined. The risk category assigned is either an expectation or an aspiration for the risk categories for the packages which comprise the option (note 2)

FEED Package

Specification/ Identification

Packages are categorised on all five change risk factors. As the various packages are defined Each package is categorized at the level of risk that is required for the package in this project (note 3)

Detail Design Component

Specification/ Confirmation/ Identification

Packages categories are updated on all five change risk factors. At this stage the technology is being specified. Each package is categorised on risk expectation (note4)

Installation Installation hardware

Specification/ Identification

Hardware is categorised on all five change risk factors Installation hardware should be categorized together with hardware to be installed (if not already categorized in detail design)

Table A 1: Focus for Risk Categorization

Copyright ©

API 17N API


Notes 1 Feasibility: If the Operating envelope is categorised as ‘C or D’ at this stage, it should be regarded

as an aspiration, expectation or requirement for the change risk factors in Table A 2 to remain at ‘C or D’ throughout the next phase of the development programme. It must be clearly recognized however that this may not be possible as project assigned a risk category of ‘C or D’ during Feasibility is likely to change to a higher category during later project phases as more technical details become available. If operating envelope is categorised ‘A or B’ then the team expects the change risk factors; technology, reliability, architecture and organisation to reach A or B in later phases of the project

2 Select: An option categorised as ‘C or D’ in Select can be regarded as an aspiration, expectation or requirement for the package risk to remain at either C or D throughout the next phase of the development programme. An option categorised at ‘A or B’ in Select is a recognition that the environment may well push the package risk categories to a level ‘A or B’ for this option

3 FEED: The focus shifts to packages and the risk category perspective changes from “aspiration” to “requirement”. However, risk categories assigned at this stage may need to be updated in subsequent phases.

4 Detail Design: In most cases categorization will confirm the package risk level defined in FEED unless detail design indicates that the package risk category should change.

5 Installation phase: categorization should only address the hardware used to install the subsea production equipment unless subsea production hardware has not been

The overall risk category for any project/package/component is determined according to the highest change risk factor and is best determined through peer review and agreement. As this is such a key element to successful implementation of the projects reliability strategy it is essential that every aspect of the project is considered thoroughly and objectively with full justification for each category and sub category. The four risk categories are as follows:

A. Category ‘A’ if any of the following apply: a. New or novel technology b. Very complex system architectures c. Significant reliability improvements are required which can only be addressed by

developing new technology.

B. Category ‘B’ if any of the following apply: a. Equipment is none mature if used under extended environments (e.g. water depth and

temperature) or extended operating conditions (e.g. temperature pressure and compositions)

b. Project involves large systems and has a large or complex management organisation. c. Hardware is safety critical d. Significant Reliability improvements are required by the customer (even if product is

considered mature) and which demands attention to both product design and manufacture

C. Category ‘C’ if any of the following apply: a. Field proven equipment in a similar operating envelope to previous projects but with

minor interface changes and minor team changes b. Moderate reliability improvements required which can be addressed by improvements to

the manufacturing process

D. Category ‘D’ if any of the following apply: a. Field proven equipment in same configuration and similar operating conditions as

previous projects. b. Existing historical reliability performance is acceptable

Copyright ©

API 17N API


In defining the risk category it is important to start the categorisation process with a Category ‘A’. If none of the criteria at this level are applicable, move to Category ‘B’ and check the criteria at this level. Continue down until A, B and C criteria have been exhausted. The criteria to be applied are:

1) Reliability stretch 2) Technology 3) Operating and environmental conditions 4) Technical scale and complexity 5) Safety 6) Organisational scale, complexity and changes

Copyright ©

API 17N API


Cat Reliability Technology Environment Architecture Organisationkey words

Reliability requirementsSystem reliabilityMaintainabilitySystem availabilityProduction availabilityFailure modesRiskUncertainty

MaterialsDimensionsDesign lifeDesign conceptLoadstress, temperature Limitsduty cyclefatiguecorrosionStress corrosion cracking

Field locationwater depthseabed conditionsReservoir size Pressure,TemperatureFluids compositionTransportationHumidity (topsides elements)Environmental loadingsCurrentsTest Location

EquipmentLayoutInterfaces, ComplexityDiver/ROVDeployment/interventiontooling

CompanyContractorSuppliers- Supply chainOperations LocationDesignManufactureInstallOperateMaintain

D

Unchanged Reliability:No reliability improvements required and existing quality control in manufacture and assembly is acceptable

UnchangedSame supplier providing equipment with identical specification, manufactured at the same location.Assurances prpvided that no changes have occurred throughout the supply chain

Same environmental conditions: Same as recent project. Lessons learnt have been obtained and MoC on system is zero

Unchanged:Architecture is identical to previous specifications. Interfaces remain unchanged, with no orientation or layout modification.

Same team as previous: Same Operator project team, contractors, suppliers and supplier’s -supply chain. Applies throughout CVP from appraise to operate and IMR

L

Low budget low risk package using field proven equipment in same configuration and similar operating conditions as previous projects. Hardware is non safety critical. Existing hsitorical reliability performance is acceptable

C

Minor Reliability improvements:Reliability Improvements requiring tighter control over quality control during manufacturing and assembly

Minor modifications:Same supplier providing essentially a copy of previous equipment with minor modifications such as dimensions or design life. Modifications have been fully reviewed and qualified where appropriate

Similar environmental conditions: Same as a previous project or project team has, by means of a design review, identified no major differences that have flagged a risk.

Interface changes: Architecture has minor interface changes, either with different equipment or control system changes. Where appropriate configuration has been tested and verified.

Minor team changes: Small to medium organization. Moderate complexity. Minor team changes in contractor/supplier

L - M

Low to moderate risk package using field proven equipment in a similar operating envelope to previous projects but with some system and organisational complexity. Hardware is non safety critcal. Moderate reliability improvements required which can be addressed by improvements to the manufacturing process

B

Significant Reliabiliity Improvements: Reliability improvements requiring changes to the design but not a change to the technology

Major modifications: Known technology applied, but with major modifications such as material changes, conceptual modifications, manufacturing changes, or upgrades. Modifications have been fully tested/qualified. Non mature for extended operating environments

Significant environmental changes: Many changes noted. Extended aggressive Operating environment. Risk requires additional review.

Orientation and capacity changes:Significant architectural modification such as size, orientation and layout. Changes have been fully reviewed and tested where viable. Large scale High complexity.

Significant team changes: Project is working with new supplier or contractor within supply chain. Key technical personnel changes during project. M - H

Moderate to High risk package using either none mature equipment or with extended operating conditions. Project involves large, complex systems and management organisation. Hardware is safety critical. Significant Reliability improvements required which demand attention to product design and manufacture

A

Significant Reliability Improvements:A significant reliability improvement demanding a change to the technology involved

Novel technology or New design concepts:Novel design that has been proven in field trials or testing up to TRL 5

New Environment: Project is pushing environmental boundaries such a water depth, pressure, temperature, new part of world, severe meteorological conditions or hostile on land test location.

Novel application: Architecture has not been previously applied by company

Whole new team:New project team working with new

suppliers in a new location. H

High risk package using new/novel technology in a new or different system architecture. Significant reliability improvements required which can only be addressed by developing new technology

Change Risk Factors Risk Criticality

Safety Critical hardware: Any items classed as safety critical should be assigned to at least category B Table A 2: Risk Categorization Matrix

Copyright ©

API 17N API


This key task acknowledges that some projects require significant levels of reliability effort, in analysis, testing and design work, while others will require minimal design effort. The matrix can be used to determine the technical risk category for the project at the following stages.

Overall Project Level Feasibility stage Field development options level Concept Design Package Level FEED Component Level Detail design Manufacturing systems Manufacture assembly and test Installation hardware Installation and Commissioning

Table A 3: Categorization application throughout project phases

7.1.3 R&M Value Analysis R&M value analysis is performed in conjunction with defining the R&M requirements. The purpose of the analysis is to assess the value of improving the reliability of particular packages in a system. This requires an assessment to be made of the CAPEX, OPEX and Income arising from production and its dependence on reliability, maintainability and intervention logistics.

The reliability of hardware packages has significant impact on operational expenditure. Package reliability improvement will decrease OPEX, decrease deferred production losses and hence increase field value. Set aside from this there may be increased capital costs associated with realising reliability improvements. For example additional costs may be incurred in performing analyses, tests and making product improvements.

The Value Analysis task can be undertaken either qualitatively or quantitatively and provides a means for cost benefit assessment for the following decisions:

• Technology selection

• Investment in R&M activities

Qualitative assessment of value based decisions can be conducted as part of a group discussion with expert judgment and lessons learnt as the primary inputs. It may be helpful to rank each options cost and benefit on a scale and plot on a matrix.

Quantitative R&M value analysis provides a means of assessing the system architecture, over the project life cycle, in terms of the financial risks attributed to either complete or partial failure of the functional requirements. The economic risk associated with the technology is determined by combining conventional discounted cash flow analysis with a system reliability assessment. Determination of the annual cash flow requires an annual income and expenditure. By implementing an availability model with a production function the annual revenue stream can be determined. In order to generate the annual expenditure a model is required to track failure events and assign failure cost data. Reference should be made to ISO 15663-2, which provides guidance on the financial evaluation techniques.

Determining the financial resources available for the R&M activity investments is achieved by assessing the operational losses. By discounting these losses to the time at which the investment is to be made, the maximum available resources are determined. The investment is determined by front loading the losses incurred during operation as an R&M investment. The available financial resource is dependent on two primary factors; the extent of the reliability improvement and the financial metric implemented.

Once the maximum available resource has been determined it can be allocated amongst the R&M improvements. In allocating resources, careful consideration should be directed towards the reliability capability maturity of the organisations (operator, contractor and/or vendor) undertaking the R&M activities as this may determine if the reliability improvements can add value.

Copyright ©

API 17N API


7.1.4 Setting R&M Requirements

R&M requirements are needed to initiate the R&M plan and ensure that the project is congruent with key business performance metrics (e.g. financial, environmental, health and safety). The requirements will direct the project strategy towards reliability or maintainability. Metric Description Availability Directly related to the system’s ability to generate revenue. When addressing

‘Availability’ it is vital to define which availability the measure is referring to as there application will return different inherent values.

Maintainability Maintainability metrics are targeted to increase the time in which the system exists in the operational (production) state.

MFFOP This metric is often employed to specify, with an acceptable probability, that no system failures occur over the early life period.

Reliability Reliability targets prolong the system life, thus reducing the impact of early life failure.

Reliability capability maturity

This targets the commitment of vendors, contractors, or project engineers to the delivery of improved reliability.

Table A 4: R&M performance measures Depending on the perceived risk of the project, the requirements can be based either on historical benchmark performance, for lower risk projects such as Category ‘C and D’ packages. For higher risk, Category ‘A and B’ packages, reliability requirements will be based on reliability allocation techniques. For numerical definition of requirements, the task is closely linked with R&M Value analysis and some reliability analysis techniques; importance analysis tools can identify which components to focus on when stating reliability improvement targets. Setting reliability requirements is driven first by the definition of the operating system (e.g. ambient conditions, operating lifetime, production fluids, etc.) and failure events that may represent a risk (e.g. loss of production capacity, loss of production fluid to the environment). For each failure event, the consequences should be determined and an acceptable probability of occurrence defined given the consequences. Setting maintainability requirements is initiated with defining the failure events that necessitate intervention and the environment in which the intervention will occur. For each failure event, the cost and intervention requirements (e.g. spares and support vessels) should be determined and the tradeoff between preventative and breakdown maintenance assessed. In addition to setting product requirements, there are also requirements relating to the management and organization of the project. These may be specifying reliability capability maturity levels (see Process 9: Supply Chain Management) or initiating a management of change protocol (see Process 10: Management of Change). Note: Further details to be provided regarding the definition of R&M requirements during Detailed Design and the Installation phase.

Copyright ©

API 17N API


7.2 PROCESS 2: ORGANIZING AND PLANNING FOR R&M Implementation of process 2, “Organizing and Planning for R&M”, is extremely important through all project phases. It is recommended that this key process is always implemented regardless of the project risk category and is updated at the start of each project phase. This section of the annex provides a description of the process.

7.2.1 Description As a general rule, it is important for the project execution plan to define and then assign resources to the reliability activities required throughout the project even when the level of effort required is small. The reliability tasks identified should be considered an integral part of the engineering process and integrated with conventional engineering tasks in the project management system. The purpose of the organizing and planning process is to allocate leadership and resources to the required R&M activities such that they add value to the project overall and do not adversely impact on the project schedule. In planning for R&M it is helpful to understand that the greatest value is achieved when: 1. The R&M process is championed by, and has the full support of, senior management 2. Delivery manager and team are “rewarded” for achieving R&M goals that deliver optimal value 3. R&M strategy and reliability performance requirements are addressed early in the design process 4. Sufficient resources (manpower, tools and time) are allocated to reliability tasks 5. Analysis is timely, quick, effective and most importantly informs decision making 6. Design teams have good capability in “design for reliability and maintainability” 7. Project plans and resources are flexible and enable R&M actions to be implemented and followed up.

7.2.1.1 Planning for R&M Reliability planning starts at the Feasibility stage of a project and is continuously updated through all project phases over the whole life cycle of the field development. Reliability Plans should typically include the following information:

• The relevant risk categorization • R&M requirement • Required activities (e.g. analyses, tests, design changes) • Resource and schedule demands • Ownership (see below) • References to internal/external standards and or practices

The plan should support the construction of the R&M Assurance documentation (see Process 4: Reliability Assurance) as it stipulates how R&M value is delivered and demonstrated. This process includes both planning the activities to deliver R&M value and allocation of tasks to task owners and participants. The planning process is driven by the project R&M requirements (Process 1: Definition of R&M Requirements). The R&M strategy and R&M requirements will determine where attention to reliability must focus and what analyses, simulations and tests may need to be performed. The level of detail and required resources will be determined in particular by the risk categorization task (Process 1: Definition of R&M Requirements). During allocation of reliability effort to specific R&M tasks, reference should be made to the importance of each task and the project risk category. Adequate resources must be allocated to activities to ensure satisfactory completion. As the level of detail increases and the risk category increases so the planned effort for each task will increase; this is observed both in terms of time to completion but also a shift towards increasingly more quantitative activities (Table A 5).

Copyright ©

API 17N API


Cat Nature of assessment work Effort Expectation A Quantitative Very high B Mostly Quantitative/some qualitative C Mostly Qualitative/ some quantitative D Qualitative Very low

Table A 5: Guidance on the level of effort required for R&M effort Once the level of effort required and resources available for each task have been defined, the plan can be formulated with the aid of conventional project management tools and practices. BS 6079:2002 provides an overview of project management techniques that can be adopted for the purposes of constructing the plan. For R&M planning the following guidelines are recommended:

1. Operators should initiate reliability plans as early as possible in Feasibility and Concept Design phase. In later phases (e.g. after Concept) plans should be adopted by contractors in consultation with the operator.

2. Planning follows initial R&M requirements definition 3. Plans should be updated during concept selection, FEED, detail design, manufacture and

Installation as the project progresses and details are defined. 4. Reliability plans for a given phase may require actions to be initiated in an earlier phase and then

updated during the active phase. For example it is recommended that installation contractors are included in design reviews during FEED or detail design, installation plans and risk assessments should be performed in advance of the Installation phase e.g. during detail design or manufacture.

5. Planning should anticipate that as the project evolves, unexpected failure modes and the need for further analysis may be required. Likewise package risk categories may change as project progresses from Concept Design to FEED and then to Detail design. The plan must therefore be flexible, updatable and, where necessary, appropriate change actions enforced.

6. The plan should a. Identify how the R&M will be understood and demonstrated through the project life. b. List all R&M activities that have been identified as necessary for the project, through all

phases, with appropriate schedules, deliverables, milestones and resources allocated as appropriate.

c. Anticipate that during each phase there will be some re-categorization of the project or package that may lead to new requirements/component and may create new R&M activity requirements

d. Reflect the technical risk associated with the project and that it is being properly implemented.

e. Allocate sufficient resources to the initial categorization and reliability goal setting tasks. f. Be updated and issued periodically as new tasks (to be performed) or unnecessary tasks

(to be deleted) are identified and defined in more detail. 7. The document should include sections describing:

a. The reliability team and the roles and responsibility of the delivery manager and the discipline leaders

b. The project/package/component categorizations at each phase of the project c. The R&M requirements for the project, including both process and product requirements d. References to procedures or procedural requirements that should be followed in order to

adhere to company requirements for: i. Reliability Analysis

ii. Project Risk Management iii. Management of Change

Copyright ©

API 17N API


iv. Supply Chain Management v. Lessons Learnt

8. The reliability plan should include clear estimates of durations, costs and resources required to implement the necessary activities.

9. The reliability plans should be formally integrated with the design schedule.

7.2.1.2 Organizing for R&M There are various approaches that may be adopted in organizing for reliability. This will depend, amongst other things, on the size and scale of the project and the Operator preferences. The following provides some guidance on the task of organizing for R&M. Three key questions arise when considering organizing for R&M:

• Who will be responsible for ensuring reliability achievement? • Who will perform the analytical work? • Who will be responsible for coordinating R&M activities?

As a general guidance, responsibility for ensuring reliability achievement should reside with the same Senior Managers responsible for ensuring the delivery of the subsea system to time and budget. Analytical tasks and co-ordination of reliability activities may be outsourced to reliability specialists if there are insufficient internal resources. However, it is crucially important that

• Reliability activities are fully integrated with engineering activities • Analytical tasks inform design decision making • Reliability decisions are followed up, acted on and closed out in a timely manner

It is helpful to assign ownership to each of the R&M activities/tasks and to delegate responsibility for the implementation of the R&M activities. For a small project a centralized approach may be acceptable. For a large project, with a large design team it will be necessary to assign specific areas of reliability responsibility and task ownership at the various levels of technology indenture depending on the project phase. For example, the overall project manager may own the project R&M processes at Feasibility and Concept Design stage but once the project has progressed into FEED, package engineers can own the relevant R&M processes. All of the upcoming R&M tasks should be resourced with the necessary and relevant expertise. For those R&M tasks that directly relate to or extend from existing engineering/business/organizational practices, the task should be resourced according to current organizational protocols with facilitation from a reliability specialist where necessary. For example, selecting a vendor would normally involve communication between operator and supplier; in order to account for reliability capability within the decision making process, support from a reliability specialist may be required. Where a task relates to a specific technology package, but not necessarily an existing engineering/business/organizational task, the package engineer should assume ownership with support from a reliability specialist where necessary. For example, technology risk categorization may be considered a new task; in this case, during FEED, the person(s) assigned ownership of the subsea control systems should undertake the risk categorization with support from a reliability specialist as necessary. The following are examples of special reliability roles which Operators Design Contractors and suppliers may consider as part of their R&M organization.

• R&M Champion

• Reliability delivery manager

• Specialist Reliability Engineer

• R&M Assurance manager- This person would own of the R&M assurance documentation and be responsible for compiling all R&M assurance data from the individual packages.

• R&M validation and verification authority

Copyright ©

API 17N API


These staff should be integrated into the overall engineering team but would have specific roles to play. For some projects the reliability specialists may have other important engineering roles in the project or may have a combined reliability role (more than one of these R&M roles)

The R&M champion would ideally be a senior manager with authority and influence. His role would be primarily that of advocate and high level R&M problem solver. He would not necessarily be the person in control of the project. The reliability delivery manager would ideally be the subsea system delivery manager and be responsible for ensuring that adequate resources are available to meet reliability, cost and schedule requirements. However, he may delegate responsibility for meeting specific package reliability cost and schedule requirements to package leaders who would be responsible for managing the R&M activities in their area of responsibility but not necessarily perform them. For example, the lead pipeline engineer should own all of the processes associated with the R&M of the pipeline, but would not necessarily be responsible for performing all specified R&M activities. R&M modeling of the pipeline, for example might be contracted out or requested from the supplier. A specialist reliability engineer will often be required to support projects. He will have specialist knowledge of tools and analytical techniques. He will often combine good statistical and mathematical skills with knowledge of engineering hardware and failure mechanisms. His role is one of owning the tools and data and facilitating R&M analysis (e.g. FMECA) and modeling (systems reliability models) R&M Assurance manager may be appointed take responsibility for collation and integration of all relevant project R&M outputs and its compilation into the reliability demonstration document. This may be performed by internal project staff or may be outsourced to specialist reliability consultants. R&M Verification and Validation authority: This may involve internal staff or may involve independent external consultants.

Copyright ©

API 17N API


7.3 PROCESS 3: DESIGN AND MANUFACTURE FOR R&M

7.3.1 Description Delivery of a reliable subsea system will require attention to the process of “design and manufacture for R&M” through out conceptual design, FEED, Detailed Design, manufacture and assembly. It should be considered an extension of good engineering practice but will require increased focus on understanding how and why failures occur in operation.

Given the information gathered during risk categorization, reliability value analysis, Reliability analysis and modeling, risk based decisions should be made regarding the design and its ability to achieve and deliver the specified R&M requirements. During the definition of R&M requirements it will also be necessary to determine whether the design focus is to be primarily reliability or maintainability or some combination as this will help prioritize design decisions.

7.3.1.1 Design for R&M

A reliability focused design attempts to reduce the probability that a system will fail during the operational time in the specified operating conditions. Different design actions may be taken at different stages in the design process. For example during Feasibility and Concept Design development phase, the focus will be on the overall system architecture with little consideration for the inherent reliability of specific packages and components. During FEED designers attention will focus on system reliability and the identification of system failure modes and cut sets. At this stage consideration should be given to redundancy and system common cause failures. In detail design, manufacturers and suppliers will drill down to component level failure modes. At this stage more information should be available to identify common cause failure mechanisms and component failure mechanisms.

Examples of design for reliability considerations include:

• Eliminating known failure modes • Improvement of interface reliability • Introduction of redundancy • Reducing the probability of failure mode occurrence • Removal of all common cause failures or reducing their probability of occurrence • Simplification of the system and parts count reduction

At component level design for reliability considerations include

• Mechanical load and stress reduction (e.g. removal of stress raisers) • Increase mechanical strength (e.g. by selection of stronger materials) • Fatigue resistance • Corrosion and stress corrosion cracking resistance • Thermal stress and thermal fatigue • Etc.

Reliability analysis will provide useful support to engineering decisions. For example, systems reliability and value analysis can be used to help decide on the approach to reliability improvement, e.g. whether to adopt a redundancy strategy or whether it is better to select a more reliable supplier of a component.

For failures at component level, physics of failure and stress-strength interference models may be employed to support design improvement decisions. These tools are often more appropriate to support product development and qualification testing.

A maintainability focused design will attempt to improve the ease with which the system can be retained in, or restored to, a production state. Examples of design for maintainability considerations include:

• Enable system inspection and condition monitoring • ‘Hot’ intervention • Improve interface accessibility

Copyright ©

API 17N API


• Introduce modular design • Introduce redundancy • Reduce interface complexity • Spare part inventory

RAM analysis tools will be useful in supporting design decisions aimed at reducing system down time.

7.3.1.2 Manufacture for R&M

It is critically important that the design reliability is not compromised during manufacture and assembly of subsea packages. Manufacturing protocols should be adopted to ensure the delivery of the design reliability. When specifying the manufacturing protocols, the following acceptance methods should be considered;

• Burn-in • ESS (Environmental stress screening) • FAT (Factory acceptance testing) • HALT (Highly accelerated life testing) • HASS (Highly accelerated stress screening) • Material properties • PFMEA (Process failure modes and effects analysis) • Screening (100% product testing) or monitoring (sample testing) • Seal integrity (leak tests) • SIT (Site Integration Testing) • SPC (statistical process control) • Thermal cycling • Tooling tolerances

The output from this process is closely linked with R&M assurance and R&M qualification testing. However, this process also introduces an iterative loop into the design process. Any alterations to the design resulting from this process should be subject to a re-assessment

Copyright ©

API 17N API


7.4 PROCESS 4: RELIABILITY ASSURANCE

7.4.1 Description Reliability assurance is the process of collating, assessing and communicating reliability information in a formal document. This information is generated during a field development project so that the end customer has the best possible indication at any stage during the project of the system’s current and eventual technical effectiveness The key output from the reliability assurance process is the reliability demonstration document (RDD). The purpose of this document is to provide the customer with evidence of progressive achievement during the project. The RDD document is a living document in that it is initiated at the Feasibility stage of a project and is continually updated throughout the various project phases up to and including the operate phase.

Evidence type Comments Current field data

The most reliable data. However, the frequency with which data is received and the accuracy of the data collection method will influence the decision making process and the available action time.

Test/Trial data Trial data can more closely replicate actual conditions in comparison to previous use data that has been modified.

Previous use data This is possibly the most abundant data, especially for mature technology. However, close attention should be directed towards the relevance of the data (e.g. the ambient operating conditions) when making reliability predictions.

Simulations Can provide useful insights that may have otherwise been overlooked. However, output generated is susceptible to model complexity and the quality of the input data.

Calculations Can provide a high level indication of the target metrics but won necessarily accommodate uncertainties relating to the input data.

Expert opinion Although this data is sometimes valuable, care should be taken when defending assertions based on this data alone as it may be subject to biases and flawed perceptions.

Table A 6: Types of R&M Assurance evidence The RDD may comprise of a number of documents from a variety of sources but they should all include the following information indicated in Table A 7, which may be implemented as a guide to the construction of an RDD:

System Description The operating environment, project goals and system layout should be defined as part of pre-existing project documentation and so can be references as an external document.

R&M Requirements Include the R&M requirements defined for the system/package/component/activity, including the associated risk categorization.

R&M Plan The strategy defined to deliver the R&M value can be fed directly into the assurance document.

R&M Evidence Present the results of any R&M activities implemented as part of the project. [Table#] provides some guidance on the different types of evidence that may be generated.

R&M Claims Any R&M value claims made on the basis of the R&M evidence should be included.

Limitations on Use Some activities will have determined the operational envelop or operational conditions that prevent the confident delivery of R&M Value. These conditions should be stated here.

Conclusions and Recommendations

Initial conclusions and recommendations for future R&M activities are specified here.

Table A 7: Suggested constituent parts of an R&M Assurance document

Copyright ©

API 17N API


7.5 PROCESS 5: VERIFICATION AND VALIDATION Validation and verification address two fundamental questions with regard to the R&M strategy:

• Validation – “Are the correct R&M activities being implemented?” • Verification – “Are the R&M activities being implemented correctly?”

The process is complementary with regard to the other processes within the R&M strategy as it serves to check the application of all processes/tasks/activities. It is an important process, therefore, when considering the confidence and value of the evidence presented within the R&M assurance documentation. Validation and verification should be conducted via peer review independent to the project delivery team. Note that this does not necessarily mean that the validation and/or verification authority should be an external organisation. During the organization and planning for R&M, the validation/verification authority should be identified for each of the key processes. The table below indicates the verification/validation activities required for each of the key processes. The importance and required effort of this key task increases with the associated level of risk. All processes and tasks should be verified to ensure that they have been implemented correctly.

Key Process Verification Validation 1. Define R&M Requirement Categorization X X R&M Value Analysis X X Define R&M Requirements X X 2. Organizing and Planning for R&M Organizing for R&M X Planning for R&M X 3. Design and Manufacture for R&M X X 4. R&M Assurance X 6. Project Risk Management X 7. Reliability and Qualification Testing X X 8. Data Management X X 9. Supply Chain Management X 10. Management of Change X 11. Risk and Reliability Analysis X X 12. Organizational Learning X

Table A 8: Recommended verification and validation of the key processes The specific sorts of questions that could be addressed during the validation process are presented below:

1. R&M Value Analysis a. See questions for risk and reliability analysis

2. Design and Manufacture for R&M a. Are suitable reliability improvement techniques being implemented? b. Are appropriate maintainability designs theories being considered?

3. Reliability and Qualification Testing a. Is the correct test being specified given the desired results of the test?

4. Data Management a. Are suitable data elicitation techniques being applied? b. Is data being stored and handled correctly?

5. Risk and Reliability Analysis a. Is the correct analysis tool being implemented given the required results? b. Is the model being populated with the right data?

Copyright ©

API 17N API


7.6 PROCESS 6: PROJECT RISK MANAGEMENT

7.6.1 Description

All field developments are created in a project environment and involve risk. These risks must be managed and reduced to an acceptable level if the project is to be a success. While there are many areas of risk that are relevant to projects the traditional dimensions of subsea project risk management are schedule, cost and safety.

The primary reason for including project risk management as a key R&M process is the need to ensure that there is an acceptable balance amongst the key project drivers, namely; reliability, cost and schedule. For example actions taken to reduce CAPEX and time to first oil/gas may adversely impact on OPEX. Likewise over expenditure of effort to improve reliability may not yield overall value if CAPEX cost increases outweigh the benefits of reduced OPEX.

Note: Here CAPEX is taken to mean the overall cost of design, engineering, procurement, manufacture, test, Installation and Commissioning, including R&M costs and OPEX is taken as the overall cost of operating and maintaining the system.

A balanced approach is needed. While project costs and schedules will be very carefully managed in most projects, realization of faults and reliability problems late in the design process will lead to more rapid escalation of correction/rectification costs than those found early in the project. This illustrates the important principle of front loading the design effort to identify assess and act on potential system and package failure modes at the earliest possible time in project.

There is a variety of project risk assessment methods, which have varying degrees of detail. Two levels of project risk assessment are recommended here;

• Formal project risk analysis • Risk review

7.6.1.1 Formal Project Risk Analysis A good project risk management methodology will enable the project team to assess the impact of R&M activities on project risk during development. Typically this might involve the following stages:

• R&M Task analysis • Identification of project risk and consequences • Risk - Response analysis

The first step is to list all the R&M tasks to be performed that are known at that time. The next step is to identify and list the risks that the task creates for the project and then to assign a category to each risk. Typical project risk categories include:

• Cost • Schedule • Safety • Supply chain

Once the risks have been identified appropriate responses can be developed and actions assigned.

7.6.1.2 Risk review The project risk review should be undertaken at the start of each project phase to support the technology risk categorization and planning tasks. The purpose of project risk management is to identify and assess the risks to the identified project activities. Of key relevance to the reliability achievement is the recognition of project risks that could impact on reliability (e.g. due to pressures on schedule and budget). Project risk reviews should be considered a component of good project management practice; reference

Copyright ©

API 17N API


should be made to the relevant in house documentation. Alternatively, reference should be made to IEC 62198:2001 for guidance on the application of project risk management.

Copyright ©

API 17N API


7.7 PROCESS 7: R&M QUALIFICATION

7.7.1 Description The qualification process is the means by which systems are examined and evidence is provided to demonstrate that the technology employed meets the specified requirements for the intended use. The qualification process is, therefore, first introduced during FEED when package reliability requirements are specified. The package risk categorization and technology readiness level (TRL) are complementary. Low risk (Category ‘D’) projects by definition are implementing field proven technology and as such the required TRL is level 7. Similarly, it is not possible for novel technology (risk Category ‘A’) to be field proven and so the highest TRL that the package can require is level 6. The recommended TRL for a specific risk category is suggested below:

Risk Category Required TRL A 6 B 6 C 7 D 7

Table A 9: Minimum required TRL for each risk category If the technology is not at the required TRL for the specific project application, then the qualification process must be defined to achieve the required TRL before the package enters operation. The qualification process as it commences during FEED will be aimed at assessing the technology readiness level of each of the packages. Package TRL can be determined from the following key processes:

• Organizational learning – A review of lessons learnt from previous projects can determine if a specific package has field life history (defines TRL 5) with relevant ambient stresses (defines TRL 6 or 7 depending on operational lifetime).

• Data Management – The existence/availability of appropriate field data for the package (defines TRL 5) in the relevant ambient stresses (defines TRL 6 or 7 depending on operational lifetime).

Note that this means that any given package can have multiple TRLs depending on the required application and stresses and may be comprised of components with differing TRLs. For example, a gate valve that has a sufficient proven track record within a certain ambient environment and with a specific duty cycle will have a TRL of 7. Placing the same hardware in a different operational environment and subject to, say, a different maintenance policy will alter the environmental stress as well as the duty cycle; this may result in a reduced TRL depending on the effect of the change in the stresses. To determine if the changes in stresses have altered the TRL, risk/reliability models should be constructed and analyzed; physics of failure models may be particularly useful to determine the effect of the altered stresses on the reliability. If hardware exhibits a TRL less than the specified requirement than a qualification testing procedure should be defined to raise it to the required level. Qualification testing provides a physical examination of any materials or equipment that is intended for use during a subsea project. The output generated is fundamental to the R&M assurance documentation as this represents the generation of the highest quality data aside from current field data. Qualification testing can also provide a means of verification and validation of some of the risk and reliability modeling and analysis activities. Within the qualification process, there are three main purposes of testing

• Testing to demonstrating the functional requirement • Testing to screen out faults and manufacturing/assembly defects • Testing to improving robustness and reliability

Functional tests are perhaps the most common but have limited ability to assess the reliability unless the test is replicated. This test can also identify if tooling tolerances established during manufacture and assembly are sufficient so as not to prevent component functionality. Sometimes the test method will have

Copyright ©

API 17N API


been predefined in a (company) standard. If the test method has not been agreed then the test program will need to be defined and validated. The design of the test program should be based on a clear understanding of the failure mechanisms expected for the operating conditions to which the product will be exposed. When testing to improve robustness and reliability, the test should be designed to cause failure, which in turn allows;

1. The implementation of failure analysis to provide a learning opportunity to increase understanding of the failure modes and mechanisms.

2. The operational and destructive stress limits to be determined. 3. Reliability and robustness improvement by implementing the lessons learnt from (1) and (2) with

design for reliability theories. Note that this type of testing regime is perhaps more applicable to reliability improvement during technology development but is also applicable when assessing and improving the insensitivity to changes in the local stresses (i.e. robustness). Screening is normally implemented immediately after manufacture/assembly and before shipping to enable the discovery of process faults and defects and prevent products with latent defects from getting into the field. It causes latent (hidden) defects introduced during design or manufacture to be realized as actual defects in the test. It traps manufacturing-related flaws by taking the product beyond the normal specification. The test is called a screen since it is used as a means of filtering out defects before shipping product to the customer. Screening also implies that all products are tested, if the manufacturing/assembly process is considered stable, then testing a select number of products may be implemented as a process stability monitoring activities (monitoring may be more practicable to 2nd/3rd tier suppliers). Test Objective Environmental stress screening

ESS is adopted to precipitate out latent and early life failures. Materials are subject to burn-in, thermal and vibration stresses.

Functional tests Check the assembled component operates according to the design specification. This test can also identify if tooling tolerances established during manufacture and assembly are sufficient so as not to prevent component functionality.

(Highly) accelerated life testing

Assess the material/component performance over a simulated life cycle. The test is usually designed to determine the operational and destructive limits of temperature and vibration stresses.

Material tests Assess a material’s performance against a specific physical or chemical process. Pressure and leak testing

Expose the sealing devices to the environmental pressures and determine sealing efficiency.

Table A 10: Types of acceptance test

Copyright ©

API 17N API


7.8 PROCESS 8: DATA MANAGEMENT

7.8.1 Description Reliability and Maintenance (R&M) data is required to:

• Inform future safety and risk assessments, reliability, availability and production efficiency analysis

• Monitor current operations and maintenance evaluations and compare with design predictions

R&M data can be collected in various phases in the life of the equipment, during FAT, SIT, Installation/Commissioning and operation. The majority of current R&M data collected for equipment or a system is obtained during once the field is operating.

7.8.2 Data Input to Reliability Analysis R&M data is required to inform safety and risk assessments, reliability, availability and production efficiency analysis. It also allows the monitoring of current operations and maintenance evaluations and supports comparisons with design predictions. Available reliability databases should be interrogated at appropriate times in the design to provide inputs to reliability analysis and reliability assurance. Any available evidence of reliability, including the reliability data, should be investigated and used to inform the reliability analysis carried out at each stage of the design cycle. This directly informs the level of reliability that may be achieved. For each system, subsystem and component, as appropriate, the expected service conditions should be considered in order that relevant historical data may be identified. This data should be input into the reliability and availability analysis, the results of which would demonstrate the achieved reliability in similar conditions and also identify failure modes that have been experienced. The data can also be used to indicate any changes to the design or conditions that need to be accounted for in the current project.

7.8.3 Data Collection The data capture systems should follow and comply with IS0 14224 which defines the minimum requirements of data to be collected, and details the process for ensuring possible exchange/transfer of quality RM data. OREDA is a Joint Industry Program (JIP) comprising nine international oil companies, including

• BP Exploration Operating Company • ConocoPhillips Norway • ENI S.p.A Exploration & Production • ExxonMobil Production Company • Gassco • Hydro ASA • Shell • Statoil ASA • TOTAL

It has the objective of collecting and exchanging R&M data to create a larger sample population of required equipment units, (Xmas Trees, Connectors, Sensors, etc) to acquire higher confidence in failure analysis data.

Copyright ©

API 17N API


RM data should be collected into databases, spreadsheets or written records to record operating and maintenance information. The following minimum data categories for the equipment and its failure and maintenance events should be captured:

• Equipment data • Identification data, e.g. equipment location, classification, installation data, equipment unit data; • Design data, e.g. manufacturer’s data, design characteristics; • Application data, e.g. operation, environment, system, fluid handled. • Failure data • Identification data, failure record and equipment location; • Failure data for characterizing a failure, e.g. failure date, maintainable items failed, severity class,

failure mode, failure cause, method of observation. • Maintenance data • Identification data, e.g. maintenance record, equipment location, failure record; • Maintenance data, parameters characterizing maintenance, e.g. date of maintenance, maintenance

category, maintenance activity, items maintained, maintenance man hours per discipline, active maintenance time, down time.

The data collected should be organized and linked in a computerized database to provide easy access for updates, queries and analysis.

Copyright ©

API 17N API


7.9 PROCESS 9: SUPPLY CHAIN MANAGEMENT

7.9.1 Description It is often found that high-level systems failures with significant consequences originate from the failure of minor components in the system. Systems designer/integrators must understand the significance of the risk potential of all components, including minor components supplied by 2nd and 3rd tier suppliers. Reliability requirements should be allocated down to all components. All suppliers will be expected to be capable of managing the various interfaces between the customers and suppliers down the supply chain.

7.9.2 Supplier Capability The ability to achieve the requirements set within the resource constraints established will depend on the reliability capability maturity of the organization undertaking the relevant task. This includes the timely and adequate completion of R&M tasks and the delivery, with confidence, of the physical reliability of individual components. The active assessment and selection of vendors and contractors occurs during the FEED and Detailed Design phases; however, the concept of reliability capability should be considered throughout the project planning phases, especially when delegating task responsibility. Assessments should be based around the key processes identified in this RP and result in a level ranking, such as that defined below;

1. No understanding of reliability concepts. 2. Prescriptive procedures that are repeatable but do not directly relate to reliability. 3. Understanding of historical achievements in reliability but with limited capability to learn from

lessons and improve reliability. 4. Understanding of design for R&M and how to correct designs to improve reliability given the

observation of failure. 5. Understanding of design for R&M and implementation into a proactive continuous improvement

program (both managerial and operational). Organizations that fit into levels 4 or 5 are considered learning organizations and should be regarded in preference to lower level organizations, especially during higher risk projects (cat ‘A and B’).

7.9.3 Contract Strategy Suppliers are crucial to the success of any field development project and as such have a real opportunity to support the improvement of performance and reliability. Simply seeking the lowest cost supplier, may not, deliver the greatest value to the project. It is therefore recommended that reliability engineering be a part of the contractual agreement between the operator and the contractor. The contracting strategy is an important tool for delivery of value to the project, especially if schemes to incentivise reliability improvement are adopted to provide a win-win solution for operators and contractors alike. Contractual specifications may include:

• Quantitative reliability requirements at system, package or component level • Minimum skills required, for example in reliability data management or Quantitative

Reliability Analysis • Minimum requirements for reliability activities such as FMECA, RBDA, Peer Reviews, etc. • Minimum requirements for internal procedures to address reliability related issues, such as

management of change, qualification testing, quality assurance, etc.

Copyright ©

API 17N API


7.10 PROCESS 10: MANAGEMENT OF CHANGE

7.10.1 Description Many failures originate from changes made to products or procedures during the life cycle of the product, without due assessment and control. Failures can also be introduced at life cycle phase transitions, due to lack of continuity of ownership of ongoing issues from one stage to the next. Companies should have systems in place for change control that include procedures for:

(a) Monitoring change: to identify the introduction of changes • To recognise when change has to be or has been introduced:

o From the Manufacturer – e.g. design improvements, revisions, upgrades o From the Operator – e.g. change in loading, installation, interface or

operating requirements o From the sub-supplier – e.g. change in material or welding properties,

manufacturing tolerances

(b) Assessing change: to evaluate any risks introduced to the project as a result of change • To identify the risks and assess the impact these may have on the product/project

reliability, either: o Formally through updating FMECAs, risk reviews, HAZOPs, etc. o Informally through design review and peer review processes

• It is then necessary to review the categorisation of the component, package, or product in the light of the changes that have been made.

(c) Managing change to control the follow up of necessary actions • To ensure all affected parties are informed of the change and any associated actions

are communicated and controlled including: o Updating of drawings and documentation o Revision of analysis (engineering and reliability) and testing o Updating the reliability plan and the RDD

(d) Monitoring and bench marking changes and follow up actions

• To evaluate after the event the impact of the change on: o Functionality and Operability o Reliability and Maintainability

The system should be built into the QA system and applied throughout the whole product life cycle to ensure that all changes that affect reliability are formally assessed, managed, documented, communicated and approved through:

Concept Design FEED Detailed Design Design for Manufacture and Manufacturing SIT, Installation and Commissioning Operations

Of primary importance with microprocessor based control systems is the establishment and adherence of a software change control procedure. The subsea control system equipment supplier should, therefore, in line with the above, demonstrate that an appropriate change control procedure is in place throughout the project life cycle.

Copyright ©

API 17N API


7.11 PROCESS 11: RISK AND R&M ANALYSIS AND MODELING

7.11.1 Description Risk and R&M models and analyses provide reliability management support by identifying failure logic and determining the frequency of occurrence. Some of the techniques are closely linked to setting R&M requirements, while others may already be considered good engineering practice within organisations. Analysis of the Risk and R&M models can be either qualitative or quantitative; qualitative models are used for failure mode identification purposes, which can then be further analysed with quantitative methods. The following table provides a summary and reference point for modelling and analysis methods.

Technique Objective Reference Availability modelling

Determine the time that the system is in an operations state given the system architecture.

Common mode failure analysis

Identify and assess the probability of simultaneous failures of independent components due to a common root cause.

ETA Graphically represents the propagation through a system of a given initiating event.

FME(C)A

Identify those failures that have unwanted consequences affecting the functionality of the system given the limits of its application.

BS 5760-5:1991

FTA Graphically represents the conditions or factors causing or contributing to the occurrence of an undesirable ‘top event’ (i.e. failure mode).

BS 5760-7:1991

HAZOPS Identify deviations from the design intent using guide word examination.

BS IEC 61882:2001

Importance Analysis

Rank the failure modes, mechanisms or components based on their contribution to system failure.

Physics of failure Model specific failure mechanisms to predict reliability of components that cannot otherwise be tested.

RBD Provide a graphical representation of a systems reliability performance by logically connecting the functional components required for a system’s operational success.

BS 5760-9 BS EN 61078:1994

Table A 11: Risk/R&M modeling analysis techniques and objectives The modeling and analysis process flows from the qualitative determination of failure modes to quantitative analysis importance analysis as indicated below:

• Identify failure modes (qualitative) • Assess the probability of occurrence of each failure mode (quantitative) • Populate reliability/availability model with the relevant data • Determine the reliability/availability and respective importance of each failure mode (quantitative)

Copyright ©

API 17N API


7.12 PROCESS 12: ORGANIZATIONAL LEARNING

7.12.1 Description Each project is a mine of useful knowledge and experience. The collection, review and implementation of lessons learnt from previous and current projects is one of the most effective methods of ensuring the same mistakes are not repeated and hence removing historical causes of unreliability. If these lessons are captured, they can be collated and fed back into later projects. Good reliability management should provide resources to ensure that information is fed back to the whole organization involved in design and system integration to allow lessons to be learned and understanding to be gained from experienced failures. The lessons learnt review is best carried out in conjunction with the project risk review and prior to the commencement of the project risk categorization, so that experience from previous projects can be reviewed. During this task, all relevant data from the previous project should be elicited from appropriate databanks. The lessons learnt usually cover the whole life of the project from strategic thinking and decision making, through project execution and delivery of the benefits. It is essential that these lessons explicitly address any issues that impact the ability to achieve reliability, from both good and bad practice. It is recommended that past lessons are considered at every stage within a project and as part of all risk and reliability review activities including design reviews. If this is carried out as part of a formal system then it is more effective at ensuring that this is actually carried out and at the right time. It is also recommended that every member of the project team be responsible for ensuring that they have each researched and captured all lessons pertinent to their role and area of responsibility within the project. Lessons relating to the achievement of reliability could include:

1. Equipment (design, manufacture, installation or operation difficulties) 2. Procedures (clarity, implementation and approval) 3. Project management (schedules, budgets, risks)

The tracking and analysis of data has most value when the information is converted into organizational knowledge and ultimately to improved product reliability. The purpose of the lessons learnt review is to facilitate the project risk review process by providing historical evidence of events during the individual project phase. The organizational learning is concerned with the transformation of data and information into intellectual capital of the organization. Intellectual capital takes 3 main forms:

1. Human Capital: Knowledge of individuals in the organization 2. Structural Capital: Knowledge structured in databases and knowledge bases (Lessons learned) 3. Customer Capital: Knowledge of the value to customers

Lessons can be gathered from a range of sources including; technical experts, project best practices, historical operating and failure data, engineering, test and inspection reports and industry networks.

Copyright ©

API 17N API


8 Annex 2: Reliability Data

8.1 OBJECTIVES Achieving very high reliability performance requires knowledge of at least three areas which must be supported by data collection in order to have acceptable scientific evidence on which to base any future (design) engineering, process and organizational improvement action:

• What current performance is being achieved? • What must/might be changed to improve that performance? • What is the economic incentive for doing so?

The objective of the reliability “data collection” activities is to provide this qualified, quantitative evidence of product design, installation and operational performance and field usage for use in future system development (performance improvement) and to provide early warning of reliability issues before the consequence of failure become unacceptable.

8.1.1 Definition of Success A data collection process for this API RP 17N which captures sufficient, appropriate and detailed data and information to:

• Establish a product history (build, application and use with time sequence) • Identify, predict and prevent repeat failures from the same root cause • Illuminate lessons learned to both prevent replication of error and enable copy and repetition of

success.

8.2 ASSUMPTIONS The “buyer” will ensure that all vendors in the supply chain are at least ISO 9001:2000 certified or supply their manufactured goods through a party who holds such certification. This will provide at least minimum assurance that adequate records are created and maintained with respect to the manufacturing processes to allow detailed root cause analysis if it should prove necessary in a future investigation. As new technology is introduced it is likely that some of those manufacturing processes will be proprietary and whilst we should expect the manufacturer to have appropriate records of the specific processes related to the particular product by serial number this information would remain confidential.

8.3 OVERVIEW A key driver of reliability performance improvement as described elsewhere in this RP is better understanding of failure mechanisms and root causes. It is not easy to define a data collection process which provides the level of detail required to do thorough failure investigations leading to an understanding of root causes and at the same time has the limited complexity and open access required of a shared database to be used by many. Equipment failures can be the result of a combination factors such as a small defects, insignificant damage, less than perfect installation and inability to detect small defects during testing. Equipment failures can also be the result of design errors or inadequate design processes – Organization and Processes. As recognized in ISO14224, it is essential to be able to capture and create a good lesson learned database. It is also important to have a generic equipment hierarchy or taxonomy which fits the real world. This should be sufficiently flexible to permit the inclusion of different field architectures and concepts. ISO14224 recommends the setting of appropriate system boundaries to avoid duplication of data and, then provides a suitable taxonomy on which to base the data collection process. For the purpose of this RP, the boundaries described in API RP 17A have been adopted as noted and illustrated above. The need to capture and collect maintenance data to reflect downtime (consequences) is addressed in some detail in ISO14224 together with the necessary data structure needed to do so. Such information is only valuable if it can be associated with geographical location, water depth, resource contacting strategy,

Copyright ©

API 17N API


management of change etc so that the sensitivity of related specific failure events, mechanisms and root causes to these parameters can be revealed.

8.4 SCOPE The collection process is illustrated visually in ISO14224 by the diagram shown below. The scope for subsea reliability data collection encompasses data relating to all equipment installed subsea within the boundaries described in API 17A for the purpose noted above, namely “to establish product performance (usage) history for further evaluation in engineering analysis for system improvements, for new system developments and avoidance of intolerable failures.” Data to be collected can be categorized under four main headings:

• Equipment data (design); • Application data (usage); • In-service Data

o Failure data; o Maintenance data (preventive and corrective), including well intervention and workover

data.

8.5 STRATEGY The strategy for data collection can be summarized as follows:

1. Data should be collected by the originator as close to the time and point of its origin as possible. This helps to reduce ambiguity in the responsibilities for data collection and ensures the highest possible level of data quality.

2. The responsibility for data collection therefore changes as a project moves through the life cycle… a. Equipment suppliers/vendors and manufacturers are responsible for collection of

equipment specific data, i.e. the design and manufacturing data b. Installation data are to be captured by the installer where he is the equipment supplier. In

case of a third party installer, the installation data are to be captured by the operator.

c. Operators are responsible for collection of the application aspects of the equipment, i.e. usage, environmental aspects, process conditions, locations, etc.

d. There is necessarily joint responsibility for in-service data such as maintenance or failure data (Operator provides data relating to time place and circumstances, manufacturer provides root cause analysis data after investigation)

3. The one who is responsible for collecting the data is also responsible for storing the data in a retrievable format. Either party may provide fields in their data system for the other party’s data to enable and facilitate the exchange of data.

It is essential to remember that the purpose of data collection is to provide performance evidence to support or deny reliability claims and provide a scientific justification for future activities. If the data lacks adequate detail and accuracy to serve this purpose the effort spent collecting it has been wasted. It must be possible to identify root cause where failures are concerned and actual operating regimes where frequency information is sought.

Copyright ©

API 17N API


8.6 RELIABILITY DATA TYPES

8.6.1 Equipment suppliers/vendors Equipment suppliers must capture the equipment specific data, which should, where possible include “lessons learned” during the Detailed Design and testing phase which will provide subsequent valuable information on design limitations and allowable operating envelope for the operator and help direct improvement effort for future systems. Typical information collected will include:

• Serial Numbers; • Material Specifications; • Manufacturing Processes (welding procedures, treatment processes etc.); • Applicable design codes; • Equipment application (pressure, temperature rating etc.); • Equipment description (part numbers); • FAT/SIT results; • Qualification tests results • Lessons learned

8.6.2 Operators Operators shall capture the application, operating environment and usage of the equipment. In addition operational inconsistencies, equipment failures and maintenance interventions performed on the subsea equipment shall be recorded. Typical data to be collected include:

• Life of field operating conditions, flow rate, pressures, sand production, water production, GOR etc;

• Geographical location, including water depth, and relevant Metocean data; • Equipment in-service information (storage of equipment, out of service, batch installation etc.); • Failure information, including specific failure description and failure root cause and causal factors; • Maintenance data, if equipment is taken out of service, replaced or adjusted; • Management of change (equipment application changed, changer of service)

8.7 MEASUREMENT OF SUCCESS How do we obtain data about success apart from an absence of failure data? There are at least two approaches to consider:

• Normal signature – continuous monitoring of normal operating parameters • Condition inspection of equipment removed from service

8.7.1 Normal signature All systems have a normal signature – the operating parameters once the system has bedded down – which should be monitored. Variations in these parameters outside the “normal” range will be a precursor to an anomalous event and may predict insipient failure if other explanations are not forthcoming. Even if there is an explanation that event may itself be a trigger for a future failure and should be analyzed carefully.

8.7.2 Removed equipment inspection Equipment removed for any reason – not just failure – should be inspected to determine if its condition is as expected. Are the wear rates, corrosion levels etc as expected, better or worse? This data can be used to modify life expectancy under similar operating regimes and in similar environments.

8.7.3 Equipment Log-Book In aviation and automotive applications log-books are used to create a permanent record of maintenance and change activities relating to the equipment, e.g. an aircraft and its sub-systems. This same technique could be adopted for subsea systems. In cases were maintenance is limited to inspect, say by ROV, these could be logged together with the results of function checks against a check-list. These “inspections” might

Copyright ©

API 17N API


be based on calendar time, operating time or production throughput or other pertinent parameters (number of start-ups or shut-ins etc.) determined by the designers during the system development phase of the project. Summary log-book information can be collected at each entry trigger as part of the evidence of success and/or progressive degradation not categorized as failure (e.g. reduced speed of valve operation).

API C2 / SC 17


API 17P TEMPLATES AND MANIFOLDS

TASK GROUP STATUS

JUNE 5, 2006

radforda

Text Box

Attachment O


-1- 3-Mar-06

TABLE OF CONTENTS

1. INTRODUCTION ..............................................................................................................1-1


3. MEMBERSHIP ..................................................................................................................3-2


5. MAJOR ISSUES.................................................................................................................5-3



8. RESOURCE NEEDS .........................................................................................................8-4


-1- 3-Mar-06

1. INTRODUCTION

The API 17P task group has the scope of work to develop a standard that would be applicable to all types of templates and the manifolds supported by them. This would include well spacer templates, riser support templates, manifold templates and multiwell/manifold temples; i.e. drilling and production templates, as well as pipeline end terminations and pipeline end manifolds. Some of the main topics to be covered by the standard are:

• Design and performance requirements for all components

• Definition of interface requirements

• Fabrication guidance

• Installation guidance

• Operations and maintenance guidance

• Abandonment considerations


Since the June API SC17 & ISO TC67-SC4-WG6 joint meeting, we have continued to refine the table of content and condensing input from several sources into the write-ups for the different sections.

Holding effective team meetings in the last quarter of 2005 was difficult and not very productive. Consequently, our intention to progress by including our overseas colleagues via phone or video conferencing did not progress.

INTEC Engineering has setup a FTP web site to post the skeleton of the draft to allow access by more than the local members of the task group (ftp:\\API:[email protected]). The draft document and other supporting documents have been posted to the site.

Second quarterly workshop has been set for June 22 at INTEC Engineering in Houston.


-2- 3-Mar-06

3. MEMBERSHIP

Membership to the task group has grown with several new members participating. Table 3-1, Table 3-2, and Table 3-3 show the changes in the current volunteer membership for the API 17P RP:

TABLE 3-1: API 17P TASK GROUP MEMBERS - HOUSTON Name Company E-mail Jeff Whipple INTEC Engineering jeffrey.whipple@intecengineering Kim Dyson INTEC Engineering kim.dyson@intecengineering Charles White DORIS [email protected] Ron Pfluger Cameron [email protected] Yong Bai Grenland Group [email protected] Eric Ringle FMC [email protected] Bhailal Parmar ChevronTexaco [email protected] Marc Hyndman Chevron Texaco [email protected]

TABLE 3-2: API 17P TASK GROUP MEMBERS - OVERSEAS Name Company E-mail Jørgen Holst Norsk Hydro jorgen.holst@hydro@com Børge Brubæk Statoil [email protected] TABLE 3-3: RESERVE API 17P TASK GROUP MEMBERS Name Company E-mail John Hellums Cameron [email protected] Chad Hughes FMC [email protected] Mario Lugo Exxonmobil [email protected] Hevle, Eric J. (ejhe) ChevronTexaco [email protected] Paul Mason Consultant [email protected] Ken Stefano ChevronTexaco [email protected]

Reserve members are not able to participate directly due to combination of project workload and temporary relocation to support projects, but are interested in the success of the task group.


-3- 3-Mar-06


Table 4-1 shows the current proposed milestone targets:

TABLE 4-1: MILESTONE TARGET DATES Milestone Targets Proposed Completion Date

Working Draft agreed by TG to proceed to Subcommittee (SC) (ISO Stage 20.99)

09/06

Draft approved by SC for formal ballot (ISO Stage 30.99)

12/06

Publication of Standard (ISO Stage 60.60) 2007

Forecast based on location of additional full time resources by early 3rd Qtr.

5. MAJOR ISSUES

Several major issues have come out of the review of the recently circulated ISO 13628-1 Annex L Draft A (14-Nov-2005) and ISO 13628-1 Clause 6 Draft A (14-Nov-2005) that were proposed as being integrated into the working draft for manifolds. In general the manufacturers in our task group find a significant number of items in these ISO draft documents to be in excess of industry standards and may preclude the procurement of off the shelf consumables. Comments made to the ISO drafts have been posted on the FTP site.

The task group wants to take the approach that the recommend practice does not specify specific materials for construction, instead examples are offered and selection criteria highlighted.


None at this time.


Task Group half-day meeting scheduled quarterly. This is a change from the once a month approach. Second quarterly meeting set for June 22.


-4- 3-Mar-06

8. RESOURCE NEEDS

Submitted request for funding in April to support full time staff for a period of one to two months.

June 2003

API SC17 SUNSET TEAMS

RP 17A/13628-1: Design and operation of subsea systems Members: Vince Vetter, Intec; William Bakke, Norsk Hydro; David Wilkinson, ExxonMobil

RP 17B/13628-11: Flexible pipe Spec 17J/13628-2: Unbonded flexible pipe Spec 17K/13628-10: Bonded flexible pipe

Members: Krassimir Doynov, ExxonMobil; Dave Wilkinson, ExxonMobil RP 17C/13628-3: TFL systems

Members: John Yonker, Halliburton, GaryHurta, Dril-Quip Spec 17D/13628-4: Subsea wellhead and tree equipment

Members: Ross Frazer, ATP; Brian Skeels, FMC; Gary Hurta, Dril-Quip Spec 17E/13628-5: Production control umbilicals

Members: John McManus, Gibson Tube; Ron Dee, Shell; Bruce Crager, ABB Spec 17F/13628-6: Subsea controls

Members: Fraser Gourlay, Mentor Subsea; Jens Neuenkirken, Statoil; John Bednar, BP RP 17G/13628-7: Design & operation of completion/workover risers

Members: Mike Byrd, BP; Anthony Muff, FMC; Gary Hurta, Dril-Quip RP 17H/13628-8: ROV interfaces

Members: Tim Marsh, Shell; Gary Hurta, Dril-Quip RP 17M/13628-9: ROT intervention system

Members: Charley White, ABB; Johann Bruun-Olsen, Statoil; Bruce Crager, ABB Note: If there is an active task group working on a revision to an existing standard the entire task group can be considered members of the Sunset Team.

June 2002

API SC 17 SUNSET TEAM(S) Effective immediately, Sunset Teams are being established to provide a source of information for the API staff to use as queries come in regarding the use of SC17 equipment. Typically, questions are received by the API from manufacturers and users regarding a particular SC17 specification or recommended practice. The API staff passes the query down to the SC17 Chairman for the Chairman’s response. When a task group is actively working the referenced document, the Chairman simply requests the Task Group Leader and his committee to convene, address the issue, and respond back to the Chairman with their recommendation. The recommendation is then forwarded on to the API Staff and then back to the originator of the question as an official API response. Typically, however, when a task group completes its designated work scope, it goes dormant, and the task group membership dissolves. This leaves the SC17 Chairman without a source of information for responding to related inquiries. The Sunset Teams have been conceived to assure the Chairman has that resource. A Sunset Team will be formed to represent each SC17 document. If a Task Group is still actively working the document, then the Sunset Team Leader is by default, the same individual as the Task Group Chairman. If the original Task Group has gone dormant, the Sunset Team Leader will be recruited by the SC17 Chairman. It is the responsibility of the Team Leader to recommend his Team members to the SC17 Chairman for approval. The Team will typically have 4 to 5 members, the Task Group Leader, the SC17 Leadership Team Champion, the ISO Project Leader and up to 2 additional members. (NOTE: It is recommended that efforts be made to have an ISO representative involved from a like ISO 13628 specification group in each Sunset Team. It will provide an added information resource and a method to feed ISO queries back into the ISO structure. While the Sunset Teams are specifically charged to address API inquiries, they should recognize those issues that should also be appropriately addressed on the broader ISO level.) The process for handling queries will be the same as was in the past. Noting the attached figure, requests come directly to the API Executive Committee. They are passed down to the SC17 Chairman, via the API Coordinator, who then selects the pertinent Sunset Team to address the issue. The Sunset Team Leader convenes his team and resolve the issue by interpreting or clarifying an issue, recommending changes to the relevant specification or recommended practice, or suggesting that a “new work item” be initiated to address an overlooked issue. After approving the Sunset Teams solutions or recommendation(s), the SC17 Chairman, sends the response back to the API Staff for the official response back to the queries initiator. The SC17 Committee Leaders will be soliciting members to be leaders and participants on both the task groups and these Sunset Teams.

John Bednar Gary Hurta SC 17 Chairman SC17 Vice-Chairman

radforda

Text Box

Attachment P

QUESTIONS API STAFF ANSWERS

SUBCOMMITTEE ONSUBSEA PRODUCTION

SYSTEMS C2/SC17

interpretationerratanwip

SUNSET TEAM(1) TG CHAIRMAN

(1) SC17 LT Champion(2) API REPS.

(1) ISO PL

SUNSET TEAM

INTERACTION

API/Liaison/NACE to API-05 1 of 1 12/1/2006

NACE / API E&P LIAISON REPORT -- JUNE 2006 NACE MR0175/ISO 15156, "Petroleum and natural gas industries—Materials for use in H2S-containing environments in oil and gas production." ISO has published four Technical Corrigenda for the parts of NACE MR0175/ISO 15156: Technical Corrigendum 1 – Part 1 Technical Corrigendum 1 – Part 2 Technical Corrigendum 1 – Part 3 Technical Corrigendum 2 – Part 3 These changes are the results of 15 ballot items that were passed by the Maintenance Panel and NACE TG 299 (oversight committee) in 2004 and 2005. One of them simply removes trade names from tables and uses only UNS numbers instead, but some of the others involve significant technical changes. Technical Corrigendum 2 for Part 3 is 18 pages long and includes many tables. ISO chooses to publish these as technical corridenda and wait until the 5-year revision to include them in the main text. At the time of the 5-year revision, they will also have to be voted on by the member bodies of ISO/TC 67, but hopefully there won’t be any problems. The corridenda are downloadable free for NACE members from the NACE Web site, and also downloadable free for anyone from the ISO Livelink Web site. The Maintenance Panel handled 31 technical inquiries during 2005 (with 3 still outstanding) and has received 9 so far in 2006, with 5 still outstanding. Inquiries and answers completed as of March 1, 2006, with 5 still outstanding. Inquiries and answers completed as of March 1, 2006, are posted on the ISO Web site: www.iso.org/iso15156maintenance.

Technical Publications Released Since June 2005:

--- New Standards Related to Production and Pipelines RP0205-2005 “Recommended Practice for the Design, Fabrication, and Inspection of Tanks for the Storage of Petroleum Refining Alkylation Unit Spent Sulfuric Acid at Ambient Temperatures” --- Standards and Reports Related to Production and Pipelines Revised or Reaffirmed Since June 2005 – TM0177-2005“Laboratory Testing of Metals for Resistance to Sulfide Stress Cracking and Stress Corrosion Cracking in H2S Environments” TM0399-2005“Standard Test Method for Phosphonate in Brine” TM0185-2006“Evaluation of Internal Plastic Coatings for Corrosion Control of Tubular Goods by Autoclave Testing” If there are questions or more information is desired please contact NACE Technical Activities Department at: 281/228-6221 or email [email protected] or contact your liaison representative at: 214/348-7692 or email: [email protected]. Harry G Byars NACE/API E&P Liaison Representative June 07, 2006

radforda

Text Box

Attachment Q

MINUTES 20 Joint Meeting API SC 17 & ISO/TC67/SC4/WG6 Subsea

Documents

Transcript of MINUTES 20 Joint Meeting API SC 17 & ISO/TC67/SC4/WG6 Subsea