This episode of the Oil and Gas Measurement Podcast explores the evolution and future of liquid flow computers, featuring insights from industry veteran Galen Cotton. The conversation highlights how measurement technologies have advanced over time and examines the role of modern flow computing, data communication, and system design in improving accuracy and operational visibility. It also touches on emerging trends that are shaping the future of measurement in the oil and gas industry.

Liquids Flow Computers Show Notes, Links, and Insider Terms

• Galen Cotton is a Managing Partner at Applied Metrology Services, LP and a measurement expert specializing in oil and gas field automation, flow measurement technologies, and loss analysis. He brings decades of experience in product development and strategic planning, along with extensive contributions to industry standards through leadership roles, patents, and long-term involvement with API measurement committees. Connect with Galen on LinkedIn.
• Nano 300 Flow Computer, a product of Newflow Limited,  represents the latest generation of flow computer technology that has been optimized for the custody transfer of liquid hydrocarbons, including the direct interface into meter proving systems.   The NANO Flow Computer is supported by range of additional software tools and signal conditioners and is a complemented by the Remote Measurement Unit (RMU), a fiscal quality RTU as well as the Pico RMU, designed specifically for meter proving applications.
• Applied Metrology Resources specializes in providing consulting services to enhance measurement accuracy in the petroleum sector, with  expertise that ensures compliance with industry standards and optimizes operational efficiency
• PD or Positive Displacement Meters are highly accurate volumetric flow measurement device mechanical flow measurement devices that measures fluids by trapping known volumes between bellows, veins, gears, or impellers as the fluid moves through a chamber of known volume.  Prior to the adoption of electronics, a non-resettable mechanical counter would capture the total number of oscillations or rotations of the device.  A counter reading would be manually recorded on a paper form (know as a Batch Ticket) at the start and end of each product movement or time period. 
• OMNI Flow Computer  was the first electronic flow computer to gain wide acceptance in the oil and gas industry for the custody transfer of liquid products. A contact closure or pulse from the primary device (often a PD meter) is brought into the Omni for accumulation, correction for temp and pressure, and final reporting.  In many early custody transfer installations, the Omni flow computer was attached to a local dot matrix printer, and printed paper Batch Tickets, which would me manually collected, carried to the office.  Omni flow computers are still widely used today, but has seen a decrease in market share. 
• API (American Petroleum Institute) represents all segments of America’s natural gas and oil industry. API has developed more than 800 standards to enhance operational and environmental safety, efficiency, and sustainability.
• Single threaded vs multi-threaded processing refers to how a computer cpu processes instructions.
  • A Single threaded cpu operates along a single instruction path, always executing commands in a specific order and at specific times.  They is said to be deterministic, in that the time between every input and every output are fixed and results are predicatable. 
  • A multi-threaded cpu can have multiple tasks being processes, each operating on their own path, with an operating system determining which instruction is being executed at any give time.   
  • In general, a multi-threaded cpu can get more work done in a give time period, but this comes with compromises.  In flow measurement, where monitoring rapidly changing I/O is key in minimizing measurement error,  a multi-threaded cpu may “slip” I/O monitoring tasks, which could result in reduced accuracy of the final calculations.
• Modbus is an industrial computer communications protocol that was introduced in 1979. It is a poll and response protocol that supports multiple devices on a communications channel but fails to meet modern data exchange integrity and security standards.  
• MQTT (Message Queuing Telemetry Transport) is a lightweight, publish/subscribe network protocol designed for low-bandwidth, high-latency, or unreliable networks.  It supports high security implementations and is becoming a de facto standard for transmission of data from industrial devices into the control room or business network.  

Liquids Flow Computers Full Episode Transcript

Speaker
Welcome to Episode 54 of the Oil and Gas Measurement Podcast, sponsored by EnerSys Corporation, provider of Muddy Boots field operations software assisting oil and gas operators to implement accurate and repeatable measurement activities across their entire operation, while also simplifying data collection from the field. Find out more about Muddy Boots at enersyscorp.com.

Welcome to the Oil and Gas Measurement Podcast, where measurement professionals, bubba geeks, and gurus share their knowledge, experience, and likely a tall tale or two on measurement topics for the oil and gas industry.

And now your host, Weldon Wright.

