This week’s Pipeliners Podcast episode features first-time guest Aron Semle of HighByte discussing the application of IIoT, MQTT, Sparkplug B, and the Universal Namespace to the pipeline industry.

In this episode, you will learn about the latest IIoT technology available for use in pipeline industry, how IIoT technology is cutting days/weeks/months of effort down to minutes, the capabilities to structure data all the way to remote devices, the importance of the universal namespace to unify real-time data, and many more exciting technological developments that can simplify complex tasks for pipeliners.

IIoT for Pipeline Operations: Show Notes, Links, and Insider Terms

• Aron Semle is the Chief Technology Officer at HighByte. Connect with Aron on LinkedIn.
  • HighByte is an industrial software development company that builds solutions that address the data architecture and integration challenges created by Industry 4.0.
  • Read Aron’s recent blog, “New use cases: HighByte Intelligence Hub version 1.4 is here.”
• IIoT (Industrial Internet of Things) is industrialized devices suited for creating data, connectivity, data delivery, and consumption. This term encompasses sensors, edge computers, controllers, communication devices, PC’s, HMI’s, etc.
• Internet 4.0 (a/k/a Fourth Industrial Revolution) refers to the modern connection of people, systems, and devices as part of the Internet of Things (IoT) and Industrial Internet of Things (IIoT).
• Kepware is a software development business of PTC, Inc. Kepware provides a portfolio of software solutions to help businesses connect diverse automation devices and software applications and enable the Industrial Internet of Things.
• EFM (Electronic Flow Meter) measures the amount of substance flowing in a pipeline and performs other calculations that are communicated back to the system.
• OPC (Open Platform Communications) is a data transfer standard for communicating device-level data between two locations, often between the field and the SCADA/HMI system. OPC allows many different programs to communicate with industrial hardware devices such as PLCs. The original system was dependent on MS Windows before shifting to open platform.
  • Fisher ROC is a protocol network used to connect Emerson and Fisher flow computers and devices to client applications, including EFM, HMI, SCADA, Historian, MES, ERP, and countless custom applications.
  • ABB Totalflow uses SCADA software that is purposefully designed for oil and gas operations to deliver first-rate automation. This includes maps, smart-screen templates, on-screen analysis tools, real-time and historical graphic trends, and reports for managing multiple aspects of the system.
• PLCs (Programmable Logic Controllers) are programmable devices placed in the field that take action when certain conditions are met in a pipeline program.
  • Allen Bradley controllers and pump stations are stand-alone, multi-pump PLPC controllers.
    • ControlLogix is a PLC that integrates with the Allen Bradley devices with historians, HMIs, and other OPC-enabled applications or devices without the need for any third party applications.
• LACT unit (Lease Automatic Custody Transfer unit) measures the net volume and quality of liquid hydrocarbons.
• SCADA (Supervisory Control and Data Acquisition) is a system of software and technology that allows pipeliners to control processes locally or at remote location. SCADA breaks down into two key functions: supervisory control and data acquisition. Included is managing the field, communication, and control room technology components that send and receive valuable data, allowing users to respond to the data.
  • RTUs (Remote Telemetry Units) are electronic devices placed in the field. RTUs enable remote automation by communicating data back to the facility and taking specific action after receiving input from the facility.
• Edge Communications is a method of building out the architecture for structured communication from edge devices in the field to a host server using connectivity to transmit the data.
  • Modbus is an older protocol that enables communication among many devices connected to the same network. The drawback is delays in the communication, oftentimes creating timestamp discrepancies.
  • Poll Response only sends data if requested by the host. This creates limitations because you may need to wait up to 15 minutes for the full data package to be received.
  • Publish-Subscribe protocol is a form of edge communications that allows edge-of-network devices to publish to a broker. Clients connect to this broker, which then mediates communication between the two devices.
    • MQTT (Message Queuing Telemetry Transport) is a publish-subscribe protocol that allows data to move quickly and securely through the system and does not bog down the system with unnecessary requests.
      • Sparkplug B uses a specification for MQTT enabled devices and applications to send and receive data. Sparkplug B enables optimizes the device lifecycle state and ensures data integrity.
