This week on the Pipeliners Podcast, host Russell Treat talks with Geoff Daily and Aaron Knabb of Bifrost, the MetaSCADA division of Techneaux, about moving SCADA data reliably across the enterprise. The conversation covers why a simple pull from the historian often isn’t enough, how Bifrost’s naming and namespace tools address the “what do you actually have” problem across disparate systems, and what a pipeline operator should look for when evaluating a data integration partner.

Real-Time Data Management Show Notes, Links, and Insider Terms

• SCADA Supervisory Control and Data Acquisition, the systems that monitor and control field equipment such as compressors, pumps, and meters.
• MetaSCADA Bifrost’s term for the layer of people, process, and technology that connects SCADA data to the rest of the enterprise, distinct from SCADA itself.
• ETL Extract, Transform, Load, the general category of tooling used to move and reshape data between systems; Bifrost started as an ETL company before expanding into MetaSCADA.
• OPC A family of industrial communication standards used to move data out of control systems; referenced as one of the “best effort” approaches operators have historically used.
• Historian A database, such as the PI System, purpose-built to store and retrieve time-series process data.
• MQTT A lightweight messaging protocol commonly requested by customers for publishing SCADA data to other systems.
• Modbus An older industrial communication protocol with limited poll rates, cited as a source of scaling problems when pulling data from many devices.
• Amazon S3 Cloud object storage mentioned as part of a growing trend toward file-based data approaches driven by storage cost concerns.
• Digital twin A virtual representation of physical assets used for analytics and optimization, cited as one of the drivers pushing operators to demand more complete and timely data.
• Artificial lift Equipment and methods (such as plunger lift) used to help produce fluids from a well; discussed as a case where missing or low-quality data leads to bad automated decisions.
• Universal namespace A single, consistent naming convention for data points across systems; the problem Bifrost’s Forge tool is designed to solve by mapping many legacy tag names to a common set of keywords.
• Forge Bifrost’s tool for mapping disparate tag and point names from different SCADA and historian systems into a common, uniform namespace.
• Flow Bifrost’s primary data integration and delivery solution, described in the episode as the tool that moves clean data around the enterprise.
• Alarm rationalization The process of reviewing and standardizing alarm configurations, cited as a downstream activity that becomes much easier once data is organized under a clean, consistent set of identifiers.

Real-Time Data Management Full Episode Transcript

Announcer: Welcome to the Pipeliners Podcast, episode 454, sponsored by Flowstate Solutions, providers of pipeline leak detection software built to remove barriers and empower operators. Flowstate helps teams detect anomalies, reduce false alarms, and improve response with practical tools designed for diverse pipeline operations. Learn more at FlowstateSolutions.ai.

The Pipeliners Podcast, where professionals, Bubba geeks, and industry insiders share their knowledge and experience about technology projects and pipeline operations. And now your host, Russell Treat.

Russell Treat: Thanks for listening to the Pipeliners Podcast. I appreciate you taking the time, and to show that appreciation, we give away a customized Yeti tumbler to one listener each episode. This week our winner is Brian Swindle with FIMSA. Congratulations, Brian, your Yeti is on its way. To learn how you can win this prize, stick around till the end of the episode.

This week we speak with Geoff Daily and Aaron Knabb with Bifrost, and we talk about real-time data management for the enterprise.

Hello, Geoff. Aaron, welcome to the Pipeliners Podcast.

Geoff Daily: Great to be here.

Aaron Knabb: Yeah, thanks for having us.

Russell Treat: As I always do, I’d like to start with a quick set of introductions. So if you guys wouldn’t mind, tell us a little bit about who you are, what you do, and how you got there. Geoff, why don’t you go first?

Geoff Daily: Yeah, I’m Geoff Daily. I’m one of the owners of Bifrost, inside of Techneaux, which is an integrated group of systems integrators. I’m relatively new to the oil and gas industry, especially the midstream space, being in this space for only four years. There’s a lot of great history in this industry, but I joined Techneaux to help get our Bifrost unit off the ground, which we call the world’s first MetaSCADA company. We’ll talk a little more about that later.

