This week’s Pipeliners Podcast episode features first-time guest Robert Ward and host Russel Treat discussing the latest information and trends around communication systems at the network edge.

In this episode, you will learn about the latest industrial communication trends around LTE, PrivateLTE/CBRS, LPWAN’s, and more, how SCADA, LPWAN, LoRaWAN, CBRS, LTE, Edge, and Wireless Sensors are evolving with the introduction of new sensor and controller connectivity technology capabilities, and what the future of the pipeline industry looks like when factoring in new approaches to connectivity.

Communications at the Network Edge: Show Notes, Concepts, and Links

• Robert Ward is an advisor, innovation advocate, and technology strategist in areas that include LPWAN, Edge Computing, and Sensor to SCADA to Cloud connectivity and migrations. Connect with Robert on LinkedIn.
• 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.
• Edge Computing differs from traditional SCADA only in the relevance of the dynamic lift that can be moved from the cloud to the Edge, for optimizing bandwidth, and functional efficiencies.
• IT/OT convergence is the integration of IT (Information Technology) systems with OT (Operational Technology) systems used to monitor events, processes, and devices and make adjustments in enterprise and industrial operations.
• The CRM Rule (Control Room Management Rule as defined by 49 CFR Parts 192 and 195) introduced by PHMSA provides regulations and guidelines for control room managers to safely operate a pipeline. PHMSA’s pipeline safety regulations prescribe safety requirements for controllers, control rooms, and SCADA systems used to remotely monitor and control pipeline operations.

Communications at the Network Edge: Show Definitions

• CatM also known as LTE Cat-M1 is Category 1 of the LTE-M IoT network technology.
• Data Rate is the average number of bits (bitrate), characters, or symbols (baudrate), referenced as bits per second (bit/s) and bytes per second (B/s).
• FotA (Firmware over the Air) is a method of sustaining a technology by being able to remotely manage its firmware during its life.
• HART (Highway Addressable Remote Transducer) is a protocol using 4-20ma for the process signal with digital protocol carrying configuration and diagnostic data.
  • WiHART (WirelessHART) is a wireless implementation of HART using 2.4GHz radio frequency.
    • WSN (Wireless Sensor Network) is used to distinguish WiHART and other proprietary local area sensor networks from LPWAN technologies.
• HazLoc are Hazardous Locations such as Class I Div. 2 and Zone 2.
• 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.
• ISM band (Instrument, Scientific & Medical RF bands) are allocated by each country as being “License Free.”  These utilize frequency-hopping techniques to mitigate collisions.
• LoRaWAN is a non-cellular LPWAN technology based on open design by Semtech.
• LPWAN (Low Power Wide Area Networks) include LoRaWAN, MIOTY, LTE-M, NB-IoT, and others.
  • LTE-M is a cellular LPWAN, Long-Term Evolution for Machines, designed for IoT, but with data rates higher than NB-IoT.
  • MIOTY is a non-cellular LPWAN like LoRa but utilizes packet splitting for signal immunity and reliability.
• LTE (Long-Term Evolution) is the cellular wireless technology bridging today’s 3G to 4G to 5G.
• MQTT (Message Queuing Telemetry Transport) is an open and freely available publish/subscribe protocol for efficiently moving data between devices.  This protocol is extremely lightweight.
  • Arlen Nipper is the president and CTO of Cirrus Link Solutions. Arlen was the co-creator of the open-standard MQTT protocol.
• NB-IoT is a cellular LPWAN. It is a single-carrier, narrowband frequency, small data rate technology achieving superior range and indoor application performance.
• NFC (Near field communications) is an RF technology & protocol used within 4cm or less.
• Node is the term for an IoT device that consists of several parts and many functions around signal interface, processing, and transmitting data. It can be quite simple or very extensive.
• OPC-UA (OPC Unified Architecture) is an open and freely available protocol for communicating between industrial equipment and software systems for data collection and control. It is a service-oriented architecture (SOA) as opposed to a publish/subscribe.
• OPEX (operational expenditures) are those which are not capitalized and generally recurring.
• Outside-the-Fence refers to points not associated with the local process module.
• POC (Proof of Concept) is a method of evaluating the feasibility of new technologies.
• Raspberry Pi is an ultra-small and affordable computer that runs on the Linux operating system. The main industrial functionality is to attach the computers to edge devices for more efficient, reliable, and cost-effective data collection.
• RTU/PLC were originally quite different, as these two are platforms are used similarly in industrial applications as programmable controllers with extensive communication capabilities.
• SCADA (Supervisory Control and Data Acquisition) though evolving quickly, SCADA is generally a software used to visualize process data, alarms, analytic results, and lately integrating video surveillance, and artificial intelligence.

