 Okay. Thanks, Anil, for the introduction. So I would like to welcome you to the OPAS adoption workshop. Wherever you're calling from, whatever time of day or night it is at your local location, we as the Open Process Automation Forum are excited to have you join us and we're confident it's going to be a productive three hours for you. So here are the agenda topics that we have planned for you today. First, we're going to start with an overview of the Open Process Automation Forum itself, the objectives of the group, and then talk about motivation as well as activities that go on in the forum. And we're going to then talk a little bit about security and then we're going to talk about how some of these systems based on Open Process Automation have been realized by own-user companies. Then we'll go into a Q&A and a break. So after that, we're really going to talk about the adoption case scenarios. And these are things that we have done based on what we call user narratives and user stories. So from those, we have tried to distill out a few scenarios where we talk about gaining experience with the OPAS standard and we're going to focus only on a popular three of these scenarios in detail. And how to adapt the OPAS standard for existing facilities, as well as lifecycle benefits that you expect to realize with the OPAS standard. Then we'll follow up with the break. Then we'll have a Q&A with the entire panel of speakers, and then we will then do a wrap-up and key takeaways from there. So along the way, we have plenty of chances to ask questions. We're constantly going to have a valuable actionable items to take back to your companies based on the workshop. So to continue on to providing the motivation and case for action, I'm going to hand it off. It's my pleasure to hand it off to Don Bartuzziak. Thanks, Mohan. Hello, everyone. My name is Don Bartuzziak. I am the Chief Engineer for Process Control and ExxonMobil Research and Engineering. And I'm also one of the co-chairs of the Open Process Automation Forum. So if you can go to the next slide, please. So the subject of this workshop and the work of the Open Process Automation Forum is industrial control systems. And this chart is as a picture of the current state of the art in industrial control systems. We refer to this architecture as the Purdue reference model. And it goes back to design principles that were established in the late 1970s and the early 1980s. And so although we've gotten a lot of benefits from this system and this architecture over the decades, there are limitations, and it's now time, and that's the work of the OPA Forum to request a change, to implement a change to the system. So what you basically see, particularly in levels one and two, this reflects the heritage of these products. But in general, the current state of the art involves proprietary solutions to the computing and communications needs, particularly as they occur in levels one and two on this chart. So if we can go to the next page, please. So what is the problem that we're trying to solve? And the first one, and I'm going to direct my comments to this leftmost column, but a problem that we're trying to solve is the limits on benefits generation, where those limits come from the fact that it's very difficult with the current state of the art to introduce new technologies, particularly technologies from third parties, not the original equipment maker. The second business problem that we're trying to solve is the high cost to upgrade or replace these systems, in contrast to the costs to affect upgrades in similar compute using situations. If I can direct your attention to the rightmost column, another business problem that we want to address with the OPA Forum's work is the fact that with today's products, the cybersecurity was really an afterthought and any cybersecurity provisions have to be what we call bolted on to the outside. And when I synthesize these business problems, basically the root cause, and we've thought about this after many years of deep thinking in my team at Nexon Mobile, that the fundamental root cause problem is the closed and proprietary nature of the current state of the art. So if you could give me the next chart, please. So the vision of the Open Process Automation Forum is to transition from closed proprietary systems to a standards-based open, interoperable, and secure process control architecture. And this chart depicts that reference architecture. And I won't spend a lot of time here. We're going to detail it in the course of this workshop. But what should immediately jump out at you is this looks more like an architecture that is reflective of the current state of the art in networking and with the Ethernet. So there are three components, the distributed control node, these edge devices here, these industry standard-based networking technology that we call the OPAS connectivity framework here, and then the on-premise, higher-powered compute capability that we give the name of the advanced computing platform. And the sessions in this workshop will detail that functionality later. So if we can go to the next slide, please, and then I'm going to wrap up my remarks. And let me give you the headlines of the workshop. I'm going to just say things without specifically pointing to any figures on this chart. But here's what I want the users of the attendees of this workshop to take away. Three points. Point number one, the business problem that we're trying to solve are the limits on value generation with control systems that are the result of barriers to introduce to new technology. Why is it so expensive to upgrade or replace these systems? And then why can't we have systems that have design for cybersecurity? Okay, and again, the root cause we've concluded of the business problem is closed proprietary nature of the current state of the art. Point number two is that our vision for a solution to the business problem is to embrace, to define and embrace a standards-based open, secure, and interoperable process automation architecture and instances of systems reflecting that architecture can be made fit for purpose for the customer for the end user. And my third point and then we're going to hand off to the next speaker is the feasible path towards the realization of that vision. You're going to hear about it in this workshop. The feasible path towards the solution of the business problem is the coalition of the willing, both customers and suppliers that you're going to hear about in this workshop. And you're going to hear it firsthand. We have speakers who are in operating companies from Shell, from DuPont, from Eastman Chemical. We have speakers who are from supplier companies, from Wind River, from Yokogawa, and from ABB. So that's what you're going to hear. I've tried to give you the headlines of the takeaways and we're all looking forward to a really productive workshop. That's now ready for Ron Bro. All right, now what I'm going to do is talk more about the open process automation form itself, the membership and structure. So OPAF is an organization dedicated to the development of industry standards and it's managed under the auspices of the open group. The membership is largely made up of suppliers and system integrators and end users from various industries, including oil and gas, chemical, pulp and paper, pharmaceuticals, mining and others. Membership today stands at over 100 members. And the organization of the form and its management under the open group was selected in large part based on the success of the open group FACE consortium, an industry and government avionics initiative. FACE has goals and objectives such as open interfaces and application portability, which the founders of OPAF found attractive. Similar initiatives in the telecommunications industry underscored the benefits of an open standards based approach. So that was the direction chosen. As noted here on the sidebar, the actual name of the standard we're developing is OPAF, not OPAF, which is the name of the abbreviation for the form. Sometimes there's some confusion there. And at the bottom of the slide here, you'll see the main focus area for each of the versions of the standard we've undertaken. Version one for interoperability, version two for base configuration, 2.1 function block configuration portability and version three application portability. So moving forward, I'd say one important distinction of OPAF is that we don't create a bunch of new standards from scratch, but we take a standard of standards based approach, drawing on and integrating existing standards from other organizations. Examples of such organizations are the OPC Foundation, the International Society of Automation, or ISA, and the Distributed Management Task Force, DMTF, and their Redfish system management standard. Our work is to integrate these standards into a cohesive body, ensuring the interoperability and portability of process automation technologies built to these standards. And another important distinction of OPAF is certification. Suppliers whose goals are to offer OPAF's conformant products must undergo formal certification by an accredited third party. Self-certification isn't an option and would not be recognized, and I'll talk more about certification in a few moments. So briefly, here's a snapshot of the logos of the companies who are active in or support the work of the form. I'm sure many of you will recognize, many you will recognize and perhaps some you don't. From large to small and everything in between, all members can participate in and contribute to the form on an equal basis. Okay, diving a bit deeper, let's look at the structure of the form itself. This slide shows you the main groupings within OPAF. The steering committee provides oversight, sets overall direction, and defines a set of working groups. The working groups are where everyday actions of the form take place, and working groups can have their own subcommittees to tackle specific topics, a kind of divide and conquer approach, if you will. The business working group concerns itself with high level use cases, business guides, marketing and outreach, and other topics of a business nature. The enterprise architecture working group captures and manages requirements and other architectural artifacts that are used to define the OPAF standard. This ensures ever important alignment between the other working groups vis-a-vis our target architecture. And the technology working group is where the heavy lifting of OPAF standard development takes place. The technology working group has the most subcommittees, as you can see, each focusing on different areas of the OPAF standard. Example, technical architecture, connectivity, security, physical platform, and others. And then finally, the certification working group is focused on the policies, processes, and activities needed to develop and deploy a fully operational commercial certification program. But as you heard earlier, it's a working group where I myself now invest most of my time. Okay. Now switching gears, I talked about ecosystem earlier. Let's look at today's automation ecosystem. This slide is pretty straightforward. It depicts a simplified view of the current situation that end users find themselves in. When they want to build, augment, or renew their automation systems, they work directly with a small set of industrial automation suppliers or vendors. Now let's compare that to the target ecosystem model we're working towards in OPAF. In this model, we see a rich ecosystem of different roles with open interaction across those roles. Rather than a one-to-one relationship, end users can interact with multiple roles that could be assumed by different companies across the full life cycle of a system or installation. These roles can be fulfilled by different companies, and companies can choose to take on a variety of roles. Sorry, just grabbing a drink here. So this ultimately ensures that end users have choice of selecting the best-in-class technologies from all suppliers, hardware, software, or full solution suppliers. Through well-defined methods, even modular systems such as process packages, for example, boilers or turbines can be integrated into a solution. The transport ecosystem is enabled by the standardized interfaces and data models described in the OPAF specification, and enabling value creation across the full ecosystem. So next, there's an old African proverb that says, if you want to go fast, go alone. If you want to go far, go together. And in OPAF, we want to go far, and that means we need partners. OPAF works with a broad range of partner organizations in the development of the OPAF standard. This can manifest itself through agreements to leverage existing external standards, as I mentioned, or through work with organizations whose goals and directions align with OPAF. In the interest of time, I won't call them in here all directly, but you can see our partners listed. Okay, now let's look more closely at OPAF certification. As I said earlier, certification is a formal process managed by the open group according to the certification policy that we developed in the forum. While undertaking the process is voluntary, any supplier who wants to claim their product is OPAF certified or use the OPAF logo must undergo certification. Suppliers who want to pursue certification contract with verification labs that have been accredited by the open group. Once their products are able to demonstrate full conformance to the OPAF requirements, they'll receive certification and be listed in the OPAF certification registry. Okay, so who benefits from the results of certification? I say everyone, end users can be confident that any OPAF certified products they procure have demonstrated full conformity to the OPAF requirements. System integrators benefit in having confidence that their OPAF certified products can be readily and successfully integrated into their solutions. Suppliers benefit in that those who invest in OPAF certification can differentiate their products from others who have not been certified or are perhaps unable to be certified. I want to note here that the open group rigorously protects their certification trademarks. They monitor and police the use of the trademarks and will undertake proactive legal action for any unauthorized use. This ensures that the OPAF certified logo is a mark of trust and quality and that's important. Okay, security, let's turn to security. So as I said earlier, from the very formation of the program, security was identified as one of the foundational quality attributes guiding our work in OPAF. Before going much further, let's align on some important basic concepts. In the industrial world in which we work, the standards most relevant to security is the ISA, IEC 62443 family. Among other things, this family of standards defines four security levels associated with various threat levels, ranging from casual or coincidental, all the way to intentional and sophisticated. End users play a key role with respect to security. End users and end users alone are responsible for determining the security level of their systems. Their choice depends on many variables including environment, physical security, cost targets, and others. They select the security level. In OPAS, our focus is on the scope of the component level, not the system level. We're defining the interfaces, data models, physical platforms, etc. that end users leverage to build a system. As part of those specifications, we identify security requirements tied directly to the 62443 standard. That standard identifies requirements for multiple roles involved in the system as we'll see shortly. So this slide demonstrates the importance of an end user's risk assessment in determining the applicable security requirements and security level. They should target to mitigate their assessed risk. For an end user deciding that minimal protection is required, or I should say for an end user who's deciding that minimal protection is required, they would select security level SL1. For an end user selecting protection against entry levels of intentional violation and generic skillsets such as basic ransomware, they may identify requirements from a combination of 62443 SL1 and SL2, perhaps other requirements, ultimately targeting at the system level, security level 2. For an end user who's deciding to protect against even higher levels of intentional violation with really specific targeted skills such as targeted ransomware, they may decide that SL2 protection is not enough and select a higher level. Again, this just highlights that risk assessment drives the process and end users don't have to be constrained by the standard. They can go beyond that, but it's all about the risk. So this slide brings it all together. So as I just said, the end user, the asset owner, am I hearing some noise? Yeah, Ron, actually you're hearing Dom. We're just about to bring him in. I think he's now on audio if he needs to add to this slide deck. So we have finally gotten connected just so you know. Okay, good. I'll just finish this up. So the end user or the asset owner or system provider as it is in this diagram determines the overall security level for their system, the target level. 62443 has specific parts and requirements associated with the end user role. The system integrator's role is to design and deploy the system per the end user specifications. 62443 standard again has specific parts capturing requirements for the system integrator role. Now here's where OPAS comes in. Product suppliers will one day offer products which are OPAS certified. Examples of these products are DCNs, distributed control nodes, function blocks, applications and others. And as I noted, the focus of OPAS is on the component level, not the system level. And 62443 defines specific requirements applicable to those components. For example, 3, 3, 4, 1, 4, 2. In OPAS, we have set SL2 as the minimum target security level for OPAS certified components. This ensures that all OPAS components, all OPAS products will be able to defend against entry levels of intentional violation such as basic levels of ransomware and have a consistent degree of security interoperability. I hope that provides some clarity on OPAS security strategy and OPAS overall from this section. And I will now pass the baton back to Mohan who will take it from here. Okay, thanks Ron. I'm going to talk about the instantiation of real world systems put together by operating companies based on open process automation principles and standards. ExxonMobil had actually first showed a proof of concept in 2018 using laboratory grade components assembled into a system that demonstrated the principles of open architecture in terms of portability, configurability and interoperability. And so subsequent to that, we decided, we as ExxonMobil decided to build a prototype system and deploy it on real hydrocarbons. And we did this at our facility in our research facility in Clinton, New Jersey. So we took the legacy DCS system off and then we put in our proprietary, we put in, we replaced the proprietary DCS system with a system based off on open process automation components secured from multiple vendors. And so this figure actually shows you the pilot plant. And then it also shows on the right hand side, it shows the cabinet that we built using hardware from 10 different vendors. And so this system was actually, this is a pilot plant system that is used to test catalyst for distillate desulfurization. And we had about 126 IO points, the system operated at temperature of 600 degrees Fahrenheit and 1200 pounds pressure. And then we put in our regular reference catalyst and then we moved in this system. So what this system showed us, I mean, and we had components from various vendors that we assembled into a system. This really showed us that we could put together a system of heterogeneous components and use it to control real live operations. It gave us the confidence that we could do it. And with this system itself, we started streaming the system where the system came online in January and operated until end of March. So we got a steady state operation through that timeframe. We used various HMIs, we used different DCMs for control. And we were still able to achieve stable and robust operations, even with some unplanned upsets like the feed pump going out and so on. So we did have a lot of learnings from this. And I think we have shared it in other forums as well. And I know that Don has written a paper for the IFAC proceedings 2020. And so you should see a lot more technical details on this in that paper. So what this told us was, yeah, you know, we can actually build these systems and we can use it to control real life processes. So the next chart really shows a open automation demonstrator concept system that BASF built for and they used a sort of a non critical usage. They used water, they had pumps to heat up the water, move the water around and fill levels and then control levels and then pump it back. So they built a group of concepts to demonstrate both the system here as well as the open process automation principles as well as MTP principles for this particular system. It was again built of heterogeneous components and then operated and showed off at the demonstrator conference at the Nemoore conference in 2019. And BASF was impressed with the system and they did declare that the success of the initiative becomes more and more likely. So the last one is a slide that I have is really to talk about the end user collaborative development that we have with other end user companies, other operating companies. And you can see the names of those companies out there. So the idea behind this is as a group of operating companies, we come together. We each establish a our own test facilities. And with our collaboration partners, we can also test some concepts at the other facilities. And the idea is to advance the learnings very fast. So we will share non-competitive learns among the collaboration partners. And this is all in preparation for testing cases and scenarios to prepare for multiple field trials. And in the bottom left, you can see the test facility, the ExxonMobil test facility that we have established with Yokogawa systems integrator that is operational in the Woodlands, Texas right now. And you probably have seen an announcement from Aramco just yesterday about their test facility that they have set up for testing open process automation concepts. So as a wrap up, what I want to really emphasize here is that there are changes that are coming to the automation industry. The open process automation standard really provides the foundation for constructing systems components first based on open interoperable secure principles. The forum itself is providing a roadmap for the business and technology ecosystem and creating the right conditions, the marketplace and looking at the conditions for how to create a thriving marketplace. So what our request is that you as part of the ecosystem, whether you're a supplier end user become engaged in this activity, you need an active voice to represent yourself. And then as the forum starts to select the standards, you need to participate in the selection of those standards and then voice your concerns or voice your ability to work in this new ecosystem. So the other couple of points I just want to make it that the significant progress being achieved the end user companies are devoting significant resources to realizing systems based on the open process automation concepts. They are being actualized both, you know, we've moved beyond the proof of concept to actualization in prototypes and test steps. And the last part, which is what this workshop is trying to address is really that the end users, system integrators and suppliers need to start considering seriously considering how to build the adoption into their plans. You know, how they would respond to an end user query, how end users can begin to integrate these systems into their operations and facilities. So that's what the rest of the workshop is going to be about. And then we would actually move into, so with that I want to wrap up this section and move into the next part of the workshop. But before that, let me talk about the resources where you can learn more about this. So you can visit the website. In fact, you can just Google open process automation forum and you should begin to see a lot of articles written about open process automation forum. And the work it is doing. You can review the media coverage. And you can actually even see some of these videos in YouTube. We have presented at multiple forums. You can review those. The key publications that you want to review are first off, it should be the business guide. The business guide provides a high level overview of the motivation and the benefits to different participants in this ecosystem. And the published standards and technology architecture are good documents. If you really want to consider exactly the technical work that the forum is doing, you can review those publications as well. And we have recently published the certification policy in 2020, as well as version two of the standard in 2020. And if you would like to join the open group, please reach out to Mike Hickey. His email contact is shown below. Okay, with that we come to the next part of the agenda.