NATIONAL TRANSPORTATION SAFETY BOARD
PIPELINE SAFETY HEARING
Leak Detection and Response
Conference Center and Board Room
National Transportation Safety Board
Washington, D.C.
Thursday, November 16, 2000
9:30 a.m.
Day 2 Transcript
Day 1 Transcript
Board Members Present:
JIM HALL, Chairman
CAROL CARMODY
JOHN HAMMERSCHMIDT
GEORGE W. BLACK, JR.
Board Staff Present:
BOB CHIPKEVICH
JOSEPH KRIS
Hearing Officer
ROD DYCK, Associate Director
Pipeline Division
JAMES CASH
DR. ERIC SAGER
ALAN BESHORE
DR. STEVE JENNER
DR. JERRY WEEKS
A G E N D A
AGENDA ITEM: PAGE:
Chairman's Statement 290
Chairman Jim Hall
National Transportation Safety Board
Panels:
Leak Detection Systems 292
Larry Stack, Neles Automaton
Alan Rodecker, Stoner Associates
Dr. Mike Yoon, Simulutions
Dr. Diane J. Hovey, EFA Technologies, Inc.
Kenneth F. McCoy, Tyco International
Independent System Design 401
Daniel W. Nagala, UTSI InternationalCorporation
Al Senftleber, Senftleber and Associates
Byron Coy, PE 439
Office of Pipeline Safety, Eastern Region
Pipeline Operators 460
Ed Nicholas, Alyeska Pipeline Service Company
Valencia Hiebert, Alyeska Pipeline Service Company
Mike Huber, Marathon Ashland Pipe Line LLC
Peter Evans, Marathon Ashland Pipe Line LLC
R.C. (Bob) Darwin, Member of the American Petroleum
Institute Cybernetics Subcommittee
P R O C E E D I N G S
9:33 a.m.
CHAIRMAN HALL: We will reconvene this Public Hearing of the National Transportation Safety Board that is being held on the subject of Pipelines and Pipeline Safety.
I'd like to welcome our guests this morning. For those who weren't with us yesterday, let me make a brief safety announcement.
In the event of an emergency, such as a fire, the building alarm system will activate, and a voice message will instruct persons to vacate the building. You should proceed to the nearest exit. There are emergency exits up front, to the left and to the right of this podium, and at the back of the room.
Also, for your convenience, restrooms and telephones are located in the foyer on the left as you exit the room.
If there is any questions or any assistance that any of the men or women that work here at the National Transportation Safety Board can provide for you during your visit with us, please just ask, and we'll try to see if we can't accommodate you.
I'm very pleased to note this morning that wehave with us the newly-elected congressman from the Bellingham area, Rick Larson. Mr. Larson, I believe, is in our audience in the back. I'd like for you to join me in welcoming the newly-elected congressman.
(Applause)
CHAIRMAN HALL: On a note before we move into this morning's agenda, regrettably, the pig that was located outside the door for observation yesterday will not be here today. The pig had first-class reservations on a USAir flight last night and had to leave. It's a tough crowd to get a laugh out of, I tell you.
We'll begin this morning with a Panel on Leak Detection Systems, and I'd like to ask our hearing officer, Joseph Kris, if he would please introduce the first panel of the morning, or Mr. Chipkevich, whoever.
MR. CHIPKEVICH: Thank you, Mr. Chairman.
On my left is Joe Kris, who's the Hearing Officer. On my immediate right is Alan Beshore, who's a Pipeline Accident Investigator for the Board. Rod Dyck, to his right, who's the Associate Director for the Pipeline Division. Eric Sager, sitting next to him, who's the Human Performance Investigator, and Jim Cash from our Office of Research and Engineering.
Mr. Beshore will be the person who will leadthe Tech Panel.
CHAIRMAN HALL: Thank you.
Please proceed, Alan.
MR. BESHORE: Thank you.
The next panel is the Leak Detection Systems Panel. On this panel is Mr. Larry Stack from Neles Automation, Mr. Alan Rodecker from Stoner Associates, Dr. Mike Yoon from Simulutions, and Dr. Diane Hovey from EFA Technologies, Incorporated, and, finally, Mr. Kenneth McCoy from Tyco International.
Panelists, I would like to remind you that you have 15 minutes to give your presentation. The yellow light in front of you will go on when you have two minutes remaining. The red light indicates that your time is up.
Mr. Chairman, the staff is ready to hear from the panelists.
CHAIRMAN HALL: Let me welcome each one of you, and we appreciate your willingness to come here and make these presentations this morning, and we'll look forward to hearing from each of you, and I guess we'll begin with Mr. Stack.
MR. STACK: Thank you, Mr. Chairman, for the invitation to participate in the panel.
This morning, I would like to take a more general deployment look at some of the technologies that are applied in our industry to the prevention, detection, location and isolation of pipeline leaks.
When we speak of this application and this technology, known as "computational pipeline monitoring", there are several aspects outside of the technology itself that must be considered, and I'd like to discuss those briefly in my presentation.
Including starting of the application --using the application of the technology in the engineering phase of the projects and the pipeline. Some of the pipeline infrastructure considerations that should be taken into account when applying this technology.
Also, the application of the technology itself to the pipeline leak detection prevention location application, and, finally, the role of operations, simulation and training is associated with equipping operators in their daily jobs.
Finally, in conclusion, some effective technology deployment considerations.
First, in the engineering phases, whether you're constructing new facilities or expanding existing facilities, in the engineering phase, thetechnology known as computational pipeline monitoring can be applied in an off-line modeling application to assist in the accurate design and verification of facility expansions.
In this technology, the advantage of using some of these techniques include visualization of the model, using modern drop and drag-type of techniques for construction of the model itself.
The application can contribute significantly to the design phase with variable fidelity, both in the dynamic and steady state calculations associated with the pipeline operations, and certainly linking to the business data that's involved in the economics and optimization of the pipeline.
One of the considerations that today's technology offers, of course, is the fact that one model can be used both in the design and engineering phases, on-line phases, and, finally, in the simulation and training of our operations people and engineering analysts on on-line type of applications, when operating the pipeline.
Traditionally, pipeline design had evolved with data acquisition systems, control systems being designed during the pipeline construction phase, and then, after that, is when the integration of logic,testing and training of the operators took place.
Using off-line technology in the design phase now allows us to do things like construct the actual control logic, begin starting and testing of our designs, and in fact training of the operator during the pipeline construction phase, allowing us to enter the line field phase of the project with well-trained operators who can concisely monitor and detect incidents on the pipeline.
Using the technology today, of course, building these models in a visual and graphic form allow us to better communicate to the engineers and to the operators of the specific design features and functionality of the pipeline system.
Regarding some of the pipeline infrastructure considerations that clearly affect the success of implementation of this technology include some points made here.
First and foremost is the communications infrastructure with regards to gathering data and performing control on the pipeline system. High-performance, reliable and deterministic type of communication is key to the successful and effective use of this technology.
Certainly as well, instrumentation withconsideration for the quality and accuracy of the instrumentation, the quantity of the instrumentation and, most importantly, the proper positioning or location of the instrumentation on the facility, and again during the design phases, this can be considerably improved during the design phases by using off-line technologies.
And an integrated model with the integration of other advanced applications associated with product movements, including monitoring and control, can give a common look and feel to the operator, allowing him to effectively and decisively operate and detect incidents on the pipeline and minimizing operator error.
The first level of application of this technology, and quite honestly most commonly used, is the on-line simple mass balance type of application of the technology. This is relatively inexpensive but appropriate if the infrastructure that we discuss regarding communication and instrumentation is weak.
It has general inaccuracies relative to some of the other technologies that we'll introduce today. It tends to be prone to false alarms during transient conditions and relatively slow than some of the other technologies, in the area of tens of minutes, to detect incidents, with lower location accuracy than can beobtained using advanced techniques.
But it does an effective job by accommodating for line pack and reasonable product tracking capabilities and inventory accounting type of capabilities.
The second and the most common technology looked at today is the on-line transient modeling. It represents a much more responsive type of technology with quite fast detection, in the order of seconds as opposed to tens of minutes, and it allows for these dynamic thresholds to minimize the false alarms which, of course, can contribute to our operations delays in terms of reacting to pipeline incidents, and has the capability to do proper detection through transient conditions on the pipeline.
It, too, provides very accurate product accounting and pig tracking and volumetric accounting applications. An accurate hydraulic profile generated from this technology allows us to monitor an alarm, maximum allowable operating pressures, even between measured points on the pipeline where we have instrumentation.
Some examples of performance attainable in a real application of this technology, the on-line technology, in the test environment are shown here, togive the idea of performance that can be achieved where communications infrastructure and instrumentation infrastructure is applied.
In this case, trucks were used, of course, to draw product from the pipeline. You can see in Test Number 1, 1.7 percent of flow rate or a small leak was introduced, detection times were in the two and three-quarter minute time frame, detecting losses of about less than five barrels.
In Test Number 2, about 50 percent more leak flow was detected in about 33 seconds in this case, limiting the loss during the leak to one and a half barrels.
In the final test, large leak, twice that of Test Number 2, five percent of flow, we were able to obtain with the technology in the order of 28 seconds of detection time and minimizing the leak to 2.3 barrels.
In these cases, this was a crude oil pipeline application, and you can see the performance that can be attained during the test procedures.
One of the key issues associated with applying this technology, of course, is the non-steady state operation, and in this chart, quickly just shows some of the issues that we have to deal with withrespect to heated products, cold products, transitioning in the pipeline, and, of course, the temperature profile shown here indicates injection of products of different characteristics with extremely different temperature issues to deal with as the product moves down the pipeline and cools.
With the simple mass balance type of technology that's generally used, this would be almost impossible. In fact, likely that leak detection system would be turned off during these type of conditions to reduce the false alarm situations.
We also had, just to present to you, some real world type of data. This was a case where we actually lost a gasket on a discharge valve. The real-time transient model was able to pick up the leak in 14 seconds, at about just less than five barrels of leak.
Of course, the operator was able to dispatch field personnel directly to a location within a few miles of the incident. The operator proceeded then under procedures to shut down the line. That took about four and a half minutes.
Proper officials were notified per procedure. Total loss in this incident was a 125 barrels. The good news, the clean-up and restoration was restored in the pipeline within about 11 hours.
Clearly here, the application of the technology during the training and simulation phase gave the operator the confidence to identify the leak situation quickly. False alarms were minimized to ensure that he was confident that he was making the right decision when he dispatched and began to isolate the leak, and quick action by the model, of course, minimized the impact of the incident.
One of the keys that we feel when working with this technology is to use it further in the training simulation area, using the actual pipeline to train the operator through the use of the model, and using the full control system integration with the simulation, so that the operator in fact has a consistent look and feel with his training environment as he does in the real-time operating environment.
This technology can include in-station simulation as opposed to just the pipeline simulation and the station simulation, including equipping the operator to deal with equipment failures in the station which also are common occurrences in his daily routine.
The accurate depiction of sonic events, very rapid communications, allowing resolution of the model every quarter of a second, give us the kind of accuracy that I was able to demonstrate in the real worldapplication.
The full function simulator allows a trainer to work with the operator, introducing malfunctions in equipment beyond just the ordinary scenarios that happen from day to day with the training model in control.
The full scope training simulator takes advantage of using the modeling technology that we know today, coupled with a virtual control system, to ensure that the operator is training on the same man/machine interface, the same look and feel that he is going to work with during the day in his job in the control center.
The trainer is allowed to use this technology to emulate the real field events, prepare scenarios, review procedures and process with the operator. He can be tested and retested to review procedures, and also traditionally these technologies can be used to review events, actual events from the field and to review and more concisely dictate procedures to be followed.
This current technology in respect of using this computational pipeline monitoring technology for real-time training and simulations to better equip our operators allows -- is different than traditionaltrainers, hydraulic trainers, in that the operator trains on a real situation on his real pipeline that he operates each day in his job.
The full control station simulation allows him to perform control. Sonic effects are reflected in the pipeline. So, he's dealing with real life situations.
Key to this is that he is using the same man/machine interface to make him very efficient and accurate in detecting the disturbances on the pipeline, and these technologies can provide up to greater than one percent accuracy for the critical variables that he must monitor and be aware of to detect application problems in the field.
To effectively deploy this technology, some considerations which I mentioned need to be looked at, but one of the key things that we look for the industry to begin to take seriously is to look at using one model in the off-line construction and design phases, in on-line, and in the training simulation application.
Using these techniques and giving the highest fidelity possible, we can have the best-trained operators, concisely able to detect leaks, to identify the incident in the system, to take decisive action without being distracted by false alarms.
The model itself must be self-tuning in order to minimize the false alarms which so often are the results of delays in taking action and isolating these leaks, and by following through with the technology to build effective training simulators, it ensures the operators that will recognize scenarios and pending incidents, practice fault isolation techniques, and make the processes and procedures second nature with respect to quick reaction to pipeline incidents.
With that, I think the technology today -- my final slide here would indicate that we believe the technology today, from the panel that we have here at the hearing today, can deliver. However, we need to employ technologies like advanced CPM modeling to our applications.
We do need integrated control systems and training systems with the on-line operations. We do need very accurate product and pipeline data to properly simulate and to model the pipeline in operation.
One of the problems that we certainly are dealing with is getting this very accurate data configured in the pipeline model.
We need integrated control systems and the advanced applications to allow the operator to be verycomfortable and familiar with the man/machine interface and the look and feel of these systems.
Finally, we need generally better communications. In the case that -- the examples I gave you, the real-life examples, fiber optic communications was being used, which gave us the benefit of being able to look at all pipeline parameters every quarter of a second or 250 milliseconds, giving very accurate representation of what's happening in the pipeline.
And, finally, the best instrumentation and control devices make the best model and the best prevention detection location and isolation of leaks, and we can, given that, provide very effective control in alarming for the operator, not to -- we can minimize false alarms and therefore his reaction time to events, and we can certainly create competent operators which take action immediately and concisely.
So, finally, in conclusion, as you will hear from the rest of the panel, the technology exists today, I believe, to move forward in this area.
Thank you very much.
CHAIRMAN HALL: Thank you.
We'll go to Mr. Rodecker.
MR. RODECKER: Rodecker.
CHAIRMAN HALL: Rodecker. Thank you, sir.
MR. RODECKER: I'd like to begin by thanking Mr. Chairman and the Board for this opportunity to present our technology.
Yesterday, we heard a lot of information about pipe integrity, specifically the pipe wall. Today, I'm going to talk about the technology we offer to the industry, looking inside the pipeline at the fluid itself, because behavior of the fluid in a leaking pipeline is different than the behavior in a sound pipeline.
But let me begin by giving you a short run-down of our current installations. We have more than 25 pipelines licensed with our technology, over 20,000 miles in length, pipe diameters that range from six inches to 48 inches, and the fluids are many crude oils and practically all of the refined products and natural gas.
One that did not make this slide is a CO2 application in South Dakota.
I'm going to run down briefly some leak detection techniques, so that I can give the Board an idea of where our technology fits into the bigger picture.
There are many. There are some physicalmethods, chemical detection, visual and acoustic monitoring. There's statistical methods, and there are those on this panel that can describe those today, and there's algorithmic methods, negative wave, volume, mass balance, and real-time models, and I'm going to focus on real-time models and give the Board an idea on how the technology works.
I think that's important because if you understand how the technology works, you can better understand its application and its limitations.
First, what is a real-time model? Mr. Stack talked about it as a transient model. I use the term "real-time model". It's a transient model. We also use the term "virtual pipeline".
A real-time model is essentially a virtual pipeline on a computer that continuously operates in step with the physical pipeline. It's fed data from the pipeline and keeps pace with actual pipeline operations.
Leak detection using a real-time model. I'll give you a quick overview of how this works. The real-time model continuously compares measured data with the virtual pipeline; that is, measured data coming from the physical pipeline is compared with calculated data from the virtual pipeline continuously.
If a leak develops in the physical pipeline, the measured data from the physical pipeline no longer match the virtual pipeline. The data in the virtual pipeline are then adjusted until the data match, and we look at these adjustments. We call them "hydraulic anomalies", and we look at those adjustments and analyze them.
If they're of sufficient magnitude and pass some mathematical criteria, we alarm a leak to the operator, and that leak alarm will have some information with it. It will estimate the location of the leak. It will estimate the size of the leak, and it will give a confidence level relative to the leak alarm itself.
To better understand how this works, I'll show three views of a pipeline. What we call the pipeline state is a physical pipeline. That's the steel in the ground, the tanks, the pumps, the valves and the fluid inside those facilities. It's continuous, both in time and distance.
That is to say, that all along the pipeline, there is pressure, there is flow, there's compositional analysis, there's temperature.
I've put a graphic up here showing the operator state, and I've got a controller that namedJoe, the operator, that looks at this sample pipeline, and what Joe sees when he controls this pipeline is a whole different view.
His view of the pipeline is discreet in both time and distance. He's looking only at three points on this pipeline, the beginning, the end, and the middle, and that sample data from the pipeline is only communicated to the operations control center periodically, and that could be five seconds, it could be 15 seconds, it could be five minutes, or like the example that Mr. Stack had, it could be fractions of a second.
The third view is the model state. It is continuous. The difference here is that the parameters inside the pipeline are estimated. There's estimated pressures, flows and compositions all up and down the pipeline, and it's continuous in distance, and it's also continuous in time.
I know the real-time model takes calculational time steps. Those time steps can be very small, and therefore for all practical purposes can be considered continuous.
So, the model is driven by data from the physical pipeline. This graphic shows data coming from the sensor devices on the pipeline being presented tothe virtual pipeline, but there's a problem in that the data from the pipeline contain errors or, more accurately, contain uncertainties, and these uncertainties have many sources.
There's some uncertainties relative or sourced in the instruments themselves, repeatability, time stamp, dead band filtering, calibration drift, to name a few.
There's also communication errors or uncertainties, analog-to-digital conversions, pulling or scan rates or even communication failure, and these errors are random. That is, we cannot use mathematic techniques to eliminate them.
So, we use a process that we call "state estimation" to treat these data, so that when they're presented to the real-time model, they allow the real-time model to accurately represent the physical pipeline.
We do this in a number of ways. First of all, the random uncertainties are related, and they're related because they're contained, and they represent a single body of fluid that's continuous all along the pipeline, and that's the behavior of the fluid that I spoke of earlier.
We apply the laws of fluid dynamics toestimate the best fit of every measured data along the pipeline, and they are voluminous.
So, let's look at our pipeline picture again. Here, we have a representation of the physical pipeline communicating raw, unfiltered data to a process, a technology we call "data filtering and state estimation", and from there, that data is presented to the real-time model.
Now, the real-time model must be tuned and calibrated to accurately represent the physical model, and there's many reasons for that, and there's many methods to do that, and I won't get into each one of those today, but I'd be happy to drill down into that technology should the Board desire.
So, what do you do with the well-tuned, real-time model that's running continuously? Well, you can do many, many things with them. One of the things you can do is look for leaks. That's what we're here to talk about.
I have a representation of a physical pipeline with a leak in it. We use two technologies that are working in parallel, working simultaneously to search for leaks in a pipeline.
One we call "leak analysis", and that's driven by pressures, and the other one we call "model-compensated volume balance", and that's volume- or flow-based.
So, let's look first at the technology of leak analysis. On the bottom, I have a representation of a physical pipeline with a leak in the middle. On the top, I have a representation of a virtual pipeline, the real-time model, with no leak.
In the middle, I've got a graph, and that will be recognized by many here as a hydraulic gradient. I'm plotting pressure on the vertical axis against the length of the pipeline on the horizontal axis, and the hydraulic gradient from the measured data, from the physical pipeline, in the white line, is different from the real-time model in the yellow pipeline, and the reason is there's more fluid in the upstream portion than there is in the downstream portion. So, therefore, there's more friction, and therefore, the hydraulic gradient is different.
The technology can look at that difference, and it can adjust the data in the virtual pipeline, so that those hydraulic gradients match, and here we show two flow rates coming out of the virtual pipeline. We call those "diagnostic flow rates", and they're necessary to make those two hydraulic gradients match.
When the two hydraulic gradients match, welook at those adjustments, and if they are of sufficient magnitude, and if they pass certain mathematical criteria, then an alarm is enunciated to the operator.
The second technology is model-compensated volume balance. Again, we look at both a virtual pipeline and the physical pipeline, and in this technology, which Mr. Stack described earlier, looks at the flow into the pipeline, all the flows out of the pipeline, and compensates for changes in inventory inside the pipeline between those two measurements.
If there's a difference, a significant difference between the real-time model, flow in and out, and the inventory, and the physical pipeline, then an alarm is enunciated to the operator.
But that's only half of the equation. The other half of the equation is what does the operator do when an operator gets an alarm? Well, if an operator gets an alarm twice a day every day, he's not going to do much. So, false alarms are very important.
But just as important, the operator has to conform to an approved procedure, and he has to practice response to rare or abnormal or dangerous events, and that can be aided significantly by training in a simulator.
I know there's members of the Board and in this room that are more familiar with the airline industry, which has a very long and successful track record in using simulators for training. So, I'll go through this very briefly.
Training on a simulator will translate knowledge into skill. You can recognize signs of emerging problems and act on those to mitigate their effects before they become dangerous, and, most importantly, you can exercise and practice response to rare events.
I've a comment here relative to operator training and the pipeline industry. The state of the science is such that a simulated environment can be created of such high fidelity that the pipeline operator cannot differentiate between operating the pipeline or operating the simulator.
Mr. Stack went through and explained how that works, but I wanted to point out that the degree of fidelity is such that you can get an operator that literally cannot tell whether they're operating the pipeline or the simulator.
In summary, the real-time model provides functional leak detection. Leaks are inferred from a virtual pipeline. The performance of leak detectionusing a real-time model is unique to each pipeline, and it's relative to the quality of measurements, the quantity of measurements, and the reliability of measurements and communications to the control center.
Operator response is enhanced through simulator-based training.
Lastly, I'd like to thank Mr. Chairman and the Board for giving me this opportunity to present our technology.
CHAIRMAN HALL: Thank you very much. We appreciate that.
Doctor?
DR. YOON: Thank you, Mr. Chairman, for the opportunity to share my experience and my thought in leak detection.
Since technical aspect is already fully discussed by Mr. Stack and Mr. Rodecker, I'd rather emphasize less technical aspect but more non-technical aspect, after I hearing those two individuals' presentation.
Okay. The objective of this hearing is to examine the capability of the existing leak detection and emergency response, and to understand the state of on-going research in this area.
To achieve these objectives, I'd like to putleak detection in proper perspective first, and then discuss what we like to achieve, if we can achieve, and also what kind of status we are in, and what kind of obstacle we have, and, thirdly, what kind of leak detection systems are available in the market.
So, in order to put leak detection into proper perspective, leak detection is one way to manage the risk and reduce the consequence of pipeline failure by ensuring fast and most likely, most importantly, reliable response to leak alarms.
If there are too many leak alarms, then operator tend to ignore that, and we have so many instances that why leak detection system fail in the past.
Okay. Leak detection, however, doesn't prevent and monitor the degradation of the pipe that leads to pipeline failure. In the strict sense, the leak detection has no effect on the technical integrity of a pipeline system. This technical integrity aspect of pipeline has been discussed fully in yesterday's hearing.
Okay. Let me define the scope of leak detection system as I see it. Okay. First, leak detection system includes field instrumentation and data gathering, such as SCADA system, and also leakdetection components, my two predecessors already described this kind of particular CPM method quite in detail level.
Okay. And also, one of the important aspect of leak detection system should include emergency response procedure, such as operator's response and confirmation of a leak, that type things, and also most important factor is, of course, pipeline operator, unless we have closed-loop control ideal system exist, but so far, it -- as far as I know, it doesn't exist.
As a result, pipeline operator is most important system which has to include, in my opinion, in the part of leak detection system.
Then ideally, what we like to achieve as a vendor, as a pipeline operator. Okay. One of the API's literature defines ideal leak detection system should never declare leak incorrectly under any operating conditions, even including select flow conditions.
Secondly, detect any leak always and immediately, and, thirdly, locate and size leak accurately, but I'd like to add a few more. Okay. First, isolation of the leak instantaneously is very important. If it is not isolated and is prolonged, due to whatever the reason, for instance, reliablerecognition, then still the fluid could be leaked.
And also, cost has to be affordable. If it is too expensive, then we're going to have a second thought, and also system is practical and easy to use and maintain. If you need half-dozen -- dozen different kind of rocket scientists to maintain the system, it's not practically usable.
Okay. I'd like to share some of the obstacle as I see. Okay. Pipeline configuration is so diverse, some of the pipeline is short, which is relatively easy to manage, and some of the pipeline system is so complicated and also quite long, and also, as Mr. Stack pointed out, instrumentation is very important, and quite often, sometimes, I won't say quite often, but sometimes, instrumentation is inadequate.
Also, data-gathering and availability is an issue, but these days, data and communication technology is well developed, and this is less an issue these days, and also operational issues, pumps start up and shut down, those kind of things in normal operation, but sometimes this one create will some of the -- create reliability problems, and also certain terrain is so unhospitable, and sometimes it create slack flow conditions. That kind of thing cause uncertainties.
Also, these days, pipeline carries -- single pipeline carries so many different kind of product, and recently, DRAs is quite often used to increase throughput, and the DRA, drag-reducing agent, change the radiological properties. So, simple modeling technique may not be easily applicable in such a situation.
Sometimes pipeline companies have some kind of difficulty to develop a concise leak response procedure and strategy because leak detection system is not 100 percent reliable, and also there seems to be no concise diagnostic tools to distinguish real leak from false alarms.
Also, emergency response is not -- certain company has well-established emergency response, but on the other hand, some companies don't, and also operators' or controllers' confidence levels sometimes is questionable when they are not fully trained.
And here, I'd like to share my experience and also identify some of the issues. Okay. In the past, last 20 years or so that I have been involved in this area, I saw many companies try this new technology in leak detection, but some definitely have a positive experience, but whatever the reason, some companies have poor experience, and either they got rotten systemor the expectation seems too high.
Also, I like to point out, frankly, that vendor tend to exaggerate the capability of leak detection system, and also, at this point, many companies do not have a leak detection system. Of course, I don't know exactly what's the main reason.
My question is that there's no -- they felt that there's no benefits or incentive to have a leak detection system. Particularly if you have unreliable system, of course, you don't have much benefit or incentive either.
So, at this time, some says that leak detection system is sufficient. Okay. I have a bit of reservation on that assurance. Definitely there's technical limitation, and key aspect is reliability, and also sensitivity will rely on instrumentation quite significantly, and also there are some non-technical issues has to be addressed.
For instance, usability, and some of the companies install this sophisticated leak detection system, but virtually they have more than half dozen people who support that. Okay. Those are acceptable or not, that's up to operating companies' discretions.
And here, one of the most encouraging things is API has taken initiative last several years atcoming up with nice guideline to evaluate particularly CPM, computational pipeline monitoring, system.
Okay. So, example include like API 1130, 1149 and 1155. Those are the guideline to follow, to evaluate CPM method, and also I saw that some of my clients have really nice -- they developed a nice response procedure, particularly in line with leak detection technology they have.
And also, one of the aspect we like to emphasize is the training aspect, and already DOT come up with some kind of guideline or some of the directives.
Okay. API 1130 defines several computational pipeline monitoring system. First is line balance. Line balance is applicable to short pipeline with small line pack, and also volume balance method. This one, on top of line balance, it take into account line pack change in the pipeline, and modify the line balance method, which we provide, includes elaborate hydraulic calculations, less demanding than this real-time model.
Of course, we both -- we offer both modified volume balance and real-time model.
Acoustic and negative pressure wave detection method. When there is a leak, then first pressure drops and also line pack is depleted, and the otheraspect is through the hole, it generate a noise, leak noise, and acoustic pressure wave -- acoustic method take advantage of this noise technique, and negative pressure wave takes advantage of this pressure depletion technique, and also pressure and flow monitoring is -- this technique is also used, same phenomena. Pressure drop and flow change.
Statistical analysis. This will be, I understand, discussed by my next speaker.
And also, there are a lot of leak detection techniques available. One is rate of pressure and flow drop devices. This was used to be a popular, but on the other hand, reliability again is a big issue. So, this is no longer that popular, and flame ionization method, this one is basically use the same principle that we have at home. What is it? Smoke detector.
And also, infrared thermography. Basically, it detect change in temperature, and leak detection peaks and hydrostatic pressure test methods were discussed yesterday session in fully.
Okay. As far as I'm concerned, I will say that I know the trend for research activity of every company, but I list through published literature and also through our activities.
I have observed the following trends. Ididn't see, at this point, I didn't see any technology breakthrough, but we continuously improve the existing technology, such as RTM method, and also many companies, I understand, focus on reliability and robustness.
Okay. It can be applicable any operating conditions, and also many companies also start developing emergency response in line with their leak detection system, and also they emphasize operator training.
As a conclusion or summary, definitely there's no ideal system exist, okay, but on the other hand, there are a lot of practical systems exist, and if I have any suggestion to pipeline companies, I rather start with the basic system rather than very sophisticated system.
Rather than run, we got to start walking first, and also emphasize on total solutions rather than just the leak detection technique only, including instrumentation upgrade, if it is necessary, and also leak detection technique, and also other factors, such as response procedures and operator training, and which is not on this slide, but most -- what I'd like to emphasize is a practical system rather than some system so elaborate that only rocket scientists can addressand maintain that system, and that's not workable in my opinion.
Thank you for the opportunity.
CHAIRMAN HALL: Thank you, Doctor, and is it Ms. Hovey?
DR. HOVEY: Hovey.
CHAIRMAN HALL: Hovey. Ms. Hovey. Dr. Hovey.
DR. HOVEY: Okay. Thank you.
Mr. Chairman, I'd like to thank you and the Board for inviting me here to speak today.
CHAIRMAN HALL: The button is out.
DR. HOVEY: The button is --
CHAIRMAN HALL: Not in. It's out.
DR. HOVEY: So, --
CHAIRMAN HALL: Is it working? Is everyone hearing you?
DR. HOVEY: It's working.
CHAIRMAN HALL: Okay. I apologize. Problem with my ears this morning. Proceed.
DR. HOVEY: Thank you.
Okay. The lead-in from the other speakers has been pretty thorough. I think I can be much quicker. Thank you for all of that pre-work.
The system that my company offers containstwo completely independent methods of leak detection. It contains mass balance with dynamic line compensation, which I think has already been talked about to the point of putting everyone to sleep. So, I shan't touch that part.
The part that is definitely unique is our statistically-based leak detection system, and within this package, the user has the option of using both one or the other. Since they're completely independent, it's the user's choice whether or not they want to use a full package or not. It's all in the box, and everything can be removed or added at their choice at any time.
The system can be offered as a stand-alone unit or it can be fully integrated into a SCADA system. Again, that's a user choice kind of issue.
It's presently licensed and monitoring over 300 pipelines around the world, and it's used on lines as short as small hydrant fueling systems through lines as long as a thousand miles that cross the United States, and the products that it covers are crude oil through ethylene, anhydrous ammonia, sulfuric acid, natural gas, methane, a large number of products, and it's the same product that gets put out at all times for monitoring all of those different situations.
Okay. Overview of the preceding methodologies. Mr. Rodecker covered this beautifully. So, I'm not going to touch on it very, very hard, but the computational -- the transient model is doing computations and matching the calculations against what's going on within the pipeline, and when it determines that there is a sufficient difference between those conditions, it declares a leak.
And in order to do this correctly, they need a great deal of information to create the basic hydraulic model, and that includes items like knowing the pipe diameter, and if the pipeline changes diameter, that information needs to be known and where that occurs.
The wall thickness, the pipe material, the pipe length, the insulation, how deep it's buried, its elevations, and if it's a very old pipeline, where we like to say the as-built drawings aren't, it makes it much more difficult to create a good physical database, and this can be extremely difficult when bringing the system on line.
It's simply a fact of life. We used to do a transient model, and I'm eternally grateful that we no longer do that.
The system also requires input from the SCADAsystem. It needs to know the flow rates, the temperatures, the pressures and the liquid properties, in order to be able to make correct calculations for what's going on within the pipeline.
For pressure point analysis, what we're looking at is not so much what's going on but the hydraulic noise and how that's changing. So, it's kind of an inside-out way of handling leak detection.
We're looking at only the most recent information, the most recent readings. In a liquid pipeline, this tends to be about the last five minutes, and if we're dealing with a relatively low-pressure gas pipeline, it might be the last hour, but we really don't care about what happened yesterday or 15 minutes ago.
The system is taking what is occurring now and looking for the most recent readings that are coming in and determining statistically if those are changing in a manner that's characteristic of a leak. So, it's looking for patterns within the noise.
Is there a pointer on this little thing? No. This particular -- is that the pointer? That one. No. Can I go backwards? Okay. I don't see -- okay. We're going to -- there it is. Good.
Okay. This particular plot was done duringthe early development of our pressure point analysis, our statistical leak detection system.
Each of these little bars that's across here is a two-second interval, and this was a leak test that was conducted on an emulsion pipeline. It was about a 20-percent water. It contained particulates, and it contained gas bubbles, about 25 miles long and about 26 inches in diameter, and we initiated a leak at that point, and what the graph is showing you is how that leak affect, that negative pressure wave propagates down the pipeline, and it moves at about the speed of sound in the product constrained by that pipeline.
So, in the case of crude oil, it moves at about 3200 feet per second, and in jet fuel, it moves it about 4000 feet per second, and what we're looking at then is the ends of the pipeline in this case.
We determined that the expansion wave, this trough that you're looking at, travels at about 25 to 30 miles before it begins to attenuate. So, for our method of leak detection, there's absolutely no need to put intervening pressure instruments. Instruments 25 to 30 miles apart see essentially the same effect within the pipeline.
We look at preferably -- where did it go? Flow and pressure at one end, and flow and pressure atthe other end, ideally. What this allows us to do is to monitor what's happening on the pipeline because if it's a leak, we're going to have an increase of flow rate down here at the pump or compressor end because we're essentially now serving a lateral to the pipeline, and down on this end, we're going to see a reduction in speed for the product going through the pipeline because some of it's being siphoned off through the hole in the pipe.
So, if we're monitoring all of those instruments, what we're looking for is the change at a given instrument. We're not comparing values. So, the relational change of the flow meter at this end in the expected direction with the pattern that we're expecting to see, that instrument, that given instrument within the system says I think I see a problem.
The pressure instrument at this end agrees. Then down at this end, if the flow instrument here sees a pattern change that's a decrease in the flow rate, without comparing values, the system will know that it had a leak on the pipeline.
If it had a pump drop at this end, that flow rate's going to decrease instead of increasing. So, the system's logic is able to determine that that was atransient activity and not a leak. So, it can effectively separate transient effects from leaks, and we have a number of installations that do have a 100 percent nuisance alarm-free operation, but it does require proper instrumentation at the ends and good response back to the leak detection system.
We also require a 16-bit resolution because the 12-bit resolution that's fairly common in some PLCs will create a stair-step effect in what the system is looking for, and we will lose leaks in that essence because the small leaks are smaller than the stair-step, and hopefully I haven't lost anyone on this or put them to sleep. Okay. That's our expansion wave.
Essentially, if we're looking at pressure across here, the system is expecting to see it extend out pretty much the same way over time. So, if we have a leak, the statistical filters determine that we have something going on here that is not normal, and, so, our range of detectability is in this window here, and depending on how much noise is normally on the pipeline, because we do have to accept the normal peak-to-peak variation that's caused by bends, valve operation, you know, the usual things that occur within a pipeline, we accept those as normal. They're random.
We're looking for the pattern that's hiddenwithin the random noise. So, we can -- it's gone. We can detect very small leaks out of the noise, providing that they are at the edge or somewhat larger.
So, in this instance, okay, this is a tank facility, and here, there's the arrow, you can see that we have pressure transmitters and flow meters across the pipeline at this location. That separates the portion of the pipeline that's going down to the wharf that we're monitoring. That separates us from the tanks.
So, the system is able to determine when a tank switch or something else has occurred or whether a switch between holes on a ship has occurred, and we have good pipeline leak detection within the facility on lines that are normally considered fairly difficult to monitor.
Flow meters, and this particular facility with these five lines has been nuisance alarm-free since it was installed three years ago.
Okay. What keeps leaks from being seen? That is a big question. Leak detection sensitivity is context-dependent. Okay. The leak detection system cannot respond to anything that the instruments are not reporting back to it. So, those instruments must be capable of responding to the changes caused by a leak.
In our case, we only need the instrument to be repeatable. That means that if it's given the same situation multiple times, the instrument will give us the same answer. It doesn't have to be the right answer, but it's got to be the same answer because we're looking for a relational change, not a specific value change, and communication with the field instruments must be stable, and, yes, it's getting better, but it isn't always great.
You can have a mix of communication systems be radio, microwave and other things coming in, and they aren't always consistent in the data that they're getting to you, and some pipelines that run across Texas, Oklahoma, there are huge sections where there's just no way of getting data back, and, so, those pipelines do need to be monitored with larger spaces than is desirable with the instrumentation.
Instrument noise. I think we've all talked about it in one range or another. It's the instability of the instrument. It's repeatability. Corruption of measurement values, data conversions.
Some PLCs and other equipment as they pass the data in can truncate significant digits that contain information that says that there is a leak on the pipeline, but in order to have fewer visiblechanges on the displays, that information can be removed, saying that maybe it's a one- or two-pound change, so that it stays constant on the display, but for leak detection, that means then you're not getting the information you need.
So, in our case, we need to come in underneath that and take the data before any of the trimming has taken place, and voltage drop and radio interference can also be a problem.
Hydraulic noise. All of the leak detection systems tend to have problems with that. Pumps and compressors. If the instrument's placed too close to a pump, what we're going to be seeing is variations in discharge pressure as opposed to the real pressure on the pipeline.
Control valves that are correcting too quickly. They put a lot of hunt and seek and over-ranging on the pipeline, and, so, models and our system both have to deal with a fluctuation that really doesn't need to be there.
Bends and constrictions on the pipeline create hydraulic noise and obstructions or places and insertion tubes, all of those create fluctuations that have to be dealt with, and how do you know it works? That's always a big question.
When we go out to sell a leak detection system, we actually like to go out and do an on-line test before someone purchases a system, and for our type of technology, that's easy to do.
This particular pipeline runs across the Persian Gulf. This is on the island of Bahrain, and the line is over at Saudi. The leak is -- was generated on the Saudi side. The leak detection system was over on the island of Bahrain. We detected on a loss of three gallons, it's a quarter-inch leak, and that was about a half a percent flow with normal operation on that pipeline, and they routinely test this leak detection system, so that they know that it's operating at the level that it should be.
And that completes my presentation, and thank you.
CHAIRMAN HALL: Thank you very much, and we'll move to our last presenter, Mr. McCoy.
MR. McCOY: Thank you, Mr. Chairman, Members of the Board.
My name is Ken McCoy. I'm the General Manager of the Tracetec Product Group, formerly part of Raychem Corporation, which may be a name recognizable to some of the pipeline people in the audience. Raychem was acquired by Tyco International about 15months ago. So, we're now part of the Flow Control Division of Tyco International.
I'm going to talk about the different approach to leak detection than the four speakers before me. Our system is a direct contact physical or chemical detector. It's a sensor cable that is placed in proximity to the object that we're trying to monitor for leaks, in this case pipeline, and as you'll see, it has quite a different profile of operation than what you've heard about so far this morning.
In many ways, it's a very good complement to the SCADA technology that you've heard so much about.
First of all, I'd like to just dwell a second on the issue of speed. You've heard quite a bit of discussion this morning of how important it is to detect a leak quickly and to shut down the line, and, of course, in the context of major pipeline failures, that's a very important characteristic of the system. You have to be able to stop the pumps, close the valves quickly in the event of a blow-out.
But there are other situations that occur when the leak is essentially a small low-rate leak, but if it goes undetected for a long time, it has very similar consequences to a big leak that lasts a little while.
These are particularly important in environmental issues, contamination of aquifers clean-up. One of the things that's important from a public relations point of view in fact is if you know about a small leak yourself as the operator, you can go out and react to it. You can get your own crew out there before you're notified by public agencies, before a neighbor calls up, before someone smells hydrocarbons or, as in the case of Mr. Johnson from Alyeska yesterday, the last thing you want is that leak detection of last resort, to have a big enough problem that you see it in the weekly fly-by.
So, we're looking at a different range of leaks, but it's an interesting range. This is data that's taken from the Office of Pipeline Safety database on their website. The horizontal axis is spill size in hundreds of barrels, and the vertical columns are just a physical count of the number of incidents that have occurred since 1986. This database goes from '86 to '99, and what it shows you is that there are quite a few small spills.
In fact, 70 percent of their total reported incidents were 500 barrels and less. Now, the big ones, the far right-hand bar, they make the news. That's the blow-outs, the catastrophic failures thatwe've heard about, but as you can see, the actual size of spills, the great quantity, is on the left-hand side, where they're much smaller.
Now, either that's because the SCADA systems are working very well or because a lot of spills are very small, slow leaks that get reported and detected visually.
So, I want to talk just a quick summary. You've heard so much about SCADA, I won't dwell on this. In fact, I'll just jump right to those three indented points in the middle.
What that says is that if you have a large deviation from the predicted flow in the pipeline, the SCADA system can detect it very quickly. That's the kind of percentages we're talking about blow-outs. Let's say, three, four, five percent or higher fraction of the line flow is suddenly missing. SCADA is going to find it. It's going to shut down the line.
The smaller deviations take a longer time. I think Mr. Stack's data, we heard earlier, kind of goes along with that. But the problem really is that very small leaks may go undetected in their entirety.
This curve -- I apologize for the quality. This was taken from the website of one of the SCADA companies. This actually is from a British company. Ichose this particular graph because it's one of the few sites that actually showed this relationship graphically.
The horizontal axis here is percent of the leak or percent of the flow in the line that's leaking, and the vertical axis is the response time in minutes, and this is pretty consistent with the data that we already saw this morning.
Basically, what it says is if the leak is in excess of, let's say, four percent, SCADA is going to find it quickly, shut down the line in a minute or less, but as that leak percentage moves to a smaller and smaller fraction of the flow rate, the response time gets larger, and in fact, if you get down to the flow rates of less than half a percent, certainly down in the tenth of a percent range, the detectability gets very, very long.
Now, if you do a little arithmetic, you can look at the consequences of this. What this slide basically says is that if you take the total flow rate in the line, you multiply it by the fraction that's leaking and multiply that by the response time, you'll have a good estimate of the size of the spill before the system is able to detect it.
So, now we're taking the time parameter,which has been emphasized quite a bit up until now, looking at what that real percentage and time means in terms of total quantity spilled, and what this says is that if you have a high rate of leakage, you detect it quickly, you have a relatively small spill.
If you have a low rate of leakage, you can take longer and still have a small spill, but there are two relatively large or two bad situations. One is that you have a high rate of leakage, and you react slowly. That's going to give you a big blow-out, and likewise if you have a low rate of leakage, but you just failed to detect it, over time, that will grow into a very big problem.
Now, I don't want to try to have you interpret the entire graphic here. This is a little bit too much data, but this is the implications of that curve that I previously showed you, and what I want to draw your attention to is the left-hand lower corner.
What you see in those columns are very small fractional leak rates but allowed to exist over relatively long times, and these are the kinds of spills that are being detected visually today.
This is the fly-over spill or the one where the hiker smells gasoline in the creek bed or calls it in. It's the kind that are not being detected by thesystem, and oftentimes these are being detected by people totally unrelated to the operation of the pipeline.
Okay. Now, I'm going to shift over to the alternative. This is the technology that my company manufactures. This is a leak detection cable. The cable itself is about three-eighth inches in diameter. It reacts to the physical presence of the liquid hydrocarbons. This is not a system for natural gas pipelines. This is limited exclusively to liquid hydrocarbons.
It reacts to the liquid or it reacts to very high vapor concentrations. The time that it takes to react is a physical determined process. It takes anywhere from about 10 minutes for gasoline up to several hours for a heavier, less volatile liquid. A crude oil, for instance.
Well, the implication of that, as I'm sure you can appreciate, is you would not want to use this thing exclusively for a rapid shutdown. You don't want to have a pipeline leaking for two or three hours in a major blow-out condition while you're waiting for this sensor to react.
But the converse is that in slow leaks, this will still react in 10 minutes, as soon as the gasolinegets to this sensor cable, whether the leak is a few gallons per day or a few hundred gallons per minute.
As a bonus, these systems are able to tell us the location of the leak, plus or minus three or four feet, actually a little better than this slide shows, and certainly within backhoe digging accuracy to go out and investigate the problem.
This is a cross-section of the sensor cable that I'm talking about. You can see a bundle of wires in the middle. Those are primarily used for communication within the cable. The two black wires are the actual sensing electrodes. The black band that you see in the middle of this slide, that's the actual sensitive element of the cable.
That's a sponge, if you will, that soaks up jet fuel or diesel or gasoline, and as it soaks up the liquid hydrocarbon, it swells physically. As it swells, it eventually makes contact with those two black wires, and that's the switch that turns on the detection mechanism and helps us locate where the spill has occurred.
For the pipeline application or beneath tanks or buried valves, we put the sensor cable into PVC conduit. This is slightly thicker wall, slightly larger in diameter than what you'd use in your backyardsprinkler system but pretty darn close.
The difference is that there are a series of cuts made into the wall of this tubing. It's essentially an electrical conduit that keeps the dirt and the sand out but allows liquids and vapors to get into the interior, and we use it as a conduit.
We have this installed while heavy construction is going on. We come out to the job site after the heavy physical work is done, and we pull the sensor cable into place, just like an electrician would pull wire into the conduit in your home.
This is a cross-section showing how the sensor is installed in a pipeline application. Typically, we would like to get this conduit and cable system anywhere from the 5:00 position or the 7:00 position relative to the pipeline. It sits in the same trench with the pipe. It sits on the sand pad that the steel pipe rests on.
This shows a new construction example. It's probably the most effective way you can pick up spills a little bit earlier, but it can be trenched in along-side at greater expense obviously, and what we do is we install long runs of this conduit, typically anywhere between 400 to 800 feet between pull points.
This is the same kind of data but for thecable, and the point I want to draw your attention to here is the relatively large numbers on the right-hand columns.
What this says is that if you have a major blow-out, and it's a less volatile fuel, like a jet fuel or a diesel or heating oil, crude oil, you're going to spill quite a bit before you detect it. So, the cable by itself is not the answer either.
But we have a complementary situation here. Where the SCADA is weak, that is, in the small slow leaks, the cable does a very good job at limiting the spill size, and, conversely, where the cable is weak, in that it cannot react quickly enough to a large blow-out situation, the SCADA is quite good.
Graphically, this is what it translates to. If you look at the red line, this is the SCADA curve coming from the upper left and going to the lower right. This is when you translate that earlier graphic I showed into barrels spilled, and I'm using a 5000 barrel per hour flow rate here. This is an 18-inch line. Basically, this is the data that was used for the Longhorn Pipeline being considered in Texas.
If you look at the blue line, that's the cable system by itself, and again you'll see over to the right side the amount spilled at high leak ratesfor cable by itself is just too high.
But the important line is the green line. If you use the two systems together, they complement each other so nicely, we essentially cut the knee off of that SCADA curve, and the two together are a very nice system.
All of the improvements in SCADA that we've been hearing about, the lines of development will essentially push that red line further down and to the left, but they won't change the fundamental shape of that curve.
I won't go over that. Just to show you, this is the same set of numbers but with the two systems combined, and you can see, just like the green curve showed us in the previous slide, the total spill is quite constrained with both systems.
This is the cable reel, and why isn't it being used? Well, it actually was developed in response to some EPA regulations in the mid-1980s. The Underground Storage Tank created quite a market in double-wall pipe and double-wall tank, and this cable has been manufactured since the mid-'80s but primarily installed in double-wall pipe systems. That would be jet fuel distribution at airports within fenced facilities. It has not been used on line pipe to anydegree at all.
We began experimenting with this direct burial technique in the mid-'80s, actually working with the utility company in New York City to monitor oil in high-voltage pipe-type cable, and in those applications, we developed a slotted conduit as the best mechanism for installing the sensor cable.
We began working with single-wall pipe on some pilot facilities in military airfields in the early '90s, and those have been our test beds. Some of the worst case conditions we've seen have been in those brackish water, swampy conditions in South Carolina, monitoring a Marine Corps air station fueling facility there.
More recently, we've had numerous installations of this product using this installation technique beneath aboveground storage tanks in California, under valves, under tanks, under valve manifolds.
The State of Florida has looked at this and decided it's a pretty good technique and has approved it for use under their aboveground storage tanks, but our first true long-line pipeline application is scheduled to go into ground this Spring, and that will be the Longhorn project in Texas.
Instrumentation for this system is we basically look at about a mile-long segment of cable. We look at it with a very low-power small instrumentation node. The instrumentation consumes only about one watt of power. It's actually low enough in power that it could be solar powered, and it can communicate directly with the SCADA communications backbone, although we are looking at some tie-ins to what's known as microburst technology to take advantage of cellular phone systems, essentially to allow this system to operate totally independently and as a redundant system to anything on the SCADA package.
So, if SCADA communications break down for whatever reason, this system theoretically could operate entirely independently of that communications channel.
I apologize. I didn't know that you were not supposed to consider cost. I put this slide in before that, but this is a big significant issue for the pipeline operator. This is at this stage a relatively expensive system, as much as $50,000 a mile for new pipe installation, although we do expect that cost to come down rather quickly as volume increases, and if you're going to ditch it in, I have one anecdotal bit of data that says it costs around $25,000 per mileextra to trench that in along an existing pipeline.
So, in conclusion, SCADA is great. It's good for long pipe runs, but it does have some significant disadvantages, that being that it's relatively insensitive to low leak rates. It is approximate only in its location capability, and as we've heard, there's quite a bit of balancing here between false alarm rate and sensitivity.
The more sensitive you make it, the more likely it is to create false alarms. The more false alarms you create, the less likely an operator is to respond. So, you're in a constant balancing act of sensitivity versus false alarm rate.
The sensor cable. Basic disadvantage there is that it's very expensive, and people just are not going to be willing to put it in the long runs of pipe. The response time is a little slow, so we wouldn't want to operate it by itself. But the two together are a very nice package. They are probably very appropriate for the SCADA covering the long runs, and the cable being used in areas where there is high consequences, extreme environmental sensitivity, or issues of that like.
Thank you very much.
CHAIRMAN HALL: Well, I'd like to thank thepanel, and I'd like to -- there's a whole number of questions in my mind, but I think they'll probably --well, most of them will be addressed by the Technical Panel and my fellow Board Members.
But let me just stress before we go to the panel the importance of your work and the importance of these systems.
I was trying to sit up here, Mr. McCoy, while you were presenting, just thinking about, since I have been the Chairman, the brief period of about six years, the leaks that we have gone to that affected the Tennessee River, which happens to be the drinking water supply for my hometown, Two Mile Creek up in Kentucky, a whole marshland in Grammercy, Louisiana, the Reedy River in South Carolina, the Patuxent River in Maryland, the Rappahannock River here in this area, and another response we made on the water supply -- that leaked and almost reached the water supply for Dallas, Texas.
So, we respond on environmental spills as well as damage to human life, and I just -- you know, this is extremely important, and I appreciate all of you all being here and providing this background and information.
We'll move to the panel. Mr. Beshore.
MR. BESHORE: Thank you, Mr. chairman.
What pipeline-operating conditions and/or physical pipeline system characteristics have the most negative impact on the effectiveness of the CPM leak detection methodologies?
MR. RODECKER: I'll go ahead and take that.
Pipelines are dynamic typically. There are those that operate in stable conditions, but as pumps turn on and turn off, they create pressure waves and transients that bounce around inside the pipeline, and that limits the effectiveness or the performance of the leak detection system.
Also, the instrumentation itself. A well-instrumented pipeline will have higher performance, as Mr. Stack demonstrated with the one that had the fiber running next to the pipeline.
So, it's instrument -- it's got to be instrumented appropriately, and then, when it's dynamic, then the response of the leak detection system, the CPM system, will be degraded during that period of time.
Those that have leak detection thresholds or alarm thresholds that are fixed likely will be turned off during those periods of transient times. Those that are dynamic, the alarm thresholds are dynamic andgo up and down relative to the hydraulic performance of the pipeline, likely will not be turned off. It's a way to minimize false alarms.
MR. BESHORE: Does anybody else have anything to add to that?
DR. HOVEY: I'd like to make one comment, also, that the instruments have to be maintained. If the instruments are not well maintained or if, let's say, a meter isn't functioning properly, it will, you know, create problems for both systems, statistically based or the model based. So, maintenance, I think, is crucial.
MR. BESHORE: Can you describe the impact of data communication losses on these systems, and how quickly they recover once communications are restored?
DR. YOON: These days, communication technology is well advanced. So, many SCADA companies, like Neles Automation, take advantage of that kind of technique fully.
But on the other hand, occasionally there is communication outage, that kind of thing occur. That's unavoidable part of it. So, these days, most CPM method will try to take into account those factors as much as it can, but specifically how do it -- how we do it, each company has different approach.
MR. RODECKER: I might add one comment. In the -- particularly in the natural gas industry, I mentioned real-time models do many things.
One of the things that they can do and do do in application, where there's a communications failure and part of your pipeline goes dark on the SCADA screen, pipelines that have a real-time model can actually operate their pipeline using the model data for a time.
Of course, those estimates get less and less accurate as time goes on.
MR. BESHORE: Anybody else have anything??
(No response)
MR. BESHORE: Now, how about start-up conditions? How quickly after a pipeline starts -- is started up do these types of systems become effective in detecting leaks?
MR. STACK: I would comment that once flow rates have stabilized, and the model can populate them, they can become effective within days of pipeline line fill.
MR. BESHORE: Well, yeah. I wasn't necessarily referring to the initial start-up of the pipeline at the beginning of a new pipeline. I was thinking more in terms of restarting a pipeline, youknow, in regular operational conditions on a day-to-day basis.
MR. RODECKER: Let me respond briefly to that. Pipeline start-up and shut-down is an example of a control move on to a pipeline that creates pipeline transients. It's a significant one and probably an extreme condition, but a pipeline that is shut in, that the pumps are stopped, and the valves are closed, you can still have computational pipeline monitoring.
So, you can go through the process, albeit degraded, with those pressure transients caused by the start-up, and you'd want to be very careful with interpreting alarms during that period because a lot of things happen during pressure transient waves inside the fluid during start-up.
DR. YOON: I'd like to add one comment to that. When pipeline is shut in, then quite often, valve is closed, but if instrumentation is not properly installed, then you are basically cut off because of the valve closure.
So, those kind of effect has to be taken into consideration, and also temperature is another factor. So, temperature can be measured, let's say, in the middle run or something, and it can measure ambient temperature, not the fluid temperature, then it cancause some kind of false alarm, too, if temperature is falsely interpreted.
DR. HOVEY: Okay. We all get to take turns on this one.
With the statistical methodology, when a line is blocked in, and it's static, for us, the sensitivity is considerably tighter, and we can find much, much smaller leaks than we can when the line is flowing, and our system for the State of California has this underground storage tank regulation for -- they don't care what size the pipe is. It must meet certain criteria, which is the three gallon per hour at 10 psi if the line's connected to an underground tank, and our system was able to get third party certification to do that.
But there's no way in the world we're going to have that kind of sensitivity when the line's flowing. When your system then starts back up into operation, how long it takes for the line to get to steady state has a lot to do with how long that pipeline is and what the product happens to be, and for our system, we go to a degraded level of sensitivity, so we can still detect leaks, but prior to start-up, you know that that line was solid because you've been monitoring in a static condition.
Then it transitions into the flowing state and then stabilizes back out, but you will have a degraded period during that transition.
MR. BESHORE: Mr. Rodecker, I think you kind of touched on the next question, but can you describe some of the differences between natural gas transmission and hazardous liquids pipelines in terms of the key monitored variables and the associated modeling equations and leak detection capabilities?
MR. RODECKER: There are two. But, first, two major differences, but first let me tell you that the technology is equally applicable to natural gas as it is to liquid pipelines.
However, the performance is much different, and there are two reasons for that. One is physical. The physics of the natural gas fluid are much different than a liquid fluid in terms of compressibility and wave speed. So, where there's a leak on the pipeline, the fluid properties transmit the signature of that leak up and down the pipeline. That movement is much slower in gas than it is in liquid, and the amplitude of that signature actually dissipates in the compressibility as it goes up and down the pipeline.
So, the first one is the physics. The second one is more the business of gas pipelines. Liquidpipelines tend to measure everything coming in and out and to communicate those measurements to the control center on a very frequent basis.
Legacy Gas Systems, natural gas pipelines and transmission and distribution, measure everything coming in and going out, but the communications of that data to the control center sometimes do not exist. It might be a dial-up information that dials up and reports the flow data once a day, or it could even be paper charts that are collected every seven days, and the technology cannot differentiate between a leak in the vicinity of a seven-day chart that has a big increase in flow. It just cannot differentiate between the two.
So, the one is a physical, having to do with the difference in fluids, and the other one is the way the flows are transmitted to the company.
MR. BESHORE: Dr. Hovey?
DR. HOVEY: Could you give me the question again? I think I was woolgathering.
MR. BESHORE: It was mainly in terms of the differences in approach between natural gas pipelines and hazardous liquid pipeline facilities.
DR. HOVEY: Okay. For statistical leak detection, like Mr. Rodecker said, it's the speed atwhich it occurs in the pipeline, is the main difference. Statistically, it's handled at exactly the same, except that we use a slower update rate, and the window of time that we look at can be as short as the five minutes but frequently it's closer to an hour.
We've got some pipelines that actually operate almost like a fluid line, so that the update rate is the same as a fluid line. We have other gas pipelines that operate at high pressure, going under long segments of water. The instruments are about 240 miles apart, which does limit the lower end of sensitivity, but we're still detecting about one percent of flow leaks, even though our instruments are about 240 miles apart. But again it's because we're looking for differences in the noise that's within the pipeline. So, it makes it easier for our system to be sensitive.
CHAIRMAN HALL: Mr. Beshore, I think that's an appropriate point for us to consider a break. I have been observing the faces in the audience, and I think it is time for a break.
Let me tell you before you move from your seats, please, the plans for the day because we've got a lot of information we still want to get in. We'll take a break now.
Wherever we are at 12:45, we'll stop for lunch. We will only take 45 minutes for lunch, and, so, if you want to slip out a little early or you want to -- whatever you want to do, and then we'll start and reconvene at 1:30.
I don't think the way it's going, we'll be able to not try to break into some questions or something at some point, but that will be -- we'll take a break now, break for lunch at 12:45. The afternoon will start at 1:30.
I'm aware that a number of people have flights and things this afternoon. So, we'd like to try and move it along.
So, we'll stand in recess now for about 15 minutes or come back here about 25 after. Thank you.
(Recess)
CHAIRMAN HALL: I'm going to reconvene this hearing, and the first thing I'm going to do is exercise the prerogative of the Chair, if my three Board Members don't oust me, to ask two questions.
Why don't all companies have leak detection systems? Does anybody want to take that on? I've heard all the technical. You've convinced me that we have many, many aspects, and I'm watching all the --and I'm just wondering why don't all the companies haveleak detection systems.
DR. HOVEY: Okay. I'll stick my neck out.
CHAIRMAN HALL: Dr. Hovey.
DR. HOVEY: We have -- well, first of all, we have a lot of customers that are extremely proactive, that have spared no expense in putting in a good leak detection system.
Then we have other people who come to us who are definitely interested in putting in a leak detection system, but when they start looking at all of the costs that are required for the instrumentation, the leak detection system, and everything else that goes with it, and then they look at their competitor across the street, who has no intentions of putting in a leak detection system, and then they look at the bottom line of what their investors are going to think about the profitability at the end of the year, they elect not to put in the leak detection system, simply because of the bottom line issues, not because they're uninterested or unwilling to do it.
CHAIRMAN HALL: So, the absence of any type of level playing field of minimum regulations in this area leaves it, you know, where it's -- obviously the good soldiers here are bearing an unfair economic hardship many times, if they are being proactive interms of safety.
DR. HOVEY: I believe that's correct.
CHAIRMAN HALL: Mr. McCoy, you mentioned this double pipe. You want to tell us about what a double pipe is, and how extensively that's used by the military or around the country?
MR. McCOY: Well, it's a technology that basically came into being as a result of quite a bit of EPA regulatory efforts in the mid-1980s.
Double pipe is what it sounds like. It's a smaller pipe inside a larger diameter pipe. Many of the companies that produce those type of systems were in the business of making insulated pipe systems for hot water and chill water delivery, and you take the insulation material out, put a set of centralizers in there to keep those two pipes concentric, and you have a double pipe.
One of the problems with it is it's very craft-sensitive to install. It's quite a bit more difficult than welding up single wall steel pipe, and we've sold quite a bit of our product into that marketplace but not without quite a few difficulties.
It's a tough installation. The rewards you get for that extra cost is you can contain a leak when it occurs. You can put it into a very easy-to-detectenvironment. Basically if you put a sensor cable like ours in that space where there is nothing, and suddenly there is a pool of diesel fuel, you can tell that pretty quickly and cleanly and know where it is.
But it's very expensive. It's roughly four to six times the cost of the equivalent single wall pipe. So, it's installed rather limited in sizes, certainly not in the scale of diameters that we're talking about for true pipeline operations. It's primarily installed inside of fenced facilities, military.
Air fields have used quite a bit of it. Commercial establishments might use it. A car factory, for instance, would have underground storage tanks with various liquids, and they would pipe that to the assembly line in double wall pipe. So, it's primarily a smaller scale of installations than what we're talking about here in this hearing.
CHAIRMAN HALL: Are you aware of anyone that has used it for environmental reasons, such as crossing rivers or being near drinking waters or sensitive --
MR. McCOY: Well, there's case pipe crossings frequently used. I can't speak, I'm not that much of a pipeliner to talk about river crossings, but certainly road crossings are -- oftentimes a larger diametershell is used as a conduit to put the line pipe through.
I don't know that that's been done extensively for aquifer protection. It's usually more for protection from mechanical damage at the crossings.
CHAIRMAN HALL: Okay. Well, those were my two. I wanted to get some understanding of -- basic understanding in a non-technical manner.
We'll now go back to the Technical Panel to continue technical questions.
MR. BESHORE: Thank you, Mr. Chairman.
I just had one final question, also, and it was for Mr. McCoy as well.
Nowadays, a lot of the pipeline crossings of waterways and environmentally-sensitive areas are done by directional drilling. Can your product be installed in conjunction with that type of an operation?
MR. McCOY: With difficulty. The problem is that we can't really survive too much mechanical abuse while the product is being installed. If that PVC conduit system or an equivalent, probably a tougher equivalent for a directional drilled pulled-to-crossing, if that can survive the installation process, then the sensor cable can be pulled into place after that.
But we don't have a lot of experience, and I wouldn't want to make any guarantees that that's something -- I don't think it should be a universal recommendation yet because we just don't have the experience and the track record to know that it would work.
MR. BESHORE: Okay. Thank you. Mr. Sager?
MR. SAGER: The emphasis that I have for my questions are a little bit different. I'm representing Human Performance or Human Factors.
CHAIRMAN HALL: Eric, it may be my hearing. Please speak into the microphone.
MR. SAGER: I have several questions that are going to shift the emphasis a little bit. We've alluded to operators. We've alluded to controllers. I'd like to examine them with a little more detail.
Dr. Yoon, you had mentioned that you had felt the controller was the most important element in the system, if I recall correctly.
DR. YOON: Yes.
MR. SAGER: Why did you say that?
DR. YOON: Well, first of all, operation point of view, who is responsible for overall operation, including emergency response? I think it is operator, and, secondly, leak detection system -- I'veheard many good stories about it, but there are so many, if I exaggerate a little bit, horror story, too.
Okay. So, with that kind of past record, if I were the pipeline operator, operating company, I would rely on leak detection system 100 percent. As a result, final say should be on pipeline operator.
MR. SAGER: What kinds of competencies would you associate with a high-performing controller?
DR. YOON: Okay. First of all, I understand DOT. I don't know the detail about DOT directive, but DOT ask each pipeline companies to train pipeline operator, not only in normal pipeline operations but also including procedures, company procedures, and also other abnormal aspect.
When there is a leak, what kind of things you expect from your control center or those kind of nature has to be train so that he knows something unusual things occur, then at least he can respond according to the company procedure.
MR. SAGER: If you were recommending to a company how to select controllers, what would you say that would be valuable?
DR. YOON: Okay. Okay. Selecting controller is difficult for me to say one way or the other, but on the other hand, training aspect can be addressed usingnot only training simulator that those two gentlemen already mentioned, and also a few other means, but at this time, I think a training simulator is one of the best means to address that.
But on the other hand, pipeline operators, if my -- the company that I visit sort of indication, then definitely they are not PTs or even master degree they have. So, okay, that doesn't mean that they are incapable, but on the other hand, it may take long time to train very sophisticated system.
So, as a result, what I said -- I wouldn't say insist, but on the other hand, I firmly believe that we got to walk before we run. So, at least we start with basic leak detection system, whatever the basic leak detection could be. That depends on each pipeline company's size and current system and what kind of upgrade ability, and, you know, to install leak detection, you will shut down the whole pipeline system. So, you've got to gradually build up and get experience with that.
MR. SAGER: Thank you.
For our other four panel members, I'd like to ask two questions. What do you believe should be the issues that we consider in interpreting what we have seen over and over as an inadequate response to alarmsand displays that are actually in front of our controllers? And the outcome of that is delay in responding to leaks and product loss and damage.
Mr. Stack?
MR. STACK: As I alluded to in my presentation, the key here in this situation is an operator is routinely dealing with operations of the pipeline, and these incidents are anomalies or special cases, and certainly training simulators can again help the operator practice to responses, recognize incidents which are not in his normal work day, and his ability to respond is clearly directly related to his confidence in the systems.
So, as vendors and operators, it is our duty to eliminate as best we can these false alarms, present consistent data to the operator, and train him to react to the anomalies as opposed to his normal day-to-day operations.
MR. SAGER: Mr. Rodecker?
MR. RODECKER: I would second those comments, but encapsulate them in one word "confidence".
The pipeline operator, the people that live along the pipeline, those that regulate those operations, and the vendors, such as us, have to have confidence that the alarms are meaningful.
Will there be a world without false alarms? I sincerely doubt it. Can those false alarms be minimized? I believe they can through a number of means.
But the confidence extends not just from the technical system itself and what lies behind the alarm and how to deal with that, but also with the confidence of the controller, the operator, and that confidence can be gained primarily through training and repetition.
Confidence will be instilled in the operator themselves. They'll trust their ability to recognize and react to dangerous conditions, and the management of the company and those that regulate them will have confidence that those operators know how to do the right thing, and back on your last question about what qualities a pipeline operator might have to be a good pipeline operator.
I can't really respond directly with that, but there are pipeline companies that do not allow operators to go on production, live on a control board until they've gone through a number of simulated exercises and have performed well. So, there are means to test for those qualities.
MR. SAGER: Dr. Hovey?
DR. HOVEY: Okay. I think that Mr. Rodecker really summed it up very, very well.
I think there have been some terrible accidents in recent time that are partly the result of, you know, controllers -- how do I want to put this?
I don't want to overlook, I think, the number of times that the control room operators have responded appropriately to unusual activities on the pipeline, which did not result in horrible accidents, like the ones that we've seen recently.
I think that these are somewhat unique, and in the amount of time that I've spent working in oil refineries prior to be coming part of a leak detection vending company and also working in control rooms during start-ups, I have seen operators with a great deal of competence and understanding of what goes on within their systems, and I think that good training drills and other activities that have been referenced are important, but I think that we don't want to lose the focus that many of these people out there are performing extremely well, and that the leak detection system does need to produce fewer nuisance alarms and other activities, so that there's a higher confidence there.
I guess I just -- I'm feeling like, youknow, the focus is so much on these incidences as opposed to the overview of the entire industry.
MR. SAGER: Well, we are the Safety Board and that tends to be our major interest.
Mr. McCoy?
MR. McCOY: Yeah. My comment is a little bit different. My observation of this -- I'm an electrical engineer. So, I look at this as a signal to noise problem, and essentially all of the comments that you're hearing in false alarm issues are the fact that we're trying with the SCADA technologies, whatever model or technique is used, to pull a very, very small signal out of a big noisy background, and you essentially set up a tension between the urgency to make that system as sensitive as possible, knowing that the more sensitive it is made, the more high the probability of false alarms.
So, you put the operators, the physical control room operator in a very precarious position. He doesn't want to call false alarms and shut down the line, but he's under incredible pressure to stop the line in the event of an accident.
Well, what do you do when you have a low signal to noise ratio? You can spend a lot of money. You can optimize the heck out of it, but bottom line iseventually, you get down to just where you can't find much more incremental value.
So, you look for a different signal, and that's my approach obviously. I don't look at what's going on inside the pipeline. I say when you run all you can out of that technology, find something else, and in this case, my case, it's physical presence of liquid where it shouldn't be.
It's got some limitations. It's obviously very costly, and, you know, it's not going to respond fast enough to do things that SCADA can do well, but on the other hand, it's a very clean signal. You know when something is there, and it shouldn't be there, and you can take appropriate action.
MR. SAGER: Thank you. That's all I have.
CHAIRMAN HALL: Let me interject on that again, Ms. Hovey, so you understand on this one item. One thing that is in the statute is that there is a requirement to report where there's a loss of 50 or more barrels of hazardous liquid or carbon dioxide, and while I respect the culture of companies, which is the most important thing in terms of safety, I have personally experienced, while being Chairman of this Board, many people that are in the operating room, it would appear, low-balling initial losses, and I'mconcerned about the training and the proficiency as well as the concern that each of those individuals have for our environment and their legal responsibilities as well.
So, this is -- as far as I'm concerned, is as serious -- is a serious, serious matter, and again I am concerned about the failure for any requirement in this area because while I don't want to put a bad light on those individuals who are attempting to do a good job each and every day, I also don't like to see people and companies that are trying to be proactive be put at a disadvantage in terms of operating their systems that have tremendous potential to cause -- and I guess we saw in the still-under-investigation that we saw in this Chalk Point, Maryland, accident/event, where we -- I won't get into that, but it's -- you know, it was again a situation that the Board's going to fully explore in terms of operations and reporting.
Proceed.
MR. BESHORE: Mr. Cash?
MR. CASH: Good morning. In everybody's presentation and virtually all of the answers, sensors has come up. Sensor reliability, sensor implementation, communication has come up.
In general, the software leak detectionpackages are highly dependent on sensor information from the pipeline, and your systems installed, how do people -- how are the sensors actually implemented? Is it a minimum? Is it people go above and beyond?
Mr. Stack?
MR. STACK: My comment with respect to that is during the initial engineering processes, there are certain standards and levels of instrumentation that are adopted, depending on the product and the environment that the pipeline is installed in.
But, generally, this determination is done at the engineering stages, and again many times with off-line models and simulators, they're able to verify the sensitivity of these applications in a model environment and are able to add additional devices on the line or relocate them to more effective locations for accuracy in this determination.
But, generally, it's determined by standards and practices during the engineering phases.
MR. RODECKER: I believe that's right. The selection of instrumentation is designed at the engineering stage for monitor and control of the pipeline, for moving product through the pipeline.
Unless leak detection is a part of the specification of a new installation, theinstrumentation likely would not be selected with leak detection in mind.
So, we find ourselves in a position of not retrofitting but installing leak detection on existing pipelines. We can look at the instrumentation through what we call leak sensitivity study to evaluate the performance of leak detection in advance of its actual implementation, and, further, we can look at the instruments themselves and do some cost-benefit analysis in terms of changing out existing instrumentation and making it more -- higher resolution in granularity to provide better information, and we can provide that again in advance of implementation.
MR. CASH: Again, on the instrumentation and sensors, I suppose if you put enough sensors on there, leak detection will be very easy. If you had them every several feet, it would be very easy to detect the leak.
Is there any new additions or new technology coming in sensors with new computers, new micritization of chips and sensors? Is there anything on the horizon that will make that easier to install on existing pipelines and new designs?
MR. RODECKER: I'm certainly not an expert in instrumentation technology, but it's not just thesensing of information from the pipeline that's important. It's also the communications of that information to the control center, and Mr. Stack referenced running a fiber optic cable along the pipeline, very, very fast communications of instrumentation.
But along -- I believe it's that same pipeline. My company did a study, back to your earlier comment about putting sensors at very frequent intervals. We did a study on -- I believe it was that pipeline, but a pipeline in California that ran crude oil, and the question that was posed to us is how frequent do we need to measure pressure in order to have good leak detection, and we found that it wasn't -- and this is in a published paper.
We found that it wasn't the frequency of one aspect of the data that was important, but the balance of all the data presented, and in this particular case, having pressure meters every 50 feet would not have made a difference because the fluid properties, that is, defining the behavior of the fluid in the pipeline, was inadequate relative to the sensitivity of the other instrumentation.
So, it's really a balance of all the information that's needed to drive the model.
MR. BESHORE: We have no further questions. Thank you, Mr. Chairman.
CHAIRMAN HALL: Very good. Well, we'll move up here to the non-technical staff. The first non-technical person is Member Carmody.
MS. CARMODY: Thank you. Good morning.
I just have one question. Much of what I was interested in was covered by Dr. Sager. Highly-intelligent questions, I must say, Dr. Sager.
I'm curious about false alarms. We've talked about them a bit, and the fact they're undesirable is obvious.
Do you have a false alarm rate that's acceptable or that's reasonable? Is there a percentage figure that you would accept as a reasonable false alarm rate? This is to anybody. Anybody want to respond?
DR. YOON: Yes, I will respond. When I approach operating companies, different company have different alarm procedure. So, one extreme is they don't want any alarm -- any false alarm at all.
Most of the companies realize the reality, and once or twice a month is acceptable. That's the majority of the companies, and one incidence, they have half dozen alarm, that doesn't bother them at allbecause they are used to it, and they know how to handle that.
MR. RODECKER: I'll comment a little differently. A false alarm is acceptable, so long as you act on the alarm. When you begin the process of disregarding alarms, that's when it becomes unacceptable, and that's different for every company.
I'll tell you about -- briefly about an incident that I'm aware of on one of our client companies, whereby there was an alarm, and a gentleman told me that I shut his pipe down last week, and it was a false alarm.
It was driven -- and I'll tell you why because I think it might give you insight into the sensitivity of the technology. This particular pipeline company uses drag-reducing agent injected into the pipeline to minimize friction, and when they do that, the hydraulic gradient, that is, the pressure decrease along the length of the pipeline changes, and the amount of DRA that they were injecting was different than that that was reported to the real-time model, significantly. I believe it was about a third as much as what they reported.
So, we had a difference. The alarm bells went off. They shut down the pipeline. Thehelicopters flew. He told me later it was a very good exercise that he could not have planned in advance, but on the other side of that coin, he couldn't do that every week either. So, I would say it's a case-by-case.
MS. CARMODY: Reason I was asking is it seems that a number of the accidents I've looked at, when the operator got an indication something was wrong, he didn't believe it, and he took action that was the converse of what he should have done. So, I was just trying to get a sense of what would be reasonable.
But I think, also, when you were answering Dr. Sager, you said that confidence in the system was important as well as company philosophy. I would think the company philosophy of how one responds is probably the key factor.
Is that -- I see nods. I'm not trying to put words in your mouth. It seems to me that would be the critical element, though, how you respond when you get these, what it is you do, and that is, as I understand it, that's a determination made by individual companies, not necessarily as a result of what you might recommend for your system.
MR. STACK: Yes, I agree, and the point that Alan, I think, was alluding to is clear. That companypolicy and procedure of how you deal with false alarms validate or invalidate those alarms as the process and procedure can be clearly beneficial, and some of the best operating companies that I'm aware of are dealing with two to five alarms a week. Many turn out to be false, but they have good process in place to further investigate and take some action accordingly.
MR. McCOY: If I could just add one thought to that. One of the ways that you deal with false alarms is a second source of information, and I think when we look at the records of many of the incidents where the operator was asked to make a judgment call, is this a false alarm, should I override the shut-down, should I start pumps, it's working with one source of information, whatever that SCADA control screen is telling him, and I think specifically of the Bellingham incident.
When there was a period of time when it was indecision in the control room, and the system was restarted, and that amount of time in this case, I think, was in the range of an hour, hour and 15 minutes. It would have been very valuable to that control room to have a totally independent second source of information, and I've thought about my particular product, and, you know, it's really heart-wrenching because that was a situation where if a second alarm bell had gone off and said, hey, not only did your pump shut down, but here's an independent indication that says looks like there's hydrocarbon in the soil at some location.
Chance of them restarting the pump were nil, but they only had one source of information. So, it's a -- if you could afford it, it would be very nice to have two separate independent systems. Unfortunately, it's very expensive and very hard to retrofit, and it's something to think about in the future, but certainly would be nice if we could afford it some day.
MS. CARMODY: That's a good point.
MR. RODECKER: May I clarify one thing? The false alarm in our context needs a little clarification.
The example I mentioned, it was not a false alarm. We did identify a hydraulic anomaly, and that's what the technology does. So, the technology performed just as it should. Did it alarm a leak? No. It alarmed a difference between what was reported to it and what it calculated.
MS. CARMODY: Yeah. Thank you. That's all I have.
CHAIRMAN HALL: All right. Member Black?
MR. BLACK: Thank you, sir.
I guess maybe Mr. Rodecker might be the best, but someone else is more -- is certainly welcome to answer.
The systems that are in existence, I'm sure they're of varying ages, but the large systems, the over-500-mile systems, how old are these SCADA systems now? How long have they been in existence? I see them turning up in accidents as far back as several years ago.
MR. RODECKER: I think I'd like to defer that to Mr. Stack, who represents part of that industry. So, he probably has a better handle.
MR. BLACK: Okay. Whoever.
MR. STACK: Member Black, I would suggest that traditionally the life cycle of this SCADA technology, the data acquisition technology, has been anywhere from seven to 15 years before they turn over.
More recently, with the falling costs of the hardware technology and so on, we're seeing turnover times in these technologies of five years or so.
There are, of course, operating companies there who are operating 10-year old systems, certainly that the -- but I would generally say that the roll-over now is in the five-year range.
MR. BLACK: And this is primarily hardware-based?
MR. STACK: It's primarily due to the cost of the physical technology, the hardware technology particularly has dropped so significantly.
MR. BLACK: Okay. With regard to -- again, this is to anyone who knows the answer. With regard to technology for remotely sensing, I used to have a little experience in that area back when we were using leased telephone lines, and that was not a very reliable system.
What are they using now for remote telemetry?
MR. STACK: You see the entire gamut of still telephone lines in use, UHF-VHF radio, microwave. Fiber optic, of course, is more recent technology that is going into new installations and is much easier to install and cost effective. Even satellite technology.
Of course, some of the concern we have as vendors in this market is deterministic data -- nature of the data, and traditionally satellite systems have not been so effective in helping us do our job with their non-deterministic characteristics.
But you see the whole gamut of installations, including cellular phone as well.
MR. BLACK: That's what I was about to say. There's one railroad that has been experimenting with remote-sensing of the operation of primarily railroad grade crossing signals by this carrier wave -- carrier frequency wave, cell phone technology, and they've been quite successful with it.
I was just wondering if that was being considered.
MR. STACK: It is being considered. Most I've seen have been pilot-type projects at this time. I would say it's not a mainstream technology.
MR. BLACK: This was a pilot project, also, but it was in a large geographical area, and it seemed to work very well based on what they saw.
Okay. Are these systems intended to be operational tools, in addition to just leak detectors? In other words, will they give an operator advice? I was reading through a report here where there was a complicated situation developing pump and pressure wise in a long system, and would this -- and they had a system -- I'm not going to mention the names.
They had a system. They didn't seem to be using the SCADA system to deal with the problem, and then when it detected or it was beginning to detect a leak, they ignored it.
In other words, is this something that sitsthere and waits on a leak, or is this something they would utilize as a system optimization tool? The existing SCADA systems?
MR. RODECKER: I'll go ahead and field that at least first.
Our clients use the real-time model that I described for many purposes. Some of our clients use it only for leak detection. It provides estimates of what's going on in the pipeline network, and they're very good estimates. In some cases, they're better than the data themselves.
So, oftentimes in the control room, where real-time models are -- exist, if you look at the screens that the operators use to monitor and control their pipeline, oftentimes you'll see both SCADA data, that is, data reported from the pipeline, and also underneath it or in a different color, you'll find model data.
That allows you to continue to operate based on those estimates. If there's a communications failure or if there's information that would be very costly to sense out of the pipeline -- in the gas industry, it's very expensive to put in mainline flow meters. So, many of our gas clients and clients from others in the industry use real-time models to get verygood estimates of the flow rates within their pipeline.
So, yes, they're used for many things, more so, I believe, in the gas industry than in the liquid industry.
MR. BLACK: So, the liquid industry, there would be primarily a leak detection or a system -- I guess you also get performance and volume data and that sort of thing out of it, which would be useful in billing or whatever. Okay.
MR. STACK: Yeah. Additionally, in the liquids pipelines, you see them used consistently for volumetric tracking, product tracking, if you're a batching pipeline, and so on as well.
MR. BLACK: Thank you, Mr. Chairman.
CHAIRMAN HALL: Member Hammerschmidt?
MR. HAMMERSCHMIDT: Thank you.
Well, for the record, Carol Carmody and Eric Sager have asked most of my questions jointly, but I was interested -- this is not really a question.
I was interested in Mr. McCoy's presentation when he said that a large rate of leakage, according to this slide, he said, "SCADA will find it quickly and will shut down the line in a minute or less", and it occurred to me that in the world we operate in as indicated by Mr. Sager, we don't always see thatoccurring in terms of the effectiveness of SCADA systems and their dependency on the non-automated systems, their dependency on the human factor to assimilate what is happening and then taking proper action.
MR. McCOY: I concur with your assessment. I was using a curve that was published in -- I'll allude back to one of the comments that was made very early on about maybe some vendor comments on the sales presentations are a little bit more aggressive than what actually happens in reality.
In fact, there was another set of data that I did have access to that I didn't put on there, which was much -- if you think about that curve that I showed and imagine it shifting up and to the right, that's the direction that reality pushes it.
One minute is probably the signal is recognized. The system, if it's in some sort of an automatic mode, probably can close valves and stop pumps, but obvious operational experience has that that doesn't happen too often.
The initial steps may be taken, initial indications may be recognized in that one minute. The line begins to depressurize. There's a whole other issue, and that is, if you have a major rupture, andyou're on a down slope, how much actually spills on the ground is oftentimes dependent on where the nearest check valve is, and where flow is stopped.
So, there's a lot of other issues besides just recognizing that signal. That was probably the best case situation that you saw in my presentation.
MR. HAMMERSCHMIDT: Right. Thank you for that clarification.
Concerning the questions and the issue of pipeline control room operators, I guess this question would go to Mr. Rodecker, concerning pipeline training simulators.
How many years have they existed, and how much are they being utilized or if anyone can shed light on that, please feel free.
MR. RODECKER: I'll go ahead and comment, and then I'm sure Mr. Stack can add to that because he provides those to the industry as well.
They've been out for many, many years, two decades at least. We have 26 companies now using them every day to train in and to qualify operators to perform their functions.
They're robust. They come in different levels. You can, depending upon the fidelity that you wish to achieve, on the one side of the spectrum, wewould get what I liken to a flight simulator.
An example problem, not your pipeline, not your examples, not your operations, but similar, and they're canned, that is, they're predefined, all the way to the other -- and those operate on a PC base.
On the other side of the spectrum, you get an operator sitting down in the same chair or a similar chair, looking at the control screens, whether there's one or six or eight of those control screens, operating his SCADA -- his or her SCADA system, but the numbers on there -- the displays have simulated numbers instead of actual numbers, and when they make a control move, they're actually operating a simulated pump instead of a real pump, literally cannot tell the difference.
So, they're out there in the industry. They're robust, and they're available for use.
MR. HAMMERSCHMIDT: Okay. That's a good answer. That's all I have.
CHAIRMAN HALL: Very well. During the break, I was approached by Brenton Green. He is the Manager of the Critical Infrastructure Protection Program at Sandia National Laboratories. He said their laboratory was doing quite a bit of work in this area with lasers.
Is anyone on the panel familiar with that?
DR. YOON: Yes. Four years ago, we had anInternational Pipeline Conference in Calgary, but one of the companies from Australia, they use laser and also laser technique and also fiber optic cable technology.
What they have done is they wrapped the pipeline with cable optic. Then they send laser through this fiber optic cable, and what they are looking for is two things.
One is when pipeline is pressured, then this fiber optic cable detect expansion of the pipe. That's first thing. And also, if some fluid is leaking, then it contaminate this fiber optic. So, it reflects index change, and those two technique, they try to develop, and then at that point, only prototype was available.
Since then, I haven't heard of the progress.
CHAIRMAN HALL: All right. Well, that's something we may want to inquire into and follow up on. Obviously most of Sandia -- a lot of Sandia's functions are financed by the American taxpayers, and many times out of our research laboratories, we're able to come up with some technology that can be transferred very effectively.
Let me just -- I've asked Mr. Chipkevich, to the extent I could discuss this Chalk Point, Maryland, event, but I think maybe the panel and maybe theaudience would be -- might be informative for you all to be aware with the circumstances, and these are the facts of the event that occurred, that our investigators have to deal with, and then the Board has to review and make decisions.
We have a local electric company, has a 12-inch diameter pipeline that is normally used to transport Number 6 fuel oil approximately 52 miles from a service terminal to a power-generating station, and there was a service company that was responsible for the daily operation activities of that pipeline, and in April of this year, they were flushing the pipeline with a mixture of Number 2 and Number 6 fuel oil.
During normal operations, the pipeline computer system calculates product flow data on the pipeline. However, when the pipeline is being cleaned or flushed, this monitoring system cannot be used due to the way the pipeline is designed.
The service company observed the first indication of an abnormal condition on April 7th, about 2:30 p.m., when employees heard the flow of fuel oil stop and suction problems develop at a pump at the same time.
The personnel believed at that time that these conditions indicated an operating problem or avalve misalignment instead of a potential leak. Therefore, they continued to operate the pipeline for approximately one hour at a reduced rate while evaluating the storage tank volumes.
About 3:30, the assistant terminal manager ordered the pipeline shut down when he could not account for over 3,000 barrels of product. At 6:02, an aerial inspection identified a leak, and at a point where the pipeline passed through a marsh that was adjacent to a creek, and the service company at that time, at 6:02, initiated their emergency response plan, and the oil spill clean-up contractor.
For your information, this pipeline is a 12-inch diameter steel with .203-inch nominal wall thickness. It was constructed between 1992 and 1993. Based on interviews, it was discovered that the maximum operating pressure for the pipeline is 550 psi, and the typical operating pressure's 350, and the day of the accident, the operating pressure was fluctuating between 280 and 240.
Now, if you are aware, they call their emergency clean-up folks at 6:02 p.m. on April 7th. It was 3:41 a.m. the following morning that the National Research Center notified the Board about the pipeline leak and reported it to be 2000 gallons.
The staff made phone calls to the company to try and determine the details on this spill, and we were not informed that the size of the leak was greater than 2000 gallons until 9:30, and by that time, the leaking fuel oil spread from the marsh into Swanson Creek and overnight into the Patuxent River, and eventually 125,000 gallons went into a marshland.
There was no detection equipment on this line.
Does anyone -- in terms of your commentary on this, I wanted to mention this because it appears with or without a system, a lot of it depends on the culture of a company in responding to the information that they have before them, which obviously goes to the training that is given to their personnel.
Does anyone want to comment on what type of recommendations you would make if you were government representatives, given that set of facts? Well, I won't put anybody on the spot.
Let me ask one question. You know, we had an investigation the Board did on a tragedy up in Alaska with a marine ship and a fuel oil system that got a lot of discussion on double hull ships for transport of crude oil on the oceans and waterways of our country or around the world.
Why would we not want to have double pipesystems? Mr. Stack, if you want to take a crack, I'll let everybody take a crack at that. Explain to me why the Board would not recommend double pipe systems.
MR. STACK: Certainly you would feel some resistance to the cost. Secondly, it wouldn't address our situation with our installed pipeline facilities, not from a retrofit point of view, and I think the third condition is a lot of the leaks, especially in the gasoline and fuel oil-type pipeline systems, are due to punctures from mechanical equipment, like backhoes and so on, and I think clearly even your solution suggests that it's going to have some shortcomings in that respect.
CHAIRMAN HALL: Okay. Mr. Rodecker?
MR. RODECKER: In terms of double-walled containment devices, pipes, tanks or otherwise, I think they ought to be recommended in very limited cases where there's extreme exposure.
A case that might come to mind might be something like a hydrogen sulfide or ammonia or something that -- or even LNG, liquified natural gas, where any product release or release of the fluid might be devastating.
Other than that, I'd have to agree with Mr. Stack that the cost would be certainly a huge hurdle.
CHAIRMAN HALL: Well, I guess we expended --I don't know what a double-walled pipe would cost here, but I know there was at least a million dollars that was spent on clean-up, in excess. That's the only number we have, and there was a significant environmental impact on the water supplies as well.
Dr. Yoon?
DR. YOON: Well, personally, I don't have double-walled experience. So, definitely the cost would be a big factor, but on the other hand, yesterday, one of the key topic was risk, risk and also risk mediation.
As long as we're alive, and we use this system, risk is inevitable part of it, and in order to reduce the risk and what kind of not only cost but also what kind of other aspect has to be sacrificed?
I think that is the whole thing, has to be put into more holistic -- I don't know whether that's a proper word or not -- more -- not bigger perspective, rather than this particular instance.
CHAIRMAN HALL: Well, I agree. Thank you. Dr. Hovey?
DR. HOVEY: In addition to the cost, there are some difficulties with double-walled containment, and in the State of California, the state fire marshalldoes prohibit the use of it in certain locations because in the difficulty of installing it, the outer case can be damaged, and, so, you're getting leakage through the case, but you don't know that, and you can also have a tendency towards corrosion internally on the internal pipe if some of the portions of the pipe are not installed correctly.
So, it can add problems that you don't presently have with a single-walled pipe.
CHAIRMAN HALL: Okay. And Dr. McCoy?
MR. McCOY: Not Doctor.
CHAIRMAN HALL: Mr. McCoy.
MR. McCOY: I second some of the comments just made by Dr. Hovey.
There are some very specific cathodic protection issues, particularly when you get water in the pipe. I'd also point out that this type of system is very difficult to install.
If you go to a labor haul and ask for pipe welders and say how many of you guys have welded single-walled pipe, everybody will put their hand up, and when you start asking how many of you have done double-walled pipe, and particularly mixed materials and double wall, the number of hands gets very small.
This is a very craft-sensitive technique, andI've seen a lot more problems with it than I'd want to relate.
Also, the engineering aspects of it are quite difficult in that essentially what you're creating is almost like a rack-mounted pipe inside another pipe. The soil anchors the outer pipe, but now you have a whole set of forces of expansion and contraction on the inner pipe which is resting on centralizer stands, and it's complex.
It is not something that I'd want to see in large-diameter line pipe at all.
CHAIRMAN HALL: Well, you all have very good systems and very technical systems that many of the general public might have difficulty in understanding. It's very easy for the general public to understand a pipe within a pipe, and it's those sort of simplistic solutions that sometimes get legislated when the industries do not proactively move forward to address legitimate concerns of society about their operations.
I would like to offer this panel, as I have all panels, an opportunity to pontificate as much as the Board does on any subject you'd like to, but preferably the one we've just discussed, and I'll begin with Mr. Stack.
MR. STACK: I would just like to make one comment, Mr. Chairman, about your earlier question as we resumed from the break, and that was regarding why our pipeline companies are not using this technology, and one of the things that did dawn on me, as I think Alan pointed out, there are probably two dozen or three dozen companies who are really effectively using the technologies today, but there are many more that have spent considerable dollars and made significant investments in this technology with, for various reasons, not very successful implementations.
I would suggest there's a lot of this technology that's not performing and is turned off at this time. Certainly we've made a lot of strides in perfecting the technology, but many have had frustrating times with this technology and making it cost effective, and, so, I would suggest that that's another reason why more companies are not using it.
That would be only comment at this time.
CHAIRMAN HALL: Thank you for that response. Mr. Rodecker?
MR. RODECKER: Thank you, Mr. Chairman, for the opportunity to speak on whatever subject.
Because this is the Safety Board, I'll use an analogy probably near and dear. On the road tosuccess, there's many wrecks in our industry, and they're still there, and you can point to some of them and look at the failure.
In our chief challenge in the industry is managing of expectations. The technology that we bring and others bring is not plug and play and forget. It is something that is -- takes resources and dedication to own and use.
We find in the industry community, we find a number of progressive companies, for whatever reason, that have embraced new technology, have lived with us through the bumps in the road, and come out on the other side with a level of confidence of which I spoke earlier.
In terms of recommendation to the Board and the industry, I would say that the technologies ought to be looked at individually as an appropriate application for each unique pipeline, each individual pipeline, and then, to use the technology, the existing technology more widely.
Thank you.
CHAIRMAN HALL: Thank you. Dr. Yoon?
DR. YOON: Thank you very much for the opportunity to summarize what I was thinking of in terms of leak detection.
We talked about company culture and also response procedures and various other things. Okay. In my opinion, most of the pipeline companies fill their social responsibility, also, and an operator quite often is quite busy, okay, may not be as busy as a traffic controller at the airport, but on the other hand, they are quite busy.
So, we talked about training simulator, but for anyone who went to military drill may recognize that that's a part of drill, where when you go into the war, that's a totally different situation. So, training is a small part of the whole thing.
So, at this point, company culture is definitely important things, but that's not the only one, and also operator training is important, but that's a small part of it.
So, we've got to look at the whole thing in -- from overall perspective rather than one single instances or that type of nature, okay, and once again, my philosophy is it should be practical, and these days, most of the people is comfortable with that technology.
We are not talking about building up new Saturn rocket. It's much simpler system compared to that, and we are familiar with that kind of things now,and our technology can be easily acceptable as long as they are reliable and also have their own clear responsibility to reflect what truly their technology is rather than exaggerating.
Okay. So, both sides have the clear responsibility on that, and also what I like to emphasize is go slow rather than we jump into it, and we just lost everything, then our companies could be stronger.
Okay. Thank you.
CHAIRMAN HALL: Thank you. Dr. Hovey?
DR. HOVEY: Everyone's been so eloquent, it's hard to think of something new to say.
The corporate culture issue is crucial. In the companies where the corporate culture is well focused on the environmental safety, keeping the operators well trained, and thinking through before committing to an action, those companies are the easiest to work with, and those are the ones who usually have very, very successful installations, and I think in the part of the vendors, as has been said, we need to work together with those companies, so that the expectations are realistic, and from there, maintaining the leak detection system and keeping it running is probably not that much different than keeping theprocess control systems in operation, since they also need the same brand of quality of instrumentation coming into them or the control loops don't work properly either.
So, it's a method of working together, and I agree, it needs to be done carefully and in a measured way.
CHAIRMAN HALL: Thank you very much. Mr. McCoy?
MR. McCOY: I don't have anything new to add. I'll just thank the Board for providing the forum and the opportunity to tell you a little bit about our industry.
Thank you very much.
CHAIRMAN HALL: Well, we appreciate it, and we are very aware, and myself personally, and I know all the Board Members have had the opportunity to visit many of the companies that are represented here and are represented in the industry, and many are doing a very excellent job in terms of providing proactive leadership in the safety area.
At the same time, we would like to be like the Maytag repair people and not be called to events such as the one in Chalk Point, even though we responded late because we did not have all theinformation accurately and on time.
But I think we have now run into 12:30, and to try and start the next panel does not make sense. So, instead of taking the 45-minute break, we will take a one-hour lunch break, and I will let everyone know again that there's a number of fast-food places upstairs for you to eat at in a short period of time.
Thank you.
(Whereupon, at 12:29 p.m., the hearing was recessed, to reconvene this same day, Thursday, November 16th, 2000, at 1:30 p.m.)
A F T E R N O O N S E S S I O N
1:33 p.m.
CHAIRMAN HALL: We will reconvene this hearing on Pipeline Safety, and, Mr. Chipkevich, whoever is supposed to be introducing the next panel, if you would please proceed.
MR. KRIS: Thank you, Mr. Chairman and Members of the Board.
The next panel is the Independent Systems Design Panel. On this panel is Mr. Daniel Nagala from UTSI International Corporation, and Mr. Al Senftleber from Senftleber and Associates.
Panelists, I would like to remind you that you have 15 minutes to give your presentation. The yellow light in front of you will go on when you have two minutes remaining. The red light indicates that your time is up.
Mr. Chairman, staff is ready to hear from the panelists.
CHAIRMAN HALL: Well, I'd like to welcome both of you gentlemen, and, Dan, if you would please proceed. You took the Number 1 seat there. So, --unless there is a different order the two of you all have agreed to. That's fine.
MR. NAGALA: We're okay. Is this working? Yes.
Panel: Independent System Design
MR. NAGALA: First of all, I'd like to thank Chairman Hall and the other Members and staff of the Board for allowing me to address you in this forum today.
My comments are directed to the overall state of the industry from a SCADA automation perspective and include comments pertaining to vendor capabilities, operating company expectations, and common practices for system maintenance and on-going support.
The comments I'm about to make have been compiled from my own observations and experience within the pipeline automation industry and are not targeted toward any particular automation supplier, pipeline operator, or service organization.
I will begin by offering a short summary of the evolution of SCADA systems over the past 25 years, followed by a discussion of the current state of the industry from my perspective, and, finally, I will offer some suggestions for how we might improve our approach to the design, implementation and support of such systems.
While some of my comments may appear to be critical of the industry in some aspects, they are notintended to be so and are only presented here to form a basis for the suggestions I will present at the conclusion.
In order to fully appreciate where we are today and how we got here, I would like to take everyone several years back in time. During the 10-year period between 1975 and 1985, many of the foundations for pipeline SCADA systems, as we know them today, were formed.
However, during these years, the approach to implementation of such systems was substantially different than that of today's common practice.
In the latter half of the 1970s, the typical approach to a pipeline SCADA project was to build a custom system to a rigid set of requirements, generally produced as a joint effort between the operating companies, engineering and operations departments, and in many cases, it was common to have selected a software or system supplier prior to the specification effort, making the process a combination of addressing specific operational and performance requirements in parallel with detailed software design.
The outcome of such efforts generally resulted in very detailed written descriptions of the software and hardware systems to be provided, includingdefinition of all principal data structures and software modules, sometimes to the point of detailed program flow diagrams.
While the merits of such a process can be debated, the end result was a solution specifically engineered to achieve a given set of requirements for a given target operation.
These projects, while time consuming and expensive, were generally completed successfully and provided expectation levels of functionality and performance.
In the late 1970s, the emphasis was typically on performance, reliability and operational stability, and the technology choices required to achieve the desired characteristics were typically left up to the operating companies, engineering personnel, and the system supplier.
While most companies in the SCADA business prior to 1980 had their preferred technology platforms, because of the custom nature of their business, it was typical to find most of them very receptive to the use of alternate technologies wherever it was deemed to be technically appropriate.
As the early 1980s arrived, system suppliers and operating companies began to grow weary of the costand continued maintenance and support complications associated with custom systems and began to look for solutions based on more product-oriented approaches.
Between 1982 and 1985, several companies initiated R&D projects specifically related to the design and development of SCADA products that could be configured and applied to solve multiple sets of requirements without the necessity of substantial custom development on every project.
These products were typically designed and developed for a particular hardware and operating system platform. However, most of those systems still remaining in the market today have also been forwarded to other platforms.
The era of SCADA products had arrived and was in full force after about 1985 with several vendors actively competing for turnkey projects with a standard product offering.
Moving into the 1990 time frame and coinciding with wide acceptance of personal computers and local area networks within operating companies, we began to see a notable shift in the expectations for SCADA within the business enterprise. The result being apparent to new architectures, many of which incorporated tools common to traditional businessapplications but never previously used within a SCADA environment.
Notably, the incorporation of relational database management systems or at least some level of connectivity to such systems into SCADA architectures was almost universal among principal suppliers in the market by 1993.
The driving force behind these evolving architectures was to provide better and more timely ways of moving information pertaining to the physical operations of the pipeline to management and to related departments.
Pipeline SCADA systems were no longer simply operational tools implemented and supported completely by a dedicated engineering group but an integral part of the daily business operations of the enterprise.
While all of the SCADA architecture and requirements changes were taking place in the early '90s, operating companies were also undergoing radical changes from the organizations of the '70s and '80s.
Almost every company experienced a significant loss of expertise related to their SCADA systems as a result of corporate down-sizing, reorganizations, mergers and acquisitions and so on, leaving the company with more complicated systems thanever before but with less internal expertise to keep those systems operating at peak performance.
Wide acceptance of and an almost exponentially-expanding dependence on internet-related technologies since about 1997 have further served to change the appearance and expectations of SCADA systems in the eyes of many industry professionals and promise to add yet another dimension of complication to these systems while the availability of sufficient SCADA support personnel and their relative depth still remains behind that which was common several years earlier.
This brings us to where we are today. Generally speaking, most of the systems that are in use today work pretty well, and while there are always exceptions to any given set of observations, it is apparent that these systems have substantially more demands being placed upon them than ever before, but for the most part, they have kept pace with the challenge.
Still, most of these systems continue to rely largely upon the legacy of the early 1980s R&D for their base functionality, having had little enhancement to the core functionality or its underlying software architecture since its initial implementation.
It is apparent that vendor companies have had and continue to have a difficult time meeting customer expectations while attempting to remain profitable and competitive.
In the typical project today, vendors, operators and consultants all tend to place much less emphasis upon the traditional performance, reliability and core functionality components of a system, and tend to focus more on the business and enterprise integration of such systems.
In fact, many industry professionals perceive the traditional core functionality of the early years as a commodity in today's market and take for granted that it will always be there. But this view may be incorrect and may be producing an unintentional shift of focus away from these items, so as to address other more pressing project requirements.
SCADA systems are significantly more complicated than ever before. Most of this can be attributed to the fact that the underlying system architectures rely on substantially more third party hardware and software components than their predecessors of the '70s and '80s.
This has also changed the image of the typical SCADA supplier to encompass a significantamount of complex system integration tasks for both hardware and software components.
Because of this, the skill sets found within vendor companies have also changed from that of pure programming and system engineering disciplines to include specialties in network architectures and protocols, multiple operating systems, relational database administration and management, graphic display standards and related tools, just to name a few.
The task of seamlessly putting all of these components together into a single continuously-operating environment, configuring them to satisfy a given set of customer requirements, and conducting complete and thorough system functionality testing, all under a budget set forth by a tight competitive bidding process, is nearly an impossible task.
Combine this with the fact that the pipeline SCADA market is very small in comparison to other automation markets, and therefore cannot offer sufficient financial resources to fund the necessary R&D required to keep pace with emerging industry expectations and advances in relevant technologies.
The results of all of this are systems that require functionality that is not always consistent with the core competencies of suppliers, complexsoftware development or system enhancement tasks being performed under the scope of specific projects, systems that go to the field before they are ready, and systems that generally require a significant amount of on-site debug and testing prior to being approved for on-line operation. Sometimes the on-site work alone can continue for up to a year or even more.
All of these things contribute to the potential for having overburdened and unreliable systems under certain conditions of operation.
A related example of this might be an instance where a given system is required to send critical information on a periodic or exception basis to some other system or another department or to even another company.
We have seen many implementations where the preferred architecture has moved away from the former dedicated communication path or protected network transport method in favor of techniques, such as the Internet's FTP, SMTP or other related means.
While these techniques can work reasonably well most of the time, they were never designed to operate in an environment where guaranteed performance and availability was required, and when a problem occurs, many times, it will require human interventionto correct.
Usually while such a problem is present, certain system functionality is completely unavailable to individuals and/or related applications. This is an example of an implementation to address an evolving functional requirement without a complete engineering analysis to determine the appropriate solution for the desired outcome with the requisite level of reliability.
Today, it is common to find the SCADA system falling under control of corporate information technology departments. While some of these organizations have simply absorbed the previously-existing engineering departments responsible for the companies' SCADA systems, others have inherited such responsibility because the former department or its key personnel no longer exist within the company or are unavailable for some other reason.
It is this latter case that is of concern to me. In my consulting practice, I have come across groups responsible for such systems who have little or no experience in dealing with critical real-time systems, not to mention the absence of a firm understanding of fully-redundant, no-single-point-of-failure architectures, and the importance of isolatednetworks for such systems.
This is not to say that such people are not receptive to these ideas, but the underlying concepts and their critical importance to SCADA are not part of the background typically afforded to the traditional IT professional.
Although most any SCADA system can be very reliable when configured and maintained properly, that same SCADA system can be very fragile and unreliable if operated in an environment contrary to that envisioned by the original system designers.
For this reason, it is of critical importance that such system be specified, implemented, managed and maintained by personnel who possess the appropriate skill sets and background system knowledge.
I've seen many of my colleagues from the real-time modeling and simulation disciplines here today, and it's apparent that these are areas very well represented. Therefore, I will withhold any specific comments pertaining to leak detection systems and their application, except for one particular item that relates directly to the SCADA system.
Most software-based leak detection systems operate in conjunction with the SCADA system and are completely dependent upon information from thesesystems in order to perform their primary function.
However, in many cases, among those specifying performance, there's a naive lack of under-standing of the relationship between the data acquisition and processing portion of the SCADA system and the leak detection algorithm.
Many times, we see leak detection performance requirements that exceed the limits of the SCADA system and its corresponding instrumentation. In some cases, such performance requirements are being heavily influenced by various regulatory and permitting agencies.
The point that I'm trying to make here is that no matter how much work is put into producing a highly-sensitive leak detection algorithm, the quality of that algorithm can only be as good as the data that it's given to work with. The SCADA system must be considered in any such sensitivity mandate.
Overall, I don't believe that any of the difficulties present in the SCADA arena today cannot be overcome by exercising prudent system engineering, conducting thorough system testing and implementing well-defined, on-going maintenance and training programs.
As I hope I have indicated, our majordifficulties are stemming from being too aggressive in some areas at the expense of others, namely core system functionality, run-time performance, robustness and reliability, while struggling to keep pace with rapidly-increasing demands on these systems.
All of this is taking place with a workforce that has a much different set of objectives to satisfy and very different expertise than their predecessors of the 1970s and '80s.
Please keep in mind that I'm certainly not suggesting that we fall back to the '70s and stay there, but I do believe that there are some lessons that were learned during that period that have either been lost or forgotten, and we need to recover those as we move forward into the next generation.
Therefore, as I near conclusion of my comments, I would like to offer some suggestions for change for your consideration.
There are already regulations mandating operator training and qualification, and I believe that this training and qualification should extend to the SCADA engineering, support and maintenance activities.
In particular, Subparts N and G of 49 CFR Parts 192 and 195, respectively, pertain to operator and technician training. While these regulations donot -- are not directly related to SCADA and/or leak detection systems, implications are that such training programs must include specific knowledge and interpretation skills related to these systems, along with proven capabilities to adhere to company-specified recognition and response protocols.
Full-scale training simulation, covering SCADA, leak detection and related telecommunication system operation, should be a required component for all new control center projects.
All personnel with system maintenance or operator access to the system should be required to be trained accordingly on such systems and should be subject to periodic follow-up testing.
Support personnel might also be subject to other detailed off-line training specifically related to the SCADA system and the maintenance thereof. This type of program would go a long way toward resolving the experience and technical depth issues related to personnel turnover I noted earlier and would most certainly result in better-running and more reliable control centers.
New agency regulations, although some might be helpful, can only go so far. For example, mandates that attempt to define acceptable levels of CPU idletime, RAM availability, disk and network utilization, would soon become outdated, and in order to be broad enough would most likely be so vague that the range of interpretation could end up being almost like having no targets whatsoever.
Instead of mandating such items, operating companies might be required to certify that a new SCADA system or the result of a substantial upgrade are compliant with a predefined and deterministic set of criteria, and OPS is already working on a control center audit checklist that identifies various aspects of the SCADA system and its operating characteristics.
One approach might be to extend this to the site testing and commissioning phase for any given project. Rather than involving -- having regulators involved in such processes, however, the responsibility should be placed on the operating company to have a qualified SCADA system engineer witness and approve the system's operation on its own merits before it is put into on-line operation.
The term "qualified" in this sense is in reference to the operator training and qualification rule I mentioned earlier.
Particular emphasis for such testing should be placed on the performance reliability, security andcore functionality of the SCADA system, and records pertaining to such testing should remain on file for reference and comparison use during subsequent follow-up audits.
The SCADA market worldwide is very small and as such does not have sufficient revenue-generating potential to fund substantial amounts of vendor-sponsored R&D. Still, it is apparent that we need to be able to take advantage of new technologies, and perhaps more industry-sponsored or even federally-funded R&D programs could be established.
Such programs might be tasked to evaluate and recommend how a certain technology could be applied in a typical SCADA environment while still maintaining the performance reliability and security aspects of the SCADA system.
Thank you.
CHAIRMAN HALL: Thank you very much, and, Al, we'll look forward to hearing from you.
MR. SENFTLEBER: Can you hear me? Yes.
Okay. My presentation probably isn't going to be quite as polished as Dan's. I'm going to work off the slides and react a little bit to some of the presentations that were made this morning. So, I'll probably deviate some from these slides.
Okay. Pipeline integrity is a complex subject. I think the three primary areas that we're looking at at this conference, this hearing, are looking at prevention of leaks, leak detection, and then once the leak has been detected, how to mitigate that leak.
But there are many hundreds of factors which are involved with the subject of pipeline integrity. So, what I'd like to do is maybe just review briefly some of these factors and then look at how they relate to these three specific areas, and then I do have a few recommendations that, over my years of consulting in the pipeline industry, seem appropriate.
Some of these contributing factors, as I say, there are literally hundreds of them, what I've tried to do is to summarize some of these. I've got 11 different categories that I've put these in. I won't read them down separately, but I'll walk through some slides here first just to give a flavor of what these factors are before I relate them specifically to leak detection.
The first factor here to just look at is just the pipeline configuration itself, even the location of the pipe. It's interesting. As oil companies are starting to use satellite technology, GPS, walking downtheir pipelines now to determine exactly where their pipeline is located, that they're finding that the pipeline's 20 feet away from where they thought it was.
It's interesting. So, even something as simple as where is the pipeline is a factor in the whole leak detection process. Obviously, the various placement of equipment, block valves, what the construction characteristics are of the pipeline itself, and what the condition of the pipe is, the age of the pipe.
Pipeline identification is another major factor. Identifying where that pipeline is so others know where it is, marking that right-of-way, how accurate is the information as to where the pipeline is, and what type of on-call system there is available.
Another major factor is the instrumentation and data acquisition areas. What instrumentation is on that pipeline? What is its accuracy, resolution, repeatability, and where exactly is that instrumentation placed? Is it placed in a fashion that you can do shut-in type of leak detection or is it hundreds of miles apart -- hundred miles apart?
Also, another area in this -- in data acquisition is the implementation of safety systems. Are those safety systems implemented on the SCADAsystem itself or are they down to the field? You know, there's difference in corporate philosophies on where safety systems should be placed.
I personally think it should be as close to field as possible, but there's many that differ with that opinion.
Communications, as was mentioned this morning, is a factor in that there's many different types of communication available to the SCADA systems. Also, whether that communication is redundant. You know, has your leak detection system become ineffective because you don't have redundancy? There is no back-up method.
SCADA. I've got three separate slides I put here. Again, I'm going to -- since I'm -- I just want to review these briefly. I'm just going to walk through them, but SCADA is a significant factor.
The leak detection packages that were heard from this morning, unfortunately, there is no silver bullet relative to leak detection. It is not just a matter of selecting one of those packages, and leak detection and mitigation are going to be instantaneous.
The SCADA system has a tremendous amount of bearing on the leak detection system performance, just the manner in which alarms are enunciated, whether youhave nuisance alarms, the clarity of the information that is displayed to the controllers, whether there's automatic control sequences that automatically shut the pipeline down in the event of incidents. These are all capabilities that are available on SCADA systems and should or should not be used for various reasons.
Some of the SCADA technology that's available, and, unfortunately, a lot of these are associated with the larger SCADA systems rather than the smaller SCADA system, features, such as play back, where you can take an incident and play it back through and use it for training as well as incident review.
Of course, Dan mentioned as well the design of a SCADA system is extremely important. The design -- excuse me. The design of SCADA systems that do not have single points of failures of critical components because that's exactly when your leak is going to occur.
Pipeline applications. Various levels of pipeline applications that can affect the leak detection. For example, if it's a batch pipeline, having batch tracking significantly helps with the line pack calculations, if you know where those interfaces are. Various technologies that are now available, including the hydraulic profile.
If you're in a mountainous terrain, they're needed to inform that controller when he's getting into slack conditions or into over-pressurization conditions.
Just listed some of the pipeline applications. Operating conditions also affect the --have effect on leak detection, whether it's operating in a transient mode, steady state or shut-in, whether we're talking about trunk lines versus distribution systems. Even the change in temperatures on the pipeline, whether you're coming directly out of a refinery or whether you are in a constant temperature mode.
Run through this a little faster. I'm going slower than I intended to.
Personnel. Another major factor in leak detection. Everything down to whether that controller is fatigued or not. What is the loading on that controller? How much else is he being asked to do? The number of pipelines that are involved.
Maintenance. Both field as well as the SCADA system are extremely important factors in the entire subject of leak detection.
Regulatory and corporate policy also have bearing. The API 1130 was a good step forward. It wasa document that was developed by the industry. It does not, unfortunately, define a minimum level of leak detection. It says if you do have leak detection, then this is the -- this is what you should do.
API 1161 is a step towards having people qualified to support that pipeline, another very important document.
Corporate policy, as was mentioned this morning, does have a significant bearing. As we've --in the last 13 years, we've been in and supported 22 different pipeline companies in their SCADA and leak detection applications, and there's definitely a corporate philosophy you can sense when you walk into these companies, and you start working with them, how they approach leak detection, how they approach the operation of their system.
And then, of course, money is also a very important function. It is a very competitive industry, and as Dan indicated, it's unfortunate that there are not larger vendors, and it's not -- it's extremely competitive, and there's not enough money to go around for some of the R&D that's needed.
So, looking at those factors, and how they relate to leak detection, leak prevention, leak detection and leak mitigation. Of course, right on thetop of the list is the actual monitoring and maintenance of the pipeline itself, and I believe yesterday, that was covered in great extent.
One of the items which hopefully there will be more of is -- and I'm concerned about is some of the markings on the pipelines, that we need to educate the public on what those right-of-ways mean. What are the consequences of digging in those right-of-ways, and the right-of-ways need to be marked sufficiently to make sure they're aware of what's down there.
Other areas that these factors come into play, for example, flow path analysis. Something as simple as the SCADA system telling the operator that they're about to open a pump on a closed valve, to go ahead and give them warnings.
These are features that are available in today's technology but not all SCADA systems use them. Hydraulic profiles, like I mentioned before, particularly in mountainous areas, are an important leak prevention tool for the SCADA system.
Controller training, I think, is probably the most important aspect of leak prevention, also leak detection, and associated with controller training are some of these new 1161 regulations. I believe that's going to go actually a long way towards making surethat the controllers understand the significance of their position and how to react.
Just a couple of other items on there. The SCADA system itself, the level of the performance of that SCADA system, as was shown in one of the recent incidents here in the last two years, can definitely have a bearing on the -- what the controller sees from the system.
If that system is down or cannot respond, then that controller cannot be expected to appropriately respond to the system. So, the SCADA system, and the last item there, even the making of changes to the SCADA system, need to be validated before they're brought on line.
Leak detection. Some of these factors that affect leak detection is one -- the instrumentation in the field. The old adage, garbage in, garbage out, is exactly what happens in the pipeline industry. If you don't have the end devices, do not have the resolution or not placed at proper locations, you can't expect them to find the leaks.
The levels and types of leak detection available. We went through some of them this morning. There's actually about six or seven different types. I honestly believe that no one type of leak detection issatisfactory in that I believe there's several complementary types of leak detection that need to be put on these systems.
We mentioned the area of confidence of the controllers. We need to provide multiple methods of leak detection to complement each other, so that when there are leaks, then that controller's not dependent on one specific technology.
The SCADA system, even without the leak detection packages, things as simple as rate-of-change alarms and deviations, it's amazing how many pipelines out there do not have even the simple capabilities implemented.
We get down to the proper tuning and maintenance of pipelines. That's actually one of the major problems with some of the application packages. Many companies over the years have spent many millions of dollars trying to implement leak detection packages just to turn it off.
It's a technology, particularly the transient technology, requires a tremendous amount of maintenance, and that's one area where, if the industry works on it all, it needs to work on the ease of maintenance of these packages because eventually they're not used or they're detuned to the point thatthey're not useful.
That bottom item, reduction of leak detection, again is an extremely important point. Depending on the size of the pipeline, you'll have --some pipeline companies will monitor 25-30 pipelines by a single controller.
So, the level of distraction, number of phone calls they get, the number of alarms which are on the screens, definitely impact their effectiveness in leak detection.
Just the maintenance of the back-up systems and even the physical condition of the controllers, whether they come in fatigued, how many hours they're asked to work, how many hours they have off.
We're running out of time here. So, I'm going to move a little faster.
Leak mitigation. Some of the factors that get into leak mitigation is these pipeline applications need to not only tell you that there's a leak, but they need to tell you what the size of that leak is and what -- where that leak is.
Then based on that, there's certainly work that can be done to automate next two items. One is, is the rapid identification of people that need to be identified based on a leak happening on a certainplace. The popping up of the specific share of the people who's on that right-of-way to identify. Also identifying immediately what's the closest block valves or what can be shut down are areas that there could be improvements in the SCADA systems.
Automatic control sequences to help the controller. I'm not an advocate of automatically shutting down pipelines that can cause more problems, but having the human intervention and having tools available which will automatically shut down certain sequences of the pipeline on the -- at the controller's initiation, and then some of the spacing on the block valves, going towards automated block valves at all points.
Okay. In summary, I do have -- I've got several more slides, some recommendations, but I do believe there is some minimal levels of standards that could be established on the SCADA systems, on the leak detections, that would be of assistance, that would not be a burden to the industry but would provide consistency across the industry.
Also believe there needs to be -- because of the costs of some of the technology, the development, some means of having some incentives, some R&D funds made available.
Also believe that these regulations should be implemented over an extended period of time. It takes quite a bit of time and effort to go back and retrofit equipment in the field and update data acquisition equipment, for example, to get higher resolution, and I believe that there should be penalties for those that don't comply, and they should get more severe as time goes on.
Thank you.
CHAIRMAN HALL: Well, thank you, and maybe we'll get -- appreciate you providing us a copy of your slides up here, and I have been noting your recommendations and your minimums. Maybe we'll get into that in a little more in the questioning.
Who's lead hitter here? Mr. Beshore.
MR. BESHORE: Thank you, Mr. Chairman.
Mr. Senftleber, I know you touched on this in your presentation, but if you could go into a little bit more detail on what pipeline system considerations and operating characteristics cause the biggest challenges for effectively detecting leaks utilizing these CPM methodologies, and would they be the same for natural gas and hazardous liquid pipeline applications?
MR. SENFTLEBER: I'm not sure I totally understood the question. Could you repeat that again?
MR. BESHORE: Well, what operating conditions cause the most difficulty and the most challenges -- MR. SENFTLEBER: Oh, operating conditions as -- on -- operating on the pipeline?
MR. BESHORE: Correct.
MR. SENFTLEBER: Okay.
MR. BESHORE: What physical characteristics of the pipeline system. For example, you mentioned mountainous terrains.
MR. SENFTLEBER: Correct. Obviously it's easier to do leak detection, for example, in the Gulf Coast where it's flat, non-mountainous, particularly if you're dealing with a homogeneous product, and there's few transients. There's not a lot of injections into it or deliveries.
You come in one end, go out the other. It's probably the simplest pipeline configuration.
Things in terms of adding complexity to that is the turning on of pumps, the additions of the DRAs, the batching of the pipeline. Is it batched where all those interfaces? You get into the situations where you get into the mountainous terrains, and you worry about then clearing those hills, slack conditions as well as over-pressurization.
The technology is there to put up hydraulicprofiles up on the screens and highlight, you know, when you have exceeded maximum operating pressures, even if it's between sensors on the pipeline.
So, I guess just in summary, the flatter, non-turbulent single product are definitely the easier pipelines to operate. You get into situations where you have many deliveries in urban areas, you know. You saw it increasing the complexity.
MR. BESHORE: Thank you. Mr. Nagala, do you have anything to add on that?
MR. NAGALA: Not too much. Just one last point about conditions of operation and specifically related to mountainous terrain.
One of the things that happens in mountainous terrain is when the pipeline's going up the hill, it requires a tremendous amount of head pressure to overcome that elevation change.
When it goes down the other side, gravity takes over, and probably in just about every pipeline that I know of, there may be some exceptions to it, but most of them go into a condition called "slack like flow", where you actually have bubbles or air pockets that develop in the line as a result of that downward change in the pipeline right-of-way.
Those conditions -- most of the modelingtechnologies for leak detection that are in use today rely on a columnar flow situation, where everything is packed, and the pressure waves can move through the fluid, so that they can detect the leaks.
When it's in a slack line condition, and you have these air pockets or bubbles in the fluid, the effects of that wave propagation are severely affected. It makes it very difficult to be accurate and to even recognize the leaking condition in some of those situations.
MR. BESHORE: Thank you. Now, can these systems be utilized to prompt the controller with suggested courses of action based on historical data or on similar operating characteristics, and are they capable of being programmed to seek a verification, for example, of a controller's command, if the system interprets those commands as potentially being inappropriate to a given condition?
MR. SENFTLEBER: There are. Yeah. There's several technologies that are available, and, of course, they're not used universally at all.
But as I mentioned, there's a flow path verification that can be used to verify that when you turn on a pump, that you do have a path to some outlet.
The same thing. This isn't leak detection,but even contamination is one of the things that drive the industry. You don't want to contaminate that tank because the pipeline company picks up the expense then, to go ahead and warn the controller, you're about to open a valve that's going to put a product, a non-compatible product, into a tank.
So, it doesn't -- it kind of says -- you're saying I want to do this. The system comes back then and will tell them that this is the consequence of what you're going to do.
In terms of giving him suggestions, one of the things that are happening is companies are starting to put their operating instructions on line, so that if you want to start this pump, and the controller should already know how to do it before he's sitting there by himself anyway, but to be able to call up the operating instructions directly on the system as to this is the sequence for bringing up this pipeline.
MR. BESHORE: Did you have anything else to add?
MR. NAGALA: No, no.
MR. BESHORE: Thank you. I have no further questions.
Dr. Jenner?
DR. JENNER: Yes, thank you, and goodafternoon.
In the last two days, we heard of some pipeline accidents where there was a delay in the controller initially recognizing or responding to alarms that there was a spill.
Based on your experience with tardy responses to spills by controllers, do you think the errors were made due to human errors, perhaps due to improper or inadequate selection, training or excessive workload, or perhaps due to technology errors, such as limitations of the SCADA system, or inadequate manner in which the information was displayed, or perhaps a combination of the two?
MR. SENFTLEBER: I think -- I'm not specifically familiar with the background behind these incidents. So, it's hard to say.
Actually, every one of those items that you listed could potentially be at fault. Over the years, I also have been acquainted with controllers restarting pumps. They don't believe the data that they've seen on their own systems or I've seen them get so busy in terms of responding to phone calls, shippers calling, wanting to know where their batches are and stuff like that, and they're not watching the screen close enough.
So, you can have delays in response time there.
Not knowing the specific systems that are involved here, it very well could be a matter of density of data on the screens, you know, how easy it is for that controller to see that data. Is that the alarms that may have been enunciated? Are they of a different level of importance, you know, than an alarm which says the printer's out of paper?
There's a lot of things that could affect the controller's response.
DR. JENNER: Do you want to add anything else?
MR. NAGALA: If I might, I'd like to add just a little bit to that.
One thing in particular when these controllers are sitting in front of a console eight or 12 hours a day, and the systems undergo various different operating conditions during the tenure of any given controller, and in some cases, though in fact it's probably a bigger problem than everyone admits, but nuisance alarms.
Alarms that occur as a result of typical and standard operations on the pipeline, that for whatever reason are not filtered out by the SCADA system or are not filtered out by the leak detection algorithm or whatever.
When these things occur, and the operators see them day after day after day, they tend to get desensitized to certain kinds of alarms. It's not to say that in some cases, those alarms are meaningful and should be acted upon, but I think when you combine the fatigue, familiarity with the system, and maybe some of these desensitization, things tend to get missed, and they tend not to believe them when they see them until they are seeing them repetitively.
I think that, you know, one of the things that probably should be worked on are more techniques and more software-based solutions to help filter and prioritize alarms.
Some companies do this. Some of them do it very effectively. Others don't, and it's just part of the way that they've chose to operate their lines, but in general, in SCADA and leak detection systems, if you start filtering out alarms and leak detection systems, the question is what are you doing to the sensitivity of the algorithm?
Generally, a higher -- a much -- an algorithm with a much higher level of sensitivity is probably going to produce more false alarms. If you raise that sensitivity up, then you're not going to catch a small leak, but you filter out some of those nuisance alarms.
The same with SCADA. Sometimes those alarms are set because they've made thresholds pretty tight, but the operator knows, well, if I do this particular operation, then that alarm's going to happen and that's okay.
The problem occurs when that alarm happens, and it's really representative of that last operation that he did. So, that's it.
DR. JENNER: Thank you. That's all the questions I have.
MR. BESHORE: Thank you, Mr. Chairman. We have no further questions.
CHAIRMAN HALL: Member Carmody?
MS. CARMODY: No questions.
CHAIRMAN HALL: Member Black?
MR. BLACK: No questions.
CHAIRMAN HALL: Member Hammerschmidt?
MR. HAMMERSCHMIDT: No questions.
CHAIRMAN HALL: Well, this has been an excellent panel, and, gentlemen, we're going to have to move it on, because we're getting so on in the day here.
I want to really note these recommendations you've made. I mean, those are basic simple things that we -- the Board's been recommending now for almost15 years, and obviously the frequency of pipeline examination by smart pig or other acceptable method.
How often do you think that should be done for a safe system? You all have opinions?
MR. NAGALA: Really, I'm not an expert in physical inspection techniques, and, so, I don't believe that I'm a good reference for that.
MR. SENFTLEBER: Yeah. I guess that's not my specific area of expertise as well because I'm on the control system side, but it is -- I would feel that it would be relative to the age of the pipeline and what the experience has been with those pipelines.
CHAIRMAN HALL: Well, anyway, your minimum standards and your recommendations and both of your presentations are appreciated, and I'll offer you as we have the previous panels, if there are any closing comments that you would like to provide for the record, that you think we should consider, we would certainly appreciate it, and I'll start with Dan.
MR. NAGALA: I'd just like to restate that SCADA is a unique component in today's IT networks, and it really has to be continued to be treated as an important and critical component in those networks.
System management personnel must be qualified to deal with the specific nature of these systems, andthey must be trained to work within a set of predefined procedures and processes for managing the day-to-day activities.
When defining and executing projects, I think that customers and vendors and consultants alike all need to be more realistic about project expectations and not to lose sight of the performance and the reliability and core functionality aspects of all of these systems.
Thanks.
CHAIRMAN HALL: Thank you very much.
MR. SENFTLEBER: The only parting comments I'd like to make is just to reiterate that pipeline integrity is a complex subject, and the point I was trying to make earlier with going through some of these factors is that all of those areas have an impact on preventing and locating and then mitigation of leaks.
As I indicated, I don't think any particular leak detection technology is going to solve everybody's problems, but I think we need to look across all of the different factors and see what incremental improvement can be made, and what minimum level of standards could be established in the industry in those different areas.
Again, I'd like to also thank everybody forallowing me to talk here today.
CHAIRMAN HALL: Well, I thought this was an outstanding list of contributing factors. I think I would have put many first rather than last, but other than that, I think you pretty well covered all the important factors.
We thank you both of you gentlemen, and we will do a quick stand-up while we call our next individual witness.
(Pause)
CHAIRMAN HALL: All right. Let's introduce then our next witness.
MR. KRIS: Thank you, Mr. Chairman and Members of the Board.
On the next panel is Mr. Byron Coy, an engineer from the Office of Pipeline Safety, Eastern Region.
Mr. Chairman, the staff is ready to hear from Mr. Coy.
CHAIRMAN HALL: Well, Mr. Coy, welcome, and we appreciate your public service and note that you are paid by the taxpayers just like we are, and, so, we're very interested in hearing from you.
Please proceed.
We at the Office of Pipeline Safety thank you, Chairman Hall, for the opportunity to speak to the Board and the audience about this very important topic.
I'm going to talk about leak detection methodologies for hazardous liquid pipelines. Leak detection can be achieved both outside the pipe and inside the pipe.
Externally, there are systems that run on the perimeter of the pipe, like vapor sensors we heard earlier, and alarm cables that will be damaged if the backhoe's in the area, and acoustic technology.
Internally, pipeline companies can apply any number of means. They can examine the threshold monitoring for pressure and flow deviations. Several forms of line and volume balance, various forms of modeling, as well as pressure wave and statistical analysis.
Now, I'm going to be focusing on internal technology to identify some up-second conditions prior to the occasions of leaks or line breaks as well as to identify leaks and ruptures after the event.
Pipelines have been using computer technology since the early '60s, and they do that to collect and analyze operating data on a more timely basis than perhaps doing it manually as done in the past.
This allows them to broaden their view of on-going operations, and it also provides a means for them to make their organizations more efficient. As a result, there have been benefits received in the form of safety and for their own economics.
Hazardous liquid pipeline operators still principally design basic safety devices in the pump station to protect against station equipment malfunctions, and that results in protection from over-pressure on nearby pipeline segments.
SCADA and leak detection technology is used to achieve system-wide views, not visible from the purview of individual pump station control panel, as was done before the arrival of SCADA technology.
Fundamental systems that were installed in the '60s typically had useful lives of nearly 20 years, but the pace of technology advancement has caused some systems that were installed even in the '90s to be considered mature.
Computer systems employed in many large pipeline control centers are very sophisticated, yet there are many small pipelines across the country that are virtually operated by hand.
The pace of computer technology improvements will continue, but it's important that we applytargeted training in conjunction with these improvements.
The replacement costs for these systems will surely differentiate one company from another, and the threat of cyber terrorism may influence pipeline regulations and the content of OPS safety oversight.
Now, pipeline monitoring and control starts first with the controller, and we heard that earlier. The controllers may be using various forms of SCADA systems for primary monitoring and control, and beyond SCADA, many folks have operation support systems.
To the degree each of these is employed, all can be key resources to help maintain pipeline integrity. The controller may be an individual or a team. He might be on-site or at a distant control center.
These folks are primarily responsible for safe pipeline operation. They use an assortment of tools ranging perhaps from a pressure gauge and a valve wheel to a multi-screen display panel and a computer mouse. They are truly in the hot seat for pipeline monitoring and control.
Now, I mentioned SCADA earlier. SCADA, although we're all very familiar now, employs the use of computers and communication networks to gather fielddata from numerous remote locations.
This data then is structured and presented to the controllers to give them information to allow them to perform their job. SCADA systems take this information to create some numerical analysis, create trends and summary reports to assist in the operation of the pipeline.
Controllers then can consequently send commands back to the field to engage changes that are necessary for their operation and the continued safe operation of the system.
Beyond regular SCADA systems, most folks I mentioned employ operation support. These may consist of the ability to enhance the controller's monitoring and forecasting the need and timing of commanded changes. They may help detect possible operating anomalies that deserve special attention. They can perform complex analysis on data more quickly that are not practical for controllers to perform by hand.
They can also provide various forms of modeling and simulation, and as a part of that, we mentioned computational pipeline monitoring.
The regulations in Part 195 do not specifically reference the term "SCADA" nor do they require the use of computer-oriented solutions. Butthe regulations do require a communication system for the transmission of information.
They require systems that include means to monitor operational data, and they require the ability to control receipt and delivery, detecting abnormal conditions by monitoring pressure, temperature flow, and transmitting this data to an intended location.
Pipeline operators must decide the degree of computerization for their pipeline. Now, many pipeline operators choose to comply with 195 by implementing SCADA systems, and by the nature of their use, SCADA systems usually come under the scrutiny of pipeline inspectors.
More specifically in reference to leak detection, 195 does not currently require the application of computational pipeline monitoring, but it does require that those who design or renovate CPM system that they currently have adopt those principles that are contained in API 1130, and, by the way, the recently-published Pipeline Integrity Management Final Rule addresses the leak detection capability.
The API 1130, I mentioned, is a comprehensive document that was developed through API to advance safety by providing for more rapid detection of ruptures and response to those ruptures, whichultimately limits the release of hazardous liquids.
It describes seven techniques to detect failures using internal data collection and analysis, and, by the way, the inclusion of API 1130 became a rule July 6th of last year.
We heard earlier about performance expectations. Part 195 nor 1130 do not reference specific SCADA or CPM performance expectations, but 195 does expect pipeline operators to prudently apply and operate the equipment they choose in order to maintain safety.
Now, many pipeline operators have implemented very sophisticated SCADA and operation support systems. They enhance their ability to identify and track upset conditions. It allows them to perhaps take preemptive measures to avert leaks. It helps them recognize possible leak situations and perhaps even speed their reaction to emergency conditions.
Because of the data integration across these systems, it's sometimes hard to distinguish between SCADA and operation support. We're all challenged to find the leak detection solution. The scale and diversity of pipeline operations impact the scope of applied computer resources.
Topology, pipe properties and operatinghydraulics impact the nature and performance of models and CPM systems. All these variables make it difficult to identify the right approach.
Each pipeline operator must find the right mix of human intervention and technology tools that best suits their pipeline. The value obtained from SCADA and CPM systems is directly proportional to the amount of effort applied to their design, engineering, controller staff, and support.
These systems need to have a well-thought-out design that ensures that the controller's not over-burdened with hand calculations in support of these systems. They must also have the ability to filter critical information to the controller amongst the mass of information that's available.
They must also offer some technique to minimize the occurrence of excessive or unwarranted alarms, so that the controllers are not distracted inappropriately, and for all this to happen, the support staff must have sufficient resources to look after these systems.
Ultimately, the controllers have to have confidence in the value of this applied technology or they'll not take advantage of its capabilities.
A managed approach must be applied to acertain technology that provides real value. Technology makes it easy to increase the imposed workload and weight of responsibilities on pipeline controllers, and as a result, the operator qualification rule becomes even more valuable, and it will require that the controllers are equipped with the necessary skills.
By the way, the OQ rule programs must be in place this coming April, and qualifications must be complete in October of 2002.
Careful consideration must be applied to CPM procedures on the occasions whenever alarms are generated, when there may be a partial data failure. Controllers must be able to know how to handle systems that present conflicting information as well as whenever possible leaks are declared and even whenever there's an apparent system failure.
Controllers must know and understand what their authority is to shut down the pipeline, and impromptu shutdowns that are done inappropriately might in fact create upset conditions that could lead to pipeline failures, an ironic situation.
I'd like to sum up by mentioning a few accidents that I hope you can relate to in some of my earlier comments.
In 1987, a controller kept thinking hourly shorts would eventually turn around, and in so by delaying response, the spill was aggravated.
In 1990, a controller dismissed a real alarm as another nuisance from an ailing system, again aggravating the spill.
In '92, SCADA displays may have lacked sufficient information, inhibiting the controller's ability to grasp the situation.
In '96, a controller incorrectly interpreted SCADA information, aggravating the spill volume.
Again in '96, SCADA screens portrayed field instruments incorrectly, which may have misled the controller.
In '99, a SCADA system without adequate capacity may have inhibited the controller's reaction to an upset condition.
This year, perhaps the limited use of instrumentation temporary to cloak the leak from discovery, and the routine process of balancing tank volumes after the delivery delayed the discovery of a leak.
In summary, the unique characteristics and the physical aspects and operation of each pipeline need to be considered in designing a leak detectionsystem.
The design, application and support of such systems can be complex, which can have a direct impact on their performance. Efforts should continue to be applied and other operation support tools where the timely diagnosis and recovery from abnormal situations may avert the onset of some leaks and ruptures.
I'll conclude by noting that a well-trained and vigilant controller will always play a critical role in leak avoidance and leak detection. Even in light of the advances in technology and improving leak detection performance, very small leaks will remain very difficult to detect.
However, forums like this will surely help to promote pipeline safety through advances in computer technology and leak detection systems.
We at the Office of Pipeline Safety appreciated the opportunity to be here, and for those that are interested, there's a web page and phone number to call if you want to talk about leak detection from our perspective.
Thank you.
CHAIRMAN HALL: Thank you very much, Mr. Coy, and we'll move now to the Technical Panel for questions.
MR. BESHORE: Thank you, Mr. Chairman. I have no questions.
Dr. Weeks?
DR. WEEKS: Yes, thank you. I have one question.
Good afternoon, Mr. Coy. You had mentioned that the systems need to have a well-thought-out design to ensure operators' confidence in the value of the technology, and that's a theme that we've heard a number of times today, both confidence, and corollary, the lack of confidence.
In your view, what are some of the factors that have contributed to this lack of confidence, and what can we do to restore or build the confidence in the technology?
MR. COY: Well, in my opinion, perhaps these systems may have been put on line and expected to perform at an inordinate performance level where it may take time for those systems to be tuned and come up to speed.
Asking them to perform notably will ultimately cause false alarms which creates a bad environment to start with. So, a moderated approach and a structured development perhaps will allow sensitivity to increase over time without goingoverboard.
DR. WEEKS: Thank you.
MR. BESHORE: Mr. Cash?
MR. CASH: I just have one question. Are there any minimum performance standards or design standards that the SCADA system must meet before it's considered an operational system?
MR. COY: Pipeline operating companies normally develop a set of specifications when they're considering the adoption of a new system.
Those expectations, I believe, are developed internally based on their own requirements of those systems. I'm not aware of any universal standards at this point that people ordinarily look to.
MR. CASH: There's no regulatory requirement? It's strictly all customer-driven?
MR. COY: To my knowledge.
MR. CASH: Okay. Thank you.
MR. BESHORE: We have no further questions. Thank you, Mr. Chairman.
CHAIRMAN HALL: Okay. Member Carmody?
MS. CARMODY: No questions.
CHAIRMAN HALL: Member Black?
MR. BLACK: No questions.
CHAIRMAN HALL: Member Hammerschmidt?
MR. HAMMERSCHMIDT: One minor question, following up on Mr. Cash's last question.
From your presentation, where you cited the Code of Federal Regulations, the CFR, is SCADA even referenced in the CFR?
MR. COY: The word "SCADA" does not appear in the 195 Code, but there are specific references to tasks and functions where many operators employ SCADA systems to comply.
MR. HAMMERSCHMIDT: Exactly. I just wanted to reconfirm that. Thank you.
CHAIRMAN HALL: Yeah. Can't go out of turn, George. Go ahead.
MR. BLACK: Hurt my feelings. I won't do it.
Mr. Coy, just sort of a quick question. There is, as I understand it, no certification requirement of your agency for controllers of pipelines.
In other words, there are only the company requirements for training, and whatever they require for certification, hours of service, things of that nature.
MR. COY: The adoption of operator qualification rule will bring us more -- bring more to the forefront, the need for qualifications, and we'llbe using that as a vehicle to better measure the performance of controllers.
MR. BLACK: But you don't issue a license to them of any sort?
MR. COY: No.
MR. BLACK: You don't intend -- well, I don't know what you intend to do, and I don't know if you know that at this point.
I can't help but draw the parallel to virtually every other transportation mode, where this is sort of an underground railroad, and the controller's sort of the locomotive engineer, and we make some requirements about locomotive engineers and hours in service and things of that nature, and this is sort of -- the mode sort of stands out in that way because the track is private, and the locomotives are privately owned.
It's a little hard to understand how we have not looked at that more in the past. I'm against regulations like everyone else, but it does seem that we are -- that this mode has been sort of unaddressed compared to the others that we deal with on a routine basis.
MR. COY: If you'll excuse my indulgence, most of the pipelines are underground.
MR. BLACK: I understand that, but they still leak above ground and cause just as much trouble as a hazardous material spill from a railroad, which might be on private railroad right-of-way, but it is still the -- just sort of a parallel.
Thank you.
CHAIRMAN HALL: Mr. Coy, as an inspector, are you provided with guidelines on how to evaluate an operator's leak detection system to ensure its compliance with the regulations?
MR. COY: There has been recent work being conducted as a result of the incorporation of API 1130, and I believe there's continued work being applied in the department to make that information more available to inspectors in general.
CHAIRMAN HALL: How long have we had some sort of leak detection or SCADA systems?
MR. COY: You mean in operation in the industry?
CHAIRMAN HALL: Yes. Historically.
MR. COY: In the early '60s, I believe most of the systems made their first appearances.
CHAIRMAN HALL: And this is not a -- this comment is certainly not aimed at you, but to think that we've had this technology for this long, and wehave inspectors that are out there, and we do not have any guidelines for them on how to evaluate the system gives an idea basically of where we are.
Are your inspectors in general sufficiently well versed in these leak detection technologies or is additional training necessary for them to be able to evaluate these systems?
MR. COY: We have a fairly elaborate training program which is mostly instituted with Transportation Safety Institute in Oklahoma City, which you're aware of.
CHAIRMAN HALL: Right.
MR. COY: We're always striving to continue to apply training and find topic areas where additional training is required. I'm not really prepared to address what our future training plans are. That's not in my arena.
CHAIRMAN HALL: I guess my question was, do you think that most of your inspectors that report to you are well versed enough now to perform their functions?
MR. COY: I guess that's pretty hard --that's hard for me to say. I believe that we do an adequate job, but the adoption of more advanced technology, as we've heard about the last few days,will require us to become even more aware of how this technology is applied and to make sure that it's applied appropriately.
CHAIRMAN HALL: Okay. Well, as an inspector -- how long, sir, have you been an inspector with this office?
MR. COY: Just over five years.
CHAIRMAN HALL: Okay. And, well, congratulations on your public service. Thank you.
What additional actions, guidance or assistance would be helpful to you in ensuring the compliance of these leak detection systems?
MR. COY: My personal opinion is that the adoption of API 1130 last year and operator qualification and continued rules development in the area of applied technology will surely advance our ability and industry's ability to adopt better safety practices in regard to leak detection.
CHAIRMAN HALL: All right. Well, Mr. Coy, I am tempted to ask you more questions, but to be honest with you, we've got one more panel to complete, and we have, I think, four or five individuals with presentations that I want to -- that I want to be sure there's sufficient time for all of us to hear from.
But I certainly want to give you theopportunity individually to express any opinions you would like or you think would be helpful to the Board as part of this hearing transcript.
MR. COY: Well, OPS takes leak detection very seriously, and we would encourage industry to continue to work towards improvements in leak detection technology, and the department, through our research funding and other techniques, will work with industry and others to help advance technology in that regard.
Thank you.
CHAIRMAN HALL: All right. Well, thank you, and what -- your office is here, sir, or --
MR. COY: I operate in the Eastern Region, but my office is in New Jersey.
CHAIRMAN HALL: In New Jersey. Well, good. How many folks do you have in your office there?
MR. COY: There is one other inspector in the same office as I.
CHAIRMAN HALL: So, there are two of you?
MR. COY: Right.
CHAIRMAN HALL: And how large a region do you cover?
MR. COY: Well, the two of us are a part of the Eastern Region. There are other inspectors based in Washington --
CHAIRMAN HALL: Okay.
MR. COY: -- and other field offices.
CHAIRMAN HALL: Very well. Well, we -- you are excused, and I guess this would be an appropriate time to take a break before the last panel, and we will come back then at 3:15 and hear from our last panel and try to close this up by around 5:00 for everybody.
(Recess)
CHAIRMAN HALL: I'll call this meeting to order and ask Mr. Kris if he'll introduce the next panel.
MR. KRIS: Thank you, Mr. Chairman.
Our final panel of the day and of the hearing is the Pipeline Operators Panel. On this panel is Mr. Bob Darwin, who is a Member of the American Petroleum Institute's Cybernetics Subcommittee.
Also on this panel is Mr. Ed Nicholas and Ms. Valencia Hiebert from Alyeska Pipeline Service Company. Also on this panel is Mr. Mike Huber and Mr. Peter Evans from Marathon Ashland Pipe Line.
Panelists, I would like to remind you that you have 15 minutes to give your presentation. The yellow light in front of you will go on when you have two minutes remaining. The red light indicates that your time is up.
Mr. Chairman, staff is ready to hear from the panelists.
CHAIRMAN HALL: Well, I'd very much like to welcome the panel. I will use my prerogative to tell a brief, brief story about Alyeska.
When you get appointed to one of these positions, you don't automatically go in. You have to go through this agonizing process called "confirmation", and during my confirmation hearings, Senator Stevens is on one of our committees from Alaska, very well respected, a wonderful American.
Senator Stevens asked me if I had ever flown the approach into Juneau, and I said, "Well, no, Senator, I have not ever flown the approach into Juneau", and then he said, "Well, you know, after you do that, you probably want to go up and look at the pipeline."
So, one of the first trips I made after I got confirmed to this Board was to go up and have the opportunity to visit Alyeska, to look at Valdez, to look at the marine aspect as well as the pipeline aspect, and then ended my trip by taking and flying into Juneau.
So, I'm real pleased that so many folks are here from the Joint Pipeline Office in Alaska, and Igreatly appreciated all the courtesies that were extended to me during my visit up there.
I guess, Mr. Darwin, we will let you lead off here, sir. You took the Number 1 seat there, and we'll look forward to hearing from you, and we certainly welcome you and your expertise, and I had a relative of mine, my brother, that used to be very active in the API, and I have a great deal of respect for the organization.
So, welcome.
MR. DARWIN: Thank you, Chairman Hall. Good afternoon.
My name is Bob Darwin. I've worked in the pipeline industry for about 35 years, and for the past 12 years have been an active member of the Cybernetics Committee of the API. This is a subcommittee of the Pipeline Committee.
Among many functions that the Cybernetics Subcommittee has is to advise the member companies on pipeline control and data acquisition systems, SCADA systems, and the related technologies that go with that, and to alert them about new technologies that improve pipeline operations.
Another thing that we do is we develop,review and maintain API documents. This is a group that works around areas in which we feel are not competitive in nature, and hence we end up with some very open dialogue, and this has led to several API published documents that have been mentioned in some of the previous presentations.
One is API 1149. This is the one that deals with the uncertainties of various elements of the pipeline and how it affects leak detectability.
API 1155, which is a defined methodology for evaluating leak detection systems against your particular pipeline, and API 1130, that's been mentioned frequently, which is a complete look at computational pipeline monitoring.
Our topic today is really leak detection and response, but in ways that several have already discussed it, I think that detection and response can't be taken in isolation. We have to take it in an overall concept which I will call pipeline integrity. That word was used in a slightly different context yesterday, but let me explain.
Pipeline integrity, from my viewpoint, includes prevention. It includes detection, and it includes response. A prudent pipeline operator is interested in the successful movement of product fromPoint A to Point B, moving it safely and moving it in its entirety, and you do that through these various aspects.
Prevention is all those things that you do that keeps the commodity safely in the pipeline, and this includes -- really begins with engineering design. It includes how you maintain your system, and many of the things that were discussed yesterday are part of that, and it also includes how you operate the pipeline.
The second is detection, and in this particular case, you're dealing with activities which are predicated on a quick and a reliable detection of a release from a pipeline.
I would say that detection is not a process -- pardon me -- it is a process. It is not a single activity. It is not a single system, but it is a process, and that it includes very many things.
It includes air patrol of pipeline and includes damage prevention systems. It includes control room operation, and it includes the CPM systems that we've heard discussed and described.
These tools operate in very different realms. Some are long-term, some are medium-term, some are short-term. You may deal from minute to minute, hourto hour, or even day to day.
The last of these, response, includes all that's done to minimize the impact of a release. It begins with initially reacting to the situation, shutting a pipeline system down appropriately. That includes dropping off units that may be active. It includes opening or closing valves in the appropriate positions, and then deploying the emergency response capability.
Releases in pipelines are really infrequent occurrences, and oftentimes we see this concept of pipeline integrity made up of prevention, detection and response being kind of equal aspects of it. All that changes in the event, either within a company or within the industry, when a major release takes place, and all of a sudden, detection becomes almost over-powering.
But I would submit that in fact, taken in its proper perspective, detection is a small, although very, very important, aspect of the overall integrity of the pipeline.
So, let me move on to detection and response. I certainly believe that's the focus of our attention today, and that what you'd like to hear is what are the current industry capabilities in this area.
All of this is built around SCADA systems. You've heard those described in great detail. So, I'll not go into that. We know that today, there's no absolute requirement that a company have SCADA systems, but in my observation, there are no companies that don't have some type of SCADA system, and in terms of computational pipeline systems, computational pipeline monitoring systems, I believe that many companies, and in fact probably most, have some kind of CPM system, maybe simple, maybe complex, but most of them have some kind.
So, when you have these type detecting systems, I think you look for who has been successful in their implementation, and I think the companies that have enjoyed the greatest success are companies that have recognized four factors.
First of all, the pipelines that you apply them on are unique. No two pipelines are exactly alike, and there's a lot of factors that go into that, but I think you have to realize that they are unique, and hence no one solution is going to fit all of them.
Secondly, you have to realize that there's probably in that uniqueness a need for more than one tool. So, if you provide one tool, you probably are not going to do the very best job that you can in terms of detecting releases.
Third is it is very, very important to understand that you must continually support those systems. In the absence of doing that, most companies have had catastrophic failures with these systems, that basically end up with them being turned off, and, last but not least, is there needs to be extensive training, and you've heard that talked about, but I'll pick these up in this order.
Each pipeline is unique. There's a lot of things that go into it. API 1149 deals with these. I'll just mention a few. Size, length, diameter. Physical characteristics. Physical configuration. Does it have intermediate pipeline pump stations? Does it have alternate origins, alternate delivers? Does it have injections? Are there major elevation changes?
All of these are things that need to be considered, and what is the operating mode? Is it a single product pipeline? Is it -- does it have batched operations? Is it continuous operation? Is it intermittent?
Again, I reiterate that because of this, because of the uniqueness, no single one-size-fits-all solution really works. So, recognize the uniqueness. You then look at the tools, and I would suggest that a variety of tools are needed to deal with it, and you'veheard this described a great deal already.
So, I won't go into a lot of detail, but I did want to say that basically, most tools are either based on the detection of a transient that occurs at the point of alarm, of a release, and that the second type is based on a recognition of the loss of the conservation of mass, and, so, both of these tools have very different -- they take very different faces.
They may be very simple. They may be very complex, and what I think we have to keep in mind is that we're trying to conduct release detection on pipelines that are in dynamic operating situations, changing hydraulic conditions, all in the time that we're doing deliveries from the pipeline, receipts into the pipeline. It isn't rocket science. We've heard that before, but it is not an insignificant technical challenge.
Okay. Let me look at the two sets of tools, and I won't go into these in any great detail, but from the operator's perspective, first of all, I think that pressure and flow monitoring, in spite of the fact that these have been characterized as somewhat out of favor, I think it is still important to the operator.
It gives the opportunity for a fast-acting, albeit somewhat less sensitive, tool, but as was -- asMr. McCoy provided in one of his slides, even though you may detect larger leaks in smaller intervals of time, the actual amount of commodity escaping from the pipeline may in fact be minimized.
So, from that standpoint, I think it's very important. One down side of it, it is not persistent. You're looking for that initial shock wave that takes place. If you miss that, within a matter of minutes, it will factor itself back in to a new steady state on the pipeline, and you miss it.
The other thing is that these tools are generally more susceptible to alarms and take a good deal of management.
The next thing is line balance, and this comes in many different flavors, simple line balance, enhanced line balance, all sorts of things. Typically, it is slower-acting than the first type tools I talked about but more sensitive, as described in barrels per hour leaks.
It has the additional advantage that it's persistent and generally has a lower rate of alarms than does the pressure and flow monitoring.
Okay. Both of these tools, when they're applied properly, will generate some kind of an indication of an alert, an anomaly on a pipeline, andthese need to be given to a highly-trained pipeline operator. That pipeline operator, knowing the capability, knowing the limitations, and being armed with current operating data on the pipeline, can make an appropriate decision about the response that needs to be taken.
Okay. If you've got -- if you've recognized the uniqueness of the pipeline, you provided a set of tools, you've got to go beyond that. You cannot apply it and walk away from it. You're dealing with a long-term commitment and a not-inexpensive commitment in terms of support.
First of all, pipelines are rarely viewed as being buried in the pipelines where they never changed, but in fact, that's not the case. It may not be a physical pipeline change that takes place. It may just be operational, but any application left to itself will soon become outmoded and hence less effective.
The second thing, we've heard described several times tuning. This is basically a balance of sensitivity versus alarming, and that needs to be done vigorously, originally, but needs to be done continuously as you use the tool, and last is alarm management.
We understand from the implementation of thequality improvement process, and our companies over the last 10 or 15 years, that the things that you measure are things that you can improve, and if you don't manage, if you don't measure alarms and their performance, then you're missing a great opportunity to enhance your tools.
The next thing is training. It's covered last, but it's certainly not least significant. It's important. It cannot be overlooked. All of us that deal with sophisticated software programs know that they must be maintained, and those people need to be trained, but the most significant thing is the pipeline controller.
Controller needs to be thoroughly, thoroughly trained to begin with. In addition to that, there needs to be frequent refresher training. As I've indicated before, leaks don't occur very often in the pipeline industry. So, you need to continue to refresh people about the tools and the things that you're providing for them.
One of the things by rule, we have to have written procedures, written procedures for normal, abnormal and emergency operations. These need to be specific. They need to be very detailed, and the controller needs to be infinitely intimately familiarwith them.
So, all of this is very important. It needs to be, I reiterate, thorough, and it needs to be frequent.
So, let me then move on for a brief touch on response. Response is many things, but in its earliest stages, when it deals with a CPM-based alert, it means that you need to do a rapid and an appropriate response. That needs to be conditioned by training, and we've heard several times talked about culture, and that's very important. I think that needs to start absolutely in the board room, in the office of the CEO and needs to filter down to the controller.
In conclusion, I'd say that today, the prudent operator of pipelines is constantly trying to prove his ability to detect releases earlier and to respond appropriately to them.
Are we doing it? Yes, we are doing it. Sorry. Are we doing it? Yes, we are. Can we do better? Yes, we can, and that's what we look forward to doing.
Thank you.
CHAIRMAN HALL: Thank you very much, Mr. Darwin, for that presentation, and we'll now go to Mr. Nicholas. Are you making the next presentation, sir? Please proceed.
MR. NICHOLAS: Val and I together will do that.
CHAIRMAN HALL: All right.
MR. NICHOLAS: The TransAlaska Pipeline extends from the Arctic Ocean on the north to the Port of Valdez on the south. Across its length, it rises to 4800 feet, though it starts at sea level and ends at sea level.
It was originally designed with 12 pump stations, and from a leak detection perspective, it's important to note that we do have flow measurements on the suction and discharge of each of these pump stations, even though only six are still in operation.
Each day, one million barrels of oil flows through the pipeline to Valdez.
Alyeska Pipeline Service Company operates the pipeline for its owners and is owned by the pipeline owners as well. You see them on the slide.
The regulation of the TransAlaska Pipeline System is provided through the Joint Pipeline Office. The Joint Pipeline Office represents five federal agencies, including the Department of Transportation, the EPA, the Bureau of Land Management. It also represents six state agencies.
Alyeska's always been under intense public scrutiny in the offices manned by the JPO in Valdez, and the JPO personnel are in sight during any pipeline shutdown or other unusual pipeline operations, and they may call and plan spill drills.
Following a GAO audit in 1989, Alyeska formally committee to maintaining the state of the art in pipeline leak detection on the TransAlaska Pipeline, and this commitment is very important to Alyeska.
I had a disclaimer side there, but I'll skip over that for today.
We provide three tools for pipeline leak detection. Those are our deviation alarms, our transient volume balance leak detection, and our line volume balance leak detection.
Our deviation alarms provide real-time detection of changes in pressure and flow measurements, and they are set with a sensitivity of about 10,000 barrels per day, which seems like a lot but it's one percent of the pipeline flow. So, it's fairly small.
The response times are one to five minutes, and they do have an implied location capability based on where the alarm occurs.
Secondly, we have two systems that are based on volume balance or mass balance on the pipeline. These systems are called our "transient volume balance system" and our "line volume balance system".
The transient volume balance leak detection system provides real-time volume balance with compensation for line pack changes using a real-time transient model.
It monitors the pipeline from pump station to pump station, so it breaks the pipeline into 12 segments, and performs individual leak detection on each of those sections.
It reaches a sensitivity of about three-tenths of a percent to half percent of the pipeline flow over the longer time periods of its analysis, with a little less sensitivity over shorter periods, and the larger sensitivity here is in areas with pipeline flow which I'll talk about in a minute.
The response time of our transient volume balance system is 15 minutes to 12 hours, depending on the leak size and location, and the system does have the ability of computing the leak milepost and also the leak size.
Our line volume balance system is also a mass balance system, and it's also based on our real-time transient model, the same real-time transient model that's used in our TVB or transient volume balancesystem, but it monitors the slack line as a single segment, and we consider it a historical volume balance in the sense that it runs once every 30 minutes rather than every time data is received along the pipeline, and it looks at the data for the last several days, and in particular the last 24 hours.
It achieves the highest level of sensitivity of about 3000 barrels per day during stable conditions, which is about two-tenths percent of the flow in the pipeline.
Its response time is six to 24 hours, and it provides some leak detection or leak location capability. Between these three systems, we have a performance map that provides fast detection for larger leaks with our deviation alarms, moderate level or speed detection for smaller leaks with our TVB, transient volume balance, system, and then the highest sensitivity but over longer time frames, leak detection using our LVB or line volume balance system.
There are a couple of factors that are the primary limiting factors for leak detection on the TransAlaska Pipeline. One of those is slack line flow, which you've heard mentioned earlier today.
Slack line flow occurs typically at a mountain peak when the pressure drops to vaporpressure, and then on the downhill side of that peak, the line flows partially full. You might envision it like a waterfall falling down a mountain if it's steep enough, but it's all inside the pipe, but it's partially full.
Then somewhere down the mountain, it repacks the line, and at that point, the flow is referred to as tight line flow, where the bubble is in the pipeline is referred to as slack line flow.
This occurs really on most liquid pipelines in some operating conditions, but it's particularly an issue for the TransAlaska Pipeline in that we have some areas where we have up to 20,000 barrels of slack volume, and by that, I mean it would take 20,000 barrels of oil to fill up that bubble that exists in the pipeline.
We have a real-time model that computes the slack bubble. We have actually models of slack line flow, but our fluid volume cannot be represented as accurately in the slack regions as it does in the tight regions, and the use of DRA or drag-reducing agent does add to the slack volume uncertainty. Correspondingly, leak detection is less sensitive and slower to respond in the slack regions.
All leak detection systems are ultimatelylimited, certainly those that are mass balance-based systems, are limited by the flow measurements in and out of the pipeline, the accuracy and the repeatability of those measurements.
We have, of course, custody transfer measurements coming in and out of the pipeline and also very accurate tank level gauges, but our station measurements, our suction and discharge measurements at each pump station, are ultrasonic flow measurements, and they are prone to repeatability errors, and they primarily are one of the limiting factors on our TVB leak detection system which operates from pump station to pump station.
We do have a project underway to improve the repeatability of these measurements, and we think we've found some of the problems with them, but that's underway, and we're hoping to improve our sensitivities as we improve those measurements.
Each month, we report our leak detection sensitivities from our TVB, our transient volume balance, system to the JPO. These next two slides are taken directly from that report, and we report our sensitivities for three different time periods, for each segment of the pipeline. These are Pump Station 1 to 2, 2 to 3 and so on, and we also report thepercentage of time that the pipeline was slack during that month.
You can see that Pump Station 4 to 5 was slack 100 percent of the time, and its thresholds, particularly on the short-term, were correspondingly much larger. On the longer-term periods, our thresholds for most our segments reached in the range of three-tenths percent of the flow rate or 3000 barrels per day. That is not quite as good in the slack regions, but it does improve over time.
This is the second half of the pipeline, and you see similar effects. Most of the regions -- so, we basically have two segments of the pipeline during the month of August that were operating slack most of the time.
Now that we've looked at our leak detection tools, it's interesting to consider whether they would have detected the leaks that we've actually had on the pipeline.
We've had five leaks on the history of the pipeline, and two of them would be detected by our current leak detection technology. The two larger ones were -- one was 1800 barrels per day or 1.8 percent of the flow. Another one was 10,000 barrels per day or one percent of the current flow, at that time maybehalf a percent of the flow.
Those are clearly within the range of detectability in our current systems. At the time, these were early in the pipeline's history, they were detected by third party report or Alyeska surveillance. The larger of these was caused by sabotage. Someone put dynamite on the pipeline.
The next three leaks would only be detected
-- were only detected then by pipeline surveillance. They are currently below our sensitivity limits, and even today would be detected by pipeline surveillance.
Now I'd like to turn this over to Val Hiebert, who will present the pipeline controller's perspective.
MS. HIEBERT: I'm going to briefly take you inside the operation control center, what we know as OCC. We are located at the Alyeska Marine Terminal in Valdez. We are approximately 10 to 15 miles from the downtown area of Valdez.
Our usual staffing in the OCC consists of a pipeline controller, a terminal controller, and a supervisor. All individuals are cross-trained and fully qualified in all operational areas of OCC, and this does include our supervisors.
This is our pipeline controller console. Ifyou pan from the left to right, the two panels are our TVB display system, the on-line and the back-up. The four displays across the front are SCADA displays, and then we do have a communication panel.
This is our terminal control panel. The terminal controller is responsible for terminal operations at the marine terminal and is also located in the OCC.
OCC controller training consists of initial qualification within what we know as QDP, a qualification and development program. We are also required to requalify every three years. We have an in-house two-day leak detection course, and we also have a pipeline simulator located on site.
We have a minimum departmental requirement to perform quarterly training on the simulator. We also use the simulator to qualify and train for pipeline shutdowns.
Our plan for the year 2001 is to incorporate TVB into our pipeline simulator. It takes approximately three to five years for a complete controller functionality within the operation control center.
Ed has addressed the three areas of leak detection within the SCADA OCC system. So, I won'ttalk about those.
I just briefly would like to address the misnomer of a false alarm. These are what we like to address as "non-event alarms". We have non-event alarms and event alarms.
A non-event alarm would be something that had an invalid or inaccurate input to create the alarm condition. If the actual alarm was a true alarm, we would see inputs to the alarm.
All alarms for the leak detection systems are audible at the pipeline console. The alarm status indicator does not clear until the actual condition clears. The controller does not have the ability to override this alarm status.
All alarms are logged and stored in our log historical database, and these events cannot be logged or changed either.
All alarms upon initial notification within OCC are treated as an event. The first steps that we'll initially try and take is to ascertain the location, the size, and the duration via MMI and also utilizing real-time and historical data.
We will also utilize field personnel for device verification and reconnaissance and surveillance. Our pump stations are manned on a 7 by24. Alyeska also has an ICS, incident command system, and we have notification procedures which include our regulators.
A very useful tool on our SCADA system is our real-time model or known as the hydraulic profile. I'll briefly cover information on this. It has the status of our communications on our leak detection system, both on-line and back-up, a depiction of MAP, maximum allowable pressures. We also receive pressures from the TVB leak detection system. It has a depiction of pipeline aboveground and below ground and statuses for MAP and leak alarms.
The lower grid that you can see is critical mile post pressures along the pipeline.
When a leak alarm is received in OCC, whether it turns out to be an event or a non-event, we always complete a leak alarm log. This is stored on site at OCC for five years, retained for the lifetime of the pipeline, and also covered in the departmental procedure. It is available and has been reviewed by JPO and by Alyeska SCADA analyst staff.
This is a copy of our leak alarm log. Information on it will be the date, the time, the location, the size, if the alarm cleared, anything that the controller attributed the alarm to, any extracomments and documentation.
I'd briefly like to cover an example where I did receive a TVB leak alarm log, and there was no immediate attribution. It was TVB highlighted the alarm at our North Pole Refinery, which is located between Pump Station 7 and 8. The refinery had been shut down for maintenance and was in the process of coming back on line.
A deviation was -- the throughputs on both crude and resid was greater than it had been prior to shutdown. We received the TVB leak alarm log. However, we received no deviation alarms.
The next steps are not in sequence. Some of them were going on simultaneously. We requested the local operator to begin proving his meters and also to perform any initial surveillance of the facility.
We subsequently performed surveillance of the north and south ends of the facility, shut down the south end of the pipeline, and prorated our producers into Pump Station 1.
Utilizing Alyeska hydraulic engineers, we performed pressure verification and testing of the site and also utilized our SCADA analyst staff. The cause was found to be a flow meter.
This is an example where Alyeska likes toemphasize our controllers do have the authority and will take the steps necessary to shut down operations based upon operational information and experience.
We also like to emphasize that of utmost importance and concern to us is the integrity and safety of the people and the pipeline and the environment.
In addition to leak detection, Alyeska also has a surveillance program, which includes weekly air surveillance of the pipeline, regular ground surveillance, surveillance for cause as was shown in the North Pole example, and annual line walks.
In summary, the pipeline controller is responsible for monitoring the system for integrity and verifies all deviations, verifies validity of any alarm on the system, and will initiate steps, if necessary, to include surveillance, shutting down the pipeline, and isolating leaks.
We log all our leak alarm logs and provide appropriate documentation to management and appropriate agencies.
MR. NICHOLAS: In conclusion, we'd like to say that we believe that leak detection, effective leak detection is a result of a commitment to a process, not simply a system.
It requires appropriate instrumentation and accurate instrumentation, effective software tools, commitment by management to the process, regular attention and support, and responsible and well-trained pipeline controllers.
Alyeska's committed to each phase of this process. We are continually maintaining and enhancing our software and leak detection capabilities, and we do believe that we are attaining the state of the art in pipeline leak detection.
Thank you.
CHAIRMAN HALL: Well, thank you for that presentation, and again I was real pleased to have the opportunity to visit Valdez and see your pipeline in operation, visit the pipeline office, and actually fly to the northern end of the pipeline. So, it was very interesting, and I admire what you all do in protecting the environment and one of the most beautiful areas not just in the United States but in the world.
However, the fog was so bad in Valdez the day I visited, I could not see anything. So, -- and a written invitation would be accepted by the chairman to come back and visit soon.
Well, I'm looking forward to this presentation from Peter and Mike. My brother hasretired from Ashland Oil, and he gave me some special questions to ask you all after this is over. So, he said it might get your attention.
So, I don't know which one is making the presentation. Peter, please proceed.
MR. EVANS: Thank you, Chairman Hall, Board Members. Thank you for inviting us today to talk about pipeline safety. We think this is an important forum to talk about our business and our mutual business in achieving those goals.
I'm going to talk today about abnormal operations and response from two different perspectives. One perspective is the technology that we use, and the other is the people or the knowledge that we use in order to detect and respond to abnormal situations.
These types of resources have to work together in order for us to safely remotely control our pipeline systems.
On the technology front, we use technology in the field, in the form of instrumentation, and in our control centers through our SCADA systems. The SCADA systems simply gather information, process that information, and display the information to a human operator or analyst.
I think today, I'm the first person to use the terminology "analyst" in this endeavor.
The SCADA system also provides a platform to run higher-level process applications to help the analysts interpret that information. Our analysts are humans. They're typically running a remote operation. This mode of transportation, like was pointed out earlier, is different than what we normally think of as transportation.
Unlike a bus driver or an airline pilot, the pipeline analyst does not sit in the cab of a moving vehicle. In addition, the pipeline analyst can also operate multiple systems in different parts of the country simultaneously.
Data quality is very important in this environment. We've worked with a consultant, Stratos LLC, a consulting firm out of Houston, in our operations center to provide tools for us to use to assure that the data that we receive is the best that we can get, and the analyst is provided the information on a computer screen that is a representation of an instrument in the field.
That instrument, for example, may tell the analyst of the pressure in the pipe at a certain location. That pressure sensor is a calibratedinstrument that converts the pipeline pressure to an electronic signal that is then transmitted from a local system and then on to our operations center via a satellite or other telecommunication lines.
The information that the analyst sees is inferential. It's a logical deduction based on facts. Inferential data isn't bad. It's just not a fact.
When responding to an abnormal situation, an analyst will most likely be using inferential data to take some kind of action. During an abnormal situation, the first priority must be safety. Often during the initial stages of evaluating an abnormal situation, an analyst can find themselves dealing with guesses, hearsay or beliefs, even fantasy.
Later on, opinions and assumptions can come to the surface. It can take time to develop precise, accurate, verifiable and measurable facts that are absolutely critical to resolving any abnormal situation.
Finding out what is going on or WIGO,
W-I-G-O, is another tool that we can use to help us climb that data quality ladder, to get away from the hearsay, the beliefs, to move above inference and to get to the facts, and using the facts to evaluate an abnormal situation.
This tool can help analysts work with others to define a problem, to get the story, to find out what is going on, to determine the object of the problem, to define and quantify the defect, to ask themselves what do I expect, what is expected, what is unexpected, to get the story, to determine the object, and to quantify the defect, but also to quantify the impact. What is going on?
I'll come back to this decision-making process in a minute.
How to improve? When we were asked to appear today, one of the items that the staff asked us to comment on was how our industry could improve.
Technology seems to always be improving. I don't know if that's good or bad, but it's a fact. Directionally, data quality needs to get better. More field instrumentation could improve our ability to analyze an abnormal situation.
Our technology needs to move towards and improve the ability to detect problems during transient line condition, especially things like slack line flow.
Smart systems can lead towards improvement in providing assistance to the human side of this equation. These improved systems can combine and analyze vast amounts of data in order to present a moreclear picture of the pipeline operation to the analysts.
Now, I got really technical with this slide here. So, pay attention. Basically, what this is is a representation of the inverse relationship between complexity and reliability.
As our industry strives to detect smaller and smaller leak rates, the complexity of the systems needed to detect those leak rates increases. There is a practical point where the increased complexity of the system can result in lower overall reliability.
Our analysts want to be able to detect small leaks with a high degree of reliability, and we need to provide them with systems that do that.
Improving our knowledge means selecting the right people for the right positions. Targeted selection is a tool that can be used to assure a high degree of what I call "motivational fit" between the employee, the pipeline analyst in this case, and the job.
Training is a continuous process that involves not only new analysts but also experienced people as we've heard. Improving our industry means improving our skills through our people always improving.
Training can be tailored to individual needs through application of individual needs assessment reviews. During these reviews, analyst-specific strengths and weaknesses are identified, and then training can be targeted towards improving those specific aps for that individual.
Using training simulator to allow an analyst practice in addressing abnormal situations is an improvement that is becoming more common practice in the industry. It may seem simple, but moving in the direction to include the use of what we call "teachable moments" or, in other words, identification of actions that need to be improved on the spot is an improvement.
Providing analysts with an opportunity to experience field assignments so they can get hands-on experience with the equipment that they will be operating can also be another kind of improvement.
Moving in the direction of discipline is an improvement, and what I mean by this is having standard operating procedures or operating disciplines in a culture that insists functions be performed in a standard and a structured way so as to avoid error.
I'll share with you a couple of examples of standard operating disciplines that we've recently developed. We call them "checklists". They're simplereminders of what to do and what is expected.
I'll begin with the end in mind. Stopping a pipeline. Abnormal situations need to be proactively addressed, and that can mean stopping a pipeline. This cue card notes some important indicators to an analyst that there could be a problem on a system and provides a reminder that it's "okay" to shut down the system.
There are several different ways for an analyst to detect an abnormal situation.
The second cue card that I'll show today is how to get help. Oftentimes analysts have related to me that they feel isolated and insulated from the world, but we encourage them to get help, to use the data quality letter that I showed earlier, and to determine what is going on when they have an abnormal situation.
This cue card is essentially a help and a reminder to use all of the available resources inside our control center and outside our control center, including resources, such as LEPCs, the public, and others. It's also a reminder that we want to find out what is wrong. We want to get help, and we want to fix it.
Another fairly simple cue card is a pre-start checklist. It's one last check to make sure that ananalyst gets the help he needs, that he determines what is wrong, and that it is fixed before a pipeline is restarted.
This checklist includes reminders to help us assure that the cause of the abnormal condition has been fixed, and that all of our resources, including those external to their control center, have been used. They've been implemented to assure safe operation.
I've got just a couple of final thoughts. Our industry should not compete when it comes to safety. We need to share concepts, ideas, strategy, and experience in an effort to continuously improve our safety record. We need to collaborate to improve industry performance.
Training is a key aspect, it's been mentioned several times today, of improving our response to leaks. We can throw all kinds of technology at a problem and still not solve it. People can and do make a difference every day.
One last final thought here. We'd rather not respond to abnormal situations. We'd rather prevent the spills from happening, and I think the best thing our industry can do to work to prevent -- is to work towards prevention of the incidents.
That's our comments. Thank you.
CHAIRMAN HALL: Well, well said. Thank you very much.
We'll turn to our Technical Panel for questioning.
MR. BESHORE: Thank you, Mr. Chairman. I don't have any questions.
Dr. Weeks?
DR. WEEKS: Yes, I do. I have two. I'd like to pose the first question to Ms. Hiebert regarding the simulator training that you give the controllers, and my question is, after the controllers have completed this simulated training, have you been able to observe or document any improvements in their performance on the actual pipeline?
MS. HIEBERT: I can't answer positively to that. We do not track that. We do have a training coordinator who will go back through and review the response to the simulation, and we have certain steps that are laid out as expectations that we look for controllers, but we haven't tracked in terms of improvement as far as I'm aware of.
DR. WEEKS: Okay. But am I to understand, though, that you do assess their performance in the simulator?
MS. HIEBERT: Yes, sir. That is correct, andthere's certain responses that we have to satisfy in order to pass what we call QIs.
DR. WEEKS: Thank you. And my second question goes to Marathon Ashland, either of you could answer.
You had told us that one of the ways to improve the knowledge or the people part of the system was through targeted selection, and I was wondering if you could expand on that in terms of what the selection criteria might be and how you chose those criteria.
MR. EVANS: I can answer that question. When I talk about motivational fit for an analyst, what we're looking for is someone who is good at problem assessment, someone who is quality-oriented, someone who has a high attention to detail, and someone with the mechanical aptitude, and those are the top four or five issues that we look at.
We've identified those through experience. If we hire the wrong kinds of people, they don't --they're not happy, and they don't stay, and we want analysts who will stay in the operation center and use that experience towards operating the line safely.
DR. WEEKS: Are those attributes that you mentioned assessed in any objective fashion in terms of entrance examinations or --
MR. EVANS: They're part of an interview process and part of the formal performance evaluation process every year.
DR. WEEKS: Okay. Thank you. That's all I have.
MR. BESHORE: Thank you, Mr. Chairman. We have no further questions.
CHAIRMAN HALL: No more questions from the panel?
All right. We'll go to Member Carmody.
MS. CARMODY: Thank you. I very much enjoyed this panel. I have no questions, but it doesn't reflect the fact that I learned a great deal and especially appreciate hearing about the Alaska Pipeline.
Thank you.
CHAIRMAN HALL: Okay. Member Hammerschmidt?
MR. HAMMERSCHMIDT: Just a couple of questions.
I'm curious, Mr. Darwin, on your affiliation with the American Petroleum Institute. The subcommittee you're a member of is called the Cybernetics Subcommittee, and what is the significance of the word "cybernetics" in reference to what you do?
MR. DARWIN: It probably doesn't come realclose to fitting whatever the dictionary definition is, but it's the application of technology to the operations of pipeline.
It takes a lot of different facets, includes communications, includes SCADA systems, includes release detection systems, and what we have been charged with, as I indicated in the presentation, is, first of all, being aware of what's going on and making the member companies aware of what new capabilities are out there and how they might be used to improve pipeline operations.
MR. HAMMERSCHMIDT: Okay. Thank you, sir.
My next question, I guess, goes to the Alyeska panelists, and I might say that I've had the privilege of visiting the Alyeska Pipeline back in 1992 briefly.
Again over the lifetime of the pipeline, how many leaks have there actually been? Have there been documented?
MR. NICHOLAS: There have been five --actually, there may be one more leak that I didn't give in my report. At most, there have been six leaks on the pipeline.
The four -- four of them smaller than, I think, the current software tools could detect, and twothat could be detected with current tools.
MR. HAMMERSCHMIDT: Okay.
MR. NICHOLAS: They were all detected. The spill volumes ranged from 400 barrels to, I guess, as large as maybe 14,000 barrels, and I think the majority of those occurred in the early years of the pipeline.
MR. HAMMERSCHMIDT: Yes. And over the history of the pipeline, how many leak detection-oriented alarms have there been, would you guesstimate?
MR. NICHOLAS: Oh, that's very hard to estimate because we've had a number of improvements over time.
I can tell you the way it is right now. Our -- perhaps our first line of defense is our TVB system. It's the one we require operators to fill out the forms on. It's the one we report to the Joint Pipeline Office.
On that system, we also report in that report how many alarms we have each month, and that number varies from -- probably averages between four and eight. I think the largest we've had recently was perhaps 14, and we had two pipeline shutdowns during that time that did cause several alarms just because of the nature of the measurements and where they are during the shutdowns.
But we -- typically, we have four to six, four to eight a month. We actually think that's a pretty good number because it means that every operator probably has an opportunity within one to two months' time period, each controller will have to deal with an alarm and have to ferret out the cause of it and determine whether it's real or not, and, so, I think we view that as a fairly reasonable number of alarms.
MR. HAMMERSCHMIDT: Okay. And that's all I have. Thank you.
CHAIRMAN HALL: Thank you.
Mr. Nicholas, what are the current limitations in the effectiveness of your leak detection system, and what improvements, if you could do whatever improvements you would like with the technology, what would they be?
MR. NICHOLAS: Well, you're asking me to stick my neck out here.
CHAIRMAN HALL: Well, I read your biography up here, and it says you designed the system, right?
MR. NICHOLAS: That's correct.
CHAIRMAN HALL: So, I figured you're the person to ask that question.
MR. NICHOLAS: The two primary limitations are (1) slack line flow, and several people havereferred to that. It does make it much more difficult to compute the change in pipeline volume and detect whether you have -- you're losing volume from the pipeline or not, and the accuracy of the station flow measurements, which I referred to.
Those two, we are doing some work on -- a lot of work on the station flow measurements, and we do think we're going to improve that substantially or we certainly hope that we're going to.
Slack line flow. Certainly when we change pipeline operations, we discuss whether it's going to increase the amount of slack line flow we have. It's something that's taken into consideration, and we do think about leak detection in those respects.
The only way to alternately truly get rid of that would be to not operate in slack line flow, and that's the case really for most liquid pipelines. Slack line flow operation is a normal form of operation in liquid pipelines, but it does work to the detriment of leak detection, and it would take substantial changes perhaps in pipeline operations to avoid that, but that would perhaps be the ideal situation.
CHAIRMAN HALL: Was it run that way for economic reasons or is that just historic and be too difficult to change?
MR. NICHOLAS: It's -- it would require additional pipeline instrumentation to avoid. You would have to actually install pressure-reducing stations along the pipeline to maintain higher pressures at the elevation peaks, and without exceeding the operating pressure, allowable operating pressures at the low points in the pipeline.
So, it is -- in that sense, it does require a bit of engineering and change in the overall pipeline operations.
CHAIRMAN HALL: Okay. Well, Peter, you and Mike have a different type of geography to deal with. What would you say your limitations are in the effectiveness of your system, and what technology improvements would you like to see?
MR. HUBER: We installed our latest CPM system in 1996, approximately. We've been tuning it for the last four years. Some of the issues that we've had difficulty dealing with are transient conditions on start-up and shut-down.
We also have some slack line flow conditions in the Rocky Mountain area that we have difficulty with, and we also would like to find a better way to detect instrumentation testing that's going on in the field locations.
Things we're doing to try to improve that situation, next year, we're starting a multi-year project to start looking at real-time models to handle some of our more complex systems, and we're working on some procedures to work with the field personnel. When they test the instrumentation, we can take that into account within the CPM system.
CHAIRMAN HALL: And, Mr. Darwin, should -- I guess in API, what percentage of the pipeline systems do you all have as members? Is everybody a member or is --
MR. DARWIN: I don't know that I can actually answer that. There are about 20 major pipeline companies that are involved actively in Cybernetics.
Obviously many of those are integrated pipeline operators, and, so, they operate many, many different pipelines.
I know that in the work that was done that resulted in some of those publications that I mentioned earlier, using various databases for names, addresses, and what have you, we sent out survey information to well over 300 companies, but many of those are maybe jointly-owned ventures that are operated within one of those -- maybe one of those 20 active members of the Cybernetics.
CHAIRMAN HALL: Okay. Do you think RSPA should require some minimum level of leak detection capability?
MR. DARWIN: That is a question that I think that the application of CPM ought to be -- ought to in fact be done.
As I have indicated before, I believe that many people are doing it and maybe even have chosen not to call it that, but I think it needs to be done, and that -- but to set it up as a minimum level is a very difficult question because you're dealing with different pipelines.
Some pipelines, minimum level means something very different than another pipeline. So, certainly to do that in a prescriptive, quantified number.
One of the things that we saw earlier today in one of the graphs that I think came off the Internet from what I understood, there was a sense that you ought to be able to detect four-percent leaks.
Well, in fact, that was a graph for only one pipeline, a unique pipeline. Every pipeline, you can generate that same graph, and in some cases, you ought to be able to do a great deal better than four percent, and in some, you will not be able to do that.
So, that becomes a difficult question toquantify.
CHAIRMAN HALL: All right. Thank you.
Well, I appreciate this panel's presentations, and I'll give you the opportunity, just as I have all the other panelists, to provide any closing comments you might like.
Mr. Darwin?
MR. DARWIN: Thank you, and I appreciate the opportunity to be here today. Just a couple of comments.
I think one of the things that really are beneficial for those companies who are successfully implementing CPM is testing. Now, you can get into arguments about whether they ought to be real, simulated, announced, unannounced. I don't want to get into that.
What I think testing ought to be is realistic. It needs to be well analyzed, and it needs to have the results of the analyzation fed back into your training process, so that what you end up with is what starts out looking like in fact a failure can end up to be success when you take your learnings, factor them back into your training, and then you have many people that benefit from that.
What all that does is drives you towardreliable leak detection, and I think that's what we're all -- all the prudent operators are striving for, and that's the detection of realistic-size leaks in meaningful time frames.
Thank you.
CHAIRMAN HALL: Mr. Nicholas?
MR. NICHOLAS: Well, I think it's -- we've talked about the API 1130, and I believe that the API 1130 primarily describes rather than prescribes what should be done.
I do think that it's -- the technology has reached the point that certainly every pipeline ought to be operating with some form of real-time mass balance or volume balance.
I've heard of too many cases where pipelines have not had that, and they've erred on the side of someone calling up and saying I need more product, and the other side saying I'm sending you as much as I can. They keep trying to send more, and meanwhile the pipeline is leaking into someone's water supply.
Real-time mass balance systems would be a step, a major step to limit that occurrence. They may or may not be based on real-time pipeline models, but I think we should remember that real-time pipeline models are simply a tool to give you a better handle of thevolume that's in the pipeline.
They're simply a tool to provide a better mass balance on the system. Still, we're fundamentally doing a mass balance or volume balance on the pipeline system, and I think that's essential. That should be done on every pipeline system in the United States.
However, it's difficult to prescribe software solutions if you don't have the hardware to support it, and we've heard about gas pipelines, Legacy pipelines across the United States that do not have real-time measurement of flows in and out of the system, and if you cannot meter your flows in and out of the system, there's no way that you're going to perform a mass balance in a timely period. Often the flows don't come in for weeks or even a month.
Perhaps on liquid lines, we err on the side of often not metering flows into tanks. We have the flows in and out of the pipeline but not the flows into the tanks, and that also limits sensitivity.
So, I think the solution in the long run, not necessarily in the short run, will involve addressing the instrumentation issues, addressing software issues, and looking at the whole system as a package, requiring an accurate volume balance.
CHAIRMAN HALL: Okay. Thank you.
Ms. Hiebert?
MS. HIEBERT: I would just like to thank you for being invited here and given the opportunity to present the controller aspect of the operations. It's an area that sometimes we aren't allowed to speak about, but thank you.
CHAIRMAN HALL: Well, we understand you have been promoted now to an analyst. So.
MS. HIEBERT: Yes, sir. Thank you.
CHAIRMAN HALL: Now, we appreciate very much you providing the real-world experience for us.
Mr. Evans?
MR. EVANS: Thank you, Chairman Hall, for inviting us today.
I think you mentioned earlier today that this was a good forum for us to get together and talk, and that the value that we get by meeting people with other companies and by sharing our experiences goes a long way at improving public safety.
Thank you.
CHAIRMAN HALL: Thank you.
Mr. Huber?
MR. HUBER: I'd also like to thank you for allowing us to be here. It's been a very learning experience for me.
CHAIRMAN HALL: Well, thank you very much. I'll see if either of my colleagues have any closing comments. Member Carmody?
MS. CARMODY: Just briefly. I wanted to thank all of the panelists we've had for the past two days. I want to thank the NTSB staff. I think it's been a very informative, very useful two days.
My background is aviation. So, I'm finding the regulatory environment in this industry different and interesting.
I was very pleased to hear Administrator Coyner yesterday and pleased with the rule that's come out on the pipelines -- on the integrity requirement and the inspections, and I'm also going to be looking forward to the next two rulemakings that she promised us by, I believe, March of next year, as I recall.
Thank you. That's all I have to say.
CHAIRMAN HALL: Member Hammerschmidt?
MR. HAMMERSCHMIDT: I also would like to extend my thanks to all the panelists who have participated during the last two days, and all those people in the audience that have attentively attended for the last couple of days.
I also think it's been an educational experience and most worthwhile.
That's all I have.
CHAIRMAN HALL: Well, I'd like to thank the panelists, and let everyone in the audience know that I understood most of what was said in the last two days.
I think over 50 percent. I wouldn't go any further than that.
But it was, I thought, very, very informative, very technical at times, but I think the
-- I could tell from the audience's attention that I think all of the information was important, and I'm very pleased that our staff put together such an informative presentation.
I'd like to thank the head of our office, Mr. Chipkevich, and our hearing officer, Mr. Kris, as well as all the other individuals from the office that participated and provided assistance.
I think these presentations were outstanding, and the effort that everyone put in them is evident, and I also want to thank very much the audience that was here.
I was so pleased to see that there are so many people that are interested in learning about pipeline safety and how to improve it. I hope you will take this information you learned here with you and put it to good use.
As I noted at the beginning of this hearing, the safe transportation of natural gas and liquid petroleum products is vital to meeting the energy needs of every community in our country, but all of us, whether we are representatives of vendors or companies or other parts of this system, also owe to every community in this country the responsibility to operate just as safely as we possibly can.
We need to do everything humanly possible to ensure that these products are delivered safely. I have difficult responsibilities, as you do in your day and in your jobs, but the day that I went to Bellingham and met with the families that -- of those three young people that lost their lives in that tragedy will be with me as long as I have the opportunity to live on this earth, and I hope that, based on the two tragedies we've had here in Bellingham and Carlsbad, that the industry itself will respond to that situation and be very proactive in working to support RSPA and work in the safety area.
Our pipelines are aging, and it is important that we make use of the best technology available to keep them operating safely and to minimize the consequences of failure. They can age and operate safely, just like the airlines that you probably flewhere today on, but your industry has got to be on top of that one factor as well as the many others.
We have examined ways to improve the inspection and testing of pipelines. We've learned about the benefits of various tests and their limitations. We've also learned about the capability of leak detection systems and problems that industry will face as they develop those systems.
The Safety Board is currently investigating six pipeline accidents, and they have safety issues directly related to those we have discussed over the last two days.
We will consider the information you have provided to us and hope this information will help us to make better safety recommendations.
In addition, I've been approached on break by individuals that represent the hydrogen pipeline system, individuals that are involved, I guess, in leak detection in our waterways and others from the national laboratory, I mentioned, and any information you have that our staff should be looking at and considering, we would certainly welcome to be presented to us.
Now, this hearing will be available for your further review on our website, www.ntsb.gov, in about a week, and we will notify those individuals who lefttheir business cards when that will be available as well as when the transcripts will be available of this hearing.
Please make use of the outstanding information that has been furnished here the past two days, and again I thank each of you for your participation, for your attention, for the courtesies you've extended to us during the time you've visited with us, and I hope everyone here has a very, very safe trip home.
This will conclude this public hearing of the National Transportation Safety Board.
(Whereupon, at 4:26 p.m., the public hearing was concluded.)
NTSB Home | Contact Us | Search | About the NTSB | Policies and Notices | Related Sites