Communications at the Network Edge: Full Episode Transcript

Russel Treat:  Welcome to the Pipeliners Podcast, episode 147, sponsored by Burns & McDonnell, delivering pipeline projects with an integrated construction and design mindset, connecting all the project elements, design, procurement, sequencing at the site. Burns & McDonnell uses its vast knowledge and the latest technology with an ownership commitment to safely deliver innovative, quality projects. Learn how Burns & McDonnell is on-site through it all at burnsmcd.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. To show that appreciation, we give a customized YETI tumbler to one listener each episode. This week, our winner is Matthew Price with Buckeye. Congratulations, Matthew, your YETI is on its way. To learn how you can win this signature prize pack stick around until the end of the episode.

This week, I have a personal friend, Robert Ward, a gentlemen I’ve known for a couple of decades. We grew up together out in the oil fields and pipelines of West Texas and the Greater United States doing all kinds of interesting automation and communications. Robert is going to come to talk to us and get me caught up on what’s going on with communication systems at the network edge. Robert, welcome to the Pipeliners Podcast.

Robert Ward:  Thanks, Russel.

Russel:  For the listeners, it’s about time I got Robert on because Robert and I have been knowing each other for way longer than either of his care to acknowledge.

Robert:  I had hair.

[laughter]

Russel:  Robert and I have known each other for a long time. We’ve done a lot automation projects together. Both of us has brought new technology into the market and then applied it and all that kind of stuff. I asked him on because there’s some cool stuff going on in communications.

I wanted to get caught up. I figured that the listener should get the benefit of hearing this banter. Robert, with that, maybe the best thing to do is ask you to introduce yourself a little bit and tell the listeners who you are and your background, all that stuff.

Robert:  Sure, Russel. I didn’t realize it until my dad pointed out just recently. Last month was 30 years that I’ve been in this business. Anyway, so starting off in the measurement space right out of school, and custody transfer measurement and then going up in number of years there with Barton and ABB, all on the automation side and instrumentation.

Then with Control Microsystems, which was almost a startup back then, and brought to market the SCADAPack RTU, then the ClearSCADA product, the Accutech wireless, instruments, Trio Datacom radios, and then later became a part of Schneider Electric.

Russel:  To summarize this introduction, you’re my kind of geek?

Robert:  Yeah. Maybe not as technical, but I can follow, I can whiteboard.

Russel:  Exactly. For the listeners that have heard me talk, very similar background to mine, because we basically grew up at the same time going through the same wars and battles and such. I asked you on the talk, starting to talk about comms and the edge and what’s going on there.

There’s a new technology that I’ve been hearing about and don’t know much about, and that’s LPWAN. Why don’t you tell us what is LPWAN and why should a pipeliner care?

Robert:  Good question. LPWAN is low power wide area networks. It was created because some people would look at it and say, “Why does this thing even exist?” Really, what happened was when broadband started coming into the cell space, the cell providers were trying to sell these big packages that were 30, 40, 50 bucks a month.

We’re moving a lot of data, but there’s a lot of applications out there, whether it’s RTUs, well controllers, chemical injection pumps, or sensors. There wasn’t really a data plan to facilitate that. These other technologies here — some of them — they’re some cellular-based LPWAN technologies.

You’ll hear about Cat M or LTE M, which stands for LTE for Machines. There’s narrowband IoT. Those are cellular technology. They are based on a carrier.

There’s other ones like LoRaWAN, which is based on a standard, and LoRa stands for long-range wide area network. These are sensor technologies that run at sub gigahertz frequencies that have the capability of talking the specification, say, 6 to 12 miles.

We have a customer that’s got applications that’s commonly 18 miles out to the sensor and a device. Those are basically free systems. There’s a little bit of infrastructure to go in. You can have a private LPWAN network. You could have a public network. You could have a cellular and non-cellular. 

