Indian products pipeline gets scada system

Roberto Bettoli, Angela Iacovoni
Nuovo Pignone S.p.A.
Rome

David Holden
LICconsult,
Cleveland, U.K.

A supervisory control and data acquisition (scada) system that, among other duties, handles approximately 400 control sequences along with leak detection and batch management, has been installed in an Indian products pipeline ( Fig. 1 [41181 bytes]).

The 1,443-km (896-mile) Kandla-Bhatinda multiproduct pipeline consists of two inlet stations, four pumping stations, five delivery stations, and two terminal stations and is equipped with 85 block valves. All the stations can launch and receive scrapers.

Annual throughput requirement is 6 million metric tons/year (tpy) in the Kandla-Kot-Karnal section, 1.5 million metric tpy in the Karnal-Bhatinda section, and 0.75 million metric tpy in the Kot-Salawas branch.

Projected expanded annual throughput requirement will be 11.5 million metric tpy (Kandla-Kot), 10.2 million metric tpy (Kot-Karnal) 2.0 million metric tpy (Karnal-Bhatinda), and 1.3 million metric tpy (Kot-Salawas). To meet these demands, pipeline facilities will include 12 pump or delivery stations.

The new scada system consists of 10 station control centers (SCC) and one master control center (MCC) located along the pipeline.

New system

The Kandla-Bhatinda pipeline will supply refined petroleum products from Kandla, a shore station on India's west coast, to stations in a four-state area of northwest India.

Products to be transported in batch include gasoline, kerosine, high-speed diesel, light diesel oil, and aviation fuel.

Following are the main pipeline scada management tools and functions including stations and systems network, scada management, application software, system reliability and availability, and product interface handler:

• Stations/systems network: The multifunctional stations along the pipeline are connected to a data network of scada systems (a master scada system, or MCC, and local station scada systems, or SCCs) and remote terminal units (RTUs).

• Scada management: The SCCs control and supervise all the pipeline stations with computer systems and RTUs which handle control sequences (approximately 400 system-wide, including direct digital control of the main plant controllable devices).

  The RTUs also perform special flow management.

  The MCC supervises the pipeline through the local SCCs and can take control of one or more of the pipeline sections. The MCC also provides special functions: leak detection, pig tracking, batch management, and pipeline efficiency determination.

• Application software: Special software provides the pipeline operator with information needed for the successful operation of the pipeline. Operator information includes the following:

  1. Real-time dynamic models provide information for leak detection and location, pig management, and parameter tuning.

  2. Batch management models track the various batches of petroleum product through the pipeline.

  3. Predictive and trainer-session models, using the real-time dynamic models as a base, provide information that allows an operator, in a safe and controlled system environment, to visualize and understand the outcome of various actions.

• System reliability and availability: For reliable communication, each RTU is connected (with redundant channels) to a local station system and the master system.

  Most of the hardware of each system is redundant, including the workstations dedicated to the pipeline application software.

  Control-related operations and execution commands and settings can be issued by either the local station system or the master system. If the communication fails, RTU-based control sequences, as well as RTU-based loop controllers, will continue to execute and will automatically adjust to current conditions.

  The overall pipeline real-time dynamic model, formed by a combining of models of individual sections, is not adversely affected by the loss of telemetry data from a local station system because most of the individual models will remain unaffected.

• Product interface handler: Product cross contamination (interface tanks are unavailable at terminal stations) is minimized and managed by an RTU-based product changeover control sequence.

Following is a description of each of the multiproduct management tools and functions (stations and systems network, scada management, application software, system reliability and availability, and product interface handler).

Network

Multifunctional stations along the pipeline include 12 primary stations (pump, scraper, pig launch and retrieve, delivery, and terminal), 23 secondary stations (block valve and optical fiber repeater sites), and 85 other block valve sites.

The primary and secondary stations are managed with a network of scada systems and RTUs. The master system is located at Karnal, and the local station systems are at 10 of the primary stations.

In addition, each of the primary and secondary stations is equipped with an RTU.

The configuration of each scada system includes processors (host computers) and terminal servers, along with workstations and printers, all connected to a local area network (LAN), local to each system (Fig. 2 [69184 bytes] and Fig. 3 [43729 bytes]).

Configuration of the RTU at each primary station includes a multiloop controller.

Scada management

With commands, set points, and control sequences, the networked systems (master system in conjunction with the particular local station system and associated RTUs) control the regulation parameters of each pump station as well as the off-take parameters at each delivery and terminal facility.

The prevailing philosophy of the pipeline is to optimize efficiency by pumping at maximum allowable operating pressure in all sections of the pipeline and to minimize interface generation.

The master system is primarily responsible for control of the pipeline; it is capable of actuating either all of the facilities or a portion of those facilities.

