The Open Group Standard

O-PAS™ Standard, Version 2.1

Part 1 – Technical Architecture Overview (Informative)

Copyright © 2023, The Open Group

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, without the prior permission of the copyright owners.

Any use of this publication for commercial purposes is subject to the terms of the Annual Commercial License relating to it. For further information, see www.opengroup.org/legal/licensing.

The Open Group Standard

O-PAS™ Standard, Version 2.1: Part 1 – Technical Architecture Overview (Informative)

ISBN: 1-957866-10-9

Document Number: C230-1

 

Published by The Open Group, February 2023.

Comments relating to the material contained in this document may be submitted to:

The Open Group, Apex Plaza, Forbury Road, Reading, Berkshire, RG1 1AX, United Kingdom

or by electronic mail to:

ogspecs@opengroup.org

---

Preface

The Open Group

The Open Group is a global consortium that enables the achievement of business objectives through technology standards. With more than 900 member organizations, we have a diverse membership that spans all sectors of the technology community – customers, systems and solutions suppliers, tool vendors, integrators and consultants, as well as academics and researchers.

The mission of The Open Group is to drive the creation of Boundaryless Information Flow™ achieved by:

• Working with customers to capture, understand, and address current and emerging requirements, establish policies, and share best practices
• Working with suppliers, consortia, and standards bodies to develop consensus and facilitate interoperability, to evolve and integrate specifications and open source technologies
• Offering a comprehensive set of services to enhance the operational efficiency of consortia
• Developing and operating the industry’s premier certification service and encouraging procurement of certified products

Further information on The Open Group is available at www.opengroup.org.

The Open Group publishes a wide range of technical documentation, most of which is focused on development of Standards and Guides, but which also includes white papers, technical studies, certification and testing documentation, and business titles. Full details and a catalog are available at www.opengroup.org/library.

This Document

This document is Part 1 of the Open Process Automation™ Standard (the O-PAS™ Standard), Version 2.1, a standard of The Open Group. It has been developed and approved by The Open Group.

The O-PAS Standard consists of the following 12 parts:

• O-PAS Part 1 – Technical Architecture Overview (Informative) (this document)
• O-PAS Part 2 – Security
• O-PAS Part 3 – Profiles (Informative)
• O-PAS Part 4 – O-PAS Connectivity Framework (OCF)
• O-PAS Part 5 – System Management
• O-PAS Part 6.1 – Information and Exchange Models: Overview and Interfaces
• O-PAS Part 6.2 – Information and Exchange Models: Basic Configuration
• O-PAS Part 6.3 – Information and Exchange Models: Alarm and Events Configuration
• O-PAS Part 6.4 – Information and Exchange Models: Function Blocks
• O-PAS Part 6.5 – Information and Exchange Models: IEC 61499
• O-PAS Part 6.6 – Information and Exchange Models: IEC 61131
• O-PAS Part 7 – Physical Platform

The parts listed above are separate documents that can be updated and re-versioned as required as we move forward with the O-PAS Standard.

This document supersedes the O-PAS Preliminary Standard, Version 2.1 published in May 2021, the O-PAS Preliminary Standard, Version 2.0 published in February 2020, and the O-PAS Standard, Version 1.0 published in December 2019.

Conventions

A Glossary and Abbreviations reference is available. If a term is not defined in that document then the common English definition, as defined in Merriam-Webster’s Collegiate Dictionary, applies.

Trademarks

ArchiMate, DirecNet, Making Standards Work, Open O logo, Open O and Check Certification logo, Platform 3.0, The Open Group, TOGAF, UNIX, UNIXWARE, and the Open Brand X logo are registered trademarks and Boundaryless Information Flow, Build with Integrity Buy with Confidence, Commercial Aviation Reference Architecture, Dependability Through Assuredness, Digital Practitioner Body of Knowledge, DPBoK, EMMM, FACE, the FACE logo, FHIM Profile Builder, the FHIM logo, FPB, Future Airborne Capability Environment, IT4IT, the IT4IT logo, O-AA, O-DEF, O-HERA, O-PAS, Open Agile Architecture, Open FAIR, Open Footprint, Open Process Automation, Open Subsurface Data Universe, Open Trusted Technology Provider, OSDU, Sensor Integration Simplified, SOSA, and the SOSA logo are trademarks of The Open Group.

AutomationML is a registered trademark of AutomationML eV..

Dell is a trademark of Dell, Inc. or its subsidiaries.

FOUNDATION is a trademark of the Fieldbus Foundation.

Gartner is a registered trademark of Gartner, Inc.

GitHub is a trademark of GitHub, Inc.

HART is a registered trademark of the HART Communication Foundation.

HP is a registered trademark of Hewlett-Packard Development Company LP.

Java is a registered trademark and JavaScript is a trademark of Oracle Corporation and/or its affiliates.

Lenovo is a registered trademark of Lenovo in the United States, other countries, or both.

Linux is a registered trademark of Linus Torvalds in the US and other countries.

Microsoft and Visual Studio are registered trademarks and Windows is a trademark of Microsoft Corporation in the United States and/or other countries.

OPC Foundation is a registered trademark of OPC Foundation.

PA-DIM is a trademark of FieldComm Group, Inc.

Polarion is a registered trademark of Polarion AG.

PROFIBUS is a registered trademark of PROFIBUS Nutzerorganisation eV.

Python is a registered trademark of Python Software Foundation.

Redfish is a registered trademark of Distributed Management Task Force, Inc.

SuperMicro is a registered trademark of Super Micro Computer, Inc.

UML is a registered trademark and Unified Modeling Language is a trademark of Object Management Group, Inc. in the United States and/or other countries.

All other brands, company, and product names are used for identification purposes only and may be trademarks that are the sole property of their respective owners.

Acknowledgements

The Open Group gratefully acknowledges the International Society of Automation for use of the ISA copyrighted ANSI/ISA-18.2 and ANSI/ISA 62443 series of standards. Visit www.isa.org.

The Open Group gratefully acknowledges and thanks the OPC Foundation for the template used to develop an OPC UA Companion Specification that is included in the O-PAS Standard. Visit www.opcfoundation.org.

The Open Group acknowledges DMTF as copyright owner of the Redfish^® standard, which is used in the O-PAS Standard. DMTF is a not-for-profit association of industry members dedicated to promoting enterprise and systems management and interoperability. Members and non-members may reproduce DMTF specifications and documents for uses consistent with this purpose, provided that correct attribution is given. Additional information is available at: www.dmtf.org/about/policies/copyright.

The Open Group gratefully acknowledges the contribution and leadership of the Co-Chairs of the Open Process Automation™ Forum and Working Groups.

(Please note affiliations were current at the time of approval.)

Forum Co-Chairs

• Don Bartusiak – Collaborative Systems Integration, LLC
• Jacco Opmeer – Shell

Business Working Group Co-Chairs

• Luis Duran – ABB AG
• Julie Smith – DuPont

Enterprise Architecture Working Group Co-Chairs

• Dave Emerson – Yokogawa Electric Corporation
• Harirajan Padmanabhan – hpad, Inc.

Technology Working Group Co-Chairs

• Kirk Smith – Intel Corporation
• Sølve Raaen – Kongsberg Maritime

Certification Working Group Co-Chairs

• Ed Agis – Intel Corporation
• Sharul Rashid – Petronas

The Open Group gratefully acknowledges the contribution of the following individuals in the development of this document.

(Please note affiliations were current at the time of approval.)

• David Fort – Rockwell Automation (Subcommittee Lead)
• Kirk Hansen – Enterprise Transformation Partners (Subcommittee Lead)
• Kirk Smith – Intel Corporation (Subcommittee Lead)

