LEAK DETECTION—Conclusion: Integrated selection method yields life-cycle benefits

A new method outlines a comprehensive approach to integrated selection and implementation of pipeline leak-detection systems, yielding both lower costs and greater efficiency over the life-cycle of the system.

Hazardous material pipeline system owners and operators live in an environment where leak detection is not only a hallmark of prudent operations but often legally mandated. Regulatory entities strive to protect human health and safety as well as the environment by requiring specific operating features and functionality.

While trying to ensure regulatory compliance and acting as prudent operators, decision makers face a set of difficult tasks including:

• Clearly identifying leak-detection system regulatory requirements.
• Defining system requirements.
• Selecting an appropriate system.
• Initial testing and validation of system performance.
• Recurring testing and validation of the installed system.

Part 1 of this article (OGJ, July 19, 2010, p. 52) examined the development of leak detection system specifications for a given pipeline, using two Alaskan crude line as examples. The conclusion, presented here, focuses on selection and implementation of the system itself.

The method presented has assisted in selection of new and replacement pipeline leak detection systems. It has also provided documentation acceptable to regulators as evidence the selected, installed, and validated systems meet their mandates.

Design

A pipeline's physical characteristics are the primary driver of PLDS performance. Each pipeline system is physically and operationally unique. This uniqueness may preclude selection of leak-detection systems incapable of meeting a particular pipeline system's attributes. Simple pipelines not subject to packing may obtain high performance with relatively simple leak-detection systems, while a more complex pipeline may require a more complex PLDS.

Real Time Transient Model (RTTM) systems, for example, use a mass-balance approach relying on a pipeline physical model integrated with a hydraulic model using partial differential equations defining the fluid commodity, heat transfer, equations of energy conservation, and sophisticated batch tracking dynamic behavior.

The RTTM may also incorporate pump, valve, control device, and control logic models. This type of system supports large-diameter pipelines crossing mountainous terrain and covering a long distance, operating in complex states such as constant slack-line conditions and intermittent slack-line areas.

An RTTM system might be excessive, however, for short, small-diameter pipelines built in relatively flat terrain and operating in relatively stable states with no batching or slack-line operation. For these systems, a more basic line- or volume-balance system with a less sophisticated packing correction may be more appropriate.

To ensure PLDS performance requirements are in line with pipeline system capabilities, PLDS users should employ API 1149, "Pipeline Variable Uncertainties and Their Effects on Leak Detectability."

API 1149 provides an evaluation methodology to determine theoretical leak-detection system performance based on pipeline instrumentation and other design parameters. The approach used by API 1149 is conservative, not allowing the PLDS to use statistical regularities occurring over time to improve performance. Such approaches are common in modern CPM systems.

Fig. 1 shows a calculated API 1149 leak-detection sensitivity performance estimate, plotting various leak sizes against time to detect for three different types of leak-detection systems. This analysis addresses the 14-in. OD crude gathering line introduced in Part 1 (OGJ, July 19, 2010, p. 52) and provides the leak-detection engineer and project team definitive system-performance specifications, which can be included in the PLDS bid documents.

Reasonable extensions of the API 1149 methodology allow false-positive rates to be estimated based on known pipeline system parameters, again assuming performance data for the meters are known. Fig. 2 is an example of a false-positive performance map developed with this process for a single pipeline segment and shows the percent of time the segment is expected to be in alarm based on the normalized leak-detection threshold NLDT, defined in terms of the standard meter excursion for the segment (see Equation box).

Fig. 2 clearly shows the lower leak-detection thresholds as strongly driven by the meter errors and that attempts to find smaller leaks by reducing the leak-detection threshold will exact a cost in terms of additional time spent in alarm. False positives also typically prevent the system from detecting a true leak if it is already in alarm.

Fig. 2 shows the cost associated with lowering leak-detection threshold in terms of false alarms. If the pipeline is configured to detect leaks over multiple segments, each of which is bounded by a meter, this problem is compounded (Fig. 3), as an increase in the leak-detection system's granularity is coupled with excessively low thresholds.

In conjunction with the previous leak-detection performance estimate, false-positive performance maps provide the owner-operator, leak-detection technical staff, and leak-detection vendor a definitive basis to develop both the bid and project system testing.

The pipeline's hydraulic design, instrumentation, supervisory control and data acquisition (SCADA) system, and all other components needed to support the leak-detection mission must be properly in place. Mass-balance systems, for example, require continuous metering at the boundaries of the system. Meters going temporarily off-line to accommodate passage of pigs, for example, will not provide a solid basis for system-wide leak detection.

