LEAK DETECTION—1: Alaskan lessons guide system selection, implementation

A step-by-step process for selection and implementation of a new pipeline leak detection system applied to a 48-in. OD, 800 mile crude oil pipeline and a 14-in. OD, 35 mile crude gathering pipeline, both in Alaska, provides useful lessons for other pipeline systems using either computational pipeline monitoring or other positive emission detection approaches to maintaining system integrity. The process brings structure to the roles of multiple stakeholders, including the owner-operator, leak-detection vendor, and regulatory agencies.

Part 1 of the article, presented here, examines the development of leak detection system specifications. The conclusion (Aug. 2, 2010), will focus on selection and implementation of the system itself.

Background

A pipeline leak detection system (PLDS) is an increasingly standard component of a modern pipeline control system. Pipeline operators function today in an environment where leak detection systems are seen as a condition of operation mandated via the legal code and enforced through both the courts and regulatory mechanisms and agencies.

PLDS system requirements have generally become more stringent with time. Prudent operators responsible for ensuring compliance with regulatory requirements for leak detection systems must:

• Clearly identify regulatory requirements.
• Define application requirements.
• Select an appropriate leak detection product.
• Initially test and validate system performance.
• Perform recurring testing and validation.

Validating vendor claims has proven particularly difficult, as noted by the US Environmental Protection Agency.1 The difficulty of the decision landscape has only increased in the 17 years since the EPA's first note on the topic. A diverse range of potential system types, with a corresponding diversity of capabilities, has helped drive decision complexity.

Computational pipeline monitoring (CPM) approaches may include pressure-flow deviation alarms, mass volume systems of varying complexity and sophistication (with packing correction ranging from none at all to sophisticated real time model-based calculations), acoustic-negative pressure wave systems, and statistical methods.² Other approaches may use positive emission detection with sophisticated hydrocarbon detection instruments.

Leak detection system selection and implementation complexity is exacerbated by the wide variety of operating constraints. Each pipeline is a unique system, each pipeline has a unique set of imposed requirements, and each pipeline has its own financial limitations. A lack of recognized industry standards (especially at the performance level) and a shortage of consistent international, national, state, and local regulations make development of one-size-fits-all solutions even more difficult.

This article provides a logical, step-by-step process for selection and implementation of a new pipeline leak detection system. Although the process is oriented around software-based CPM systems, it can be extended to other types of systems employing positive emission detection.

This selection process was successfully used as a value-added technique in the selection, deployment, and validation of CPM on a complex crude oil pipeline system consisting of both an 800-mile, 42-in. OD pipeline and a 35-mile, 14-in. OD gathering system.

Basic approach

The large majority of pipeline leak detection systems sold today are software based computational pipeline method systems operating in conjunction with a pipeline's supervisory control and data acquisition systems (SCADA). The basic process for selecting and implementing such a system is to:

• Survey all applicable regulatory and governmental requirements, industry standards, and company internal requirements, as well as any additional operational, performance, and engineering needs for the system.
• Use the regulatory, industry standards and other formal requirements in conjunction with operational, performance, and other system needs to develop a written PLDS functional basis document.
• Survey pipeline design and operation, determine whether or not it can support the PLDS needs, and implement any control, instrumentation, or data upgrades necessary to meet the requirements.
• Evaluate commercially available systems in light of both regulatory-internal requirements and pipeline design-instrumentation capabilities.
• Implement the PLDS, ensuring the process addresses development time, properly documents the system, and includes all necessary controls and testing for the installation to meet predetermined system needs.
• Maintain the system in a manner allowing it to continue to address all original requirements.

PLDS requirements

Any serious leak detection system must satisfy some minimum level of formal leak detection standards or requirements. Requirements vary from the general (a leak detection system is required) to the specific (the leak detection system must be able to detect a leak of such-and-such size in a certain period of time). Determining these requirements should happen at the start of the system definition task.

The origins of PLDS requirements can be categorized as:

• Governmental and regulatory.
• Industry standard.
• Company internal standards.
• Project specifications.

Governmental and regulatory mandates are legal conditions of operation. Pipelines' status as large industrial facilities often crossing state and national boundaries makes the process of determining leak detection requirements both important and complicated. These mandates only become more stringent with each passing year (OGJ, May 15, 2006, p. 56).

The only international standards which might apply are those occurring by reference via international treaty, or as conditions of funding for supranational pipeline projects (enacted, for example by international funding agencies such as the World Bank). Most such ventures either ignore this issue, or (more commonly with time), refer to national or even state-level standards.