• Universal Namespace (UNS) is the attempt to create one source of truth for data that is understood, adopted, and followed across the operation.
• SQL (Structured Query Language) is a standard code language that is used in database programming and queries.
  • Microsoft SQL Server is a relational database management system developed by Microsoft. As a database server, it is a software product with the primary function of storing and retrieving data as requested by other software applications — which may run either on the same computer or on another computer across a network.
• JSON (JavaScript Object Notation) is a data-interchange format that supports the connection between humans and machines. Users can read and write in this format and machines can parse the scripts.
• Python is an interpreted, high-level, and general-purpose programming language.
• FLOWCAL is an oil and gas measurement software platform that is used by operators to measure the product flowing through pipelines.
  • CFX is a specific data file format used by FLOWCAL that is encrypted to maintain the integrity of the data.
• Google Protocol Buffers is Google’s language-neutral, platform-neutral, extensible mechanism for serializing structured data.
• Remote node is a terminal or computer located apart from the main system network.
• Ignition IIoT is a robust IIoT platform with full-featured SCADA functionalities built into the platform.
  • Ignition Edge IIoT turns field devices into MQTT-enabled edge gateways that work with Ignition IIoT and other common IIoT platforms.
    • OSIsoft is a software tool that connects to the MQTT protocol through Sparkplug B.
    • Canary is a software tool that can define data from Ignition and other platforms.
• Amazon Kinesis is a real-time data streaming service that continuously captures large volumes of data per second.
• AWS IoT Core enables users to connect remote devices to the AWS cloud without the need to manage servers.
• LoRaWAN is a non-cellular LPWAN technology based on open design by Semtech.
• Leak Detection is the process of monitoring, diagnosing, and addressing a leak in a pipeline to mitigate risks.

IIoT for Pipeline Operations: Full Episode Transcript

Russel Treat:  Welcome to the Pipeliners Podcast, episode 183, sponsored by P.I. Confluence, providing software and implementation expertise for pipeline program governance applied to operations, Pipeline Safety Management, and compliance, using process management software to connect program to implementation. Find out more about P.I. Confluence at piconfluence.com.

[background music]

Announcer:  The Pipeliners Podcast where professionals, Bubba geeks, and industry insiders share their knowledge and experience about technology, projects, and pipeline operations. Now, your host, Russel Treat.

Russel:  Thanks for listening to the Pipeliners Podcast. I appreciate you taking the time, and to show the appreciation, we give away a customized YETI tumbler to one listener each episode. This week our winner is Aaron Martinez with Marathon Pipeline. Congratulations, Aaron. Your YETI is on its way. To learn how you can win this signature prize, stick around till the end of the episode.

This week, I warn you we’re going to get a bit geeky. Aron Semle, with HighByte, is joining us, and we’re going to talk about Industrial Internet of things, MQTT, Sparkplug B, and the universal namespace.

Aron, welcome to the Pipeliners Podcast.

Aron Semle:  Thanks, Russel. Pleasure to be here.

Russel:  Really good to have you. This is going to be fun for me because Aron and I go back a ways with the same group of folks that have been doing industrial communication software for a few decades. We have been swimming in the same geek-filled waters. This will be your friendly nerd excursion right here.

Aron:  That’s right. I remember the first, that must have been 10 years ago now when you first came up to Portland, Maine, when I was at Kepware. You came in and were like, “Hey, you should look at this EFM space.” We were like we couldn’t even spell it, EFM, trying to figure out what that was, and yeah.

Russel:  [laughs] Yes, we’ve come a long way. I remember going up there, and I had on a wide-brim fedora. It was snowing, so it was to keep my head warm and keep the snow off my glasses. Somebody went back to Steve Sponseller and said, “Hey, there’s some dude at the door in a cowboy hat. I think he’s here to see you.”

Aron:  [laughs] In January. What’s he doing?

