Oil and Gas Pipelines: Integrity and Safety Handbook

By R. Winston Revie

A comprehensive and detailed reference guide on the integrity and safety of oil and gas pipelines, both onshore and offshore

• Covers a wide variety of topics, including design, pipe manufacture, pipeline welding, human factors, residual stresses, mechanical damage, fracture and corrosion, protection, inspection and monitoring, pipeline cleaning, direct assessment, repair, risk management, and abandonment
• Links modern and vintage practices to help integrity engineers better understand their system and apply up-to-date technology to older infrastructure
• Includes case histories with examples of solutions to complex problems related to pipeline integrity
• Includes chapters on stress-based and strain-based design, the latter being a novel type of design that has only recently been investigated by designer firms and regulators
• Provides information to help those who are responsible to establish procedures for ensuring pipeline integrity and safety

• Language: English
• Publisher: Wiley
• Release date: Apr 2, 2015
• ISBN: 9781119019206

Book preview

Preface

The objective of preparing this Handbook was to make available, in one volume, essential scientific, engineering, and technical knowledge on integrity and safety of oil and gas pipelines. The aim was to help ensure the safe operation of pipeline networks that we depend on for reliability in service, deliverability of energy, protection of the environment, and safety of the public.

This book, containing 52 chapters, is divided into the following eight parts:

The breadth of coverage will help make the book useful to engineers, scientists, technicians, and students from a wide range of disciplines. The depth of coverage is intended to meet the needs of those who require a high level of detail. In addition to the case histories presented in Part VIII, there are practical examples with solutions to problems and analytical discussion throughout the book. References to other books, journals, and standards that readers can consult for further information are listed

The 86 authors who have contributed the 52 chapters come from different sectors, industry, academia, and government, and from 14 countries, bringing diverse perspectives to pipeline integrity and a balance of practice and theory.

I would like to convey my thanks to the team of authors for contributing chapters in their areas of specialty. I would also like to highlight the contributions of the reviewers who, in anonymity, reviewed the draft chapters and provided their comments, suggestions, and recommendations for the authors, so as to enhance the quality of the chapters, documenting the current state of knowledge. In addition, the International Advisory Board provided helpful advice and guidance in the preparation of the Handbook.

I would like to thank Bob Esposito, Michael Leventhal, and the staff at John Wiley & Sons, Inc. for their encouragement. The concept for this book was developed in discussion with Bob Esposito about the Banff Workshops on managing pipeline integrity, which I organized over a period of nearly 20 years, beginning with the 1993 Workshop. These Workshops continue to be held biennially.

If this Handbook helps in the quest to achieve the objective that we all share of zero incidents—no incidents, in the world of engineering and business where zero means zero and no means no—then the efforts of the entire team who worked tirelessly in preparing it will have been rewarded.

R. Winston Revie

Ottawa, Ontario, Canada

Contributors

Gusai H. Al-Aithan, Saudi Aramco, Dhahran, Saudi Arabia

Jon Allin, Permasense Ltd., Horsham, UK

Faisal M. Al-Mutahar, Saudi Aramco, Dhahran, Saudi Arabia

Ted L. Anderson, Quest Integrity Group, LLC, Boulder, CO, USA

John A. Beavers, Det Norske Veritas (U.S.A.), Inc., Dublin, OH, USA

Lynsay A. Bensman, Det Norske Veritas (U.S.A.), Inc., Dublin, OH, USA

David H. Boteler, Earth Sciences Sector, Natural Resources Canada, Ottawa, Ontario, Canada

Holger Brauer, Salzgitter Mannesmann Line Pipe GmbH, Hamm, Germany

Stephan Brockhaus, ROSEN Technology & Research Center, Lingen, Germany

William A. Bruce, Det Norske Veritas (U.S.A.), Inc., Dublin, OH, USA

Dean Carnes, Canadian Natural Resources Ltd., Calgary, Alberta, Canada

Homero Castaneda, Chemical and Biomolecular Engineering Department, National Center for Research and Education in Corrosion and Materials Performance, The University of Akron, Akron, OH, USA

Frederic Cegla, Mechanical Engineering Department, Imperial College London, South Kensington, UK

Ljiljana Djapic-Oosterkamp, Statoil, Kårstø, Norway

David Dorling, Starco Engineering, Calgary, Alberta, Canada

Ayman Eltaher, MCS Kenny, Houston, TX, USA

Merv Fingas, Spill Science, Edmonton, Alberta, Canada

Doug Fisher, Willowglen Systems Inc., Edmonton, Alberta, Canada

Ming Gao, Blade Energy Partners, Houston, TX, USA

James Gianetto, CanmetMATERIALS, Natural Resources Canada, Hamilton, Ontario, Canada

Ray Goodfellow, IRISNDT – Engineering, Calgary, Alberta, Canada

J. Malcolm Gray, Microalloyed Steel Institute Inc., Houston, TX, USA

Lorna Harron, Enbridge Pipelines Inc., Edmonton, Alberta, Canada

Shokrollah Hassani, BP America Inc., Houston, TX, USA

Holger Hennerkes, ROSEN Headquarters, Stans, Switzerland

Douglas Hornbach, Lambda Technologies, Cincinnati, OH, USA

Nobuyuki Ishikawa, JFE Steel Corporation, Hiroshima, Japan

John J. Jonas, Department of Mining and Materials Engineering, McGill University, Montreal, Canada

Katherine Jonsson, IRISNDT – Engineering, Calgary, Alberta, Canada

Paul Jukes, Wood Group, Houston, TX, USA

Lynne C. Kaley, Trinity Bridge, LLC, Houston, TX, USA

Christoph Kalwa, EUROPIPE GmbH, Mülheim an der Ruhr, Germany

Russell D. Kane, iCorrosion LLC, Houston, TX, USA

Shawn Kenny, Memorial University, St. John's, Newfoundland, Canada; Carleton University, Ottawa, Ontario, Canada

Leo A.I. Kestens, Department of Materials Science and Engineering, Ghent University, Ghent, Belgium; Department of Materials Science and Engineering, Delft University of Technology, Delft, The Netherlands

John Kiefner, Kiefner and Associates, Inc., Worthington, OH, USA

Gerhard Knauf, Salzgitter Mannesmann Forschung GmbH, Duisburg, Germany

Franz Martin Knoop, Salzgitter Mannesmann Großrohr GmbH, Salzgitter, Germany

Angel R. Kowalski, Det Norske Veritas (U.S.A.), Inc., Dublin, OH, USA

Klaus Kraemer, Vallourec & Mannesmann Deutschland GmbH, Düsseldorf, Germany

Ravi Krishnamurthy, Blade Energy Partners, Houston, TX, USA