The US Department of Transportation Office of Pipeline Safety (DOT-OPS) regulates transportation of hazardous liquids, including crude oil, in the US via the Code of Federal Regulations as legislated by Congress through the Pipeline Safety Act and its reauthorizations.3 49 CFR 195 requires operators of hazardous liquid pipelines who use CPM (computational pipeline monitoring) systems to apply API 1130 "Computational Pipeline Monitoring" as reference for such systems. 49 CFR 195 does not require pipeline operators who currently do not have CPM systems to install one. Those operators, however, who currently operate such a system, or who plan on installing one in the future, must consult API 1130 when designing, evaluating, operating, and maintaining such systems.

State and local regulatory requirements in the US may specifically rely on or be more stringent than 49 CFR 195. For example, the 48-in. OD, 800 mile crude oil pipeline and a 14-in. OD, 35 mile crude gathering pipeline in Alaska must comply with Title 18 of the Alaska Administrative Code (AAC). These requirements are generally much more stringent than Federal regulations. Alaska regulations generally require:

• Installation of systems capable of detecting a pipeline commodity release.
• Stringent performance requirements.
• Technology evaluations as part of oil spill contingency plan submissions.

Title18 AAC 75.055(a) specifically states "a crude oil transmission pipeline must be equipped with a leak detection system capable of promptly detecting a leak, including:

• If technically feasible, the continuous capability to detect a daily discharge equal to not more than 1% of daily throughput.
• Flow verification through an accounting method, at least once every 24 hrs.
• For a remote pipeline not otherwise directly accessible, weekly aerial surveillance, unless precluded by safety or weather conditions."

Local requirements at the regional, city, or similar levels may be even more restrictive. This was not a problem in the pipelines used as examples in this article due to Alaska's small population and infrastructure density (Fig. 1), in other parts of the US, however, with greater densities of both population and infrastructure, such local requirements could be extensive. Additional pipeline-specific prescriptions may arise through right-of-way, connection, or other legally binding agreements between the pipeline and government entities.

Proper selection and implementation of pipeline leak detection systems is critical to maintaining the integrity of crude oil pipelines such as this one near Alaska's Prudhoe Bay (Fig. 1).

Government regulations may reference industry standards for pipeline monitoring. In the US, for example, American Petroleum Institute Standard 1130 is referenced by 49 CFR 195 and serves as the primary pipeline industry standard applicable to most pipelines falling outside US Environmental Protection Agency1 oversight, including the Alaskan lines discussed here. API 1130 provides general guidelines and recommendations with respect to CPM system categorization, selection criteria, specification of commodity properties, applicability to various kinds of pipeline systems, supporting field instrumentation, supervisory control and data acquisition (SCADA) systems required to support the CPM system, data presentation, system operations, system testing, data retention, and operator training.

In general API 1130 language is not strongly prescriptive in nature, prompting states such as Alaska to introduce their own regulatory requirements. Most API 1130 criteria are expressed as recommendations or guidelines. No performance requirements are included. However, 49 CFR 195 does require hazardous liquid pipeline users of CPM systems comply with API 1130 Section 4.2: "Selection Criteria." This API 1130 section provides a list of features operators should refer to when designing (or presumably selecting from commercial offerings for) a CPM system.

Additional requirements may arise through the operating company's or applicable pipeline organization's internal standards applicable to leak detection systems. It is not uncommon for such internal standards to mirror or reference regulatory or industry standards, but it is not unheard of for corporate standards to exceed such requirements. It is also not uncommon for operators to have no specific leak detection standards.

Development specifications

At a minimum, the PLDS must satisfy regulatory and other formalized system requirements discussed previously. These formal requirements, however, are likely to be incomplete in terms of true system needs. Consequently, all CPM system implementers should perform a project-specific evaluation to ensure the new leak detection system is fit-for-purpose and meets reasonable requirements for the application. The project manager should ensure project system requirements are complete and well documented. Written specifications should include:

• Architectural requirements.
• Performance requirements.
• Related functional requirements.
• User interface requirements.
• Test and validation requirements.
• Documentation, administration, training, and other requirements.

Architectural requirements for the PLDS address processing platform, data acquisition, provision of results, data archival, system redundancy and survivability, and similar hardware and design requirements.

The processing platform for most leak detections systems usually takes the form of a vendor supplied PC or other computer processing unit. Purely software-based solutions amenable to being hosted on a client supplied computer offer another alternative.

A SCADA system can supply input data for the leak detection system (i.e., measured flows, pressures, temperatures, etc.). The system can acquire field data directly from field devices using MODBUS, OPC, or other network-based protocols.

