Pipeline Leak Detection Software

Skip key takeaways

Updated October 4, 2026

• CPM is defined as a tool that alerts rather than one that acts The regulation makes the software a detector and an annunciator whose output is an alert addressed to the pipeline dispatcher.
• Design sits in 195.134 and operation in 195.444 Both bind the operator of a hazardous liquid pipeline to API RP 1130, in the 3rd edition of September 2007.
• Seven method families, each with its own data appetite Section 4.1.2 runs from line balance to statistical analysis and the list describes practice rather than restricting it.
• No system meets all the selection criteria The 1998 rule reports that the standard's own introduction says so, and with no numerical performance standard in the rule the operator writes the acceptance criterion.
• A CPM alarm is a regulated object with a plan behind it A written alarm management plan applies, with a monthly census of points off scan, inhibited, false-alarming or held at a manual value and an annual controller workload check.

Copy takeaways

Pipeline leak detection software on a hazardous liquid line has a regulatory name, computational pipeline monitoring, and a one-sentence definition. The definitions section of 49 CFR 195.2 says: "Computation Pipeline Monitoring (CPM) means a software-based monitoring tool that alerts the pipeline dispatcher of a possible pipeline operating anomaly that may be indicative of a commodity release." The definition paragraph spells the term Computation while the sections that impose the requirements write computational, the spelling used here. Both halves of that sentence are constraints on the software: it is a monitoring tool, and its output is an alert addressed to a person rather than an action taken on the pipeline.

In short: 49 CFR 195.134 carries the design requirements for a CPM system and 195.444 the operating ones, both written as duties of the operator of a hazardous liquid pipeline and both pointing at API RP 1130. Section 4.1.2 of that standard describes seven method families, from line balance to statistical analysis, and in engineering practice each asks something different of the instrumentation and of the SCADA data behind it. The regulation sets no numerical leak detection performance standard, so the sensitivity against false alarms trade is settled by the operator and inherited by the software team, while 195.446 requires any operator using a SCADA system to run a written alarm management plan, which is where a CPM alarm presented on the SCADA console lands.

What computational pipeline monitoring is

The verb in that definition was chosen deliberately. Issuing the 1998 rule that created the definition, the agency explained the change to its own draft wording: "we have revised the definition for Computation Pipeline Monitoring to clarify that a CPM system alerts the pipeline dispatcher of a possible operating anomaly rather than allows the dispatcher to respond to an operating anomaly." Read as a specification, that sentence makes a CPM system a detector and an annunciator. Nothing in the definition gives it an action on the pipeline, and the decision it triggers belongs to a person with other evidence in front of them.

What the software must do inside that envelope is set by API RP 1130, whose coverage the regulator describes in a footnote of its 2019 hazardous liquid rule: "API RP 1130 focuses on the design, implementation, testing and operation of Computational Pipeline Monitoring (CPM) systems that use an algorithmic approach to detect hydraulic anomalies in pipeline operating parameters for hazardous liquid pipelines." Four verbs there cover the whole lifecycle of a piece of software, which is why compliance work on a CPM system looks like engineering process rather than document review.

The publisher's own description is shorter. On its standards page, API writes: "The RP addresses the algorithmic monitoring tools used to enhance the ability of a pipeline controller to recognize hydraulic anomalies that could show a pipeline leak." The standard is sold rather than published, so nothing here is quoted from inside it, and its program-management companion, API RP 1175, Pipeline Leak Detection - Program Management, carries no force under Part 195.

Two classes of system are in play, and the class names are ours rather than the regulation's. An internal system, which is what CPM means, reads the pipeline's own instruments through SCADA and computes. An external system watches the outside of the pipe. A 2023 gas rulemaking lists that second class: "Vendors and operators have been experimenting with a number of methods such as pressure wave monitoring, acoustic monitoring, in-ditch sensing with fiber optic sensors, and other devices." That document is a gas proceeding, used here only for mechanism, and it imposes nothing on a liquid operator.