Russel:  I’m like this is not a cowboy hat. I left my cowboy hat at home. This is just a hat.

Aron:  [laughs] You want to see a cowboy hat.

Russel:  We’re getting way off in the weeds. Aron, I asked you to come on to talk about what you guys are doing over there at HighByte. Maybe you could tell me a little bit about your background and what you do at HighByte, and then we’ll talk a little bit about what HighByte is and all of that.

Aron:  I came out of school. I’m from Maine. Lived in Maine. Maine boy through and through. I went to school at UMaine Orono, computer engineer. Got a job in Portland, Maine, which is one of our bigger cities for Kepware, which is where I got into oil and gas.

We were doing driver connectivity, communications. Kepware really started in discreet manufacturing, OPC servers, and all that. It followed the PLCs. We had Allen Bradley controllers and pump stations. The next thing you know we were in oil and gas, fracking, and the whole nine yards.

When I was there, probably towards the end of my tenure there, then I went to PTC. Then I jumped to my own start-up, and now I’m CTO at HighByte. When I was there, we were just starting to do this cloud thing where people were like “I got this cloud IoT platform, can you get the industrial data up into it?”

We did the simplest thing, which was to take all these tag data points and just stream them up to the cloud with tag names and a value. It worked. The data landed in the cloud, and we thought we were done.

Turns out a few years later as the market has matured, when you just take tag data points that has some cryptic name and a value and throw it up in a big database in the cloud, you have to do a lot of work to put context around that. You end up with this mess of data.

In SCADA, we’re all familiar with Modbus mappings and all the junk we have to deal with. If you don’t clean that up before it gets to the cloud, now you’re dealing with that in the cloud, and you’re paying AWS or Azure.

Russel:  Oh God, I’m going to show my age here, but this reminds me very much of when relational databases were first coming out. Back before relational databases, databases were either done in DB2 on an IBM mainframe or in something equally as arcane in some kind of UNIX mini computer.

The database structures were really arcane, and very limited, and very unique to that particular box and whatever the software application was. Moving data from application A to application B was a nightmare.

What we find ourselves in with this whole IoT thing, the Internet of things, is that we’re taking all this stuff and we’re getting under the covers, if you will, around all the data, all the way down to the tag names and their full enumeration, all of the stuff you got, what it came from. This PLC in this format, and here is the formatted ASCII word, and all of that kind of super-geeky, data in the weeds stuff and just taking that data and throwing it up into the cloud, and all these guys that are cloud guys, they’re IT guys. They think in databases and things that are organized and rationalized. They see all this and they go “Okay, I got a whole bunch of data here, but so what.”

Aron:  [laughs] Exactly.

Russel:  Your point about context, it’s really to the point because what people really care about is, and context in the automation world is interesting because some people will say it’s pressure, and that’s the context.

No. What kind of pressure is it? Is it a suction pressure? Is it a discharge pressure? Is it a pipeline pressure? Is it a meter pressure? Is it a pump internal casing pressure? What kind of pressure is it? That’s context.

Aron:  What are the units of measure and all that? Historically, we’ve done a really good job inside of SCADA. If you look at a SCADA system, it’s going to model the data. You can do templates, and you can create multiple screens. That modeling, historically, has ended there. In terms of the cloud systems and all that, those data models from SCADA don’t go up into the cloud. The raw data does.

Russel:  They’re not well structured enough. What happens is I build a template for presenting data, and then I modify the template to deal with all of the field device-specific differences. Right?

Aron:  Yeah, exactly.

Russel:  Again, a specific illustration of that is you think about a three-way valve that you use in any LACT unit. You got a three-way valve, and you’re flowing the oil, and if a sensor detects high water or high bs&w [basic sediment and water], it throws the three-way valve. That’s all pretty simple when you get it to the graphic and illustrate it.

I could probably talk about a half-dozen different ways to implement the automation in the PLC around that three-way valve.

Aron:  The ladder logic and everything.

Russel:  Is it an integer and the position is a one, two, three? Is it a series of digitals, and on, and on, and on? If it’s one, two, three, what is position one, what is position two, what is position three?