The PLDS user interface can provide results directly, or the output data for the leak detection system (presumably in the form of alarms and graphical objects), can be supplied to the SCADA system, where it will presumably be displayed via the SCADA user interface.

The Alaskan pipelines' PLDS used vendor supplied PCs interconnected with the SCADA system using OPC communications. These SCADA systems in turn used a network-based IP protocol to obtain all field measurements.

Data archival for PLDS is becoming an increasingly important issue as legal requirements for these systems assume increasing prominence. Such archival may be required to allow operators and regulators to view past performance, but may also be used by engineers and analysts to perform system parameter tuning and evaluate "what if" scenarios.

CPM systems are increasingly being viewed as mission critical systems which cannot fail for any reason, prompting implementation of redundancy at the combined hardware, software, and network levels in the Alaskan pipelines. Such redundancy specifications ensure seamless operation in the event of failure, but can increase the complexity of the installation.

The PLDS runs the risk of satisfying no-one if system performance requirements are incompletely specified. Certain performance requirements may stem from regulatory requirements. These requirements, however, are likely to be incomplete. The Alaskan PLDS include criteria for:

• Leak detection sensitivity.
• False positive maximums.
• Leak location requirements.
• System stability requirements.
• Resource utilization.

Leak detection sensitivity performance typically requires specification of leak rates or discharge volumes and probability of detection as a function of time.

Regulatory, industry standard, or other formal requirements may establish minimum leak sensitivities and maximum time-to-detect metrics. If formal requirements do not address these specifications, however, the operator should develop a complete set of requirements.

This metric should identify a range of leak sizes with specific associated minimum detect times. Identification and specifying a range of leaks considers that larger leaks should be detected faster than smaller ones.

Small leaks have a higher probability of not being detected than larger leaks, requiring the leak detection performance specification be stated as a level of probability. Operational constraints and system capabilities prevent 100% leak detection, casting it instead as a probabilistic event tied to a complex set of variables. Leak detection performance should establish a probability-to-detect level as a function of leak size and time, such as 95%; for identified leak volumes and time-to-detect specifications, the system must be able to detect that leak 95% of the time or better (Fig.2). The Alaskan pipelines established leak detection specifications of 95% within 24 hr for leaks of 1% nominal flow and larger.

The number of nonleak alarms or false positives plays a large role in operator acceptance. This system metric is rarely stipulated in regulations and often missed in internal standards. As Carpenter, Henrie, and Nicholas have noted, however, expanding the outputs from automated software-based pipeline leak-detection system performance testing to include false positives (nonleak alarms) can improve assessment and optimization of PLDS. Marked improvement is available when these new outputs are combined with appropriately high-level measures of PLDS efficiency and performance (OGJ, May 22, 2006, p. 50).

Regulatory guidelines for this metric are conspicuous by their absence. False alarms, however, are of interest to operations personnel, since such alarms may be their only normal interaction with the PLDS. If false positives are a common occurrence when compared with true positives (i.e., the alarm is a real leak), and if the false positive rate is high, users of the system are unlikely to have a good opinion of the system, and may not respond properly when a real leak occurs. In general, users do not want a system tuned so weakly nonleak alarms become a nuisance, nor so tightly that true leaks are not discovered. Operations personnel role in defining this standard should therefore be prominent.

Many leak detection systems can now show where the leak is, allowing the company to focus spill reconnaissance personnel to a specific area and reducing the time required to verify it. This ability depends on PLDS capabilities and pipeline configuration. The Alaskan lines leak location allowable errors were set according to nominal leak rates and line lengths. Their leak location parameter uses a 75% probability the leak location shown is within 25% of the line length of the actual leak for small leaks and within 5% of the line length for large leaks. Leak location error typically increases as the size of the leak decreases. Specification should therefore be provided in terms of distance error as a function of leak size.

A highly reliable PLDS should have minimal system stability problems. Three areas requiring specific testing are:

• Abnormal termination.
• Standards for cold start or warm restart.
• Manual alarm termination, reset.

Ideally the system should never experience an abnormal termination. The maximum number of such events should be 1/year. The user should be able to quickly restore the system via warm or cold restart. A warm start typically uses archived state files allowing for rapid recovery. A cold start usually involves a complete restart with no recovery files, requiring extended system stabilization and tuning. Including bad data in the recovery files can cause a warm restart to fail. The system should have an extremely low rate of failure to warm start, and should virtually never fail to cold start. Companies should also develop standards on how abnormal termination recovery will take place.