Weldon Wright
Hello. I’m your host, Weldon Wright of FPV Prime Measurement Consulting. And after almost two years of trying to sync up with recording, I’m honored to finally have Galen Cotton with us today.

Galen has been a fixture in the measurement world for 35-plus years. He’s probably best known for his liquid consulting in our industry and the key role that he has played for quite a few years in the development of our liquid measurement standards with API.

Galen, welcome. Before we dive into liquid flow computers, tell the listeners a little bit about yourself and all the stuff you have going on in the industry.

Galen Cotton
Well, I’m happy to do that. Good morning. I’m Galen Cotton. I’m one of those people who really doesn’t like to talk about themselves that much, so it’s a little intimidating to review one’s history for an audience.

But I have been in the measurement industry for 50-plus years. I actually started with Brooks Instrument Division back in 1972 and have had a long and very enjoyable association with a number of companies, the Emerson companies as well as Smith Meter, Khaldun, where I was a partner and president of the Petroleum Division, and have been involved in product development for most of my career, as well as management and sales activities.

Some of the things that I’ve enjoyed the most have been in the area of product development. That’s always been a feature of almost every employment that I’ve undertaken, including in the consulting capacity.

I have been a consultant for the last 26 years. I attempted to retire in 2000 after I left Khaldun and ended my partnership there. I had the strangest experience. I didn’t think that anybody would require my services, and suddenly I got numerous phone calls. Would I come and look at this, or would I look at that, and we have a material imbalance we need somebody to look at. Well, before you knew it, I was consulting almost continuously.

So I formed a company, Applied Metrology Services, which is the consultancy that I operate. And I’ve enjoyed the consulting part of the business. I had one client that I served for 20 years, a major NGL company. I think many people thought I was an employee. I was there so much.

All of those activities, both in product development on the engineering side as well as on the management side, led me to become engaged in API. The American Petroleum Institute is the foremost center for development of standards for our industry. It encompasses both the gas world as well as the liquids world.

I’m more comfortable, frankly, on the liquid side, and most of my activities have been centered there, although I do quite a bit of gas work as well.

The API experience has been really interesting because when I first engaged with API, some of the older participants were really quite knowledgeable, and they were happy to act as coaches for the more junior contingent within the API. That provided an opportunity to learn a great deal from people who had started back when measurement, for instance, was largely a mechanical affair.

My career started before the advent of computers. We didn’t have digital operations anywhere. There was no internet. There was no communication of that kind. I started in the industry back when, for instance, pipeline tickets were paper tickets produced by mechanical counters on meters in the field.

At that time, there were no turbines in operation. There were no Coriolis meters, no ultrasonic flow meters. None of that technology even existed. So everything was mechanical, largely PD meters. The industry was dominated by Smith meters and Brooks instruments.

People would go around, people who worked for pipeline companies, for producing operations, that sort of thing, and they would pick up paper tickets, often in a mason jar attached to a post somewhere. Those paper tickets were picked up, taken back to the home office, and their material balances were constructed manually from those paper tickets.

Weldon Wright
That’s an interesting way to do business. It’s also very lethargic. Hard to know what your financials look like when the ticket process could take anywhere from a week or more from the field to the office.

Galen
But it was what we had back then, right? That’s all we had. I mean, the gas world, when I got into the gas world, it was very much the same thing.

When we had the advent of computers show up, the first computer I ever saw was a little 4-bit processor that I had to program in machine code. So early days of computing were not terribly useful, but it grew very quickly. By the mid-’70s, we had already progressed to the point where we had programmable calculators.

There are a lot of things that took place in that first decade, the latter half of the 1970s and early ’80s, that had a big impact on standards production at API. I had the opportunity to operate and contribute to a lot of that.

I’m very proud of the fact that I was instrumental in getting API Chapter 5.8 for ultrasonic flow meters into the standards back when I was a partner at Khaldun, a producer of ultrasonic flow meters. That led to my appointment as Chapter 4 chair, which is the chapter that governs all the documents having to do with proving and calibration of instruments, primary flow meters in the field. So this is the proving documents, and I held that post for about 15 years.

All total, I have been associated with API for a little better than 35 years. So out of the 50 years in the industry, a bulk of it has been spent working with API. I continue to do so. I do chair a number of working groups even presently and plan to continue that association because I think that investing in API is a valuable thing to do.

