 So, I'm going to hand over now to Anil Ali, who you saw earlier, who's going to moderate the next panel. Over to you, Anil. Thanks, Steve. Okay, so we have a question here related to. Industry existing industry standards, specifically IEC 6, 14, 99 and IEC 6, 11, 31. The question is, is IEC 6, 14, 99 a prerequisite for openness within industrial control, or is there a way to achieve openness with older or widely adopted standards like IEC 6, 11, 31? I'll answer that one. You can definitely use 6, 11, 31. 6, 14, 99 is a build on 6, 11, 31, but it is by no means a requirement to achieve interoperability. Okay. Thanks, Dave. And we've got another question related to OPC UA. Actually, let's let's skip on down a little further. I think that one was answered. Okay, here's another one on operating systems. Is OPC designed around particular operating systems? If yes, which one? So, I'll jump in here again. OPC UA is not operating system specific. OPC UA is information and communications standard, which can be implemented, I think, in all of the various operating systems. Well, that's good, Dave. And to go a little bit further on, well, actually, can you comment, Dave, and go a little bit further as to how the OPAS standard addresses OPC UA or how it references it within the standard? So when you think about it, OPC UA really gives a system ability to be interoperable in that it overcomes all the integration issues that we face with traditional systems with their particular, either proprietary or we'll just call it favorite protocols. OPC UA is based, it has an open foundation for the standard. The approach they take is that systems can be built using this tool without specifying chips, operating systems, languages, that kind of things. So really, when you start thinking about open systems, what you need is open interfaces and open standards. And OPC UA is an excellent example of an open standard based technology. And then you chime in a little bit, maybe there's some history with OPC that is confusing that the original version of OPC was built around COM and DCOM from Microsoft. And so, you know, a lot of people still think that OPC is stuck in that world, but it's really not. And so there are commercial versions of OPC stacks that come with Windows, Linux, VXworks, I'm sure there are others. And there's a vibrant open source community there too. Oh, okay. I think that's an excellent point. Yeah. And well, you know, for the listeners, you know, UA is the backbone of the information model for the OPAS standard. So I think our next question here is, let's see, are there any particular software knowledge, or is there any particular software knowledge or familiarity required? And I'm assuming that's the question there is related to software or integration of the OPAS standard. Dave, I think that might be a question for you. You have two days. I'd say you have to be more specific than that, but I remember reading this question in the Q&A, and I forget it exactly, but I've only just started implementing an OPC UA product. And what I found helpful was to have a little bit of a tutorial on an OPC UA, and then the various stacks come with, like, libraries for different languages. So I'm using the C++ one. There's a .NET one, and there are Python ones, and you know, you can probably find Java ones, and all kinds of things. But I would say that, you know, if I didn't know C++ and I didn't know the standard template library in C++, I would be struggling quite a lot to integrate OPC UA into my product. Now, on the flip side, maybe there's a question of if you're going to use OPC UA not so much implementing it, but use it in your plant, what do you need to know? And I haven't done that, so I don't know the answer to that. But, I mean, certainly back in the olden days of OPC before UA, there was a set of stuff that was really pretty important to know about how to set up the security and the passwords and that kind of thing. So, does anybody have some experience on that side, the using side? I'll add there, you know, the vendors products are starting to implement OPC UA. The use of OPC UA for me as an end user, I want to use it in the product. So, when it comes to actually, if programming or system development is necessary, I'd recommend you find a good system integrator who has some experience and exposure to OPC UA and is willing to work on the system and help you get it working, right? I think as more products become available and it becomes much more widespread than the OPC classic, we'll start finding that it works a lot of the same ways. It has more features, which since it offers the ability to have the information model, which is in the standard for the OPAS, it is really the solution of the future. I think as far as other technologies, the same issue exists. Depending on how sophisticated you are in your use of your equipment and engineering of that equipment, then it would determine whether you need systems integrator help, vendor support, or you're capable of dealing with most of it yourselves. Now, we'll say that the open standards approach of the OPAS is really important in that it's a lot easier to learn those open standards than it is to learn the proprietary methods of vendor X or vendor Y. And so that is my perspective as an end user. It is slightly different in that you have to learn the open standards at some point, but once you do, if you change vendors, you won't have to learn any new standards with open. I've got one question that will change gears a little bit. But then we can go back to probably more of the technical aspects of the standard, but here's a question from Steven Stanford. DCS vendor business models are still predominantly product to margin driven. Is this a barrier to adoption of OPA? Will the nature of contracts need to change, for example, away from product sales towards rewards for the delivery of benefits shared between buyer and suppliers? So I think this question more so speaks to the changes between actors within the business ecosystem. So would anyone like to take that one? So I think we certainly anticipate some changes in the business ecosystem, whether that will change to more of a, I like the suggestion that the person suggested there where instead of selling you a product, I'll install a product and take a cut of your savings, that kind of a thing. Those kind of metrics are difficult to define, I think, but it's an interesting idea. So I don't know how the pricing and delivery kind of mechanisms will shake out in the future. For example, we're talking a lot about separating hardware from software in these products where today, when you buy a Rockwell Automation Controller, you generally get software and hardware all together in one price and it's not really clear how much you're paying for either of those things. So if we were going to develop a product where you could put anybody's software on our hardware, then we would need to find a way to price those separately and that might be a difficult problem. So I think I can say with confidence that we don't really know how it's going to happen yet, but we do expect something to change. I guess I'd be interested to hear if any of the audience has a suggestion for how they'd like to see that market change. Yeah, or how they, any predictions that they have, I'm sure with that appeal, we'll get a couple. I have... So Anil, if I can just add to that. Yeah, following up on what Brandon had said about the whole digital transformation and the ability of the systems as well as Gene's comments on having flexibility. The move towards sort of the open standards is in some sense inevitable. It's a question of when it is going to happen and how fast it is going to happen. Right. I think we're in that case. I think the analogy to the software defined networking is also very appropriate where, you know, when Cisco and others used to sell proprietary routers and, you know, you were locked into that system. Versus, you know, after SDN, Cisco said, you know what, this is the new way this game is going. And they figured out how to change from proprietary network and routing to more of the selling services and more value added components. That's right. I think that change is happening and it's happened in other industries. It is going to happen in this industry as well. So, and it's really, I think going back to this is not about putting suppliers, you know, disadvantages suppliers or changing their, you know, it is going to change the mode of operation. But it's really about eliminating the inefficiencies in the system. Right. I mean, a particular supplier may have relationships with existing, you know, their own existing suppliers, sub suppliers. And, you know, that doesn't necessarily allow you to get the best in class service or a product. And so I think this is all about eliminating those inefficiencies and creating value in the business model. Got a question here. Control systems are designed to last 20 to 30 years. Do you see this technology as a disruptor like IOT where end user organizations upgrade early to replace these systems? Or do you see this as a transitional technology that will take years to take hold? I see it as a disruption. And the reason is if you look across your automation system, the lifetime expected life, you know, of this equipment and the pieces parts are different. We know that wiring lasts many decades. Instruments last decades. I O generally last a decade or two computers. Well, you know, three to five years from now, we want a new one. If you think about Moore's law, it is always progressing. If you think about the need and the demand for better software, new efficiencies, new optimizations, that demand is going to come. So when we start looking at what the, you know, OPA is proposing in the standards is somewhat of a, we start abstracting away software from hardware. And even in the hardware world, maybe we abstract way IO from compute. And so if you think about it, you might need a stronger computer. You know, and in our desktops, you imagine we don't need a new mouse. In our automation systems, we might not need new analog input cards. But having a better computer is something would be advantageous. Obviously, it's got to be a business justified. We're not going to trade them in every year. But the idea that somehow the computer technology from today is going to be useful in 20 years. I think we've actually learned that lesson and that making me hold this computer for, you know, 1520 years makes me hold it way past its prime and has impacted my ability to generate benefit for my company. So I think that in the brownfield world, there will have to be a conversion. And that will take some amount of time. But I do believe the technology itself that OPA represents is really a disruption and a giant step change. That's a good question that I appreciate you asking it. I think from my perspective, the answer is yes, it'll take years for this to become the normal thing. So for sure it's not going to happen overnight. But I also expect that although plants will be designed to run for 20 years, we hope to make upgrading the control system incrementally and easy enough that you don't wait 20 years. And at the end of those 20 years, you have a thing that's completely junk. So what we're hoping is that every, you know, like Dave said, every time there's a significant technology change, like five years or so, that you'll start to pick apart little pieces of your system and upgrade those little pieces. And so instead of having these huge, huge upgrade events every 20 years might have a smaller upgrade event every five years, something like that. That's kind of what we hope happens. So essentially what that would mean is that within a system that's installed to last maybe 20 or 30 years, say you're wiring last two decades, your computing resources would not necessarily have to abide by the same kind of lifecycle. You can update your computing resources more frequently. And then, you know, some of the other components within your system, like the end devices or your level controllers or your temperature transmitters or your wiring can, can live out there. Yeah, yeah, literally, they can live out there. So wiring can last 50 to 80 years, easy. Instruments depends on their useful life. And they do every piece of electronics has that, but the computing capability as the business evolves and capabilities, you know, progress, technology advances. You know, that's the kind of thing if if we can turn this kind of 20 year upgrade into an evolution and it happens, you know, done by a maintenance technician, and not by some multi year large cost project. I mean, that is that is the goal behind some of the standards activity, at least from the, you know, my company next on mobile, we look at that very, you know, very strong benefit down the road. If you can use standards, you can change the parts you need to change when the business says, let's make it better and we can, we can justify that expenditure. Yeah. The next question is, does this standard apply in the services industry? If yes, how can it be used in the process innovation or re engineering phases? I think that that question is posed from a perspective of, you know, maybe like Brownfield, Brownfield asset kind of rework or upgrades something something kind of probably more of that nature. You know, I think the services industry when we start talking about especially the conversation we had earlier about roles in the marketplace. If you have open standards based technology, then you don't have proprietary lockout, shall we say. We know there are suppliers of services that have specialized in various proprietary technologies. And if you were to go to more of an open standards based than everyone would be able to participate in that activity, not just develop some ability. I think that it allows for more innovation as well. And innovation is one of the key pieces of all this. That with open standards, you don't have to worry about can the innovation work in somebody else's proprietary world. They're all open standards based. You can start using it and it doesn't matter if your products were bought from vendor X or vendor Y. I think those are the pieces as far as services go. And so I liken this to the maybe the computer world back in the day where mainframes were the computers of choice. You could only get support and service from the vendors that sold you those equipment. We look at today, you know, if you have a portable computer or tablet, you know, you can get that kind of service from anywhere. Many people are capable of performing the services they need to do themselves. So I think that the marketplace will open up for services. I think we have an OPAP has a liaison with the CSIA and specifically because we think they will play a critical piece in providing services for these open standards based systems. I think we have one last question here. Can you talk about the differences between open standards, open systems and open source software? And are there open source options for designing, executing and managing the code on DCNs? Something synonymous to Java piggybacking on David Ford's analogy. That is a really great question. I think some of those questions are questions I had when I first started working with OPAP. So I'll start by trying to talk a little bit about the three different kinds of openness. An open standard is one which anyone who wants to implement the standard is allowed to implement the standard without, I don't know if I want to say, without any restrictions on it or without unreasonable restrictions on it. But there are some standards which you have to license the standard and pay a royalty to the people who invented the standard and that kind of thing. And that's not what we have here. What we have is a standard which was collaboratively developed and is available to anyone who wants to implement it. I guess I don't know a good example of one that's not open, but anyway. An open system is one in which any vendor can install components that participate in that system. So if we think of maybe the difference between, I'm going to say, a Macintosh and a PC, the Macintosh had, you know, you open it up, it has all Apple boards inside. The PC, you open it up and it could have any number of companies inside. And that's because the interfaces to the internals were defined in a standard. And so then other companies came out with products that implemented that standard and they were able to work together. Similarly, they could write their own software and run it on that system. So an open system is one which allows various vendors to participate. And there's a whole range of different ways you could participate. You could have access to the data inside. You could have the ability to run your own software. You could have the ability to substitute in your hardware for some other hardware or to put your hardware beside other hardware. So there are a number of different ways that you could participate in that openness and you wouldn't necessarily participate in all of them. And then third one was are there open source software? So I don't follow the open source community all that closely, but the one I mentioned earlier, there is an open source OPC implementation. I know that there are open source PLC implementations. So I know there are some open source projects. I know there are open source communication stacks. And maybe we should talk just briefly about what open source means, is that that's a collaboratively developed implementation of a product. And what we would call the intellectual property is collaboratively developed. And that's different than an open system, where in an open system, I might allow other, let's take my example where I have a controller, a PLC, I might make it so that other companies can access the data in that controller or that they can run their software programs in that controller, but I might not actually give them the operating system source or the schematics. And so I might consider that to be kind of my secret sauce in my company or where I can differentiate and make a better product. And so I'm not going to give that away to other people. So that might be the distinction between an open source product and an open system if that's helpful. Yeah, we could ask those three items, questions regularly within our company because a lot of people think of open source as free. The reality is open source, if you're really going to participate, you have to help support and help advance that open source software. So it's not exactly free. The software would obviously be available if you wanted to use it. But I think that there's a lot of misnomers about what open source can or can't do in terms of security and how well it might work. A lot of products are actually built on some open source building blocks. But in the end, we need a marketplace. And what that means is that people will bring their IP and their ideas and be able to sell them and generate economic value for the companies that they represent. I think the open standards allows them to interoperate with other people so we can create these open systems. And that's really the big piece. I'm not against open source. I'm not an advocate that it should all be open source. I think that especially with automation, it should all be tested and validated. And if open source can fill the build, then great. I'd rather open standards so that I can build open system and procure or get the products, whether they be software or hardware, from the vendor community. It is definitely a question you have to put in your mind. And others have to remember they're not the same thing. Open systems and open standards and open source are not the same thing. I have one final question. This is one that'll go back to OPC UA. It says if it's all based on OPC UA, why do we need OPAS? There's more to an automation system than just the communications and information model. So I took a swing at that in the chat and try to interrupt, Dave. Go ahead. I think it's a good question. And the answer is, well, maybe if we all agreed that OPC UA was the right thing to use, we wouldn't have this committee. But without OPAS, before OPAS, we hadn't really decided that OPC UA was the way a process control system should be architected. And then once we decided on OPC UA, there's quite a bit of work around how do you represent a particular thing in OPC UA? So OPC UA is fabulously flexible. And so what we essentially did was constrain OPC UA to achieve higher interoperability between OPAS products. So what would be an example? Like one of the examples would be, you know, we have to implement certain client server profiles, and we represent our signals in a certain way. So when you have two different products that are both talking about a signal, they can hook it up and good things will happen. So I'm not saying that that wouldn't have happened if OPAS didn't exist, but it hasn't happened yet. So what OPAS tries to do is find these good underlying standards like OPC UA and then add some prescriptive text about how exactly to apply that standard to our domain. And in that way, to make the standard work better for us and to achieve what we call our quality attributes, which are the big ones are things like interoperability and interchangeability and security and stuff like that. So that's, yeah. And then I'll go to where Dave DiBare was about to go, I think, which was there's more than communication here. We're, you know, OPC UA is our transport, and we've defined our information models in OPC UA, but we also have mechanisms for exchanging programs between various vendors. So there's an import-export format, which OPC UA does not talk about. There's some offline representation stuff that's not an OPC UA. There's some physical platform definition that is not an OPC UA and will be, you know, even more thoroughly defined in the future version. There's things like how to commission nodes or how to manage them and how to orchestrate them. That's a calming section in the spec. Anyway, so the point is that communication transports is one piece of the automation puzzle, but there are many others. That's a good answer. You know, essentially saying that the OPAS standard is going much further just addressing the communication protocol or the communications between devices on the system. Right. That is a big piece, but it's not the only piece, and that's why you can't just say, you know, use OPC UA and everything's, you know, that's all you need to do to do OPAS. It's much more as Dave put it. All the parts have a component that can use and might rely on OPC UA, but there's other things that will not be OPC UA-based just because of the nature of what they are. That's right. And well, you know, David, to take that a little bit further, there are already systems that are UA-based that are implemented by, you know, different assets and integers, and there are still shortcomings in those systems as well. So, you know, the, well, you know, I guess, you know, to kind of sum up what David Ford said, UA is not, it doesn't completely solve the problem because, you know, there are existing standards that, there are existing systems that are all UA-based. So, I think we've got one last one here. It's, no, okay. All right. I think that'll conclude our Q&A session for today unless we have any, yep. Oh, sorry. I'd say that Patrick Simon asked the question, isn't, it is an OSI enterprise approach OPC UA all layers. So, I'm not quite sure. I know what the question is. Yeah. So, I don't know. We want to talk about all about how the OSI model would apply here. You know, this is why, this is why maybe the OPC UA is not, is not everything in the system. We have applications, automation. The automation, you know, runtime application, it might communicate with its, I'll call it friends, the HMIs, the historians, the other controllers, if you will, with, you know, data using OPC UA, but actually an OPC UA is not running my PID algorithm that's controlling the level or flow. The historian application isn't, you know, it may communicate and use the information model from OPC UA, but that's not the critical piece of what it's doing. And so, that's maybe the part about the OPC UA. It fills some very nice roles because it's got a lot of features, way more than the OPC Classic had, but it's not the entire system. And so, I don't think it's the whole stack. As far as the networking, and I think that's where the comment may be being added, there's a lot of what we call OCF is based on OPC UA, but we do have some things like Redfish and some other aspects that are not OPC UA for system management. Any last comments, David Ford and Mohan? I think we'll just echo the, you know, call to read the standard version 2.1 and join 100 plus friends and participate and contribute to the development of the standard. And pretty soon we're going to start seeing products and systems, commercial deployments, and people starting to generate value from this. I think if you really want to get on the bandwagon, that is the time. That's right. Good point, Mohan. And as you're reading through the 800 plus pages of the specification, I'd recommend any questions, queries, concerns, or suggestions. Point all of those to OGspecs at opengroup.org. And that's an email address that's managed by the form and we will see all questions, comments, and recommendations that go to that email address. So I highly recommend, you know, like Mohan said, get a copy of the standard, start reading, review it, and then please send feedback to that address. And with that, I will turn it back to our host, Steve Nunn. Thanks, Anil, and thanks to all our panelists. David Fort, David DeBurre, Mohan. It's great to have you share your insights and answer those questions. So some great stuff came up there. Thank you very much to everyone who asked a question. I hope you got them answered to your satisfaction. And thanks again to our speakers and panelists today. So that largely concludes today's activity. I hope you found it useful and enjoyable.