Asymmetry between the two classes is regulatory rather than technical. Part 195 binds an internal CPM system to a named standard and an external system to nothing, while still requiring that some effective system exist. PHMSA said as much in the 2019 rule: "PHMSA notes that negative pressure wave monitoring, real-time transient modelling, or other external systems are not necessarily required to comply with the rule." An architecture leaning on an external method still has to satisfy 195.444's duty to have a leak detection system and to evaluate its capability.

The rule the software has to satisfy

Two sections carry the duty, and they split along the line a software team would draw anyway. PHMSA states the first in the 2019 rule: "Section 195.134 contains the design requirements for computational pipeline monitoring leak detection systems." The second section, 195.444, governs the system once it is running.

Design is one sentence in 49 CFR 195.134: "A new computational pipeline monitoring (CPM) leak detection system or replaced component of an existing CPM system must be designed in accordance with the requirements in section 4.2 of API RP 1130 (incorporated by reference, see § 195.3 ) and any other applicable design criteria in that standard." The word replaced matters to anyone maintaining an installed system: swapping the model engine or the statistical layer pulls that component back under the design rule.

Operation is 49 CFR 195.444, which asks two separate things. It states a duty to evaluate: "An operator must evaluate the capability of its leak detection system to protect the public, property, and the environment and modify it as necessary to do so." That evaluation must consider, at a minimum, the length and size of the pipeline, the type of product carried, the swiftness of leak detection, the location of the nearest response personnel and the leak history. The section then binds the software: "Each computational pipeline monitoring (CPM) leak detection system installed on a hazardous liquid pipeline must comply with API RP 1130 (incorporated by reference, see § 195.3 ) in operating, maintaining, testing, record keeping, and dispatcher training of the system." Record keeping and dispatcher training are named alongside operation, so both sit inside the compliance obligation rather than beside it.

Inside a high consequence area the same duty is written a second time. The integrity management section, 49 CFR 195.452, puts it this way: "An operator must have a means to detect leaks on its pipeline system. An operator must evaluate the capability of its leak detection means and modify, as necessary, to protect the high consequence area." The factor list attached to that evaluation runs longer than the one in 195.444, adding the pipeline's proximity to the high consequence area and the results of the risk assessment. What that means for a delivery team is our reading rather than a stated rule: segment identity belongs in the tuning record and in the alarm log from the first release.

Scope is narrow in two directions. Both sections reach only single-phase liquid, as 195.134 opens: "This section applies to each hazardous liquid pipeline transporting liquid in single phase (without gas in the liquid)." The same section excepts two line types: "The requirements of paragraph (b) of this section do not apply to offshore gathering or regulated rural gathering lines." Its two deadlines have passed, 1 October 2020 for pipelines constructed on or after 1 October 2019 and 1 October 2024 for those constructed before it.

Which edition binds is settled in 49 CFR 195.3, the list of matter incorporated by reference, whose entry reads "API Recommended Practice 1130, Computational Pipeline Monitoring for Liquids: Pipeline Segment, 3rd edition, September 2007, (API RP 1130)".

Check that before ordering a copy. API's own standards announcement page for RP 1130 still names a 2nd edition, and the incorporated one is what binds.

One thing the rule does not do is order the software into existence. Per the 1998 rule: "The rule does not require an operator to install a CPM if the operator does not already have one. It only requires that an operator with such a system follow API 1130." An effective leak detection system is still required, with an evaluation of its capability, which pushes an operator without CPM toward an engineering decision rather than a product choice.

The seven method families and what they demand

The method families are not a vendor taxonomy. Enumerating what section 4.1.2 of the standard contains, the 1998 rule states: "Section 4.1.2 describes seven CPM systems: line balance, volume balance, modified volume balance, real time transient mode, pressure/flow monitoring, acoustic/negative pressure wave, and statistical analysis." The same document adds that the list describes rather than restricts: "API 1130 lists and describes the seven CPM systems that are used by the pipeline industry today. Section 4.1.2 does not limit the use of CPM systems to only those described." An eighth approach is therefore allowed, and 195.134(c) still requires that its design follow section 4.2 of the standard.