Axel Kulgemeyer, Salzgitter Mannesmann Forschung GmbH, Duisburg, Germany

Rolf Kümmerling, Vallourec & Mannesmann Deutschland GmbH, Düsseldorf, Germany

Jason S. Lee, Naval Research Laboratory, Stennis Space Center, Mississippi, USA

John Leeds, DC Voltage Gradient Technology & Supply Ltd., Wigan, UK

Sarah Leeds, DC Voltage Gradient Technology & Supply Ltd., Wigan, UK

Keith G. Leewis, Dynamic Risk Assessment Systems, Inc., Calgary, Alberta, Canada

Brian N. Leis, B N Leis Consultant, Inc., Worthington, OH, USA

Arnold L. Lewis II, Research and Development Center, Saudi Aramco, Dhahran,

Saudi Arabia

Hubert Lindner, ROSEN Technology & Research Center, Lingen, Germany

Brenda J. Little, Naval Research Laboratory, Stennis Space Center, Mississippi, USA

Hendrik Löbbe, Salzgitter Mannesmann Line Pipe GmbH, Hamm, Germany

Jim Mason, Mason Materials Development, LLC, Birdsboro, PA, USA

Brenton S. McLaury, Erosion/Corrosion Research Center, The University of Tulsa, Tulsa, OK, USA

Robert E. Melchers, Centre for Infrastructure Performance and Reliability, The University of Newcastle, Newcastle, NSW, Australia

Rumi Mohammad, Willowglen Systems Inc., Edmonton, Alberta, Canada

Lars Vendelbo Nielsen, MetriCorr ApS, Glostrup, Denmark

Mavis Sika Okyere, Bluecrest College, Kumasi, Ghana

Robert O'Grady, Wood Group Kenny, Galway, Ireland

Alan Pentney, National Energy Board of Canada, Calgary, Alberta, Canada

Roumen H. Petrov, Department of Materials Science and Engineering, Ghent University, Ghent, Belgium; Department of Materials Science and Engineering, Delft University of Technology, Delft, The Netherlands

Ben Poblete, ATKINS, Houston, TX, USA

Daniel E. Powell, Williams, Tulsa, OK, USA

Buddy Powers, Clock Spring Company L.P., Houston, TX, USA

Kathleen O. Powers, Trinity Bridge, LLC, Houston, TX, USA

Gail Powley, Willowglen Systems Inc., Edmonton, Alberta, Canada

Paul Prevéy, Lambda Technologies, Cincinnati, OH, USA

Konrad Reber, Innospection Germany GmbH, Stutensee, Germany

R. Winston Revie, Consultant, Ottawa, Ontario, Canada

Hernan E. Rincon, ConocoPhillips Company, Houston, TX, USA

Kenneth P. Roberts, Erosion/Corrosion Research Center, The University of Tulsa, Tulsa, OK, USA

Randy L. Roberts, N-SPEC Pipeline Services, Business Unit of Coastal Chemical Co., L.L.C./A Brenntag Company, Broussard, LA, USA

Omar Rosas, Chemical and Biomolecular Engineering Department, National Center for Research and Education in Corrosion and Materials Performance, The University of Akron, Akron, OH, USA

Edmund F. Rybicki, Erosion/Corrosion Research Center, The University of Tulsa, Tulsa, OK, USA

John R. Shadley, Erosion/Corrosion Research Center, The University of Tulsa, Tulsa, OK, USA

Abdelmounam M. Sherik, Research and Development Center, Saudi Aramco, Dhahran, Saudi Arabia

Siamack A. Shirazi, Erosion/Corrosion Research Center, The University of Tulsa, Tulsa, OK, USA

Binder Singh, Genesis-Technip USA Inc., Houston, TX, USA

Robert Smyth, Petroline Construction Group, Nisku, Alberta, Canada

Tom Steinvoorte, ROSEN Europe, Oldenzaal, The Netherlands

Larisa Trichtchenko, Earth Sciences Sector, Natural Resources Canada, Ottawa, Ontario, Canada

William Tyson, CanmetMATERIALS, Natural Resources Canada, Hamilton, Ontario, Canada

Neb I. Uzelac, Neb Uzelac Consulting Inc., Toronto, Ontario, Canada

Michael VanderZee, Willowglen Systems Inc., Edmonton, Alberta, Canada

Doug Waslen, Sherwood Park, Alberta, Canada

Nader Yoosef-Ghodsi, C-FER Technologies, Edmonton, Alberta, Canada

Greg Zinter, Applus RTD, Edmonton, Alberta, Canada

Part I

Design

1

Pipeline Integrity Management Systems (PIMS)

Ray Goodfellow and Katherine Jonsson

IRISNDT – Engineering, Calgary, Alberta, Canada

1.1 Introduction

Effective management of pipeline system integrity is essential for safe and reliable pipeline operation. Pipeline integrity management systems (PIMS) provide the overarching, integrated framework for effective pipeline asset management.

Significant failures in both gas and liquid pipelines have made global headlines. Although pipelines are statistically very safe and reliable, pipeline failures have resulted in fatalities, environmental damage, and an erosion of public confidence in the pipeline industry. Some examples of catastrophic pipeline failures that resulted in fatalities include the sweet gas line rupture in Carlsbad, New Mexico, in 2000, the gasoline pipeline failure in Bellingham, Washington, in 1999, and the gas line rupture in San Bruno, California, in 2010. Failures in oil pipelines such as the Kalamazoo River oil spill in 2010, the Red Deer River spill in 2012, and the Mayflower, Arkansas, spill in 2013 also generated significant public concern regarding environmental impacts. Failure investigations have identified that the significant contributing factors to the cause and the size of pipeline releases are directly related to flaws in the company's management systems. As such, an effective PIMS is critical to prevent failures. Additional information on pipeline failures and causes is publicly available on websites such as Pipeline and Hazardous Materials Administration (PHMSA), the U.S. National Transportation Safety Board (NTSB), and Alberta Energy Regulator (AER).

Pipeline integrity management requirements and expectations have been continuously evolving and will continue to change in the future. There is no single correct formula for developing an integrity management system; however, this chapter outlines the fundamental basics of an effective management system that have been successfully integrated in companies across the world. Industry groups such as International Association of Oil and Gas Producers [1] and the American Petroleum Institute (API) [2] have developed guidance documents that can be used as additional references for developing management systems. This chapter covers downstream, midstream, and upstream oil and gas pipelines. Pipelines have different operating practices and different consequences of failure; however, the fundamental principles of an effective integrity management system apply to all pipeline operations.