Which gets to what is HighByte. What is HighByte? What does HighByte do for you if you’re doing industrial automation, or in my world, if you’re doing pipeline automation?

Aron:  To your analogy that, it’s almost like the assembly language. The PLC is like the assembly language of our space. You don’t want to push that up to the cloud. No one in the cloud wants to understand that the on-state can be a string, or a bull, or whatever.

What we need is a data modeling layer to abstract away the specifics of the sites, take a pump station or wherever. By the time we shift that data up to other systems, and I say cloud, this could be a maintenance system. It could be an ERP system, whatever.

Russel:  It could be on-premise or whatever. It’s just a data structure.

Aron:  It’s structured. All of my pumps look like this. Under the seams, we had three different guys program them, and the PLCs look totally different, but by the time it lands in AWS, or Azure, or my cloud system, they all look the same. I’ve abstracted away that difference.

What HighByte is is it’s a thin application layer in there for data modeling to be able to create a standard model across your enterprise of your different assets, or process, or whatever to abstract away the specifics of the site or what’s going on in the PLC.

Russel:  Again, I have to go back in history and date myself, but to me, again, it’s very similar to what happened as we were moving from these old mainframe databases to relational databases, things like what’s now Microsoft SQL server, and Oracle, and so forth.

It’s like everybody understands SQL. Pretty much everybody has some exposure to SQL and how to query that kind of database. Those data structures are pretty self-described. I know that this is an invoice and here’s all the things that go on an invoice and such.

What HighByte does is the same thing, but for real-time data, for industrial automation data.

Aron:  Yeah, exactly. There’s different protocols, but the primary one today when you get up in the cloud systems is JSON formatted data. You could look at it. It’s a text-based format of your data structure. It’s very human understandable, but you can also program against it really easily in basically any language.

Russel:  The value of that is everybody talks about big data and data analytics. Data analytics requires as a prerequisite well-structured data.

Aron:  You nailed it.

Russel:  I can feed JSON into pretty much any analytics engine, or I could build my own using Python, and that is relatively straightforward.

Aron:  Yeah, absolutely.

Russel:  If I’ve got to get that data out of the SCADA system, the level of difficulty is probably a couple of orders of magnitude higher.

Aron:  Absolutely. It’s really simple stuff like I’ve got a pump, and it’s got these three attributes. Traditional SCADA’s only going to send you the data if it changes kind of thing, and it has a quality on each and a timestamp on each value. It doesn’t treat the pump as a structure.

If you give me that data all ad-hoc so as different values change, it’s coming up to the cloud, each one has its own timestamp and its own quality, and you ask me as an engineer to feed that into an ML [Machine Learning] system, I’ve got to do this whole front end pipeline where I try to stitch together the data across different timestamps.

Russel:  Aron, you’re talking about a manufacturing model. In a manufacturing model, most of the protocols are chain-centric, and they have fairly good timestamps on them. That is not the case in a pipeline model.

In a pipeline model, most of the polling, even today, is poll response. I get a data set at a time-stamped usually in the server — not at the remote — at the time that the communication comes back to the server, which is some delay, maybe milliseconds, maybe a second, but some delay. I get all the data, whether it has changed or not. I feed it to a historian and clean it up to try and get rid of the changes. That’s a whole different problem from a contextualized, meaningful, “feed it to an analytics engine” standpoint.

Aron:  They’re two different data sets almost.

Russel:  I’m going to get a lot of data. In SCADA systems, because I poll once every minute, once every 5 minutes, once every 15 minutes, whatever it is, I don’t see all the changes between polls. I just see here’s a snapshot. Here’s a snapshot.

Aron:  You can miss the transients.

Russel:  The value of something like HighByte for that is I normalize the data, build context on it, but I still am not really getting where I need to go in order to do what you’re talking about, which is more common on the plant floor, which is I’m seeing each thing as it changes. I might not have context around it. Right?

Aron:  Right.

Russel:  It’s a slightly different problem. How does HighByte go about creating a data structure for real-time data? How does that actually work? What are you doing?