Line balance is where every other method starts. The advisory bulletin marks where arithmetic stops being enough: "Those pipeline operators with longer and more complex systems, with multiple sources and/or destinations, are more dependent on computerized processes to perform a thorough product tracking resulting in a leak detection process." It also states what the computerized version buys: "The line balance processes incorporating SCADA or other technology are geared to find less obvious failures such as partial line breaks and smaller leaks not apparent in general flow and pressure monitoring." The one cadence any of these documents commits to attaches to the manual process, not to a scan rate: "it is PHMSA's expectation that these operators would have systems configured and staffed in such a manner as to routinely, safely and accurately perform this manual calculation process at a maximum of one-hour intervals."

Model-based detection is the other pole, and the 1998 rule reduces it to two sentences: "Such models compare current operating conditions with calculated data values. A deviation may indicate the possibility of a leak." The data behind that comparison comes from where everything else does: "SCADA systems utilize computer technology to continuously gather data (e.g., pressure, temperature, and delivery flow rates) from remote locations on the pipeline." Everything a model adds over a plain balance is an attempt to explain a deviation before alarming on it.

Negative pressure wave detection works on an event instead of a balance. The 2023 gas rulemaking describes the mechanism: "pressure sensors placed periodically along the pipeline can detect anomalous negative pressure waves that propagate from the location of a rupture." Its coverage limit is ours to state: a wave is launched by a change, so a leak already running steadily when the detector starts gives it nothing to see.

The table below separates what a regulator stated from what we are asserting. Method names in the first column are the regulator's, from the enumeration above. The four columns after them are our engineering description, not a requirement of API RP 1130 and not a statement of 49 CFR.

Method (sourced)	Principle (editorial)	Data it demands (editorial)	Strength (editorial)	What it misses (editorial)
Line balance	Compare metered volume in against metered volume out over a fixed window, alarm on the discrepancy	Inlet and outlet flow meters, a shared clock, a settled window	Simple and auditable, working with the instruments a line already has	Blind inside the window, and defeated by anything moving inventory without passing a meter
Volume balance	The same comparison corrected for the inventory held in the line	Pressure and temperature on top of the meter readings	Sees smaller discrepancies than a raw meter balance	Integrates over time, so a small leak hides inside measurement uncertainty
Modified volume balance	Volume balance with line pack compensation, so a transient is subtracted not alarmed	Multiple pressure and temperature points, calibrated fluid properties, synchronized sampling	Survives pumping and batching that would false-alarm a plain balance	Needs a fluid model that stays true as batches and temperatures change
Real time transient mode	A hydraulic model runs alongside the segment and measured state is compared against computed state	Dense pressure and flow instrumentation, elevation profile, pipe and fluid properties, tight time alignment	Highest sensitivity, and it estimates leak size and location	Most demanding to keep tuned, and model drift surfaces as alarms
Pressure/flow monitoring	Alarm on rate of change or on a threshold breach at individual points	Fast pressure sampling at a handful of points	Fast and cheap, useful for a large release	Cannot see a small leak or separate one from an operational change
Acoustic/negative pressure wave	A rupture launches a rarefaction wave and arrival-time differences locate it	High-rate pressure or acoustic sensors, plus accurate relative timestamps	Very fast, and it localizes well	An event detector: a leak already running steadily produces no wave
Statistical analysis	Test residuals against their expected distribution and alarm past a confidence threshold	A residual series from a balance or model method, plus a characterized noise baseline	Makes the trade explicit and tunable rather than implicit	Only as good as its baseline, and it inherits its input's weaknesses

A starting rule for reading that table, ours rather than anyone's guidance: if the line is short, simply metered and steadily operated, start from a balance method and put statistics on its residuals. If it batches, swings in temperature or climbs across elevation, start from a transient model, because most of what a simpler method reports as a discrepancy is real hydraulics on that line. If the worry is a rupture rather than a slow release, start from the pressure and wave family. The instrumentation each one demands then decides whether it is available at all.

Sensitivity against false alarms