Although this chapter focuses on PIMS, it is important to note that the pipeline industry is shifting toward safety management systems (SMS), which are more comprehensive than traditional PIMS. For example, SMS emphasize safety culture and process safety management more than conventional PIMS. Significant changes are expected within CSA Z662 Section 3.0 Safety Loss Management to reflect the transition to SMS principles. API Recommended Practice 1173—Pipeline Safety Management System Requirements [2] (Draft Version 11.2 issued in June 2014) is an example of an industry SMS document. The reader is encouraged to review and understand the latest industry and regulatory documents pertaining to both SMS and PIMS. SMS are outside the scope of this chapter; however, PIMS and SMS are closely linked and the principles governing PIMS development can be extended to SMS.

1.2 Lessons Learned and the Evolution of Pipeline Integrity

In the early days of the oil and gas pipeline industry, integrity-related activities such as coating application, cathodic protection, corrosion inhibition, and weld inspection were implemented in response to pipeline failures and incidents. As the pipelines have aged and the size and complexity of pipeline networks have grown, the impact of pipeline failures has increased. More specifically, there is more public awareness and concern regarding pipeline failures. In response, the industry improved prevention, mitigation, monitoring, and inspection technologies for pipeline hazards. For example, coatings have improved, in-line inspection (ILI) was developed (and has since evolved dramatically), corrosion inhibitors have become much more effective, and alternative materials to carbon steels, such as spoolable composites, were developed.

In addition to improving technology, companies started utilizing risk assessments to focus and prioritize integrity management-related activities. Risk assessments provide a more structured and analytical approach to identify and address pipeline integrity issues.

As a result of the combined efforts of technology improvements and risk assessment application, the number of failures in the North American pipeline industry declined significantly. For example, the upstream pipeline failure rate in Alberta declined from 5.0 failures per 1000 km of pipelines in 1990 to 1.5 failures per 1000 km by 2012 [3].

The regulators and the oil and gas industry agree that technological improvements and risk management are positive changes that are reducing the number of failures; however, they also understand that these advancements alone are not sufficient to address all pipeline hazards. Integrity management systems provide a more encompassing and integrated approach to addressing pipeline risks. At the June 2013 National Energy Board (NEB) Pipeline Safety Forum, the NEB paper Emerging issues in oil and gas industry safety management listed three key aspects that must be in place for an effective management system. This paper states that the management system must be

Consistently applied

The system elements are applied consistently across operational programs (worker safety, asset integrity, damage prevention, environmental protection, and emergency management), facilities and geographic regions.

Highly integrated

There are multiple interdependencies between management system elements and so the management system is designed to share information and intelligence to promote better decisions.

Assign accountability

All officers and employees have a role to play in meeting the safety, security and environmental protection goals of the organization. These responsibilities must be clearly assigned and communicated. Performance must be measured and improvement required.

Pipeline failure incident investigations provide important insight into why an effective management system is necessary. The examples below are summarized from pipeline investigations published on regulatory or industry websites describing contributing factors to major pipeline failures:

Lack of training and competency: examples include operator error that led to overpressurization of a system, inadequate inspector training that led to construction-related failures, and incorrect ILI analysis that misinterpreted a defect signal.

Lack of effective change management: examples include production changes that altered corrosion rates, staffing changes that resulted in critical tasks incomplete or communicated improperly, and material substitution that resulted in an unsuitable material being used incorrectly in the wrong environment.

Lack of records: improper or missing/lost documentation.

Lack of understanding hazards: a lack of understanding of potential hazards resulting in an unaccounted for corrosion mechanism that resulted in pipeline failure, and an incorrect assumption of pipeline condition (the pipeline was assumed to be dry but rather the pipeline catastrophically ruptured due to internal corrosion).

As explained above, pipeline failures commonly link to management system failures. Developing and implementing an effective PIMS requires significant, albeit critical, work to prevent pipeline failures due to ineffective management systems. The success of PIMS requires the integration of a company vision, a well-developed structure, and a company safety culture supported by process management. The following sections will define and outline the core structure of an effective PIMS.

1.3 What is a PIMS?

The principles of asset integrity management apply to a wide range of industries, including power generation, aircraft, nuclear, pharmaceutical, transportation, and defense. Common asset management system principles apply to any system with physical assets that are core to achieving the company's business objectives.

There are many industry documents, standards, and recommended practices that describe asset integrity management systems. One standard that is frequently used as a guideline document for asset management is the Publicly Available Specification (PAS) 55 [4], which is administered by the British Standards Institution (BSI). This standard was developed by the Institute of Asset Management and has been adopted by utility, transportation, mining, process, and manufacturing industries worldwide. PAS 55 has been incorporated by the International Organization for Standardization (ISO) and has been updated as the ISO 55000 Asset Management series of standards [5].

In PAS 55-1:2008 [4], asset management is described as

Systematic and coordinated activities and practices through which an organization optimally and sustainably manages its assets and asset systems, their associated performance, risks and expenditures over their life cycles for the purpose of achieving its organizational strategic plan.

An organizational strategic plan is described as

Overall long-term plan for the organization that is derived from and embodies its vision, mission, values, business polices, stakeholder requirements, objectives and the management of its risks.

Figure 1.1 demonstrates the interdependencies of company vision/strategic plan, the management system structure, and the company culture. All three elements are required for success.

Figure 1.1 PIMS: vision, structure, and culture.

In the oil and gas industry, assets can include pipelines, pressure equipment, piping, and tanks. Integrity management systems can be developed for the conventional oil and gas assets mentioned, and can also extend to rotating equipment, electrical, and structural systems.

The purpose of pipeline integrity management is the effective execution, documentation, and communication of the technical work throughout the pipeline life cycle, and PIMS provides the framework (structured and integrated system elements) to execute effective pipeline integrity management. The technical programs can include, but are not limited to, quality control and inspection, cathodic protection, ILI, chemical inhibition, coating selection, excavation (dig) programs, corrosion monitoring, and river block valve maintenance. These are the activities that require plans, programs, processes, and procedures to be managed, scheduled, executed, tracked, documented, communicated, and reported.

There are multiple interdependencies between the many functions within an organization. Effective integrity management requires the cultural aspects of understanding, communication, and collaboration between operations, engineering, management, finance, and safety—in fact, almost every function within an organization through business unit integration. A great technical program may fail for one of the following reasons: people are not trained and competent, change is not effectively managed, key information, records, and documents cannot be found, and roles and responsibilities are not clearly defined.

1.4 Regulatory Requirements

The codes, standards, and regulations that govern the pipeline industry continue to change in response to lessons learned from industry failures. These regulatory documents provide a defined basis that is used by industry to deter-mine pipeline integrity requirements. It is important to realize that regulatory changes take time and typically lag public expectations and industry practices of progressive companies.