Russel:  The level of terminology in that little episode [laughs] was a lot. Let’s unpack it a little bit. I get LPWAN. I get using WAN as a carrier-based, meaning a Sprint or an AT&T, somebody like that, or using it as a private, in other words it’s infrastructure I build and put up myself.

What I wonder about, when you say WAN, is this basically the same thing that we run in our house in terms of WAN, or is it something different from a standpoint of WAN?

Robert:  No. When you take a look at a wireless architecture, it would be, but as far as the capacity and throughput and data rates, it’s not. These are things that are going to be fairly infrequent, small amounts of data.

Russel:  Give me a comparison of a typical home WiFi network and its data throughput capacity versus a typical LPWAN and its data throughput capacity, just order of magnitude.

Robert:  Even to take it down, at your home, I get about 200 megabits per second at home. That’s what I get through my WiFi to the Internet.

Russel:  That would be a pretty big package at the house. That’s a big…That’s for somebody that’s got…

Robert:  That’s a business package at the house. When you think about if you go to a CAT 4 LTE modem, if you get AT&T MiFi to keep in your truck or your computer bag or something, with that one, you could get up to 150 megabit, but you’re probably going to get about 20 to 30 megabits.

Russel:  There’s the difference between what the device says it can do and what the network will actually let you do. That’s a big distinction.

Robert:  These LPWANs, there’s things like one called a SigFox that is bits per day. It’s really, really small. It’s, I think, 11 bits per message and a limit of 6 to 10 messages a day. It’s very small. That could have changed.

Russel:  That’s micro small.

Robert:  It’s real small. Then you go up to LoRaWAN. LoRaWAN is like 50 kilobits per second, so still quite small, but if you think about a sensor or a chemical injection controller, a plunger controller, or something…

Russel:  Some kind of a pressure sensor. If I needed to add additional pressure sensors to a pipeline, 50 kilobits give me a lot of data…

Robert:  It does.

Russel:  …off of a pressure sensor. I could be hitting that guy a lot for that kind of data rate.

Robert:  You can have thousands of sensors going back to a gateway. A gateway is not a lot of money. They’re $500 to $1,200. You can have thousands of sensors. You can cover 300 square miles with one gateway. You can bring these things in.

The idea is to establish these sensors so that you can get what’s relevant about these points. This is data that would be considered low consequential data. You’ve probably never monitored it before. You had somebody drive out and look at it periodically. It was out in the field.

What you’re doing is you’re making it available at a lower interval frequency. The idea is that you have these sensors set up so that you’re not pinging everything. You don’t have data coming in saying…

Russel:  You also get that traffic off of your critical network.

Robert:  Exactly. If something is sitting at 750 or 751, whatever the engineering units are, and it keeps coming in, you don’t need to know that. You need to know if it changed by five. That’s where the data, with some context, achieves relevance. Then you can minimize the throughput and optimize that network.

Russel:  I’m thinking about what the applications in pipelining would be.

One of the things I’m thinking about is if I have farm taps and those farm taps are not currently instrumented and my field data network, my radios or whatever, can’t really take the additional capacity or for some reason I don’t want to put that additional capacity on that network, this would be a way to get that data in at an affordable price point.

Robert:  That’s exactly right, Russel. I hate to use the word paradigm, but my vocabulary’s not big enough to know something that’s kind of like it.

Russel:  Everything’s a paradigm, Robert. Everything’s a paradigm.

Robert:  If you think like a seven level architecture where you’re starting at a sensor and then you start at a RTU that’s going to go into a panel, somebody’s going to pick what that sensor’s going to be. Chances are it’s going to be a fairly costly industrial sensor. There’s some new lower cost these days.

Then somebody’s going to pick whether it’s one sensor or a dozen sensors. There’s going to be a small, to go back into my world, a SCADAPack 100 or a FreeWave IO radio.

Russel:  Some kind of RTU or EFM or something.

Robert:  Somebody’s going to put it in a panel. They’re going to wire it. They’re going to design it. They’re going to do drawings. They’re going to do loop checks. They’re going to scale the IO. They’re going to commission it.

They’re going to call a comms guy, who’s another discipline, and say, “Hey, I’m going to put this on the network. Where’s it going to go?” They’re going to contact a SCADA guy, who’s going to say, “Hey, how do I map this through my polling engine?” Then operations is going to contact SCADA or alarm management and say, “This is the operator on this route.” Then there’s going to be a data lake.

