MAY-JUN 2019

Issue link:

Contents of this Issue


Page 11 of 55

Standard of standards Creating a "standard of standards" for open, interoperable, and secure auto- mation is a complex undertaking. OPAF intends to speed up the process by le- veraging the valuable work of various groups in a confederated manner. The OPAS Standard will reference ex- isting and applicable standards where possible. Where gaps are identified, OPAF will work with associated or- ganizations to update the underlying standard or add OPAS requirements to achieve proper definition. Therefore, OPAF has already established liaison agreements with the following organi- zations: ● Control System Integrators Associa- tion (CSIA) ● Distributed Management Task Force (DMTF), specifically for the Redfish API ● FieldComm Group ● Industrial Internet Consortium (IIC) ● International Society of Automation (ISA) ● NAMUR ● OPC Foundation ● PLCopen ● ZVEI Additionally, OPAF is in discussions with AutomationML and the ISA Secu- rity Compliance Institute (ISCI) as an ISA 62443 validation authority. In addi- tion to these groups, the OPC Founda- tion has joined OPAF as a member, so no liaison agreement is required. As an example of this cooperation in practice, OPAS Version 1.0 was created with significant input from three exist- ing standards, including: ● ANSI/ISA 62443 (adopted by IEC as IEC 62443) for security ● OPC UA adopted by IEC as IEC 62541 for connectivity ● DMTF Redfish for systems manage- ment (see redfish) Next step: Configuration portability Configuration portability, now under development for OPAS Version 2.0, will address the requirement to move con- trol strategies among different auto- mation components and systems. This has been identified by end users as a requirement to allow their intellectual property (IP), in the form of control strategies, to be portable. Existing stan- dards under evaluation for use in Ver- sion 2.0 include: ● IEC 61131-3 for control functions ● IEC 16499 for execution coordination ● IEC 61804 for function blocks O-PAS Version 3.0 will address ap- plication portability, which is the abil- ity to take applications purchased from software suppliers and move them among systems within a company in accordance with applicable licenses. This release will also include the first specifications for hardware interfaces. Under the OPAS hood The five parts that make up O-PAS Ver- sion 1.0 are listed below with a brief summary of how compliance will be verified (if applicable): ● Part 1 – Technical Architecture Over- view (informative) ● Part 2 – Security (informative) ● Part 3 – Profiles ● Part 4 – Connectivity Framework (OCF) ● Part 5 – System Management Part 1 – Technical Architecture Overview (informative) describes an OPAS-confor- mant system through a set of interfaces to the components. Read this section to understand the technical approach OPAF is following to create the O-PAS. Part 2 – Security (informative) addresses the necessary cybersecurity functional- ity of components that are conformant to OPAS. It is important to point out that security is built into the standard and permeates it, as opposed to being bolted on as an afterthought. This part of the standard is an explanation of the security principles and guidelines that are built into the interfaces. More spe - cific security requirements are detailed in normative parts of the standards. The detailed normative interface specifica - tions are defined in Parts 3, 4, and 5. These parts also contain the associated conformance criteria. Part 3 – Profiles defines sets of hardware and software interfaces for which OPAF will develop conformance tests to make sure products interoperate properly. The O-PAS Version 1 profiles are: ● Level 1 Interoperability Hardware Profile: A certified product claiming conformance to this profile shall implement OSM-Redfish. ● Level 2 Interoperability Hardware Profile: A certified product claiming conformance to this profile shall implement OSM-Redfish BMC. ● Level 1 Interoperability Software Pro- file: Software claiming conformance to this profile shall implement OCF- 001: OPC UA Client/Server Profile. ● Level 2 Interoperability Software Pro- file: Software claiming conformance to this profile shall implement OCF- 002: OPC UA Client/Server and Pub/ Sub Profile. The term "Level" in the profile names refers to profile levels. Part 4 – Connectivity Framework (OCF) forms the interoperable core of the system. The OCF is more than just a network, it is the underlying structure allowing disparate components to interoperate as a system. The OCF will use OPC UA for OPAS Versions 1.0, 2.0, and 3.0. Part 5 – System Management covers foundational functionality and inter- face standards to allow the manage- ment and monitoring of components using a common interface. This part will address hardware, operating sys- tems and platform software, applica- tions, and networks—although at this point Version 1.0 only addresses hard- ware management. Conformance criteria are identified by the verb "shall" within the O-PAS text. An OPAF committee is working on a conformance guide document that will be published later this year, which explains the conformance program and requirements for suppliers to ob- tain a certification of conformance. Technical architecture The OPAS Standard supports commu- nication interactions that are required within a service-oriented architecture (SOA) for automation systems by out- COVER STORY 12 INTECH MAY/JUNE 2019 WWW.ISA.ORG

Articles in this issue

Links on this page

Archives of this issue

view archives of InTech - MAY-JUN 2019