There is a sourced answer to the question of which method satisfies every selection criterion, and the answer is that none of them does. Selection criteria live in section 4.2 of the standard, and the 1998 rule reports what that section's own introduction says about them: "However, the introduction to Section 4.2 makes clear that no system meets all the criteria." That single sentence is the whole design problem. In engineering practice, raising sensitivity on any of these methods raises the rate of alarms nobody can explain, and the tuning that follows is a policy decision about which error the operator prefers to make.

Similar vocabulary appears in the comment record of the 2015 proposed rule, attributed there to commenters rather than the agency. One state regulator "found that any new standards should consider detection of small leaks in HCAs, maintenance, accuracy, transient conditions, system capabilities, and alarm management." The agency summarized the record as a whole: "The commenters identified several issues that should be considered in establishing new leak detection standards, including the need to minimize false alarms, to set appropriate volumetric thresholds, and to encourage the use of best available technologies."

None of it became a number. PHMSA closed the point in the 2019 rule: "PHMSA is not making any additional changes to the regulations concerning specific leak detection system performance criteria requirements at this time." The consequence is direct: the acceptance criterion for a CPM deployment is the operator's to write, because 195.444 makes the system's capability something the operator must evaluate, and an operator with a CPM system must be able to demonstrate compliance with API RP 1130 the way it would for any other pipeline safety regulation.

Alarm management is a regulated activity

A CPM system's output is an alarm, and an alarm is a defined object. Per 49 CFR 195.2: "Alarm means an audible or visible means of indicating to the controller that equipment or processes are outside operator-defined, safety-related parameters." The parameters are the operator's, which is the reason to treat a CPM alarm threshold as a governed setting rather than a tuning constant buried in a configuration file. The same section defines the recipient: "Controller means a qualified individual who remotely monitors and controls the safety-related operations of a pipeline facility via a SCADA system from a control room, and who has operational authority and accountability for the remote operational functions of the pipeline facility."

Around those alarms sits a mandatory plan. 49 CFR 195.446 states it: "Each operator using a SCADA system must have a written alarm management plan to provide for effective controller response to alarms." Several of the provisions that follow are product features in disguise: a CPM system either supports them or forces somebody to maintain a spreadsheet beside it.

Sharpest of those provisions is a monthly census. Under 49 CFR 195.446 the plan must "Identify at least once each calendar month points affecting safety that have been taken off scan in the SCADA host, have had alarms inhibited, generated false alarms, or that have had forced or manual values for periods of time exceeding that required for associated maintenance or operating activities". A false-alarming point is therefore something the operator identifies on a monthly cycle, alongside points off scan, inhibited or held at a manual value, which is the strongest argument for logging every CPM alarm together with the inputs that produced it. Controller workload is measured on a longer cycle: the operator must "Monitor the content and volume of general activity being directed to and required of each controller at least once each calendar year, but at intervals not exceeding 15 months, that will assure controllers have sufficient time to analyze and react to incoming alarms".

What prompted the NTSB's SCADA safety study is recorded in the advisory bulletin: "The number of hazardous liquid accidents investigated by the NTSB in which leaks went undetected after indications of a leak on the SCADA interface was the impetus for this study." An indication that reached the interface and was not acted on is the documented failure mode, so an alarm a controller cannot act on is not a detection.

Testing and validating a CPM system

Testing is named in the rule rather than implied. 195.444 puts testing and record keeping inside the compliance obligation, and the 1998 rule says how that is shown: "Each operator who has installed a CPM system will have to demonstrate that it is complying with the requirements in API 1130, as it does with any pipeline safety regulation." Demonstration means evidence produced on request, which shapes what a delivery team owes at handover.

That boundary has been stable since then. An advisory committee recommendation in the same 1998 rule reads: "The operations, maintenance, and testing portions of API 1130 should apply to all existing and newly-installed CPM systems, and API 1130 in its entirety should apply to all newly installed CPM systems and replacement sections of existing CPM systems." That is the boundary 195.134 and 195.444 still draw, and it decides which rule a modernization project falls under.

