Reynold's Wrap Up: Why Do We Have So Many API FEMI Standards?

Introduction

In a recent Inspectioneering Editorial Board Meeting, a question was raised that some industry users may want to know why we have so many API Fixed Equipment Mechanical Integrity (FEMI) Standards/Codes/RPs and what triggered the need for them. So, I thought with my 40 years of experience being involved in the API standardization process, I would try to address those questions. Back when I started out in the API standardization process, we had only one Code (API 510) and it was only 12 pages long. Additionally there was a set of Guides for Inspection of Refinery Equipment (GFIORE), a series of 20 or so paper copies in a large binder of these “guidelines” detailing experiential information relating to inspection and maintenance practices with all sorts of refinery equipment, including not only fixed equipment, but also machinery, electrical, instrumentation, PSVs, and more. I believe that the last editions of the GFIORE were published in the 1970s or so and then were withdrawn or superseded by various RPs. Those were the documents on which I “cut my teeth” when it came to educating myself about industry inspection practices that came before the time that I joined the industry out of school in 1968. Some of those documents became precursors for follow-on FEMI RPs for inspection of vessels, PSVs, welding, etc. Much has changed since the time of the original GFIORE and our one Code - API 510.

In this edition of Reynolds Wrap Up, I will try to answer some of these questions:

• Why do we have so many API FEMI standards now?
• How and why did each of them come into being?
• Do we need all of them?
• What is their value to the industry?
• Who approves the need to create them and the eventual contents in them?

Before I get into why some of these specific FEMI standards were created, I will try to answer some of the more general questions above.

API Procedure for Approval of Standards

Every time a new FEMI standard is created, there is an API bureaucratic procedure, based on the ANSI Standardization process, to be satisfied to make sure that the standard is needed and that nearly all of API member companies support it. The vast majority of FEMI standards are initiated by the API Subcommittee on Inspection and Mechanical Integrity (SCIMI) or the API Subcommittee on Corrosion and Materials (SCCM). When a subcommittee believes a new standard is needed or an existing standard needs modification, then a request (SRRR Form) is submitted to the parent API Committee (Committee on Refinery Equipment or CRE) to provide the resources necessary to create the new standard. The CRE then goes through a defined process to make sure that it will be a valuable endeavor and is really needed by the industry before approving the request. Typically, after an investigation and documentation of need, the approval for any new standard is granted by unanimous or nearly unanimous agreement. So, it’s a defined, rigorous ANSI/API work process that is necessary to get the approval of all (or nearly all) API CRE member companies to create a new FEMI standard (or even update an existing standard) based on industry needs.

The vast majority (if not all new standards) come into being because the majority of member companies are in need of a so-called “recommended practice (RP)” or RAGAGEP type document to address an integrity and/or reliability issue that is common to the process/refining industry. Unfortunately, a few of our standards have come into being as a result of the industry experiencing substantial losses (some including explosions, fires, injuries, etc.). Each time a significant FEMI event occurs in our industry, the appropriate API subcommittee tries to learn as much as possible about what happened, why it happened, and how it could have been prevented; and then makes a determination of whether or not the industry needs a new FEMI standard or existing ones need to be improved. In most cases, subcommittee discussions determine that we already have sufficient requirements, recommended practices and/or guidance to cover the issue. But on occasion we do find the need to make improvements in our existing codes/standards or to create a new standard to help FEMI owner-operators avoid future incidents and/or improve their FEMI programs.

Some FEMI standards have come into being because of federal and/or local jurisdictional authorities clamoring for the need. For example, API 653, which covers Tank Inspection, Repair, Alteration, and Reconstruction was created as a result of significant federal and state pressure on the API to create such a standard after an enormous spill of diesel oil from a ruptured tank that contaminated the Monongalia and Ohio Rivers starting on January 2, 1988. Few would deny that the event was an environmental calamity. The challenge to the industry was to have a group of our industry experts create a standard in order to help avoid having such an incident ever occur again, or government bureaucrats would do it for us. So an immediate and intense effort by a large API task group created the first edition of API 653, which was eventually published in 1991.

Indeed, we do have a lot more FEMI standards now than we did when I joined the industry some 50+ years ago. But the needs of the industry have changed dramatically since I joined the industry in 1968, including:

