Podcast Episode 51 min
Richard Beeson on Four Decades of Industrial Data
Former OSIsoft CTO Richard Beeson on four decades of industrial data: the Hawaii story behind PI, what Asset Framework was really for, and why AI could bring the next spreadsheet hell to OT.
In This Episode
- Richard Beeson, former CTO of OSIsoft, joined Oil Systems Incorporated at the very start of 1990, when it was a ten-year-old startup of about ten people, has spent 30-plus years obsessed with operations information, and is now building a distributed energy company facing tens of millions of telemetry streams.
- The PI System's origin story is a lesson in listening: a customer in Hawaii ignored the optimization results and stared at the before-and-after data instead, which pivoted the company from optimization consulting to data capture. As Richard puts it, if you just listen to customers, it's amazing.
- In 1991-92 "open systems" meant Sun, IBM, HP and Digital each shipping an incompatible Unix, so OSIsoft built PI 3 for seven platforms; within a couple of years everyone wanted the Windows NT version, but Richard argues the Unix offering is what earned them a seat at the table in the first place.
- Asset Framework was designed for model-driven analytics, not to organize a hierarchy, and its graph and process-modeling features from around 2000-2005 mostly didn't survive because only the approachable, quick-win parts did; David's BASF experience adds that top-down contextualization stalls on activation energy, since operators already know their tags by heart.
- IT and OT keep misreading each other: Richard's Christmas Day pager call about a deleted PI folder shows OT owning computers without the expertise to run them, while digital teams underestimate the risks ("put an IoT sensor in it, send it to the cloud, no problem"), and David's vending machine and site-wide outage stories show the same gap from the plant side.
- Richard's warning is that giving AI to OT creates the next spreadsheet hell, "AI hell", and that the shift will be as big as electricity in factories: swapping a drive shaft for a motor changes nothing until you rethink what you do, because otherwise you can do dumb things a whole lot faster.
A Cold Open and an Introduction: The Embodiment of IT/OT Convergence
00:00 – 02:20David opens solo, since Willem is not on this episode, and introduces Richard Beeson as, in his opinion, the embodiment of IT/OT convergence: someone who has been around digital in manufacturing for decades and served as CTO of OSIsoft, the company behind the PI System.
The two go back a long way. David recalls first meeting Richard while he was still at BASF, when Richard was explaining why certain features David wanted in the PI System were a very bad idea, a memory Richard, tongue in cheek, says he can't imagine being true.
“He's really the embodiment of IT/OT convergence. He's been around digital in manufacturing, digital in the industry for decades already. He's been CTO of OSIsoft with the PI system.”
David Ariens · 00:48
A Chemical Engineer Gone Bad: From Dropout Musician to OSIsoft
02:20 – 05:03Richard describes himself as a chemical engineer gone bad. He wrote software for industry to pay his way through university, expected to become a musician, and ended up in chemical engineering, which exposed him directly to the language and problems of operations even though he never practised the profession for long.
After university he joined OSIsoft, then what he calls a ten-year-old startup with only about ten people, and has been obsessed ever since with operations information: how to manage it, how to get value out of it, and how it has absorbed 30-plus years of technology transitions. David's question about the name reveals that OSI stands for Oil Systems Incorporated, and Richard explains that PI 2's first impact came in oil and gas, quickly followed by pulp and paper and power generation and distribution.
“The short version, I am a chemical engineer gone bad. So I was actually writing software for industry to pay my way through school. I thought I was gonna be a musician..”
Richard Beeson · 02:20
After OSIsoft: Dairy-Free Ice Cream and a Distributed Energy Company
05:03 – 08:54OSIsoft no longer exists as an independent company, having been acquired by AVEVA, and Richard's path since then has been an unusual one. He is a partner in a small company making a dairy-free ice cream in California, a project he had hoped would involve more hands-on IoT and operations work than it ended up doing. He also describes the OSIsoft sale as a moment to reflect on what he wanted next, and says the opportunities that showed up with Schneider weren't the right fit for him at that time.
What he wanted was two things: to recapture the passion of an early-stage startup, and to build software that directly solves a business problem. With a couple of partners in Texas he started a distributed energy resource company that brings solar, batteries and other equipment that is out of reach for many households into their homes affordably, through direct benefit contracts with utilities and with builders and developers. It is, he explains, a massive distributed control system problem, and at that scale the telemetry alone is something he is happy to sink his teeth into.
“As you can imagine, when you have tens of thousands or hundreds of thousands of sites that you're controlling in a distributed fashion, you've got tens of millions of streams of telemetry.”
Richard Beeson · 07:16
Writing a Foreword for the IT/OT Handbook: Two Perspectives, One Destination
08:54 – 11:34David calls out that Richard is one of the two foreword writers of the IT/OT Handbook, and that he kindly said yes. Richard says it was an honour, especially after reading some of the early cuts that got him excited about what David was doing, and a chance to put a little fingerprint in the book.
David explains why the pairing works: Richard brought the OT-first perspective, while the second foreword writer, John Smart, brought the IT-first one. The starting points differ, but both end up in a very similar place, and Richard's dry take is that if they didn't, you would have a really big problem. David then steers back to the early days of Oil Systems Incorporated and asks what the PI System was in the beginning, which problems it faced and which stories stuck.
“If it doesn't end up being a somewhat similar place, I think you've got a really big problem.”
Richard Beeson · 10:03
The Hawaii Story: How Listening to a Customer Created PI
11:34 – 15:38When Richard joined right at the start of 1990, PI 2, a VMS-based system, was already established with at least fifty customers. He wasn't there for the beginning, but as he tells it, the company was started by Dr. Pat Kennedy, a chemical engineer with a PhD, and a small team who were consulting on and selling optimization technology to refining.
A customer, in Hawaii, wanted proof of the before and after, so the team had to capture data to compare the two. When they presented the results, the customer barely paid attention to the optimization itself and instead stared at the data, the history and the comparison. Pat, an astute salesman, saw that this was what the customer valued, and in a classic Silicon Valley pivot the business began to focus on collecting data from isolated, air-gapped digital systems, bringing it together and making it possible to visualize and compare it. Richard's lesson is that if you just listen to customers, it's amazing, which David sums up as the key takeaway of the episode.
“It was just about listening to a customer say, this is what's valuable.. It's amazing. If you just listen to customers, it's amazing.”
Richard Beeson · 12:12
Open Systems in 1991: Building One Product for Seven Platforms
15:38 – 21:12Richard explains how PI 3 came about. Engineers were still mostly on terminal servers or mainframes, PCs had just arrived without anyone quite knowing what to do with them, and sites were starting to get networked at the LAN level. Almost overnight the business world turned hostile to VMS, driven by a business decision to use open systems, which in 1991 and 1992 meant Sun, IBM, HP and Digital Equipment each shipping their own, mutually incompatible flavour of Unix.
To bridge that transition, OSIsoft offered what customers wanted, and when Windows NT arrived, after a Bill Gates keynote in San Francisco, it was added to the stack, so they ended up building for seven platforms. PI 3 became the vehicle for fixing many of PI 2's problems. The twist is that within a couple of years nobody was asking for the Unix versions any more and everyone wanted NT, yet Richard argues they would never have been allowed to sit down at the table without them.
David adds that after two decades of Windows-only OT, the first question on newer installations is now whether something can run on Linux and in containers. Richard agrees it's for a good reason: the next level of scalability and manageability demands new technologies and different ways of thinking, and nothing was wrong with Windows NT.
“We couldn't have even gone to the table and had that discussion and let that unfold if we weren't able to bring those other things to the table. They wouldn't have been allowed to sit down with us.”
Richard Beeson · 19:06
Asset Framework Was Built for Model-Driven Analytics, Not Hierarchies
21:12 – 26:40David sets up the two scaling bottlenecks from the IT/OT Handbook: data availability, which today is more a business decision than a technology problem, and contextualization in a very broad sense that goes beyond asset hierarchies. He asks Richard about the origins of Asset Framework, and recalls Richard once wanting full ontologies and graphs in the PI System, which turned out to be too hard a sell.
Richard says the original AF was a fundamental abstraction to enable model-driven analytics: to write an analysis such as a material or energy balance that applies to any plant without knowing the plant in advance, you need a model of the plant that the analysis can interrogate. Most people now see AF as a hierarchical namespace, but the graph-like and process-modeling capabilities were all in there, released roughly between 2000 and 2005. He wonders whether they were too early, or whether building models was too heavy a lift for the value of the problems it solved. The parts that survived were the approachable ones that could drive quick wins.
He adds that the naming problem starts with the very first PI tag: every time you define something you create the next barrier, because there is always another way to label or reference it, so you keep bumping into the next abstraction.
“The original AF was designed as a fundamental abstraction to enable model driven analytics.. Most people now think of it as a hierarchical namespace of organizing things and abstracting some of the data.”
Richard Beeson · 22:46
Why Top-Down Contextualization Fails: Activation Energy and Strict Taxonomies
26:40 – 31:29David asks how you solve it and whether a perfect model even exists, noting that terms like master data management and data governance carry a negative connotation in operations. He recalls trying to build a business case at BASF for a basic hierarchy across plants. Coming from a first job as a data scientist, where every project started with untangling tag names, he was sure it would help, but a plant manager pushed back: his operators already know their tags, and could name the five nearest flow meters to any location in the plant from memory. It convinced David that a big top-down contextualization project was the wrong approach.
Richard calls it the activation energy problem: as long as there is a big lift to the first point of value, it's a really hard sell. He hints at a novel approach he is working on, for another session, built on the idea of decoupling strict taxonomies from how you get things done, the way the Dewey decimal system and card catalogs are tied to the physical world. The constraint, he notes, is that in OT a strict taxonomy matters, because a pipe has to carry material from here to there and tank A has to keep containing what's in tank A. That gap between digital thinking and physical reality is, for him, as much what IT/OT is about as anything else.
“You just say a random location in my plant, and my operator will give you the five nearest.. flow meters just, you know, right up there out of their heads.”
David Ariens · 26:40
IT/OT War Stories: The Deleted PI System, a Vending Machine and a Site-Wide Outage
31:29 – 40:46Asked for IT/OT war stories, Richard takes a trip to the Wayback machine with a children's-book setup: give a process engineer an IBM AIX computer and they will ask for PI. At a mid-nineties Christmas dinner his pager went off, and a distraught process engineer wanted to know why he had deleted their PI system. It turned out that on old Unix a deleted file that is still open is only flagged for deletion, someone had deleted the PI folder, and the files disappeared when the machine was rebooted, with no recent backup. For Richard it illustrates the IT/OT gap from both sides: OT owning computers without necessarily having the expertise to run them, and digital teams not appreciating the nuances of the risks and security involved, as in "put an IoT sensor in it, send it to the cloud, no problem."
David answers with his own stories: vending machines that sat on the OT side of the network, where an IT incident procedure demanded taking over a screen that didn't exist, and a site-wide network outage in Antwerp after core routers gave up, with trucks jamming the highway while IT was still debugging the root cause instead of implementing a fix. Richard closes the section by praising the handbook for being grounded in real personal and customer experiences.
“I called the distraught engineer and the process engineer and he's like, why did you delete my PI system? And I'm like, okay, it's Christmas, it's not April Fool's Day.”
Richard Beeson · 32:24
AI Hell: The Next Version of Spreadsheet Hell
40:46 – 46:47Asked whether he has one more story before wrapping up, Richard shares a thought he had just the day before and is voicing for the first time: giving AI to OT is creating the next version of spreadsheet hell, which he calls AI hell. Like spreadsheets, AI solves a real problem, and it is much easier for an engineer to just do it than to build a governance, security and management system around it, which leaves open who governs it, who manages it and what happens when that person leaves.
David agrees and asks how broad a data foundation needs to be and how to separate business-critical applications from experiments, which often become permanent by accident. He shares the story of a plant spreadsheet with a daily button nobody could explain once its author had left, which his team re-engineered, and notes that AI can now at least help explain such things. But he cautions about LLM-generated PLC, SCADA and DCS code: the tools answer confidently, so if the code isn't reviewed it may be fine for a fun app but becomes a much bigger problem when it runs a plant, which Richard agrees with.
“I think you give AI to OT and you are creating the next version of spreadsheet hell.. It's AI hell.”
Richard Beeson · 41:18
The Arrival of Electricity: Why Swapping the Drive Shaft for a Motor Changes Nothing
46:47 – 49:27Richard, who has been experimenting with all of this in the new company he helped create, calls AI as significant as the introduction of electricity to operations and manufacturing. In the story he tells, factories replaced a giant drive shaft running through the plant, with each machine tied off it, and it took years before people realized that small electric motors let them fundamentally rethink how machines are used, and the benefits finally arrived.
He expects the transformation in OT to be a fundamental shift in not just how things are done but even what gets done, and as disruptive as that, if we can survive getting there. David says the example is in the IT/OT Handbook, and describes seeing the old drive shaft and belt setup at a bakery museum, which showed him that simply replacing the machines with electric motors works but is kind of pointless.
“I think this is as significant as the introduction of electricity to operations and manufacturing.”
Richard Beeson · 46:47
"You Can Do Dumb Things a Whole Lot Faster": Deep Dives and Wrapping Up
49:27 – 51:49Richard ties the story together: without rethinking what you do, you can do dumb things a whole lot faster. David jokes that he almost titled the episode that, but it was too perfect an ending line. He then announces the IT/OT deep dives at the IT/OT Academy, a new format where the academy audience takes a deep dive into a topic, and suggests AI in OT as a perfect first subject. Richard agrees that a lot of people are trying to figure this out right now, and David says he'll hold him to it.
David thanks Richard for a conversation that covered both the past and the future, and points listeners to the IT/OT Handbook at itotbook.com (ordering it and leaving a review makes a big difference), the academy at itot.academy, and the blog and podcast at itotinsider.com.
“You can do dumb things a whole lot faster.”
Richard Beeson · 49:27
Full episode transcript raw feed ▸
David: I have a very, very, very interesting guest. Richard: I've spent my whole life building, writing, making software information systems for other people to do cool things. Okay, what did open systems mean in 91-92? It meant Sun's flavor of Unix, IBM's flavor of Unix, HP's flavor of Unix, Digital Equipment's flavor of Unix, which were not compatible. It opened the door to saying, okay. Prices, we need to look at how we're going to bridge that technology transition. We need to offer what customers want. David: Welcome to the IT/OT Insider podcast. I'm still David. Willem is not with me today. However, I have a very, very, very interesting guest to yeah to present to you. he is definitely, in my opinion, d the embodiment of IT/OT convergence. He's and I'm putting the I'm I'm putting these stakes high here, Richard. So he's really the embodiment of IT/OT convergence. He's been around digital in manufacturing, digital in the industry for decades already. he's been CTO of OSIsoft with the PI system. So yeah, you now you should know who I'm talking about. It's obviously Richard Beeson. Richard, thank you so much for joining us. Richard: David, it's so great to see you again. David: Yeah, again, because this is actually really funny in the sense that I the first time we met, I was still at BASF and you were trying to explain to me why certain features I wanted in the PI system were a very bad idea. I still remember that. Richard: I can't imagine having an opinion like that. No David: But hey, here we are. And and I think in the in the in the meantime we met so many times. First of all, for those who don't know you, start with a short introduction. And then we can step into a bit of the history of PI as well. But let's let's first start with introduction. Okay. Richard: Let me do a quick one. the short version, I am a chemical engineer gone bad. So I was actually writing software for industry to pay my way through school. I thought I was gonna be a musician, and I honestly. And at some point I said, no, that's that's not what I want to do. And I was kind of lost. And then as most dropout musicians, they pick up chemical engineering. So that's what I did. David: Yeah, that's what I also heard. Richard: which is fantastic because it it not only was fascinating, it allowed me to be directly exposed to the language, the problems, the issues of operations. so even though I I never spent a good amount of time practicing chemical engineering, it it allowed me to understand that space. and And then after university, I ended up finding this company called OSI Soft, which was what I will call a 10-year-old startup. Because there were really only about 10 of us when I joined. and even though it had kind of gone through its first iteration, that was happening. So so yeah, that's I've spent my whole life since that point basic basically obsessed with operations information space, how to manage that data, how to get value out of that data, how it has evolved and absorbed the technology transitions that have come and come and come and come over the last 30, 35 years. And getting to both help guide that and also be subject to it has been an interesting journey. David: Absolutely. I and actually I you you once told that to me, I think OSI soft originally stands for is it oil systems incorporated or something like that? Richard: Yeah, the OSI is Oil Systems Incorporated. Yeah. So when I when I joined up. yeah. David: Really were only in oil at that time. Richard: Well, no, actually, well, it's funny. the the three big sectors that we had the initial impact with with PI two was oil and gas, which is where we got our first foothold, but then very quickly into paper, pulp and paper. that was a big one, and then also into power generation and distribution or trend. David: Yeah. Richard: Yeah. So those were the kind of the early, early big, big hits, I would say. David: You OSI soft doesn't exist anymore. It's been acquired by AVEVA you're doing other stuff right now. y you're in like ice cream and and something with energy. Richard: Yes, I ice cream. Ice cream is a taste good, is to feel good kind of thing. we have a small we have a small company that does a dairy free product out in California. I I had hoped to do a lot more with IoT and hands on and stuff, but that life took me other other directions. So I'm I I'm a partner in that in that effort, but I don't get to play I as much with the equipment and the the operations as I wanted. Yeah, and yeah, as you mentioned, OSIsoft was sold. And it was a point for me to reflect on what I wanted to do with my life and and and honestly, there were some really great opportunities that that showed up with with Schneider. but ultimately what I think I wanted to do and where they were headed didn't just didn't it just wasn't the right time place for me. So I spent my whole life building, writing, making software information systems for other people to do cool things. No, no, no. It's not to say that building a software was not incredibly fulfilling and exciting, challenging and fun, and got to meet lots of great people. And nice thing about being in that space is you get to see every industry, which is probably what your experience is. You're absolutely you know, you're you're making cookies one day, you're making ice cream the next day, you're you're boiling oil the next day, and figuring out how to deliver drugs, pharmaceuticals the next day. David: Absolutely, yeah. So cool. Richard: Right? It it is it's it's like wow, it's fantastic. but what I realized is two things. I wanted to get back to that passion of of like early early company startup kind of thing. I mean, it's it's the worst and best of all worlds. David: Yeah. Richard: Probably similar to the life you've been living for the last couple of years. and the other thing is I wanted I wanted to make software to solve a business problem. So I wanted to I wanted to be the cons I I wanted to directly make that be part of what the business was about. so we got together, me and a couple of partners down in Texas and we started a a distributed energy resource company, which is really geared at bringing energy through direct benefit contracts to the utilities, direct benefit contracts with builders and developers, and enabling this, you know, the the classic solar battery, everything that's out of reach for many people to bring that technology to their houses in an affordable way. So that's what we've been working on. And to solve that is a massive distributed control system problem. Cool. So I've been working on that. And as you can imagine, when you have tens of thousands or hundreds of thousands of sites that you're controlling in a distributed fashion, you've got tens of millions of streams of telemetry. So that has been something that I've been able to sink my teeth into. It has been very fun. David: That actually gives us quite a lot of topics to discuss. Richard: Yeah. David: no, but it's so cool. That's so cool. and and and by the way, and I I I need to do a small call-out here. you are also one of two forward writers of our IT/OT handbook. I I I kindly ask you, and you kindly said yes. Richard: I kindly said because it was quite an honor, especially after reading some of the early cuts. I was very excited about what you were doing and it was definitely an honor to be able to put a little fingerprint in there. Yeah. David: No, but it's so cool. And what what I actually like is you you brought the OT IT OT perspective, and then and then the second forward rider, John John Smart, who he he brought the IT first IT/OT perspective. And and and I think that it's really interesting to see there are differences, there are other points of view, there are other starting points, but in the end, it it's what you also mentioned with the with the the the energy example where we try to end up is actually at a very, very, very similar place. Richard: You know, if and if it's not a visa if it doesn't end up being a somewhat similar place, I think you've got a really big problem. David: It's i it's it's also interesting how that l ties into IT/OT conversions. But that's you know, maybe maybe we get to that in the the rest of the podcast. let me go back to the early days of Oil Systems Incorporated, and at a certain point in time, and I think that's a really interesting story because for me the PI system is maybe not the the first historian on the planet, but definitely the first like Not just big one, but also the first one where we brought in these concepts of how can we do more than just historize data? how can we, you know, a at structure as something which people now might refer to as something called the unified namespace. But I I I I think the PI system has been doing similar stuff for quite a while already. like take me back to What what what the PI system was in the beginning and and and why you saw these needs to to keep on h enhancing it, with what were the problems you faced, what were the the the fun and juicy stories you you encountered in these early early days. Richard: Okay, and and we've got you set aside how many hours for this? David: Yeah, like like it's now it's it's afternoon when we're recording it, so I it's it's okay. Time till late this evening. Richard: Well so like I mentioned, I I joined Oil Systems Incorporated, which became OSI Soft, which in Europe is OZoft. and a PI two, which was a VMS based fax based system, was pretty established. And when I say established, there were At least fifty customers at that point. So fifty pie systems. David: What year? What what l what what period are we talking now about? Richard: So that all transpired between the mid and late 80s and to the early 90s, right? So I joined right at the very beginning of 1990. New decade, new new career. and I wasn't I wasn't there for the start startup high two, but the the story I've heard is that the company basically started by by Dr. Pat Kennedy. and he brought in a wonderful gentleman, Marc Hughes, who had made his way to California from MIT to go spend septana Cal. And they they ended up and bringing in a couple other amazing people. they went after basically consulting and and selling optimization technology to refining. which was some of Pat's background. He was also a PhD in chemical engineering. And you know, so they'd get out there, they'd go through, okay, this is what we're gonna do. And the customer, as I understand it, again, I wasn't there, the customer essentially was, okay, prove to me that the before and the after you've actually made the difference you said you're gonna make. And they're like, okay, how are we gonna do that? So like, okay, we're gonna have to capture all this data so that we can see what it was doing before and then we can compare to what it was doing after. Course, Adam the gang went back to and this of course it had to be in Hawaii, right? So you gotta have a customer, it's gotta be in Hawaii. So they head back to Hawaii and and you know they're they're sitting there showing, okay, this is how it was operating and that we've applied our technology and our optimizations, and this is like how awesome we are and what we did, and the customer is sitting there, not even paying attention. They're just looking at the data and the history and the comparison and what they were able to do. And then Pat, who obviously is very astute, he was an amazing, amazing salesperson. he's like, that that's what they are valuing here. And you know, in a in a classic Silicon Valley, even though we were silicon adjacent. in a classic Silicon Valley way, that was a big pivot. And they the whole business started to slowly get focused on this new concept of like, we got data, we got data from this from this digital system, and we got data from this digital system. And in that world, in those times, you didn't have networks. Everything was an I literally an island. I mean, we talked about data silos and all that stuff today, but this was like literally that equipment was. Air gap to bring that equipment and that equipment and that equipment. So the idea of bringing that all together and having all that history and being able to visualize it and compare it. That was that was the aha. And it was just about listening to a customer say, This is what's valuable. Yeah. It's amazing. If you just listen to customers, it's amazing. David: Key key takeaway from the episode, listen to your customers. Richard: Well, I've got another story about that, but maybe we can get to. So so that was that was kind of how PI PI two happened. I happened to show up right when this whole a couple things were happening. it's hard to imagine now, but most engineers used terminal servers connected to their backs or to other things or to their mainframes. weren't networked, they didn't have PCs. The they would get PCs and nobody knew what to do with the PCs. Okay, this is a great thing. I need it. This is cool. Now what? so I I rode into town just as that was that was happening. And of course, you know, as the kid, of course, that's that's where the world's going. and so a couple things happened. That that phenomenon happened, sites started to get networked a little bit, at least LAN, not not WAN. We weren't talking internet here. and the business world overnight changed. I would say it became VMS hostile. It wasn't so much VMS hostile is that the that that the the the business decision and this is maybe like kind of the IT-ish side. the business decision side is saying, yeah, you can do all this stuff, but you have to use open systems. Okay, what did open systems mean in ninety one, ninety-two? It meant Sun's flavor of Unix, IBM's flavor of Unix, HP's flavor of Unix, Digital Equipment's flavor of Unix, which were not compatible in any way, shape or form. They weren't all based on, you know, it's not like Linux we have today, which is pretty pretty uniform and mainstream. So it opened the door to saying, okay, prices, we need to look at how we're going to bridge that train that technology trans transition. We need to offer what customers want. when we started that, we didn't even Windows NT wasn't even on the radar. Really? but Bill Gates came down to San Francisco and gave this Great keynote presentation in San Francisco talking about this whole thing that was coming the path to I can't even remember what path it was. But it was the early introduction of the concept of of Windows NT. because I don't think Bill wanted to lose to IBM's OS2 or whatever. Thank goodness. Anyway, so then we added that to the stack, and so we built for seven platforms. PI 3 became this thing targeting seminar platform. and and so we used it as an opportunity to solve a lot of the problems that we had with PI 2, and this evolved into Py3. That was the origin story for Py3. That's how we got or we got to today in a way. David: It's really interesting. So that's also really like having all these different code bases which you needed to support? Richard: Every single one. Yes. And and unfortunately, so so here's here's the funny thing about business decisions and especially when OT still has problems they need to solve. the fact that we offered these Unix solutions somehow allowed them to say, Okay, well, we can get that, but this is better. So we want the NT version. Yeah. And so within a couple of years, nobody was asking for the Unix versions. Everybody wanted the NT versions. But we couldn't have even gone to the table and had that discussion and let that unfold if we weren't able to bring those other things to the table. They wouldn't have they wouldn't have been allowed to sit down with us. So sometimes sometimes you have to make decisions like that. That was a fun one. David: That's it. Yeah. It's also okay. Time has shown what what direction. It's also interesting to see now that this well i I I think in the OT world in general, we've been the last two decades or so, it's been Windows only. Like everything, literally everything ran our Windows. Now, and okay, we're we're now jumping a few decades in the future, but it's actually interesting to see how that's now changing again. Where I think the first question we're getting right now, espe especially for when we're installing newer systems, is can it run on Linux? can we can we can we run that as a as a you know as as a separate container or something we can easily scale or something which which we can easily move across hardware, et cetera, et cetera. so it's it's interesting to see how after a couple a couple of decades of pure Windows dominance, this is now this is now changing again. Richard: And I think it's for a good reason. I don't think anything's wrong with Windows NT. it's not like any anything went wrong. It's to get to the next level of scalability and manageability and everything, you you it it demands new technologies. Yeah, really different ways of thinking about that. David: So let's get back to the PI system and and again jump a couple of years. What's very interesting in my opinion is so in in the in the ITOD handbook, in the the part about scaling, we we talk about two major bottlenecks. And the first bottleneck is data availability, which still today is an issue in many environments, but it's an issue which is today very easily technically solvable. There is enough technology on the market to solve the connectivity problem. So this is more a business decision to make than a technology problem to solve. The second bottleneck we'll talk about is contextualization in its in a in a very broad sense, not just asset hierarchies as many people know it about, but very broad definition of contextualization. So maybe a a bit about your experience, going back to to I don't know when asset framework was was introduced, but there had to be a point where you also went like So we we need more than just flat flat tags. And then Richard, there is this I and I don't know whether this is gonna be a rabbit hole again as well, but I know you we at at some point we were you you were visiting me or so and you were talking about the fact that you actually wanted to have more than just hey, you know, the tree structure, you you you you wanted to have full ontologies, full graphs implemented in the pie system as well, but that was Too har too hard of a sell, if I if I remember correctly. So the ta taking it back to that thought process. Richard: Okay, wow, that's a whole lot to unpack. Wow, wow, wow, wow. So the original AF was was designed as a fundamental abstraction to enable model driven analytics. That was the problem that was being solved. It's like hi so so how how can you write an intelligent analysis yield the coming name? material balance, energy balance, anything that you would just throw at a at a at a at a at a plant that's applicable to the plant without knowing the plant ahead of time. How do you write that analysis? Yeah. So that's so to solve that, you needed to be able to structure you basically basically to be able to build a model of the plant that represented the aspects that the analysis needed to be able to interrogate, understand what it was looking at, and then execute and then generate the results. So that was the original AF. Most people now think it think of it as a hierarchical namespace of organizing things and abstracting some of the data and stuff like that. So it was actually everything. So the graph esque, the process modeling esque, all of that was actually in and released wow in the first five years of so between two thousand and two thousand five that was all that was all in there. So that we we saw that were we too early? Did we not know how to sell it? was the building of models such a heavy lift that there weren't enough high value problems that people could justify doing that work. All kinds of things came into play. So parts that survived were the parts that people could that were approachable yeah and where you could maybe drive some quick quick wins some quick value which which often drives a lot of what's going on so I think that's one of those cases where we did some really amazing stuff and it was too soon or some of the other parts and pieces weren't there so it became what it became but But just back at so so back on the topic of of of names and naming and all of that. I mean, from the very beginning of PI 2, PI 3, you already have the problem of you're you're putting in a name, you're putting in a description, you're putting in where the data's coming from, you're putting in engineering units, you're putting in that, you're putting in all the different aspects of meta information. And then the tag, it's a pie tag. It was just, you know, a simple set, but it's still a set. But guess what? Every single time that you you define the thing, you're you're basically creating the new barrier, the next barrier, the next impasse, because there's always going to be some other way to conceive of it or shape it or label it or identify it or want to reference it. so so it actually that whole problem started even from the most basic aspects of here's a sensor. How do we relate to that sensor? And then how does that relate to everything else in the whole constellation? David: And it it and it keeps on being a a a a tough nut to crack. it's it's Richard: Every time you bundle it, you you you you bunt you're you're gonna bump into the next abstraction. Yeah. David: Yeah. Richard: So David: It's interesting. It's interesting. How do solve that? Yeah, how do you solve that? Yeah, it's it's a very difficult one because here we're talking indeed about how do you build the perfect model? Does a perfect model exist? We often use the words yeah, master data management, data governance, which has a very negative connotation to to many people, especially in operations. They go like, yeah, no. But here is a funny story. So when when when I was working on introducing the PI system so many years ago at at BASF, so we came from another system which has no hierarchy at all. And I was actually trying to build a business case to to invest in in modeling, yeah, to to at least have a a basic a basic hierarchy rolled out across across our plans. So I started talking to operations managers and I went like like I star I started to explain like how how how cool would it be, how how interesting would it be to to have that hierarchy available in your systems? Because in my first job I I was a data scientist and so that means that and and I wasn't I I was doing those projects for for several plans, which which meant that. Every time I started doing a project, the first thing I needed to do was untangle the data. Because for for for me, though those tag names meant almost nothing. Except for you know, finding the P Vs and the SPs, etc. Yes, sure. But but but for the rest, it meant almost nothing to me. And and I still remember that the the people, the plan manager I talked to back then said like, David, I I I really don't I I really don't see the reason why why we should start investing in that because People in our plant, they they know these stacks. They work with them. They like you just say a random location in my plant, and my operator will give you the five nearest I don't know, flow meters just, you know, right up there out of their heads. That for me was a bit of a sign that we're we're we're I was trying to do this in in in the wrong way. I I was trying to come with a let's do a big project, let's do a big contextualization type of thing top down. Yeah, that that that's Clearly didn't work. At least at that time. I don't know if you had similar discussions, other discussions Richard: Yeah. No, that's a that's it's exactly the the I'll call it the activation energy to get to get past this problem. as long as as long as it has a a a a a big lift to get to the first point of value, it's it's a hard sell. It's really, really a hard sell. now, I I'm not gonna say too too much, but I have been working on on what I think is a a novel approach to that problem and maybe maybe in the future we can we can have another session with David: Talk about that. Richard: but you know the basic the basic idea is that the Dewey decimal system and card catalogs are great but they're tied to the physical world so how do you decouple you know in the information world how do you decouple these these strict these strict taxonomies from how you get this done. And and I think that's I think that's that's a a ripe area that I'm I'm poking on and I think there's an opportunity there. The problem, or I don't know, it's a constraint maybe more than a problem is that in the physical world, in the OT world, a strict taxonomy is very important because you need to know that a pipe is going to flow material from here to here and it's not going to be different tomorrow. At least or what's in tank A is kind of what's in tank A. And you when you pull on that, you expect to get a particular product. you know, so it it that is again this this whole world of digital information and how that feels so different than physical grounded reality that it's supposed to be representing. And and that I think that's as much of this whole IT/OT thing as anything else. It's like how do you think in in in digital speak and how do you think in physical speak, which you see day in and day out, obviously. David: I already introduced you as the as the embodiments of IT/OT convergence. Or it or or or at least maybe trying to. There have to be a couple of IT/OT war stories, things you encountered, which you Richard: Can I can I go to the Wayback machine for some of this? yeah. David: Yeah yeah. J like like shoot. Richard: Okay, okay. So here we go. let's see. I don't know if this plays in in in Flanders. when you give a mouse a cookie. Okay. I a most American children will say it's going to ask for a glass of milk. David: No no I yeah, that's a new one for me. Richard: Okay, so the the end of the and when you give a process engineer an IBM AAX computer, David: Yeah. Richard: what are they gonna say? They're gonna ask for pie. Okay, okay, this is pie. And we're not talking cookie pie, we're talking about the pie system. Right, okay. So I'm going somewhere with this, I promise. So imagine Christmas dinner or a mid nineties with my family. This is back in the day when we carried around a a mobile brick, mobile phone and a pager. And that was our 24 hour support solution. So anything that was really a problem got escalated. So I'm sitting there enjoying, I don't know, whatever we were eating, and all of a sudden, all of a sudden the pager goes off and so I I called. I call this I called the distraught engineer and the process engineer and and he's like, why did you delete my pie system? And I'm like, okay, it's Christmas, it's not April Fool's Day. So got that. This is anyway, it turns out that this was on a on a on a Unix machine. And I don't know if you've ever deleted folders and files in old Linux, old Unix, the pre-Linux. So basically what it does, if a file is open, it flags it for delete. doesn't delete it. Turns out that somebody had deleted the PI folder. And it just happened that on this day, this person decided to reboot the computer, which released the files, which deleted the files. David: Really? Richard: So no, I mean, honestly, and not funny for them. I I felt bad because they didn't have too recent of a backup. But where where am I going with this? It's it's this is part of that that that IT OT thing. It's like, I mean, back in the day, and I hear even still today to some extent, OT will own the computers. But they're not, but that's not necessarily their expertise. Okay, so here's someone who who had a computer, was using it to solve problems, but didn't necessarily track all the nuances of what it took to do it right. Right? So so that's and and I just I I see versions of that playing out over and over and over, actually on both from both sides. Digital land not quite really understanding. the nuances of the problems that that that they're they're trying to help solve. And and and on the other side, really not appreciating the nuances of the of the risks, the security, how to manage this stuff, you know, put an IoT sensor in it, send it to the cloud, no problem. What could go wrong? David: No, no, absolut yeah, absolutely, absolutely. I that I've also encountered so many versions of of of of of of of that of that same story I I I I I know actually the the book starts with one of the stories Willem will have encountered and We we made a decision it's it's a very fun and engaging story and it's it's all it's also happened in the night and it's about trucks who can't enter the sites and there is also a very in the end stupid reason about things which went wrong, but I'm not gonna I'm gonna I'm not gonna spoil the intro. I I think I think w o if I if I look back to there are so many calls, so many problems I also attended, but something very simple like like my my team was also responsible, for example, for the vending machines, which In our case, vending machines are were also part of the yeah of the OT network. well, OT, of course not the control network, but at least not part of the IT network. Yeah, they were separated. and and if there is one thing like you don't want to do is you don't wanna piss off shift people. Like like they are there during their night shifts, during holidays, you know you don't wanna piss them off. so vending machines are actually something really important for them because if they're hungry or thirsty, they they wanna go there. and fair point, right? I also wanna I also wanna eat during the night. but I I actually remember a story where so the vending machines were were not working at w not working anymore, there was no network connection, nothing happening. Network was owned by by IT. needed to needed to lock an incident. But the procedure the procedure says that they had to try take over the screen. And I went like, yeah, there is no screen. Like the like I yes, sir, but we we need to we need to have the IP address so we can take we can try taking over the screen. And I went like best I can do is send you a picture of the damn machine. Like, but Richard: a small disconnect there. I just yeah. David: Or or another one, another one where we had a a a sidewide network out outage. some I core routers, I think, just just gave up. And there was a problem with redundancy, sidewide outage. And p preo one incidents, all bells and whistles, s s crisis team, trucks jamming the highway, you know, All the all that all that physical stuff which you know tank starts filling up, production needs to scale down because you they they they can't they can't send out their product anymore. All these things. And and IT was working on a problem somewhere on an office abroad. And and and at a certain point in time they found a problem. and went like, yeah, good. Alright, so now now we can we can we can implement a fix and then hopefully in like half an hour or so. We can start rebooting our systems and we're back up all online. And after an hour still nothing. And Richard: We can get our sneakers bar. David: we can get our sneakers, both. and after after after I think an an hour still nothing, an hour and a half, still nothing. And and at a certain point in time I I I called the highest in chain. I was at that time also responsible, highest in chain on on the Antwerp site. And I went like, what the fuck are you doing? And the the guy told me he was somewhere again on the other side of the road, and went like, but we are debugging the problem. I went like you are what? Like you are not going to debug this problem. You're gonna implement a fix right here, right now, and I give you five more minutes. And and they were just unaware of the gigantic impact, but really gigantic impact that outage was having at that time. Richard: No, that's David: Yeah Richard: I I I wanna for for the people who might be interested, one of the things that I found so refreshing, compelling, when I read the early drafts of your book was how it was this wonderful grounding in your personal and customer experiences, like real things that have happened. Yeah. Combined with some real forethought and and yeah, I I I expect people in this space are really gonna appreciate what you David: Thank you so much. Thank you so much. That's that's that's really really nice of you saying so. so, like this is typically the time where we are wrapping up the episodes, but this this one flew so much faster than than other ones. I'm just I'm like wondering, was there still any any any fun story, interesting thing you wanted to share with the audience, Richard? Richard: I had an interesting thought yesterday. And I'll be curious if this resonates. this is the first time I'm I'm throwing this out. AI. David: Shoot, shoot. I'm I'm very Richard: AI is is representing this this what I think is a very interesting opportunity, obviously, across the world, but it how it intersects with OT. And I've been reading a lot about what some people have been doing. And all of a sudden I had this flashback to spreadsheet how. You know, you know spreadsheet hall, right? David: Yeah of course I do, absolutely. Richard: No, it it happens, it happened, it happens today, yeah, because it it it solves a a real problem in a way, but it creates a real problem. I know you've played with it. You know all the things you can do with AI, right? I think you give AI to OT and you are defining creating the next version of spreadsheet hell. Okay. It's it's AI hell. And it's are there problems that you you give these tools, you give a spreadsheet to an engineer. Things that they can do that is just so much easier for them to just do it than try to build a governance system and a security system and a management system. They just have a problem they want to solve. But then now you've got this stuff that who's governing it, who's managing it, what happens when that person leaves? So I think we're entering a whole new realm of spreadsheet hell, and I'm calling it AI hell. David: I couldn't agree more. And and it it's a very it's a very interesting problem because a as you rightfully said also when we're talking about spreadsheets and and and and mackerels and somebody's f coding a solution t to a a real problem. Like the the the they're they're Richard: Yeah. David: real problems. And And then and then you we kind of got a feeling about yeah that that it doesn't really scale. N now we're again at this almost again ground zero, again a new starting point. and and here comes then this this very interesting thing is okay, how much and this is also just an open question here, but how much of a fundament do we need? Like how how how broad should our data platforms but be? How do we make sure that we make a distinction between business critical applications and then the the things we are just, you know, we're we're playing around with. But but also the the things we are playing around with, they often become permanent by accident. More often than not, unfortunately. there are again so many stories. but I think one one one story is also. happened was that there was this excel sheet which was being used every day in a plant I I guess by a planning department or something like that. And my team came in because they gone they were going to identify important spreadsheets and then replace them by a a supported solution. And then they asked the team like, okay, what what what what what do you do? Yeah so I'm using this spreadsheet every day. Okay, what what do you do with it? I have to press this button every day. What does this button do? They went like we like we don't know because the the the the person who built this thing doesn't work for us anymore. It it it it does stuff, and I need to use the output to do my work. but that was it. Like and and and so but what the team did was actually completely re-engineer what the spreadsheet was doing. Now, with AI, this is becoming a little bit bit more easier because you can actually ask a clever chat tool. With about with with enough context, you can actually ask it, like explain me what this thing is doing. So that's actually really nice. but but but let let's let's take engineering engineering as an example. People are talking, and rightfully so, about using LLM powered tools in the engineering realm. or to you know, to to write to write PLC code, to write SCADA DCS code, all the all the good stuff. which I fully agree with because there needs to be a change in how we How he code these things, and many, many of them, you know, many engineers, they still have a virtual machine on their on on their on their laptop running Windows XP or something else, because you know that tool and that version still requires that version of Windows. But the problem is when I'm coding in with with with my AI tools, often I get a response back and he's very confidently saying. This is the result. This is the answer. And then I I respond back with I but then for example, I say, Yeah, I don't think so. Because this, you're you're you missed this and this and this. And then he also always says, Yes, you're right. Very good catch. And I went, like, yeah, I know it's a very good catch. I don't need you to confirm that to me. but the problem is if I'm not revising that code or whatever is being produced, if it's just for a fun app. Which doesn't work, okay, fine. But if that same code is now gonna run my plant, Richard: Mm-hmm. David: might be a bigger problem. Richard: D think it definitely represents a bigger problem. there's there's so many there's so many ways to go with this. Maybe we could do a whole session on on AI and OT because David: We should. Richard: I I have I know really I I've been I've been digging into this you know having a having a new company I've I've helped create to experiment with all of this stuff. So a lot of lessons learned. but honestly, I think I think this is as significant as the the introduction of electricity to operations and manufacturing. I I'm sure you know the story, and I maybe even told the story in the book. I I sometimes I get I get confused whose book it was up. But the you know, this is the story of the introduction of electricity is we replaced this big giant Diesel drive shaft that runs through the whole plan and you and you you you tie off of to run your different machines. And then it took years before people realized that no, you actually can fundamentally rethink about how you use small motors and run electricity to all of them is much easier than having a massive drive shaft and just, you know, why aren't we getting the benefits? Why aren't we getting the benefits? I I think. I think the transformation we're going to see in in OT and I don't know how long it will be. I think it's I think it's going to be a fundamental shift in in not just how you do things, but also even what you do. I think it's it's it's that it's gonna be that disruptive if we can survive getting there. David: That example is indeed is indeed in the book. And actually just a couple of months ago, I was at a an old bakery museum, and there was actually this this old drive shaft setup was still there. It was actually my first time I saw that. and it was really, really cool to see because you indeed have the different machines which are were used in an old bakery. And they were indeed perfectly aligned with the diesel power driveshafts. Richard: And then little belts. With the belt connecting up. David: Yes, with the belt. Really cool. This is like the first time I'm I'm I'm I'm seeing that that setup. It probably exists in other museums as well, but was for me the first time I saw it and that's it's really interesting because it's it showed you how how just replacing those machines with an electric engine works but is kinda pointless. Richard: This is part of the you can you can do thing you can do dumb things a whole lot faster. David: Yeah, Richard: Faster. David: no, no, I was thinking I should maybe I titled this episode doing dumb things dumb things faster, but I'm not gonna do that because then it's it's it's a it's a perfect way to end the episode. By the way, we are so we're actually introducing for IT/OT Academy, we're introducing something new, new, which we call the IT/OT deep dives, where we're inviting our academy audience to do a deep dive on a certain topic. Maybe this AI thing is gonna be a Perfect a perfect topic to discuss in one of those deep dives. Richard: I think it's I think it's a lot of people are are trying to figure this out right now. So that would be a perfect one. Yeah. David: Gonna I'm I'm gonna hold you to that. So let's let's let's talk. but with that, Richard, time flies when you're having fun. this was so enlightening enlightening. I hope our audience also liked this this little discussion where we discuss both the past and the future. Very interesting. so as always, obviously we talked a bit about our IT/OT handbook, which you can you can find at itotbook.com on all major online booksellers pre-ordering or ordering the book leaving a review really really really makes a difference for us we wanna have a small change we really want to do something for this industry we believe it's important so buying the book leaving a review is gonna make all the difference for us we talked about the academy people can find that on itot.academy and obviously our blog and podcast on itotinsider.com. so with that, Richard, thank you very much. Richard: Thank you. It was great getting to spend some time with you again. You do well. David: Awesome. And also to our audience, thank you for tuning in. your support is highly appreciated. It's what we love to do, and seeing so many people consume our content makes me a very happy camper. So thank you for that, and until we meet again, take care. Bye bye.