Anybody in the industry that has an interest should attend and volunteer to work on the documents. You might think of it in the context that your participation is really essential because every participant in a working group stands as a watchdog for the industry. The industry standards reflect not what we want to do, but what we are doing. And so they evolve over time as new processes and new instrumentation are introduced.

It stands to reason that those with experience in the field should be the ones standing with the reins in their hand to keep API standards from running amok. There is a tendency for that to happen. So API is very valuable.

Weldon
Well, I think, let me interject there. This is kind of a soapbox of mine, but you mentioned early on that when you first became involved, many of the older guys there were very willing to take you under their wing and help you learn.

I want to reinforce that API, the standards groups at API, AGA on the gas side, GPA on the midstream side, participation in these groups is not for the 35-year experts only. While they, as you said, have the reins, it’s critical to get new folks, new insight into those committees.

If you want to learn about anything in the world, one of the best places to learn that at is on these committees. Get involved. Maybe all you do is proofread and spell check. God knows anything I’ve been involved in needed a lot of spell check.

Get involved in these groups. You will learn more from your participation in these groups than practically any other way that you can gain knowledge in this industry.

Sorry to derail you, Galen. Back to your—

Galen
I think those are valuable observations. The younger guys who come in have a different perspective than someone like myself. Hey, yeah, I’ve been in the industry for a long time, and there’s a tendency for the younger crowd to look at the older guys and say, oh, you’re an old guy. He doesn’t know anything. He doesn’t know what we’re doing now. And there is at least a grain of truth in that.

On the other hand, people who have a great deal of experience in the industry have the advantage of perspective. We see things as they began, how they evolved, and where the pitfalls were that we avoided because we have, in every case that I can think of, avoided major mistakes just by having an adequate number of people participate who said, no, no, wait a minute, that’s not really the way we do this. You’re writing a standard for something we don’t even do.

And there are still examples of that today. So we need the younger, but we need their view. We need their freshness, if you will. But you also need the leavening that’s provided by the guys with greater experience.

Weldon
I agree 100 percent, Galen. I think getting those folks involved is critical to keeping your industry fresh and alive.

So let’s wrap back around and talk a little bit about Applied Metrology and New Flow and the part of the flow computer business that you tinker in.

Galen
Okay. Well, I think it deserves a little perspective before we get into the meat of it. As I said before, back in the old days, before we had computers, everybody was running around picking up paper tickets.

Back in about 1990, 1991, Omni came into being, mostly guided by an old friend of mine, Ken Elliott. Ken is no longer engaged in that. He went home to England, where he was from originally. He and his brother Peter actually started the business, and he filled a niche that was an absolute void.

How do we gather data in the field, prepare it, organize it, transmit it to some central point? Well, we started off with Omni flow computers in the field, and still we had people running around picking up tickets. They were printed tickets that came off of the Omni.

Later on, as the infrastructure developed and we were able to get links to those sites, primarily major pipeline sites to begin with, we were able to retrieve that data digitally. So that filled a niche that had absolutely no one else even involved in it.

So that was a case where a company had a very good idea and was first to market. As a result of that, Omni has really dominated the industry over the last 35 or 40 years.

Interestingly enough, the equipment that they produce today is virtually identical to the equipment that was originally produced. It has not really evolved. And one of their much-pronounced selling points is that it doesn’t change. And that’s fine. That’s all well and good, but things do evolve, and innovation—I once had a guy that I worked for whose favorite line was, “We innovate or die.” So we can get left in the dust or we can innovate.

I think that’s true in this industry, although the industry is by and large very stodgy, lethargic in terms of adopting new technologies, not known for being early adopters. Nonetheless, things do progress. With the Omni, it has frankly not progressed. It is very much the same device as it was originally.

That has opened the door for a number of companies to get into or attempt to get into flow computing. That includes Emerson with their ROC series of flow computers. That includes Spirit flow computers, AXSYS devices, and of course it includes a device that one of my companies, Applied Metrology Resources, markets in the Western Hemisphere, and that is the Nano flow computer.