Aron:  The first process is to model the data, so whatever your asset is like a pump station, define the attributes that you have — human-readable attributes. How would you describe it to somebody? Those are your attributes of your data model.

That model, you can create instances of it. For each pump station, you have an instance of the model. That’s where you do the wiring. You would wire up the OPC tags. Considering data’s coming from OPC, or ControlLogix, or Fisher ROC, or whatever, wire the tag data into that instance to be like “This is pump station one.” HighByte will pack, at some interval, we’ll consume that data, fill in the model, and send it up as one distinct unit to the endpoint. That’s the process.

Russel:  Would you say it’s reasonable to describe it as a bridge between the real-time communications and the data-consuming application?

Aron:  Yeah. Yep, definitely. It fits into this concept. I know we’ll get to the unified namespace where the unified namespace is this idea or concept that has really caught on.

It’s a very powerful concept that inside my organization I’m going to have this thing — this bucket — and inside that bucket is going to be all of my data, my real-time data, my transactional data in this kind of namespace. Anyone can come in and subscribe to different parts of that they’re interested in and can get it.

You get up and you pitch that to a manufacturing or SCADA, and everyone’s like fantastic. Why? One of the biggest problems we’ve always had is you can’t get access to the data. It’s all broken up. It’s in silos. You come up with a solution, say there’s this unified namespace concept.

Russel:  If you can’t connect to it, you can’t understand it.

Aron:  I’m going to put all your data in this thing, and you can just come in and subscribe and get it any time you want. Fantastic. In practice, what it’s turning into in the industry is it’s an MQTT broker. MQTT has the technology for publish-subscribe. Sparkplug B, which is a standard on MQTT, which we can talk about, is to publish data in a unified way, and then people can subscribe and read that out.

What HighByte is doing in that architecture… So, the way we think of the cloud as this unified namespace, currently we’re sitting on the edge of that, making sure that when you push data into the UNS, it’s not garbage data. It’s structured in a way that everyone agrees on, that they can consume and work with, so cleaning up that unified namespace.

Russel:  You just said a whole lot there. I’m going to try and decode a little bit of it. I see this in several steps. One thing is you have HighByte, which is structuring your data, so I’m going to define an overused word, but I’m going to define object. This is a pump of this type. I could be as specific as this is an ACME pump, model number xxx. Right?

Aron:  Yep. Absolutely.

Russel:  Then this other thing’s an ACME pump, model number, because really what we care about in the enterprise is the machines, the equipment. Right?

Aron:  Yeah.

Russel:  The other thing is when I’m going to do multiple instances and this is that pump, but with this RTU connected to it, and this is another pump, and I’m not getting it from the RTU. I’m getting it from the local SCADA system. This is another pump. You’re defining instances based on whatever the automation device is that’s collecting the data and making it available to HighByte.

Aron:  Yeah, exactly.

Russel:  From there, you’re making that data available to whomever wants it, SCADA, machinery analysis, economic analysis, whatever that is, you’re making that data available from there to anybody else who would be interested in it.

Aron:  Exactly. MQTT has a topic, which is like an address. You’ll publish that data in a specific format on that address, and anybody — it’s a one-to-many relationship — anybody can subscribe to that address and get that data. That’s very trivial.

Russel:  That’s one of the things that people don’t understand about why IIoT is such a big deal, or IIoT is such a big deal, is I’m taking… If I can move all the data on a narrow band remote network, MQTT, I’m going to move more data, so I’m going to get more relevant data. I’m going to get more concentrated data, and I’m going to get it over much less bandwidth. That’s the net outcome of using MQTT.

A lot of people are taking and they’re building devices that simply in the field pull the old, legacy protocol, Modbus, or whatever, and translate that to MQTT. In the field, I can pull Modbus and pull every 100 milliseconds.

Aron:  Looking for that data chain.

Russel:  Then I can put something that sits on top of that that’s watching that Modbus and says “Okay, that changed. Send it up.” “Okay, this changed. Send it up.” All of the addresses that are static, my valves, my names, all that kind of stuff, never get pushed up.

