Abstract
Operating offshore oil and gas facilities is often associated with the threat of emerging corrosion-related issues and the subsequent risk of failures. In order to manage this threat, operators commonly use models to support decision making. In the case of managing the threat of microbiologically influenced corrosion (MIC) and establishing the potential rate of degradation, several models have been developed in the last 15–20 years. However, there are few available methods to systematically map the threat of MIC. This is for many reasons: the highly unpredictable nature of microorganisms, disagreement among scientists and operators regarding which groups of microorganisms 290influence corrosion, and limited knowledge about which (physical, chemical, and biological) factors drive MIC. The models use qualitative, semiquantitative, or quantitative measures to help assess the rate of degradation caused by MIC. Commonly, the rate of degradation is referred to as “MIC risk,” implying that the rate of metal degradation is proportional to the risk associated with system failure. This is incorrect as risk is determined from the probability of failure (PoF) and consequence of failure (CoF); the rate of degradation is merely a factor in the estimation of the PoF. CoF is usually determined in conjunction with the asset operator and varies across the asset systems. The recommended practice DNV-RP-G101 (2010) explains how this is done when establishing a risk-based inspection (RBI) analysis. CoF is not considered in any of the MIC models reviewed in this chapter; instead the focus is on the MIC threat. Often the threat of MIC is identified based on physical, chemical, and biological parameters in the system under investigation. However, other important parameters are the design and operating history of the asset. The models have different approaches to identify the potential for and rate of MIC. Some models base the result on many different inputs, covering physical, chemical, and biological parameters while others only cover biological parameters. Due to scarcity of publicly available data, it is difficult to say which approach gives the most accurate results. In addition, the available information about the specific system under investigation can also differ from one case to another. In other words, decision makers may need to rely on different models when assessing different operating systems. Another important aspect is that, in many cases, the information we have available is incomplete to make a proper decision, and only fragments of data are available. This will also impact the model selection process. Uncertainty in results must not be underestimated. Therefore, data collection is an absolute necessity to enable evaluation of the model input in order to increase the likelihood that the model output yields a meaningful and reliable outcome. It is also vital to ensure the threat is evaluated over time to gain confidence in the models used and how their output relates to actual asset integrity. Since the current models only identify the threat of MIC, decision makers need to put their results into context with other degradation mechanisms in the system in order to manage MIC. This can be done by incorporating the result in other asset integrity procedures/analysis where the CoF is considered. Only when this is done can decision makers take action based on the complete view of the asset integrity risk. This chapter analyzes a number of the key models available and critically discusses them in detail.
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Disclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.