What’s happening here is these LPWAN sensors, you’re going from the sensor to the data lake. You’re injecting data. If you take a look at the Purdue model for security, you’re bypassing levels one, two, and three firewalls, going directly to the data lake through Azure, AWS, or whatever.

You’re making that data available to all the different disciplines in the company without impacting the cost associated with the, I hate to say, bureaucracy. There’s five people that get involved to get a point online.

Russel:  I think we originally met when I was doing a paper at one of the measurement schools on one data point, seven configurations.

Robert:  [laughs]

Russel:  To your point, this is a legacy problem. It’s actually becoming bigger, not smaller, because now we’re tying in leak detection. We’re tying in measurement. We’re tying in machinery analysis. We’re tying in third parties that want to look in at their stuff. The problem’s getting bigger, not smaller.

Robert:  It really is. Especially with all this COVID stuff that we’re dealing with, people have less people in the field. They need to make the most use of their time as possible. The amount of time that’s being wasted looking at things that are not actionable has to be extracted. You have to get rid of all that.

Russel:  I want to ask you a question about this. In the pipeline space, there’s this issue of safety-related points. That’s all covered in the Control Room Management Rule. Pressures and flows and product densities on the liquid side and things like that typically are all part of your safety-related. They feed into your leak detection algorithm.

There might be other points that aren’t safety-related, but would be useful to the control center. I’m sitting and I’m wondering how you might take that data that’s coming straight up to a data lake and then from the data lake to a console but identified as “This is not safety-related. This is diagnostic support.” Is anybody doing anything like that, that you know of?

Robert:  Yeah. It’s on the E&P side, but they absolutely are. One of the reasons is that this LPWAN stuff and connecting to Azure in the data, it’s so new that the company standards for their IT security and data delivery protocol don’t have anything to facilitate this new technology.

They had to come up with something and say, “You know, we’re either going to sit still and stay within our policy, or we’re going to innovate outside of this and firewall this or air gap it somewhere, decide what’s relevant and what’s not. Then we’re going to inject that into the system where it needs to be.”

Russel:  It’s actually an interesting conversation. We, in our companies, just in the last month have really started to get deep into the cloud providers, Azure, Google Cloud, AWS, all that kind of stuff and looking at their offerings.

It’s something I’ve been wanting to do for years and been afraid of because unknown is risk and risk is cost. We, particularly in the current market environment, have a limited belly for that. I’ll just put it that way.

We’ve taken a big dive into it. I think just in the last two weeks, I’ve had my eyes opened in a way, about the cloud, that I have never…I would have never said a year ago what I would say today about what the cloud is and what it can do and the possibilities.

For a technical guy like myself or like yourself and you start getting into that and looking, you’re like, “Man, look how quick I can stand something up that’s completely secure and scaled appropriately to the size I’m doing.”

Robert:  It’s amazing.

Russel:  It’s unbelievable. We did something in a week that five years ago would have taken us six weeks. We did it for less than $1,000. It would have cost us 50. Those are real legit numbers.

Robert:  Russel, you know you don’t do anything less than $1,000. [laughs]

Russel:  I’m just talking for the services versus the hardware and the gear. I’m not talking…

Robert:  I got you.

Russel:  I know. You’re right. We can’t get out to the site for less than $1,000.

Robert:  [laughs] Before we leave on the pipeline stuff, some of the things that we’ve run across are pig monitoring and tracking, corrosion monitoring, rectifiers, pressure relief valves, valve states. I’ve made a state change on a valve. Did it make the change, or did it not make the change?

Russel:  Pig tracking, in a lot of applications, cathodic protection, all of that’s not part of my safety-related points from a Control Room Management standpoint. They fall under different controls and guidelines and regulatory auspices. There’s actually a value proposition for getting that data out of the control room, I think.

Robert:  Interesting.

Russel:  I’d have to think through that more. I should warn the listeners that what happens when Robert and I get together and talk is my brain starts firing up about all the things that are possible, not necessarily the things that should be done. My lawyer has advised me to make this comment.

[laughter]

Robert:  Or disclaimer.

Russel:  Exactly. Let’s transition. Let’s talk about the edge. I’ve been tracking IoT, Internet of Things, for a while and industrial IoT for a while. There’s a lot of conversation about the edge. The edge in the factory is the machine.

