 Hi, I'm David Fort from Rockwell Automation, and I'm here to give you an update on version 2.1 of the open process automation standard. The open process automation specification is divided into parts shown here. Version 2.1 focuses on the black one, the gray ones are planned for the future. The scope of open process automation standard is shown here in the box, notably outside the box's safety instrumented systems and field devices and planned equipment. Field devices are things like temperature and pressure transmitters or valve positioners. OPAS systems are centered around a connectivity framework based on OPCUA, which facilitates communication between any participating control nodes, which we usually call DCNs, or distributed control nodes. DCNs can be dedicated to IO for measurement and control, or to computation, a mix of both, the gateway to systems such as PLCs or DCSs, or to other equipment such as analyzers or non-OPAS subsystems. Here's the OPAS architecture applied to an example plant. Some equipment is housed in a central control room, other in remote enclosures, and some on a modular package system such as a compressor skid. In version one of the OPAS standard, we focused on interoperability, the ability for devices to operate together on the same networks using OPC protocols and following the same set of security rules to exchange their information. In version 2.1, we've added layer F portability, which is function block programs being easily moved to other vendors' equipment such as you might have if you're opening a new plant or upgrading an existing plant. Coming versions of the specification will extend portability to other application types and enhance management capability and define a hardware platform. The interfaces circled in green here are the ones that are included in version 2.1. We used this Philo picture a lot to show the layered nature of the software architecture, and an analogy with Java might be to have a Java editor up at the top and a Java byte code program as a layer F application and a Java runtime environment as a layer I application and below that the connectivity and storage and OS tasks and schedule, scheduler and sockets, that kind of thing. Software security is essential in industrial applications, particularly large process control applications. OPAS security is based on IEC 62443 security standard. Each interface defined by OPAS has associated security requirements, but remember that security must be applied throughout the plant lifecycle and that everyone has a role in security. OPAS conformance certification revolves around the concept of profiles. Profiles define a set of requirements for some aspect of a product. For example, the communication aspect or the physical platform aspect. The profiles shown here in bold are new since the version 1 knows this fact. The OPAS communication framework leverages OPC UA, which provides client server and public subscribed transports and information models which describe how to organize and represent information and the GDS global discovery server to discover equipment, services and data available, location of signals and manage security credentials and authorization. OPAS standard 2.1 extends Redfish system management via a new profile that adds two new top level resources, one to describe distributed control nodes and one to provide information about the operating system. Part 6 is about information and exchange models. An exchange model represents design information that can be shared with other engineering tools. An information model defines how operational data is organized and communicated to online participants over the OCF. Under F, function block applications are encoded in vendor neutral AML files and packaged in open packaging convention OPAS zip files. OPC UA information models are defined for control devices, function block applications, function blocks alarms, signals and other things. Here is an UML diagram of some of the main objects defined by part 6.2 of the OPAS specification. Here is a UML diagram showing how OPAS representation of signals derives from the base OPC UA variable types. Here is the same picture using the OPC information model syntax instead of UML and it makes it clear that OPAS signals are compatible with PA DIMM signals. PA DIMM is a standard for process automation devices information model and is used to represent temperature, flow level, pressure, valve positioners and that sort of thing on OPC UA. Here is an OPC information model of a DCN providing the same interfaces as PA DIMM for vendor information such as make model and serial number and health information and we've added a function block engine. Part 6.3 specifies how alarm configurations are encoded in AML for export and import and it defines the run time information model used to exchange and manage alarms among OPAS components using OPC. Next we'll be defining hierarchies and how best to represent them in a distributed environment. Part 6.4 defines a non-exclusive set of commonly used function blocks, analog input and output, proportional integral and derivative block, discrete input and output, multiple discrete input and output. The standardization of function blocks is done at the interface level and that in particular is the pins and the parameter names and types, the interblock signal connections such as the cascade relationship, the status and mode and the data interface to the HMI or similar applications. We also have a reference implementation but that is just informative. You aren't required to do it that way. Another function block types are to come in version 3. As an example of the kind of information provided in the specification, on the left you see the functional logic for a PID block and on the right the information model that says how the variables within the PID block are exposed to other clients on the OCF communication network. IEC 61499 is a control programming system using distributed event-driven function blocks. This section is still under construction. IEC 61131 is a control programming system using function blocks, structured text, ladder diagrams. Part 6.6 defines the import-export information model used by IEC 61131 application development tools and specifies the UA nodes in the information model that the OPAS application must provide in its OPC server. These rules are used by the function blocks defined in part 6.4 that we talked about earlier and also by vendor or end-user custom function blocks. Version 2.1 of the OPAS spec introduces a few requirements for generic or vendor-specific distributed control node hardware, but the big progress since Version 1 has been the design of two proposed physical platforms. We plan to incorporate learnings from these prototypes in Version 3 physical platform spec. This slide shows an Intel proposal where there have a bus containing a handful of compute nodes and connected to those compute nodes on another bus are up to 96 single-channel I.O. modules. And in the center here you see a CAD drawing of a mechanical mockup and on the right a prototype. Another proposal came from Georgia Tech Research Institute funded by ExxonMobil and it's similar architecture as you can see on the right that you have a handful of compute modules that are connected on a bus with up to 96 single-channel I.O. modules. The CAD drawing on the left is a rendering of the prototypes that they built and demonstrated for us. To validate the OPAS specification and to help clarify topics, we've spent a lot of time in the past few months doing a manual walkthrough of building a system using the OPAS specification. We started with a piping and instrumentation drawing of a small example process. The functional elements for the section we want to control resulting in this simple function block diagram arbitrarily assigned the function blocks to different control nodes just to make the example interesting. Resulting in this topology of four control nodes connected to the OCF Ethernet network, some nodes have function blocks, some have I.O., some have both. We show how process values are communicated between control nodes via OCF giving each signal an alias name that can be looked up in GDS to find its physical location. Here is a subsection of the function block application to control this process showing OCFB blocks to communicate between control nodes and PID block to compute the control action. This slide shows how the data within the various function blocks is mapped into the OPC server and the OPAF information model. The red line shows the representation of the execution engine running the function blocks and the purple is the instance of an OCFB block which is named AI2 OCFB0 out and the yellow shows one of the parameters within that block being mapped to the outgoing variable OPC item. HMI graphics can be linked to the OPC UA information model. Note that HMI is not standardized so the presentation can be vendor specific but the layout of the data on the network is standardized and the HMI or any other application can access it subject to it to secure authorization. Here you can see the mapping of one of the graphic objects for the PV in this case and where that comes out of the OPC information model over at the right. This concludes our quick walkthrough of version 2.1 of the open process automation specification. You can download a copy from the URL shown and submit comments to ogspecs at opengroup.org and I hope you will. I look forward to seeing your creative application of this specification.