Before any of it, there is a decision to record. The advisory bulletin expects "the operating plans and procedures required by the pipeline safety regulations should include the performance of an engineering analysis to determine if a computerized leak detection system is necessary", and it expects the paperwork to survive: "operators must retain documentation from any related engineering analyses for the computerized leak detection and line balance considerations to demonstrate the thoroughness of review during an inspection." A decision not to build is as inspectable as a decision to build.

Our own validation practice runs three exercises, none of which any reachable source states as a requirement, and between them they answer the four questions we ask of a candidate configuration. Replay of recorded operating history against the tuned configuration measures how often it alarms on nothing, using data the line actually produced. Synthetic leak injection into that replayed history, scaled from large down to small, measures how small a release the configuration can see and how closely it places the size and location of one it finds. Transient rehearsal across starts, stops, batch changes and pressure excursions measures how it behaves while normal operation moves the line, and how much of the alarm budget that consumes. Each exercise leaves a record, and the record is the artifact the demonstration duty asks for.

Architecture beside SCADA

SCADA is the substrate, and a footnote in the 2022 valve and rupture detection rule defines it with the control direction included: "These are computer-based systems used by a controller in a control room that collects and displays information about a pipeline facility and may have the ability to send commands back to the pipeline facility." A CPM system consumes the first half of that sentence, and our position is that it stays out of the second half, so a fault in the detector can never reach the control path.

Two failure modes there are silent, and each needs its own decision. A detector that has stopped running raises nothing and looks exactly like a quiet pipeline, so a heartbeat and a watchdog on the CPM service are as load bearing as the detection logic. A detector still running on stale or frozen inputs is worse, so input quality checks belong upstream of the model, and a point held at a manual value is precisely the case the monthly census in 195.446 exists to catch.

The control room rule attaches to that arrangement rather than to the pipe. 49 CFR 195.446: "This section applies to each operator of a pipeline facility with a controller working in a control room who monitors and controls all or part of a pipeline facility through a SCADA system." Field changes and backup systems are both covered. A point-to-point verification between SCADA displays and related field equipment is required when field equipment is added or moved and when other changes affecting pipeline safety are made to field equipment or SCADA displays, and any backup SCADA system is tested at least once each calendar year at intervals not to exceed 15 months.

What follows is our architecture rather than a requirement of any rule. The CPM engine runs beside SCADA, not inside it, reading a replicated real-time feed. A historian holds the raw measurements at full resolution, because replay validation and the false-alarm census both need the original series rather than a summarized one. Alarms reach the controller on the same console path as every other alarm, so the workload monitoring the rule requires counts them honestly.

Four pieces of the whole are ours to specify: the acquisition path and its quality checks, the tuning and its version history, the alarm presentation with its records and the replay harness. Telemetry disciplines underneath them, meaning collection, buffering and clock alignment, are covered in our IoT development guide, and the wider control and monitoring estate around a pipeline in our energy software development guide.

How Pharos Production helps

Pharos Production works on the software around a leak detection engine rather than on the detection mathematics inside it. Our oil and gas software development page sets out that engineering scope, from the SCADA-facing data path through to the evidence an evaluation has to show.

Sources: 49 CFR 195.2, 195.3, 195.134, 195.444, 195.446 and 195.452 on ecfr.gov; the Federal Register texts on govinfo.gov of the 1998 RSPA final rule incorporating API 1130 (63 FR 36373), PHMSA Advisory Bulletin ADB-10-01 (75 FR 4134), the 2015 proposed rule (80 FR 61610), the 2019 final rule (84 FR 52260), the 2022 valve and rupture detection final rule (87 FR 20940) and the 2023 gas leak detection proposed rule (88 FR 31890); the API standards page for API RP 1130. API RP 1130 is cited by title and edition, API RP 1175 by title, and neither is quoted. Read on 16 September 2026. Engineering guidance, not legal advice.

FAQ

Last updated: October 4, 2026

Quick answers to common questions about custom software development, pricing, process and technology.

Expand all Collapse all

Search FAQs

Popular

Type to filter questions and answers. Use Topic to narrow the list.

Showing all 6