At this point, it’s the third generation of the Nano 300, and these products are all very much differentiated by a couple of things. One is their physical components. With an Omni, you buy an Omni. If you want it to do a certain job, well, you’ve got to have a selection of cards in the device that accommodate whatever it is you’re going to do. So it is a device that is largely hardware-defined. It has no set I/O. You select the I/O you want and you add cards to accommodate that. So it is very much hardware-defined.

The Spirit flow computer was, I think, an attempt to do something that was a little more flexible. It does have a fixed I/O. Its shortcoming is that its I/O is not very well isolated, and the programming is largely through a series of spreadsheets.

Now, I use spreadsheets all the time. However, I’m very much aware that any spreadsheet, regardless of how secure you may think it is, can easily be broken. So security is another issue. I can break most spreadsheets in probably less than 30 seconds. So that’s not a great feature.

I became involved with New Flow Limited, a UK company, about, oh Lord, it must be nearly 15 years ago. I have a number of U.S. patents that address various measurement devices, including provers. And one of the things I became interested in was the delay in a proving operation using current flow computers.

Provers by their very nature are real-time. When the prover hits the first switch, that is a particular point in time. That process gets sent to the flow computer. The flow computer has latency. It’s running a loop. That latency is a delay. So the delay time skews the data. And if the delay time is significant relative to the total proof period, then that can render a meter factor that is incorrect.

So the patent that I developed required a high-speed computer to correct for the time delay, and that’s how I got involved with New Flow. They had a platform that would do the job, a single-thread instrument. In other words, all of the data coming in over the I/O had no interrupts. It was a complete process, whereas most computers, if they have some internal housekeeping that has to be done, they will stop their program loop, take care of the housekeeping, then come back and resume. So that’s a variable latency, and this device did not have that.

So it was very much a device that was suited to the purpose. My relationship with New Flow developed over the years to the point where we decided that it would be a good idea to expand their operations in the Western Hemisphere. I was amenable to doing that, and so we formed an arrangement whereby I now represent them in the Western Hemisphere.

We produce, in combination with New Flow, a lot of instruments for flow measurement. We are the number one producer of interfaces for provers, both pipe provers as well as compact provers. We service virtually every prover manufacturer out there today. Our devices provide the interface for data exchange as well as for selection of prover volume. So we’re very much involved with provers. We have hundreds, if not thousands, of these instruments in the field.

We’re also very much involved in flow computing. Our flow computers are really quite different than anything else on the market, and that first of all, they are single-threaded devices. They do not have interrupts.

These devices are much like if you want the flow computer to be a prover, you simply load the application for proofing. If you want it to be a gas flow computer, you load the gas flow computer application. If you want it to be a liquid flow computer, you load the liquid flow computer application.

The liquid flow computer is very flexible. It handles crude, NGL, refined products, the whole range of products that are normally serviced.

Now, these devices are unique beyond the fact that they are single-threaded instruments. Their I/O is fixed, totally isolated. We don’t develop anything that is not totally isolated. We have MID approvals, we have ISO 9001 approvals, we have just about everything you can think of, every approval from national agencies that you can lay your hands on.

But the thing that’s really unique, in my view, aside from the fact of its programmability, how it is a standard set of hardware with multiple services, is that its programming is really quite simple. It has an embedded website in the instrument. All you have to do is go to the IP address, open the menu, and it is highly secure. There are about nine levels of security that can be applied.

But once you get into the instrument and into the web interface, everything you need to do is menu-structured. So you can walk through the instrument and program it in a matter of minutes. If you have a standard setup, it’s easy enough to program one instrument and transfer that same program to multiple instruments. Moreover, if they’re all on the same network, they can all be managed remotely.

We produce all of the utility programs for remote servers so that you can get into the aftermath and do whatever you need to do, extract reports or whatever. This device has a voluminous number of reports as well as graphing for all of the inputs. So it is really quite sophisticated and very easy to manage.

Moreover, it’s less costly than probably any other flow computer on the market. Its power consumption is half of what a Spirit is, and Omni consumes five times the energy this device does. So it is really quite a unique device.

Weldon
Galen, if I can wrap back around to something a moment, you mentioned it a couple of times, but I’m not sure that folks that don’t have an understanding of computer programming and computer hardware understand it. You’ve mentioned single-threaded a couple of times.