When you talk about oil and gas operations, the edge is often the facility. It’s the gas plant. It’s the major oil separation facility, that type of thing. It’s not the RTU that’s out at the interconnect or out at the pump. That’s not actually the edge in our world yet.

One of the things that I’m wondering about is what has to happen for the edge to become the edge, and what has to happen to make the current edge edge-like. That’s a whole lot of saying edge, isn’t it? Do you understand what I’m asking?

Robert:  [laughs] Yeah. Do we put like edge v.1, edge v.2? The distinction’s really difficult, Russel. It absolutely depends. I would say it depends on the segment that you’re talking about, so oil and gas, upstream, midstream, downstream, or transmission, whatever. You pick a spot. Then it depends on the discipline. Is it a measurement guy? Is it a EH&S guy, social relevance guy?

Russel:  I know. That’s right.

Robert:  Is it an automation instrument tech guy? Is it the guy that’s responsible for all the rotating equipment and the vibration analysis that’s going on?

Russel:  I would actually say that you’re right, and it’s also about the network.

Robert:  It is.

Russel:  If I’m behind the termination of the business network and I’m in the field data communications network, that materially impacts the definition of the edge.

Robert:  It does.

Russel:  All the things that I might want to do become harder, because they don’t really have edge devices that work in classified areas and under the temperature conditions and low power and all that.

Robert:  One of the things that really puts a lot of variability on discussion of edge and deployment of edge is that communications. What’s that network look like? What’s the capacity to move data? People are wanting to do more analytics than they’ve ever done before.

Do you build a big pipe all the way out to beyond the edge, through the RTU and into the sensors, so that you’re collecting high-resolution data and send it back and do a real heavy lift on an analytic?

Or do you do that one time, put a data logger out there for a while, collect a bunch of high-speed data, create a model on it, optimize that, lighten the load on it through an edge device, and put it out there?

Then periodically, you do a heavy lift on it. You compare it and say, “Hey, you know what? We could lighten that up a little more.” Then you keep doing…

Russel:  I have a couple of different thoughts on that subject, Robert. One is the nature of the data. If you think about a compressor station, at the real edge on the compressor station is the compressor controller and the engine controller. That’s the edge. I want data at that level. I want to do machinery analysis at that level. At that level, I want to look at microsecond data.

Without microsecond data, I can’t get anything meaningful. If I go back and I just abstract off of that and I go, “Well, now I’m talking about what’s the data I need at the station,” at the station I might need one-minute data.

Then I’m going to abstract off of that. I’m going to go back and say, “Well, what do I need back in the business office?” In the business office, I probably need hourly data.

Why would I take millisecond data, move it all the way up to the host, and then push it all the way back down to the guys that need it. That seems kind of crazy. Why would I want to move the data that way? I think that’s where something like LPWAN or those kinds of technologies have an impact.

A compressor is a bad example of that because it’s a lot of data, but if you think about other kind of instruments, it might. The whole thing is what’s the edge and where’s the edge and the nature of the edge. We have not yet figured that out.

Robert:  I think it’s where you want it to be and where you need it to be. It is going down to the sensor. The LPWAN, some of these sensors, especially around LoRaWAN, they actually have a Python or C++ microprocessor on the RF component. People can write analytics. They can do power management and all these kind of things.

Russel:  That’s right. All those things are going to start supporting MQTT. They’re going to do MQTT with data about the data type data set. I’ll not only have…Here’s my readings, but here’s my standard deviation. Here’s my average for the last minute, average for the last five minutes, average for the last hour, and blah blah blah.

Robert:  Creating context and relevance about that piece of data.

Russel:  The metadata.

Robert:  Historically, what we’re seeing now might be a little bit different. There are some things. There’s a large part of all of our operations that, maybe with the exception of some seasonal occurrences or whatever, have a lot of repeatability. You can extract some correlations on that and push that down to the sensor level, and really minimize what’s being transmitted until it’s relevant.

Russel:  I think the key takeaway from that little segment, if you will, is that it depends on what you’re defining as the edge. There’s a lot of complexity in that, potentially. There’s a lot of opportunity in it. There’s a lot of opportunity to do analytics at the edge, but there’s a lot of complexity. There’s a trade-off between the analytics I can do and what the infrastructure will support.

