Welcome to the Pipe Liners podcast, episode 15. The Pipe Liners podcast, where professionals, bubblegeeks and industry insiders share their knowledge and experience about technology, projects and pipeline operations. And now your host, Russell Treet. Thanks for listening to the Pipe Liners podcast.
We appreciate you taking the time and to show our appreciation. We are giving away a customized Yeti Tumblr to one listener each episode. This week, our winner is Timothy Pasternak with Dominion. Congratulations, Timothy and your Yeti will be heading out in the mail directly to learn how you can win this signature prize back.
Stick around to the end of the episode. I want to start this episode by doing a shout out to listeners. Had a question from Randy Herman asking about what is a bubblegeeks? And if you listen to the intro for the show, you'll hear that term you.
So first off, just let me say I consider myself a bubblegeeks. This is a term of a deerment infection. For those of us that work in oil and gas, drive around and four wheel drive pickup trucks, like technology, many of us like things that you might think nerds like. And at the same time, we probably all so like those things that rednecks like like fish in and hunting and being outdoors.
It's actually one of the things that's nice about being in the pipeline business. You do get the opportunity to see some beautiful country. So that's what a bubblegeeks is. And another way to say that might be a nerd redneck.
So Randy, thanks for the question and I hope that clarifies things. Also, I'd like to shout out to several listeners. I'm not going to call them out by name, but had several people reach out and ask a question as a follow up to the last episode with Gian Carlo, Alano from Atmos International asking how much data is enough. And I get asked this question frequently.
So I thought what I'd do for this episode, something maybe a little different. I'm going to dust off a presentation I made at the 2015 intellect fall conference that was on this very subject. Some people would ask the question, how much data do I need from a regulatory standpoint? Or they might ask, you know, what are the implications of operating under the various regulatory requirements for control, re-management, leak detection, among others that would tell me, you know, how much data I need to get?
So I think the first thing you need to do is you need to talk a little bit about what kinds of system are you getting the data for? But because that matters and it matters in a material way. So the first thing to talk about is a little bit about SCADA. And, you know, obviously that's an industry term and most of us are familiar with what SCADA is.
But if I'm going to break that down, SCADA is two things. SCADA is data acquisition. And that relates to the data in the field and all the telemetry and software and hardware used to get the data from the field back to a computer system. And it's also supervisory control.
So supervisory control, it's kind of a key term in SCADA systems, which are used in pipeline, amongst many other industries. Supervisory control means I'm monitoring and I'm passing set points to the field, but the control, the actual logic that's, you know, controlling pressure or controlling temperature or controlling flow, that logic actually exists in the programmable logic controllers in the field at the field location. So that's why we call this supervisory control and data acquisition or SCADA for short. So SCADA is really a stack of technology.
There's a lot of things that go into it. At the very bottom level, it starts with instrumentation, pressure gauges, temperature gauges, flow instruments on the head of meters and so forth. Above that, we would have the PLCs or programmable logic controllers and the RTU's, remote terminal units and flow computers that take the signals and perform math and logic to determine flow and control points and so forth. And then behind that, or on top of that, in the stack, you'd have communications.
That can be field radios, cellular systems, satellite, telephone lines, and many other kinds of modes of communications, basically any physical hardware that's moving the data. Beyond that, we have what historically has been referred to as the SCADA host. That's getting in today's world a little bit less clear because the communications server and the SCADA host are often two separate pieces of software and can't exist on separate boxes. And I'll talk a little bit about that a little later in the episode.
So, and then of course, on top of that, you have the applications. The cost of building this technology stack out starts in the field. So I've got to put these programmable logic controllers and instrumentation and power for all that at the field. There's a big investment in that.
Then I have to have my communications network. There's a big investment there. But as I climb up this stack of components, my incremental cost gets less, but my value gets increasingly more because particularly once I get past the SCADA host and I start looking at applications like leak detection and analytics and engineering and so forth that can analyze this data and use it to support decision making, that data starts becoming very valuable. But I can't get there if I don't first make this spend on the full stack.
You might ask the question kind of follow this up. So all this data that's coming up through this data system, who all needs it and what do they need it for? Most commonly, we think about this data being used in the control room. I'm monitoring pressures.
I'm monitoring flows. I might be monitoring analysis. I might be monitoring, you know, H2S, but I'm monitoring what's going on in the field and I'm making decisions and I'm taking action to communicate with others to respond to what's happening in the field. So that's the first and most common use of SCADA.
We also collect data and pass it to the measurement group. So all of the information that measurement needs to perform its accounting and verification processes typically is collected through the same communications infrastructure that's collecting data for SCADA. I might also be passing this data to some kind of CPM or computational pipeline model that's taking the data and performing calculations and using those calculations to make an assessment of whether or not I might have a leak in the pipeline. I might also be gathering this data and passing it to some kind of historian or repository where that data is used by engineering.
It might be used by financial groups for developing models to forecast. I might be sending it to a facilities management system or machine management system in order to gather analytics to determine what level of ongoing support and service of that equipment might be justified. So obviously there's a lot of people using this data and all of this kind of goes into the conversation about how much data do I need because each of these users really need this data contextualized appropriately for their specific use. So I talked a little bit about how much data do I need from a regulatory standpoint.
So there's two regulation bodies that would govern the collection and use of data. One is all the 49 CFR part 192 and 195, which is the pipeline safety act, 192 for gas and 195 for liquids. There are aspects of in 195, there's leak detection requirements and they call out API 1130 as the standard to be used. And then likewise, you also have the control room management rule.
And that rule you have call out specific to adequate information and alarm management. In addition to the pipeline safety act, there's also Sarbanes Oxley, which artists bottle talked a little bit about in a recent episode, which would primarily govern measurement because Sarbanes Oxley is primarily a financial rule and measurement data that's created in the field by connecting up instruments and bringing that data into flow computers and performing calculations. All that information is going through accounting is ultimately directly impacting the financial. So Sarbanes Oxley governs that.
So even though we have these regulatory requirements and we have a number of standards that are incorporated by reference, we really don't have anything that prescribes the amount of data that you need to do any of these tasks. That's all left up to the judgment of the operator. When I start looking at how much data do I need, I need to start thinking about, well, what's the purpose of the data I'm collecting? And then what are the types of needs that are related to those purposes?
Let me try to unpack that a little bit. First off, I have prevention through systems. So by that, I mean things like leak detection and alarming. Alarming might not be a lot of information, but I need to pick it up in a way that I can get the alarm and the alarm will be timely.
So you have to ask yourself questions like if I'm monitoring pressures, how quick compressors change and how do I want that to alarm? That there's also issues that we'll talk a little bit about in the communications protocols themselves and how am I actually getting that data? So also have the issue of vigilance. So in the control room, vigilance is the term that goes to the controller monitoring the various screens that they're looking at and having enough free time and the appropriate data to be able to discern if something doesn't look right.
So that's another use or purpose of the data is to support vigilance. It could be called adequate information. I'm also using this information to coordinate delivery, make sure that I'm going to hit my daily and monthly targets for delivery through all my metering points. And then of course, I'm going to use this for the back office measurement.
Now, within all of this, there's also different needs for this data. So measurement obviously needs it marketing and scheduling need to see measurement data because they're coordinating with customers to make sure that customers are staying on their targets and meeting their nominations. There's also analysis data or analytical data that might be used by engineering. There's also optimization data that you might be bringing in off of pumps and compressors and types of rotating equipment to optimize my use of fuel or power in order to move the product.
And then of course, there's other types of coordination with other entities. So that kind of gives you a background. So when you ask the question, how much data do I need? The first question you have to answer is, well, data for what purpose?
Because that impacts how much data I require. So I also have some system considerations and these issues are kind of all interrelated. One issue is the actual communications capability that exists within my system. So if I'm moving data by satellite, satellite by its nature can have a natural delay between the time I asked for the data and the time I received the data of several seconds or more.
That impacts what I can do with the data. If I've got to be able to see things that change more quickly than once per second, maybe satellites not the way I want to go. Likewise, there's issues in the protocols. Most of the protocols that have been implemented historically are what would be called poll response, meaning I ask for the data by sending a request through the telecommunications and then I get a response.
So I don't get any data unless I ask for it from the host. This can create some limitations because depending on the amount of data points, I'm using protocol and the telecommunications capacity, I might only be able to get data at a maximum of some number. And in some systems, I've seen that take as long as 15 minutes because there's so much data being moved through the communications network. It takes me 15 minutes to make each request and wait for the response.
So that can drive considerations. There are other systems that are sometimes they might call this report by exception, but they basically send data to the host when it changes. In the Internet of Things, there's a protocol that's been around for a while, but is gaining popularity called MQTT, which is a published subscribe protocol. What that means is the data only goes to the host when it changes.
And that can be a big deal because I can move a lot more data and move it a lot quickly. And I don't bog the system down with requests that are let me know that things didn't change. So your whole communications capability, the polling, the protocol, the telemetry, all of that's going to impact what you're actually able to do. The other thing that would be impacting what you're able to do or should do is going to be the product type.
And by that, in general terms, I'm talking about am I talking about liquids? Or am I talking about gas? And liquids, pressures tend to move through the system very quickly. There are tools we use for leak detection.
Leagues can have significant environmental impact if they occur. So typically in liquid systems, I'm looking to get the data more frequently, something more like once every five seconds, maybe even more frequently, if possible. Then I have, what do I need for measurement? In measurement systems, particularly in a state of the art measurement systems, where I'm bringing a full audit trail from the meter in the field, I'm moving very large amounts of data.
And typically, I only do that once an hour because most measurement in the field is accumulating an hourly number. And then I'm bringing the data back at that being the resolution of the data. So I really can't pull any more frequently than once an hour. But when I do run that poll, I move a whole lot of data and that can materially impact, you know, the constraints of the system.
And then lastly, there's the pipeline operating condition. I've seen systems where they're low pressure, they're low volume, they're small pipeline sizes and data is only coming back to the host once every five to 15 minutes. I've seen other systems where they're large liquid transportation systems and they're moving data back to the host once every five minutes. So that's kind of unpacking system consideration.
So, you know, I've got to understand what's the purpose of gathering this data. And then I've got to understand my system and strengths and what that means to me and what capabilities I can implement. Then I have the data consideration itself. So now I start talking about how many data points do I need?
What's the quantity of data? You can think of that as do I have 100 pressure points or 1000 pressure points. You can also think of that as what kinds of data is it 100 pressure and 100 temperature and a 100 flow. That doesn't necessarily make a lot of difference in the communications infrastructure, but it certainly makes a difference in what am I doing with the data?
And then the other thing is speed or you could think of this as latency. And that being the when I ask for the data, how long do I have to wait to get it? And that can have a material impact. Likewise, I have frequency, how often do I ask for it?
Some data that I'm using for leak detection, I need that data very frequently. And increasing frequency improves the performance of the tools I use for leak detection. And then also I got to talk about is is there data that I need to put together in sets in order to process it. This is actually quite material.
Many of the older protocols, Modbus being a notable one. When I make a request, the timestamp is the time the data comes back to the host. It's not necessarily the actual time. So think about it this way, if I make a request at 15 seconds past the top of the hour, and if it takes five seconds for that request to get to the remote, and then the remote has to do some processing and that takes five seconds, and then it sends it back and that takes five seconds, then the data when I receive it versus the data and when it was created, it has a 15 second difference.
Now, in many cases, that doesn't make a difference. But if I'm doing leak detection in a liquid system and I want to be using five second data, then I need all those timestamps to be correct to actual time. That could be a material consideration in terms of getting additional accuracy or additional performance out of your leak detection. There's also other issues where I may want to be looking at data like a data set that relates to measurement and I got to make sure that those times are correct and accurate.
So there's a lot of considerations around the data itself. Let's break this down a little bit and I'm going to talk about several different uses. So when I talk about measurement and I look at these four different considerations, the quantity is all the measurement points that I require for my balancing or flow monitoring. The speed, a lot of times, bringing back measurement data, particularly through legacy narrowband communications, can take several minutes per request.
The frequency daily to maybe quarter hourly, depending on operations, most common would be hourly. And then the set would be when I'm doing line pack or balance rollup, I've got to get all the meters within that group that allow me to do the line pack or the balance rollup. So that's the way to look at measurement. From a marketing perspective, the quantity of the data is all the measurement points where I have volumes that are nominated.
Again, speed can take up to a few minutes to get updates. Frequency typically, I need that hourly. And then the set is I need a current day total flow rate and a time left in the day so I can calculate a number to compare it with the nominated volume is. When I look at measurement and marketing, the issues in the data are more about the sets and the sets being pulled totally, but it's not generally a lot of data.
It's just getting the data together well. When I start talking about analysis and optimization, I'm talking about lots and lots of data and the more data, the better, the more quantity that I have. I get data every five seconds, then every one second is going to be better because that's going to improve the fidelity of the algorithms that I'm using to optimize. How quickly I get the data doesn't really matter because usually I'm doing this analysis in the back office after the fact.
And in terms of frequency, you just call that often in terms of set data or processing. The key thing here is if I'm looking at if I'm doing a presser analysis, then I need all the data around the compressor. So I need pressures by cylinder and RPM and firing timing by cylinder and so forth. So but it's getting all that data together in order to be able to do the analysis itself.
From a vigilant standpoint, the quantity is whatever's necessary for the controllers to retain situation awareness and then when they have things that don't look right, whatever quantity of data is necessary to support their analysis. In this case, the speed issue, typically that needs to be quick. If I'm looking at a critical process, if I'm adjusting a flow control at a critical point, I might want to be seeing that update every few seconds. The frequency is generally never less than once every five minutes.
There are exceptions to this, but in the control room, if you have a point that you need in the control room, typically you're going to need to see that data at least ever five minutes, if not more frequently than that. And from a set processing standpoint, there's really not any of that. It's just I need the data on my screens to be current. Another purpose of data can just be simply coordination.
Typically, if we're coordinating, we're coordinating around flows or pressures or valve positions and whatever contract requirements related to how we're operating speed, generally quick. I mean, if I'm asking for information that I need to communicate, it needs to respond quickly. Frequency here is generally on request. I only need the data when I ask for it.
And then again, from a set processing consideration, there's little if any considerations there. And then lastly, in terms of purpose, we'll talk about alarming and emergency response. So the quantity is generally only the data at the site. So when I have an alarm, way to think about this versus just I have a high pressure is I want to know what's going out on at a location.
So if I have a high pressure at a mainline valve, then I probably want to know everything that I can get data wise around that mainline valve. Likewise, if I have an issue around a compressor station around a pump, I want all the data. I want the data quickly. I want the alarm to enunciate when the data is out of the operating range.
It should be within. And from a set processing standpoint, I want to be able to tie my alarm enunciation back to my alarm rationalization, meaning my understanding of what would cause the alarm to generate and what things I might do need to do in response. And that's really a topic for another episode. Let's talk about leak detection because really most of the questions that I got were, well, what do I need to be worried about with regards to leak detection?
From a regulatory requirement standpoint, API 1130 is incorporated in 49 CFR 195 by reference. And in particular, what you need to consider is what's in the appendix and specifically where they talk about sensitivity, reliability, accuracy and robustness. So sensitivity is the ability to predict a particular leak size and the speed at which you can do that prediction. Sensitivity is driven by the frequency of data.
You're going to have better sensitivity with five second data than one minute data as an example. The other thing that will drive sensitivity is the accuracy of the instrument. So if you have instruments that are out of calibration or out of service, that's going to impact sensitivity. The other issue is reliability.
And that is alarms that actually indicate a leak and alarms that enunciate, but where there's actually not a leak in place. And then you have accuracy, which is being able to predict a leak's location, its flow rate, its volume loss and the flip type. And then robustness and robustness is getting accurate prediction through a range of operating conditions. You can think of that as a range of pressures, a range of flows, a range of flood characteristics like density and having the system work so that the more data makes a leak detection system work better, provided it's properly built and that the data is accurate.
So doing a good job of managing a leak detection system is very much about making sure that leak detection system is being fed timely, accurate information. In API 1130, there's a figure called C1, that's Charlie dash one, that figure shows how a CPM system uses instrument data. So think of it this way, I get instrument, I get instrument information from the field and I feed it to the engine that is performing the leak detection algorithm, doing the math and coming up with a result that tells me whether or not I have a leak. And then it's taking that data and it's comparing it to the instrument data.
So it's taking the data used to perform calculations and comparing the output of its algorithms to the data it used to perform the calculations and it's doing it to the additional math to determine should I alert on what I'm seeing. The instrument data is actually used twice. It's used first in the engine that does the processing to create the outputs that tell me whether or not I might have a leak and then again to compare what's going on with the instruments with what's going on with the inference engine and particularly in real time transient models, this is critical. So think of it this way, I feed the data to a math model that tells me what should be happening a minute from now and then a minute from now I compare that to what I'm actually reading from the instruments.
That means that the instrument data, how much I'm getting, its accuracy and it's, you know, how it's organized is even more important because it impacts two parts of the leak detection process. Again, let's come back to data and how the question, how much data is enough. And I'm now going to talk a little bit about section 5.1.1 in API 1130. What you have to do is you have to match the instruments and their ranges and their specification to the pipeline and its operating design in terms of pressures, flows, temperatures, et cetera.
I need to be looking at the instrument manufacturers, stated accuracy and linearity. And I need to combine all the different instruments and their stated accuracy and linearity and use all that information to determine an uncertainty. So uncertainty, you can think of it this way. I've got all these instruments and none of these instruments measures a specific number.
They measure a number within a range, within a tolerance. And each instrument has its own tolerance. So if I take three instruments and put them together and each of those instruments has an uncertainty of 0.25%. I can very quickly, by combining those instruments, get a system uncertainty up to 1%.
Without breaking that down, but the thing that's very important is the accuracy of the instrument. So the number of bits that I'm bringing in, whether I'm bringing in 8 bits, 16 bits, 32 bits, 64 bits, off of the instrument bits being the technical jargon, if you will, for a amount of data. You can think about it. Am I reading the number to four digits?
Am I reading the number to eight digits? That's a good analogy for what we're talking about here. So it's not only the accuracy of the instrument, but it's also how much data in each packet for a specific number it can send and the more it can send the better. All of that goes to overall uncertainty.
So really, the question, how much data enough is enough is kind of the wrong question. The right question is, what kind of data do I need for what purpose and then how do I supply that kind of data? As with many other things, there's a little bit of engineering and analysis is required to get this correct. I just covered in about 20 minutes, what I spent about 35 minutes talking about at intellect back in the fall of 2015.
I'll actually load up a copy of that presentation so that you can download it off of the show notes page. Given the timing of my getting this episode out, I'm actually a little behind the the curve this week. It may not be up there the day the episodes drops, but it should be with up there within a day or two. So as I often do when I'm interviewing a guest, I want to try and boil this down to three key takeaways.
So I think the first takeaway is the question, how much data is enough is a little bit the wrong question. Probably the better question is, what am I trying to do and how much data do I need to accomplish that function? So where this question comes up, the most is with leak detection and with leak detection, it's certainly more data is better, but it's not just more data. You actually have to look at a program and you have to look at my instruments and how, you know, what's the accuracy of those instruments and how many bits of data can I get when I get the data back.
That may mean that I would better spend my money getting more detailed, accurate information from the instruments versus getting more data. There's a trade off between those two things. That's key takeaway. Number one, I think the second key takeaway is as with many other things, you got to look at this as a system.
You got to look at the system constraints and make sure that whatever I'm doing to get the right amount of data, I'm addressing that comprehensively. And then lastly, when you really start trying to get the very high accuracy, very high sensitivity and leak detection, the amount of data and the accuracy of the instruments and the time stamping of all that data becomes very critical. That's not a lot to say in a statement like that, but there's a lot to unpacking that fully from a system standpoint. I hope you enjoyed this week's episode of the Pipe Liners podcast.
It's an honor and privilege to actually be the guest if you want to look at it that way and have the opportunity to talk to you about how much data is enough. Just a reminder before you go that you should enter to win our customized Pipe Liners podcast, Yeti Tumblr. Simply visit pipelinerspodcast.com slash win. That's pipelinerspodcast.com slash win to enter yourself in the drawing.
If you have ideas, questions or topics that you'd be interested in, please let us know on the contact us page at pipelinerspodcast.com or reach out to me on LinkedIn. My profile is Russell W treat. That's Russell with one L and I'm easy to find. And then lastly, I just like to mention that we have had several listeners ask the question, how do you get into the pipeline business?
I'd like to get on the show as a guest, a recruiter or somebody internal to an HR department that's involved in recruiting for pipelines to come on the show and help answer that question. So if you'd be interested in doing that, just go to the pipeliners podcast.com site slash contact or the contact page and drop me a note. Thanks again for listening and I'll talk to you next week.