Russell Treat: MetaSCADA. Okay, great. Aaron, same question, tell us a little about yourself and what you do.

Aaron Knabb: Yeah, my name is Aaron Knabb, and I’m also one of the owners of Bifrost. I helped found this group within Techneaux. I’ve been at Techneaux for about seven years now, and I come from a long background in enterprise software development across a multitude of industries. I manage the software engineering side of Bifrost, the coders, the QA processes, and our software stack, basically.

Russell Treat: Great. Well, I’ll have you guys come on and talk about getting data out of SCADA and into the enterprise. I have a long history doing control systems work, so maybe it’d help to talk a bit about the history there, how have we done that historically? I think that’s evolved a lot in the years I’ve been in the business.

Geoff Daily: Yeah, at a high level, what people have generally tried is a variety of best-effort solutions, is the way we think about it. You have OPC in a variety of different flavors, where people are writing one-off scripts. You have utilities often offered by the data platforms themselves, and some more generic ETL platforms, ETL stands for extract, transform, load, that you’d find in the marketplace, but they aren’t necessarily geared to the unique challenges of the SCADA world, which is a very dynamic world from a data perspective. Aaron’s got more context he can add.

Aaron Knabb: Yeah, the fact is, in a lot of the SCADA world we’re dealing with older software platforms that might not have the most modern connections to the cloud and data world. We’re also dealing with a number of different protocols and unique data streams, in particular a really large amount of heavy time-series data that’s tricky to transfer in a secure and stable way, when we’re talking about billions and trillions of records being moved around large enterprises. We’ve seen a number of different approaches, like what Geoff mentioned, everything from one-off scripts to different broker approaches and different sets of APIs. We’ve seen just about all of it here at Techneaux, and that was the bedrock on which we started Bifrost.

Russell Treat: So one of the common conversations I get into when we’re talking about hooking our tools up to SCADA is, why don’t you just pull the data from the historian? Why don’t you just pull it from PI? So I’ll ask that question, why don’t you just pull it from PI?

Aaron Knabb: That’s an excellent question. The first problem some of our customers run into is, well, how do you get the data to PI to begin with? How do you get it to the historian in a way where the data is of extremely high quality, because we’re seeing more and more of our customers needing that data to be darn near perfect, due to the AI platforms they’re interrogating the data with, plus data science applications and many other reporting applications and so on.

One of the main challenges is that this is an extremely large amount of data, and any synchronization process that moves data from one system to another has to have a lot of intelligence built in to handle all the edge cases, network outages, comms outages, SCADA hiccups, as well as possibly design changes on the historian side. Put all that together, and what seems like a simple problem quickly becomes very complicated.

Geoff Daily: Yeah, because what we often see is every platform has limits, whether it’s a SCADA platform, a historian, a broker, whatever. And when you’re operating at the scale of oil and gas, with the performance requirements that are often expected, and that bar keeps getting raised every year, you really can’t just throw it over the fence and hope the data makes it. It’s just not good enough anymore.

Russell Treat: Yeah, there’s a lot bound up in that. Historically there was a conversation about “good enough,” was data with holes in it better than no data? And now, because of things like digital twins, advanced analytics, and real-time optimization, all these things around the data being accurate, complete, and timely, managing latency, which can be a huge issue, all of that matters.

Geoff Daily: Absolutely. And on top of that, the amount of data we’re starting to talk about now, especially in some of these large enterprises, we’ve got ten of the top twenty-five upstream and midstream oil and gas companies as customers of ours, and the amount of data they’re moving, there are real cost concerns. If you just haphazardly move all the data everywhere, that cascades through your IT budget in a lot of painful ways. We’ve been able to, well, we’ll talk more about what we actually deliver, but being able to have the control to decide what data is valuable and make sure it actually gets to where it needs to go, and then have appropriate control over the less valuable stuff as well.

Russell Treat: Yeah, so it’s not as simple as “I have a pressure in a time series.” It’s more about, well, which pressure is this, how frequently do I need it, how accurately do I need it, and who needs it?

