551
Chapter
9
Liquid PiPeLine OPeratiOn
The operations directly related to hydraulics are covered in Section 5.1 and batch op-erations in Section 5.2. This chapter discusses various techniques and tools necessary to improve safety and efficiency in operations; SCADA, leak detection, DRA injection, tank farm operation and volume measurement, and power cost control.9.1 SUPERVISORY CONTROL AND DATA
ACQUISITION (SCADA)
9.1.1 Introduction
Pipeline systems are automated to provide the capabilities of operating pipeline sys-tems reliably, efficiently and thus economically. Pipeline operation involves moni-toring and controlling of a pipeline system, and monimoni-toring is required for checking the pipeline states and controlling facilities such as pump and valve stations. Modern pipeline system operation is centralized because a centralized operation of the pipe-line systems benefits the stakeholders including the pipepipe-line company, producer of the product, and the shipper of the product. A centralized system provides the capability to monitor and control the complete pipeline system in a safe and efficient manner. It allows the stakeholders to meet the changing demands for the product being shipped expediently and to move the product from source to market safely and quickly in the most economical way possible. A SCADA system provides the pipeline companies with centralized monitoring and controlling capabilities [1].
SCADA is an acronym for Supervisory Control and Data Acquisition; supervisory because human operators always issue control commands, not providing a closed-loop control function. A SCADA system is a computer-based data acquisition system de-signed to gather operating data from an array of geographically remote field loca-tions, and to transmit this data via communication links to one or more control center location(s) for monitoring, controlling, and reporting.
A SCADA system is designed to assist pipeline operators in the operation of the pipeline system using real-time and historical information. Pipeline operators typically regulate pipeline pressure and flow, start and stop pumps at stations, and monitor the status of pumps and valves through the SCADA system. Local equipment control sys-tems monitor and control the detailed process for the pump and its associated driver. They may then issue commands of a supervisory nature to the remote locations in response to the incoming data. Additionally, software programs implemented within the SCADA host can provide for specific responses to changes in field conditions, by reporting such changes or automatically sending commands to remote field locations.
Pipeline system control is accomplished by setting a controlling variable at the desired level and the control system responds to reach the set point. Depending on the controlling functions, the controlling variable can be pressure, flow, and sometimes temperature. The controllers monitor and change the controlling variables through the SCADA system, which transmits the control signals to remote stations such as pump,
lifting, delivery or valve station. Figure 9-1 illustrates the relationship between the master and remote terminal through the computer and communication system.
Traditional SCADA users include the pipeline system dispatchers or controllers, oper-ation engineers, system engineers, maintenance and measurement staff. System dispatchers use the SCADA for safe and efficient pipeline system operation while meeting transporta-tion requirements. Operatransporta-tions engineers analyze pipeline operatransporta-tional problems to increase operation reliability, efficiency, and throughput as well as troubleshooting, while system engineers configure and maintain the SCADA system including instruments and remote terminals. Maintenance staff analyzes equipment performance based on historical data, and measurement staff validates volume measurements.
Current business environment requires fast access to operational information. As a result, other groups use the SCADA data to improve the pipeline business. These groups include accounting personnel who account liquid volumes and issue invoices, liquid marketers who use estimated batch data to schedule and market liquids move-ments, and management who make management decisions regarding normal and ab-normal conditions including emergency situations.
In order to accommodate a rapidly changing business condition or environment, corporate-wide information access has become critical to the efficient operation and management of a pipeline system. Not only is it important to provide accurate informa-tion to operainforma-tion and management staff, but timely access to this informainforma-tion is of vital importance to the successful operation of the pipeline company’s business. Companies that are able to acquire, process, and analyze information more efficiently than their competitors have a distinct market advantage. Such expansion of the scope, function-ality, and capabilities is made possible by continuing improvements in computer and telecommunication technologies.
A properly designed, installed, and operating SCADA system is a keystone in the operation and management of a pipeline in today’s competitive deregulated pipeline market. The SCADA system has become the hub for corporate information systems. Refer to Figure 9-2 for an overview of an integrated corporate and SCADA system. Looking at the information requirements of a pipeline company and considering both operational and business aspects, the key requirements can be broadly grouped into the following categories [2]:
Measurement information
· — Measurement information is used for the safe and efficient operation of the pipeline system. It includes pipeline data
Master
(Host) TerminalRemote
Data Acquisition
Supervisory
and
Hardware/Physical
Software/Protocol
acquired from field telemetry equipment such as volumes, flows, pressures, temperatures, product quality, and equipment status. It would also include any calculated data originating from the SCADA host.
Simulation information
· — Simulation information incorporates measurement data and simulated data to diagnose current pipeline states and predict future behavior of the pipeline. The simulation information can be used for system optimization, line pack and capacity management, storage management, prod-uct scheduling, and training-related applications on the pipeline system. This data would originate from a modeling application that may use measurement information.
Business information
· — Business information combines measurement data
and possibly simulated data along with business and economic data. The infor-mation is used in business applications related to custody transfer, preventative maintenance, cost tracking, contracting, marketing, inventory, scheduling and accounting. This is where SCADA and simulation data are aggregated with other business data to feed into business processes.
Decision support information
· — Decision support information is a summary
of the key measurement, simulation, and business data required for executive level decision support. Extracting this key data is generally the function of a Management Information System (MIS). Such a system has the ability to gather and aggregate data from numerous corporate and operational databases to supply key performance data.
It is becoming more and more common for pipeline applications to be tightly integrated with SCADA systems and to be part of a higher level Management Informa-tion System (MIS). The advances in computer and communicaInforma-tion technologies have made it much easier to connect SCADA systems to business systems. This allows for both physical integration of SCADA and business systems as well as business process
Enterprise Resource Planning Volume & Revenue Accounting Internet/
Intranet MarketingSales/ Corporate User Level Operation User Level Corporate Database Historical Database SCADA Pump/ Compressor Stations Meter
Stations Storages Pipeline & Valves Interface Field Level (PLC, RTU) Real-Time Applictions Non-Real-Time Applications Real-time Database
integration. Process integration means that SCADA systems are becoming a key part of business processes. This provides for both proactive business processes as well as the ability to provide better information and thus better service for customers.
9.1.2 Pipeline System Monitoring and Control
The pipeline system has to be monitored for control. The control of a pipeline system is achieved mainly at pump stations located in a tank farm and along the pipeline, meter stations in receipt and delivery locations, and valves along the pipeline and in these stations. In addition, flow direction and tank levels in a tank farm have to be monitored and controlled. Therefore, their status and values have to be monitored first and then controlled if required.
Pump station monitoring and control
· — Since a pump is a primary
pres-sure control device, the pipeline prespres-sure is controlled by starting or stopping pump units or adjusting the pressure set point at the operating pump station. Most pump stations are equipped with multiple pump units. Depending on the pressure or flow requirements, the operating pumps can be arranged in series, parallel or a combination of series and parallel through open/close operations of valves. The pump station pressure generated by fixed speed pumps are con-trolled by a control valve at the station, while the pressure generated by vari-able speed pumps is controlled by the pump rotation speed. Refer to Chapter 4 for a detailed discussion of pump station control.
Pipeline monitoring and control
· — The main function of a pipeline control
system is to monitor flows, pressures, and sometimes temperatures along the pipeline. Pipeline companies receive nominations, schedule volumes, and lift and deliver them by controlling flow rates while maintaining the pipeline pres-sure within the operating prespres-sure limits and the flow rates within the capacity. Valves along the pipeline are used to change the flow direction, isolate some sections of the pipeline, or open other sections. The quality of the products has to be monitored and batch movements have to be tracked for proper delivery.
Meter station monitoring and control
· — An active pressure control does not
take place at a meter station. Instead, the flow rate and volumes are monitored to control the flow directions to an appropriate location such as tank or pump. The most important function of a meter station is custody transfer by providing metering information.
Tank farm monitoring and control
· — Petroleum products are either lifted at
or delivered to a tank farm. A tank farm is composed of multiple tanks, booster pumps, meters, valves and piping. The correct product should be lifted from the correct tank at the injection station and delivered to the correct tank at the correct tank farm. The product movement, flow direction, and tank level have to be monitored and controlled by opening or closing various valves along the flow path to make this happen.
9.1.3 Control Center and SCADA System
Since the SCADA system plays a critical role in the success of the pipeline business, it must satisfy the following requirements:
Capability to operate the pipeline system safely and economically, ·
Provide timely and accurate data for monitoring and controlling the pipeline ·
Be reliable with high availability, ·
Provide security, protecting valuable corporate information from inside and ·
outside intruders.
Most modern SCADA systems can provide the functionality to meet these re-quirements. However, the combination of the SCADA system together with its control center should be configured to fulfill them.
There are three basic tiers in a SCADA system as shown in Figure 9-2, namely, field device, control room, and corporate. The field to SCADA connection is some form of a telecommunications network, and the connection between SCADA host and the corporate or enterprise environment is made with a communication network. A backup control center located at an offsite may be connected to the main control system.
In US, PHMSA incorporates American Petroleum Institute (API) recommended practices 1165, 1167 and 1168, which are the recommended practices for Pipeline SCADA Displays, Pipeline SCADA Alarm Management, and Pipeline Control Room Management, respectively. Each document describes the following:
API RP 1165 — Pipeline SCADA Displays [3] focuses on the design and im-·
plementation of displays used for the monitoring and control of information on SCADA.
API RP 1167 — Pipeline SCADA Alarm Management [4] provides guidance ·
on industry practices that include alarm definition and determination, alarm philosophy, alarm functionality and design, alarm handling, alarm documenta-tion, alarm audit and performance monitoring, roles and responsibilities, man-agement of change, etc.
API RP 1168 — Pipeline Control Room Management [5] addresses pipeline ·
control room personnel roles, guidelines for shift turnover, pipeline control room fatigue management, and pipeline control room management of change. The operational nerve center of today’s pipelines is the pipeline control center. It is from this central location that a geographically diverse pipeline is monitored and operated. It is also the center for gathering information in real time that is used for real-time operation, for making business decisions and for operational planning. Figure 9-3
Figure 9-3. Control Console (Cerda J., 2008, “Oil Pipeline Logistics” Instituto de Desarrollo
Tecnológico para la Industrial, August 11–21, Mar del Plata, Argentina, http://cepac. cheme.cmu.edu/pasi2008/slides/cerda/library/slides/jcerda-pasi-2008-1page.pdf )
shows a modern control console that the pipeline operator uses for minutes by minutes system operations. Usually, several large screens are made available to monitor the entire pipeline system.
Since the control center provides real-time information, it may also include an emergency situation-room adjacent to the control room. This room may be dedicated to addressing dispatching issues and particularly to resolving emergency or upset con-ditions. Several stakeholders, including technical support and management, may be assembled to address emergencies.
A backup control center may be required in order to operate the pipeline sys-tem continuously in the event that the main control center is severely disrupted. This backup is normally in a physically separate location from the main control room. The backup center is equipped with the same equipment and devices as the main control center. One option is that the backup system receives the real-time data directly from the field devices each cycle, so that it is the exact replica of the primary system. The other option is that the entire backup system is refreshed with the required data re-ceived from the primary system at a regular interval.
The division of control between a central location and the local pump station var-ies widely. A large complex pipeline system may be divided into multiple control sec-tions defined in terms of size of the pipeline network, complexity of the network, or number of shippers. This division allows the operators, assigned to each section, to efficiently monitor and safely control the pipeline system.
A control center houses most of the equipment used by the operators on a daily basis. The equipment required includes the SCADA system computers and terminals, printers, communication devices, and network equipment used to implement Local Area Networks (LAN) and/or Wide Area Networks (WAN). In addition, pipeline sys-tem maps and schematics may be displayed, and operator manuals and other informa-tion required for performing dispatching funcinforma-tions can be made available.
A SCADA system consists of three main components; host or master, commu-nication system, and remote terminals. A SCADA host or “master” is a collection of computer equipment and software located at the control center and used to centrally monitor and control the activity of the SCADA network, receive and store data from field devices and send commands to the field. A SCADA system gathers the data from a variety of field instrumentation, typically connected to remote terminals. See Figure 9-4
for a modern SCADA architecture of both the main control center and backup control center.
The architecture of SCADA systems can vary from a relatively simple configura-tion of a computer and modems to a complicated network of equipment. In whatever form it takes, however, SCADA architecture will incorporate the following key hard-ware and softhard-ware capabilities:
Ability to interface with field devices and facilities for control and/or monitor-·
ing, usually through remote terminals.
Provision of a communication network capable of two-way communication be-·
tween the remote terminals and the control center. This network might also pro-vide communication between the control center and a backup control center. Ability to process all incoming data and enable outgoing commands through a ·
collection of equipment and software called the SCADA host. Modern SCADA systems provide additional capability:
Business applications such as meter ticketing, volume accounting, nomination ·
management, etc.
Application software such as leak detection, inventory management, and training ·
Interface to corporate systems ·
The network is normally an internal private network. However, there are now SCADA systems that utilize secure connections to the Internet that replaces the private network. Web-based SCADA systems are ideal for remote unattended applications, as-suming that an RTU or flow computer is available. In other words, they are suitable to pipeline systems or remote locations where centralized computing or control require-ments are not intense and the primary function is remote data gathering. A web-based SCADA system offers several benefits. The main advantages are as follows:
It provides an economical solution with wireless technology using the Internet ·
infrastructure.
It allows data access from anywhere without extra investment in communica-·
tion and software.
Here, it needs to be mentioned that a distributed control system (DCS), instead of a SCADA, can be used for controlling pipeline systems. The goals of DCS and SCADA are quite different. A DCS is process oriented. It looks at the controlled process (the gas processing plant or chemical plant) as the center of the universe, and it presents data to the operators as part of its job. SCADA is data-gathering oriented; the control center and operators are the center of its universe and the remote equipment is merely there to collect the data — though it may also do some very complex process control.
DCS systems were developed to automate process control systems. These systems are characterized by having many closed loop control elements controlling an analogue process in real time. The key differences and characteristics of DCS and SCADA are as follows:
A DCS normally does not have remotely (i.e., off-site) located components ·
and is always connected to its data source. Redundancy is usually handled by parallel equipment.
SCADA needs to have secure data and control over a potentially unreliable ·
known good values’ for prompt operator display. It frequently needs to do event processing and data quality validation. Redundancy is usually handled in a distributed manner.
A DCS does not poll data but rather needs to be able to process a high number ·
of transactions at a high speed in order to implement multiple real-time closed loop control.
The majority of operations, such as start/stop commands and alarm detection ·
of a SCADA system are digital. They also gather/poll analogue readings but do not implement closed loop control; humans determine if set points need to be adjusted. A DCS is process control oriented and therefore is designed to be able to implement many control loops as well as standard operator initiated start/stop commands.
When the DCS operator wants to see information, he usually makes a request ·
directly to the field I/O and gets a response. Field events can directly interrupt the system and the operator is advised automatically of their occurrence. The remote terminals are located where the process values are monitored and interfaced with the host SCADA. They can be a remote terminal unit (RTU), program-mable logic controller (PLC), or flow computer. The remote terminals collect data from the process devices, transmit data to the host SCADA, receive supervisory commands from the host SCADA, and issue these commands to the process devices. Supervisory commands may include pump/compressor station or unit start and stop commands, valve opening and closing commands, and set point settings.
An RTU acquires process values independent of the host by scanning hardware and software points, and communicates with the host, field I/O points, and other com-puter systems. It can detect and report alarm conditions, which include I/O error, bad measurement, high/low limit violations, rate-of-change alarm, and other deviations from set-points. An RTU provides limited control functions at field devices. The func-tions range from simple on-off or open-close control to logical control sequences such as ESD. It supports diagnostic checks with diagnostic software running in the remote watching for a number of possible problems. Some RTUs provide electronic flow measurement capability, by performing calculations of AGA, API and other standards, storing the measurement data, and allowing instant access of the measurement data.
A PLC provides extensive control, communication and operator interface capa-bilities. PLCs are used as remote terminals on a SCADA system, the heart of station control for field equipment (pumps, drivers, lube oil systems), communicating with the host. At a pump station, it can perform all the monitoring and control functions of pump unit and driver, station valve, station suction and discharge, station electrical and auxiliary equipment. It may have its own memory for the data to be transferred, or logic control for the gathering of data and error-checking with the host. PLCs can also be networked to provide a complete control system for a complex station.
It has to be noted that DCSs are not only economic for large installations but can be a solution choice for larger pump stations. They would certainly be considered for installations where there is a station and an associated processing facility or a refinery that would utilize a DCS for its control. The traditional boundaries between various control system solution options have become blurred due to the flexibility of today’s control equipment. For small systems, the control system will generally be imple-mented using a PLC. As the facility gets larger and more complex, several options are now available of choosing between installing a control system using networked PLCs or a DCS system, requiring a careful consideration to ensure the operating require-ments are met while at the same time the design dovetails with corporate business information gathering and processing.
Reliability and availability requirements particular to individual installations will determine the configuration of redundant SCADA and database computers and redun-dant networks. Reliability provides an indication of how frequently a system or device will fail, while availability is the amount of time a system is fully functional divided by the sum of the time a system is fully functional plus the time to repair failures. Figure 9-5 illustrates a fully redundant SCADA architecture, in which both computer and communication systems including the associated equipment are duplicated.
SCADA host software architecture is different for every product. However, they all have the following key components:
Operating system such as Unix, Windows or Linux ·
Relational database for historical data management, interfacing with corporate ·
databases
Real-time database for processing real-time data quickly ·
Real-time event manager, which is the core of the SCADA ·
HMI manager for user interfaces ·
In addition, various utilities and development software are important for system development, configuration, and maintenance.
The SCADA will manage the polling of data, processing of that data and the pass-ing of it to the real-time database. It will make data available to the presentation layer consisting of the HMI Manager and interfaces to other applications, as well as process control and data requests.
9.1.4 Data Communications
Data communications for a SCADA system require various components; modem, pro-tocols, network, transmission media, and polling. A modem is an electronic device that encodes digital data on to an analog carrier signal (a process referred to as modulation), and also decodes modulated signals (demodulation). This enables computers’ digital data to be carried over analog networks, such as the conventional telephone network. In general, modems are used for the connection between an RTU and the SCADA
SCADA MASTER A (PRIMARY) SCADA MASTER B (BACKUP) OPERATOR WOKSTATION 1 OPERATOR WOKSTATION 2 ARCHIVE SERVER A ARCHIVE SERVER B LAN A LAN B TERMINAL SERVER A TERMINAL SERVER B CROSSBAR SWITCH
network or where it is not feasible to have a high-speed network, connection directly to the RTU.
In the context of data communication, a network protocol is a formal set of rules, conventions, and data structure that governs how computers and other network devices exchange information over a network. In other words, a protocol is a standard proce-dure and format that two data communication devices must understand, accept, and use to be able to exchange data with each other. A wide variety of network protocols exist, which are defined by worldwide standards organizations and technology vendors over years of technology evolution and development. For a retrofit or upgrade project, it is important to ensure that the SCADA system can support all of the protocols that exist in the legacy equipment that will be connected to the SCADA system. In some cases where there may be proprietary protocols, converters may need to be implemented. On a new SCADA system, there is no need to be concerned about existing equipment and protocols. However, it is important to ensure that the SCADA system utilizes in-dustry standard protocols and not just proprietary ones. This will make expansion and addition of new equipment easier. It will also provide more flexibility in being able to choose equipment from a wide range of vendors and not be tied to a specific vendor’s equipment.
A SCADA system will usually incorporate a local area network (LAN) within a control center and one or more wide-area networks (WANs). The major improvement in current generation SCADA systems comes from the use of WAN protocols. Not only does this facilitate the use of standard third party equipment but more importantly it al-lows for the possibility to distribute SCADA functionality across a WAN and not just a LAN. In some WAN distributed systems, pipeline controls are not assigned to a single central location. Instead, control operations can be switched or shared between numer-ous control centers. Responsibilities can be divided vertically according to a control hierarchy or horizontally according to geographic criteria. In both cases co-ordination and integration of control commands issued from various centers are maintained. In the event of the loss of one or more control centers, the operation can be switched to another center.
The SCADA network requires some form of communication media to implement the WAN connection between the SCADA host and remote locations. Ultimately the choice of which media to use to implement a connection to a remote site will be based on cost, availability of a particular medium and technical factors such as reliability, data transfer rate, geography, etc. A second choice to be made is whether the commu-nication should be leased from a 3rd party or owned and operated by the pipeline company. This decision needs to be consistent with the corporate IT and operating guidelines. Commonly adopted communication media include:
Metallic line is a hardwired physical connection between the SCADA host and ·
the remote location. This is a good practical choice in SCADA applications where the distances between the SCADA host and the remote locations are not significant and there may be a limited choice of other media. An equivalent is usually leasing “lines” from a telephone company. The connection will utilize the internal network of the telephone company and may be any combination of wire, fibre optic cable, and radio. Another alternative is to utilize mobile telephone networks which provide good coverage in populated areas.
Application of radio transmission on a pipeline SCADA usually takes two ·
forms. The simple case is where a radio link is used as the last communication link between the SCADA and a remote site. The main communication back-bone of the SCADA system is some other media other than simple radio. A long distance pipeline that may be geographically located in remote areas as well as
near occupied areas may well incorporate a mix of radio links and fixed links (leased lines, fibre optic, etc.)
A fibre optic cable uses coherent laser light sent along a “cable.” The cables ·
are not lossless and repeater equipment is required at spacing of up to 100 km. The growth of the need for data transfer capability for the internet and private networks has spurred advances in fibre optic equipment. Because a fibre optic cable uses light and not electricity to transmit data it has the benefit of being unaffected by electromagnetic interference. On new pipeline projects, some pipeline companies have installed fibre optic cable in the same right of way as the pipeline. This can be a cost effective way of providing a transmission medium to implement the SCADA WAN.
A satellite can provide a cost effective communication solution for pipelines ·
under certain conditions. This solution is usually considered when the RTU is in a very remote location where the ability to utilize other media is not practical or very expensive. The capital cost is typically more than alternative techniques but when operating costs are factored in, this option can be a cost effective solution. However, poor weather conditions can adversely affect the reliability of communications.
Polling is the term used to describe the process of the SCADA host communicat-ing with a number of RTUs connected on a network and exchangcommunicat-ing data with each RTU. The arrangement between the SCADA host and the remote RTU is sometimes referred to as ‘master-slave’ implying that the SCADA host is in charge of each com-munication session with an RTU. The types of polling schemes are as follows:
Polled Only or multi-drop scheme: The SCADA host will sequentially initiate ·
communication with each RTU in sequence on a fixed schedule. There will be a fixed number of attempts to establish communication with an RTU before reporting that communications with the RTU are faulty. One can imagine that for a system with a large number of points to be updated at the SCADA host, this may take some time and therefore there will be some time lag between the sample time for the first data point and the last.
Freeze scheme: One variation of multi-drop scheme is the ability of the master to ·
issue a freeze command to all RTUs. The RTUs then store their data samples and the master begins polling and retrieves the data. This results in a database update at the master where all data was taken more or less at the same time. One way of mitigating this is to have all the RTUs take and store data samples at the same time. The major disadvantage of the above two schemes is that the status and value of all data base points are transmitted every polling cycle, which can be costly.
Polled Report by Exception (RBE): In this scheme, a local history of each data ·
point is saved and the RTU will only send back those points that have changed since the last poll. In the case of an analogue value, these will have a dead band that the value must exceed before a new value is sent back to the SCADA host. This reduces the amount of data traffic on the network. The user must be careful in choosing dead bands for analogue values for example to ensure that information is not lost.
Unsolicited RBE: In this case, the host does not poll on a regular basis, but each ·
RTU “pushes” data back to the host when it has updated data to send. This can reduce data traffic even more than the polled RBE. However, it has the disad-vantage of the host not knowing if data points have not changed or failed. A variation can be to have a system that incorporates a guaranteed polling time. For example, all RTUs may be scanned at least once every 15 minutes.
9.1.5 Data Management
Typical data required for the safe and efficient operation of pipeline systems from vari-ous locations include the following:
Pump station — values and quality of suction, casing and discharge pressures. ·
Sometimes, temperature value and its quality are made available, especially if a heater or chiller is installed. Status of various valves is also required. For variable speed pumps, unit speeds are made available for the operator to review the performance of the unit. Data to allow monitoring of unit operating point is also useful for determining operating efficiency.
Meter station — values and quality of flow, pressure, and temperature. In addi-·
tion, a densitometer reading may be available for liquid pipelines, particularly batch pipelines. The status of various valves is also required.
Control or pressure reducing valve station — values and quality of pressure or ·
flow.
Pipeline — values and quality of pressures along the pipeline. Sometimes, ·
values and quality of temperature are available. These may be retrieved from automated block valve sites to take advantage of the need for an RTU for valve control. The incremental cost of pressure and temperature measurements in this situation is minimal.
Alarm messages are generated to signal the potential or real interruption of normal operation at any monitored location on the pipeline.
There are four basic data types in a SCADA system, namely, “discrete,” “ana-logue,” “internal,” and “parameter”:
The term “discrete” reflects the fact that these points can only be in one of two ·
(or more) predefined states. Discrete points are generally binary in nature, i.e., they only have distinct states. This can represent open/closed, on/off, normal/ alarm, etc. They are referred to as digital, status or binary points. Some systems will implement three or four state points, such as a valve status, to indicate that the valve is “open,” “in transit,” or “closed,” or a pump is running, in start-up, in shutdown or off.
“Analogue” or “Analog” refers to points that have a numeric value rather than ·
two or more discrete states. Analogue inputs are field data points with a value that represents a process variable at any given remote location such as pipeline pressure, oil temperature or pressure set point on a control valve. Analogue output points can also be sent as commands from the SCADA host, such as set points for controllers.
A third type of data point is determined internally by the SCADA host as op-·
posed to being sent by an RTU. The internal data type is also called derived data. This can range from a simple calculation to change the engineering units of a field value to more complicated calculations such as the corrected volume measurement in a tank based on tank level, temperature, and product density of a flow calculation that uses API corrections.
Parameters or factors are generally used to calculate derived values. Exam-·
ples include orifice plate sizes, AGA calculation parameters, and performance curves.
All SCADA systems work in a real-time environment, consequently they have a real-time database to process real-time data. The real-time database must be able
to process large amounts of real-time data quickly. A typical corporate relational database cannot meet such requirements. Conventional database systems are typi-cally not used in real-time applications due to their poor performance and lack of predictability.
The SCADA host must be able to meet the requirements of a real-time environ-ment and easily interface to standard external databases for the purposes of making key data available to other business processes. One method used is to utilize some form of a data repository or data historian to store SCADA data for access by other applica-tions. This reduces the transactions in the real-time database and improves response performance.
Creating the SCADA database consists of populating the database with each of the individual data sources in the SCADA network. Each point will require a number of information fields to be entered to complete a record in the database. This effort is a time-consuming task and must be done accurately. Typically, the SCADA host provides a high-level software utility for interactive creation and modification of the system database. A key feature of a SCADA system is the ability to download RTU configuration information from the database thus eliminating the need to re-enter data at each RTU. This also eliminates another source of possible error. Database changes (e.g., addition, deletion, or modification of points) can generally be performed on-line and should not require recompiling the system software
All data points will be stored with a time stamp indicating when they were sam-pled by the RTU. A “quality” flag may also be stored indicating the quality of the value. Some examples of quality indicators are “Good” meaning that the data has been scanned recently and is within range, “Stale” indicating that the point has not been re-freshed for some configurable period, “Bad” meaning that the point’s value cannot be relied upon, etc. Analogue values are processed by the SCADA host and stored in the real-time database, usually along with the original or raw value received from the RTU. Typical processing of analogue points could include conversion to engineering units, alarm checking against pre-set values for each reading, rate of change alarm, instru-ment failure alarm, averaging, and totalizing such as volume going into a tank.
SCADA data security and integrity features must be consistent with the corporate IT standards and should be outlined during the development of the SCADA require-ments. SCADA manuals should include detailed procedures for generating accurate and complete copies of records, while the system should allow for each user’s account to limit the access and function the user can execute. All SCADA historical records should use secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records.
A historical database provides for internal analysis and reference as well as meet-ing the requirements of regulatmeet-ing agencies to review pipeline system operation. For example, operation engineers use the historical data for operational analysis for performance enhancement. The regulator may require emergency scan data to track events leading to and following an emergency condition and eventually to determine the cause/effect relationship. SCADA historical data includes time-stamped analogue values and other control-related analogue values. It can also include digital points and host generated points including alarm and event logs. Operator task logs are also typi-cally included.
Since a large amount of data can be accumulated, the historical data needs to be ar-chived periodically. Arar-chived data refers to data that has been stored on archival media (CD, digital tape, etc.) and is stored in a separate location from the SCADA host sys-tem as required by corporate policy. The period of time after which data should be ar-chived is determined by corporate policy. The data archive should include all analogue
and digital data, alarms, events and operator actions. The SCADA system must be able to retrieve archived data without interrupting ongoing process operations.
To facilitate analyzing system upsets and events, the SCADA system can have a feature known as “playback.” This functions much like a rewind on a VCR and al-lows a user to replay historical data through an off-line operator terminal in order to more easily analyze and determine the root cause of an upset. It can also be used to do “post-mortems” with operators to provide feedback on actions that were taken and to determine if remedial action taken was done correctly and in a timely fashion. The SCADA data base manager needs to store and time tag all operator actions (alarm ac-knowledgment, commands, etc.) as well as all incoming and outgoing data to get the most benefit from this feature.
9.1.6 Alarms
For safe pipeline operation, potential alarm situations should be addressed by annunci-ating alarm messages. High-priority alarms may require audible alarming. Alarm condi-tions are expected during the course of pipeline system operation. The alarm processing function can help to identify potential alarm conditions before actual alarm conditions occur. Examples of potential alarms include high-pressure violation, high-temperature violation at a compressor discharge, leak detection, etc.
The alarm processing function should be able to limit the number of alarms to those that are important. If the number of alarms is too large, the operator’s attention is consumed reviewing and acknowledging alarms instead of monitoring and controlling the pipeline system. An overabundance of alarms also desensitizes the operators and can result in them ignoring critical alarm conditions.
In general, alarms are prioritized according to their critical nature in order to give the operator an indication of which alarms need to be attended to first. Emergency alarms require the operators to take immediate action to correct the condition, while communication alarms may require them to contact support staff immediately. Warn-ing alarms are not usually critical, requirWarn-ing preventive measure without immediate action. The severity of alarms should be configured to be one of multiple levels of severity (for example, high, medium, or low) for all alarm generating points. Alarms are usually color coded, requiring a different color for each level of alarm. In addition, an audible signal should be generated for high-level alarms.
Analogue alarms are generated when a current value for an analogue point reaches a limit pre-defined in the data base attribute for that point. Figure 9-6 is a typical alarm sum-mary display, which in this case shows the conditions both “in alarm” and “not in alarm” as well as both the “unacknowledged” and “acknowledged” statuses. The first two alarm messages are in an alarm condition because the tank is in “Low-Low” level.
Alarm levels will typically include the following:
High-High (or Alarm) means that the point has reached its maximum allowable ·
value. This will generally mean that it is close to or has reached a point where local automatic protection systems may be initiating action.
High (or High Warning) means that the point has reached a warning level. If ·
remedial action is not taken, the point may reach High-High. The trending sys-tem will allow an operator to display such a point to see how long it has taken the point to get to the warning level.
Low-Low (or Alarm) similar to High-High but for a lower limit ·
Low (or Low Warning) similar to High but for a lower limit ·
Rate of Change: The slope of a trend line has exceeded a pre-defined limit. This ·
Discrete alarms are generated upon a change of state of the data base point. These can represent:
Change from normal to abnormal such as a high-temperature alarm on a com-·
pressor station outlet.
A change of status that was not the result of an operator control action. For ·
example, a valve closes or a pump shuts down with no initiation from the operator.
All such alarms will be reported and logged, as will any change of status of a point. This will provide not only a record of all abnormal events but will also show when equipment was acted upon by an operator.
A basic alarm management scheme consists of detecting the alarm and reporting the alarm to the operator. An alarm management system will also log and provide an audit trail of each alarm. This will include the time that the alarm was reported, when it was ac-knowledged by the operator and when the alarming point returned to normal. This informa-tion along with the database log will provide key informainforma-tion for post-event analysis.
In any system upset, there will be an initiating event followed by secondary indica-tions or alarms. For example, a control valve may fail causing pressure to rise, which may then cause pressure relief valves to operate and flow rates to exceed expected values. Some SCADA systems may incorporate some form of artificial intelligence to process alarms automatically to advise the operator of what the potential root cause may be.
The SCADA database will have the ability to assign various levels of alarm sever-ity to individual points to provide an easy means of reporting high-priorsever-ity alarms to an operator. In an emergency condition, it is important to not overload an operator and allow concentration on priority items.
The alarm message includes the date and time of the alarm, the point that caused the alarm, the severity of the alarm denoted by color and an audible signal, and the state of the point. The message is displayed in the alarm window and in the tabular summary of alarms. The alarm window lists all unacknowledged alarms, which should be made available on the screen at all times. Alarms are always logged in an event summary, including not only all the information in the alarm message but also the time when the alarm was acknowledged and by whom.
The operators should be able to easily monitor alarm messages and quickly re-spond to the messages. Therefore, messages should be made readily available to the operator. The current alarm summary is mainly used for monitoring and acknowledg-ing the messages, while the alarm history summary is mainly used for reviewacknowledg-ing the alarm status and pipeline system operation.
9.1.7 Human Machine Interface (HMI) and Reporting
Key features of displays and reports are discussed in this section. Typical data x/y in-cluded in displays and reports are as follows:
Telemetered data, including analogue, digital, and derived values and quality ·
Parameter data, such as orifice plate size ·
Schematic information, including station yard piping, facility locations on the ·
pipeline system, and other pertinent information
The displays need to be designed to meet the needs of individual operators, be-cause they are the prime users of SCADA displays. Displays need to:
provide a fixed area on the screen for alarm and emergency annunciation ·
refresh the displays dynamically and within a short time (at most a few sec-·
onds) after a command is issued
allow the operators to be able to navigate the displays easily and quickly ·
maintain a consistent “look and feel” and use intuitive design industry- accepted ·
display design methodologies and standards.
All SCADA vendors will have a comprehensive HMI system, which will include tools for creating and modifying displays and reports. In fact, the capabilities of most systems can be bewildering and intimidating. Since a typical SCADA host will have a large real-time database, the challenge is to design an HMI that presents relevant information to the operator in an easy to understand set of displays.
It is suggested that a fixed area be reserved on the screen for alarm and event mes-sages, system performance monitoring, and annunciation of emergency scan. In other words, this information remains on the screen always until it has been acknowledged. It is important to develop some guiding principles for each system before the displays are created. These guidelines should include some variation of the following:
1. Have a hierarchical approach: Top-level displays will show key summary information but also have the ability to “zoom” in quickly for more detail. Typically, the top level display is a pipeline system overview or a pipeline sys-tem schematic. The syssys-tem overview display allows the operator not only to view the current pipeline states including set points and alarms of the system but also to access a particular station for viewing control points and/or modifying their values. It not only displays all pump/compressor stations and current alarm messages but also flow, pressure and temperature including set points. In addition,
this display may show the link to pump/compressor, meter, or valve station con-trol panels through which the operator can send a concon-trol command.
2. Screen navigation should follow the current expected features found in most window-type navigation software to reduce operator-learning time and to make the system as intuitive as possible.
3. Ensure a consistent “look and feel” of displays to minimize training and the chance of operator error. These will include the use of color and a consistent and logical approach to the use of buttons, menus and toolbars. A judicious choice of colors is important as certain types of color blindness can result in some colors appearing the same to some people.
4. Keep screens as uncluttered as possible while still supplying the required in-formation. The possibility of confusion should be minimized and care taken to reduce the possibility of information being lost or “buried” on the screen. The following displays are considered to be key display requirements for effective operation of the pipeline system:
Display or schematics of an entire pipeline system ·
Pump station overview including measurements on piping, unit and driver ·
Meter station information including flow rate and accumulated volume, total ·
station flows, etc.
Pipeline elevation and pressure profiles with MAOP ·
Batch tracking information along the pipeline system ·
Tank and storage information such as tank inventory ·
Alarm and event annunciation and summary ·
Communication summary ·
Measurement and equipment status summary ·
Security-related information including system status and police contacts ·
The displays are either in tabular or graphical format. In some cases, it may be useful to have both tabular and graphical formats for displaying data. The selection of format depends on how the data is used. For example, it is more useful to display pres-sure drop along the pipeline in graphical format. Most modern SCADA systems use several display mechanisms, which include textual and graphical images augmented with real-time information. Color and shape can be used to relate discrete information in an intuitive manner, plot and trend display types can be used to display graphs of analog data in an x/y format or a horizontal or vertical bar graph.
There are other display types such as pushbutton for selecting a button to perform a specific function, meter/gauge for showing a meter/gauge device with values, and region for marking a location on a display. Some SCADA display systems support display format control. The format control functions include popup and pan/zoom. For example, the functions such as set-point control and communication control can be supported by pop-ups. A large display area can be easily navigated by means of a panning/zooming feature of the display system.
Figure 9-7 is a display of a pipeline system. It shows the operating statuses and parameters of the entire pipeline system; pump stations and the operating pump units, current station pressures and flow rate, density, and list of alarm messages at the bottom of the display. From this display, a desired pump station or alarm message is selected to review the detailed data for the station.
Figure 9-8 shows a typical pump station diagram. To monitor or control a pump station, it can be directly selected from the display of the pipeline system. Then, the operator can monitor the measured variables and controlled parameters of the selected
Figure 9-7. Screen display of a pipeline system (courtesy of Telvent)
station as well as its station operation statuses including pump unit and valve statuses. From the pump station display, the pump units and valves can be controlled and the control point can be set. Normally, the suction or discharge pressure is controlled from this screen.
Figure 9-9 displays a meter station in a tank farm, installed with a meter prover. The operator can view the current meter station statuses and meter data including flow meter and valve positions as well as control the meter station from this display. The operator can acknowledge any alarm messages related to the meter station operation. These alarms are listed in the alarm summary at the bottom of the screen. In addition, the flow meter can be proved by means of a meter prover.
Figure 9-10 displays the elevation profile, and pressure profile with MAOP. The pressures can be presented in terms of head so that all three units are the same. This allows the operator to visually detect trouble spots such as slack flow conditions along the pipeline.
Data trending capability is one of the most important functions of any SCADA system because it helps the dispatchers and operations staff to identify potential prob-lems before they arise and to diagnose alarm conditions. Data trending is used to dis-play any analogue values which are stored in the historical database over time at a specific location or locations. Data trending displays are in graphical format due to the
large amount of data. Figure 9-11 shows a typical trend plot of flow rate, pressure, tem-perature, and API gravity at any specific point of a pipeline. Any data can be trended, and the trended data can be analyzed to detect any anomaly at the point.
All SCADA systems have some type of reporting capability. This will typically consist of both standard reports generated automatically by the system and user-defined reports. These reports are generated from the SCADA databases containing real-time, historical and calculated data. The standard reports are of a predefined structure, while the user-defined reports meet the user’s specific needs. Examples of standard reports include operating summary reports and billing reports, and those of user-defined re-ports include such things as command/alarm log sorted by station.
Figure 9-10. MAOP, pressure and elevation profiles (courtesy of Telvent)
The types of reports usually found on a pipeline SCADA system would include some of the following:
Operating reports ·
Shift or daily operating summary reports ·
Product movement report ·
Alarm summary report ·
System availability, communication and reliability report ·
Emergency scan report, containing operating data during emergency conditions ·
Government regulators may require pipeline companies to submit regulatory re-ports. Normal operation reports may need to be submitted regularly, but emergency reports are mandatory in the event of emergency conditions.
The SCADA system provides system administration tools to configure and main-tain the system, and allows the SCADA users to access various logs.
Command log, containing a record of all commands issued by the operator ·
Alarm log, containing all generated and acknowledged alarm messages for ·
tracking operational problems
Database maintenance log for recording commands used to change any SCADA ·
database values
System log for recording the SCADA system performance including error data ·
such as the start/stop time, abnormal running time, etc.
Communication log for recording the statistics of the communications with the ·
RTUs such as the number of attempts, the number and types of error, etc. The number, content, and style of reports will vary widely depending on the pipe-line type, the business requirements, and the regulatory environment. It is important that the SCADA system provides an easy to use, flexible reporting package that does not require programming changes to create and implement reports.
9.1.8 Security
A SCADA system will provide for user password access and the ability to configure specific levels of access for each user. For example, there may be users who may ac-cess the SCADA system but are allowed only the ability to read some pre-configured reports. For example, only those who are directly responsible for the database are al-lowed to make changes to the database and this is done with password protection.
SCADA systems have long been thought to operate in a secure environment because of their closed networks, which are not exposed to external entities. In ad-dition, the communication protocols employed were primarily proprietary and not commonly published. Recent advances, such as Web-based reporting and remote operator access, have driven the requirement to interface with the Internet. This opens up physical access over the public network and subjects SCADA systems to the same potential malicious threats as those that corporate networks face on a regular basis.
Typically, compliance with industry standards and technologies is regarded as a good thing. However, in the case of newer SCADA systems, recent adoption of commonly used operating systems and standards makes for a more vulnerable target. Newer SCADA systems have begun to use operating systems such as Windows that are commonplace in corporate networks. While this move offers benefits, it also makes SCADA systems susceptible to numerous attacks related to these operating systems.
RTU to host protocols are now utilizing industry standard protocols, which may com-promise their security.
Due to cyber terrorism, the security associated with the SCADA network needs to be designed and assessed by the same policies utilized in other areas of the company. If there are no such clear network security policies in place, then they need to be estab-lished before taking specific actions on the SCADA network. For detailed information on SCADA security, refer to API Standard 1164 — Pipeline SCADA Security [6]. This standard provides guidance to the operators of pipeline systems for managing SCADA system integrity and security.
9.2 OVERVIEW OF PIPELINE LEAK DETECTION SYSTEM
9.2.1 Introduction
This section discusses various aspects of pipeline leak detection without an emphasis on any particular techniques. Anyone, who is interested in the detailed discussion of the leak detection techniques and their implementation considerations, are referred to other volumes [1]. This section introduces the selection criteria of a leak detection system and various leak detection techniques.
Pipeline leak detection is only one aspect of a pipeline leak management pro-gram; it encompasses leak prevention, detection and mitigation procedures. In order to minimize the consequences of a leak, pipeline companies require a comprehensive leak management program. A leak detection system by itself does not improve on a pipeline’s integrity nor reduce potential failures of a pipeline system. However, such a program will not only help prevent and monitor the degradation of a pipeline that may eventually lead to failure, but will also minimize the consequences of pipeline leaks if they occur.
Pipeline companies minimize leaks through a leak prevention program. The main causes of leaks are: outside or third party damage such as excavation equipment hitting the pipeline, geophysical forces such as floods and landslides, improper control of the pipeline system, and pipe corrosion. Figure 9-12 shows leak statistics in US, Canada and Europe.
Even though the statistics are about ten years old, they can be relevant to ad-dress key issues on leaks. Incidents resulting from damage by a third party are signifi-cantly higher in Europe than those in Canada, mainly because the population density in Europe is much higher. Proper control of third-party damage is achieved through: marking of the right of way; education of employees, contractors, and the public; and effective use of systems such as “One-Call.” Geophysical forces cannot be controlled but can be monitored and their effects can be mitigated. Pipeline integrity management is a significant subject by itself and discussed in separate volumes [7].
Leak mitigation is the attempt to reduce the consequences of a leak when it occurs. If a leak can be detected quickly and isolated quickly, the spillage can be minimized. This requires that the leak alarm and its associated information are reliable and accu-rate. Having effective procedures in place and the proper resources and tools to enact them are critical in addressing the leak mitigation issues efficiently. The leak confirma-tion and isolaconfirma-tion issues should be part of leak detecconfirma-tion. The scope of leak detecconfirma-tion does not normally include spillage management issues such as cleanup procedures and manpower mobilization.
Historical data indicates that leaks were predominantly detected by local opera-tion staff and third parties. Successful detecopera-tion by means of a single leak detecopera-tion system was random. This was because no single leak detection system could detect leaks quickly and accurately or provide reliable leak detection continuously and cost-effectively. Therefore, more systematic approaches to leak detection are required, such as a combination of line patrol, sensing devices and/or SCADA-based systems with automated leak detection capability.
Since SCADA systems have become an integral part of pipeline operations, a particular consideration has to be given to leak detection methods that can be easily implemented on the SCADA system. API Publication 1130 [8] addresses various Com-putational Pipeline Monitoring (CPM) methodologies, integrated with a host SCADA system. In association with the CPM, API Publication 1149 [9] and API Publication 1155 [10] are briefly discussed with respect to how they are used for specifying and evaluating leak detection performance.
Pipeline Leaks
This chapter uses the definition of leaks as defined in “Petroleum Pipeline Leak De-tection Study [11].” There are two types of leaks: an incipient leak and an actual leak. “Incipient leaks” are defined as those that are just about to occur. Certain incipient leaks can be discovered by inspecting the pipeline and dealt with before they become actual leaks. Here, an actual leak is called a pipeline leak when fluid is leaking out of a pipeline system.
All pipeline leaks are associated with certain external and internal phenomena. External phenomena include the following:
Spilled product around the pipeline ·
Noise generated from leakage at the hole in the pipe ·
Temperature changes around the hole ·
Internal phenomena include: Pressure drops and flow changes ·
Noise around the hole ·
Temperature drop for gas pipeline ·
All leak detection systems take advantage of the presence of one or more leak phenomena.
Standards on Leak Detection
In North America, a leak detection system is normally required on new liquid pipelines, but not on existing pipelines unless mandated otherwise by the appropriate regulatory agency. In general, there is no leak detection requirement on gas pipelines other than a few new gas pipelines. The same is true of multi-phase gathering pipelines.
Pipeline companies are using various leak detection methods with varying degrees of success. At present, no single method truly stands out as an ideal system able to de-tect the wide ranges of leaks with accuracy and reliability, and having low installation and operating costs. Some are accurate and reliable but too expensive, and some are economical but unreliable.
Different countries have developed different leak detection regulations and prac-tices. A few references and standards are introduced below. However, in general, the codes and standards on pipeline leak detection are not well defined.
American Petroleum Institute (API) has published several standards on pipeline leak detection. They are listed below:
API 1130 “Computational Pipeline Monitoring” addresses the design, imple-·
mentation, testing and operation of Computational Pipeline Monitoring (CPM) systems. It is intended as a reference for pipeline operating companies and other service companies. The publication is used as a standard by regulatory agencies in many parts of the world.
API 1149 “Pipeline Variable Uncertainties and Their Effects on Leak Detecta-·
bility” discusses the effects of variable uncertainties and leak detectability eval-uation procedures for a computational pipeline monitoring methodology. This publication describes a method of analyzing detectable leak sizes theoretically using physical parameters of the target pipeline. It can be used for assessing leak detectability for new and existing pipelines.
API 1155 “Evaluation Methodology for Software Based Leak Detection Sys-·
tems” describes the procedures for determining CPM’s leak detection perform-ance. Unlike API 1149, this publication addresses the performance evaluation procedures based on physical pipeline characteristics and actual operating data collected from pipeline operations.
The Canadian standards applicable to oil and gas pipelines are specified in Z662, “Oil and Gas Pipeline Systems.” Section 10.2.6 of Z662 specifies leak detection for liquid hydrocarbon pipeline systems. The specifications in Section 10.2.6 for liquid pipeline systems states:
“Operating companies shall make periodic line balance measurements for sys-tem integrity. Operating companies shall periodically review their leak detection methods to confirm their adequacy and effectiveness. Installed devices or oper-ating practices, or both, shall be capable of early detection of leaks. Measuring equipment shall be calibrated regularly to facilitate proper measurement.”
The title of Annex E is “Recommended Practice for Liquid Hydrocarbon Pipeline System Leak Detection.” The annex describes a practice for leak detection based on computational methods, particularly material balance techniques. It does not exclude other leak detection methods that are equally effective. The annex emphasizes that op-erating companies shall comply as thoroughly as practicable with the record retention, maintenance, auditing, testing, and training requirements, regardless of the method of leak detection used.
Leak Detection System Selection Criteria
It is essential that the objectives and requirements for employing the leak detection system are defined. The objectives of the leak detection system are to assist the pipeline operators with:
Reducing spillage of product and thus reducing the consequences of leaks, ·
Reducing operator’s burden by detecting leaks quickly and consistently with-·
out relying heavily on operator experience, Satisfying regulatory requirements. ·
A leak would be initially detected and located by the leak detection system and then confirmed by some means such as visual inspection. After, or even before the leak is confirmed (depending on the company’s leak response procedures), the leak must be isolated by closing block valves adjacent to the leak. After the leak is iso-lated, a significant volume of product can be lost depending on the leak location and terrain of the leaked pipeline section. The spillage during the detection phase is often relatively small compared to potential total spillage. Therefore, the impor-tance of rapid detection time as a valuable feature of a detection system cannot be over-emphasized.
It is important to define a set of selection criteria for use in assessing the perfor-mance and selection of various leak detection systems. Typical perforperfor-mance criteria are listed in Table 9-1 [12, 13]:
An effective leak detection system helps pipeline operators mitigate the risks and consequences of any leak. It can shorten leak detection time, increase reliability (not miss actual leaks and at the same time not produce false alarms), and reduce leak con-firmation and isolation time with accurate leak location estimates. Simply put, overall cost of a leak can be reduced using an effective leak detection system. However, there are costs to implement and operate a leak detection system.
Therefore, the decision-making process of implementing and operating a leak de-tection system can be made by balancing the risk and consequences of possible leaks against the cost of a leak detection system and mitigation program. The following TAbLE 9-1. Leak detection system performance criteria
Criteria Description
Detectability Detectability of leaks is measured in terms of leak detection time and range of leak size.
Sensitivity Sensitivity is defined as the minimum leak size that the leak detection system can detect.
Reliability Reliability of a leak detection system is defined in terms of false alarm rate. If the frequency of false alarms is high, the operators may not trust the leak detec-tion system, increasing the confirmadetec-tion time and thus spillage volume. Robustness Robustness is defined as a measure of the leak detection system’s ability to
continue to operate and provide useful information in all pipeline operating conditions.
Operability The leak detection system needs to operate not only continuously but also in all operating conditions (shut-in, steady state and transient state). In addition, the system should not interfere with normal operations.
Accuracy Accuracy is defined as a measure of the leak detection system’s ability to esti-mate how close the estiesti-mated leak location and size is to the actual leak location and size.
Cost The cost includes the installation and operating costs of a leak detection system, including instrumentation or sensing devices.
