1、 Guidance to API Specification Q2 API TECHNICAL REPORT 18TR2 FIRST EDITION, DECEMBER 2017 Special Notes API publications necessarily address problems of a general nature. With respect to particular circumstances, local, state, and federal laws and regulations should be reviewed. Neither API nor any
2、of APIs employees, subcontractors, consultants, committees, or other assignees make any warranty or representation, either express or implied, with respect to the accuracy, completeness, or usefulness of the information contained herein, or assume any liability or responsibility for any use, or the
3、results of such use, of any information or process disclosed in this publication. Neither API nor any of APIs employees, subcontractors, consultants, or other assignees represent that use of this publication would not infringe upon privately owned rights. API publications may be used by anyone desir
4、ing to do so. Every effort has been made by the Institute to ensure the accuracy and reliability of the data contained in them; however, the Institute makes no representation, warranty, or guarantee in connection with this publication and hereby expressly disclaims any liability or responsibility fo
5、r loss or damage resulting from its use or for the violation of any authorities having jurisdiction with which this publication may conflict. API publications are published to facilitate the broad availability of proven, sound engineering and operating practices. These publications are not intended
6、to obviate the need for applying sound engineering judgment regarding when and where these publications should be utilized. The formulation and publication of API publications is not intended in any way to inhibit anyone from using any other practices. All rights reserved. No part of this work may b
7、e reproduced, translated, stored in a retrieval system, or transmitted by any means, electronic, mechanical, photocopying, recording, or otherwise, without prior written permission from the publisher. Contact the Publisher, API Publishing Services, 1220 L Street, NW, Washington, DC 20005. Copyright
8、2017 American Petroleum Institute Foreword Nothing contained in any API publication is to be construed as granting any right, by implication or otherwise, for the manufacture, sale, or use of any method, apparatus, or product covered by letters patent. Neither should anything contained in the public
9、ation be construed as insuring anyone against liability for infringement of letters patent. The verbal forms used to express the provisions in this document are as follows. Shall: As used in a standard, “shall” denotes a minimum requirement in order to conform to the standard. Should: As used in a s
10、tandard, “should” denotes a recommendation or that which is advised but not required in order to conform to the standard. May: As used in a standard, “may” denotes a course of action permissible within the limits of a standard. Can: As used in a standard, “can” denotes a statement of possibility or
11、capability. This document was produced under API standardization procedures that ensure appropriate notification and participation in the developmental process and is designated as an API standard. Questions concerning the interpretation of the content of this publication or comments and questions c
12、oncerning the procedures under which this publication was developed should be directed in writing to the Director of Standards, American Petroleum Institute, 1220 L Street, NW, Washington, DC 20005. Requests for permission to reproduce or translate all or any part of the material published herein sh
13、ould also be addressed to the director. Generally, API standards are reviewed and revised, reaffirmed, or withdrawn at least every five years. A one-time extension of up to two years may be added to this review cycle. Status of the publication can be ascertained from the API Standards Department, te
14、lephone (202) 682-8000. A catalog of API publications and materials is published annually by API, 1220 L Street, NW, Washington, DC 20005. Suggested revisions are invited and should be submitted to the Standards Department, API, 1220 L Street, NW, Washington, DC 20005, standardsapi.org. iii v Conten
15、ts Page 1 Scope 1 2 Terms, Definition, Acronyms and Abbreviations 1 2.1 Terms and Definitions . 1 2.2 Acronyms and Abbreviations 1 5.3 Risk Assessment and Management . 1 5.5 Contingency Planning 1 5.8 Control of Testing, Measuring, Monitoring and Detection Equipment 3 6.3 Analysis of Data 4 Bibliogr
16、aphy 5 1 Guidance to API Specification Q2 1 Scope This document provides guidance on the intent and use of API Specification Q2 (API Q2). This document is not intended to provide training on the development and implementation of a quality management system (QMS). This document will not provide guida
17、nce to each section of the API Q2. 2 Terms, Definition, Acronyms and Abbreviations 2.1 Terms and Definitions For the purposes of this document, the terms and definitions given in API Q2 apply. 2.2 Acronyms and Abbreviations MOC management of change NDE nondestructive examination PMITP preventive mai
18、ntenance, inspection and test program QMS quality management system SQP service quality plan SRP service-related product TMMDE testing, measuring, monitoring, and detection equipment NOTE Paragraph numbering aligns with the sections of API Q2. 5.3 Risk Assessment and Management Risk assessments crea
19、te an awareness of situations, processes, environments, etc. that may cause or contribute to disruptions, incidents, problems, failures, delays, or loss. Risk assessments are conducted by an individual or team who is competent (see section 4.3.2.2) in the methodology, operational and environmental c
20、onditions, and the intended service and service-related product (SRP). Risk assessments may be incorporated into other management system processes, procedures, documents and records. There are numerous industry tools and standards that can provide guidance for risk assessments. Although tools and te
21、chniques are required to be identified in the procedure, the specific tools and techniques used for risk management are identified by the service supply organization. NOTE ISO 31010 provides examples of various techniques for risk management. The primary goal of risk mitigation is to lower the risk
22、exposure to within acceptable threshold limits identified by the organization. For risks that exceed the identified risk threshold, mitigating actions are identified by the organization. 5.5 Contingency Planning Contingency plans are not limited to emergency response or business continuity plans. 2
23、API TECHNICAL REPORT 18TR2 Contingency planning is the process by which the organization identifies backup plans in the event that the risk which impacts service delivery materializes. Contingency planning does not change the probability of the event occurring, but can change its impact. Developing
24、a contingency plan involves making decisions in advance about the management of services and SRPs, coordination and communication procedures, and awareness of a range of technical and logistical responses. Risk mitigation and contingency planning are two strategies that are used in the management of
25、 risk. Both are closely related to one another as they are sequential, complementary steps used in the risk assessment process. Every contingency plan requires a risk assessment (see section 5.5.2); however, some risks may be deemed acceptable by the organization without further mitigation or contin
26、gency planning. 5.6.1 Purchasing Control Requirements established in section 5.6.1 a)e) are applicable to purchasing control of critical and non-critical services, and SRPs. The difference between the requirements for critical and non-critical services is that the organization performs an on-site as
27、sessment of the critical service or service-related product supplier prior to initiation of the purchase agreement. The purpose of the assessment is to verify the suppliers ability to meet the specified scope of work, and that the suppliers QMS meets the requirements specified by the purchasing orga
28、nization. For non-critical service or service-related product suppliers, the organization has the option of performing one or more of methods identified in section 5.6.1 (i, ii, iii). It is the organizations responsibility to determine and define what is critical, and non-critical, as it relates to
29、SRPs or services, and the evaluation process is defined in section 5.6. The product or service being supplied and the associated risk are used to determine QMS requirements. NOTE See further clarifications in Section 1 Scope and Application. 5.6.2 Purchasing Information Requirements established in s
30、ection 5.6.2 a)e) are applicable to purchasing information for critical and non-critical services and SRPs. Each requirement is applied “where appropriate” for the type of service to be performed and/or SRP to be provided. Examples of where this information could be captured or referenced include, b
31、ut are not limited to: purchase order, master service agreement, master purchasing agreement, contracts, addendums, statement of requirement, etc. 5.7.2 Service Quality Plan A Service Quality Plan (SQP) is a requirement for all services. The organization is responsible for determining how to build a
32、 SQP that will be effective, usable and compliant to all requirements listed in 5.7.2. The SQP is not intended to be a bridging document between multiple management systems. It is possible to employ one document or a combination of documents to achieve this. The SQP can be standard, job specific, se
33、rvice specific, or customer specific as long as it meets the specific requirements of API Q2. “External parties” is a general term that can describe customers, regulators, suppliers, contractors, subcontractors and other parties external to the organization that impact the delivery of the service. I
34、n other parts of API Q2 where the standard mentions subcontractors and/or suppliers, there are specific requirements that are applied to those external parties. The SQP requires identification of the responsibilities of suppliers, subcontractors and other external parties. This includes the identifi
35、cation of the subcontractor, and the description of the controls over the subcontractor. GUIDANCE TO API SPECIFICATION Q2 3 The SQP may address requirements a)j) through direct inclusion in the SQP, the service design development outputs, or through reference to the controlling documents or processe
36、s. Information on quality plan development can be found in ISO 10005. 5.7.3 Identification and Traceability API Q2 specifies the minimum set of requirements for traceability for critical SRP, which includes rental tools designated as critical. Specific material traceability and records requirements
37、will depend on the product and the requirements defined by the organization and the customer. Critical SRP, including legacy tools that do not meet the traceability requirements of API Q2, would be identified as nonconforming product and handled in accordance with section 5.10. The identification of
38、 the criticality of SRP (including components) is based on risk assessment, and performed during the design of the service. Identification of an assembly as critical does not, by default, make all the components in the assembly critical. It is the responsibility of the organization to communicate th
39、e criticality of SRP to applicable personnel throughout the service realization process. 5.7.5 Customer Property Customer intellectual property could include, but is not limited to well data, lab results, specifications, proprietary products, logging data, reservoir data, etc. 5.7.7 Validation of SR
40、P Some SRP that cannot be fully validated prior to execution of service (e.g. cement, perforating assemblies, well trajectory design) may be fully validated as part of the service performance validation process. Some SRP may require a facility and special testing equipment for validation that is not
41、 available while the SRP is deployed. Some SRP may be deployed and utilized for multiple customers and in multiple wells prior to being returned to a facility where the SRP is validated. The frequency and methods for validation of SRP are identified by the organization (see ISO 9000:2005, section 3.
42、8.5 for definition of “validation”). 5.7.8 Preventive Maintenance, Inspection, and Test Program The requirement for a preventive maintenance, inspection, and test program (PMITP) applies to SRPs that are used throughout the execution of the service. Critical spare parts for SRP can be determined by
43、the type of service, location, risk levels established by the service provider and customer, input from the original equipment manufacturer, and the application of the SRP. Usage history (5.7.8 b) can include a variety of factors related to the cumulative time SRP is used, the environments and condi
44、tions the SRP is exposed to, the related environmental impacts on the SRP, the type of SRP, the application of the SRP, etc. The requirement for acceptance criteria applies to processes, tests, and inspections (see 5.7.1.2). Components of the SRP subjected to planned inspection and testing are requi
45、red to have documented acceptance criteria. 5.8 Control of Testing, Measuring, Monitoring and Detection Equipment Not all testing, measuring, monitoring, and detection equipment (TMMDE) may be part of the calibration program. It is the responsibility of the organization to determine which TMMDE is u
46、sed for verification and validation of service and SRP. The organization has the responsibility to verify that TMMDE supplied by their external sources for its use is calibrated and/or verified prior to its use. This may include verification of the TMMDEs calibration through calibration status indic
47、ators, confirmation with the owner of the TMMDE, and review of records. Organizational procedures describe the process for determining evidence of conformity. 4 API TECHNICAL REPORT 18TR2 5.10.2 Nonconforming Service Execution and SRP Nonconformities are handled as defined in the documented procedur
48、e for addressing nonconforming SRP, including where software is used in the execution of a service. 5.11.2 MOC Implementation A management of change (MOC) is not needed for routine personnel changes (e.g., crew or shift changes) if the change is not going to impact the execution of service. 5.11.3 M
49、OC Evaluation, Notification and Controls The specification requires notification of relevant personnel, including the customer, of the change and the risk assessment results. The source or initiation of the change does not affect the requirement that the MOC process be used. It is outside the scope of the specification to require a response or acknowledgment from the customer. 6.2.2 Internal Audit Outsourced activities that are not located at the organizations facility are not required to be included in the internal audit. Activities not located at the organizatio