• Industry need to improve reliability and integrity of process equipment for process safety, environmental and competitive needs;
• Too many major industry losses in the 30 years before the turn of the century as a result of FEMI issues;
• Substantially more pressure from the media, jurisdictional authorities, and the result of legal liability claims after a FEMI event involving injuries.

The result of implementing these FEMI standards has been a substantial reduction over time of the type and size of industry incidents being experienced due to FEMI failures. Read that sentence again, as it largely answers the question about whether or not we need all these standards. For example, after API 653 was published (and now in its 5th edition), there has never been another tank rupture incident anywhere near the consequence size of the Monongalia River event, and tank ruptures and large spills due to tank integrity issues are now rare. In 1995, a sister document to API 653 was published (API RP 575 – now in its 4th edition) which contains a lot of practical guidance on inspection and maintenance of existing storage tanks.

Another example of an industry standard created as a result of a major incident that happened on August 2, 1993 at a refinery on Gulf Coast. A carbon steel pipe elbow had been originally installed by mistake in an otherwise specified 5 Cr piping system on a hot oil process. That one elbow then corroded at a somewhat higher rate than the rest of the 5 Cr piping components, resulting in premature rupture and a major fire with two fatalities. As a result of that incident, the industry scrambled to spend multi-millions of USD to upgrade their material verification processes (MVP) and positive material identification (PMI) work processes with the intent to help avoid having such a major incident ever occur again. This incident highlighted the need for a RAGAGEP type standard for material verification for new and existing alloy piping systems, leading to the first edition of API 578 in 1999. Over 30 companies brought data and their experiences with MVP/PMI to the API standardization meetings (SCIMI) which led to the creation of API RP 578 (now in its 3rd edition).

Those are just two examples of FEMI standards that were created to help avoid big incidents in the future after a catastrophic incident occurred that highlighted the need for an API Standard to address the issue. Here are a few more examples of API FEMI standards that have been created or modified to help improve industry FEMI – some based on reactively solving an industry FEMI problem and some with information based on proactively avoiding potential FEMI problems.

Other FEMI Codes/Standards

API 510 & RP 572