I really started in this industry working for Bristol Babcock with their flow computer devices, standalone and their distributed control systems also. That device and virtually every other device that’s out there in the market is not what you call a single-threaded device.

In another world of computer speak, instead of single-threaded, we would call it deterministic and non-deterministic devices. A single-threaded computer of any sort is called a deterministic device. We can sit down and calculate, or we can do it on paper, we can determine exactly what’s going on in that device at any given time. We can know exactly how often it looks at I/O, how often it does this, how often it does calculations.

In these non-deterministic or these multiple-threaded devices, we don’t have control. You mentioned interrupts. If the computer has housekeeping it needs to do, that happens.

Also in the gas flow world, that’s important, but it’s not critically important. In our measurement and office measurement, we’re not doing high-speed I/O. We’re okay. I want to look at that a few times a second, right? And we’re averaging this. It’s not high-speed I/O.

But if you are looking at pulses coming from another computer-driven device, if you’re looking at pulses from a turbine meter, if you’re looking for prover inputs, not knowing when that I/O is going to be looked at, and once the data gets into the I/O, once it’s gone through an A/D converter, when does that information get into the program? Not knowing that introduces problems and inaccuracies into that whole process.

So the fact that the Nano is a single-threaded and deterministic device is really important for making sure we have integrity of the data coming out of that unit.

Galen
Absolutely. And one thing I didn’t mention is that the heartbeat of the Nano is a half-second increment. So we’re looking at I/O connection every half second, and that goes continuously. Every half second, we’re making the rounds.

That information then is passed up to a CPU board that’s actually doing calculations, but it’s getting data that is deterministic. So it’s a very unique device, not just in the matter of its construction, its isolation, its low power consumption, its ease of programming.

We have lots of customers out there who say, well, you know, we like your standard program, but we’ve got this certain situation over here and we really need to do something a little bit different. We want to modify the program to do this thing, whatever it is. That’s really quite common with Omni. And in that case, they’re manipulating Modbus registers and that sort of thing to get the data that they want.

These devices are Linux-based devices. They’re open-source. And so we utilize a highly typed C++ programming language, and we supply a graphical programming interface free of charge to every one of our users. We provide instruction, and we’re happy to coach them through making any modifications they want to make as far as how they’re gathering data.

The one thing they cannot do is unlock any of the modules that are calculation modules. They’re MID-approved and they’re locked, which is critical. You can link them thread to thread to do whatever you want to do. So our graphical interface allows the user to do that really quite simply and very straightforward.

As you probably know, manipulating Modbus data can be kind of a morass. And so we are Modbus-capable. We have Modbus registers. We can give you the information as a matter of Modbus points, but we go beyond that.

We actually produce a device that is capable of any number of comms protocols. We do Modbus, we do OPC UA, we do XML, we do MQTT, and frankly, MQTT has become our favorite communication process. That’s a process that was developed by IBM back in the early 2000s and has progressed over the years into a protocol that is eminently secure, far more secure than XML or Modbus registers.

One of the things we like about it is it’s not a pull-response protocol. With an Omni using Modbus registers, it’s necessary to go out and ping it and say, give me these registers. And then the Omni replies and supplies the data. We push the data all the time. We don’t require a broker. We send it straight to, for instance, an AWS server, queued up and retrieved as necessary.

It has a very efficient and low-cost protocol for data transfer. I have one customer in North Dakota who had a large installation, some two and a half million barrels of storage, unit trains, the two rail barns, 24 loads in the rail barns, and for those who are not familiar with the loading, that’s a terminal flow computer, and for pipelines in and out of the facility, as well as 12 truck racks, all with their own flow computers.

Now, we partner with a company called High Wire that is in the back-office business. They do data accumulation for all of these kinds of facilities. So they produce the material balance reports for the facility based on the data coming from all of these devices.

Well, none of these devices really have similar protocols for transmission of data. What we did is we went to this facility, we put in three Nano 300s. Those three Nanos poll every instrument in the facility every half second and transmit that data via MQTT to the back office at High Wire. So we integrated the entire facility using three Nanos.

Weldon
You know, that communication piece, the integrity of the security of the information piece. Now, Modbus is still in common use. And I kind of, if we were recording video, you’d see me hanging my head and shaking it when I say still in common use, but I want to qualify this. Modbus is absolutely the best thing available in 1980.