Aaron Knabb: Yeah, especially with the way a lot of our customers use their data, something as simple as a little bit of missing data can lead to, for example, models being trained incorrectly, or analysis being wrong, where you come up with the wrong conclusion. We see a lot of our customers dealing with this with artificial lift data, tubing and casing data and those sorts of things, where if some of it is missing, they draw the wrong conclusion, and their automated changes back to those systems end up incorrect. They don’t get the total result they were expecting, all because the data has to be extremely high quality.

Russell Treat: Yeah, when you talk about artificial lift, there’s a wide gamut of that, and each type has its own specialized algorithms. Things like plunger lift need very high concentration data, particularly while the plunger is moving. I don’t need data when it’s not moving, but I need a lot of data when it is. So for that application, I don’t want to store all that data when it’s not moving, but I do want it when it is, and then there’s a whole set of other issues around how you properly manage time-series data.

Aaron Knabb: Yeah, and in some cases, especially with artificial lift data, we’ve seen valuable parts of that data sitting in device transactions that aren’t even mapped into the SCADA system. So you need a solution that can interrogate that device transactional data to pull out the pieces critical for the customer’s analysis. And in many cases, how you extract that device data differs per device manufacturer and the application running on it. Again, the problem quickly becomes very complex.

Russell Treat: Yeah, and if you’re relying on things like Modbus to bring data across, with the limitation of poll rates and all that, it gets even more complicated.

Geoff Daily: We’ve encountered some horror stories with customers where they were using a utility, that was the thing people would use, but because of limits on how many tags it could handle, they’d have to run a hundred of them concurrently. Talk about a liability, you’ve got a hundred little scripts running as fast as they can.

Aaron Knabb: Yeah, it creates a real unfortunate needle-in-a-haystack situation.

Geoff Daily: And that kind of thing can be driven by legacy software or legacy devices in the field. I think this is actually something material to this conversation, it’s fairly easy to build something that works for a single device in the field. It’s quite complex to build something that works for ten thousand devices in the field. It’s like building a tool shed versus building a skyscraper.

Russell Treat: Right, and the level of engineering and architecture required is different for those two things.

Aaron Knabb: Same thing with building SCADA ETL for one site with a thousand tags versus ten sites with millions of tags, completely different set of challenges you have to deal with.

Russell Treat: Exactly.

Geoff Daily: We’ve seen all manner of device strangeness. Missing date-time components, where you have to build in strange intelligence to try to assess what date-time the device is actually feeding back to you. And it turns out that in time-series data, time is incredibly important, it needs to be extremely accurate.

Aaron Knabb: Yes. Time zone differences, too, are we talking device time, server time, real time? We’ve seen it all. In some cases the devices are set up and configured properly, and in some cases the device was configured a long time ago by someone who isn’t even with the customer anymore, because it came through an acquisition, and nobody’s sure how it got that way. But it’s still got to work.

Russell Treat: Right, and if I’m pulling data out of something like a compressor or a pump, and there’s a clock inside the device, the level of intentionality around managing that time is very different than if I’m managing a flow computer. People have processes where they go check the clocks on flow computers and update them, because it’s material to getting a good mass balance or a good total measurement. Whereas with a pump or compressor, historically, if it’s about right, that’s good enough. Now you’re starting to feed that data into a complex algorithm where you’re trying to look at how gas is moving through a system and optimize it, now time matters everywhere, down to the millisecond.

Aaron Knabb: Yeah, it’s interesting, with a lot of our customers, our approach is to be really neutral. We deliver the data as is. And because we don’t take a side on what should be done with the data or which platforms it should go to, that’s up to the customer, that neutrality sometimes reveals interesting things about their infrastructure. We see time drift on certain devices, where they slowly migrate off of time, and things like that, and we report the data accurately and honestly. Then there are questions inside our customers’ organizations, does that mean we fix the device, or do we modify the data coming out of it? All these interesting conversations come up.

Russell Treat: Yeah, I’m right there with you. So you guys use a term called “MetaSCADA.” What is MetaSCADA? What do you mean when you’re talking about that?