The Open Group gratefully acknowledges the following reviewers who participated in the Company Review of this document.

(Please note affiliations were current at the time of approval.)

• Aneil Ali – The Open Group
• Zhafran Abdul Aziz – Petronas
• Steve Bitar – ExxonMobil Corporation
• Amanda Blevins – VMware, Inc.
• Trevor Cusworth – Schneider Electric
• David DeBari – ExxonMobil Corporation
• David Fort – Rockwell Automation
• Cathy Fox – The Open Group
• Craig Griffin – Wind River Systems
• Nisha Jains – Intel Corporation
• Alex Johnson – Schneider Electric
• Jim Luth – Schneider Electric
• Tim Mirth – Rockwell Automation
• Hari Padmanabhan – hpad, Inc.
• Sølve Raaen – Kongsberg Maritime
• Julie Smith – DuPont
• Kirk Smith – Intel Corporation

Referenced Documents

The following documents are referenced in Part 1 of the O-PAS Standard.

The documents are referred to in the text in such a way that some or all of their content constitutes requirements of this part. For dated references, only the version cited applies. For undated references, the latest version of the referenced document (including any amendments) applies.

(Please note that the links below are good at the time of writing but cannot be guaranteed for the future.)

Normative References

Part 1 of the O-PAS Standard is informative, so there are no normative references.

Informative References

• ANSI/ISA-62443-1-1:2007: Security for Industrial Automation and Control Systems – Part 1-1: Terminology, Concepts, and Models (adopted by IEC as IEC 62443-1-1)
• ANSI/ISA-62443-4-2:2018: Security for Industrial Automation and Control Systems – Part 4-2: Technical Security Requirements for IACS Components
  (adopted by IEC as IEC 62443-4-2)
• IEC 60715:2017: Dimensions of Low-Voltage Switchgear and Controlgear – Standardized Mounting on Rails for Mechanical Support of Switchgear, Controlgear, and Accessories; refer to: https://webstore.iec.ch/publication/29026
• IEC 61131-3:2013: Programmable Controllers – Part 3: Programming Languages; refer to: https://webstore.iec.ch/publication/4552
• IEC 61499-1:2012: Function Blocks – Part 1: Architecture; refer to: https://webstore.iec.ch/publication/5506
• IEC 61512-1:1997: Batch Control – Part 1: Models and Terminology (ISA 88.00.01); refer to: https://webstore.iec.ch/publication/5528
• IEC 62264-1:2013: Enterprise-Control System Integration – Part 1: Models and Terminology (ISA 95.00.01); refer to: https://www.iso.org/standard/57308.html
• IEC 62264-3:2016: Enterprise-Control System Integration – Part 3: Activity Models of Manufacturing Operations Management (ISA 95.00.03); refer to: https://www.iso.org/standard/67480.html
• IEEE Std 829-2008: IEEE Standard for Software and System Test Documentation; refer to: https://standards.ieee.org/ieee/829/3787/
• IETF RFC 2119: Key Words for Use in RFCs to Indicate Requirement Levels, March 1997; refer to: https://tools.ietf.org/html/rfc2119
• ISA-TR106.00.01: Procedure Automation for Continuous Process Operations – Models and Terminology; refer to: https://www.isa.org/isa106
• ISO/IEC/IEEE 24765:2017: Systems and Software Engineering – Vocabulary; refer to: www.iso.org/standard/71952.html
• ISO/IEC Guide 51:2014: Safety Aspects – Guidelines for their Inclusion in Standards; refer to:https://www.iso.org/standard/53940.html
• O-PAS Standard, Version 2.1: Part 2 – Security, The Open Group Standard (C230-2), February 2023, published by The Open Group; refer to: www.opengroup.org/library/c230
• O-PAS Standard, Version 2.1: Part 4 – O-PAS Connectivity Framework (OCF), The Open Group Standard (C230-4), February 2023, published by The Open Group; refer to: www.opengroup.org/library/c230
• O-PAS Standard, Version 2.1: Part 5 – System Management, The Open Group Standard (C230-5), February 2023, published by The Open Group; refer to: www.opengroup.org/library/c230
• O-PAS Standard, Version 2.1: Part 6.1 – Information and Exchange Models: Overview and Interfaces, The Open Group Standard (C230-6a), February 2023, published by The Open Group; refer to: www.opengroup.org/library/c230
• O-PAS Standard, Version 2.1: Part 6.2 – Information and Exchange Models: Basic Configuration, The Open Group Standard (C230-6b), February 2023, published by The Open Group; refer to: www.opengroup.org/library/c230
• O-PAS Standard, Version 2.1: Part 7 – Physical Platform, The Open Group Standard (C230-7), February 2023, published by The Open Group; refer to: www.opengroup.org/library/c230
• The Industrial Internet of Things Volume G5: Connectivity Framework (IIC:PUB:G5:V1.0:PB:20170228), Industrial Internet Consortium; refer to: https://www.iiconsortium.org/IICF.htm

1.1 Objective

