 Okay, so I'll start out saying thank you for the introduction, and Jean and I are very pleased to be up here. We've been working on this business guide now for about the last year, and we had a lot of help from across the organization. We just were facilitators in collecting and gathering the data to create what we believe is a pretty good document for the scope and direction of the group. And that's the reason that this particular document was created, was so that, one, the people that aren't necessarily in the group today can read about what we're doing and why we're doing it. So we're going to talk a little bit today about a couple of things, including why we're here, why the form was created, some of the use cases that were created, the ecosystem around that, some of the quality attributes and sort of the call to action that kind of happens with that. So we'll go ahead and get started with, you know, what happens in, what's the vision of this group, right? That's the creation of an open standard for process automation architecture, right? There are a couple key ideas that were important to make sure that we're included as we move forward in this space. So easily integrates best in class components through interoperability. So one of the reasons that it was started in this space was we want to have a way to accelerate innovation. The belief is that by allowing interoperability in your control system, you can have other people than your currently suppliers participate as well. And so that system integration can happen for best in class solutions in a lot of different spaces in your factory. Adaptive and intrinsically secure. Adaptive in the fact that it needs to be able to both incorporate existing technology and older technologies as well, which goes to the intrinsically secure piece to it. Like we, a lot of the machines that were probably connected in the whole Internet of Things world as you start looking at this will have data flows that have never been connected to anything before. And so there is obviously some concern in that space around as you do that, how do you make sure that that data feed is secure and it's not hackable? Obviously if someone was able to get into the control system of your factory, there could be some concerns in that space. So we want to make sure that security is built into the system from the ground up as opposed to applied later over the top. Modular integrations of certified components. So one of the things that we're working on next after the business guide now is complete is conformance. So how do you certify that these components are going to work in this interoperable system so that any fit for purpose products that are sent in this space, the end user or the buyer can be confident that it's going to work in as intended? Promotes innovation and value creation. So the idea, like we said earlier, was with that interoperability, we believe it creates an opportunity for further innovation. And with that, we believe there's value creation that can happen. What we've said is we're looking at this both from a technical and a business perspective so that there's opportunities for end users, suppliers, systems integrators to all find new ground and fertile ground for opportunity. And then finally, development of portable applications. So you find something that works in one factory. You want to be able to move it to another that maybe doesn't necessarily even have the same type of system. The idea is sort of like you can move your applications from one location to another like happens in sort of the IT world today. So this group was started by a couple of key founders, if you will, back in November of 2016 in a very hot and cramped conference room in San Francisco. And we've grown quite quickly, 115 as of the middle of January. I've heard that the business guide has actually been generating some interest, so we may be a little above that now, so hopefully that continues. You can see that there's a lot of major corporations participating in this. I know my company is very interested as we look for how does general purpose compute play into the space. So what's the mission of the group? So when you look at the standard, it really becomes how do we publish a standard that is a realistic open architecture so that everybody can participate, the suppliers, the integrators, the end users. Some of the things that we've talked about is the standard should be around some of the interfaces so that anybody can connect, if you will. So the intent is to utilize existing and emerging standards wherever possible. The group's intention is to, if at all possible, not create new standards. We'd like to create a standard of standards, if you will. But wherever there isn't one, obviously, we'll have to maybe take that on. And as I said earlier, we're addressing both the technical and business aspects within the framework so that recognizing that if it doesn't make a lot of business sense, it's not going to move forward very easily. So a little bit about the organization of the forum. So probably the key thing here to look at is the bottom row. So if we start on the lower left, if you will, the business working group. This is where Gene and I have led the subcommittee for the business guide. We're trying to address the ecosystem of players in the space to be able to make sure that it makes business sense to move forward. And Gene will talk a little bit about, I think one of the key slides you'll see today is how we envision the ecosystem playing out in the future and where that space comes in and how we thought through that. On the far right is the technical working group. So these folks are working on what should that technical standard be? How do we actually create that and what do we need to understand as the system is created to be able to pull in the right standards? And then the two middle groups here, one being the enterprise architecture working group is how we sort of pull the business and the technical leads together to make sure whether we understand kind of how they fit and how they interoperate. And then the standards body interface working group is helping us to go to find those standards that exist so that we're not creating something new that is already in the world today, unnecessarily, okay? So at this point, I'm gonna turn the presentation over to my colleague Gene. Just so you know, Gene just told me before we started here that this was his dream to present to the forum of a technical audience. So let's give him a round of applause as we fulfill his dream. It's nice to be able to check off those bucket list items. And so now talking in front of computer architects is off the list. So I'll pick up now where my colleague left off in terms of looking at the various groups and how they work together. Because it's important to understand how we're gonna develop these standards. It starts with business use cases written by end users and manufacturers and documenting use cases and things they'd like to see out of the future state system. In addition, one of the founding people and drivers of the Open Process Automation Forum, Don Bartusiak, during that November hot crowded room, he asked the member companies who are the founding members to contribute statements, founder statements, why they're joining the forum. And so between the business use cases and the founder statements, we started drawing out common themes that would form the basis of requirements. Those requirements were then turned over to our enterprise architecture working group for compilation, prioritization, getting further into the meaning of those requirements. In turn, those requirements will then drive the technical standard produced by the technical working group. So drawing back from the beginning, it starts with business use cases, which we've documented extensively in the business guide and wanna thank, there's some authors of portions of those business guides in the audience, thank you for your contribution. We use those business use cases plus the founder statements, and then from then teased out the requirements that the enterprise architects analyzed and then translate over to technical requirements as executed by the technical working group. And in that fashion, we have this flow through flow back to ensure that we have the requirements as documented by the enterprise architecture group satisfying the business use cases, the founder statements via the technical standard. And what we found through the business use cases, the request out to the companies, we drew from all across the process industries, so the oil and gas, we had submittals from mining and metals, pulp and paper, bulk cam, fine chemicals, biopharmaceutical, exploration and production, common themes across the industry. And those were distilled into the requirements driven, again, by business use cases and founder statements. So among those themes, we categorized them into technical themes and business outcomes. And Darren covered some of these already, he talked about interoperability. What we saw from most end users and manufacturers, disparate control systems within a factory or a plant, not talking to each other. And we really, as an end user myself, really want these systems to integrate seamlessly, reusable configuration, a lot of energy. And we've put into the code that runs our factories. That represents IP from our company. And we'd like to make it portable across platforms. So reusable configurations was another theme that came out in the business use cases. This one means a lot to me, personally, standard interfaces. I spent a lot of time doing custom APIs and custom drivers. And it took a lot of time. It was hard to maintain. So the need for standard interfaces was, again, a strong driver for putting this forum together. Integrating best-in-class technology, something Darren's already talked about. I'd like to elaborate a little further on something also Darren talked about, industrial internet of things. There is a large number, with the advent of cheap processors and inexpensive sensors, we see an explosion of data from the field, typically not connected to a control system. So it's IO in the field, not part of an existing control system. This data from the field, there's tremendous potential in driving, using analytics to drive further productivity insights, gain efficiencies in production. And so bringing that into a big data lake or a big data platform and doing analytics is something a lot of the end users would like to achieve. On the analytics piece, my company, and I think I speak for a lot of other manufacturers, we were setting up data science teams. And once we ingest this large body of data that's out in the field, bringing our scientists into the analysis, and again, to drive productivity benefits and improve yields, that's going to be enabled by the Open Process Automation Forum. Darren's talked about the cybersecurity piece. I'll delve into predictive maintenance. So another new area tied into industrial internet of things is the processors in the field and the ability to diagnose equipment, model the equipment for our company in particular. Big fans, pumps, motors, compressors that drive big equipment, we want it to run as long as possible. We're trying to avoid some kind of premature failure or catastrophic failure that brings about downtime in the manufacturing floor. So predictive maintenance is a piece that a lot of end users would like to continue to drive to, and again, driven by proliferation of inexpensive sensors and cheap computing power. Advanced control and modeling. So this, in particular, comes from the oil and gas industry. In operating big refineries, there's opportunities to layer on applications on top of the control platform. And it's not easily done with legacy systems that tend to have and require custom interfaces. So part of Open Process Automation Forum and the standard interfaces is to have that seamless integration of layered applications on top of control systems. So the seamless integration is something that a lot of people have been asking for as part of the technical themes. And then robotics, yet another control system for robots integrated on the platform needing to talk to the other systems in the manufacturing space. So the business themes, and I've kind of touched upon that through the technical themes, but the business outcomes that we seek to deliver include zero or minimal downtime, schedule flexibility. One use case in particular, I believe it comes from refining in chemicals, is the idea that rather than taking down the whole system and losing revenue during that time, is the ability to gain schedule flexibility, take down parts of the system, or one loop at a time, one part of the planet at a time, and be able to continue to run and so do upgrades in a way that achieves this zero or minimal downtime, as well as operating in a safe manner through this cutover migration. The standard interface piece really drives the next bullet, reduced engineering hours. So we're getting away from custom interfaces. With standard open interfaces, we'll be able to layer on applications, and with the certified products that are part of the open process automation suite, we should be able to take out the hours of maintenance and development of these custom interfaces. Speed to market and product quality and deferred, reduced capital spending, I'll draw from my own industry in pharmaceuticals. Often we're in competition with other companies, similar products arriving on the market at the same time, so there's a big advantage for those who are first to market, and in most of the plant and facility startups I've been associated in the farm industry, the qualification of the process control system has been the rate limiting step. That is the last step in bringing the factory up. So by reducing custom interfaces, we can compress the amount of time it takes to qualify the facility and bring it up and reduce the time to market. In addition, in the farm industry, we conduct clinical trials on people before we're allowed to release product to patients. And in doing these risky clinical trials, sometimes you can fail at phase two or phase three. So we've seen the problem in my industry where we've started a capital project, a long timeline product, and only at the very end of the clinical trials realize, hey, this is not as effective or safe as we thought it was. And then so you have all this wasted effort and deployment. If we can compress timelines in getting the facility, we can delay the deployment of the capital and make a decision at the last possible moment before spending all that capital. And so product traceability is enabled when all your systems in a factory talk to each other. And you can identify when in certain stages of a manufacturer of the product, there was a problem. And I talked about reduced qualification costs as well. So common themes that came out of business use cases and founder statements, which then are compiled into requirements, requirements then drive the open process automation standard. So another chapter, switching gears here, away from business use cases, but to the ecosystem that Darren referred to. We did, as part of the business working group, a very comprehensive analysis of the process control industry and the roles that are needed to develop, design, and deploy a process control system. And it's important to note that we need to think of these as roles in the ecosystem and not necessarily companies. Companies can play a single role in the ecosystem, but more often than not, they can encompass multiple roles. But we needed to do this breakdown of the ecosystem into roles for two reasons. For one, this is a business guide. And we're trying to speed up adoption and speed up understanding of what the form is trying to achieve. And so we did this ecosystem analysis and laid it out in the business guide so existing players in the ecosystems can read the guide and see themselves in the ecosystem. OK, yeah, this is where I am currently. And then we did a mapping into the future state using a business model canvas analysis. And this was to help those current players in the ecosystem see where they are today and where potentially they could go in the future. The second important reason to do the ecosystem was around understanding where we wanted to set up the open and published interfaces. And so in between roles, and I'll go through the roles now, there's an end user role, a system integrator role, a subsystem integrator role, hardware supplier role, software supplier role, and a service supplier role. So those were the identified roles within the ecosystem. And again, don't think of it in terms of companies. Although companies can comprise a single role, more likely companies can do various roles across the ecosystem. But the role analysis is important because we wanted to establish where handoffs took place and where we have handoffs, that's where we'll put in those open and published standards. An example to help people understand the roles in the process control, process automation space, if you think of a plant, a common plant like a power plant, you'll have an automation contractor typically for the whole power plant, and that would typically be a center system integrator role. The end user would be the power company, it could be an oil company, whoever's running the power plant. So the power plant typically consists of a turbine, you'll have the balance of plant, you'll have a boiler. Those are all subsystems within your power plant, and typically a subsystem integrator would be in charge of each component of that power plant. And then the turbine provider, for example, would contract out a hardware control system and then layer on software, maybe do it all in-house, maybe apportion it to someone else. But the key point is there is a trade-off, there is an exchange of requirements from one role to another, usually accompanied by money. And the deliverable from the supplier, the role of the supplier in that role, will be a design, maybe it's software, documentation, and the like. So it's in between roles where we see exchanges. Again, from one party, typically set of requirements and probably some money, and then in return they get code, and they get design deliverables and heck of a lot of documentation. So in those spaces is where we want to establish the open standards, and by identifying them earlier, we'll be better positioned for success in getting this work as a business ecosystem. So to do this analysis, we got together as a business working group and went through this business process called the Osterwalder Business Model Canvas. And what the business model canvas analysis does is you look at companies playing certain roles, you look at who their customers are, what their revenue streams are, what their costs are, what training do their people need to be able to execute as part of the ecosystem. And to get the best possible analysis we brought together, people from across the industry to do the analysis and provide feedback to each other. And out of this three-day workshop we developed the current state and a projected future state. And with that future state included what the value proposition of each role is in the future state, strengths, weaknesses, opportunities, threats in the future state. So going back to the original premise of why we did this workshop, why we had to do the analysis for the ecosystem, it was twofold. One, to get existing players in the ecosystem to read the business guide, see the role they currently play, and then read through the analysis that this team did to see and project into the future what opportunities do we have in the future in this ecosystem. And so you can read in great detail all we said about what the future state looks like in the business guide. But to give you a teaser here's some of the themes that we saw. A more flexible execution model once the open process automation standards are in place. We see more players being able to take on more roles within the ecosystem because of the published open standards. And lower barriers to entry and increased innovation. And as part of the original goal of doing the forum, the best in class solutions, that also came out as a theme that in multiple parts of the OPA ecosystem, best in class solutions would be able to be integrated more seamlessly. Importantly, there are also emerging business models and opportunities. So just because you have a current state with current revenue streams for role players in the ecosystem doesn't mean that those things are static. When you introduce the open standards, new revenue streams, new business models will emerge. And what we also conjectured was that first movers in the space, so if you follow the developments of the open process automation and you understand where things are today and where things may be in the future, being a first mover in the space will give you a better chance of increasing revenue and taking advantage of the new emerging business models. We also saw reduced customization, the ability to port software, software and configurations levered across platforms. Faster adoption of new technologies was also part of the hypothesis of the future state. And finally, conformance and certification being key to making it all work. So with that, I'll say a few words about conformance. Conformance, and I borrowed these slides, thank you, Louise, from a gentleman in the audience. And it was helpful to include this information, both in the business guide and as well to talk through this in this plenary session. Conformance is key to the success. It's understood as 100% adherence to the technical standard. And it's not enough for a company just to self declare, oh, we adhere to the OPAF standard. The conformance has to come from a verification authority and that verification authority will be stood up as part of the development of the open process automation forum. And the conformance has legal standing. And that's also important in ensuring the sanctity of the standard. Conformance is applicable to a product offering from a supplier following the open process automation standard. It's not the whole system itself. But if the system, as in its entirety is comprised of OPAF compliant components, you have high assurance for ultimately the end user that all the components will work in a seamless and tight fashion. And the conformance does not apply to the performance of the overall system just to adherence to the open process automation standard. And there will also be, as we develop out the conformance committee, a way to register conformant products and to advertise and market them as adherence to the OPAF standard. I'll say a few words as well about certification. Certification is primarily for buyers to be confident that what they're getting is a product that adheres to the open process automation standard and is gonna be able to allow the end user to integrate products without a lot of retesting and documentation. We're also trying to create preference for these conformant products. So in the marketplace, you have non-conformant products, you have conformant, and by creating a market for OPAF products and the certification of these products to try to drive preference to those products that conform to the standard. OPAF is looking to also establish a timely and affordable process that reduces redundant testing and integration costs. We talked about how that is a primary driver for doing the forum. We wanna protect the integrity of the technical standard. And finally, Darren and I, and we've got a new colleague joining us, Julie Smith. We're gonna take a crack at writing a contract guide. So following the business guide will be a contract guide and it'll include generic language for both suppliers and end users on how to transact an OPAF conformant product with generic language and guidelines to get people started. Okay, so with that, I'll turn it back over to Darren. He'll talk to us about quality attributes. So yeah, when we were looking at how we approached this problem, one of the things that we looked at was we brought the technical and the business leaders together into another workshop where we said we need to understand collectively what the quality attributes of the system need to entail. We started off by saying there are a few key ones that are so inherent that they're almost above and beyond kind of that attribute. So we'll talk about those were safety, resilience, and maintainability. So without those, the system wasn't even viable to begin with and then what we did was we looked at, we had, I don't know the exact number, at least 25 plus different attributes that we had kind of brainstormed ahead of that workshop. And the goal was to look at those, understand what each of those meant and there's an explanation in the guide as well on each of these that you see here as the top 10 on what those mean. And we collectively determined how, followed a process to determine what's the priority of them. And I think we'll just talk through maybe the first five here as important. So interoperability, I think you've heard that theme from myself as well as Gene a couple of times. I think that's probably obvious why that one came out on top. Modularity, so how do we be able to incorporate different portions of the system that can be deployed in various ways that interoperate. A standard conformance, which Gene did a little farther investigation on here and talked to you about. Want to make sure that anything that sort of gets the OPAF stamp of approval if you will is gonna be able to interface with the other components. Scalability, so how do you, how does this work from I've got a small instantiation where I only need maybe 12 to 50 IO or something that's based to a full on large factory of some sort that might have hundreds of thousands of inputs as well. So we need to be able to scale from small to large. And then security ability, obviously this one is the talk a lot in the space where we need this to really happen in a secure way because it is so important. I think we've talked about a lot of different breaches over the past several years that have become very public and trying to understand kind of what that means. The other five here, also very important but really the top five is what we called the highest of the high. And then we try to incorporate anything else so we can. So we think some of the, probably the next five here are going to be some of the first five are probably minimum requirements. The next five almost is where some of the value can be created in my opinion. Reliability, affordability, portability, availability. Those kind of things are available to be able to create value around for end users and for suppliers in the space. So one of the questions that we thought we would address in this presentation, I don't think we have addressed it particularly in the business guide other than mention it is. So why do we believe that we can be successful in this space? We're trying to utilize learnings from previous transformations and the two that have been called out in the past that we've had discussions upon or first are telecommunications to a software defined network. So if you go back several years and you look at AT&T in China Mobile, their networks were breaking if you will. They weren't scalable. It was a very proprietary hardware in the space and software and very expensive. So with the advent of smartphones that you all probably carry around in your pocket the explosion of data over those networks was becoming unbearable. The network providers couldn't keep up that sort of drove this transformation. And so being able to move to sort of an open type of system for networking. So all of your cell phones now run on a more open network as around the world. Like I said, the two big companies and users that drove that were AT&T in China Mobile. And so that was something that my company Intel was heavily involved in. And so we have some of those learnings as well as the future airborne capability environment or face which is part of the open group. And Dennis Stevens was part of that who's here with us today as well. So this one was the government didn't want to continue to pay to rewrite software as it moved from one platform to the next. And so they wanted to be able to create sort of standards around how that software was utilized and interacted so that they could reapply and reuse it as much as possible to from one platform to the next in order to become more efficient as the cost of generating new military platforms was becoming more and more expensive over time. So both of those have had very good success in the marketplace. And so we're looking to utilize the learnings from both of those transformations to help us with this one and understand kind of some of the key pitfalls and learnings at BKM so that when we do that we can accelerate this transformation as quickly as possible. So a little bit on the summary of the benefits. So we talked, these are obviously some very common themes that we've probably mentioned before but end users, we've talked about supports reuse of the control system application so that portability of those applications increases the value creation so we want the opportunity for the ecosystem to create additional value. Not just solving the end user problem but also of the suppliers and the system integrators and the space and the technology providers. Enables continuous innovation. So you have a common platform where you can continually drive forward that produces data that you can utilize and make your factory run better more efficiently, higher throughput and move from today, looking from just how do I make it more efficient to having a manufacturing facility even potentially become a strategic business asset for you as you move forward in new and innovative ways. Solves those integration issues so we're gonna have things that Gene has talked about in his own company is how do we buy skid tools and how do we make them interoperate? How do we add new features into our control system and allow it to connect in and we wanna be able to have that capability. It's safe and it's intrinsically secure. Obviously this is very important for any factory and empowers the workforce. So one of the things that we wanna be able to do is give the people, the tools to be able to do their jobs more effectively, more efficiently in the space and then ultimately we believe this can reduce the total cost of ownership. So hopefully in the up front CapEx as well as operational OpEx as it gets deployed. We're still working on proving how that might come into play as we sort of understand how the transformation might happen and so that'll be something that we continue to work on. From a supplier standpoint, the goal here is to let the overall pie grows and the top line grows by reaching new markets and customers in areas where maybe there wasn't an opportunity in the past. Data in the IoT space should create new opportunities and new use cases. Remaining relevant to existing customers, obviously you've built some of the suppliers have built long-term relationships with some of those customers and so it's important that they have that opportunity to continue and then creating new goods and services for expanded markets. So as new technologies come out, how do you make sure that you can adopt to those and get to market quickly? And then the idea here is also that you can grow your bottom line through increased margins and reduced costs, eliminating sort of non-differentiated products so you can utilize products multiple ways so that it doesn't have to be designed the same way multiple times. So obviously, like with most of these kind of things, it boils down to better, faster, cheaper but obviously there are things that we can try to do here to make this continue to move forward. So finally, this is our last slide here today. We'll talk about, we're trying to create an industrial control system with stakeholder companies, system integrators, users, hardware and software suppliers and that ecosystem slide that Gene showed you and we encourage folks that want to know more to go to the business guide, talk to Gene or Irene and the other members of the forum that are already here today and tomorrow and then learn more about it. There's obviously, there's a link here too as well. So I know we've had a lot of interest through the website as we track folks that are reading, pulling up the business guide and stuff, so we're encouraged by that but looking for more folks to join us. Thank you very much. Thank you gentlemen. We've got quite a few questions coming in for you. Won't be surprised to hear, but let's see. So before I get into the questions, it's so great to hear you from up on the view of the open group. It's so great to hear you talking about in the still fairly early stages talking about the importance of certification and conformance and starting with the business, you know, the business needs and the use cases and that's where it works best. So, you know, it's completely the right thing to do from our perspective and we look forward to working with you on that. So a few questions. It sounds as though the potential for efficiencies and savings is huge here. Has anyone put any numbers on this yet? So we have not done that yet. I mean, I think we're looking at it in some individual, individual companies are probably looking at it, but from a total market standpoint, I think that's, you know, still TBD. You know, I think right now we're probably, there are companies I've seen some reports and publishings that sort of have put some stakes in the ground of goals in the, you know, how do we cut CapEx and OpEx by half or things like that? Right. I mean, I know Gene, you forgot. Yeah, I'm actually part of another cross industry collaboration and we're doing some initial forays into setting up open systems and exchanging of communication with common data models. And as part of that prototype soft simulation, so to speak, we're also gonna take a look at what engineering hours are saved by, you know, through this use. So it'll help inform what some of those future savings are. And I can speak personally as a former, like API engineer that custom interfaces and all the engineering around that huge hours that come out of the system. It's both time and money in terms of engineering costs. Yeah, you mentioned that as you were talking that the efficiencies there. Next question, how is OPC UA similar, different or even interesting to the Open Process Automation Forum? So maybe I'll start with that. And I'm not an expert on OPC UA. I think I read a book about it once, but so that's the extent of it. And we think that's an important protocol that's been used in earlier versions, just classic OPC and now becoming more of an open standard, moving away from some Microsoft Decom components, truly becoming an independent protocol standards data model. It's got many things you can call it. And it's something that this Open Process Automation, the technical working groups are looking at it as one of the protocols, potentially as part of the standard of standards. Yeah, and obviously as we build a control system that utilizes more general purpose types of components, time-sensitive networking is gonna be critical. And so OPC UA is one of those standards that we're investigating to solve that as a problem, right? There are others, but that one is one that's all, of course, being discussed. Okay. What's being done to support ontological differences between IIoT devices? There must be vast amounts of time trying to understand what data is and to correlate it to value. You wanna take that one first? You first. Yes, I'm there. Well, so if I think of, I understand the question. So obviously there's a lot of data being generated in the industrial IIoT transformation that's happening. And so the data model and how you can utilize that data and the speed that it's delivered is very important. So Intel is transforming itself into a data company, so we're very concerned about that as well, just speaking from my own company experience and how that data gets used, I think we're still as a marketplace in general exploring. We recognize that there's tremendous potential there and there are pockets of it that are taking advantage of it that I've personally experienced, but it's still something where we're kind of figuring out how that plays into the marketplace. Yeah, I was just gonna add that the world of IIoT and the data standard is still evolving, emerging. It depends on where in the industry you're coming from. If you're coming from a process control space, you have certain opinions on what needs to be part of the protocol. So again, I'm gonna lean on the technical working group to look at the array of standards out there and see what's most appropriate for adoption as part of Open Process Automation Forum. It's still a non-mature space. I may be wrong, but I can probably guess where the question came from. We've had some interest in the Open Group for some time on ontologies and finding ways to, and we've even got a standard, ODEF, which is all around making it easier to find the common terminology and that's coming in that may be slightly different in one industry, but essentially is the same thing and using that. So I imagine somebody's gonna speak to you about that if they haven't already. Okay. We may be able to help or get in the way. Who knows? We'll tell you what we know and we'll make up what we don't, I guess. Okay, you have an impressive collection of industries involved in the forum. Are there any not involved so far that you would like to join up or get involved, it says? Well, I know one of the things that we've been pushing for that we think has to make this move forward is our representation of some of the end user manufacturers. We'd like to see some increases in as well. And then, obviously, you could list out probably numerous companies in various industries, but we are getting good representation, but there's always more work to do and more engagement. One of the reasons we put the business guide out was so that people could see that and hopefully join us. And we made a deliberate decision, the business working group, to focus on continuous processing industries, relatively speaking, as opposed to discrete parts manufacturing, which often already have established standards in their own open collaborations. But the idea is we would eventually also either partner with them, adopt some of their standards, or work in having their standards conform more to what's being developed out of the open process automation space. So continuous industries in particular, but with an eye on food and beverage, discrete parts manufacturing, that in the future, we'd like to see it all under one umbrella. Okay. Conformance and compliance are very important to pharmaceutical validation process, for example. It's embedded into the way the business works. Can you speak to how to convince other industries to work this way? So if you wanna work like the pharmaceutical division, yes, we're very good at validation, lots of documentation, because ultimately we don't have a right to sell pharmaceutical products. It is licensed, granted by the government. So we are under scrutiny and regulation by the government and to satisfy government regulators, very strict testing and very complete documentation. In some ways, that's why open process automation is such a benefit. Our ability to reuse components, modularity of code, porting IP across platforms, hinges on documenting the performance of the system and nothing being compromised. And that's why some of my colleagues that are so interested and excited about being part of the forum is that it's well suited in terms of the compliance certification piece towards the pharmaceutical industry. Okay, so that one was mostly for you, Gene. One that's specifically for you, Darren. How is Intel rationalizing the open process automation forum standards work with all the other industry bodies in the same space? Well, that's a good question. So Intel, obviously we played two hats potentially in this space. We are obviously a technology provider, but we're also a large manufacturer, so we're interested in how this goes forward. We do participate in a lot of different forums and trying to understand one of the things that we've been discussing lately is how does the open process automation forum, as well as some of the more sort of generic industrial IoT and fog forums come into play. One thing, reason that we're engaged here is because it is a very specific and targeted path forward for an industry that's looking to make a change. The other ones so far are dropping in use cases that are across various industries, so this one sort of fits into a very specific area of the marketplace. Like I said, you started with on the Industrial Solutions Division in IoT, and so this is something that's very interesting to us. Okay. Could you elaborate on the challenges with regard to integrated testing and performance of large systems made up of components from multiple vendors? Yeah, I can talk to that, and prior to working in the pharmaceutical industry, I worked in industrial gas, air separation, and energy, and so that power plant example I spoke of earlier was actually one of my previous projects and the integration systems. Typically, and this is what was done in the old days, is you would just layer on one overarching control system and then integrate with special drivers or APIs to subsystems, and it was never a clean development of these APIs and drivers, and so part of my own personal unfulfillment of being an integration engineer is part of the motivation of I joined the open process automation forum. I saw the need, I felt the pain early on in my career, and so it's very real, and if you look at other industries, if you look at telecom, if you look at face, how they have solved the problem through the open public standards, it really gives us a path forward to reducing the complexity of the integration. Okay. When you talked about standard of standards and not reinventing the wheel but filling gaps, when will you begin evaluating existing standards as part of the standard of standards or have you already identified any that will form part of this standard? So I mean, I know in the technical work group, they're already started looking in those spaces. Whether any have been finalized, I don't know yet, I think it's still in the evaluation phase, but the idea is if there's something that exists and is already agreed upon by the industry, there's no reason to try to create something new and into that space. I was just gonna add, following some of the latest developments of the technical working group, they're doing a gap analysis for certain protocols against the requirements and identifying those gaps, so the analysis is already going pretty deep and determining what's most suitable, what protocols will be part of that set of standards, satisfying as many requirements as possible. Okay, where could one find more in-depth information about how the interoperability actually works or its specification? I guess, yeah. You can come join the working group. The technical working group is a great place to join the forum and be part of it. Yeah. Great to hear you guys say that. We need more volunteer and have to. That's excellent. Yeah. Yeah, yeah. As with all that, I mean, you talked about workshops and I know workshops implies work and there's work to be done and only so many people involved, so sharing a load is good, isn't it? Yeah, we've been at this for a little over a year now and I think we've made great progress but there's still a lot of work to be done. Yeah. Okay, next one. This philosophy is way overdue. Are the hardware and software suppliers on board or is there a risk that the titans of industry will adapt to such an architecture or do new suppliers emerge that are more willing to adopt? Well, I mean, in the forum, we actually have major industrial OEM suppliers engaged, so Siemens, ABB, Schneider Electric and others are engaged in the forum and so if they were not engaged, we'd be a little more concerned in that space. Right. We're trying to engage, the forum tries to engage all the players in the ecosystem so you have titans, but the smaller players are important as well too. So laying out a business case through the business model campus, current state, future state is a way to show all players in the ecosystem what the future state looks like and get in early so you can learn what this is about and be a player in the future state. Yeah, and one of the things that I'll apparently mention as we said in the talk was it's important for us to understand how the business model changes for the players in that ecosystem slide that Gene showed so that there is space for innovation and growth. The idea is that the whole pie grows and everyone benefits. What I love about this forum is the specific engagement on the business side of the piece. How many standards have we seen? Small group of technical experts get together and it's a perfect technical standard that doesn't solve any business problem, business needs and kind of lies dormant for ages. So this one has business considerations up front driven by business use cases, founder statements and ultimately translated to the technical requirements. Absolutely, and I think going the extra step of the contract guide that you referred to when you were talking to you, I mean that actually helps the people who need to use it or we want to use this standard in procurements or wherever they're using it to actually apply it like they've done with the face standards. Okay, does the forum envisage a true standard with true portability among solutions, i.e. Profibus or OPC UA, within forced conformance or a standard like IEC 61131 which allows each supplier to develop their own flavor that are close enough? I guess it's hard conformance versus wiggle room. I'm not close enough to the technical working group to answer. I mean I know that the interfaces and the idea was that inside of the function there's a room for innovation and the interfaces would be a fairly hard standard to not difficult but strict conformance to. So how that plays out obviously we're at a stage where we maybe don't even have the final answer to that at this point. Whoever asked that question should join the technical working group. Absolutely. That's right, yeah, okay. So that's it for the questions. I know I understand you're doing a blog on this as well for us at the open group. Yeah, I believe it's already been sent out. It's already done, yeah. Okay, great stuff. Yeah, thank you. Thank you, so that's it. Load of questions and great presentation and good luck, a lot of work going on this week as well so good luck with that and thank you both. Yeah, thank you very much. Thank you for the opportunity. All right, thank you.