Companies often fall into the trap of building their integrity management systems to meet, but not exceed, regulatory requirements. In the 2013 NEB Safety Forum, Jeff Weise, Associate Deputy Director of PHMSA, commented to the audience that regulatory requirements are ‘the floor’ on which you stand and meeting regulatory requirements is nothing to be proud of. He emphasized that companies need to be proud of their safety and performance achievements, not of meeting minimum requirements. If you are only meeting regulations, then you are already well behind the industry leaders and good integrity management practices.

Regulatory requirements fall into two very different categories. The specific and prescriptive shall and must aspects of regulations provide clearly defined minimum requirements. For example, the AER Pipeline Rule that the licensee of a pipeline that crosses water or unstable ground shall at least once annually inspect the pipeline right of way is easy to understand and apply. The minimum compliance is therefore one right of way (ROW) inspection a year; however, an effective and comprehensive approach to risk management suggests that companies conduct ROW inspections at an appropriate frequency for their operating conditions. The appropriate frequency can be quarterly or monthly, and in some cases, operators perform daily aerial surveillance to mitigate risk.

The second category of regulatory requirements is more general and requires interpretation. Regulations regarding management systems require each company to interpret the intent and incorporation of the stated requirement. For example, the management systems requirement for management of change (MOC) is only prescriptive in the sense that MOC is required. Each company must determine what specifically is required to ensure MOC exists in their organization, including documenting, communicating, and archiving MOC documentation such as the MOC process or completed MOC forms. Logically, MOC for a small upstream company may be simpler than MOC for a major transmission pipeline company.

Regulations for management systems, on the other hand, are more general and require each company to interpret how to meet the intent of the stated requirement. For example, a regulatory audit investigates a company's document and records management system. The audit may determine that yes, there is a document and records management system and it meets the audit requirements. However, this conclusion does not mean that the company has an effective system that ensures all critical records, documents, and information are verified and are readily accessible for use in supporting risk assessment, fitness for service, MOC, and other important processes. From a process maturity perspective, an adequate system is a long way from a more mature competent or excellent system.

A maturity grid approach can be used to determine a system's relative state. A maturity grid is a description of the characteristics/criteria of the company operating at various levels of maturity; for example, maturity levels may include Innocence, Awareness, Understanding, Competence, and Excellence. This is a qualitative assessment technique that can provide an effective way of communicating and illustrating the current state of the management system as well as the future state that the management system aims to achieve. This approach has been used in many industries and a good example can be found in the book Uptime: Strategies for Excellence in Maintenance Management [6]. There can be a staged approach to achieving the desired level. For example, a company may wish to first achieve Understanding and then implement a plan to progress to Competence or Excellence.

It is important for each company to evaluate major inci-dents and review their own programs for weaknesses and deficiencies. Canadian and U.S. regulatory and industry bodies (such as the NTSB, AER, NEB, and PHMSA) will include interim directives, current incident investigation reports, and other communications on industry lessons learned. It may also be beneficial to consider regulations and industry practices that are not mandatory in the regulatory regime in which your company operates. Other pipeline or industry regulations and practices may be in a more advanced state or may contain useful approaches to more comprehensive integrity management systems. As previously mentioned, the API Recommended Practice 1173 addresses process safety management and safety culture in more detail than this chapter provides, and the reader is encouraged to review this document for additional information.

1.5 Core Structure and PIMS Elements

All pipeline companies have some degree of a PIMS in place; however, the PIMS elements typically are not fully integrated between business units and/or not effectively executed. So, what does a fully integrated and effectively executed PIMS look like? As mentioned in Section 1.1, there is no single right PIMS; however, the purpose of this chapter is to introduce a method to effectively structure and develop a PIMS.

A complex, interdependent system such as a PIMS can be difficult to describe and illustrate. One common way to represent a dynamic PIMS is using a Plan–Do–Check–Act (PDCA) cycle. The PDCA cycle can be drawn and interpreted in many ways and the reader is encouraged to customize the approach used here to meet their own needs. The PDCA cycle shown in Figure 1.2 has been adapted and modified from PAS 55-1:2008 [4]. PAS 55 describes the importance of strategic planning (Plan), program enable and execution (Do), assurance and verification (Check), and management reviews (Act). In this chapter, we will examine each of these sections in terms of what they mean and present ideas for development.

Figure 1.2 Integrity management Plan–Do–Check–Act cycle.

The center circle in Figure 1.2 represents the ongoing PDCA cycle that must be in place to keep the integrity management system functioning to mitigate both asset and business risks. For clarification purposes, the primary inputs into the ongoing integrity management cycle are illustrated as arrows feeding into the circle. The PDCA cycle inputs include the following:

New asset design–fabrication–construction–commissioning that tie in the asset life cycle.

Improvement opportunities from outside the company to illustrate adopting industry lessons, new technology, and new concepts.

Inputs that can impact asset integrity planning such as changes in company objectives, significant regulatory changes, new acquisitions, and so on.

1.6 PIMS Function Map

A function map, such as that shown in Figure 1.3, is another method that can illustrate the PIMS core elements. The intent of Figure 1.3 is to provide an overview of common elements; as such, it must be customized for each company. The same four elements of Figure 1.2 (Plan–Do–Check–Act) are incorporated into Figure 1.3. Function maps are particularly useful for structuring and organizing the systems a company uses to execute asset management activities.

Figure 1.3 Pipeline integrity management system (PIMS) function map.

1.7 Plan: Strategic and Operational

Figure 1.4 shows an expanded function map for the Plan element. Operational planning for integrity programs includes both annual activities and longer term strategic plans. In addition, operational planning often coincides with the annual budget cycle. An annual budget is created for ILI and excavations (digs), cathodic protection, risk assessments, scheduled training, facilities programs, and line replacements.

Figure 1.4 Plan function map.

Strategic planning is a more comprehensive exercise and must incorporate lessons learned from management reviews as well as changes in corporate objectives and plans for new major projects or acquisitions. Strategic planning includes considering new concepts and ideas, addressing long-term risk reduction, and ensuring new major initiatives are properly planned and resourced. Strategic planning is about stepping back and ensuring there is a long-term focus on sustaining and improving integrity programs.

Strategic planning should also include the assessment of new technology, participating in joint industry projects, and funding research and development projects. In addition, technologies, ideas, and concepts from outside the oil and gas industry may provide a long-term benefit to the organization.