Robert:  That’s right, Russel. One of the things, I think people are identifying the edge as something that facilitates simplicity. For real critical applications, it’s something that fully autonomously…If it had a disconnect, everything would be fine, with as much complexity as you can imagine, like doing search control or a gas turbine or something. It just really depends on what’s your edge.

Russel:  And what the process is that you’re trying to do something with or about.

Robert:  The criticality of that particular process has a big impact on the decision.

Russel:  I want to talk a little bit about MQTT and Sparkplug B. First, I’m a guy who’s a protocol guy. I grew up in measurement. When I first started doing telecoms, I was watching bits and bytes or hex fly across a data scope and watching messages go back and forth and such. I came up that way.

MQTT is a publish-subscribe protocol. It’s a little counterintuitive in a poll response network, like a data radio network. How does that actually work?

Robert:  You really should get Arlen Nipper on here just because he would do such a beautiful job.

Russel:  I’m making a note. Who’s Arlen Nipper?

Robert:  Arlen is one of the founders of MQTT. He’ll usually throw another gentleman’s name, which I can’t recall. I’ve met Arlen a number of times. He just does a fantastic job talking on this subject.

Russel:  Cool. We’ll have to get him on.

Robert:  He’d be great. One of the things that I think is such an attraction of MQTT in our space in the last couple of years is that there’s a ton of legacy radio networks out there that are 9600 baud or whatever.

People are saying, “Hey, I want to put a camera out here. Hey, I want more data out here.” They’re collecting all this data. Earlier, I talked about data that was relevant or that had context or whatever.

If some data’s critical and some data’s not so critical and it’s Modbus or ROCLINK or whatever the protocol is, then you’re either going to manage it at the polling engine on how fast you’re going to poll that data, or you’re going to get a whole bunch of data that likely is not relevant at all because it’s not changed.

Putting MQTT on the frontend of that out in the field…

Russel:  Not only is it publish-subscribe. It’s also report-by-exception. Why wouldn’t I just use DNP3?

Robert:  [laughs]

Russel:  For people who don’t know, that was a softball question. We were talking about that off-mic. DNP3 is also a report-by-exception protocol. Five years ago, it was all the rage. Then it went away. Now MQTT is all the rage. I’m trying to figure out why.

Robert:  I don’t know that my answer’s going to be right. If we have any real geeks on here, they may go, “Oh, my gosh.” Having been a part of Control Microsystems when we were doing the DNP3 implementation, it was a heavy lift.

There wasn’t a lot of simplicity, but I will say that the hardware development environment was different then. You were creating something in a RTOS and trying to get everything to…

Russel:  RTOS?

Robert:  Sorry. Real-time operating system.

Russel:  Embedded firmware.

Robert:  Embedded firmware. Today, anything that is a Linux microcontroller and can run a Python or a C++, you can go to GitHub and download an MQTT component and put that into your code.

Russel:  This is something I don’t think a lot of people understand. You just said a mouthful.

When I had to build a DNP3 protocol driver or a ROCLINK driver, whatever driver you want to pick, and I was doing it in an RTOS, meaning I’m picking a C chip and I’m writing C code from scratch to implement a protocol, I was talking six months of a guy or two hammering it out until I could get to testing, right?

Robert:  Yeah.

Russel:  What you just said is if I get something that runs Python or I get something that runs Linux, I can go to GitHub, on the Internet, download the code, and have MQTT running. It’s already verified. I can do that in a half day.

Robert:  Yeah.

Russel:  That’s what is making MQTT catch on, because I can do that.

Robert:  We’re used to dealing with technology adoption hurdles that you’re either long jumping or pole vaulting or climbing. This is like a door threshold where you just take a little step.

Russel:  It’s actually open the file cabinet. There it is. You don’t even have to go through a door. [laughter] Seriously. It is so radical, so, so very radical. The minute every single instrument supports MQTT and I can deploy it small or large, wow.

Robert:  Yeah, Russel. Some of the stuff that has really taken a lot of attraction was…Maybe another time we can talk about device management. I believe there’s a lot of people that are in for a rude awakening in a year or a couple years, especially if they’re scaling at all or they’re in active M&As.

Russel:  People are already starting to challenge with this. We talk about talking about this, but one of the things I think is a huge obstacle in all this stuff about instrumentation and edge is it’s getting easier and easier and easier to get the data, but there’s no data context.