System evaluation

The PLDS project manager should provide a complete copy of system specifications to vendors of all candidate systems. Vendors should be asked to respond to the specification and clearly identify areas whose requirements they either cannot or will not commit to meeting.

This approach works fairly well. In the area of PLDS performance, however, it is difficult for vendors to commit to the operator's leak-detection requirements and for pipeline users to have any confidence in the vendor's claims. Only appropriately designed testing can validate such claims with any confidence.

System testing

Despite the benefits of the API 1149 approach, there is no substitute for actual testing of the leak-detection system. Up-front capability tests validate vendor claims against PLDS performance needs. API 1130, Section 6.2, System Testing provides an overview of CPM testing suitable for initial system testing, retesting, and maintenance tests. Up-front testing provides a method to measure "actual performance and provide a baseline of achieved performance."¹

As provided for in API 1130, vendor validation testing may use a variety of methods, including commodity release and simulated data. Commodity-release testing involves actual removal of product from the leak-detection system.

Commodity-release tests, however, are problematic for many reasons. First is selection of a location where sufficient commodity volume can be safely removed to simulate the test leak rate while maintaining normal operation. This involves either draining the commodity to a sump, tank, or storage medium large enough to handle the leak volume for the duration of the test or special piping to reroute a portion of the fluid stream back to the inlet side of the leak-detection section.

The volume of removed product can be large. As an example, if the pipeline volume is 100,000 b/d and the leak-detection objective is 1%, the commodity-release test must occur at an offtake rate of 42 bbl/hr for an entire day or longer. Storage capacity must exceed the bbl/hr leak rate × 24 hr, in this case totaling 1,000 bbl. Accommodating this volume can be difficult for pipeline operators.

Even if some means of handling the estimated leak volume is available, removing product from the pipeline always carries risk, spanning the range from inadvertently creating a spill to generating an emergency, such as a fire, threatening not only the physical environment but personnel as well. The logistic, cost, and risk factors also make it virtually impossible to obtain detailed performance maps with commodity-release testing. For these reasons, if at all possible, vendor claim testing should be conducted with simulated leak-testing data methods.

API 1130 identifies two methods of simulated leak testing. One involves "altering an instrument output, such as a meter factor, to simulate a volume imbalance, or a pressure output to simulate a hydraulic anomaly that represents a leak." The second simulated method involves "editing CPM configuration parameters to simulate commodity loss (software simulations) or a desired hydraulic condition."¹

Simulation of leaks via software that imposes leak rates of known size on prerecorded pipeline data acquired via the pipeline SCADA system is particularly effective. Such simulation involves software modification of recorded SCADA data to simulate a variety of leaks via the following process (OGJ, May 15, 2006, p. 56):

• Specify a range of leak sizes.
• Calculate the estimated impacts on flow rates, product temperature, and pressure boundary conditions for each leak rate and leak location.
• Modify normal SCADA data readings to reflect the calculated leak rates.
• Run the data through the vendor's PLDS off-line in a "fast-time" mode limited only by computer resources.
• Determine whether the leak was captured in the allotted time and how long it took.
• Repeat for each leak rate or desired test.
• Store the statistical data.

Modifying the data in advance allows evaluation of multiple vendor systems against the same data set and PLDS performance requirements. This approach has several distinct advantages:

• Lower costs.
• Higher speeds.
• Lower risks.
• Extensive performance maps not possible through commodity discharge testing.
• Provision of a consistent data set for multiple vendor evaluations.
• Repeatability.

Fig. 4 shows a performance map obtained by this methodology.

Using modified stored SCADA data is a sound technique for validation of vendor claims.

Implementation

To the degree one uses the up-front work employed by this article's methodology to properly define the system and project requirements, actual implementation should be relatively smooth. Although the system has been up-front tested, it should be retested by factory-acceptance test via the offline leak simulation methodology described to validate final system tuning and performance. This tuning should be evaluated by site-acceptance test with selected commodity discharge testing.

Maintenance

Once the PLDS is installed, tested, and accepted, the pipeline operator should maintain it in accordance with all regulatory and operational-internal requirements previously identified. API 1130 requires periodic retesting, which should be performed following the offline methodology described. The system should also be retuned and retested every time changes take place in pipeline hydraulic design or measurement configuration.

Reference