 What we want to do is we now have all of our speakers and panelists here. So we would like to open this session for questions. So if you do have questions, please, as John mentioned, put it in the Go to the Live Now box and then type in your questions. So I think we did get one from a previous case, right? So did we have a question on Neil? Did you recall the question that was on with respect to the system? Unfortunately, the previous one closed. We'll receive about a dozen questions, Mohan, this is Luis. OK. I tried to answer one. So maybe we should start, probably, from those. Let me start with this one. So are the IO modules connected in a communication boss or are they assigned to specific PLCs? I mean, we're not talking about PLCs or here necessarily. We're talking about the distributed control node that's performing control functions. It might be a PID or a logical function. In either case, we're talking about the DCN having the ability to have either a hardware, local IO, or being connected to an IO subsystem of some sort using interfaces. The details of that is described in the OPALS standard. So I will invite you to review that. I just thought that that was important to clarify. Did anybody else want to add something to the description from Luis? Well, no, this is Don. It's not an ad. It's just a reinforcement of the points that Luis made. And depending on the profile, which is the specific configuration of the DCN device, but the general principle is decoupling of interfaces. So I would say the strongest answer we can give to that question is, for the majority of the profiles that we envision, there will not be a close or proprietary association between IO and compute. That will be software assignable. And that's the takeaway I'd like to leave with the audience. Great answer, Don. Thank you. So Anil has a couple of questions on here that I guess he gathered from the previous session. What is the expectation for DCN gateway to be universal or specific to one or more legacy systems? Is the gateway that was described, is it specific to a legacy system or do you perceive it to be a universal one? Well, I think Dave answered the question best, maybe if Dave can have another go at it. I'm sorry. On the gateways, the universal side of the gateway will be the OPAS OCF side. And this will be standardized. And then, as far as a connection to each existing system, OPAS is not going to standardize that because it deals with the specific of each system. My prediction, personal prediction, is that you'll see the market drive suppliers to develop universal gateways on that side, or at least gateways that support many different protocols. Of course, even things I mowed about and then up to other more recent technologies be supported. Now, I think the hardest part will be if there's a proprietary DCS network that's protected and totally proprietary, you probably have to depend upon that supplier. But there may be other ways to connect systems with other protocols, too. And just to build upon that last question Don answered, once information and once process data or any values from the existing control system are into the OPAS gateway, one of the prime building blocks or foundational principles for OPAS is that all data will be available to all DCNs in the ACP. So therefore, even if the IO comes into one DCN or the gateway brings data in, all the other DCNs can access. So thanks, Dave. And sort of similar idea with the connection to legacy systems. So this is a question about interoperability of components purchased from one vendor. And this question actually is yesterday a particular vendor name. But if you purchase a component from one vendor and you install it onto a different, onto the system, what other equipment would I need to make that OPAS system work and everything talk to each other? So in this case, the questioner has put if I purchased a level sensor from one vendor, installed it onto a system. And I assume they are talking about an open process automation, system made of open process automation components. What other equipment would I need to make that OPAS system work and everything talk to each other? Maybe I can help with that a little bit and others can back me up. The OPAS standard is being designed to work with any number of field devices from different manufacturers that use common protocols. And this goes down to the most old ones. If we just look at analog inputs, whether it's 4 to 20-year voltage, digital input, digital output, those can be supported. Protocols, field digital protocols, heart, foundation field bus could be because OPAS is not standardizing field protocols. What we want to do is be able to build these gateways. And it may be a gateway not to another automation system, but to field protocols. We expect suppliers who will develop these and then bring that data into the OPAS system. So if what you mean by one supplier system is an OPAS system, that data can come in from the field and then be shared among all the DCNs. OK. Just to reinforce the point, we have a very simple scope picture, which I think Louise used. And the scope boundary, this is exactly, I'm just reinforcing what Dave said, is the field-facing side, aka the south side of the distributed control node device. So whatever evolution occurs in field networking and communications technologies, be it wired or wireless, the OPAS architecture will adapt to that. And another point that Dave said is, once you get data into a system consisting of OPAS conformant products, the conformance to OPAS means the interoperability quality attribute will be delivered and enabled largely by the OPAS connectivity framework. So that's the general answer to the question, I think. Thank you, Don and Dave. So I skipped over one question earlier. So it was, what is the difference between OPAS and the Namur Open architecture in terms of control system architecture? So I think we get this question a lot. So I would maybe like one of you to comment on this. Do you mind if I try to answer? Yeah, you're a good one, Louise. Go ahead. Well, so what I see in the Namur Open architecture approach, and I'm going to try to make it very simple and short, their vision is the core process control system remains in touch. I mean, you have the ability to extract and bring information into the, or from and into the core process control. But essentially, you're trying not to disrupt the process control as it exists today and then enable applications for monitoring and optimization either at the planned level or the corporate level. In the open process automation forum and the scope of the standards, we have discussed in the previous answer that Don made and we presented in the scope. We're actually revisiting or envisioning a new way to develop the core process control. And that is kind of what I see as a key differentiation between what we're doing in OPAS and what the Namur Open architecture does. Definitely, as demonstrated also in the case of the BSF example that Mohan presented earlier and Ron presented earlier, there are users that are already experimenting the core existence, for lack of a better name, of these different industry initiatives and standards. And the industry will support multiple approaches to automation. So it's not negating, I mean, OPAS is not negating or in conflict with what Namur Open architecture is trying to do, but the scope is different. That's kind of my answer. I hope it's clear and being confused more. If somebody wants to add to it, I'd be glad. Yeah, if I may. So this is a question that we're asked often. And so we, I say we, it was a paper that we published at the IFAC 2020 World Congress. We addressed that question specifically. So if I'm going to refer to the OPA reference architecture chart that's basically on slide six of this deck, but we don't have to go back to that. If you can just have that mental image of the OPA reference architecture, which has the DCN edge devices at the bottom, including the gateway connections to either existing non-OPAS conformant control devices or even to things like wireless gateways, that basically gets your data onto the OPAS connectivity framework network, that industry standard network technology. Now there's no requirement for those data to be passed through any compute nodes performing control functions. So even though we show the OPAS connectivity framework just as a flat line, it doesn't mean that in implementation you will not have segmentation zones and conduits within that network topology. So basically you can achieve the benefits and the intent of the Namur Open architecture by a holistic architecture that enables data acquisition and transmission of data to higher parts of the stack without having to have those data pass through the closed loop control performing nodes in the architecture. And we elaborate on that concept in the IFAC paper. So Don, I think that you sort of addressed one of the questions that came up, which was question on continuity to higher level systems. So assuming control system DCS is replaced by OPAS based system, how will connectivity be maintained with higher level systems? Yeah, I don't want to monopolize. I think any one of us can answer that question. I'm going to ask one of the other panelists to have a go with that. If nobody steps up, I'll call it. Yeah, Yaku's back. Okay. Yeah, I'm back. Well, our view is that we will have way more capabilities to connect to the outside world than we have today. We're kind of limited in what we can do today, first in bandwidth as well as on the information we can share with an open framework and open platform and the capabilities that actually brings. We believe that this will actually allow us to transmit more data from the system as well as get more data into the system than we can do today. Obviously that brings challenges. We understand that, but I think the architecture also shows that we expect to have a lot of connections to, there's not a lot, but on the architecture page, what we do expect to have a lot of connections to cloud and other platforms that will give us more capabilities than today. And that's not just the up of standpoint, but it's also our corporate standpoint. So maybe others. Yeah, and I just wanted to add to Jaco's point that the whole idea behind this is sort of, taking that layered approach that has been there and sort of turning it 90 degrees, making it more flatter architecture, right? So that allows for a data transparency to go from your business systems or your NES to down to the level that you need to grab the data that you want to be able to then make real-time decisions. So I think that that is one of the key features of the architecture here. All right, so there was another question about, okay, understanding is that OCF is based on OPC UA, are there any other protocols in the pipeline? Well, we considered other protocols, but I can tell you we converged the collection of companies that has been active in the OPA forum since the beginning, again, customers and suppliers. We converged pretty early, and this was a convergence that occurred, I think even in 2017, that OPC UA is going to be the basis of the OPAS connectivity framework. We talk the principle in the standard of standards way that the open group works is, we certainly want to envision the possibility of other means for things like communications and interoperability. And I could just drop some buzzwords like MQTT and the like, but honestly, we are focusing pretty heavily on OPC UA. We could, if you guys want to elaborate, we could start to differentiate the value of OPC UA in the information modeling aspect versus the message packets and the protocols on the wire. But I don't think that we want to go there in this session. Thanks, Don. So, Ron, there was a question about OPAS offerings. Do you want to talk about it? Yes. So the question is, are there vendors already offering OPAS ready solutions? IO, gateways, DCNs, operator workstations, et cetera. So I'd first say in the spirit of the terminology today, there is no such thing as an OPAS ready solution. The direction that we're heading is, as I said, when I was talking about certification, defining a formal certification methodology that suppliers would need to take their products through to have OPAS certified products. So just to be clear, ultimately what we're targeting is the availability of OPAS certified products. And while there may be vendors today who are closely following the development of the standard and who are prototyping, we don't have the certification process formally in place yet. We're still in the process of working through the definition of that and the mechanics of everything that's necessary from identifying test cases to accrediting labs and onboarding them. So as the OPAS standard solidifies, and I expect that the next version should start to solidify towards the latter half of 2021, then our target would be approximately a quarter after that, we would have a formal certification process in place. So just in summary, once we have a formal certification process in place, then it will be up to the individual suppliers to pick up the challenge to take their products to the open group for certification and then have them available with the bright shiny OPAS certified logo. Hope that answers the question. Ron, I was just gonna add to that. I think part of that question too was how do I get my supplier vendor to offer those solutions? And I think it's important for us as end users to begin expressing our interests and desire and at some point requirement for that offering. And so I think now's a good time for us to start mentioning our awareness and interests of our suppliers and asking them what they know about and what their plans are. And at some point when we start making requests for solutions and quotations, we start putting that in either at least as alternatives if not a requirement at some point in time. That's one point, fully agree. Yeah, thanks, thanks, Steve and Don. And I think that was very helpful. Steve mentioned, yeah, I think we talked about the fact that look, I mean, at the end of the day, the end users are going to write a check, right? And I think they're gonna start requesting that more and more of these, they're gonna start asking their suppliers about the roadmap that the suppliers have towards an OPAS compliant solution. So I think that's the moment that you would see that's gonna drive the marketplace to offer those solutions. So I have another question here. It says, okay, there are already PLCs that support OPC UA. Does that mean they would be OPAP ready or are we waiting for application portability? Yeah, I think I can talk to that or at least kick off the discussion. Having connectivity via OPC UA is certainly an important enabler and a step towards fitting into the OPAP ecosystem. But to be an OPAP certified product, there are other requirements over and above that. It will depend on the specific functionality that the product offers because there are some products that encompass certain parts of the specification, some that focus on others. We've got them defined in terms of different profiles and suppliers will bring their products and certify against specific profiles. So at a high level, it will depend on the profile, but in terms of this question, I would say connectivity, OPC UA support is one of those that will likely be a requirement for many products, but there will be others on top of that. And a very simple example would be security. There are security requirements over and above OPC UA that we have added into the specification, into OPAPs, and those will also have to be satisfied as part of the process of going through OPAP certification. Does anyone want to add to that? I'd like to add to that. I mean, just to take the opportunity to invite the audience to really visit the OPAP documentation that is published, and get familiar with it. I mean, as you pointed out, right? So OPC UA is a key element for connectivity and interoperability, but there's more. So I just wanted to plug in the invitation to really visit the documentation and get familiar with the standard. And that's kind of a free tie back to what we were discussing earlier through the adoption steps. You know, what else do you need or what else will provide a benefit for your iPhone situation to really build on and tie to what are the requirements outside of OPC UA you will need to take, right? That's kind of my only addition. Yeah, I want to give a practical answer to the question. I think it's perfectly in the spirit of this industry adoption workshop. When we take a look at the prototyping projects that have been done by the operating companies, so ExxonMobil has been pretty forthcoming in our proof of concept and prototype. You heard about the BASF demonstrator, two other prototyping projects that we can talk about in the public domain. Georgia Pacific has started on an OPA prototyping activity, as well as there was a press release earlier this week by Saudi Aramco that Saudi Aramco is started on an OPA testbed building activity with Schneider Electric. As a practical matter and a direct answer to the questioner's question, currently available products that have attributes that are kind of heading in the right direction of OPAs, that has been one of the criteria that we have used to select products for incorporation in our prototypes. And just to reinforce the point Ron and Louise made, you know, they're not OPAs conformance certified products yet, but clearly the supplier is thinking in alignment with the vision. So that has been a practical consideration in the product selection for our prototyping. So are there currently available today OPAs conformant products? No. Are there products that are headed in the right direction? Yes. Okay. So I think that there is a few more questions in here. So let's see if we can get through them. Will there be OPA for OPA system integrated courses, technician, sorry, training and certification exams that qualify their understanding of the design and implementation philosophies as well as verification validation methodologies? Wow, that is an excellent question. I've certainly seen the open group take the lead in this area for other standards and specifications and offering certification. Jaco, I don't know if you're on from a business perspective or Louise, would you like to comment on that? Yeah, I think it's a great question as well. And it's one we discuss a lot. So the system integrator role is a role that will actually put the system together, make the systemness of the system, make it work. Well, it will also be looking at other elements that are not necessarily defined in OPAs itself. So that role is an extremely important role and I think the education track and how we have to educate anyone who is certainly getting a lot of attention, attention I should say. And I think I'm not going to say yes, we're gonna develop a full program because I think the system integrator will always have to cover elements that we cannot cover in the OPAs program. But I think with the, for instance, the CSIA, we will work on that track to see whether we can develop products in educational material that will help system integrators to get started. And there are arms around this. Anyone else who wants to tap in? Yeah, I'd like to add something to that Jaco, if I might. You know, and that's important. You mentioned something that is the collaboration with the control systems integration organization, right? And as Ron mentioned in the introduction that we did earlier today, you know, we want to go far so we're not going alone. We were working with others. So we definitely need to define what the other participants in the ecosystem and that includes system integrators and others. I mean, this is not an end user and suppliers game. This is a multi-pron, multi-role ecosystem and that was also presented. But in that, we need to collaborate to define the ultimate goal of having the right type of skills that's available as a way to enable this, the adoption of OPAs in the industry. Having said that, obviously for the system integrator to make a business out of integrated OPAs certified products we need to have the OPA certified products first. And as much as we can help the system integrator community to familiarize with OPAs, I think it's important to also put the priorities of the forum into having the certification plan completed in any case. I think that's drawn already alluded to that as well. Okay, great. Thanks, Louis and Shaq. So I think there are a few more questions in here. So are there any lifting repositories or resources available for building DCNs? Probably, I would say if you wanted to learn how to build a DCN, I would start with understanding the OPA specification by leveraging the resources at the open group. And I think as seen elsewhere in this presentation there are some links where you can download the specifications and start to work your way through them and understand them. There are also resources that we even talked about from a business perspective why you would be going down this path if you need to answer those questions with your leadership team. But at this point, those are the resources that come to my mind that I would be looking at. And then from there you can cascade into some of the supporting standards that we reference. So if you're not familiar with OPC UA, for example, you would understand where to go, which documents there to focus on. If you need to learn more about 62443 security, we can point you in the right direction. Anybody else want to build on that? But just to focus, OPAs, the OPAs spec part seven addresses the physical characteristics of the DCN. So I would direct the reader's attention to OPAs part seven. We published version 2.0 of OPAs has the first go at part seven and it's going to have a significant upgrade in version 2.1 which will be published in a few months. Thanks, Tom. So there is another question. For a modern gateway, you probably need the latest version of the vendor system. Will there be vendor lock-in until legacy system is completely gone? Well, I'll take that one, another gateway question. That's a good question. It will depend upon the automation system that exists there and what's available, but to access, for example, the worst case, most severe cases, if there's a DCS system and the DCS supplier does not support an OPAs interface, it will be a challenge. Other DCS vendors are already starting to provide OPAs interfaces based on OPC UA. And you'll see this grow. And so I think that market pressure is going to drive support for OPA gateways to all the existing systems. Now that said, until the legacy equipment is totally gone, that gateway is needed. So yes, that is accurate. Okay. Thanks, Dave. There was a question I skipped over earlier. So will there be safety instrumented systems that are OPAs compliant? I think I would just direct us to the scope of OPA, the forum's scope in terms of developing standards. We did exclude the SIS from the standards here. Doesn't mean you cannot talk to those systems, but that is out of scope from OPAs. Yeah, Moa, if I can just add a little to that also. It's very typical in the process industries that any advancements in the SIS space lag behind what happens in the BPCS space. For example, use of bus-based IO is very common in the basic process control world, but it's not common in the safety applications yet. So I think it'll get there eventually, but that's pretty far into the future. It has to be proven in use first in order to be used in safety applications. Thanks, Julie. So I did see one other question come in, and I know we're coming to the end of the time commitment. So I'll pose this to the suppliers at large. How do control system vendors differentiate themselves with OPAs? Okay. Well, I mean, I'll start and then others pick up is, you know, for my employer, what we see is OPAs is a decades-long trend of information technology coming into the operational technology space. Networks are ether-based now. 1.20 years ago, people said it was impossible to do that. In the late 90s, we saw windows, platforms, used operatist stations, and the price dropped. And so we see this as just an ongoing trend that's inevitable. So we want to be leaders and try to change how the industry and our company is going to respond to new environment. So we think there's room. Also, we see software as a real value generator for end-user. So we want to focus on that and provide the value where customers, you know, obtain it. I don't know what others see. I totally agree with the value creation, right? So definitely it's the OPAs gives the opportunity to develop new ways of delivering the value that the end-users are asking for. And it's, to me, it's a matter of, you know, as you say, they're getting there earlier, but also having the vision to determine where you want to be the best in class, or is it that you can innovate and create new ways of delivering value? I think that's a key. Great, thank you both for the answer. There is one, maybe this is the last question we want to take is what are the challenges during integration of the testbeds? Any lessons learned that can be shared? Don, do you want to? Well, yeah, I'll just cite, I mean, sure, there's a learning curve whenever you start anything new. And speaking for the Exxon Mobile team and our research program and the systems integrators and hardware and software suppliers that we have used over the past five or so years, again, with our proof of concept and prototype system, you know, we've documented much of those learnings and pain points in the IFAC World Congress paper. Again, it's still in the proceedings, so it's a little bit difficult to access. But I don't want to take the time here, you know, to go through that long list of learnings that we have acquired. The takeaway I want to leave with the audience is that with our proof of concept and prototype system, we demonstrated the quality attributes that we aspire to get, and that is to say interoperability, interchangeability, configuration and applications portability with systems made up of component products sourced from different suppliers. And we were able to achieve those quality attributes by using what we saw at the time of where the OPAS standard was heading. So I'll just, I'll stop there. Again, we've written a lot about it and the very technical level in the IFAC paper. Thanks, Don. So with this, I would like to try to close the Q&A session so I do appreciate the questions that came in and I hope you took away some from here. So in the remaining time, what I would like to do is sort of summarize where we are and then provide a wrap up and key takeaways, reinforcing many of the points that our panelists made through the presentation. So what we have done is, you know, so first I wanna thank you for your patience in sticking with us, especially through the audio issues and recognize it's not easy with different time zones where it may be interfering with your daily activities. I wanna thank the Open Groups events team for their efforts in putting this workshop together. I think we're continually learning and we'll get better in the next one. Okay, so while we are there, John, yeah, thank you for the reminder. We do want to run that final poll so that people can respond to it and then, you know, we'll use that data to refine our ability to host these workshops, okay? Yeah, thanks, John. So what I do wanna say is, you know, first off, yeah, and by the way, so we do have, I mean, I do wanna thank both the speakers for the sessions, the panelists, as well as, you know, a lot of people who have done a tremendous amount of work who are not in the panel right now, but contributed to the development of the workshop. So my sincere thanks to all of you. So, you know, what we have done is, you know, just to summarize, we've shared the vision of the forum on building an open standards, secureable, interoperable process control, automation architecture. So, and the key for us is really the transparency and visibility of data without the limitations of close processes. So, we'll give you a little bit of how the workshops are organized within the forum and how we're doing a business approach to try to figure out the technical problems to be tackled. And as you heard from Steve, Jaco, and Julie, I mean, the benefits to end users are really more competition, greater flexibility, data availability, and managing obsolescence. You know, for these are sort of very critical parameters for end users. I think we think the standards and the work done there will really help as we develop the marketplace. So suppliers, you know, the question came up on suppliers to distinguish themselves. I mean, right now, as Jaco mentioned, you know, you don't want just a good enough solution to be able to incorporate and say, yeah, this is the best I could come up with versus a concept of specialization and differentiation. So focus on the things that are the most, you know, where you add the most value. So Dave Emerson mentioned about focusing on software and trying to make sure that the suppliers focus on their core strengths. And then that way with the standardized interface, then we don't need to worry about the integration aspect as much. So that would be the, you know, other kind of takeover. So the second point I really wanna make is, you know, we talked about the intro to the standard, the OPAS standard, and what is coming up in terms of coming attractions. Communications, configuration, application portability, the key aspects of the standard. And, you know, those are the ones that are being worked on right now. I mean, you've got version two of the standard and you know, more on deck to come. Okay, so keep an eye out on this space, right? So, and Luis mentioned this point is that the pace of change in the industry is really accelerating. And, you know, really, I mean, everywhere you look, you see this software decoupled from hardware that enables new tools, new applications to come in, right? So, and applications that use real-time data, you know, to be able to do predictive and other predictive maintenance and predictive analytics. So these are all going to be enabled by the use of the OPAS standards, okay? So number four is, you know, that the exciting aspect is that, you know, the end user companies are really building example systems to actualize the standards, you know, testing the boundaries and then figuring out, you know, how they feed this back, testing use cases and scenarios. So I think you're seeing this start to happen more and more. Don mentioned some of the end user companies that have started to do this work with ExxonMobil, BASF, Ramco and others making announcements. And you will see a few more come through in the next, you know, shortly. So the second, you know, maybe number five point is, is really that it's sort of time to get prepared. You know, the standards are coming, the market place is coming. And so here's what we would advise. So if you are an end user, you should really, you know, I would have two asks of you. You understand how decisions are typically made but you understand that process of how decisions are made within your industry, your company. And you should engage a list of stakeholders in your organization, prepare them for the coming changes and how your companies can benefit from OPAS. And, you know, as automation people, you guys know the pain points, but again, articulating them to the top management to get there buying as well as the projects group and whatever other stakeholders you have in implementing projects, you know, do talk to them. At the same time, discuss with your suppliers about what their roadmap they see is for open systems. Steve made the point earlier about talking to your suppliers, having an open conversation with them. Because, you know, the more you write it into your RFI, it goes through information, it goes through proposals, you're going to see a response from the suppliers on the marketplace, right? And the question, there was a question on suppliers, you know, look for suppliers, it's status quo is not going to continue because of the rapid changes in technology. And new market opportunity is really being created. And, you know, it's almost like, you know, you have to prepare to disrupt or be disrupted, right? So you should really advocate for your company to get involved and figure out the roadmap of open systems in this. And, you know, one of the key goals here is really the innovation, you know, what we're saying is we need to lower the barrier for innovation and allow new entrants to come in and that way grow the pie. But Dave Emerson and Don Bartosziak both talked about decoupling of software and hardware. I mean, that really allows more innovation to be introduced, a lot of things become, you know, software-driven. You've all heard about, you know, how Tesla was able to manage, thermal manage their older cars doing nothing. You don't have to bring it into the shop. You were able to change the, and extend the battery life by thermal management, by, purely by software. I mean, that's where the industry is really going through. And as Jaco mentioned, you know, it's hard for one company to be an expert at everything. So, you know, the end product system ends up being a, well, you know, it was good enough, we cobbled it together. And, you know, that really doesn't serve the end users and the community at large anymore. I mean, we need differentiation. We need expertise that comes up with opening up the system. So, and, you know, so I'll leave it there. And last but not least, we want, we welcome you to join us. You know, I can tell you that, you know, personally interacting with all of the people in the forum, this is a great community of, you know, both thinkers and doers. So, you know, it's a great place, whether, you know, you want to participate in the business, technical or other aspects of the forum, you can join the forum and participate and benefit, you know, both from your personal standpoint, as well as from your company standpoint. So talk to any of us about how to join. So I think I want to leave it there and I want to, you know, please provide your comments and inputs to the workshop. We hope you found this workshop useful. Please provide your candid suggestions in the polls as well as, you know, drop us a line, okay? So I just want to leave you with this quote. I mean, from BASF, it says open process automation offers a win-win-win for suppliers, end users and solution providers and the success of the initiative becomes more and more likely. Okay, with that, I would like to conclude the workshop and leave you with this sort of, okay, the resources page or just Google open process automation forum and you should be able to get in touch with us, all right?