All the things that are dynamic, all my analog devices, my pressures, my temperatures, my flows, my accumulators, all of that gets pushed up based on configurations I make about if it changes less than a tenth of a PSI, I don’t care. If it changes less than a PSI, I don’t care, whatever that number is. Right?

Aron:  Yeah, exactly.

Russel:  Then you can filter the data and get a lot more bandwidth. Again, that’s just moving the data. I still have to take that MQTT feed and contextualize it.

Aron:  Exactly. MQTT’s generic enough you could send Modbus packets across it if you really wanted to, probably a bad idea because then you need a decoder of Modbus on the other side.

A great example is the EFM use case, the traditional use case of I’m going to go pull my Totalflow or Fisher ROC once a day. I’m going to send this request out at the central SCADA that has all the logic out on this Fisher ROC device. These are the addresses that I’m going to pull, all the Modbus registers…I go get this huge data set that bogs down my communications network, and a big part of the data I probably didn’t even need because I already had it.

Aron:  Exactly. This is me selfishly saying from the software engineer having written some EFM stuff, writing the logic to do those pulls, and all the mappings to convert to FLOWCAL, and all the other providers, it’s a pain.

Russel:  You’re preaching to the converted, man, right there.

Aron:  You get it. This idea that we’re going to use this unified namespace and Sparkplug B to distribute that intelligence to say I’m going to put a little intelligence device on the edge next to my Fisher ROC that’s going to pull it, you’re right at the edge.

The controls engineer that set that up knows the mappings. As you know, all that stuff is certified. Those mappings aren’t going to change willy nilly. It’s just not going to. I can put that intelligence at the edge, do all the mappings and conversion, and what comes upstream is the FLOWCAL ready data format through MQTT, like the data that’s almost ready to go. Like you said, I can optimize it.

Russel:  It’s really a little bit more complicated than that because what you’re going to do is you’re going to pull back upstream the things you need as they are created in the remote device in the field. As I get an hourly total, that hourly total goes back up. As I get an hourly average, that hourly average goes back up. Right?

Aron:  Yeah.

Russel:  It goes back up as it changes. If I change an orifice plate, when that orifice plate change is registered in the RTU, it flies back up. If the value doesn’t change, I don’t move it.

Aron:  Don’t send it.

Russel:  Right?

Aron:  Yeah.

Russel:  What I do at the back side, at the host, is I take all that stream of data and I assemble it into the format, the CFX, that the downstream system needs.

Aron:  Which is made infinitely easier by the fact that you’ve modeled and contextualized the data coming up from all your remote sites. You’re not dealing with these Enron Modbus data mappings and all the other garbage.

Russel:  That also takes us to Sparkplug B. Let’s talk about what is Sparkplug B. If you live in this space, if you’re doing work around oil and gas automation, you’re hearing a lot about MQTT and you’re hearing a lot about Sparkplug B. What is Sparkplug B?

Aron:  MQTT’s been around a long time, really lightweight protocol, publish-subscribe. We get that. What MQTT lacks is a data standard around it. Aside from being able to publish anything and anybody can subscribe to it, the actual context of the data and interactions, like rights, none of that is defined. You’d have to make that up.

Sparkplug B is a specification that was created specifically for SCADA to start to put those typical SCADA requirements around MQTT to make it usable out of the box.

Some of the main things it does is it defines the data payload. If you were to look inside, like I have an MTTFX client that I can subscribe to a broker, and it has a setting that says show me the data in Sparkplug format because it knows the format. If I hit that setting, I can look and read the data that’s coming in as is.

Also the Sparkplug data format is encoded in it’s called Google Protocol Buffers, which is a spec that came out of Google 10 plus years ago, but it’s really efficient at packing data over the wire. Sparkplug also optimizes the data across the wire to reduce it to a minimal form.