In most cases when the need arose to address or improve FEMI work processes to avoid leaks and failures, enhancements are made to our pressure vessel or piping inspection codes as opposed to creating a new stand-alone standard of some sort. Hence, over the years since I have been involved with API Standardization, API 510 has grown from a small, general 12-page document to a much more detailed 10th edition which is 64 pages, plus 7 annexes with over 300 requirements (“shalls”) and many more expectations (“shoulds"). All of these changes/improvements followed the strict API/ANSI Standardization process to make sure they were needed and that the vast majority of member companies (often close to unanimous consensus) agreed with them, i.e., nothing goes into API 510 or any other FEMI standard because a few people had a bright idea and slipped it into a standard while the rest of the members weren’t looking. As such, the standardization process differs greatly from that used by the federal government when they pass bills with all sorts of hidden spending in them. If an issue is too large or complex to be included in API 510 and/or 570 codes, then a stand-alone RP may be justified, and then that new standard will be referenced in our two codes.

API 510 now references its sister standard API RP 572 with another 144 pages of recommended practices for pressure vessel inspection. API RP 572 was created in 1972 to capture some good guidance in the GFIORE chapter on pressure vessel inspection techniques that would have overloaded API 510. Most of the shoulds and shalls for pressure vessel inspection are included in API 510 with more of the recommended practices and guidance included in RP 572. Hence the two documents complement each other and are intended to be used together.

API 570 & RP 574

Up until 1993, there was no process piping inspection code. When API 570 was published, it became the equivalent of API 510, only it addressed the requirements and recommendations for inspection and mechanical integrity of piping systems. Prior to the publication of API 570, one of the outdated chapters of the original GFIORE was converted into API RP 574 in 1990, which then became the sister document to API 570, for the same reasons that API RP 572 is the sister document to API 510. The publication of API 570 was the result of needing a code to address how to avoid the numerous piping incidents in the industry that led to explosions, fires, and injuries in the 1970s and 80s. As with API 510 code, API 570 has grown in size over the last 28 years as member companies have brought forward to SCIMI numerous internal company work practices for consideration by SCIMI to standardize work practices to improve FEMI of piping systems. As a result, the industry is experiencing fewer and fewer significant releases from process piping systems over the quarter century.

API RP 577 & RP 582

API RP 577 and API RP 582 are our two sister welding standards with a lot of recommended practices to promote success when making welds on our fixed equipment. API RP 577 covers welding inspection and welding metallurgy while API RP 582 covers specialized welding issues. Their contents came about as a result of lessons learned by many member companies on weld failures experienced in the industry. As with the previous two codes (510 and 570) and their sister RPs (572 and 574), these two welding standards are a compilation of recommended practices assembled by 50-60 welding engineers/specialists from all over the world to increase the chances of having each owner-user successfully weld on process equipment during fabrication and repairs. The welding guidance in these documents are “worth their weight in gold” in helping operating sites avoid failures that others have experienced. Every site does not have to learn the hard way through trial and error if they follow the good guidance in these documents which is extensively referenced in our two codes (510 and 570). As with all our FEMI standards, without these types of welding standards, each company and each site would have to learn and document their own lessons learned and guidance on how to make successful welds that are less likely to fail in service.

API RP 571 and 970 on Damage Mechanisms and Corrosion Control Documents

These two RPs came about as the need for corrosion control documents (CCDs) became valuable documents for inspection planning, especially after the industry started switching from sweet crude diets to aggressive crudes for economic reasons. In the early days of that switch there were a lot of corrosion failures until refiners began to better understand the need to “alloy up” for handling more aggressive crudes. Several major refining companies started formulating CCDs and experienced the benefits of substantially reduced leaks, failures, and production losses. Hence the API member companies saw fit to standardize valuable information on the 70+ damage mechanisms (now covered in API RP 571) affecting fixed equipment that could then be used to create unit specific CCDs (now covered in API RP 970). So these documents are two more examples of the industry and the API recognizing the need for standards that would help proactively improve FEMI programs at each operating site.

API RP 576 on PRD Inspection and Maintenance

API RP 576 was first published in 1992 but was preceded by a GFIOFE chapter before the first edition. This standard is another good example of a document that has grown in content over time as the industry has improved pressure relieving device (PRD) inspection/testing methodology and technology. As a result, it is very rare that a FEMI event is ever experienced in our industry that resulted from PRD malfunctioning. Hence it appears that following all the requirements and recommendations in API 576 has served the industry well over time in taking care of our last line of defense when it comes to over-pressure protection. Like most other API FEMI standards, API 576 is a vital standard for industry process safety. The 4th edition published in May 2017 contained substantial recommended improvements in the handling, inspection, testing, and management of PRDs.

API RP 580 and 581 on Risk-Based Inspection

These two RPs came along starting in about the year 2000 when the industry started recognizing the value of implementing risk-based inspection (RBI). Many jurisdictions, including the federal government, were leery of RBI because to them RBI meant doing something “risky” – taking more risk in order for money-grubbing oil companies to make more money. They even pointed to the RBI name to indicate that the industry wanted to do something “risky.” Hence the industry felt the need to standardize RBI methodology and make it very clear that RBI was all about controlling and reducing risk, not taking more risk. API 580 was published to provide requirements and recommended practices for any and all forms of RBI to meet in order to be considered a valid method within API requirements and recommendations; while API 581 was published to provide one example of a semi-quantitative RBI methodology that could be the basis for a software program that would meet the requirements of API 580. Hence, these two standards were clearly needed to provide validity of the RBI methodology for inspection planning for those companies looking to graduate from the traditional time-based inspection and condition-based inspection that had been standardized in API 510 and 570 up until RBI came along. One other reason API member companies felt the need to standardize an RBI methodology that would fit the needs of our industry is that the only other industry actively using RBI at that stage was the nuclear industry. But their methodology was overly complex, extremely detailed and tended more toward fully quantitative risk analysis (QRA) which would not have fit the needs of our industry. As a result of these two standards, many owner-operator companies have not successfully implemented RBI at their operating sites with success in managing and reducing FEMI risks.

API RP 583 on Corrosion Under Insulation

API RP 583 came about as a result of the industry having more and more outages as a result of aging insulation systems and resultant corrosion under insulation (CUI), a few releases of which were resulting in process safety incidents. API process safety auditing and data collection on leaks and failures clearly indicated that all sites were struggling with the issue of getting CUI under control and that CUI was responsible for a large percentage of FEMI leaks. Although CUI was already covered to some extent in several existing API standards (e.g., 510, 570, 571, 572, 574), API members believed there was a need for a much more comprehensive standard on CUI inspection and management to help owner-users reduce losses and thereby reduce exposure to process safety incidents from this insidious damage mechanism. As a result, API RP 583 is another good example of a new FEMI standard created to meet a universal industry need.

API RP 584 on Integrity Operating Windows

API RP 584 on integrity operating windows (IOWs) was created when numerous industry leaders recognized the need to identify and set limits on process variables that could lead to FEMI incidents if those variables were not properly controlled. During failure investigations, it was becoming more common to identify lack of IOWs as a significant contributing cause of leaks and failures. Those owner-operators that were leading the effort brought their documented IOW work processes to SCIMI and displayed the success they were having with IOWs in reducing FEMI leaks and failures. Hence, to strengthen the existing PSM effort to create process safety operating envelops that would help avoid FEMI incidents, the API SCIMI created RP 584 (now in its 2nd edition) to add FEMI IOWs to that work process. This is an example of the industry trying to stay a step ahead of incidents with a standard that is meant to proactively prevent potential future incidents by standardizing a work process to strengthen our FEMI programs.

API RP 941 on High Temperature Hydrogen Attack

API RP 941 (8th edition) on high temperature hydrogen attack (HTHA) underwent a substantial improvement after a major HTHA incident on the west coast that resulted in seven fatalities. Additionally, a number of owner-operators discovered that they had experienced HTHA in hot, liquid hydroprocessing services that was not predicted by the current Nelson curves. API 941 was significantly revised to include the lessons learned from these incidents, just as it was back 25+ years ago when the C-1/2Mo curve was dropped from the design curves. So, API 941 is another good example of one of the FEMI standards that has been continually updated from lessons learned in the industry due to incidents experienced by owner-operators as well as reported inspection findings. Plus, the ninth edition has been substantially updated to reflect new knowledge on improved HTHA inspection techniques.

API RP 939C on Avoiding Hot Sulfidation Corrosion Failures

The API RP 939C standard (2nd edition) is another good example of a standard that was substantially updated and improved after a sulfidation fire at a west coast refinery. The standard already had quite a bit of information in it on how to avoid sulfidation corrosion failures from previous lessons learned in the industry, but considerable improvements were made in the 2nd edition published in 2020 as a result of many members reporting on how they handled inspection and QA/QC practices associated with the issue of low silicon carbon steels corroding at a higher rate in sulfidation service. So far it appears that implementation of the inspection techniques detailed in the current edition of RP 939C have been successful in reducing the number of sulfidation leaks/failures in the industry.

Summary and Conclusions

In this issue of the Reynolds Wrap Up, I have tried to answer some questions about why we have a growing list of API FEMI standards and explain why some of them came into being, as well as why they keep getting improved with new lessons learned. I have briefly explained the regimented process in use to justify the creation of FEMI standards using the rigorous ANSI/API standardization process to assemble, approve and publish each new and revised FEMI standard. I have tried to explain what these standards have done for the industry since the days before the turn of the century when big fires, explosions and injuries were all too common and thus gave rise to OSHA 1910.119 section (j) on Mechanical Integrity in 1993 and the creation of the Chemical Safety Board (CSB). If space allowed, I could have included an explanation for how and why each of the 44 FEMI standards covered in the API brochure on “Mechanical Integrity: Fixed Equipment Standards and Recommended Practices” came into being ^[1]. But without covering all 44 FEMI standards published by the API, I have selected examples to illustrate why the API occasionally creates new FEMI standards and why API CRE subcommittees continually update existing standards.

So what are all these API FEMI standards worth? In my humble opinion, they are all very inexpensive compared to the size of the volunteer effort of the hundreds of knowledgeable specialists that it took to compile them; and also very inexpensive compared to what could happen at your site if you didn’t have the valuable information contained in them to help you avoid FEMI incidents. The bottom line is that the existence of all these FEMI codes/standards has substantially reduced the number and size of FEMI incidents in the industry and thereby significantly improved process safety in the industry.

If you still have questions about the need for any of the other 44 FEMI standards or new ones that we are currently working on or should be working on, please forward them to me through the Inspectioneering and I will respond as best I can.

References

1. "Mechanical Integrity: Fixed Equipment Standards and Recommended Practices," 2nd Edition, January 2018, American Petroleum Industry, Washington D.C. 20005-4070.