Geoff Daily: It’s only a term we’ve been using for about the last year. We’ve been in the market for about four years. We started off thinking of ourselves as an ETL company, extract, transform, load, as I mentioned earlier. But that doesn’t capture the full set of challenges that large-scale SCADA users face in getting their SCADA data to the rest of the enterprise and back again. So we’ve defined MetaSCADA as the term for the layer of people, process, and technology that connects SCADA data to the enterprise. Typically it’s scripts, utilities, generic platforms, whatever people have cobbled together. We believe we’re the first company to come in with a dedicated solution set specifically targeting what we call “the briar patch,” all the gnarly challenges associated with getting clean, reliable data into and out of SCADA systems for all the other use cases you might want that data for.

Russell Treat: Yeah.

Geoff Daily: In practice, once you get inside these larger enterprises, their needs can’t be simplified down to one or two data streams. In many cases there are hundreds of data streams going to different reporting platforms, different geospatial regions, different AI platforms, different databases, different historians, brokers so they can publish out to different locations. It’s all over the place. We’ve tried to build a total solution where the customer can have whatever infrastructure makes sense for them, and we deploy a complete solution with all the support necessary to keep that data flowing. That’s where “going to enterprise” becomes really practical, it means a lot of data pipes going all over the place, and they all have to have incredibly high uptime, because our customers depend on it to make critical decisions.

Russell Treat: So how is what you’re doing different from some of the messaging tools, like TIBCO or Splunk?

Geoff Daily: There are a few ways to describe that, but the first is what I mentioned before, we try to stay really neutral in how we connect customer data. That means the customer sets the requirements for how their internal data infrastructure works. We’re extremely flexible. Our technology can sit entirely on-prem, it doesn’t have to be cloud-hosted, so the customer’s data never has to leave their firewalls if they don’t want it to. That’s extremely important to a lot of our customers, for security and proprietary-information reasons. Because we deploy our software and move the data the way our customers want it done, we don’t ask them to make those compromises. That’s the first layer of differentiation.

When it comes to protocols and applications, for example, one protocol we get a lot of requests for is MQTT. We’re very agnostic to that, and happy to publish data out to that protocol, or to a web services endpoint, or whatever the customer wants. We’re seeing more customers use file-based approaches too, because of storage costs, for example, Amazon’s S3. Really, it all comes down to whatever the customer needs it to be, and we stay extremely flexible. Then whatever gets deployed in the customer’s environment, we support twenty-four seven to make sure everything keeps running. We have a lot of software intelligence that keeps everything aware of its environment, so the whole approach is very fault-tolerant, because network infrastructure and compute resources go down, that’s just part of the real world. Our customers aren’t willing to accept “there was an issue, someone will get to it tomorrow.” It has to work automatically, because there’s just too much data to handle with a manual-labor approach. That’s one of the lessons we learned when we started Bifrost, and it shaped how we built it.

Aaron Knabb: And I’d add, the main thing I’d say is, most of the other tools out there require someone on your team, or a contractor you hire, to actually go use them. What we’re selling is a complete, integrated solution. Our integrators handle every aspect of setup, support, and monitoring. It’s not just a tool to go figure out the problem, our team figures out the problem, and that’s part of the overall value proposition.

Russell Treat: So how does this manifest? Does this look like an enterprise application that configures and monitors every source and endpoint of data? Is that what it looks like in practice?

Aaron Knabb: Yeah, it’s similar to that. Inside our technology, what we’ve essentially built is an intelligent workflow platform. By workflow, I mean we set up a set of rules, a set of steps that define how the data gets moved from A to B, and any changes that might occur during that transfer, plus a million little configuration settings about timing, efficiency, throughput, and so on. As Geoff mentioned, our integration team sets all that up and configures it, and then our technology platform runs constantly in the background, absorbing whatever nuances occur in the data, exceptions, issues, outages, and so on. It’s really a combination of automated solutions and our integration team making adjustments and tweaks, constantly tuning it for the customer’s needs.