The other thing that Sparkplug does is it provides a standard around which devices can come online and offline. The concept is you can just plug a device in in the field, point it at the broker, and your SCADA system, whatever that is, if it’s Sparkplug-enabled like in Ignition, when that remote node publishes up data, it just appears in Ignition’s address space. You didn’t have to do anything. You didn’t have to put an IP address and poll. That’s magic. When you see that happen the first time, you’re like Holy Grail. This is awesome.

Russel:  I’ve seen that in some of the working group stuff that some folks are doing around Ignition. I’ve seen some of that kind of stuff where they’re auto elaborating the Sparkplug B into the SCADA system. You just hook up, and you say I got Sparkplug B, and all of a sudden here’s all my meters. Here’s all my meter data. Here’s all my real-time data. I’m like, “You just did in a minute what we used to spend months and multiple people doing and never get it right on the first attempt.”

Aron:  You’re like this is black magic.

Russel:  It’s like holy smokes.

Aron:  It’s incredible.

Russel:  That is wild. For people that are adding meters and dropping meters out of a SCADA system, that’s huge.

Aron:  Totally. It has birth and death certificates, so also if a site goes down, the SCADA system is notified of that immediately. As you know, that’s super important in SCADA. Traditional MQTT isn’t going to offer that kind of out-of-the-box capability.

Russel:  MQTT is, it’s basically if you think about a data package as a train, MQTT is the engine and the caboose. It knows what tracks to run, and what switches to hit, and where to go. That’s all MQTT is doing. Sparkplug B is everything about what’s in the railcars.

Aron:  That’s a great analogy.

Russel:  How does HighByte work with Sparkplug B?

Aron:  We support Sparkplug B as an input and an output. We could be at the edge, aggregating the data from the control system, converting that into a model, and publishing it up into Sparkplug where OSIsoft, or Canary, or Ignition, any Sparkplug-enabled system, would just appear in their address space like we were saying before, or we can also consume Sparkplug.

A lot of times we’ll be using cases where we’re connected to a broker that has Sparkplug-enabled data, but you want to get that out into AWS IoT Core to put into Kinesis to go do some analysis on it.

AWS or Azure isn’t going to support Sparkplug. Maybe eventually they will, but they don’t support it out of the box. We’ll convert Sparkplug to a JSON format and shift that up to the cloud, so that translation happens in and out of the protocol.

Russel:  What you’re really doing is I’m doing data manipulation between the edge and the enterprise.

Aron:  Yeah, both ways. We started out with a lot of edge-to-cloud use cases, which we thought “I got data at the edge; I want to format it, get it to the cloud.”

Cloud to edge, the other way around, is just as important. One of the cool applications where we see Sparkplug used a lot is we will subscribe to AWS IoT Core, get data from some third-party company that has LoRaWAN-based sensors. They publish it up to AWS. We actually pull it down into HighByte, and model it, and then push that down farther to Sparkplug down to the SCADA system.

We’re taking these out-of-band sensor data, and bringing it back into the SCADA system to generate things like alerts and notify operators via the traditional means.

Russel:  That’s a big deal. There’s starting to be a proliferation of these very low-cost sensors that gather data that is not critical to operations, but is useful for optimization. What you’re doing is you’re enabling a pathway to get that into the operations control center. Interesting.

Aron:  Yeah, exactly. What’s really cool about Sparkplug is as soon as you publish that into the Sparkplug namespace, again, it shows up in Ignition. It shows up in OSIsoft. You don’t have to do anything else. It just shows up in the namespace, and you have access to the data, which is phenomenal.

Russel:  Awesome. There’s probably a lot of listeners out there that have listened to all this and their eyes are glossing over a little bit because there’s a whole lot of lingo that we’ve been slinging around here that’s appropriate for geeks and maybe not appropriate for other folks. If that’s the case, and you’re a listener, I apologize. It’s hard to talk about this stuff and slow down and define every term.

We’ll put together some show notes for this, and we’ll try to be pretty deliberate about defining all the jargon that we’ve strewn into this episode, if you will, so that if you want to go find this thing on the website online, and read it, and understand, it’ll be helpful.