How many pressures do I have on my pipeline? Thousands. Which one of these are pipeline pressures? Which one of these are suction and discharge pressures? Which one of these are meter tube pressures? Which one of these are pressures on my line? Which one of these are pressures on my partner’s line? Pressure is not necessarily just pressure.

Robert:  Yeah, Russel. That really is addressed with the Sparkplug B component. Where I was going to go with that is that everybody loved Modbus for a while. They liked it because you could do anything, but they hated it because you could do anything. There was no consistency.

If you’re doing a well pad or a compressor station and you’re using two or three different integrators and they’re all doing the same thing, can you point the same SCADA system to all of those and the data come back all in the same place? No, not unless you gave them some kind of organizational structure to develop their application on.

Russel:  And they followed it.

Robert:  And they followed it.

Russel:  And continued to follow it over the lifecycle of the implementation of 15 or more years.

Robert:  Sparkplug B really supports or enforces that foundation of consistency, standardization, contextualization. It really makes that transportable throughout the enterprise.

Russel:  Interesting. That’s a huge, huge thing. I know very little about Sparkplug B. You’re compelling me that I need to go pull the spec out and read it, dang it.

[laughter]

Robert:  Or hit YouTube.

Russel:  I’m going to make an assertion about where we’re headed. I want to hear your take. First, let me tee this up. If you think about SCADA and automation technology when we first started in the industry, that was all in its own department.

The technology from the instrument all the way up to the host was all isolated. It was all engineered. It all had a team of people around it. Other than the people on that team, nobody knew how it worked, right?

Robert:  Yup.

Russel:  Since then, instruments have standardized. We used to have our own independent networks that we ran this stuff on. Now the network is shared.

The network has extended from just in the office building to the office building and the remote offices and out to right in front of the master radio, maybe all the way out to the physical RTU if it’s at a station where it made sense to take the business network all the way out to the device, and all that’s owned by IT.

Then IT took over all the gear, the servers, and the workstations. They support all of that. Then they started taking over all the software applications. There’s this conversation about IT and OT.

While the management disciplines are a little bit different, I’m asserting that with MQTT and with things like LPWAN and with the IT disciplines beginning to understand and own those technologies, that SCADA is dead. Tell me what you think.

Robert:  Wow. I don’t even know if I want to chase that rabbit.

[laughter]

Robert:  I think the whole philosophy of consumers of data, regardless of the discipline within the company, consumers of data, if they’re not already, they will soon be able to subscribe to data within the company, within the enterprise, that is relevant to them.

I sat on a SPE panel with the CTO from Anadarko a number of years ago. At that time, they had estimated that Anadarko spends 81 man years a year looking for data. That’s not…

Russel:  Using it. That’s just looking for it.

Robert:  That’s just looking for it.

Russel:  Oh, my gosh.

Robert:  When you think about the relevance of data, it’s just waste. When that goes away and you’re not sorting through what’s relevant and what’s not, the efficiencies of scale are just incredible.

Russel:  When I say I assert SCADA’s dead, what I mean by that is the disciplines that we grew up learning are going to very soon be no longer relevant. There’s a whole new set of disciplines that look more like IT disciplines. They’re going to be applied to OT.

Robert:  I would totally agree with that.

Russel:  Doesn’t mean that the control room goes away. It doesn’t. I do think that the biggest obstacle for that to actually happen is there needs to be tools for putting the context and managing the real-time data. Those don’t exist currently in the market.

Robert:  I would say that’s a good assessment. One of the things that was brought to mind recently, a number of years ago, API had this thing called the big crew change. There was a program. I went around to schools and showed a video and talked about the oil and gas to try to stimulate some interest in high school students, so that they would want to go into the oil and gas business.

It really compared it to…Everybody thinks NASA is all high tech and everything. The correlation was…You mean it’s high tech because they put the Rover on the moon? Yeah, that’s cool. You mean where it’s an inert environment? There’s no corrosion? There’s no erosion? There’s no ambient pressure or anything?

In the ’60s, the oil and gas business, we had rovers at the bottom of the ocean, where there’s hydrogen sulfide pumping out of these little pretty tubes. It’s corrosive and erosive. There’s 6,000 PSI bombarding it. We’re doing that. You ought to see what we’re doing today, to try to get that interest up.