A strategic plan is more comprehensive than a 1-year annual budget cycle. Strategic plans often forecast multiple years in advance to plan the progressive advancement of key initiatives to improve pipeline integrity programs. For example, if a company's goal is to move from Innocence to Excellence (using a process maturity perspective) for information management, strategic planning would outline a multiyear approach and achievable targets to progressively advance the information management system at a manageable pace. Another example of strategic planning is the divestiture of low-value but high-risk pipeline assets.

1.8 Do: Execute

The Do cycle shown in Figure 1.3 has three main components, which are expanded in Figure 1.5. The Do section includes the core life cycle technical activities that address pipeline hazards, documentation, and communication.

Figure 1.5 Do (execute) function map: risk management, enable, and life cycle.

Risk management is a key element of integrity management and determines how pipeline risks are assessed and controlled by the organization. Risk management is a comprehensive framework of principles, processes, and procedures to ensure the safety and integrity of pipelines and facilities.

The ISO 31000:2009 [7] standard for risk management provides principles, framework, and a process for managing risk that can be applied to pipeline integrity. Risk man-agement is not a stand-alone activity that is separate from the main activities and processes of the organization; rather, risk management is a part of management's responsibilities and an integral part of all organizational processes, including strategic planning and all project and change management processes.

Risk management includes identifying threats, hazards, and/or degradation mechanisms that could lead to failure, characterizing risks, prioritizing actions, and executing risk control from design and construction through mitigation, monitoring, and inspection programs.

An effective risk management process will include the following:

Process management to ensure effective execution and integration of the processes and supporting activities throughout the organization.

A common understanding and effective communication between operations, engineering, maintenance, asset integrity, and other groups regarding their respective roles, responsibilities, and contributions to achieving safe and reliable operations.

Defined physical and operational threats that could result in product release that could potentially have serious safety, environmental, production, or regulatory impacts.

Processes to assess risks and guarantee that the appropriate prioritized controls are in place to reduce the likelihood of a release and to limit the consequence if a release occurs.

Defined requirements to assess and continuously improve the risk management process through internal reviews, incident investigations, and the use of key performance indicators (KPIs). This may include developing metrics and defining categories (bounds) to indicate performance levels.

Enable processes are those that provide the support structure for pipeline integrity work. They are the common management processes that are used to guide and support the work activities, and they are applicable to all aspects of the company's business. Examples include MOC, training and competency programs, and information management.

The effective execution of these processes is essential for a successful PIMS. These processes need to be in place to ensure that the knowledge, skills, and tools are available to manage risk and support the life cycle elements. As previously mentioned, failures still occur in companies that have corrosion controls and inspection programs in place; however, important hazards are still missed or are not properly addressed, so their risk management programs are ineffective for all relevant hazards. Examples of significant contributing factors to pipeline failures include a lack of training and knowledge, inadequate documentation and records management, and poorly applied MOC.

Life cycle processes of a management system include the technical processes and activities that are required to effectively execute integrity programs and activities. Life cycle processes are the technical core of pipeline integrity activities, and include the technologies and activities that are directly applied to the pipeline to prevent failures. For pipeline integrity, the activities and tasks can be broadly grouped into design and construction, maintenance (mitigation, monitoring, and inspection activities), assessment, and abandonment.

Design and construction includes materials selection, life cycle design, fabrication inspection, construction quality control, and commissioning that must be completed before a pipeline (new and repaired) is transferred to operations. Integrity issues that are built into a pipeline (such as weld seam defects, poorly applied coatings, construction dents, and incapability with ILI tools) either create additional hazards to manage during operation or limit the ability of operations to manage hazards. A well-thought-out life cycle design and the elimination/reduction of fabrication and construction defects can significantly improve pipeline safety and reliability.

Maintenance life cycle processes include mitigation (cathodic protection and chemical inhibition), monitoring (corrosion coupons and slope stability), and inspection (ILI, direct assessment, and ROW surveillance). These are the primary operation activities to address and control potential pipeline hazards such as external and internal corrosion, geotechnical hazards, and cracks.

Assessment processes are in place to ensure all hazards are understood and addressed, fitness for service methodology is applied to pipeline defects, and sound engineering judgment is used to make good decisions based on operation, monitoring, and inspection data.

Discontinue and abandonment processes are required to ensure end-of-life programs are in place and any residual hazards due to a pipeline are addressed.

1.9 Check: Assurance and Verification

The next element in the PDCA cycle is the Check (assurance and verification) step. This element includes external audits, internal reviews or assessments, incident investigation, and research and development. This also includes external inputs such as new technologies, industry lessons learned, involvement in joint industry projects (JIPs), and participating in industry task forces. Figure 1.6 outlines the expanded function map for the Check element.

Figure 1.6 Check: assurance and verification.

The Check part of the PDCA cycle is critical, but often not well executed. During a review of major incidents, the NEB determined that capturing lessons learned and implementing learnings is an area often overlooked. The quote below is from NEB Safety Forum 2013 paper titled Emerging issues in oil and gas industry safety management:

The assessment indicted that while most organizations involved in the accidents had management systems or programs developed, they were not effectively implemented or reviewed on a regular basis to ensure adequacy and effectiveness.

A well-thought-out internal review process can be a useful way to assess the internal process and program effectiveness. The internal review process should include both the traditional audit check (are we doing what we say we are doing) and a way of measuring or quantifying effectiveness. The highest value obtained from an internal assessment will be a measure of program effectiveness and recommendations for improvements. A maturity grid or other assessment models can be used to support the assessment of effectiveness.

1.10 Act: Management Review

The Act portion of the Plan–Do–Check–Act cycle is shown in Figure 1.7. The management review is an assessment of the outcomes of pipeline integrity work, including performance measures, audit and review results, reviews of major projects, outcomes from participation in industry task groups, and evaluation of important company and industry lessons learned. Management reviews can be conducted annually or as a more frequent, less formal, assessment.

Figure 1.7 Act: management review.

Many companies have a dashboard summary report for senior management. The objective of a dashboard is to succinctly communicate a few key metrics that represent the ongoing performance of the pipeline integrity program and represent a status or progress gauge. The metrics or performance measures incorporated in a dashboard are often tied to a company's specific safety, reliability, and production targets.

Management reviews often include high-level assessments such as a summary of the top 5 risks. This allows the most significant risks to the company to be understood and addressed at senior level in the organization. Addressing these risks can become part of the company's strategic plan.

Management assessments provide direction for future activities. This direction can be expectations for process changes, audit improvements, and training requirements. The outcomes of the management reviews can be used to determine changes required or additional resources to support integrity programs or as inputs into longer term strategic plans.

1.11 Culture