I’ll get Aron to share some more simplified PDFs and such, and we’ll link that up in the show notes so that you guys have access to that if you want to learn more about what this is and think about it.

Aron, I want to ask this question as a wrap up. What should pipeliners know about universal namespace?

Aron:  Be able to spell it. Be able to spell it. [laughs]

Russel:  I could give you my answer, and then you could tell me if I’m full of it or not.

Aron:  It’s a new concept, specific to manufacturing, not specific to manufacturing, in manufacturing and in SCADA with this idea that we can land all the data in a place that everyone has access to it so we don’t have all these point-to-point connections between systems.

Specific to SCADA and pipeline, it’s a way to almost flip the communications on its head and say I’m going to put the intelligence out at the edge. I’m going to publish the data in a standard format up when needed. It just makes life much easier on the consuming side of that data in the application.

Russel:  Everything you said is just right. I will say it in a different way. What we’re talking about here is that you think about SCADA, SCADA’s supervisory control, data acquisition. That’s what SCADA stands for — supervisory control and data acquisition. What you’re really doing is I’m inserting a piece between data acquisition and supervisory control called the universal namespace.

The beauty of that is now not only SCADA has the data, and now not only SCADA can get data from other sources other than just its data acquisition. It’s really taking the SCADA and the data and inserting something in the middle that is an enterprise solution for all the people that need that industrial data.

That’s where the real value is. It’s not so much about getting the data to SCADA, in and out of SCADA, as much as it is getting the data to the enterprise, all the other people that need it.

There’s so much opportunity for machinery optimization, for process optimization, for leak detection, all that type of thing in that data that if I can normalize it and get it there, then all kinds of smart guys can start looking at it, playing with it, and they’re going to come up with stuff we hadn’t thought about.

Aron:  For sure. You get an A on the answer. I get a C, say C+. [laughs]

Russel:  I don’t know about that. I’m trying to translate from factory to remote facility, from that standpoint. [laughs]

Aron:  I think you’re 100. You’re 100.

Russel:  You give me too much credit is what I’m saying.

Aron:  You’re absolutely right, though. The requirement comes in when you’re trying to get that data in to other systems that aren’t SCADA. It’s a path forward just to open that up.

Russel:  Or get it from other systems into SCADA.

Aron:  Into SCADA.

Russel:  Right?

Aron:  Yep. Exactly.

Russel:  The whole Sparkplug B thing is a way to structure the data all the way down at the remote device so that everything else can be self elaborate.

Aron:  No more mappings. Just push that stuff down. [laughs] Make it go away.

Russel:  [laughs] I’ll be bouncing some grandkid on my knee saying, “Son, you don’t remember back when we used to have to do manual Modbus mapping and deal with high words, and low words, and offsets. I spent three days in Africa because I didn’t have the Modbus spec for this silly device, trying to reverse engineer that. Back in the olden days.”

Aron:  Then you say you’re welcome we fixed all that for you.

Russel:  So true. Listen, man, this has been fun. I really appreciate it. We’ll need to get you back on. It would be really cool to talk about a case study if there was an opportunity to do that.

Aron:  Yeah, absolutely. We’d love to. It’s an evolving space. Stay tuned. Keep paying attention. It’s constantly changing.

Russel:  It’s moving quickly.

Aron:  I will say it is. It’s pretty exciting.

Russel:  Again, Aron, thanks for coming on board. This has really been fun.

Aron:  It’s been awesome. Thanks, Russel.

Russel:  I hope you enjoyed this week’s episode of the Pipeliners Podcast and our conversation with Aron. Just a reminder before you go, you should register to win our customized Pipeliners Podcast YETI tumbler. Simply visit pipelinepodcastnetwork.com/win to enter yourself in the drawing.

If you’d like to support the podcast, please leave us a review on Apple Podcast, Google Play, or on your smart device podcast app. You could find instructions at pipelinepodcastnetwork.com.

[music]

Russel:  If you have ideas, questions, or topics you’d be interested in, please 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.

Transcription by CastingWords