Russell Treat: Okay. So, not having actually seen the tool, one of the things that comes up for me is, say I’m a large pipeline company and I have a whole universe of data that I’m collecting, analyzing, transforming, and sending somewhere else, and then doing that again, and again, and again. Historically, what I’d do is have people responsible for each of those data connections, without much attention to how much resources they’re using, network bandwidth, communications, storage, compute, all of that. What you’re really doing is saying, let’s turn this point problem into an enterprise problem.

Geoff Daily: Yeah, that’s a good way to put it. It’s one of the very first motivators for coming up with some of this. Our customers were coming back to us saying, look, we’ve got so much manual labor going into maintaining all these disparate data streams, typically set up with different scripts written by different people who may or may not still be with the organization. It comes down to a large amount of labor cost, and the total solution that produces frequently results in more compute use and less stability, because we’re highly incentivized to keep everything running in a clean, automated, efficient manner, it benefits us and our customers. It’s a slightly different approach, and our customers really seem to value that.

Russell Treat: Yeah, I think what you said about point versus enterprise is a very good way to put it, because the unfortunate reality is there’s a lot of unmanaged liability in oil and gas companies at that layer. Every oil and gas company has a MetaSCADA layer, whether they’re managing it or acknowledging it or not.

Geoff Daily: Right, that’s kind of our thesis. And if you’re managing it with a bunch of random scripts and utilities, and some guy named Bob who may not have anything written down, we’ve heard some horror stories where that guy Bob left, and everyone went, “Oh no, does anyone have any idea how any of this works?” And they don’t, necessarily. And these are like tank-gauge data flows, we’re not talking about little side stuff, this is the heartbeat of these organizations. We believe this part of the industry needed a different level of solution, and that’s what we’ve been trying to bring to market.

Russell Treat: Yeah, I’d think too that there’s some opportunity, particularly as you move more toward the gathering side of the business, where a company has grown through acquisition, there’s very little harmonization of the automation at the field-asset level. There’s a real opportunity to normalize all of that, so I can manage things like alarm rationalization, log entries, and those kinds of downstream activities against a clean set of identifiers. You might like this, the term I’d coin for it is “MetaSCADA systems,” right?

Geoff Daily: I’ll definitely co-opt that phrase. I’ll make that one mine.

Russell Treat: Excellent. Go for it.

Geoff Daily: That’s what I’m saying, I know exactly what that looks like. Years ago, a good friend of mine brought me in to do some work around rationalization, and I started getting under the covers with their SCADA system, looking at their tags, and I had to sit down with them and say, listen, until you completely re-engineer your SCADA system, and I actually know what the real values are, I can’t help you with rationalization. There’s nothing I can do for you, because this is a train wreck. There’s so much dead wood in this system, I can’t tell what’s real, and what site A calls something isn’t the same as what site B calls it. The only way you’re going to get a handle on this is to start from the beginning.

Aaron Knabb: And it’s tough, because a lot of our customers, we’re fortunate that our customers tend to be overrepresented with folks who really care about what they’re doing, who really want it to work and understand how important all this is. But it’s been a difficult world for a lot of people, especially if you’re a company doing a lot of acquisitions, nothing’s nailed down, things are changing underneath your feet all the time, and it’s all about get it up, get it on, get it flowing. Especially if the whole strategy is to acquire, improve, and then sell, there’s a limit to any long-term improvements, because the whole point is to flip it. So you have a lot of good, hard-working people just with their fingers in the dam.

Russell Treat: Yeah, that’s a reality. In the case I mentioned, it was a situation where a company had bought another company out of near-bankruptcy, and they got into something they didn’t realize what they were getting into. Sometimes you jump in a pit to dig a little, and you find out it’s half full of snakes, what are you going to do, try to get out of the pit?

Aaron Knabb: Yep. I think what we see with some of our customers, on a really practical human level, is that we can reduce a lot of stress. No one wants to wake up at 2 a.m. because a script stopped moving data, and now someone’s boss is mad because he can’t do his quarterly report. On a human level, having to maintain uptime all the time can be very stressful, and on that practical side, we do a lot to help our customers, we see a lot of stress reduction, frankly.