The Open Process Automation™ Standard (the O-PAS™ Standard) defines common interfaces that support the development of open process automation products, enabling interoperable, interchangeable, portable, and modular best-practice implementations of Distributed Control Systems (DCSs at scale.

This document describes the overall Technical Architecture of an industrial automation control system containing O-PAS conformant components. These components interact through the defined interfaces to meet the requirements of a distributed and secure process automation system that has an open architecture and that considers the impact of 23 key quality attributes shown in Table 1 and described in Section 1.2.1.

Table 1: Quality Attributes

Quality Attributes
Affordability	Availability	Compatibility	Configurability
Discoverability	Evolvability	Flexibility	Interchangeability
Interoperability	Maintainability	Manageability	Modularity
Portability	Reliability	Resilience	Reusability
Safety	Scalability	Securability	Standard Conformance
Testability	Traceability	Useability

This document has seven chapters, as follows:

Chapter	Role
1	Further defines the quality attributes with specific examples from the standard and outlines the interface concept.
2	Describes key terms.
3	Describes the overall Technical Architecture of an Industrial Automation Control System containing conformant products.
4	Provides an overview of specific interface concepts envisioned as open architecture interfaces evolve and become specified in more detail over time.
5	Describes the O-PAS Connectivity Framework (OCF) service foundations for standardizing interoperability between applications.
6	Introduces the scope and breadth of system security, based on the conformant products envisioned.
7	References forward-looking platform-independent application interfaces planned for further development.

The O-PAS Standard is developed by the Open Process Automation™ Forum (OPAF), a Forum of The Open Group.

1.2 Overview

The Technical Architecture allows for construction of reliable, secure process automation systems that are scalable from very small to very large, that do not require process shutdown to perform updates and extensions, and that can be applied to existing plants and to new construction. The Technical Architecture has been defined to not compromise the safety, resilience, reliability, maintainability, and security of a process automation system.

1.2.1 Quality Attributes

The O-PAS Technical Architecture facilitates the key quality attributes selected by OPAF. The foundational quality attributes are safety, reliability, and securability.

Going beyond those, a central goal of OPAF is to allow development of process automation systems with components from multiple vendors, without requiring custom integration. This will demand a high level of the following quality attributes:

• Interchangeability: the ability of a component to be replaced by an equivalent component from another vendor without modification

This requires the interfaces between components to be clearly defined.

• Interoperability: the ability of two or more systems or components to exchange information and to use the information that has been exchanged

This requires the information flow across an interface to be provided as a critical part of the interface’s definition.

• Portability: the ease with which a system or component can be transferred from one hardware or software environment to another

• Modularity: the degree to which a system or computer program is composed of discrete components such that a change to one component has minimal impact on other components

Desired quality attributes and examples of how the O-PAS Standard achieves them are listed in Table 2.

Table 2: Quality Attributes

Quality Attribute	Description	Examples of the O-PAS Approach
Affordability	A characteristic of design, expressed as a solution that meets a customer’s needs or requirements at an acceptable price (to include recurring and non-recurring cost).	Common design avoids duplicate invention. Open systems drive competitive innovation to reduce cost. Modular design allows right-size scaling and expansion as needed. Standard interfaces with defined component capacities (such as processor speed, storage, etc.) enable use of off-the-shelf technologies. Upon failure, only failed components need to be replaced. Standard interfaces reduce training costs.
Availability	The degree to which a system or component is operational and accessible when required for use. Source: ISO/IEC/IEEE 24765:2017	The O-PAS Standard does not currently have specific guidance on availability, but expects vendors to provide components and systems to provide needed availability for a given process requirement.
Compatibility	The capability of a functional unit to meet the requirements of a specified interface without modification. Source: ISO/IEC/IEEE 24765:2010(E)	Ethernet and standards-based protocols enable exchange of data between disparate control products without regard to vendor or capacity or function. Physical interconnect standards are being defined to facilitate interconnection of products. Behavior of function block cascade mechanisms and mode change behavior is defined to allow seamless exchange of information between control elements. Leveraging common standards, such as DIN connectors, PCI connectors, OPC, etc., ensures compatibility with a wide variety of products.
Configurability	The capability of being tailored or adjusted with a finite set of parameters in the context of stakeholder needs.	In addition to standardized function blocks (data and semantics), mechanisms to define new function block types are provided.
Discoverability	The ability to find an item and understand its information exchanges and capabilities.	OPC UA and Redfish® allow the discovery of: OPC UA servers DCNs Capabilities of DCNs Information that can be exchanged by a DCN Services provided by a DCN Location of information
Evolvability	The ability of an item to be extended or enhanced with new capabilities over time.	Technology insertion is eased via replacement of independent modular components as technology increases capability. New components might be from a different vendor, and can implement backward-compatible interfaces.
Flexibility	The ease with which a system or component can be modified for use in applications or environments other than those for which it was specifically designed. Source: ISO/IEC/IEEE 24765:2017	Modularity and configurability combined with ease of inserting new or different technologies allows application-specific solutions, tailoring a solution to a specific industry, or transferring a solution from one industry to another unrelated industry.
Interchangeability	Ability of a component to be replaced by an equivalent component, possibly from another vendor, without modification.	Standardized software and hardware interfaces; e.g., OPC UA information models for representing function blocks, system management, security interfaces, and alarm interfaces.
Interoperability	The ability of two or more systems or components to exchange information and to use the information that has been exchanged. Source: ISO/IEC/IEEE 24765:2017	The O-PAS Standard focuses on defining interfaces; some examples are API, messaging, and hardware (see Section 1.2.2). The O-PAS Standard standardizes the representation of information using information models and AML files, and O-PAS Part 4 defines how that information is communicated via OPC UA throughout the control system. These formats define an interface and follow a set of international standards for Manufacturing Operations Management and Control – Level 2 and 3 information exchanges, as defined in IEC 62264-3. Defined through interfaces and information models, using existing standards where feasible and The Open Group standards, extensions, or profiles where needed.
Maintainability	The ease with which a hardware or software system or component can be repaired or modified to: Change or add capabilities Correct faults or defects Improve performance or other attributes Adapt to a changed environment Source: ISO/IEC/IEEE 24765:2017	The Redfish System Management Interface facilitates diagnosis. Modular design allows replacement of individual components. Update and upgrade of software and hardware are allowed by standard interfaces. This makes it feasible to switch to a different version or different vendor if the original component is not available or lacks needed capacity. A system can be implemented to be incrementally upgraded and enhanced, without system shutdowns and without turning off power to the rest of the system: Allows incremental upgrades by replacement of components with the same or additional functionality, without system redesign Provides the ability to move applications across control nodes without modification, allowing recovery from control node failure
Manageability	The ability to monitor and control the state of health of system components.	Standardized system management interfaces (e.g., Redfish) provide system-level situational awareness for system-level data for both hardware and software components. Standardized connectivity provides a common information model framework and interface to manage multi-vendor applications. Increased standardization of IEC 61131 and IEC 61499 interfaces support a common approach for management at scale. O-PAS function block interfaces and standardized algorithms support migration and orchestration across vendor devices. Standardized interfaces support common deployment, upgrade, update, and patching methods at scale for defined hardware and software interfaces, including deployment, onboarding, and orchestration techniques.
Modularity	The degree to which a system or computer program is composed of discrete components such that a change to one component has minimal impact on other components (Source: ISO/IEC/IEEE 24765:2017) The degree to which a system’s components may be separated and re-combined (Source: Wikipedia)	“Profiles” are used to define the interfaces of modular components, so that components from different vendors satisfying the same profile have the same minimal functionality. Ethernet and standards-based protocols (e.g., OPC UA with the use of aliases) can be used to separate physical location and use of signals and allow separation of control functions into discrete components.
Portability	The ease with which a system or component can be transferred from one hardware or software environment to another. Source: ISO/IEC/IEEE 24765:2017	Examples encompass import, export, and migration of workloads at scale. Interface standardization makes IEC control workload configurations portable from one system to another. Generic workload portability interface standardization recognizes and supports Virtual Machines (VMs) and containers as forward-looking mechanisms for a broad class of applications used in OT and IT environments. For example, function block programs are exported and imported using IEC standard formats. Configurations are exported and imported using AML.
Reliability	The ability of a system or component to perform its required functions under stated conditions for a specified period of time. Source: ISO/IEC/IEEE 24765:2017	O-PAS component specification decisions have been made in ways that do not impede reliability. System reliability decisions (such as failover or high availability) are issues for system design rather than component specification. Vendors are encouraged to provide components that offer the needed reliability for a given process requirement.
Resilience	The ability of a system or component to perform its required functions despite adverse events.	OPC servers can be configured for redundancy, and standard Ethernet infrastructure can be deployed in resilient configurations. Provides the environment for k-out-of-n redundancy, where a node may assume the role of a failed node and either run its applications, use alternate I/O, or simulate the failed I/O. Redundancy can be implemented on an I/O point-by-I/O point basis, reducing the scope of failure to a single loop and providing the capability for automatic transfer of control logic.
Reusability	The degree to which a component can be used in more than one system, or in building other systems. Source: IEEE Std 829-2008	Modularity and configurability allow tailoring a solution to a specific industry, or transferring a solution from one industry to another unrelated industry, or reusing equipment in a different process in the same plant. Replacement of existing instruments or wiring is not required.
Safety	The expectation that a system or component does not, under defined conditions, lead to a state in which human life, health, property, or the environment is endangered. Source: ISO/IEC/IEEE 24765:2010(E)	ANSI/ISA 62443 cyber-security requirements increase safety. Status and quality information is communicated with each process variable measurement or actuator command. Dedicated functional safety systems (e.g., SIS) are out of scope. Duplicate transmitters can be connected to separate I/O-Channels to provide high availability measurement of some process attribute. If one transmitter or I/O-Channel fails, the signal value can come from the other.
Scalability	The degree to which a system can have its capacities adjusted to meet system requirements.	Modular design and standardized interfaces allow adding or removing capacity as needed, including future expansion. This is achieved through the ability to change the number of DCNs (scale out) and the ability to increase the capacity of individual DCNs (scale up), without any changes to the architecture and minimal impact on other components. The end user is only required to buy the needed capability and capacity and can easily add or remove capabilities or capacity later.
Securability	The ability of a system or component to be protected against unauthorized access or modification throughout its lifecycle.	ANSI/ISA-62443-4-2 SL2 certification is required for each O-PAS certified component. Security is designed into all aspects to allow low lifetime support efforts to maintain updates and patches, and to allow secure communication between components and other systems.
Standard Conformance	Satisfying 100% of the Conformance Requirements (CRQ) of any O-PAS profile claimed or implemented.	This is achieved through the definition of interface functions and information exchanges based on IEC, ISO, ISA, and other internationally recognized standards that have a means of testing conformance. All of the standard interfaces have conformance tests and profiles defined which describe what conformance tests are met to provide evidence of conformance. The O-PAS Standard has a robust Certification Program with testing performed by independent test labs.
Testability	The extent to which an objective and feasible test can be designed to determine whether a requirement is met. Source: ISO/IEC/IEEE 24765:2017	The Certification Working Group is writing test purposes and test cases for each requirement defined in the O-PAS Standard.
Traceability	The degree to which a relationship can be established between two or more products of the development process. The discernible association among two or more logical entities, such as requirements, system elements, verifications, or tasks. Source: ISO/IEC/IEEE 24765:2017	Polarion® is used to trace user stories, use-cases, requirements, conformance requirements, test purposes, and test cases.
Usability	The ease with which a specified user can learn to operate, prepare inputs for, and interpret outputs of a system or component. Source: ISO/IEC/IEEE 24765:2017	Use of standard control technologies simplifies the task of configuring a control system. Use of networking standards that are consistent across the plant reduces training efforts. Consistent representation of function block data enhances operator understanding of the plant.

1.2.2 Interfaces

Section 1.2.1 lists four key quality attributes: interchangeability, interoperability, portability, and modularity. The O-PAS Standard defines the interfaces critical to achieving those quality attributes.

An interface is a boundary where systems or components meet and act on or communicate with each other. The interactors can be between software, computer hardware, peripheral devices, humans, or combinations of these.

The key principle enabling interchangeability is to separate the interface from the implementation. The interaction between two or more components is specified by the O-PAS Standard. The functionality required by the interface is defined. But how each component provides the functionality required by the interface is not defined – that is left up to the designer.

The O-PAS Standard can specify several types of interface, as described below.

Software Interface

(In the following descriptions, upper-case letters represent software components.)

• Subroutine-call interface:

—  A calls an entry point in B

—  A and B exchange data representing information and/or directions for processing

—  A proceeds from the point just after its call to B

This is commonly termed an Application Program Interface (API). An API specifies the “signature” for the function, process, or method being called. The signature includes such information as the entry-point name, scope, inputs, outputs (including any return value), and any exceptions thrown.

• File interface:

—  M writes a file

—  N reads the file and may update it

• Network (aka Stream/Message/Wireline) interface:

—  X and Y interact by passing data back and forth over a communication channel

Physical Interface

• A device’s physical port or connection, linking to a physical communication channel
• Specification for the space in which a physical device is to be installed: size/shape/weight/power/voltage/etc.

Note: The O-PAS Standard also makes frequent reference to the Human-Machine Interface (HMI), which is the user interface or dashboard that is presented to the operator, engineer, or technician. But because it is not an interface between system components, specifying the HMI in detail is not in the scope of the O-PAS Standard.

1.3 Conformance

Part 1 of the O-PAS Standard is informative, and no conformance requirements are defined in this part. Normative requirements and conformance criteria are defined in the other parts of the O-PAS Standard.

In the O-PAS Standard, a Component is a defined part (either a hardware part or a software part) of a process automation system. A Conformant Component is a Component that meets all the stated conformance requirements for a component of its type.

Part 1 is intended to provide a general overview of a system that contains O-PAS conformant components and to describe the general functionality of the interfaces between them. The interface specifications are detailed in the other parts of the O-PAS Standard.

1.4 Normative References

Part 1 of the O-PAS Standard is informative, so there are no normative references.

1.5 Terminology

Part 1 of the O-PAS Standard is informative, so this section is not applicable.

1.6 Future Directions (Informative)

A future version of the O-PAS Standard will address additional functionality. Many expected revisions are indicated in individual parts in their respective Future Directions (Informative) sections. As the individual parts evolve, Part 1 will be revised accordingly.

As technology evolves, determinism and functionality are expected to improve, and the O-PAS Standard will embrace those improvements.

Improvement of the OPC UA standard with introduction of User Datagram Protocol (UDP)-based PubSub will improve communication efficiency. Introduction of IEEE 802.1 Time-Sensitive Networking (TSN) will improve timing of UDP communication. As a result, O-PAS communication will improve determinism and quality of service.

The use of the Automation Markup Language (aka Automation ML, AML) for sharing of information among engineering tools is introduced in O-PAS Part 6 and will be elaborated in a future version of the O-PAS Standard.

Other future directions include system orchestration (e.g., TOSCA[1] for OT); improved real-time quality of service management (TSN); system management (Redfish) enhancements; and application portability interface standardization as it relates to application workloads that are native, virtualized, or containerized. The increased standardization of runtimes, security evolution beyond SL2, O-PAS function block interfaces, and physical platform interface evolution are expected to further drive industry transformation.

For the purposes of the O-PAS Standard, the following terms and definitions apply. Merriam-Webster’s Collegiate Dictionary should be referenced for terms not defined in this chapter. The OPAF Glossary and Abbreviations should be referenced for additional terms not defined in this chapter.

2.1 OPAF Glossary and Abbreviations

For the OPAF Glossary and Abbreviations, see the definitions at: www.opengroup.org/open-process-automation-forum/glossary.

2.2 Terms Specific to Part 1

The following definitions are specific to O-PAS Part 1 (and therefore differ from the definitions contained in the OPAF Glossary referenced in Section 2.1).

Term	Definition
Distributed Control Node (DCN)	A connected, secure, and managed device that exchanges data via the O-PAS Connectivity Framework (OCF) network and may perform plant-specific application functions and/or attach to field devices for measurement and control.

Figure 1 is a concept diagram that illustrates a process automation system that is a collection of O-PAS conformant components. A conformant component is any hardware or software that is conformant to a profile defined in the O-PAS Standard. The primary conformant components described are Distributed Control Nodes (DCNs) connected via the O-PAS Connectivity Framework (OCF). The OCF is a data networking framework that provides a logical data exchange service to the endpoints participating in an information exchange using OPC UA transport mechanisms and an O-PAS information model.

Using OPC UA, the OCF provides information representation and transport mechanisms for determinism and quality of service as required for data exchanges to support distributed control logic execution. (For an introduction to OPC UA, please see the Introduction to the OPC UA appendix in O-PAS Part 4.) An O-PAS system is a collection of O-PAS conformant components exchanging information using the OCF.

A DCN consists of OCF connectivity and an information model, O-PAS system management interfaces, and optionally a physical platform, applications, field I/O, and other capabilities. A virtual DCN is one running on a virtualized physical platform.

An application is a set of one or more programs, supported by required data and customized by configuration information, performing a group of related functions. Connectivity to non-conformant O-PAS devices is provided through DCNs performing gateway functions to make the non-conformant O-PAS device’s information accessible through the OCF.

Each component in the system may execute all or part of the overall control and operations strategies, based on the capabilities and capacities of the component.

Figure 1: Concept Diagram of a Process Automation System of O-PAS Conformant Components

3.1 O-PAS Connectivity Framework (OCF)

The O-PAS Connectivity Framework (OCF) is a secure and interoperable communication framework, defined in O-PAS Part 4.

While the OCF is shown as a single network in Figure 1, actual implementations may consist of segmented networks, VLANs, firewalls, and other mechanisms to ensure security, performance, and quality of service.

3.2 Control Nodes

3.2.1 Distributed Control Node (DCN)

A Distributed Control Node (DCN) is a secure and manageable device that exchanges data via the OCF network and may perform plant-specific application functions and/or attach to field devices for measurement and control. There are two aspects to a DCN that are discussed in the O-PAS Standard:

1. The network view of the device – the DCN term is used to mean any device that implements the network interfaces required of a DCN. This might be rack-mounted general-purpose computers – Advanced Computing Platforms (ACPs) – or DIN[2] rail-mountable industrial controllers or proprietary equipment that expose data in an O-PAS conformant way. In this definition, if a device implements the network interfaces such as the O-PAS Connectivity Framework of Part 4, the O-PAS Information and Exchange Models of Part 6, and the O-PAS System Management Interface defined in Part 5, it is considered a DCN.
2. The physical characteristics of the device – when discussing physical platforms, a DCN is a small rugged device that can be mounted in the field and perform some autonomous control locally. In this case, contrast with ACP, analyzer, and other types of equipment which are sometimes considered “DCN” according to aspect #1 immediately above. Physical platforms are discussed in O-PAS Part 7.

DCNs come in many shapes and sizes, some vendor-specific and some (in the future) conformant with the O-PAS Standard. Regardless of physical form factor, DCNs have some common attributes:

• OCF connectivity and information model
• O-PAS System Management Interfaces
• Basic physical properties (Ethernet, secure boot, …)
• Network capabilities including time synchronization
• Security features supporting conformance to ANSI/ISA-62443-4-2 SL2

DCN types include the following, possibly overlapping types:

• DCNs with physical I/O

Process measurements from the field and commands to actuators in the field are exchanged in O-PAS information models (aka signals). The I/O subsystem may conform to future O-PAS physical standards and future configuration and pass-through information models, or it may be vendor-specific.

• DCNs with end user-programmable control

These may have function block execution engines, alarm execution engines, historians, or other applications which exchange data over the OCF.

• DCNs with control and I/O (includes both of the above)

• Virtual DCNs which execute DCN functionality within a computing environment

• Gateways

A DCN that provides OCF interoperability to a software component, device, or system that lacks it. For example, a DCN acting as a gateway may be connected to a legacy DCS, legacy Programmable Logic Controller (PLC), smart device, DeviceNet device, FOUNDATION™ Fieldbus device, or a network of such devices.

The OCF side of a gateway presents information using O-PAS information models, but the configuration of the gateway operation is vendor and/or protocol-specific. How the information is converted to or from the OCF is not in scope for the O-PAS Standard.

Equipment, such as DCSs, PLCs, analyzers, etc., containing an OCF Communication Interface (OCI) can participate in O-PAS information exchange. They are visible through the OCF and exchange O-PAS signals with other nodes on the OCF.

Each DCN can be configured based on the role it performs in the overall automation and operations strategies. This allows replacement of a DCN to be a simple maintenance action.

3.2.2 Advanced Computing Platform (ACP)

An ACP is a computing platform providing the determinism, low latency, and reliability needed to handle applications or services that require more resources than are typically available on a DCN.

Applications hosted on an ACP exchange data with other O-PAS applications via their OCI.

ACPs may also be used for applications which cannot be easily or efficiently distributed; for example, due to compute requirements and limited capacity of DCNs or intolerance of node-to-node communication delays.

ACPs may provide abstractions such as VMs in which DCN functions are performed.

The O-PAS Standard does not preclude software components that do not conform to O-PAS portability standards, but no claims of portability or platform independence are made regarding such additional components.

3.3 Application Types

An application is a set of one or more programs, supported by required data and customized by configuration information, performing a group of related functions. Its three parts can be represented graphically as illustrated in Figure 2.

Figure 2: Parts of an Application

The three contained boxes are:

• Configuration: the parameters and initial settings for the program
• Program: the instructions to be executed
• Data: bytes on which the program code operates – designated parts may persist between executions

There are different types of applications defined in this document using a “FILO” model of describing layers of software, as shown in Figure 3.

The FILO model is used to uniquely define the meaning of the term “application” that can have different meanings to different users. An application is a combination of configuration information, a program, and data used by the program. The labels “F”, “I”, “L”, and “O” are in alphabetic order, reflecting their relative order in the layered FILO model of applications.[3]

Figure 3: FILO Model of Applications

Layer-F applications include those that are defined via the O-PAS configuration specifications defined in the sub-parts of O-PAS Part 6. These include function blocks, alarm applications, IEC 61131-3 programs, and IEC 61499-1 applications. This also includes the basic configuration information defined in O-PAS Part 6.2. The Layer-F applications may also include function block libraries that can be used in the construction of Layer-F applications or to build additional Layer-F libraries. Layer-F function block applications using IEC 61131-3 and IEC 61499-1 are defined in O-PAS Part 6 and other application types such as Python^® or Java^® interpreted programs will be considered in a future version of the O-PAS Standard. Note that interaction of a Layer-F application with other Layer-F applications in a standard way (i.e., via OCF) is independent of its interaction with its execution environment in Layer I and the two aspects are defined as separate conformance profiles. A Layer-F application may conform to the OCF interface (providing interoperability) yet use a vendor-specific Layer I (thus not providing portability).

Layer-I applications are typically defined in an IT programming language (such as C#, C++, Go, Ada, etc.). Layer I provides the interfaces needed to execute the Layer-F applications and operate on the Layer-F configuration information. A future version of the O-PAS Standard will include interface definitions to support platform-independent Layer-I applications.

Layer-L applications are typically libraries or service programs that are defined in a typical IT language (such as C#, C++, Go, Ada, etc.) which provide services to the Layer-I applications. Layer-L applications are generally platform-dependent, in that they have been compiled into a binary format for a specific CPU architecture and Operating System (OS).

Layer-O applications are typically parts of the underlying OS that provides the environment for the Layer-L and Layer-I applications. In the O-PAS Technical Architecture this is identified as the platform OS, or an OS running above a hypervisor/separation kernel.

3.4 Equipment Using the O-PAS Communication Interface (OCI)

A wide variety of automation equipment can be integrated into an O-PAS system by implementing the O-PAS Communication Interface (OCI) functionality on each device. Such equipment provides the capability of participating in OCF communication with other O-PAS Nodes, and is visible through the OCF. Examples of such equipment might include PCs, field instruments, DCSs, PLCs, analyzers, safety systems, and electrical systems.

Different aspects of the OCF interface are defined in different places in the O-PAS Standard. To learn more about the OCF, see:

1. The interfaces defined in O-PAS Part 2
2. The services defined in O-PAS Part 4
3. The System Management Interface defined in O-PAS Part 5
4. The Configuration Management Interface defined in O-PAS Part 6.1
5. The basic configuration information defined in O-PAS Part 6.2

3.5 Business Function Connectivity

A system built with O-PAS conformant components may contain connectivity to business functions (such as Enterprise Resource Planning (ERP), Material Resource Planning (MRP), Product Lifecycle Management (PLM), Supply Chain Management (SCM), and other business systems running in IT data centers).

The connection between the OCF and business networks is shown in Figure 1 connected through a firewall as an example, following the recommended best practice as documented in the ANSI/ISA 62443 standards.

3.6 Internal and External OT Data Centers

A system built with O-PAS conformant components may support communication to internal and external Operations Technology (OT) data centers to support applications running IEC 62264 Level 2 and Level 3 functions. In addition, OT data centers may execute functions not defined in the O-PAS Standard, such as offline engineering tools, simulation tools, and management tools.

Connection to OT data centers is shown in Figure 1 controlled by a firewall between the OCF and the external OT data center as an example, following the recommended best practice as documented in the ANSI/ISA 62443 standards. However, applications running in OT data centers may participate directly in OCF communication, if allowed by local security rules.

4.1 Components and Interfaces

The Technical Architecture as fully envisioned identifies the principal components (boxes) and associated interfaces (arrows and file symbols) of an O-PAS conformant system and is illustrated in Figure 4.

• The import/export formats for the Layer-F applications are specified in the sub-parts of O-PAS Part 6
• The download/upload formats for the Layer-F applications and configurations are specified in the sub-parts of O-PAS Part 6
• The dark blue interfaces to the components are specified in O-PAS Part 4, O-PAS Part 5, the sub-parts of O-PAS Part 6, and O-PAS Part 7
• The red interfaces and the nesting and relationships between elements in the DCN box are planned for a future version of the O-PAS Standard, as further defined in Chapter 7
• The general functionality and examples of the components depicted as the gray boxes with white letters are described by the O-PAS Technical Architecture, but the implementation of the functionality is not defined

Figure 4: Principal Components and Interfaces

4.2 O-PAS Interfaces

Figure 5 expands on Figure 4 by showing specific interfaces between O-PAS conformant components, management services, and the networking infrastructure.

Notes

The “ball and cup” symbols are UML^® symbols used to indicate interfaces between objects or systems. The “ball” is connected to the object or system implementing the interface. The “cup” is connected to the object or system consuming the interface.

The tags interfaces shown in Figure 5 have the following meanings:

• Interfaces with solid lines indicate software interfaces
• Interfaces with dashed lines and solid black circles indicate physical interfaces
• Network interfaces provided using OCF functionality are indicated with a “+”

Figure 5: O-PAS Defined Interfaces

Some of the key interfaces to be defined in the O-PAS architecture are as follows:

• Information in the Layer-F application import/export format defines the configuration of a system of DCNs and applications that are created and maintained by external management services or tools, such as Layer-F application editing tools, configuration management services, application management services, and system management services
• The Configuration Management Interface defines the configuration management services used to manage the download and upload of configuration information in an O-PAS conformant component by configuration management services (Part 6.1)
• The Application Management Interface defines the application management services used to manage applications in an O-PAS conformant component by application management services (Part 6.1)
• The Connectivity Framework Interface defines the network protocols necessary for DCNs to communicate across the OCF
• The System Management Interface defines the system management services and information models used to manage the hardware and associated OS software in an O-PAS conformant component by system management tools
• The Platform Networking Physical Interface defines the physical layer interface to the network

4.2.1 Layer-F Import/Export and Download/Upload Formats

The Layer-F formats define the common information that is used to configure O-PAS conformant components.

• The purpose of the import/export Layer-F format is to allow DCN configuration to be portable across different vendor implementations
• The purpose of the download/upload format is to provide a common mechanism for deploying the configuration to DCNs from different vendors

The basic configuration defines configuration information for each DCN; for example, signal names, signal types, alarm and condition information, DCN roles, and Layer-F applications.

The Layer-F import/export format is often organized by physical processing equipment asset (such as areas, process units, process cells, equipment modules, control modules, etc.) using hierarchies defined in IEC 61512-1 (ISA 88), IEC 62264 (ISA 95) and ISA-TR106, and by OCF network hierarchies.

The Layer-F import/export format also includes the specification of the platform and conformant component execution environments, such as:

• The information that characterizes capability and capacity requirements of applications, such as required support for the application services, timing requirements for cyclic programs, and required available memory
• The information that defines the capabilities and capacities of conformant components
• The information that defines the capabilities and capacities of platforms
• The information that defines the capabilities and capacities of the OCF, organized by network segment if appropriate
• Vendor-specific download information or an O-PAS conformant component, such as binary files or encoded configuration information

The information defined in Layer-F download/upload formats is generated by a vendor’s Layer-F application editing tool ①.

The download information in the Layer-F import/export files would be used by a configuration management service to select what to download to each component ②. The information is downloaded using the Configuration Management Interface ③. The downloaded information is used to fill in the local storage that is exposed using an OCF information model ④. The run-time information is then made available using the OCF access methods ⑤, as illustrated in the example in Figure 6.

Figure 6: Example of Configuration Information and OCF Access

4.2.2 Configuration Management Interface

A system composed of O-PAS conformant components may contain thousands of configurable conformant components from multiple vendors. Managing component configurations download/upload in this multi-vendor environment requires common configuration management capabilities.

The Configuration Management Interface is used to download configuration information to a conformant component and to upload the configuration information from a conformant component. The upload could be used for purposes such as performing backups or comparisons of actual versus expected configurations.

4.2.3 Application Management Interface

A system composed of O-PAS conformant components may contain hundreds of distributed Layer-F applications executing in multiple vendor environments. Managing application startup, shutdown, and other application controls, this multi-vendor environment requires common application management capabilities.

The Application Management Interface is used to control the execution of Layer-F applications.

4.2.4 Connectivity Framework Interface

To meet the requirement for real-time DCN communication in a system of components from multiple vendors, the Connectivity Framework Interface is defined in O-PAS Part 4.

4.2.5 System Management Interface

A system composed of O-PAS conformant components may contain thousands of components from multiple vendors. Managing platform configurations, and providing platform maintenance support, in this highly distributed environment requires common system management functionality to be specified.

To meet the requirement to manage a system of components from multiple vendors, the System Management Interface is defined in O-PAS Part 5.

The O-PAS Connectivity Framework (OCF) defines the framework services, using the Industrial Internet Consortium, Industrial Internet Connectivity Stack Model, as described in The Industrial Internet of Things Volume G5: Connectivity Framework. The OCF provides the transport services for messages, the services for data consisting of streams, events, and state information, and the information needed for distributed real-time control.

The OCF interfaces are defined in O-PAS Part 4, and extended in the sub-parts of Part 6.

One of the main purposes of the OCF is to define the services for handling the information flows between applications. Any Layer-F application that exposes information to or reads information from other applications does so through the Connectivity Framework Software Interface, even if the corresponding applications are running in the same DCN.

Figure 7 illustrates the communications route, through the different parts of an O-PAS conformant system, when the accessed field data is on the local DCN.

Figure 7: Local Data Access Route

Figure 8 illustrates the communication route, through the different parts of an O-PAS conformant system, when the field data is not on the local DCN. Components in the DCN (or other conformant component) provide the services and contain the information to determine the location of the data.

Figure 8: Network Data Access Route

Figure 9 illustrates how physical signals are handled through their transformation into Layer-F application programs, and out of application programs to physical outputs. It illustrates the final expected set of O-PAS Standards:

• An O-PAS defined physical interface between termination assemblies and I/O conversion elements performing analog to digital conversion (yellow lines)
• An O-PAS defined interface between the I/O conversion and computing elements (green lines)
• An O-PAS OCF defined interface (blue lines)
• An O-PAS defined interface between Layer-F application blocks (purple lines)
• Vendor-defined interfaces that interface the OCF exchanged signals into and out of service function blocks (OCF_IN and OCF_OUT)

Figure 9: Physical Components, Signals, and Software Components

Figure 10 illustrates the same data flows and standards but with different options for the physical platform. The right side illustrates a combined Physical Platform (PP), from a single vendor, in which the termination block to I/O element and I/O element to compute element are vendor-specific and not exposed. The right side shows an example of a combined compute element and I/O element with a vendor-specific internal interface, but with an O-PAS Standard interface to the termination assembly.

Figure 10: Alternative Physical Platform Options

A system composed of O-PAS conformant components may be made up of thousands of DCNs from multiple vendors. Managing security in the highly distributed O-PAS environment requires security to be specified in all components of the Technical Architecture: DCNs, platform-independent applications, Layer-I applications, Layer-L services, OSs, network devices (switches, routers, etc.). See O-PAS Part 2 for additional information, including some security requirements. Specific requirements for security functionality are included in O-PAS Part 4 and O-PAS Part 5.

O-PAS conformant components will enable the development of secure systems, but no O-PAS interface standard can guarantee comprehensive security. It is the responsibility of the system owners to develop the continuous process of assessment of security threats, implementation of countermeasures, validation of the countermeasures, and correction of the system to prevent or reduce the impact of the risk. (See ANSI/ISA-62443-1-1 for information about Industrial Automation Control Systems security.)

To build secure platform-independent applications the Security Management Interface and the Security Services Interface are planned to be defined in a future version of the O-PAS Standard.

The platform-independent application interface specifications for Layer I, Layer L, and Layer O are planned for a future version of the O-PAS Standard. The interfaces identified here are included to illustrate the eventual platform-independent applications and interchangeability capabilities of a system built from O-PAS conformant components. The interfaces shown in Figure 11 in black text are in Version 2.1, and the interfaces in gray text are planned for a future version to support platform-independent Layer-I and Layer-L applications. Figure 11 is an extension to Figure 5.

Figure 11: Layer-F, Layer-I, and Layer-L Application Interfaces

The platform-independent application interfaces will define the APIs that are available to applications. The purpose of the interfaces is to allow applications to be platform-independent, commonly configured, and commonly managed.

It is planned for the platform-independent application interfaces to be a set of abstract service definitions which can be implemented in different languages. This allows the system to evolve as additional computer languages and APIs are developed. The services will contain the minimum set of services required to run an O-PAS conformant application as well as other expected applications.

The platform-independent application interfaces will specify the complete interface between platform-independent application software and the underlying platform and libraries. The interface definitions will include the syntax and semantics of the programmatic interface and all necessary protocol and data structure definitions.

The seven additional planned interfaces for platform-independent applications are illustrated in Figure 12. Applications may also be consumers of services from proprietary systems; however, using these services would prevent platform independence if the proprietary services are not available on the target platforms.

Figure 12: Future Possible Application Interfaces

Figure 13 illustrates all of the Version 2.1 and planned future software interfaces to be defined in the O-PAS Standard:

• Layer-F import/export formats define the interfaces to external tools used to create and manage applications and configurations
• Layer-F download/upload methods define the interfaces to DCNs and OCIs used to manage O-PAS conformant components
• Layer-F download/upload formats define the standard data used in DCNs and OCIs to configure O-PAS conformant components
• Layer-F applications will usually be run by a Layer-I application
• Layer-I applications are consumers of Layer-L applications and services and associated data
• Layer-I applications may also be consumers of services and data from proprietary systems
• Layer-L applications and services are providers of services and associated data to Layer-I and Layer-F applications and external management tools
• Layer-L applications and services are consumers of services and associated data from the Layer-O applications and services and from external management tools
• Layer-L applications and services may also be consumers of other services and data as needed
• Layer-O applications and services are providers of services and associated data
• Layer-O applications and services are consumers of services and associated data from the physical infrastructure and external management tools
• Layer-O applications and services may also be consumers of services and data from proprietary systems

Figure 13: O-PAS Version 2.1 and Planned Interfaces

Planned interfaces for a future version of the O-PAS Standard include:

• Security Management Interface
• Security Services Interface
• Connectivity Framework Software Interface
• Application Services Interface
• Configuration Information Interface
• Platform Services Interface
• Platform I/O Physical Interface

7.1 Security Management Interface

The Security Management Interface is a network interface that defines services and information models used to manage security in an O-PAS conformant component by security management services.

The services to be provided by the Security Management Interface are planned to be defined in a future version of the O-PAS Standard.

7.2 Security Services Interface

The Security Services Interface is a software interface that provides security management available to Layer-I applications, Layer-L applications/services, or Layer-O applications/services that manage their security, including system security services provided by the underlying platform.

The services to be provided by the Security Services Interface are planned to be defined in a future version of the O-PAS Standard.

7.3 Connectivity Framework Software Interface

The Connectivity Framework Software Interface is a software interface that defines the services and information models used by Layer-I, Layer-L, and Layer-O applications to communicate using the OCF.

The services to be provided by the Connectivity Framework Software Interface are planned to be defined in a future version of the O-PAS Standard.

7.4 Application Services Interface

The Application Services Interface is a software interface that defines the services and information models used by applications to access Layer-L services, including system services provided by the underlying Layer-O application/services, and also exposes the application status information.

The services to be provided by the Application Services Interface are planned to be defined in a future version of the O-PAS Standard.

7.5 Configuration Information Interface

The Configuration Information Interface is a software interface that specifies the services and information models for Layer-I applications to make the configuration information available to Layer-I applications or Layer-L applications/services, and also exposes the application configuration information used by the application.

The services to be provided by the Configuration Information Interface are planned to be defined in a future version of the O-PAS Standard.

Figure 14 illustrates a possible use of the configuration interfaces, with an internal data store that is used to hold the configuration information, making it available to both configuration management tools and to applications.

Figure 14: Example of Configuration Information Flows

7.6 Platform Services Interface

The Platform Services Interface is a software interface that provides access to the underlying OS services, allowing applications to be written independently from the platform hardware and software. The interface is planned to cover services such as memory management, thread management, task and program control, persistent storage management, connection to the platform I/O, and connection to the physical network hardware.

The services to be provided by the Platform Services Interface are planned to be defined in a future version of the O-PAS Standard.

7.7 Platform I/O Physical Interface

The Platform I/O Physical Interface is a specification of the hardware interface to connect physical I/O signals to O-PAS devices. Facets of the specification will include:

• Physical frame or backplane
• Size, Weight, and Power (SWaP) heat duty of components in the frame or backplane (e.g., compute, I/O, power supply modules)
• Power and network connections
• I/O termination standards, such that a standard removable Terminal Assembly (TA) will be usable with any O-PAS conformant I/O module (e.g., how a 4-20 mA HART^® device attaches)
• Backplane connectors, signal levels
• Backplane protocol and message contents
• HART passthrough protocol to enable configuration, digitalization, and analytics
• Standard types of I/O; e.g., 4-20 mA input with HART, 4-20 mA output with HART, 24VDC discrete input and output, RTD, thermocouple, frequency/counter

The specification of the Platform I/O Physical Interface is planned to be defined in a future version of the O-PAS Standard.

The purpose of the Platform I/O Physical Interface is to support interchangeability of components, such as I/O processing components, compute components, and I/O termination components.

Platform profiles are used to identify different types of physical infrastructure, from fixed-size, weight, and power modules that can fit into an O-PAS framework or backplane, to general-purpose PCs and servers with standard Ethernet connections.

7.8 Typical Layer-L Application and Service Functions

Some typical functions that could be performed by a Layer-L application or service may include:

• OCF data provider functions
• OCF data consumer functions
• OCF data publisher functions
• OCF data subscriber functions
• Access to standard configuration information
• Mapping local name space to physical name space
• Application management for platform-independent applications and DCF services
• License management services
• Backup and recovery services
• Location-independent tag/data services
• Access to platform services

Layer-L services may be platform-dependent or may be platform-independent, depending on the profile followed.

7.9 Platform-Dependent Applications

Applications are not required to be platform-independent, and may be dependent on a specific environment. Platform-dependent applications are outside the scope of the O-PAS Standard, and may use native platform services, native OS services, services defined in the Application Services Interface, services defined in the Configuration Information Interface, or services defined in the OCI.

Examples of platform-dependent applications include:

• Interface to a dedicated device (such as a chromatograph, boiler control, valve array, spectrometer, blender, etc.)
• Gateway to a non-OCF network
• A program (such as applications written in Ada, Pascal, C++, Perl, Python, Visual Basic, etc.) with a proprietary program download and control interface

This appendix is informative and defines various example system structures that could be built using O-PAS components. The list is not meant to be all-inclusive, and is only intended to illustrate the range of possible structures that can be supported. The figures do not show the external management tools that would be used to configure and support the system.

A.1 Small Systems

This section defines envisioned small system structures, ranging from a few I/O points to more I/O and connectivity, to legacy PLCs, DCSs, and field networks.

A.1.1     DCN Only

This is an example of a DCN-only system where the computing capacity of the DCNs is sufficient for the project. Figure 15 illustrates the simple DCN system, where DCNs with I/O provide the capacity to run the required applications. The profiles for the DCNs are not shown, but the assumption is that some DCN profiles are sufficient to run applications.

Figure 15: DCN-Only Configuration

A.1.2     DCNs and Legacy PLC

This is an example of a system with DCNs and a legacy PLC. Figure 16 illustrates this structure, where DCNs with I/O provide the capacity to run the required applications and a DCN acts as a gateway to a legacy PLC to make its information available to the OCF. The profiles for the DCNs are not shown, but the assumption is that some of the DCN profiles are sufficient to run standard or custom applications.

Figure 16: DCN and Legacy PLC

A.1.3     DCNs and PLC with OCI

This is an example of a system with DCNs, legacy PLC, and a PLC with an embedded OCI. Figure 17 illustrates this system structure, where DCNs with I/O provide the capacity to run the required applications, a DCN acts as a gateway to a legacy PLC to make its information available to the OCF, and a PLC with an embedded OCI makes its information available to the OCF and provides OCF information to the PLC. The profiles for the DCNs are not shown, but the assumption is that some of the DCN profiles are sufficient to run standard or custom applications.

Figure 17: DCN and PLC with Embedded OCI

A.1.4     DCN with Legacy DCS and Field Networks

In a DCN with legacy DCS and field networks system structure, the computing capacity of the DCNs is sufficient for the project. Figure 18 illustrates this system structure, where DCNs with I/O provide the capacity to run the required applications, a DCN acts as a gateway to a legacy DCS to make its information available to and from the OCF, and a DCN acts as a gateway to field networks to make their information available to and from the OCF. The profiles for the DCNs are not shown, but the assumption is that some of the DCN profiles are sufficient to run standard or custom applications.

Figure 18: DCN and Legacy DCS and Field Networks

A.2 Medium and Large Size Systems

A.2.1     Medium Size Brownfield Example

In this example an existing system (the brownfield) is extended with additional capability by the addition of O-PAS conformant components. In the example in Figure 19, additional I/O is added to DCNs, DCNs act as gateways to PLCs, machinery monitoring, and safety system information, and an ACP is added to run Layer-F and Layer-I applications that may be too large to run in the gateways or I/O DCNs. The existing DCS is shown as having an embedded OCI so that selected information is available through the OCF.

Figure 19: Medium Size Brownfield Example

A.2.2     Medium Size Greenfield Example

In this example a new system is being built using O-PAS conformant components. In the example in Figure 20, DCNs with and without I/O provide computing capability, other devices (such as analyzers, machinery monitoring, field networks, safety systems, and electrical systems) all have embedded OCI functionality and the ability to run applications, and an ACP is added to run applications that may be too large to run in the gateways or I/O DCNs.

Figure 20: Medium Size Greenfield Example

A.2.3     Large Greenfield Example

In this example a new large system is being built using O-PAS conformant components. In the example in Figure 21, DCNs with and without I/O provide computing capability, other devices (such as analyzers, machinery monitoring, field networks, safety systems, and electrical systems) all have embedded PP functionality, and an ACP is added to run applications that may be too large to run in the gateways or I/O DCNs. Additional connections are shown to enterprise data centers for connectivity to business-level functions, through applications in a DCN. Additionally, an external data center is shown, which has the capability of DCNs to run tasks such as engineering services and simulations.

Figure 21: Large Size Greenfield Example

A.3 Integrated Device Example

This is an example of an integrated device that can participate in the OCF by making its local information available and by accepting the basic OCI configuration but does not have the capability of executing Layer-F applications or platform-independent applications.

Examples of basic OCI configuration include:

• Data location/data name (signal)/data type and alarm information
• DCN capability configuration information
• OCF network configuration information
• System management information
• Security and access rights information

Essentially this could be an I/O termination node, a data storage node, or a DCN with embedded functionality that does not include the capability for running Layer-F applications. Figure 22 illustrates an integrated platform-dependent O-PAS conformant component. It would be able to send and receive information (configuration definitions, service requests, service responses, etc.), support system management functions, and support the minimum application management functions for an embedded internal application.

Figure 22: Integrated Device

A.4 Integrated Device Example with Layer-F Application Support

An integrated device that can participate in the OCF by:

• Making its local information available
• Accepting information in the Layer-F application/configuration format
• Providing the capability to execute Layer-F applications (for example, function blocks)

This example also has the capability of executing platform-dependent applications, but does not have the capability of supporting platform-independent applications.

Essentially this is a DCN with fixed control code execution capability, such as a dedicated function block controller, or a device that has the capability to run downloaded Layer-F applications. This concept is illustrated in Figure 23, where the configuration information includes a function block program, and a platform-dependent application provides a function block execution environment.

Figure 23: Integrated Device with Layer-F Application Support

This appendix is informative. For the purposes of the O-PAS Standard, an application is considered a program and associated configuration information and data. The term “application” has different meaning for the different roles of the O-PAS Standard. Often, what is an application to one role (e.g., system integrator) is viewed as just configuration or data by another role (e.g., software supplier).

For example, a system integrator would define a function block application using the IEC 61131-3 Structured Text (ST) language and associated configuration information. The supplier of the function block 61131–3 program execution application would consider the system integrator information just configuration and data that the Layer-I function block execution application uses.

Figure 24 illustrates an example of the layers of applications and programs using the example above. The top level is intrinsically portable, because there is no recompilation required to execute companion specification applications on different DCNs. The middle layers could be portable if they only use the services of the lower levels, but may require recompilation based on the physical platform profile.

Figure 24: Example of Application Layers

Figure 25 illustrates application layering, using a typical IT set of tools. In this example the top level is a Java program, represented as Java Byte Code and associated configuration and data. In the next level down, a Java Virtual Machine (JVM) executes the Java Byte Code, using Layer-L services. The Layer-L services components use the services of the underlying platform implemented as a UNIX^® OS provided by the platform supplier.

Figure 25: Application Layering Using Java Example

Figure 26 illustrates multiple different examples of deployment environments for applications. These range from bare metal applications and libraries to containers in virtual servers. The environments have been annotated with the FILO model terminology to illustrate the layers of applications and services that exist in many different deployments. The figure is derived from information provided by the Industrial Internet Security Forum (IIC).

Figure 26: Example Deployment Environments for Applications

For the OPAF Glossary and Abbreviations, see the definitions at: www.opengroup.org/open-process-automation-forum/glossary.

[1] TOSCA stands for: Topology and Orchestration Specification for Cloud Applications.

[2] A DIN rail is a metal rail of a standard type widely used for mounting industrial control equipment in equipment racks, as described in IEC 60715.

[3] FILO is not intended to be a word or acronym; however, the word “filo” is used because it is also a type of layered pastry dough and reinforces the layered model of applications and services.