Proposal for Individual Damage Mechanism Risk Calculation in API 581

This updated article presents a proposal for an enhanced risk analysis method that enables individual damage mechanism risk calculations. This approach allows each mechanism's risk to be compared to a defined Risk Target, which, when reached, would automatically generate a corresponding inspection task with its own due date. Its references are still related to API 581 version 3 which I have not updated, but the calculations reference are the same.

Background

API 581 is an excellent recommended practice for risk-based inspection (RBI). Its methodology allows the Owner/User to calculate risk by both damage mechanism and component, and to use that information to prioritize inspection activities.

However, as effective as API 581 is, the question remains: Does it truly optimize inspection task scheduling and, by extension, Maintenance and Shutdown planning?

In my professional opinion - no, it does not. There are further opportunities to optimize the process and improve planning efficiency.

Current Risk-Based Inspection Approach

To understand this position, it's important to review how risk-based inspection prioritization is currently performed. According to API 581 Version 3, Part 1, Section 4.3.1, 1st paragraph, risk is calculated as follows:

4.3.1 Determination of Risk

In general, the calculation of risk is determined in accordance with Equation (1.6), as a function of time. The equation combines the POF and the COF described in Sections 4.1 and 4.2, respectively.

R(t) = P_f(t) ⋅ C_f

(1.6)

The resulting risk is then compared to a Risk Target set by the Owner/User.If the calculated risk reaches the target before the planned inspection date, inspection tasks are generated, with the due date corresponding to the point at which the target was reached.

So far, so good but the details matter.

Where the Current Approach Falls Short

Once calculated, the Consequence of Failure (COF) generally remains constant (based on the four hole sizes defined in API 581). In contrast, the Probability of Failure (POF) - which depends on the degradation rate inputs for each damage mechanism - can vary significantly with each inspection.

This means the POF is the most dynamic driver of risk over time. To understand this further, let's examine how P_f(t), the total Probability of Failure, is determined:

The Existing API 581 POF Calculation

From Part 2, Section 3.1:

3.1 Overview

The POF is computed from Equation (2.1).

P_f(t) = gff_total ⋅ D_f(t) ⋅ F_MS

(2.1)

In this equation, the POF, P_f(t), is determined as the product of a total generic failure frequency (GFF), gff_total, a damage factor (DF), D_f(t), and a management systems factor, F_MS.

Since both gff_total and F_MS are static, we focus on D_f(t), which changes with inspection data. According to Part 2, Section 3.4.1, paragraph 2, D_f(t) consists of the following damage mechanisms:

DF estimates are currently provided for the following damage mechanisms.

1. Thinning - D^thin_f-gov
2. Stress Corrosion Cracking (SCC) - D^scc_f-gov
3. External Damage - D^extd_f-gov
4. High Temperature Hydrogen Attack (HTHA) - D^htha_f
5. Mechanical Fatigue (Piping Only) - D^mfat_f
6. Brittle Fracture - D^brit_f-gov

Combining Damage Factors in the Current Method

API 581 combines multiple damage mechanisms according to Part 2, Section 3.4.2, Subsection a):

3.4.2 Damage Factor Combination for Multiple Damage Mechanisms

1. Total DF, D_f-total - If more than one damage mechanism is present, the following rules are used to combine the DFs. The total DF is given by Equation (2.2) when the external and/or thinning damage are classified as local and therefore, unlikely to occur at the same location.

   D_f-total = max[ D^thin_f-gov, D^extd_f-gov ] + D^scc_f-gov + D^htha_f + D^brit_f-gov + D^mfat_f

   (2.2)

   If the external and thinning damage are general, then damage is likely to occur at the same location and the total DF is given by Equation (2.3).

   D_f-total = D^thin_f-gov + D^extd_f-gov + D^scc_f-gov + D^htha_f + D^brit_f-gov + D^mfat_f

   (2.3)

   Note that the summation of DFs can be less than or equal to 1.0. This means that the component can have a POF less than the generic failure frequency.

Regardless of which equation is used, all remaining mechanisms - SCC, HTHA, brittle fracture, and fatigue - are implicitly assumed to occur at the same location.

The Core Issues

There are a couple of core problems with the current method:

1. Unrealistic Co-location Assumptions: In practical plant experience, different damage mechanisms rarely occur at the same location. Summing DFs assumes otherwise and therefore over-simplifies real degradation behavior.
2. Composite POF Drives Identical Due Dates: Summing all DFs yields a composite damage factor, and therefore a composite POF, which is then applied uniformly to all mechanisms. This causes all inspection tasks—regardless of mechanism—to share the same due date, even though their degradation rates and risk trajectories differ.

The Proposed Enhancement

To address these issues, I propose modifying Equation (2.1) to allow individual damage mechanism POF calculations:

Here, D_f(t, Ind) represents the individual damage factor for each mechanism (thinning, SCC, external damage, etc.).

Consequently, the individual risk for each mechanism becomes

Each R(t, Ind) would then be compared to the Risk Target independently, generating separate due dates and inspection scopes for each mechanism.

Why This Matters

This modification enables:

1. Mechanism-specific inspection intervals reflecting real degradation behavior.
2. More efficient resource allocation, since inspection frequency aligns with each mechanism's actual risk growth.
3. Improved shutdown planning, as inspection tasks can be staggered instead of lumped together.
4. Consistent risk tolerance, since the same Risk Target is still applied.

Conclusion

In summary, applying individual damage mechanism risk calculations within the API 581 framework offers a logical and data-driven way to refine inspection planning.

This approach could better optimize inspection resources and reduce unnecessary work, all while maintaining equivalent risk levels.

I believe this methodology should be offered as an optional workflow within API 581, complementing the existing one rather than replacing it.

Some Questions and Comments from the Original Article:

Since our original post, we have received a variety of comments and questions. Here we consolidate those into one location. We hope you will keep them coming.

Question: One of the deviations we incorporated into DNVrpG101, and the resulting ORBIT software, was to allow the user the ability to isolate the driver of the LoF risk factor. Later versions of the API software presented this as well, as it was always in there, if one knew where to look. Since the inspection type will differ depending on the damage driver, it makes sense to granulate them for the user. The overriding logic of not revising the RP was that by combining the DFs, a more conservative next inspection date would be generated, however, this conservative limit would not prevent a user from identifying the most relevant inspection technique, aligned with the DM contributing the greatest to the resulting LoF. Greater clarity is always of value, and improving the transparency a novice user has to the underlying LoF drivers is a good thing, however, it might be a hard sell to API to revise the RP, since it does not "as written", prevent the user from implementing inspection plans based on this approach, as long as the next inspection date is on or less than the one produced by the current combined DF results. Best of luck, and thanks for the continuous improvement activities, wrt API RBI.

Response: John, thank you for the comments. I agree with you that the values are there, and it is not precluded in the RP. However, there are many RP users that mistakenly believe that as long as I follow the methodology to the letter, if an incident occurs, the regulators will not hold their company responsible. This might keep them from thinking that dealing with the damage mechanism risk independently is possible without understanding that no written prohibition exists. That is why I proposed this as an option so that they can explicitly see it in the RP. Thank you for your comments, I hope we can keep up the dialogue.

Question: For sites with existing total damage factor approaches, the individual damage factor approach will be a lot less conservative and could not be justifiable to internal and external stakeholders (as suddenly inspection dates are pushed out). Do you have other validated data that you can share that the individual damage factors although being less conservative is actually sufficient in managing the mechanical integrity?

Response: I challenge you on the concept of less conservatism. The example risk target of 35 ft2/yr is pretty conservative. If risk is analyzed for each damage factor as per API 581, without a plan date, each will progress to the example risk target on its own. This generates a different target date for each damage mechanism. As part 1 indicates, just using the calculation target dates are not enough. Remaining life should be considered as well as the Owner/Users acceptable risk policy. I have no data to share on the conservatism on this idea, but my thoughts when I wrote the article was that the 35 ft2/yr would take care of this along with the other factors I have mentioned.

Question: Thoughts on cases, where specific locations have more than one damage factors applicable?

Response: I think they should remain separated with the possible exception for Internal and External Thinning/CUI where both aren't "localized". I would combine the internal thinning and external thinning damage factors for this case.

Question: Thoughts on reducing the risk targets for accommodating individual damage factors? (So it is not portrayed as a less conservative method).

Response: If risk is analyzed for each damage factor as per API 581, without a plan date, then instead of using the same 35 ft2/yr risk target, they could be tailored to suit the owner's needs. This is where the owner/users acceptable risk policy comes in to specify these risk or other targets.

Be the first to comment

There are no comments for this article.