Another recovery standard is how frequently leak alarms must be terminated or reset. When a leak alarm occurs analysis may determine it is false. The system, however, should not have an excessive number of false positives and methods should be provided to terminate the false alarm condition, since the system cannot detect new leaks while in an alarm state.

System resource utilization standards establish the relationship between the system hardware and software. It is undesirable for the leak detection application to use too much of the system resources, particularly if the PLDS platform also hosts other mission critical applications.

As a guide, PLDS should not exceed 50% of system resources under normal operations. This threshold provides adequate computing resource reserves for leak and system analysis to be performed without degrading system capabilities.

The PLDS is often obtained in conjunction with related applications either using a similar set of software components, or providing related functionality. The user should consider the following functionalities:

• Real-time hydraulic gradient model.
• Batch and pig tracking.
• Off-line training simulators.
• Off and on-line optimization models.
• Off-line engineering simulators.

A similar approach as is used in this article should be applied to each of these systems.

A properly designed user interface is critical to maximizing usability of the PLDS. Considerations for developing a user interface specification should include:

• What operational alarm information is presented.
• Where leak alarm analysis occurs.
• What graphics capabilities will be available for alarm analysis.

PLDS specifications must clearly state what and how operational alarms are presented. The pipelines used as examples in this article conformed to SCADA system reporting specifications requiring each alarm identification include location, estimated leak size, estimated leak location, and leak initiated time stamp.

This aspect of PLDS specifications is often overlooked, not only in leak detection systems but in SCADA systems as well. Hollifield and Habibi have noted that inadequately addressing the user interface has been a contributing factor to the seriousness of upsets, incidents, and major accidents.4 Inclusion of this specification improves understanding of how the SCADA system and PLDS must interface, a technical detail capable of affecting overall project schedule, cost, and performance.

The project manager should ensure system specifications allow for proper testing. If the acquired PLDS is anything beyond a pure "off-the-shelf" acquisition and requires configuration or feature-functional development, both a factory acceptance test (FAT) and site acceptance test (SAT) should be run.

Both the FAT and SAT should evaluate all system functionalities. The FAT occurs at the vendor's facility, and may use recorded pipeline data to validate performance measures. The SAT typically happens once the system is installed at the pipeline control center and may also employ commodity release testing.

The operator must be able to maintain the installed system. The vendor should therefore supply good documentation for the system, including operator-user manuals and proper maintenance manuals. At a minimum, the operator manuals should provide instruction on working with the user interface and diagnosing leak alarm conditions. The maintenance manuals should provide guidance on installing the system components, starting the applications, cold- and warm-starting the system, and configuring the leak detection statistical operators, as well as any required modeling aspects of the PLDS.

The vendor should also ensure the system can be properly administered, including providing all operating system and leak detection software installation media and standard documentation. The pipeline user should ensure all security arrangements and components are understood, including use of hardware security devices and cyber security requirements.

Training to be obtained from the leak detection vendor also needs to be specified, including topics to be covered, class sizes, and class durations. Training should cover both end-user and maintenance issues, as described in the system project documentation.

References

1. US Environmental Protection Agency Office of Research and Development, "Standard Test Procedures for Evaluating Leak Detection Methods: Pipeline Leak Detection Systems," 1990.
2. American Petroleum Institute, "Computational Pipeline Monitoring for Liquid Pipelines," API 1130, 2nd Ed., November 2002.
3. US Department of Transportation, Pipeline and Hazardous Materials Safety Administration, 49 CFR 195, "Transportation of Hydrocarbon Liquids by Pipeline," 2004.
4. Hollifield, B. and Habibi, E., "The Alarm Management Handbook: A Comprehensive Guide," PAS, Houston, 2006.

The authors

Morgan Henrie ([email protected]) is president of MH Consulting Inc., Anchorage. He has also served as project manager and SCADA engineer at Alyeska Pipeline Service Co. He holds a PhD in engineering management and systems science (2005), MS in project management (2000), and BS in electronic engineering (1997) from Old Dominion University, Norfolk, Va., George Washington University, Washington, DC, and Kennedy-Western University, Cheyenne, Wyo., respectively. He is a member of the Project Management Institute, American Society for the Advancement of Project Management, and Industrial Engineering Society.

Philip Carpenter ([email protected]) is president of Serrano Services and Systems in Austin. He has also served as engineering supervisor at Alyeska Pipeline Service Co. in Anchorage, and has held senior level engineering positions at both Alyeska and BP Pipeline. He holds BS (1977) and MS (1979) degrees in engineering from State University of New York at Buffalo.