Statement of John Wallace
Data Recording for Pipelines
Teledyne Brown Engineering

We see a lot of negative publicity about oil, product, and natural gas pipelines in the news, and it seems the media likes to cover accidents and doesn't always cover more positive news releases, like this one from Koch Industries that appeared on their Web site April 13, 1999. Koch Industries runs a lot of pipelines; mostly liquid pipelines. They have just won a prestigious award from the Smithsonian, and I'll just read a part of it.

It says, " Koch Industries' state-of-the-art pipeline monitoring program became part of the Smithsonian's permanent research collection on information technology." "The system uses centralized artificial intelligence to perform simulation analysis of more than a 125,000 points each minute from the company's crude oil and refined petroleum pipeline systems." "The Wood River Pipeline which transports crude oil to Koch's Minnesota refinery completed three full years transporting more than 2.4 billion gallons without a reportable spill." There is a lot of pro-active things being done in the pipeline industry to improve safety, and Koch has invested a lot of money to make sure they have the safest system possible.

What I want to do today is cover some of the fundamental introductory things you might be interested in knowing about supervisory control and data acquisition systems (SCADA) for oil and gas pipelines. Please note that this is not intended to be a sales pitch, even though I'm a salesman, and sometimes I try to get up on my soapbox.

This illustration is a generic pipeline. It has several sites shown, although a lot of pipelines have a lot more sites because there's a lot of facilities that are required to move products or natural gas through a pipeline.

Some of the instrumentation at these sites include pumps that pump liquid or compressors that compress natural gas and push it along the pipeline. Other sites would have measurement equipment, block valves, sensors to pick up pressures, and so on.

At the inlet there is instrumentation to measure how much gas or liquid is going into the pipeline. At the other end, there are sites that measure the product going into tanks or if it were natural gas, there would be sites called City Gate Stations where deliveries will be made out of a larger transcontinental pipeline.

This is a layout of a pipeline with a lot of different sites. There can be hundreds of sites monitored, and data can be acquired from these sites very rapidly. Many companies acquire data from all sites every five seconds. Critical data may come in even faster.

By way of introduction, let's talk about some of the things that have to happen in order to get this data that is at these different sites back into a central site and recorded.

First of all, the little boxes shown here are transducers. Transducers are varied, and I'm sure all the industries represented here use transducers to measure some of these same parameters, but in pipelines, they want to measure the temperature of the fluid, the pressure inside the pipe, the position of valves, the operating conditions of motors and engines, flow rates, etc..

In all pipelines, an accurate measurement of the flow rate is critical. A calculation is performed based on flow rate to determine how much product or natural gas has gone past each site in the pipeline. There are also a lot of contact closures and other kinds of contact inputs to the instrumentation at the remote sites, and there's all kinds of other transducers out there as well.

There are regulator valves that regulate pressure delivered out of a natural gas pipeline. There are often pulse outputs from positive displacement meters to measure flow. These meters feed pulses into instrumentation systems which process the pulses to accurately determine the flow rate and total flow for each hour of the day.

These transducers feed into another device, which I'm going to call a field device, but they are often called remote terminal units (RTUs). There are several commonly available kinds of devices which gather information from transducers and convert it into digital values that can be processed by a computer and sent electronically to a central location. Other devices that are commonly used to interface to the transducers are programmable logic controllers (PLCs), electronic flow calculators (EFCs in the gas pipeline industry), chromatographs (which measure gas quality in a gas pipeline), unit controllers for pumps (and compressors used for natural gas), and others which can be processed by field devices.

Many transducers are "smart" which means they contain small microprocessors, so that they can acquire the data and perform processing on the data. When a smart transducer acquires data, it convert the data to something a person can understand. For example, these transducers can convert an analog pressure measurement into pounds per square inch instead of a voltage or current reading.

Processing also includes computation of the data to provide flow rates that are adjusted for pressure and temperature characteristics and the chemical content of the gas. That kind of information, once processed, can become billing information from electronic flow calculators, EFC, devices.