Normally, therefore, the master system directs a local station system to an action. The local station system, in turn, directs the corresponding RTU and its RTU-resident control sequences.

Functions performed by RTU-resident control sequences include set point adjustment to controllers; start/stop/regulation of main line pumps; regulation of inlet and outlet manifold; valve positioning; scraper launch and retrieval; start and stop of sump pump; support of meter-proving functions; support of emergency-shutdown sequences; and support of various other functions (filters and strainers, the compressed air system, and the fire-fighting system).

Pump-station parameters regulated by control sequences include pump engine speed, pump-station discharge pressure, and pump on-line. The pump station parameter regulation is based on values for allowable station discharge pressure, required throughput capacity, and minimal allowable suction pressure.

The RTU-based control sequences respond to, among other pipeline situations, pipeline throughput decrease as a result of pumping slow-down or shutdown, pipeline throughput increase as a result of start-up of pumps and pump stations, and change in flow rate as a result of operator action.

The sequences also respond to terminal or delivery station shutdown by reducing pump-station discharge pressures logically and sequentially.

An orderly emergency shutdown operation and, likewise, a quick and orderly start-up after the shutdown are handled by control sequences. These also regulate and control the flow rate of each of the legs from Kot, the Kot-Karnal section, and the Kot-Salawas branch.

Other scada management functions include:

• Various monthly schedules, for example, batch movement and pigging operations; take-off deliveries at intermediate delivery stations; and equipment maintenance

• Various monitoring functions; availability of tankage at delivery sites; and units on-line/off-line in the data communications network

• Maintenance of station records

• Product dispatched and received

• Equipment operating hours; communication handling

• Telemetry data retrieval (15-sec data for application software)

• Data base access, generation, and maintenance

• Alarms, events, logs, reports, format display access, generation, and maintenance

• Data trends

• Man-machine operator workstation interface

• Store, retrieve, backup of historical data

• Periodic broadcast of time to RTUs

• Mimic-panel display (at Karnal master system site).

Application software

The application software generates real-time dynamic models, batch management models, and, on a "trainer" system, predictive/trainer-session models.

The dynamic models are used for detecting a leak and its corresponding locations for pig tracking and for parameter tuning; the batch-management models, for tracking various batches of petroleum through the pipeline.

The predictive and trainer-session models, which combine dynamic models and hypothetical operations, analyze the outcome of operator actions in a safe and controlled manner.

The application software system environment consists of two workstations and a trainer computer located at the site of the master system in Karnal.

The workstations operate the real-time application and the batch-management system. The predictive and trainer-session models are implemented on a trainer computer.

Results from the application software are displayed in a variety of formats. Operator alpha-numeric displays are provided for the real-time system, batch managements, and training simulator.

There are also several more detailed displays, system engineers' displays, which can be used to "fault-find" particular problems in the pipeline operation.

Various reports are printed automatically at midnight or on request showing details of leak detection, batch information, and pressure and flow measurements. A graphical user's interface also shows flow, pressure, batch management, and leak status for each of the pipeline sections.

Real-time models

The real-time dynamic models are used for detecting a leak and its corresponding location, for pig tracking, and for parameter tuning.

Leak detection is performed with the method of characteristics based on conservation of mass, momentum and energy, and the equation of state. Boundary conditions for each of the pipeline sections are used to determine variations of pressure, flow, temperature, and density along the pipeline.

These calculated values can be compared to measured values to determine over or under-pressure detection, leak or no-leak analysis, and leak size and location. The system also includes shut-in leak detection.

Three methods of leak detection are provided: unexpected flow variations, unexpected pressure variations, and corrected net-volume balance. By a comparison of measured values with simulated data, unexpected flow and pressure variations may be determined for all stations equipped with measurement instrumentation.

Predefined thresholds are set for each of the responses. The threshold represents the uncertainty in the calculation of the response based upon the instrumentation accuracy and repeatability.

The predefined threshold represents the minimum detectable leak size for each method of leak detection for the pipeline operating under optimal conditions.

The threshold will rise above the predefined value dynamically during degraded conditions of pipeline operation, data acquisition, or modeling.

Under certain severe conditions, leak-detection attempts will become meaningless and the leak-response calculations will be automatically disabled until proper conditions reappear.

The pig-management software tracks the position of the pigs in the pipeline and appropriately warns the operator at the receiver station that the pig is approaching. Pig positions are updated based both on the velocity profile generated by the flow model and on the intermediate pig passing detection signals.

All pigging operations are monitored; to prevent false leak-detect alarms, the leak-detect threshold is increased automatically during these operations. Pig-related schedules, reports, and data available on the master systems are downloaded to the relevant local station systems.

