Problems With Industry Guidance Docs

Threat Identification and Risk Assessment

ASME B31.8S Standard has served us well over the last 10 years, however continuous improvement is expected. Accordingly, improved guidance should now be provided to operators on how risk assessments should be conducted in order to meet IMP expectations. Note also, the recent PHMSA criticisms regarding the current industry practice of pipeline risk assessment.

Proposed Changes to 2.2 Integrity Threat Classification

The threat categories—both the 9 categories in the higher level and the 21 in the more-detailed level—should be revised. Some of these ‘threats’ refer to vulnerabilities rather than failure mechanisms and some failure mechanisms are missing. For example, a category to capture all crack-related mechanisms—not just SCC—including fatigue and all environmentally assisted cracking (EAC) such as SCC, SSC, HIC, and others is needed.

Another urgent change needed is to the category called ‘stable’. The idea of stable ‘threats’ has proven to be problematic. It is inconsistent with risk assessment practice in other industries and is often challenged from a technical perspective (eg, NTSB report on San Bruno). It is also, a significant cause of confusion in modeling interactive threats.

Here is the issue.  Most would consider a ‘threat’ to be synonymous with failure mechanism. Several of the ASME B31.8S listed ‘threats’ are not failure mechanisms while others are. Some are potential weak points or locations of ‘increased vulnerability’ and must be treated differently in a risk assessment. Manufacturing defects, construction defects, and equipment defects are not failure mechanisms–they do not cause failure. They however represent potential weaknesses or potential initiation sites for certain failure mechanisms. For example, fatigue or corrosion could act as an underlying failure mechanism to grow a lamination or pipe seam/weld imperfection; or an external force could concentrate stress on a wrinkle bend or gasket to a point where it becomes a point of failure.

Practitioners of risk assessment often attempt to treat the B31.8S ‘stable’ threats—which are actually locations of potential weaknesses—in the same way they treat bona fide failure mechanisms. This has led to confusion and inaccurate risk modeling. The recognition of inappropriate consideration of ‘threat interaction’ is one example of problematic application of the threat categories as currently stated. Therefore, a re-classification of these ‘threats’ is imperative.

Recognizing the difference between failure mechanisms and potential weak spots largely resolves issues of ‘threat interactions’ in a risk assessment. By coupling the likelihood of a failure mechanism being active AND occurring at a weak spot, that interaction is captured.

Pending full revision of the listed threats, the following high level change to the threat categories is suggested (with accompanying clarification language, to be proposed later):

• • Time-Dependent
  • Time-Independent
  • Potential Strength Reductions

Note: many alternative labels for the ‘stable’ category have been suggested and might be appropriate. Examples include:

• Potential Resistance Issues
• Possible Weaknesses
• Special Vulnerabilities
• Special Susceptibilities
• Locations of Increased Susceptibility

Another alternative would be to discuss this category separately from the failure mechanisms discussion, thereby not listing it as a third category but rather as an entirely separate issue to cover in a risk assessment.

Regardless of specific label or how to treat it in the text, this category must be differentiated from the actual failure mechanism categories, somehow capturing that these are components in a pipeline system that must be treated as specific locations with potentially increased vulnerabilities to certain failure mechanisms.

Proposed Changes to 5.5(a) Risk Assessment

This paragraph is in conflict with the objectives of IMP. The “fairly simple” approach mentioned cannot support required IMP tasks and is not consistent with IMP objectives.

For example, both remaining life estimates and mitigation effectiveness valuations are implicitly mandated by IMP and are most appropriately conducted within the IMP risk assessment. Most of our older, relative models were not designed for the analyses rigor specified in IMP.

Proposed Changes to 5.5(b) and (c) Risk Assessment

The discussion of four possible RA approaches in Section 5.5 mischaracterizes risk assessment and needs to be largely removed. ALL acceptable risk assessments should use SME’s, scenarios (the underpinnings of our understanding), and should be probabilistic in nature. So, those three–SME, scenario, probabilistic–are not really ‘approaches’ but rather ingredients in any and all acceptable risk assessment. Implying that a different level of rigor is associated with each approach further complicates the issue.

The suggestion is to avoid labeling risk assessment methods. There are no universally agreed upon labels—ie quantitative, semi-quantitative, qualitative, scoring, indexing, probabilistic, deterministic, mechanistic, etc are examples of labels that are used, but do not add clarity.

Also, consider replacing the removed language with a list of minimum essential elements in any risk assessment. A full guideline on how to perform pipeline risk assessment would be a huge undertaking, difficult to produce, use, and be a basis for audits. This prompts the suggestion for a minimum ingredients list, to ensure a pipeline risk assessment, regardless of specific underlying methodology, is sufficiently robust for IMP. See Essential Elements for an example.

Proposed Changes to 5.7(i) Risk Assessment

We suggest the removal of paragraph 5.7(i) dealing with weightings.

The use of weightings is very problematic, creating possibilities for incorrect risk estimates. They are largely unnecessary and counterproductive in a modern risk assessment. However, B31.8S seems to mandate their use in section 5.7 for both prescriptive and performance based. The difficulties encountered with the use of weightings are discussed below.

A common use of weightings is to create a forecast distribution of future leaks, predicated on past leak history. This can be realistic in certain cases and for large ‘populations’ of pipeline segments over long periods of time.  When a database with enough events is available and conditions and activities along a pipeline are constant and fully represented by the data, the pre-conceived distribution may be a credible forecaster of population behavior. However, one can easily envision scenarios where, in some segments, a single failure mode, uncommon in most other segments, should dominate the risk assessment and result in a very high probability of failure estimate but is artificially, and incorrectly, kept low by the use of the population-based weighting.

Even if the assumed distribution (from which weightings are created) is valid in the aggregate, there will be many locations along a pipeline where the pre-set distribution is not representative of the particular mechanisms at work there. In fact, the weightings can fully obscure the true threat. Consider the often very localized effect of a geotechnical threat.  A model using a distribution heavily weighted towards third party damages and external corrosion forces a bias against recognition of geohazard, even when this threat dominates. Depending on the algorithms used, even if a threat such as landslide was deemed imminent for a certain segment of pipeline, it would probably not be able to numerically dominate the higher-weighted threats. The model would dilute or perhaps even totally obscure this high probability of failure since the numerical change would be virtually unnoticeable.

In addition to masking failure potential at specific locations, the use of weightings can force only the higher weighted threats to be ‘drivers’ of risk, at all points along all pipelines. This is rarely realistic. Risk management can become incorrectly driven solely by the pre-set weightings rather than actual data and conditions along the pipelines. This is a technical error and contrary to the whole intent of IMP.