The processes, procedures, skills, knowledge, and technologies required for pipeline integrity management are only one part of an effective PIMS; the other critical aspect is a process safety culture. Safety can be considered in two ways: occupational safety that addresses personal safety issues such as slips, trips, and falls and process safety that addresses preventing releases of any substance (ruptures and leaks) that could lead to injury/fatality and/or environmental damage. Process safety started in the chemical process industry after a series of serious equipment-related failures that resulted in numerous fatalities such as the Bhopal, India, disaster. Process safety includes both the mechanical integrity of the equipment and the safety culture required to ensure that the structure and company culture are aligned.

The importance of a safety culture is emphasized in CSA Z662 Safety Loss Management [8] and in API Recommended Practice 1173 [2]. As detailed in Section 1.1, the pipeline industry has had far too many major failures resulting in public fatalities (Carlsbad, Sand Bruno) and environmental damage (Kalamazoo, Red Deer River) [9]. Pipeline operators have been adopting process safety and cultural change into their overall approach to pipeline integrity management, with the goal to minimize, and ultimately eliminate, pipeline failures.

This overview of PIMS provides the framework and ties together the supporting processes and procedures to provide the overall structure to ensure pipelines are designed, built, operated, and maintained in a way that achieves pipeline safety and reliability. The functions described in the PIMS include the roles, responsibilities, and accountabilities that, when fully understood and implemented, can drive culture change.

1.12 Summary

To be effective, a PIMS must be fully integrated within a company's core business functions. The multiple interdependencies within an organization regarding integrity management need to be defined and understood. Operations, engineering, asset integrity, and many other groups have essential roles in achieving safe and reliable operations. The responsibilities and accountabilities must be clearly assigned and communicated.

In addition to role clarity between departments, the PIMS elements must be applied consistently across all operational departments, facilities, and geographic regions. The risks associated with lower value assets need to be understood and managed with the same diligence as high-value assets. The elements of integrity management should have the same focus and attention as the company's commitment to personal safety and production targets.

The PIMS is a comprehensive, continually improving and evolving system that is essential to achieve safe and reliable operations. The PIMS does not need to be overly complex or heavily dependent on processes—it is fundamentally a simple system intended to effectively manage risks and assets. If companies create too much structure and implement complex controls, the system can become bogged down and rendered ineffective. PIMS can be successful if the interdependencies and relationships of the elements shown in Figure 1.2 are understood, the processes are in place to support these elements, and the roles and responsibilities are defined. The system requires regular reviews, assessments, and improvements to ensure it will continue to be effective and, as a result, both the company and the pipeline industry will change for the better.

References

1. International Association of Oil and Gas Producers (2008) Asset integrity: the key to managing major accident risks. Report No. 415. Available at http://www.ogp.org.uk/pubs/415.pdf.

2. API (2014) API Recommended Practice 1173: Pipeline Safety Management System Requirements.

3. Alberta Energy Regulator (2013) Pipeline Performance in Alberta, 1990–2012. Report 2013-B. Available at http://www.aer.ca/documents/reports/R2013-B.pdf.

4. British Standards Institution (2008) PAS 55 Specifications for Asset Management. PAS 55-1:2008—Asset Management Part 1: Specification for the optimized management of physical assets. PAS 55-2:2008—Asset Management Part 2: Guidelines for the application of PAS 55-1.

5. ISO (2014) ISO 55000 Standards for Asset Management. ISO 55000 Asset management—Overview, principles and terminology. ISO 55001 Asset management—Management systems—Requirements. ISO 55002 Asset management—Management systems—Guidelines for the application of ISO 55001.

6. Campbell, J.D. and Reyes-Picknell, J.V. (2006) Uptime: Strategies for Excellence in Maintenance Management, 2nd ed., Productivity Press (Figure 1-8: Maintenance maturity grid).

7. ISO (2009) ISO Standards for Risk Management. ISO 31000:2009, Risk management—Principles and guidelines. ISO Guide 73:2009, Risk management—Vocabulary. ISO/IEC 31010:2009, Risk management—Risk assessment techniques.

8. Canadian Standards Association (2011) CSA Z662-11: Safety Loss Management.

9. Hayes, Jan and Hopkins, Andrew (2014) Nightmare Pipeline Failures: Fantasy Planning, Black Swans and Integrity Management, CCH Australia Limited, Sydney, Australia.

2

SCADA: Supervisory Control and Data Acquisition

Michael VanderZee, Doug Fisher, Gail Powley, and Rumi Mohammad

Willowglen Systems Inc., Edmonton, Alberta, Canada

2.1 Introduction

The daily operation of pipelines has long since been computerized by "SCADA" (supervisory control and data acquisition) systems. In its simplest definition, SCADA is a computer network that gathers real-time pipeline operational data and brings them into a control room for humans to view and make control actions on [1]. In other words, SCADA can be thought of as the eyes and ears of the people who control the pipeline. SCADA has brought measurable and tangible benefits to the owners and operators of pipeline assets, most notably in terms of pipeline integrity and safety due to the real-time nature of the SCADA control systems. SCADA can and should be deeply integrated into a pipeline company's safety protocols and incident avoidance and mitigation.

Due to the proven benefits that SCADA provides to pipeline owners as well as to the environment and public at large, SCADA systems are considered mission-critical and vital equipment to pipelines. In fact, most jurisdictions around the world have legislated that SCADA systems be installed as a necessary part of all petroleum pipeline systems.

The SCADA system consists of several parts, including sensors, RTUs/PLCs, computer servers, computer workstations, communications infrastructure, computer networking equipment, and various peripherals (such as a GPS accurate time reference source). Some equipment is, by necessity, located out at field site locations, whereas the focal point of the SCADA system is located in one or more pipeline control rooms. Common terms used in SCADA are defined in Table 2.1.

Table 2.1

SCADA Terminology and Definitions

Unfortunately, the industry use of the term SCADA is somewhat ambiguous; some use the term to refer only to the software displaying operational data in the pipeline control room (such as pressures, temperatures, densities, and flow rates), whereas others using the term also include the sensors and the RTUs. In this chapter, the term SCADA will be used in reference to both the pipeline control software and the RTUs that sit out in the field and interface to the sensors.

SCADA systems can generally be classified as either enterprise-level or simpler HMI systems. HMI SCADA systems are less capable and historically were limited to real-time data gathering and presentation, whereas full-fledged enterprise SCADA goes further by including many additional features. Examples of features distinguishing HMI and enterprise-level SCADA would be the following:

Retention of past data values in a historical database.

Interfacing to other corporate software (e.g., pipeline scheduling, leak detection, accounting, and ERP).

Ability for additional emergency backup control rooms.

The quantity of I/O points the SCADA system can manage.

Hardened system to protect against hackers and cyber threats.

A human factors interface to avoid human operator error and enhance efficiency.