Data are recorded locally in many of these devices because memory has become so inexpensive. EFCs can keep data at the remote locations for days or even weeks, if there is enough memory in the device. There are several reasons why that is very important: for example, communications is one of the weak points in these systems, so recording at each remote site provides on-site back-up if communications becomes unavailable. Traditionally, pipeline companies have had to rely on voice grade circuits or dial-up circuits which can become victims of all kinds of problems. If communications is lost with one or more site, data will be lost unless the device has enough memory to save hourly and daily readings. When communications is re-established, the system can bring itself up to date by reading that data from the historical file maintained at the site.

The smart devices can do a lot of control functions in a close-loop fashion, so that if they want to control a set point at a regulator valve to lower pressure gas into a city, they can issue a set point and control functions in the RTU or PLC can control pressure and set it where the operator at the central facility wants it.

And, of course, communications. Now, field devices do a lot of communications in this industry with central systems, and I'll talk about the communications features more when we talk about central systems.

This drawing shows the central facility, which may be located a long way from the remote sites. People like Shell in Houston and Texaco in have a lot of pipelines all over the United Sates. These pipelines are operated long distance, and they rely on communications to get data back and forth between the operations center that is manned 24 hours a day and the remote sites that provide the monitoring we've just discussed.

The central facility gathers data and processes it as required for the operational personnel. That may mean that the data that's collected is accepted as is from these sites. Some of the calculations done at the remote sites is not redone at the host site. Sometimes it is, but a lot more processing can take place with this data at the central site.

The standard kinds of processing you see in the traditional SCADA system are things like high and low alarm processing, high high and low low, rate of change alarms. If pressures start to increase or decrease too rapidly (rate of change), you would be concerned about that and an alarm would be sounded.

So, there's a lot of processing that takes place in the field and in the central site. We have what we call MMIs, the man-machine interface, which is not politically correct anymore. We now talk about OMIs, operator-machine interfaces, which are the way the operator interfaces with the system. They're just a bunch of CRTs that display the data to the operator and gives him processed information when he needs it, such as alarm notification.

The data recorded at the central site are more comprehensive than at the remote sites because most of the remote sites just don't have the amount of memory required. You can imagine what kind of memory and recording capability is required if you're going to try to keep up with a 125,000 points brought into your system every minute. That is a lot of data.

The central facility also is capable of interfacing with the remotes to set up controls. I mentioned set point control as a close-loop function at the remote. The set points themselves, say a pressure set point, can be issued from the central facility and sent out to remotes, so they can be changed on line in real time. So, basically, that's what's happening there at the central facility.

The recording of information at each remote sites is done a couple of ways. Data is recorded periodically at a remote site, such as every minute, every five minutes, every 15 minutes, every hour, every day, every week, or it can be recorded by events. Event-driven means if the remote site picks up an alarm, it may decide to start recording certain data or it may save off certain data in a special file that it has established for just that kind of activity. Since time is an event, they really are the same thing, but we tend to think of them a little bit differently. There may be an event which causes data that has been recorded to be sent to the host. There are all kinds of event-driven recording that can be done. One of the typical things we see is a process which records data points only when they change. Why fill up your memory with the same value in several times when it hasn't changed? Data saved only when it changes requires that the date and time be saved off as well.

The kinds of things you might record at the remote sites include what is called "accumulator" data. Accumulator data is how much product or natural gas has passed by that point in a certain length of time. Gas pipeline accumulators are normally saved off hourly at the remote locations and/or at the host, but most systems now save accumulators at the remote locations. From remote memory, you get hourly accumulator totals, daily accumulator totals, and alarm conditions. These are some of the data that are processed and saved in memory at the remote site.