Galen
Yeah.

Weldon
Right. And it was a great work that the group that put that out did some amazing work in the PLC, the controller, the small industrial computer device footprint. But it’s 1980, and it hasn’t changed much since then.

Getting away from the poll-response environment, getting away from the random cry out without the expectation of getting that cry out in step is just a vastly superior protocol. And I don’t know why, as an industry, we haven’t bowed up already and required to get away from these non-secure protocols.

Galen
I don’t know. It doesn’t really make a lot of sense to us, but we seem to be stuck in 1980 with a lot of these efforts. We’ve overcome that problem even for legacy devices in the field because we can go out, we can pull all the Modbus registers, we can accumulate the data, ship it via MQTT. And so that really solves the problem for an area like this one in North Dakota where they have a multitude of instruments. They’re not going to change those now. The expense is too great. They’re working fine, but they need to move the data. So we accommodated that.

Weldon
But you’re keeping that Modbus data and those other protocols secure within the facility, typically by wire or fiber. You’re not letting it loose into the outside world in an unsecured format.

Galen
Correct. So we provide all of that security. We are actually the firewall. All that data comes to us and it’s transmitted only to the AWS server. It doesn’t go anywhere else.

So yeah, I thought that particular application, first of all, it was a lot of fun.

Weldon
Well, I dare say not a lot of companies could have done this. And you talked a little bit about the work you did pulling in all those devices, how many devices that facility had in the field.

We ought to talk just a little bit, and I say this with a little bit of hesitation because if I get you on this topic, we may run into an hour-and-a-half podcast instead of a half hour or so, but the goal behind that is not just to get that information from each of those individual devices, but it’s to get it in a timely manner, an accurate manner, and in a format that we can put it together in a material balance that is very, very, very close to real time, as opposed to a couple of times an hour or, as we were back in the ’80s, hey, we get the information at the end of the month and then we look at it about the fifteenth and see what happened last month, right?

So being able to enable that timely material balance is very critical in that entire process in both the liquid and the gas world.

Galen
It’s a really good point. Material balance structures, as you say, are often well after the fact, where we’re looking at archive data that may or may not always tell us why the balance is not what it should be.

But if you have real-time data, and I didn’t mention that in this particular case, we’re also not just monitoring the ancillary flow computers for the flow meters in the facility, we’re also monitoring the tank gauges. So we have all the tank gauging data.

This is a mixed crude facility, so they have various grades of crude coming in. We’re analyzing density in the tanks, providing calculations for shrink. We’re doing all of that in the Nano. They’re not capable of doing that in the instruments in the field.

So that has a huge impact on material balance at any point in time for the facility. Now, the purpose in that is to allow the facility to get ahead of instrumentation that is producing data that contributes to imbalances.

So we’ve got a meter that’s gone haywire. We’ve got a tank gauge that’s hung up. We’ve got a mix of densities that were unanticipated. Let’s say the average in the tank is a 30 API, but they frequently have 42, 45 API entering the tank. Now we’ve got a big shrink problem, and so the balance in the tank is not what they think it is. It’s not strictly volumetric. We have to allow for the shrink.

Well, to have a pipeline connection where they’re injecting butane produces a tremendous amount of shrink, and that was also being uncalculated. So all these things allow the user to get ahead of his material balance and have a much more concise picture in real time so that he can fix it rather than having suffered through the imbalance for a month and then trying to correct it.

Weldon
Very well put, Galen.

So, Galen, we’ve talked a little bit about your history. We’ve talked a little bit about the history of flow computers on the liquid side. And I know we mentioned it or not, but there’s a multitude of devices out there on the gas side. The number is so much fewer on the liquid side, right?

Now there are companies out there that sell in the gas world that say they do liquid, but there’s really more differences in the two when we start talking about the calculations. The computer hardware, there’s a lot of differences in those two.

And so you’ve talked a little bit about what we need to be doing, how you can help address some of those things. Where do you see us going in the future, Galen? What’s the future of measurement and what’s the future of these liquid devices?

Galen
Well, you make a good point in distinguishing between gas and liquid flow computers. I look at gas flow computers and think if we as a company, if we’re going to really address the gas market, we’re going to have to do, I think, here pretty soon, a little bit of redesign because frankly the Nano 300 is overkill. That has far more capability than is necessary for gas measurement.