Ability to replay historical events captured by the SCADA system for incident review or training.

Operator training scenarios.

Advanced alarm management.

Operator shift handover report.

Rapid polling of screens being viewed by operators.

Interfacing to related computer systems such as leak detection, batch tracking, energy management system, equipment maintenance systems, and pipeline hydraulic simulation.

Sometimes, there can be confusion with those not familiar with the industry about a similar product called DCS (distributed control system). Although very similar in many regards in that both SCADA and DCS ultimately collect and display data from sensors in a real-time fashion, DCS was designed to be used in processing plants where the physical distances between sensor and computer control system are relatively small and often used to manage a process (such as refining crude oil into products such as jet fuel and diesel). SCADA, on the other hand, can span almost any geographical distance. Large pipelines often exceed 5000 km in length with sensors spread across the entire length, and this is the domain of SCADA systems, whereas DCS would not be able to do this.

2.2 SCADA Computer Servers

The backbone of the SCADA equipment in the control rooms is the SCADA server computers. These computers communicate with and gather data from the RTUs and PLCs out in the field, maintain the SCADA real-time database, maintain a historical database of past values, interface to other computer systems, and generally do everything except providing the graphical interface for the human SCADA operators [2].

Best practices for maximizing pipeline integrity require that each SCADA server contain internal redundancy in the form of dual power supplies, RAID hard drives, dual Ethernet interfaces (connected to dual SCADA LANs), and possibly dual CPUs.

To further the concept of redundancy, SCADA servers are delivered in pairs so as to provide a main unit and a hot standby. A good SCADA system will improve upon this by load sharing between the two servers under normal circumstances, and reverting to one or the other server if either should fail.

SCADA servers may be Windows based, but UNIX servers are often better suited to industrial applications such as SCADA due to the Windows operating system not having been designed for real-time applications.

In all but the smallest SCADA systems, the servers are usually delivered without video display, mouse, or keyboard. Rather, they are normally rack-mounted computer hardware providing the background work of the SCADA system. The SCADA system's user interface is provided through the SCADA workstations.

2.3 SCADA Computer Workstations

The SCADA workstations exist to present the GUI to the human operators and this is the method through which pressures, temperatures, flow rates, and other parameters are displayed. SCADA workstations are often outfitted with multiple LCD panels with the specific arrangement designed with the physical control room layout in mind. Common arrangements are 2 × 3, 1 × 4, and 2 × 2.

The quantity of SCADA workstations in each control room should be a function of the pipeline operations and is proportional to the length of the pipeline(s) being controlled (larger companies usually have a network consisting of numerous pipelines all being controlled from within one control room). Obviously, the minimum is one SCADA workstation, whereas the largest pipeline control rooms contain upward of 30 SCADA workstations.

Due to the client/server software model, SCADA workstation hardware need not be as hardened as the SCADA servers. Often high-end off-the-shelf PCs are the best choice for SCADA workstations. Usually the most important parameter of the SCADA workstation is its graphics ability, which is a function of the video card in the computer.

Although there is no need for high fidelity, most SCADA systems produce alarm sounds when a process variable exceeds its nominal range. As such, SCADA workstations should have volume-adjustable audio capability.

At present, the human operator interfaces with the SCADA workstation mostly by use of the mouse and, to a lesser extent, the keyboard. However, emerging trends are increasingly augmented with haptic touchscreens [3].

2.4 Hierarchy

Enterprise-level SCADA systems should be able to be implemented in a hierarchical fashion. In a large distributed system, it may be desirable, for example, to have completely independent SCADA systems for each separate region, but a higher level master SCADA system that receives summary data from each of the lower SCADA systems, thus forming a hierarchy. In fact, this idea of a hierarchy of SCADA systems can consist of more than just two levels; conceptually, it should support three or more levels, for example, SCADA at a municipal level, then provincial level, and finally national level. Or alternatively a pipeline company could have separate SCADA systems for its gas pipelines versus crude pipelines versus liquid product pipelines, and an overall SCADA system on top whose database is the sum of the three lower level SCADA systems.

Depending on the pipeline operator's needs, it is not always necessary to push the entire database up to the next level of hierarchy. Instead, it should be possible to identify the specific data in the lower level database that are needed in the higher level database. Thus, by picking and choosing data points, a customized summary of data can be pushed up to the next level of hierarchy.

From a pipeline integrity point of view, one benefit this approach can provide is additional personnel to observe and review operations in real time.

2.5 Runtime and Configuration Databases

Although not universal in all SCADA systems, best practices in SCADA technology require that there be separate databases for the live runtime data and the system configuration. The main reason for this is to allow for system changes to be made, and possibly tested out on a development server before being committed to the runtime system. Any SCADA package that does not provide this database separation will have system development being done on the live runtime (production) database. Obviously, the consequences of making an error when editing a database are more severe if those changes are made on the live runtime database.

The purpose of the configuration database is to hold the SCADA system parameters. This would be information such as how many RTUs and PLCs there are, how many I/O data points each contains, the computer address of each one, the log-in user IDs for each human SCADA operator, and generally all system information.

The purpose of the live runtime database is to use the configuration database as a framework, but to populate it with live data.

These two databases are linked through a process called a commit.

The best SCADA systems will offer a feedback mechanism between the live runtime database and the configuration database. The meaning of feedback in this context is a software mechanism to allow the human SCADA operators to fine-tune certain system parameters on the live runtime database and to have those parameters automatically updated in the offline configuration database. This is a unique and uncommon action as the data flow is normally from the offline configuration database into the live runtime database. Feedback is normally automated for only a small subset of the overall system parameters.

2.6 Fault Tolerance

In any SCADA system that includes interfacing to more than a single RTU or PLC, it is an important design criterion that the SCADA host should be fault tolerant. The general design question to ask is: Is there a single component (software or hardware) that if it fails will prevent SCADA from monitoring and controlling the critical field devices? Note that a failure of a single RTU will prevent monitoring and control of field devices connected to that RTU, but should not affect the other RTUs, and so usually failure to communicate with a single RTU is not considered critical. However, if there is a single RTU that is considered critical, then that RTU itself should have some fault tolerance built into it, such as a dual communication line, a dual processor, or the entire RTU could have a hot standby RTU.

