 All right, good morning and welcome back. I hope you can hear me okay. So let's continue now and trying to address some of the questions that we received before about the adoption alternatives or examples that we have prepared. The purpose of this section is really to go about how to get started with the introduction of the OPAS standard. And the agenda that we have prepared is really, divided into three elements, gaining experience with OPAS standard, going about introducing the standards into existing facilities and then realizing life cycle benefits as an example of these introductions. So let's move on with the first part which is getting standard with existing facilities. As a matter of introduction what I'll do is I'll cover some of the principles that we have addressed in OPAS and go back about the scope. So from the section before and from those of you that have seen all the documents produced by the forum, you might have seen these illustration and essentially this diagram illustrates the different types of components or products that could be used to put together an automation system and highlight those that have been designed to fulfill OPAS requirements in yellow or gold and differentiates those that basically existing automation products that were not designed according to OPAS and in consequence are not conformant to this standard. On the next slide, I'm gonna show you essentially as we illustrated earlier on the first section, kind of what the forum is concentrated on in terms of the scope of the standards. So what we're trying to do in the forum is obviously as we have mentioned to produce a standard of a standards OPAS that is addressing the core automation system infrastructure for different reasons. We are excluding certain elements like safety instrument systems and field devices or business systems. The forum, as we have mentioned, focused on the standards and business practices required to achieve interoperability, modularity and portability of software and hardware components and that basically comprise the process control layers. And we cover within this scope then the sections that are typically found on an automation system like the control on IO, PLC and some advanced controls. So moving to the next slide, we wanted to, in order to illustrate this transformation we wanted to bring a picture that will be maybe more common to many of the users that are participating in the automation space. So we tried to depict the same scope so we kind of reshaped some of the aspects like the control and IO boxes, the PLCs and then some networking infrastructure. And essentially what we're trying to do here is just to show that those elements that we saw earlier in blue and gold basically are now going to be presented in a different way once the transformation starts to happen. So what we're showing really is, in the, when we're represented trying to get a handle around this automation system using OPUS components what we're trying, the idea that I'm trying to present here is how to create this functional parallel between the world as we know it today and the world that exists essentially introducing OPUS conformant products or certified products. So when we talk about today control and IO either process control or PLC in OPUS we're really seeing distributed control node or BCN, this might include physical IO that is connected to the field devices and elements and so on. These might host an application. So the applications that we have it today on the PLC might also be hosted by these devices. Additionally, let's say we can also host applications on what we call an advanced computing platform. We ambition that there will be certain functions that will require, let's say, further computing power for some applications or there might be different ways to deploy automation that will require this advanced computing platform. And then also we'll be able to host applications. But in order to connect this together and to really enable the interpretability that we have presented as a core element in the vision of the forum, we also need to have this ability to connect all of these devices seamlessly. And that is what we have conceived as the OPUS connectivity framework. I will be elaborating a little more as we go through but the idea was to create this as I mentioned earlier the parallel between the world as we know it today and the world that we ambition can be implemented in an automation system using OPUS certified products. Now, some of the examples that we have, essentially we have already illustrated some of the experiences of some users. So as an end user perspective, I'd like to invite Jack up here from Shell, my colleague in the business working group to present some of the challenges in these scenarios, right? So Jack, if you might, Jack, are you there? I'm here. Now we can hear you. I think the system, as more of us did. So, yes, thank you, Luisa. And I'm happy to be here and explain our case. So as you heard, my name is Chocopia. I worked in Shell projects and technology in the Netherlands. And I have two roles in Shell, all in the same function, but I have a functional role and I'll have a support role supporting some of our or most of our assets, to be honest. And overall that comes together in a program that's called DCS of the Future. In that I'm responsible for being the liaison of Shell in OPOP and the more asset role I have, which I'll elaborate a bit more on is on the migration programs we have. So in my asset role, I get to see a lot of limitations of our current platforms. We struggle and as Don already said, we actually would like to see and get more of our current systems. And the reason is that over the last decade, these systems moved from adding value, seeing as added value equipment to being a cost element. There was not a lot of extra additional benefits coming from the systems we use. And we did see a lot of technology advancements in other industries, which we wanted to make use of and use, but that's really a pain point. So we moved from gain to pain. And yeah, obviously the systems are still working fine. They give us the flexibility we always had, but it's not where we wanna go. So that's one of the things I see in my asset role. And as we see that there is also a support role supplier challenge, I would say, a challenge to cope with all the new technologies that are actually being introduced and to introduce them on their current platforms because that's a lot of work. Our current supply is having proprietary systems. They cover everything, they all range from the hardware to all the software elements or most of the software elements. And they have to keep up with all those developments which are taking place in all these different spaces. So that's a challenge. I think our suppliers have, and I'm not sure if they can actually cope with the demand we have because we need new technology to advance in our business. So the whole asset space I'd like to call industry 3.0, which is clearly automating our plans. And as we all know, we're at the end of that. Now, the second part of my role is more a functional role. And as part of that functional role, and that was already said, I'm co-chair of the business working group. And through OPAV and some other platforms, we collaborate in, we see that there is an enormous potential of new technology or when new technology is a great enabler actually. It's looking in the window of a sports car dealer while you drive a Mini. That's how I try to envisage this. You drive a Mini car and you look at this great sports car. And your car does its job. It drives, it brings you from A to B, but not necessarily to C. So that's where I leave this parallel, but you can understand how this feels sometimes. So now looking at our company, and it's probably true for many companies, we have two scenarios we have to look at when we implement new systems. And obviously there's a greenfield scenario where we build complex, consisting of many plants or just an additional plant or a small chemical facility. That's typically what we do. Or we have a brownfield plant. We have an extension. And then if we look at implementing OPOS for both of these two scenarios, there is a commonality. There is a commonality between those two and that's, you know, you have to gain experience. And why do you have to gain experience? Because, you know, looking at, well, I'll take an example, if you take the three Bs, the people procedure and process comparisons and what do our people have to learn and understand before we can implement those systems? How do we change our ways of working when we have those systems? What can we change to our processes if we have that technology available and these capabilities available to us? So there is a lot of learning and understanding you have to do before you really implement it at, for instance, a greenfield side, which everyone will probably understand. So therefore, you know, I come to the end of my introduction, I have a question to Louise and my question is, how do we start? How do we gain experience with OPOS? And Louise, I hope you can help me, but certainly also all the people who are listening in, how can you help me with that question? How do we gain the experience and how do we start? Yes, absolutely. And I need to remake the presenter so we'll give you a couple of sketches of what I have in mind and I can do that in a second. So, all right, so we can start with this, you know, vision of the automation systems, we know it today. And the idea, obviously, as you mentioned, you had made an investment, you have your asset is being controlled by these systems today, so what do you want to gain experience? And I think that one example of how to gain experience, how to realize or how to at least test if your benefits or benefits you anticipate for your production asset can be achieved is by creating some test scenarios and putting that into play in a real situation. That real situation doesn't mean that you have to reap your existing automation facility and bringing all new technology that will be an expensive proposition. So, what we have seen from the cases presented by Ron and Mohan in the first section, like the ExoMobil case and the BSF demonstration are ways in which the user can, those users have chosen to test the standards and validate the benefits that the standards can deliver to them, right? So, in this particular case, you know, the idea will be to draw in a parallel to the functionality that exists in the automation system is to create an experimentation, an area of experimentation that could be considered a pilot, a prototype or a proof of concept, a test system, a training system in which the end user will essentially have the opportunity to experiment. This doesn't need to be a new process in some of the examples, you know, as we saw it in the example of BSF, they created a small process that it was transferring fluids from one vessel to another in that scale situation. In other cases, we can work with simulations and ultimately once the user has achieved the confidence that trust on the automation system that they're using OPPOS products, then they can transfer that to a live process like ExoMobil already presented in the previous section, right? And so, there are different ways in which the user can experiment and test these technologies. And that's kind of what we envision will be some of the earlier adoption cases to produce a test bed or a test system to experiment, to try out. And then moving to the next scenario in which now this can be brought into a live process. So that's kind of what we anticipate. I hope that answers your question. So maybe we move on to, I don't know, Jack, if you have to want to add some... Well, I think you're answering the question and I think you're answering the question for a lot of people. There is no way to, if you wanna be informed, I think there's no way to just wait and sit back and then things will come at you. You'll have to start exploring things as well. And obviously, you answered that question. I think that's fine. Thank you very much, Luis. One thing that we should see, right? So also the ability to experiment, we want to highlight the experimentation that users want and could do around OPAS, but like in the case of BASF, and I'm sure with the case with other end users, the experimentation might extend beyond what has been only covered by OPAS. They might want to try other things that are not necessarily in the OPAS scope. Like in the case of BASF, there were other initiatives or industry trends that they wanted to try out. And they did, they try out a modular approach. They try out the interface to kind of a business system using the Nomura approach. So there's a lot of room for tryouts in this space. So there's a lot of benefits to begin. Now, to summarize this first example, I kind of wanted to highlight four things. Obviously, we cover the scope of OPAS standard. That was what we began with. And then we established this parallel between the existing automation system and the traditional view of an automation system and that the equivalency with OPAS certified products rough equivalency, I should say. Then we also, I illustrated some of the things that end users want to understand, right? So they want to understand OPAS. They want to see the value that it creates for them. They want to test the capabilities and establish some dissipated benefits. Then they also want to evaluate and experiment and try out. And that then can start small and continue to grow. And this is a trend that we're seeing. It might have been three years ago. It might have been one company. Now we're talking about six or seven companies trying to do this. So the momentum is, we see the momentum growing, right? And now the other one is just to illustrate the examples. Test systems, test bed, training system are all the examples of this initial installation. So we have seen those in practice and that have been color. So with that, let me move on to the next piece and maybe here, which I should hand over to Dave Emerson. Well, I have to, yeah, take you from here. Thank you. This is Dave Emerson with Yogawa. And I'll be talking a little bit about how to use OPAS standard with existing facilities. Now, I'd like to introduce Julie Smith with DuPont and maybe ask her on what her thoughts are. And what are the issues with this or how do we get started? Julie, do you have any questions? Yes, hi, Dave. Thanks for the opportunity. Good morning, good afternoon, everyone. As Dave said, I'm here representing DuPont. We are a specialty chemicals manufacturer. We make all sorts of different materials to serve different specialty products, industries, lots of plants around the world and they run all sorts of different control systems. It's part of them. We pretty much got one of everything, every vendor out there, also every vintage out there. We've got some systems that are very old and may be installed in the late 70s, early 80s. First generations of systems to help. We've also got some facilities that were updated recently. We haven't sat back and waited. We've started our migration journey at some facilities. Every year, there's a new migration project that either completes or gets kicked off. So one question that I have is, before those facilities who have recently gone to a migration project to whatever the current generation of vendor X's system is, how is this going to impact them? Have we missed the boat? Do we have to wait another 25, 30 years before we can take advantage of this technology? Because that's how long it's going to take before we do another migration. Migrations are very painful, very disruptive to business. There's not a lot of return on that investment. So yeah, that's a once every 25 years type of activity. And it would be a shame for us to have to wait just because we're a couple of years late to the party. Another challenge we have is a lot of our businesses growing incrementally. It's very unusual for us to build a completely new greenfield facility where nothing existed before, particularly in the US. And to grow incrementally through addition of modular process systems. This either could be something on the backend, safe drawer, VOC emissions control, or it can be something on the front end to purify materials or utilities. And sometimes it's even smack in the middle of the process where you need a higher capacity compressor or turban or some other highly specialized piece of equipment to make a new improved product. And integrating those package systems has always been a real pain. They typically come with an onboard PLC of some sort. You don't really know what's inside the systems. We have to kind of figure it out. And then we have to figure out how to tie it into the main control system running the rest of the process. So how can we open up help with the integration of those modular systems? So in summary, my questions are two part one, existing facilities, how can we take advantage of this technology rather than wait another 25 years to the next migration project? And two, how can this help with the incremental expansions we see with modular process systems? Thank you, Julie. I think what you've described is a reality for the majority of people and companies in the process industries. And in OPAS, we've looked at this and I'll try to explain some of the thoughts we have and how OPAS can be used with existing facilities. And then especially with the increasing use of modular process systems, our ideas for how to work that in. Of course, when you describe today, getting started with existing systems in our industry, very rarely is there opportunity to start with a clean slate. Of course, they'll come along and they're great, but invariably, whether it's a rip and replace or migration upgrade, there's a lot of constraints in existing facilities, whether it's floor space, whether it's protocols, whether it's technology and just operating windows to do the upgrades in, there's all types of challenges. To bring OPAS into an existing system, the first step is to establish a gateway. And the gateway we show here is a DCN and that's really just to show that it could be the same type of box as a controller. But the key thing is there has to be communications established between the future OPAS components and the existing control system. Now, OPAS is standardizing the OPAS environment per se and we use the term OCF or OPAS connectivity framework. This is really just a logical name for the network for the OPAS systems. So the first step is really to establish an OCF environment inside your plant and actually just having a DCN serve as a gateway. Now, the protocol it talks to the existing system will depend upon that system, existing systems, capabilities, it's age, what features it has. So there's many different ways that could be done. On the OCF side, though everything will be standardized. Now, to find this gateway, you're gonna, as an end user, you'll have to talk with your suppliers to see what they're gonna offer. Some companies are already laying plans to have gateways into the OPAS environment. So they'll be able to be hybrid system say. Other suppliers may not be that far along. So there will be a discussion there. There also may be the possibility that third party suppliers can provide gateways into automation systems that the automation supplier originally didn't intend. But once this gateways established, the next step is to add a DCN for control purposes. And now this could be any number of types of control purposes, they're gonna be just monitoring only. Here we show a DCN with an application writing in it. Now this could be an 1131 control engine or maybe as Exxon, Don Petusziak Exxon mobile noted, they're using the IEC 61499 standard or it could be even some proprietary function box that match the original automation system. There's a number of options there. It could also just be used for control, I mean for monitoring input only to monitor parts of the plant with no control in which case an OPCUA server in this new DCN can be used to broadcast or make available measurement data either back to the existing automation system through the gateway or an HMI could be put on this gate on the OCF or business systems or historians could be plugged in here. So there's many different types of ways to start from a functionality standpoint with this first DCN. Probably just monitoring only is a safe way to make it used to it, add control functionality, maybe add IO to actually control a part of the plant. Over time, it's possible then to expand this and here we show another DCN and there's really no hard limit to the number of DCNs that can be on a system. Of course, so there'll have to be practicalities as far as network traffic. No network is all powerful, but there's the ability to add the DCNs and these DCNs can have as much IO or as little. They could be designed or purchased to support field digital networks or they may just handle judicial twisted peer inputs on analog and digital IO. So there's a lot of flexibility here. Also, what can be added is the advanced computing platform or ACP. Now this looks like a big box, but it doesn't have to be. There's no requirement in the standard on how big or small an ACP has to be. In some companies, it's envisioned to be a large virtualized compute storage and network environment with high availability, but there's also appliances, lower cost appliances or it could be a server much like you have in your plants today. I think a great benefit though is to run virtual machines inside the ACP. This is a trend that most operating companies want to do today and most automation suppliers are supporting and that way it helps with obsolescence. Older operating systems can be run in a newer hardware and new hypervisor. We can bring in multiple applications to one hardware platform, so therefore there's just all types of savings involved with that that's well known. But again, this ACP could be similar to what you have today in your facilities. It could be a small server or it can even be a small appliance. So don't be afraid by the word advanced in there. It's great capabilities, but it can also scale down to be a small system. One of the aspects I think from an operating company needs to be determined is when the DCNs are added to a process. Is this a process expansion? Is it replacing your existing equipment over time as it becomes obsolete? If it's a process expansion, will it have its own HMI? This does not show the HMI in this photo but in this image, but of course it can be added anywhere here. Can you run off the ACP or it could just be a machine that's a computer that's on the OCF? There's no limitations on that. Also the data, as I said before, can be routed back and be shown on this existing operator console. Over time, as DCNs are added and applications, maybe level three applications are added into the ACP, it may be appropriate or desired to have the OPAS side of this hybrid system become the master and that's where the operator consoles reside. But this can be done gradually. And the goal of OPAS is not to create a big barrier or big bang for upgrades or a rip and replace, but to let the system grow organically as needed and be able to do upgrades, rolling upgrades, without having to say upgrade the HMI just because you want a new feature in the controller. So the decoupling of the software from the hardware and from the different nodes you see in the OPAS system is going to allow that flexibility. I think that's a big benefit Don Patuziak mentioned earlier as far as a smoother upgrade path and there'll be great savings in that, I think, from an operating viewpoint. Now, if we look at modular systems, Julie, you mentioned the use of these and this is a popular trend and it's been going on for a number of years. In Germany, the more organization has come out with something called MTP Modular Type Package because they see even in the future, building plants, new plants purely from modular systems. You know, other parts of the world having SKIDS packages come in, they can come in with all types of automation. Now, it's likely, maybe initially, that they'll remain as PLCs, but we envision that there'll be benefits for these modular process system companies to put a DCN or multiple DCNs onto their modular systems. And this way, there can be a standardized feature, automation, as multiple modular systems come into a plant, they can then be integrated into a master OPAS system, or as shown here, they can be then integrated in through a gateway into the existing legacy systems. And over time, as a system matures and grows, as I said before, it may flip over. And so the OPAS system or modular systems can become the master part of that system. So we recognize this is a trend and we're working, OPAS is working with them more to bring MTP into OPAS and to OPAS. And I think there's a lot of potential here for unifying these approaches. Now, Julie, I hope that answered your questions. And just to kind of summarize some of these, OPAS does not see the industry in a big bang just one day in a digital switch adopting it and not using anything else. We expect it will be a gradual moveover. There'll be new plants that use OPAS and there may be some rip and replace activities that do that, but also there'll be these gradually built systems that over time will then turn into an OPAS majority system. So there's ways, no matter what's right for an operating company, there's a way to start using OPAS. And item two here, what calls out is when you start looking at using OPAS products, make sure you have the certified products. What that will do is give you in a level of assurance that these products will be interoperable, interchangeable and meet the expectations of what OPAS is talking about. So if there's some of this not certified, it may well work, but it wouldn't have been tested to the rigorous certification requirements that OPAS is creating. And that on number three, the initial installations, again, can be very small and don't worry about that term advanced and advanced computing platform because that can be very small or it could even start off just as one of your existing servers, there will be a dual role, but it will be important to talk with system integrators. OPAS does not expect end users to get all this separate equipment, get it together and make it work. The system integrator role will bring experience and capabilities of your organization. You may think of this as one of your local system integrators now or one of your global system integrators, but make sure they have some OPA experience. And the best way to do that is to make sure they belong to OPAS involved and have people that have been involved in developing the OPAS standard. And so for end users, if you've developed a small test system, training system and you're wondering what to do and you don't have the opportunity for a brand new system, I think there are a lot of options in for bringing in OPAS components as incremental additions to existing systems, whether it's a replacing kind, whether it's an expansion, a small process expansion or just adding in new monitoring capabilities, there's lots of ways to get started and they don't require a huge step at that point. So on the wrapping up this segment, we'll turn it over to Steve Smith and talk about lifecycle benefits. And then he'll talk with Lewis about what can be done over the lifecycle of a system. Steve, are you or are you there? I am here. Steve, please. Well, thank you, Dave and thank you, Louise. I am Steve Smith. I'm the manager of control system support at Eastman and my entire 29 year tenure with Eastman has been focused on automation and control system implementation. And the organization that I currently lead is responsible for the daily support and enhancement of the control system installations at our largest manufacturing site, which is also our corporate headquarters in Kingsfort, Tennessee. And as a global specialty materials company with really over 50 manufacturing sites around the world, Eastman has over 350 control system installations comprised of numerous brands and advantages containing over a half a million points of IO. So we're very much in the similar situation that Julie described herself being in as well. And at just our Kingsfort site, which is where I'm based and have primary responsibility, we have 60 DCS systems from six different suppliers. And these 60 systems alone are comprised of over 20 different generations or advantages of these suppliers offerings, ranging in age from newly installed to over 25 to 30 years old. And in the PLC arena, again, just at our Kingsfort site, we have over 800 PLCs from 16 different suppliers consisting of over 40 different generations or advantages ranging in age from newly installed to over 30 to 35 years old, especially in terms of the installed technology. So really clearly, I think based on this landscape and footprint, life cycle support of these systems is a tremendous challenge for us. I mean, spare and replacement parts are truly becoming an absolute nightmare. And therefore, going forward, we're looking for greater interoperability, modularity and portability of system components and applications. And likewise, our systems reliability, both now and in the future, is of great concern due to this age in obsolescence. And through recent experiences of ours, of entire system replacements and migrations, the rip and replace, as we've called it, it's clear to us that this is not a viable strategy alone to successfully address the reliability and obsolescence of our automation fleet, given the significant cost and labor and time required by such an approach. And therefore, we are looking for alternatives to help address this ever-increasing problem for us. So, Luis, how does OPAS help to manage obsolescence? Great question. So let's paint the scenario that you kind of are fully invested in OPAS and you start to introduce this technology as Dave had described in his answer to Julie. And now it's been 10 years and it's year 2030 and you've been using this approach in your automation systems. So you might have systems that are already operating your plan using technology from different suppliers in this heterogeneous type of automation solution. But let's say you face a challenge, one of the challenges you described, right? Let's say that you have bought a DCM from supplier X and for different reasons supplier X is no longer in the market. Or they might have come up with a new approach to resolve the DCM functionality that they provide. As long as the interfaces and has been defined in OPAS remaining place, that shouldn't be a limitation for you, right? So let's say that over time and in this scenario the supplier X decides that they're no longer in the market for different reasons. And basically you in the current stage you will be left basically on your own how to resolve that problem with this scenario what we're describing is what about you no longer having access to products from supplier X but however supplier Y provides let's say another DCM that also basically have the same interfaces as we have defined or fine in supplier X. We also can host the applications the same way that you can do in your supplier X BCN. And so the idea here will be to replace the DCN that was delivered by supplier X here and with the one available from supplier Y. And in that scenario basically re hosting the application. So within with let's say without needing to have significant capital expenditure to let's say upgrade your complete automation system or to go through a major turnaround to let's say take off or take down part of your plan or your complete operation to replace the automation system then you will be in this case switching over from the DCN that by supplier Y by the DCN from supplier Y and removing the DCN by supplier X with the DCN by supplier Y re hosting the application to put in the portability or exercise the portability of the applications and then basically continuing your activity. It will be in a way the way that we envisioned this and the way the status was conceived. The idea will be to have these open interfaces and well-defined interfaces that allow for the inter-probability of the components regardless of the supplier brand and basically to be able to re-host the applications as you will do on your existing DCN. So that then minimizing the impact of the exchange of components in that situation. At the same time you can also using this approach might even benefit from some enhanced functionality that is not impacted by OPUS and the OPUS interface defined interfaces. And that will also be a way in which you can keep your existing current and remove OPUS lessons without a major disruption of your process or a major capital expenditure. I hope I have answered the question. And I think that we can probably move into some of the section summary and the next steps to discuss. So here, definitely the idea obviously that we have tried to illustrate with this example is that the open interfaces and the inter-operability will enable this exchange of replacement of components that as we have described in the case. So the maintenance of removing of that OPUS lessons as the two kind of examples that we have tried to illustrate had limited impact on the process of availability. It's only impacting those components that are affected. And this exchange of components that are available from an open marketplace of suppliers really reduces the risk of dependency on a single supplier that can go out of business or my obsolete given technology forcing the end user in a particular case. So this is one key element of OPUS. The forum is to enable this open marketplace, open ecosystem as Ron described in his section at the beginning. And last but not least, again, these open interfaces and the interoperability also facilitates the introduction of technology refreshing without a major capital project, which is another key value that we see in the forum. I guess with that, should we, I guess we go to Mohan for continuation here, I guess. Nice. All right, well, let's go to the conclusion of this part and then we bring Mohan who is our master of ceremonies today so we can move to the next section. We only have a few minutes left. So, you know, what we have tried to illustrate and kind of took a look on this section really is, you know, how we can gain experience with OPUS, right? So the, what we have show is really start small, learn and grow once you have the confidence and the experience that you have accumulated. With that also seek those benefits, right? We have illustrated some life cycle benefits as to manage the obsolescence in a cost efficient way. You can also be growing with the OPUS approach, right? The start small as I mentioned before benefit from the gradual expansion based on your experience and needs rather than starting a big band that might be expensive and difficult to justify economically, then the OPUS standard also for existing facilities, right? So as Dave mentioned, work with your suppliers to start adding these OPUS products, but it's important then to keep in mind, you know, how to expand, what are your goals that you're trying to achieve? And then last but not least and probably the key here is these reliance on the open interfaces and interpretability that is described in OPUS that facilitates introduction of technology and the technology refreshing without the complete replacement of an automation infrastructure as we are experiencing in many cases today. So with that, I think that we should probably where we are, I don't know, Mohan, if you want to take it from here and explain how we're gonna handle the next. Sure, Luis, thanks. And yeah, I thought that was a pretty informative session on sort of the end user perspectives and the idea that you can actually bring in OPUS not as one big block, but gaining experience and then trying to deal with different types of issues and modular systems and integrating it into your existing facilities as well as managing obsolescence. Steve, I mean, I was shocked when I heard the kind of things that you had to, you have the complexity and the diversity of systems that you have in your operations. So I think it's truly something that the companies can benefit from. Okay, so what is your level of familiarity with Open Process Automation Forum? About a third of the respondents say it's high awareness and 20% about medium awareness and about a third who have and about a half of them are going to be saying low awareness or not. Okay, great, thank you for that. Okay, all right. And we hope the introduction was useful. And what I would add is that we're working to make sure, I know we had some audio difficulties early on. So in the recorded session, we will correct the audio discrepancies. Okay, so this next question was really about what is your role in the automation space? Who do you represent? So about 27% say they represent owner operators and about 10% are software and hardware makers. About the eighth of the people are DCS suppliers and 15% describe themselves as system integrators. And about a quarter of the participants are technical or professional consultants. Okay, so and about 10% are other category. Okay, all right, that was helpful, thank you. And we hope it is useful for you and in getting your level of familiarity up and also thinking through how the adoption would work. And be aware that this is the first of our kind of adoption seminars. Of course, we would have liked to love to have done this face-to-face with you, but also I realized that we wouldn't have as many people in a face-to-face setting. So there is a positive and a negative to both of those cases. So yeah, we'll work with this and we will be running more of these and maybe hopefully in a time zone that is more friendly to you as we start to put more of these together. Okay. So there was a question that's come in, Mohan. I don't know if you've spotted it saying that redundancy is a feature that today's DCS have. Is there redundancy in the DCM? Yeah, Mohan, I can address that if you want. Sure. Yeah, so if the questioner would allow me to repose the question from the perspective of the asset owner, what we really care about is availability and redundancy in the spirit of the question is one way to achieve high availability. So we need to be thinking about new technological capabilities that enable us to achieve high availability without necessarily requiring physical redundancy. So what you'll see us working on in the OPA forum and in the OPAS standard itself is the incorporation by defining the interfaces for new types of technologies that allow us to achieve high availability and concepts like failover without always requiring physical pairwise redundancy. So I could break the answer to the question down more precisely in terms of what you're capable of doing with IO versus what you're capable of doing with the software execution. So where there's a physical thing that can fail, yeah, you probably still need, you probably still need physical pairwise redundancy, but as soon as you move into the cyber domain where you're talking about software execution functions, we're definitely thinking about other solutions to the problem and the requirement for high availability without necessarily requiring physical pair to pair redundancy. So that's the best answer I can give to the question.