It's really important that you understand this is not a comprehensive list of data that is saved at a remote site. There are all kinds of things that can happen at a remote site that you might want to remember. For example, in the gas industry, it's common for people to calibrate the instrumentation periodically. When they perform calibration, they have to keep a record, called an audit trail, so that they can document when they made these calibration adjustments along with the before and after conditions.

In the old days, when they had simple analog chart recorders, people would calibrate the transducers and write notes documenting the calibration on the chart by hand. Since they can't make hand written notes anymore, those notes have to be stored in the SCADA system. Things that happen at a remote site, like calibrations, gets tagged with the date and time and the individual who performed the calibration. Normally you get the ID number for the individual who performed the calibration in the record, so you can keep track of everything that's happened at each site as it occurs.

Recording at the central site is the same thing that happened at the remote: there is just a lot more of it. The central site also keeps the hourly totals, daily totals, and it provides some other facilities to merge data that may not be available at the remote sites. Chromatograph data may not be available at the remote site, but the data is required to accurately compute flow totals in a gas pipeline.

All events including alarms are recorded. An alarm is the same thing as an event that's brought to the attention of the operator. A kind of event that's not considered an alarm might be an operator sending a set point to a remote site. That's an event, but it's not an alarm, and, of course, the maintenance records that I mentioned earlier are also recorded permanently. All the activity at each site is recorded and kept in a database.

Many applications may run at the remote but there are not a lot of applications at the remote site that are recorded since memory is limited. Most of the historical data is maintained at the host site. At the central site, there is a lot more memory since the cost of the hardware has come down over the years. We do not have a problem with memory anymore. It is not unusual to have GB of memory with 10's of GB of hard disk available for historical data storage.

The on-line historical database, as we call it, is available to the operations people because they need historical databases for accessing how things are going throughout the day. Operations personnel may use a trend display which graphs the amount of gas that's actually been delivered at a point in the system versus the projected delivery. They can look at the historical data as it is accumulated throughout the day and see how well they did at forecasting the day.

But they can go back and look at any historical data very quickly out of this on-line historical database. The biggest difference between the on-line historical database and a relational database, which may be there as well, is that the relational database is more open to the rest of the company: the rest of the enterprise.

After the data has been stored in the on-line historical database, it is moved into a long-term relational database where data may be kept for years. It's not uncommon to see requirements for data recording in a relational database for two or three years. Once it is stored in a relational database, these data are usually available to anyone in the company.

The data in the relational database is available to personnel in the operations group. They need that data because they need to forecast of how much natural gas they need to deliver over the next few days. What they do is go back into the relational database and search for similar days in the past to use as a guideline for what's going to happen in their system the next day or so.

The relational database acts as a "firewall" between the operations group and the rest of the company which may be concerned with other things going on in the company that are not real time. This firewall is important because the real time operations are critical to the safe management of the pipeline and outside access could compromise the speed of the SCADA system.

Company personnel outside of the operations group may be doing engineering studies. Someone may need to access the database for training purposes. There's all kinds of other uses people need of that database for. There are times when someone needs this database to go back and reconstruct what happened during an upset condition in the pipeline operations. That is a very important part of the process as well.

Because hard disk drives are cheap, we see systems that require up to a hundred gigabytes of on-line disk storage. Of course, with a lot data points, you can imagine that's not an unusual requirement anymore. Having data on hard disk is very important, and then that data is archived off to some kind of removable media for even longer storage. The requirement for keeping data has always been there. Even when people used chart recorders, they had to keep charts in big stacks. I visited companies years ago that had rooms full of circular chart recording information, but that no longer is done in most companies.

As requirements and operating procedures change, the pipeline industry is well positioned to accommodate new data acquisition and processing. New hardware and software is currently being developed to enhance SCADA systems so that they can take advantage of new technology and perform their tasks more accurately and faster than before. A continual investment by the pipeline companies to maintain their SCADA systems will be required to keep them up to date. SCADA vendors must provide a cost effective path to upgrade these systems without a lot of difficulty. I hope that this introduction to data recording in the pipeline industry has been helpful.