 So please a warm welcome for Kirk Smith. Thank you. Well, thank you very much. So as the co-chair for the technical working group of the Open Process Automation Forum, very humbled and honored to do the announcement today and walk through what the standard has achieved. I think what Don and Trevor have put together is astounding in what they've accomplished in the past 12 to 18 months with the number of attendees involved. So looking forward to walk through with you exactly what the standard entails. So they're really focused on creating the next generation distributed control system. What does that control system look like? And the forum is very much focused on a standards-based, open, secure, and interoperable approach for building that next generation process control architecture. I'll make sure I get it down, learning how to advance the slides. So why would you do this? Why would you create a new standard for the industry? Industries have lots of standards already. Why do we need something new? So I think you've all heard about the IT, OT, transformation talk in the industry. I don't think that's relatively new. But for industrial systems, it's very new. So control systems in general are very state-based, require high degrees of determinism and clear understandings of latencies in those networks. And so being able to move quickly in those domains across multiple vendors is just something that doesn't happen very fast today. So as I think Don and others have pointed out in the last year, the industrial manufacturers are under an increased amount of pressure to lower capital and lifecycle costs of the systems that they develop and put in their processes and improve the profitability of their operations. Many of those systems are predominantly closed and proprietary. Today, you can't mix devices on the same control bus. And integrating those third-party components becomes costly, typically happens at a much higher level in the ISA 95 or Purdue model stack through IT-like systems where the latencies and determinism is much slower. And you can still do control at those frequencies. It's just you're limited into how far you can move out to the edge. So it's expensive to upgrade and maintain those. There's generally a lack of intrinsic cybersecurity throughout. It's usually patched. It's thought about in advance, but as everybody here knows, there's enough security threats that come out just in the news on a daily basis that no system stays secure for very long these days. So we believe the open, interoperable, and a secure by design process automation system architecture will address all of these issues in the context of interoperability here initially. There's a lot to do from a portability standpoint where you look at configuration portability and application portability longer term with this standard. But here we're introducing interoperability. So the goal and purpose of the open process automation forum is ensure that these systems adopt and reinforce standards that achieve true heterogeneity by providing the intrinsic security, multi-vendor interoperability, future proof innovation, and an easy pathway for system migration. So what are the accomplishments in the past year for the open process automation forum? So we've had substantial forum growth, and we'll look at that in a moment. There's been four to five different publications put out that we'll look at briefly. And we've successfully released here in January the version one of the preliminary standard of the open group that's really focused on driving interoperability in this space. So we'll walk through the structure and the overview. It's architecture, the security fundamentals that are part of the standard, the systems management capabilities that are being introduced, the connectivity fundamentals, and the normative interfaces that are implied or mandated actually from a conformance viewpoint for the standard. And then we'll talk a little bit about our plans for 2019. So growth. OPAF has had significant growth in the past year. OPAF has grown membership in excess of 25% in 2018 alone. New members include, and you can see the list, but they're a mix of OEM, ODM, system integrators, very large companies to smaller companies that focus purely on control system integration. So we're very proud that that is happening and continues to happen, and the size of the organization continues to grow, and we expect more growth in 2019. From a publication viewpoint, we've released a business guide in January of 2018. We released the requirements white paper, W184. The open process automation technical reference model snapshot was released in June of 2018, and we had very good feedback for that, and that really helped shape the release that's coming out today. And then, of course, the OPAF standard version 1, a preliminary standard of the open group released this month, and will be announced as well at ARC next week. This P90 spec is a preliminary standard, and it will become hardened and formalized between now and roughly Q3 of this year is the expectation. So what's in standard version 1? From a structure perspective, it's made up of five parts. Part 1 is a technical architecture overview that's informative. It describes the conformance system through a set of interfaces to those components. So this standard is meant to be an interface definition to support interoperability. We want to make it a function of a system of systems and standards that already exist. We don't want to create new standards in this space unless we absolutely have to. So we're very focused on leveraging what's already in the ecosystem and bringing it together from an architecture view and a standard view. Part 2 is focused on security. IEC 62443 is fundamental to the security. And it is purposely set up to be informative for this first release. We recognize the lift to get to security level 2 for lots of organizations, and we understand the fragmented approach to that by different groups. We, of course, emphasize the cybersecurity needs. Most people who look at this want to be as secure as they possibly can, so we think this will naturally take root, but it won't drive people away from a cost perspective. And then the detailed normative interface specifications are defined in parts 3 through 5, where we define a set of profiles that mix connectivity, security, systems management together in a set of configuration profiles depending on what your business may require. Part 4 is focused on the connectivity framework and heavily emphasizes OPCUA and embraces that standard as a way to model those systems generically that we all are familiar with, both continuous processes and others. Part 5 is, of course, focused on systems management, and there's a recognition that systems management is not just through the control service capabilities that you typically find in something like OPCUA, but extends to other network functions, specifically through Red Fish, DMTF, and embraces NetConf, Yang, and SNIA, and some of the swordfish standards. So it's really designed to define and allow development of systems consisting of opponents from multiple vendors without requiring custom integration. That's the goal. So some key concepts that are part of the architecture that are important to highlight here today. The notion of a distributed control node, this goes way back to the first graphics that were even introduced by Don Bartusiak and Steve Bitar and others end users as we began defining what the industrial world at least needs from a distributed view for computing. So you see the concept of a distributed control node that's really made up of a distributed control platform, which really is a function of the hardware and underlying base system firmware and low-level software, and then the distributed control functions, which host applications, and those are, of course, linked together via distributed control function services. So this performs a basis for connectivity and interface development for the standard that's defined in detail, if you look at part one. So kind of a blown-up view of the technical architecture, and this is probably the most familiar diagram in the deck, just talks about where distributed control nodes fit from an architectural view. And here you can see at the lower level of the diagram, the recognition of distributed control nodes connecting to analog and digital IO on the far left-hand side, and then as you move across the lower part of the slide, you see how you can connect the distributed control systems that are acknowledged, could be embedded programologic controllers, could be smart IO in the field that might be something like an analyzer or specific types of machinery or other field networks and safety systems, are recognized as interfaces for these types of open interoperable distributed control nodes. They're all connected via an OPAS connectivity framework, we refer to it as the OCF, and that's built upon OPC-UA today, but also includes system management interfaces that are associated with managing those systems in and out of an OPC-UA system. Northbound, there are still distributed control nodes, but you think of this server class devices that may be running many types of applications at the level 2 and level 3 function space connecting the IEC 62264, that's the fiber optics that are commonly used, and you see the connectivity of firewall to level 4 for business platforms, and then the recognition that non-OPAF environments will exist, so Northbound or even horizontal connectivity through other DCNs are important to support from an interface perspective, and I guess I should also say that the external OT data center connectivity is also recognized, you may have functions sitting in an on-premise or off-premise data center that are running distributed control functions that you want the on-premise software to be able to connect and leverage in its operation. So from a security view, what's involved in the standard? On the left-hand side, you can see the objectives mapped against the ANSI IHSA 62443 series of foundational requirements, and so that covers everything from identification and authentication to user control and system integrity and confidentiality, restricted data flow, the timing of events and resource availability, and mapped against the objectives in OPAF that are focused on identification, authentication, non-repudiation, authorization, integrity, et cetera. I won't read the whole list to you, but definitely want to be comprehensive in that space. Security is fundamental to the standard, and on the right-hand side, it's important to note from a lifecycle perspective where security is and is not applied in the standard, so you see the boundary condition laid out for the scope of the security specification for 6443-3 and 4-1 and 4-2 are included, but it's included in the bounds of where the hardware supplier, software supplier, and the subsystem integrator typically operate, right? You notice it's not including downstream end-user and service suppliers. At least it's not in this version, right? It could be. We spent a lot of time discussing that, and quite frankly, there was no one standard that covered an entire lifecycle of devices from the creation point all the way to the end-of-life scenario, so we bounded it this way today. Systems management. Systems management, of course, is fundamental to managing any system, but it's very important when you're managing a control system. As I mentioned earlier, determinism and latency and maintaining state for things when you turn systems on and off are very important, and doing it in a standardized way doesn't really exist across all the vendors, if you look at all the vendors distributed to control systems from a proprietary view today. They typically have their own pane of glass. Sometimes it's on a per hardware basis, and their ideal state is to be able to manage this from one pane of glass, one set of methodologies and capabilities. So this slide just highlights that we're gravitating to DMTF redfish, and that's the standard that is leveraged for system management. If you know anything about DMTF redfish, you know that it's really the next evolution of IPMI, which is commonly used today. The systems management standard also covers in-band and out-of-band scenarios, where you have board management controllers to tunnel in, right, for people who want to put those in their devices. So actually probably the longest section or part of the whole standard. It's, I think, in excess of 200 pages today. So, and that's just because of all the DMTF parameters that you can use to monitor compute, storage, networking devices, so that you can add that telemetry to your system, right, so that you can have the hooks and handles to develop system management via the interfaces that would be desired for the products you would want to bring to market. Connectivity, and I don't expect you to read the normative references on the right, but I just wanted to let you know there's a bunch of them. So, and a lot of it is focused on leveraging what the OPC UA, Unified Architecture provides for the ecosystem. So, being able to develop, publish, subscribe, and client server models for connectivity frameworks is extremely important in this domain, and we see this evolving with the directions for time-sensitive networking. As another example, over time, really the industry, I think, is really rallied around OPC UA as a methodology for connectivity in industrial systems. In fact, the votes have been practically unanimous when we looked at it inside the forum to date on a way to move forward. So, very much excited about this. This document specifies the parts and pieces that are normative for being conformative with the standard, or conformant with the standard, and will be a key piece of the interoperability workshops we're running later this year. Normative interfaces. So, this is just a view from the Distributed Control Platform view up through the Distributed Control Framework, where the horizontal control bus data resides, and the connectivity through applications. They wanted to highlight everything in bold is part of this standard. It's the system management interface, the connectivity framework interface, and both North and South across that control bus. So, this initial standard, this initial interoperability standard allows two proprietary devices to reside on the same control network and communicate with each other, right? And so, today, you cannot do that in a conformant way, right? In a standard way without a heavy lift. In future releases of the standard, everything that's grayed out will become darker and get revved, and those will become the future interfaces that are provided to build on the future versions of the standard. So, what's our plans for 2019? So, 2019 is focused on configuration portability. So, in Q2, we actually, and it's focused on version one interoperability conformance testing with the devices we expect to happen in mid-year. Procurement guide, the conformance certification policy specifications expected to be finalized roughly the March timeframe to support the interoperability workshop in June. And then in Q3, we expect to have a conformance matrix and test chassis methodology that we can utilize for future sessions. And with a snapshot for the form hardware specification in version one, I think that should be 2.0. So, there's six plus subcommittees part of the technology working group. And physical platform is really focused on finding what's the common specifications they can rally around as a body to drive standardization for some of the things like terminal buses, where you connect the wires in the field, and users don't want to have to move those ever again once they've laid them down. I think I've heard quotes of something like $100 a foot just to lay wire in a refinery and maintain it. But they're still working with developing that ecosystem. So, that's probably, the physical platform space is still probably the hardest space. So, you don't see it in version one. And in the final low-pass specification for vision one, we'd like to get ratified in Q3, as I mentioned earlier. And then Q4, we'd like to have the preliminary low-pass specification in version two focused on configuration portability in the review process in the Q4 time frame. So, questions? Thanks, Pat. Please take a seat. We do have some questions. Hey, you guys don't rest on your laurels, do you? You're going to get the final version out in Q3 and then start with the next preliminary spec for the next quarter. I think I told you we had 30 pages of minutes in our last face-to-face. So, that's a good attendance and a lot of momentum. So, we're excited about that. So, some questions come in for the audience. Steve mentioned multiple industries in his intro. Can you tell us more about what they are who are involved in the forum? The multiple industries? Yeah. Yeah, so, continuous process industries is typically where this has started with, I think, ExxonMobil leading the charge. And there's a broad idea, I think, with a lot of the OEMs and ODMs that are involved that this could extend to discrete, right, as well. There's no reason it can. Of course, you've got tighter constraints there. So, I think robotics, I think assembly test, manufacturing thing, discrete processes, machine controllers, or the CNC industry, for example, machining and tooling, et cetera, right? So, I think we're just getting started, right? And the CPI is probably the major focus with some of the users, but we ideally would like to see that grow, right? And I think with some of the OEMs and end users involved, it likely can. Yeah, I know when we look at the membership breakdown, I know you showed the last slide was some of the members, not all, I think. Yes, that was only some. You know, I know there were at least seven industries and I always forget one and I never know what it is, but I know we've got oil and gas and petrochemical and pharmaceutical and pulp and paper and utilities and food and beverage. Exactly, right. And there's always one I forget that's close to pharmaceutical, but not quite. So, but anyway, it's good, it's good. So, what is the OPAS definition of process and has it been harmonized with the TOGAF definition? Oh, that's a good question. So, yeah, in my conjecture, I'd be guessing to give you a complete definition. So, I don't know that it's been harmonized and that's something that we should probably look at, right? So, process to me is a very broad term and it's not necessarily specific to any one of the industries you mentioned, I don't think. Right, so, right. Okay. So, how has the forum's work been received in the market positively or another standardization effort doomed to failure? So, I think Ed told me last week that there were, we had no dissensions in our voting of all the members that voted and we had a large number of members who voted for it. So, I think that speaks very well to the kind of acceptance of the direction that this is moving. And I don't know the exact numbers, but it was almost a whole forum, I think, yeah. What makes this different from previous similar question? What makes this different from previous standardization efforts in the process automation space? I can relate to that question in that I was at one or two of the industry days when we were getting this going and it was, oh well, you know, we've tried before, what makes this different? I think what makes this different, there's probably two things. Just one, the first thing I would mention is a high level of end user involvement. So, I know Don Bartusiak and Coke Industries and others that are participating have really developed in the process of developing a bigger ground soil within users and they've really been driving the requirements and I really focus on end user requirements has been important there and I think has been key to the work that's happened. And the second area would just be from a technology perspective. Technologies, this whole ITOT idea seems to be taking root, right, fairly well. So, I think, you know, consolidating workloads, making things more plug and play like other industries do and being able to do it in a control environment, there's test cases and use cases that are being proven out by various companies that are attracting interest. So, I think the fact that a standard approach is being taken as well helps. Yes, and that absolutely does, absolutely. We're not trying to create anything, yeah, we're trying to pull things together from an integration in a systems view. Okay, it's a very aggressive schedule. Kudos to you all. Is there a key to getting that kind of support to deliver on this schedule? Scope, so I don't know. So, we spent, we were in Dallas last week, we spent a lot of our time talking about what's in scope for version two and ratifying that as early as possible in the cycle. Up to and including having rough drafts, even if they're just blank headers and placeholders early in Q1. So, we're trying to be a month ahead of where we were last year. But we don't want to cut scope just as we get close to the deadline to get something out, we want to make sure that it's extremely valuable, right? And with the effort we're putting in, so that's a balance, yeah. Good stuff. Final question then. Do you have any view on when the first OPAS conformant equipment might hit the market? So, well, there's an interoperability workshop that's gonna happen in June. And so, that is not a conformance test, that's vendors coming together just to see how their devices will work. And then I think it's probably December, January, maybe or Q1 of the following year is my guess. There's a lot of work been going on on the conformance program and what that will entail, so I think it's... And we think we've designed the standard in such a way that there's a lot of OEMs and companies that could have a breadth of devices that could, with little effort, be made conformant. So, that's the hope there, yeah, yep. Well, Kurt, thank you for sharing more detail on this significant accomplishment. Congrats to all the forum. Thank you. And everyone who's worked really hard on that. So, and thank you for your time and thoughts today. Thanks. Thank you.