That was all tied to the big crew change. The big crew change never really happened. Everybody said, “Oh, these kids are going to come in here. They’re not going to know everything that the gray-haired guys knew. We’re going to be in a bind.”

They came in. They innovated. Nobody had taught them “This is how we’ve always done it.” They’re coming in with their Raspberry Pis and writing Python. They’re doing these things out of the box. That’s what’s going to make this…

Russel:  It’s just like when I came into the business. I was the first guy with a personal computer. I was writing code and grabbing data and doing analysis and printing reports and putting out stuff. Nobody had ever seen anything like that before. It’s the same kind of thing.

Robert:  That’s what’s going to make that IT/OT convergence go so well.

Russel:  I just think that we’re on the cusp of a really, really radical change in the industrial technology world. We’re really early in it, but it’s also going to move a lot faster, because of things like GitHub. I just need to know what to look for on GitHub. It’s no longer about do I have to write it. No, I just need to know where to go find it.

Robert:  It’s G-I-T. It’s git. It’s not get. [laughs] One of the things that’s happening, really quick — it was actually supposed to happen last month but has been pushed; we talk about connectivity out to the field — is private LTE.

Private LTE is basically private broadband that is cellular-based. There’s a couple of ways to get there. Between 3.5 and 3.7 gigahertz was a frequency that was owned by the US military. The government has relinquished that. They’re putting it out for an auction.

Russel:  That’s going to be licensed spectrum, right?

Robert:  It is licensed. There’s actually a kind of free way to obtain it. If you’re in an area like downtown Houston or any metropolitan area, there’s going to be so many users that you would need a license.

In rural areas, there’s a license that’s called general authorized access, which means you can just operate kind of freely. Maybe over the next several years, you have free broadband. Nobody is in your space, because there’s a lot of pipe available out there.

When you think private LTE, it’s carrier grade, which means high reliability. Nobody’s going to take it away from you. You don’t have to worry about like AT&T, where when you hit one gig a month, they’re going to dial you back or anything. You don’t have that.

You have all the networking security features. It can be deployed privately. It’s totally air gapped. It can have total intrinsic, non-Internet related security for voice and data communications at broadband data rates.

Russel:  That’s huge, particularly for these guys operating remote facilities. Now I can throw a canopy of LTE. If I put it up and have more capacity, I can re-sell it to others, if that makes sense.

Robert:  The auction was going to be June 15th, but they pushed it back to August 9th for the full license spectrums. There are five major North American oil and gas companies that have their hands in the pot. They’re going to be buying license. There are some people there that have business plans around it, that are going to provide data. They’ll sublease it out.

Russel:  They’re going to provide data platforms, I guess.

Robert:  In October, at one of the IoT events, the CIO or CTO of BP got on stage. One of the questions after the panel event was “What are you guys doing with 5G?”

He said, “I just spent five to seven days with T-Mobile, Verizon, and AT&T, everybody that’s out there. I don’t want anybody thinking about 5G for the near future. We’re looking at CBRS private LTE. We’re going to put fiber out to the field. When the fiber stops, we’re lighting everything up with private LTE because it’s full broadband. There’s no more…”

Russel:  They’re going to have all the data they need. They’re not going to have all the issues politically that people are going to have with 5G. Whether those are valid or not, we won’t talk about.

Listen, Robert. This has been great. For the listeners, if you want to find out more about Robert, he’s got a blog. It’s called the Autonomous Edge, Google it. You can find him at Autonomousedge.tech. Thank you very much. Also, we’ll link a bunch of this stuff up on the show notes as always. Robert and I are getting ready to get off the microphone, because it is after five o’clock on a Friday. There’s a cold adult beverage. We’re going to continue this conversation. We’re going to actually go and light up and redline the geek-o-meter.

Robert:  [laughs]

Russel:  Hey, Robert. Thanks for coming, man. It’s good to talk to you.

Robert:  Thank you, Russel.

Russel:  I hope you enjoyed this week’s episode of the Pipeliners Podcast and our conversation with Robert Ward. 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 would like to support the podcast, best way to do that’s to leave us a review. You can do that on iTunes/Apple Podcast, Google Play, or whatever smart device you happen to use to listen. You can find instructions at pipelinepodcastnetwork.com.

[background 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