• What is computational pipeline monitoring?

  Featured question. Copy link Copies a direct link to this answer to your clipboard.

  It is the name 49 CFR Part 195 gives to software-based leak detection on a hazardous liquid pipeline. The regulation defines it as a monitoring tool that alerts the pipeline dispatcher to a possible operating anomaly that may indicate a commodity release, and the wording was deliberately narrowed so that the system alerts rather than acts.

  In practical terms a CPM system reads pressure, temperature and flow through SCADA, compares what it measures against what it expects and raises an alarm for a controller to investigate. In the regulation's description it is a detector and an annunciator rather than a controller of the pipeline.

• Does 49 CFR require every hazardous liquid pipeline to have a CPM system?

  Copy link Copies a direct link to this answer to your clipboard.

  No. The rule requires a leak detection system and an evaluation of its capability, and it does not order a computational one into existence. What it does say is that any CPM system an operator has must follow API RP 1130, in design under 195.134 and in operation, maintenance, testing, record keeping and dispatcher training under 195.444.

  PHMSA's advisory bulletin expects the operating plans and procedures to include an engineering analysis of whether a computerized system is necessary, and the documentation of that analysis to be retained for inspection. Both routes end in written evidence rather than in a product choice.

• Which API standard applies to leak detection software?

  Copy link Copies a direct link to this answer to your clipboard.

  API Recommended Practice 1130, Computational Pipeline Monitoring for Liquids: Pipeline Segment, in the 3rd edition of September 2007, which is the edition 49 CFR 195.3 incorporates by reference. Section 4.2 is the design hook the regulation names and section 4.1.2 is where the seven method families are described.

  The document is sold rather than published, so build against the incorporated edition and expect to buy a copy. A companion practice on leak detection program management, API RP 1175, exists but is not incorporated into Part 195 and carries no regulatory force there.

• Which pipelines do the requirements on this page cover?

  Copy link Copies a direct link to this answer to your clipboard.

  Hazardous liquid pipelines under 49 CFR Part 195, and nothing else. The CPM design section applies to a pipeline transporting liquid in single phase, meaning without gas in the liquid, so a multiphase line falls outside it.

  The same section excepts offshore gathering and regulated rural gathering lines from its design requirement. Gas pipelines are not governed by Part 195 at all, and this page makes no claim about what does govern them. If the line in front of you sits in one of those classes, the method families still describe the engineering honestly while the compliance frame on this page does not carry across to it.

• Why do leak detection systems produce false alarms?

  Copy link Copies a direct link to this answer to your clipboard.

  Because sensitivity and false alarms trade against each other, and the 1998 rule reports that the introduction to section 4.2 of the standard makes clear that no system meets all the criteria. In practice, normal operation moves the pipeline constantly through starts, stops, batch changes and temperature swings, and every one of those shifts the measurements a detector reasons about.

  Tuning a configuration to catch a smaller release generally means accepting more alarms that turn out to be nothing. The regulation contains no numerical threshold to settle the argument, so the operator writes the acceptance criterion and the software team implements and evidences it.

• What should a CPM handover leave behind?

  Copy link Copies a direct link to this answer to your clipboard.

  Four artifacts, and this list is ours rather than the regulation's. A tuning version log, so that any configuration the line has run under can be reconstructed and explained rather than remembered.

  Alarm records that carry the inputs which produced each alarm, because an alarm stored without its inputs cannot be re-examined afterwards. A replay corpus of recorded operating history with a stated retention period, since replay is the only way to re-measure a tuning change against data the line actually produced. Last, the engineering analysis behind the leak detection decision, which PHMSA's advisory bulletin expects an operator to retain so the thoroughness of that review can be shown at inspection.

I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.

As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.

My focus is on complex products where mistakes are costly:

• Web3 and blockchain platforms
• FinTech and regulated products
• High-load startup systems
• MVP → scale transitions

We don’t do body-shopping.
We don’t sell generic outsourcing.

Instead, we help founders:

• build the right team structure from day one
• keep technical ownership and transparency
• scale delivery without losing control
• avoid vendor lock-in and hidden risks

Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.