The simplest level of SCADA fault tolerance is called cold standby and is achieved by providing two identical pieces of hardware installed with identical software. If any component fails, then the failed device is manually swapped out with the spare from the cold standby. As this requires a skilled technician on call, the main drawback of this method is the time it takes to fix a problem, and the second drawback is that it requires a regular maintenance step to ensure that the spare devices are working properly and available to be swapped in. The second level of fault tolerance is called warm standby. It is similar to the cold standby setup, but the hardware is physically installed and running. If any component fails, it should be set up so that it can be easily swapped out as a whole unit by moving a switch or moving some cables. This significantly shortens the time to fix a problem, and lessens the requirements for the technician who initiates the swap. The warm standby still should be checked regularly to make sure it is functional. In this setup, there are often procedures that must be followed after a switchover as the most current configuration might not be installed on the warm standby computer and recent information such as current process variable set points would have to be reentered. The third level of fault tolerance is called hot standby. It is similar to the warm standby setup except that databases on the two hosts are kept up to date and it is possible to easily switch control between the two computers. How up to date the hot standby server is varies by SCADA vendor and can be as little as a fraction of a second to as high as several hours old. For a hot standby setup, the communication links to the RTUs must be designed to be easily switched from one SCADA server to the other. Ethernet connections are fairly easy to switch over; serial connections will require a changeover switch. In this setup, the SCADA host software should be able to automatically initiate a swap if it detects a failure of the active host, or the operator should be able to initiate a swap. The fourth level of fault tolerance is called function-level fault tolerance. It is similar to hot standby except that if a single function fails, for example, a serial port used to talk to an RTU, it is no longer necessary to fail over the entire host computer. In this mode, individual SCADA features can be swapped over from one server to another. This makes an overall SCADA system much more tolerant of small failures and makes it much easier to test standby hardware. This also opens up possibility for load sharing when a standby would otherwise be unused. In any fault-tolerant system, it is very important that the standby hardware be tested on a regular basis. The most reliable means of testing this is by initiating a swap on a regular basis such as once a month. Depending on the hardware, it might be possible to test backup lines automatically. For example, to test backup communications to an RTU, the RTU must be able to support talking with two hosts at the same time. Remember that a backup system that is never tested is very likely to not be working when it is really needed and thus would not provide any fault tolerance.

2.7 Redundancy

Beyond the above-mentioned software concept of fault tolerance, physical redundancy is one of the most effective tools a pipeline operator can employ to improve pipeline safety and integrity. The basic notion is to provide two pieces of equipment to do a single job: a main and a backup. This concept of main and backup can be simultaneously employed at three levels. The lowest level of physical redundancy exists within the computer servers themselves. The SCADA servers should be designed with dual power supplies, dual Ethernet interfaces, RAID hard drives, and dual CPUs.

Once each SCADA server is built with inherent redundancy, the second step is to provide not just one such server but two such SCADA servers in the control room. In this way, even if one SCADA server is rendered ineffective, a backup SCADA server remains available to take over. This is important because even though many components of each server are provided with a backup, not all components are. For example, the motherboard itself is not redundant. Although it is unlikely that all those components would fail, if they did fail, then the entire SCADA server would be out of commission and so it makes sense to have a backup.

Beyond these is the third and final level of redundancy, which is redundancy of entire control rooms. This is a growing trend in SCADA systems and has legitimate value. History has shown that natural forces can be unpredictable and intense. Threats of tsunami, earthquake, tornado, fire, hurricane, and so on make an entire control room vulnerable. Even if a control room contains two SCADA servers, each of which has redundant components, a tsunami will knock out both servers if it knocks out one, hence the logic for a second control room situated some distance away, often 50–100 km distance between control rooms.

Although the concepts of fault tolerance (described above) and redundancy overlap, there do exist some differences.

Clearly, the best approach is to use both redundancy and fault tolerance.

2.8 Alarm Rationalization, Management, and Analysis

Alarms notify human operators about abnormal situations, so they can respond in a timely and effective manner to resolve problems before they escalate. Studies have shown that the ability of operators to react to alarms depends largely on how well alarms are rationalized and managed.

In the early days of SCADA, alarms had to be hardwired to physical constructs such as flashing lights and sirens. These physical limitations forced designers to be very selective about which alarms to annunciate. In comparison, modern software-based alarms are often considered free. This creates a common mindset where anything that can be alarmed upon is configured to do so. The result is a SCADA control room with a constant overload of alarms, often unnecessary or unimportant, which operators are expected to filter through when searching for real alarms with serious consequences.

Efficient alarm management begins with proper alarm rationalization. Every alarm configured in the system must be considered carefully by a team of experts with operational domain knowledge. Consequences with regard to safety, finance, and the environment must be factored in. The goal is to create as few alarms as possible, while accounting for all serious consequences. The approved alarms and procedures for responding to each alarm should be captured in a master alarm database (MADB), which is then periodically reviewed by the team. The MADB serves as the foundation for configuring alarms within the SCADA system [4].

Alarms must capture an operator's attention, and depending on the severity of the alarm, this is done using a combination of graphic effects such as flashing colors and repeated sounds. It should be easy for the operator to distinguish the process variable in alarm from other process variables that are not in alarm. For example, a red flashing border stands out against an otherwise gray screen. Operators should then examine and acknowledge the alarm. Information that can help the operator react to the alarm should be easily accessible from the context of the alarm.

A summary list of recent alarms helps operators identify when an alarm occurred, the nature of the alarm, its severity and scope, whether it is still in alarm, and whether an operator has acknowledged it. A searchable list of historical alarms helps both operators and analysts to track alarms over long periods of time to detect important patterns. These lists can be filtered and sorted.

Sometimes, alarms need to be suppressed. Operators can suppress alarms for a short period, for example, when a sensor is temporarily malfunctioning. Alarms can be configured to be suppressed for long periods of time, for example, when a point is still being commissioned. Dynamic logic can also suppress alarms, for example, suppressing a low-pressure alarm for a pipe when the corresponding valve is closed.

Long-term operational use reveals badly configured alarms. There is an arsenal of techniques to correct these configuration issues, based on analysis of recurring trends. Analog alarms that constantly chatter between low and high values can apply deadbands to mute the noise. Digital alarms that quickly switch states multiple times can apply on-delays and off-delays to stabilize the state transitions. Incidental alarms for a device power outage can be presented as a single group of alarms. Analytical tools can hone in the most frequent offenders, which when dealt with can reduce unnecessary alarms by large percentages. As established earlier, fewer alarms make alarms more manageable for operators in real-time environments.

2.9 Incident Review and Replay

In any SCADA system, situations will arise that management will want to have reviewed to find out what exactly happened and whether the operator had sufficient information available to properly handle the situation. A SCADA system should provide tools to make it possible to review these situations. Some SCADA systems include audio recorders on all phone lines and radio channels for this kind of review. It is also possible to record the operator screens to verify whether the operator went to the correct screens to diagnose a problem. The disk storage requirements for this are quite high, so the number of hours of storage will have to be limited. There are also potential personnel issues with this level of monitoring, which should be carefully reviewed.