Russell Treat: Here’s a key question I want to ask. All these things we’re talking about, moving data around, the automation systems, the scripts, all that infrastructure, has to be updated. They roll out Windows patches, shut something down and turn it back on, modify a network path, change the rules on a firewall, all the things they have to do for care and feeding of the system. How do you deal with it when they make changes? Do they notify you?

Aaron Knabb: Not typically. Sometimes they do, but usually not, to handle that, because we don’t like getting called at 2 a.m. either. What we’ve built is what we call a resource-awareness system inside our technology. Our tech knows all the different systems it’s connected to and the health of each one. It can automatically detect downtime, a server going down for a patch window, for example, and the software will automatically suspend that data workflow and resume it once the resource becomes available again. But to hit your question specifically, we also provide notifications, both to our support team and directly to customers, “hey, this server just went down,” or “it just came back up,” through a series of KPIs delivered via email and other systems. A large amount of our software development time is spent building systems like that, which provide a lot of self-healing and awareness. And the practical answer is, a lot of the time we’re aware of infrastructure issues inside our customers’ environments before the customer is, because we’re connected to just about everything there, we’ll see a database go down and know they’ll figure it out soon, but usually we’re one of the first to know.

The other part of that answer is the human side, our integrators aren’t just monitoring and resolving issues, they’re meeting weekly, depending on the customer’s requirements, with the IT and data teams inside the customer’s organization. So they’re aware of the customer’s workflows and changes, and they know who to call if something’s broken, effectively part of the team.

Russell Treat: Exactly.

Aaron Knabb: That makes a huge difference. In our opinion, it was the only way to actually solve this problem in a sustainable way, because there are so many edge-case, in-the-weeds things that pop up regularly. You need a centralized team that’s very experienced doing this kind of work and can move fast.

Russell Treat: Yeah, interesting. Well, we’re coming to the end of our time, guys. What would you say to a pipeline operator who wanted to look into this? Where do you start? How does that conversation begin?

Geoff Daily: It’s pretty straightforward, it’s just starting to understand what critical integrations you have that aren’t currently meeting your needs, either because of reliability issues and data gaps, or because of edge-case, gnarly stuff we’re not afraid of. If you’ve got something that whatever internal team you’re using has been struggling with for a while, whichever thing is getting you woken up the most in the middle of the night, that’s exactly right, let’s worry about that one, and then we’ll get to the next one in time.

Aaron Knabb: And depending on urgency, we’ve literally gone from a customer asking for something to it being in production within twenty-four hours, because there was an issue with a pipeline at a midstream company. I’m not going to say it was life or death, but it was high stakes, and our team said, okay, we understand this is important, we’re going to jump on it. Other times, this process can take months, because you have a lot of stakeholders to manage, and customers don’t always know the full scope of their requirements. There’s a full range of realities on that front.

Russell Treat: Well, I think my takeaway from this, and actually one of the reasons I wanted to get you on the podcast, is that I don’t work in this domain every day anymore, and it doesn’t take very long for your information to become dated. You fall behind pretty quickly if you’re not in it every day, because this stuff moves fast. But I wanted to get you on because what you’re doing solves what I know to be a very big, long-term problem that a lot of people have had for a long time. I think what you’re doing is really interesting, and I wish you all the success.

For the listeners, we’ll do what we always do, we’ll link up Geoff and Aaron on the website, drop their contact information, and link some information in the show notes about Bifrost and Techneaux. If you have questions, reach out to Aaron or Geoff, I’m sure they’d love to talk to you.

Aaron Knabb: Absolutely. Thanks so much for this opportunity, Russell. It was really a pleasure.

Russell Treat: Thank you. I hope you enjoyed this week’s episode of the Pipeliners Podcast and our conversation with Geoff and Aaron. Just a reminder, to register to win our customized Pipeliners Podcast Yeti tumbler, visit PipelinePodcastNetwork.com and enter the drawing. If you have ideas, questions, or topics you’d be interested in, or if you’d like to be a guest, let me know on the Contact Us page at PipelinePodcastNetwork.com, or reach out to me on LinkedIn. Thanks for listening, I’ll talk to you next week.