Gas measurement is by and large one density. It’s going to hover around 0.57. That’s where it is. You don’t have a lot of variation in density. Most of the installations are either differential pressure or they’re ultrasonic. We can accommodate both of those kinds of measurement, whether they’re digital or analog inputs doesn’t make any difference to us. We have all the temperature inputs that we need to accommodate any of those applications.

But the liquid world is really quite different. You have a multitude of densities. You have a multitude of different calculations depending on whether they’re crude or NGL or refined products. Some have stable densities, some don’t. Some are more temperature-critical than others.

We get into the NGL world and start looking at that thing, we have critical temperatures as low as 98 degrees and critical pressure under 70 psi. So these are applications that are calculation-critical, and the need for input security is heightened.

If we have, for instance, an ethane application, and we have temperatures above 98 degrees, that needs to be flagged automatically that we’re out of the envelope, that we no longer have a calculation that applies because the temperature is too high for the calculations. Same thing is true for the pressure if we start getting below 70. So these are all issues that have to be addressed by the flow computer that don’t exist in the gas world.

As far as where the future is going, we’re going to have to have devices that are faster, that are more secure, that can compact data into packets that are more easily transmitted. We need to lower the cost of these devices. We need to lower the cost of data communication.

I know plenty of companies who have a major part of their budget consumed just by the communication. They’re using a broker. That gets expensive, particularly when we’re having a call and then waiting for a response. So we’ve got a large bandwidth.

That’s one thing that MQTT does for us. The bandwidth is incredibly small and highly secure.

So the future, I think, will ultimately be a picture where we have more standardization in the device, lower cost in the device, more secure transmission protocols, data that is pushed rather than required by a call for, and we’re going to see an overhaul in companies’ material balance groups.

I know one major NGL producer here in Houston whose measurement material balance group is voluminous, quite large, particularly on the gas side, but it’s also true on the liquid side. Most folks, I think, actually in the near term are in jeopardy because with more, let’s say, better real-time data with faster communication protocols, more timely information, this lays the groundwork for the application of AI and more and more AI.

And so where we develop AI systems that can look at an accumulation of data, make the diagnosis, and say, well, at this site, the proving can’t be right because the frequency being produced for the period switch, the switch in the prover, doesn’t match what the unit was programmed for. So we’re missing pulses here. So here’s your problem here. You’ve got an inaccurate meter factor for that device because the prover was at fault for whatever reason.

So we’re going to have AI systems that can look at this accumulation of data, and they’re going to be able to say in real time, you need to go fix this because you’re fixing to have a big problem as a result. They can look at stuff that no matter how many analysts you had in that material balance group, there can’t be enough people to look at that stuff anywhere near real time.

Weldon
Right. That is exactly right. And data feeds AI.

Well, I think that’s a great place to start to land this thing at, Galen. Anything else you’d like to add before we wrap this up?

Galen
Well, you know me, Weldon, I can sit here and talk.

Weldon
This is a little unusual. I really like to hear myself talk.

Galen
Yeah.

Weldon
But you say that, Galen, but you like to talk, and almost everything that comes out of your mouth, we ought to take note of.

Galen
Oh, well, thank you. That’s a very high compliment. I appreciate that.

Weldon
Well, thanks for being on the podcast with us, Galen. It has taken a couple of years to get synced up, so also, thank you for doing this.

Galen
Well, you know how it is. We’re all busy.

Weldon
All right, sir. Take care and safe travels, and wherever your next missions take you.

Galen
Well, thank you very much.

Weldon
Thanks for listening, and please spread the word about our podcast by telling your boss, your coworkers, and your industry peers. Don’t forget, folks, that podcasts live and die by reviews and feedback.

Not only do reviews let our sponsors know we’re reaching the right folks, but every review improves our placement on search engines and makes it easier for new listeners to find our podcast.

So, as usual, we’ll have Galen’s contact info along with the full transcript of this episode in the show notes on our website, pipelinepodcastnetwork.com.

And if you have comments or questions about this episode, suggestions for new topics, or if you would like to offer yourself up to the podcast microphone as a guest, please send me a message on LinkedIn or shoot me an email at weldon.wright@fpvprime.com.