System wide pig-related functions are available: the pig launch and retrieval function, at each primary station; pig detection, at all primary and secondary stations.

Tuning is achieved with an automatic or manual adjustment of system parameters with the purpose of establishing the closest possible accordance between the real and model-led process.

Batch management

System-wide batch-related functions include the following: batch scheduling, batch reporting, batch-arrival predictions, batch-arrival detection, batch delivery, and batch changeover.

Batch-management allows the operator to implement a batch schedule for each of the pipeline sections and to monitor whether the actual batch transportation is taking place according to schedule.

The operator can define the batch sequence of products to be dispatched and delivered. The schedule is defined by its source, product, batch name, volume, and quantity to be delivered to each off-take point.

The batch-movement software tracks both the scheduled batches and the actual batches, so that the operator can compare the pattern between the two types. Batch fronts are updated based on the velocity profile generated by the pressure/flow model and the actual flow measurements from the off-take points.

The functions relating to actual batches include the determination of the source tanks feeding the pipelines, determination of changes in density at the inlet, and indication of a pig (when batches are separated by a sphere), as well as the batch volume based on flow measurement into and from the pipeline.

Predictions of batch arrival are based on information obtained from the dynamic pipeline model. Batch-related schedules, reports, and data, available on the master system, are downloaded to the relevant local station systems.

Predictive, trainer models

Predictive models, generated on the trainer system, combine dynamic models and hypothetical operations to analyze the outcome of operator actions in a safe and controlled manner.

The off-line simulation models (up to 10 scenarios) can be used to train the operator, check operational strategies before implementation, analyze critical situations and preventive actions, or assess the consequences of changes in product demand, supply, or storage.

There are three possible starting conditions for a simulation model: current pipeline condition based on the real-time model, previously predefined condition, or restart of the last training simulation.

Reliability

The reliability of the data communication within the network of systems is attained with redundant communication channels (circuits) controlled by the telemetry subsystem of the particular scada system and with a subcircuit composition of redundant data lines controlled by the cable communication interface unit (Fig. 4 [43667 bytes]).

The reliability of data communication is also attained on a system level: If the communication fails between a local station system and RTU or between the master system and a local station system, the master system will communicate with the particular RTU(s) directly.

Availability

The availability of the redundant host computers is ensured by "fail-over watchdog" software; of redundant terminal servers, by "communication watchdog" software; and of redundant LANs, by the host computer operating system.

Additionally, the workstations dedicated to pipeline application software are controlled by "application watchdog" software.

Control-sequence software, resident in each RTU, responds to operator commands and settings. Multiloop controllers, resident in the primary station RTUs, also respond to operational settings.

Such commands and parameters can be issued from the local station system to the RTU, but normally the master system which is primarily responsible for control of the pipeline, directs the RTU through the local station system. If that station system communication fails, the master system would issue commands to the RTU directly.

Regardless of the system-to-RTU communication status, the RTU control sequence software will continue to respond automatically to internal parameters as well as to local panel settings. Similarly, the multiloop controllers will also continue to respond automatically to current conditions.

A real-time dynamic model is generated by the application software for each of 11 sections (each section being bounded by two primary stations) along the pipeline. The loss of telemetry data from a local station system could adversely affect individual models, but the overall pipeline dynamic model, formed by combining the individual models, is not adversely affected.

Product interface

The Kandla-Bhatinda pipeline is designed to handle simultaneous off-takes; the total of these off-takes must equal pipeline-throughput capacities. The networked systems control the regulation parameters of each pump station as well as the off-take parameters at each delivery and terminal facility.

Regulation and control of the off-take parameters at delivery and terminal facilities are based on input values of minimal allowable pressure in pipeline stations upstream from delivery station, station delivery pressure, and station off-take capacity.

Two off-take capacity choices are available: off-take of all throughput capacity at one delivery point only or minimal off-take at the delivery station. Capacity of each off-take and its opening and closing times are based on current operational parameters.

Interface tanks are unavailable at the intermediate delivery stations because product interface is not planned at these off-take locations.

Interface tanks are also unavailable at terminal stations. Product interface, therefore, will have to be blended with the base product. The ability of a product to blend with successive products determines the order of the batches; the amount that can be blended will determine minimum batch length.

To minimize cross-contamination of a batch product during change-over operations, the manifold valve control sequence manages a "flying change": one valve closing while another is opening.

Acknowledgment

The authors wish to thank B.S. Arya, Indian Oil Corp. Ltd., New Delhi, for permission to refer to the Kandla-Bhatinda pipeline project, and Burt Brockmann, Auspex Inc., Houston, for his cooperation.

Based on a presentation to Energy Week '96, Jan. 30-Feb. 2, Houston.

The Authors