The Open Group Standard

O-PAS™ Standard, Version 2.1

Part 4 – O-PAS Connectivity Framework (OCF)

Copyright © 2023-2024, 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. Specifically, without such written permission, the use or incorporation of this publication, in whole or in part, is NOT PERMITTED for the purposes of training or developing large language models (LLMs) or any other generative artificial intelligence systems, or otherwise for the purposes of using, or in connection with the use of, such technologies, tools, or models to generate any data or content and/or to synthesize or combine with any other data or content.

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 4 – O-PAS Connectivity Framework (OCF)

ISBN: 1-957866-10-9

Document Number: C230-4

 

Published by The Open Group, February 2023.

This document is updated to apply Technical Corrigendum U242, and re-issued August 2024.

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 and open source initiatives by fostering a culture of collaboration, inclusivity, and mutual respect among our diverse group of 900+ memberships. Our membership includes customers, systems and solutions suppliers, tool vendors, integrators, academics, and consultants across multiple industries.

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 4 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)
• O-PAS Part 2 – Security
• O-PAS Part 3 – Profiles (Informative)
• O-PAS Part 4 – O-PAS Connectivity Framework (OCF) (this document)
• 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.

See also Appendix C.

Trademarks

ArchiMate, FACE, FACE logo, Future Airborne Capability Environment, Making Standards Work, Open Footprint, Open O logo, Open O and Check certification logo, OSDU, The Open Group, TOGAF, UNIX, UNIXWARE, and 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, FHIM Profile Builder, FHIM logo, FPB, IT4IT, IT4IT logo, O-AA, O-DA, O-DEF, O-HERA, O-PAS, O-TTPS, Open Agile Architecture, Open FAIR, Open Process Automation, Open Subsurface Data Universe, Open Trusted Technology Provider, Sensor Integration Simplified, Sensor Open Systems Architecture, SOSA, and 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.)

Lead Contributors

• Amine Mohamed Houyou – Siemens Industry, Inc.
• Paul Hunkar – Yokogawa Electric Corporation
• Ram Kuruganty – Siemens (Subcommittee Lead)
• James Luth – Schneider Electric (Subcommittee Lead)
• Vien Nguyen – Yokogawa Electric Corporation

Additional Contributors

• Abdullah Alkhalifah – Aramco Services Company
• Donald Bartusiak – Collaborative Systems Integration, LLC
• Steve Bitar – ExxonMobil Corporation
• Dennis Brandl – BR&L Consulting, Inc.
• Stan Brubaker – Beeond
• Mark Bush – Avistar Consulting
• Monte Cadle – Azbil Corporation
• Mark Carrier – Real-Time Innovations, Inc.
• Don Clark – Schneider Electric
• Patrick Den Haese – Schneider Electric
• David Emerson – Yokogawa Electric Corporation
• Camilo Gomez – Yokogawa Electric Corporation
• Maris Graube – Relcom
• Craig Griffin – Wind River Systems, Inc.
• Kirk Hansen – Enterprise Transformation Partners
• Jeff Harding – ABB AG
• Alexander Johnson – Schneider Electric
• Firas Khalil – Siemens Industry, Inc.
• John Leung – Intel Corporation
• Mathias Maurmaier – Siemens Industry, Inc.
• John McBride – ExxonMobil Corporation
• Harirajan Padmanabhan – hpad, Inc.
• Sølve Raaen – Kongsberg Maritime
• Atsushi Sato – Yokogawa Electric Corporation
• Carl Schumaker – Rockwell Automation
• Bob Strebel – Lockheed Martin Corporation

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.)

• Zhafran Abdul Aziz – Petronas
• John Casey – CPLANE.ai
• Cathy Fox – The Open Group
• Craig Griffin – Wind River Systems
• Kirk Hansen – Enterprise Transformation Partners
• Alex Johnson – Schneider Electric
• Jim Luth – Schneider Electric
• Jeremy Rover – Intel Corporation
• Kirk Smith – Intel Corporation
• Andrew Vanderpool – Phoenix Contact

Referenced Documents

The following documents are referenced in Part 4 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

Normative references for Part 4 of the O-PAS Standard are defined in Section 1.4.

Informative References

• 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 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

1.1 Objective

The objective of Part 4 of the O-PAS Standard is to specify the O-PAS Connectivity Framework (OCF).

1.2 Overview

The O-PAS Standard provides a comprehensive set of standards and specifications to meet the requirements of a distributed and secure Industrial Automation Control System (IACS) using an open and interoperable architecture. The standards are defined to allow development of systems composed of functional elements from multiple vendors, without custom integration.

Part 4 covers the OCF. The purpose of the OCF is to allow interoperability between instances of O-PAS Distributed Control Nodes (DCNs). It defines the mechanisms for handling the information flows between instances of O-PAS DCNs utilizing a standard OPC Unified Architecture (OPC UA) communication model (interface). The OCF defines the runtime environments used to communicate data.

The OCF provides the interoperability for process-related data between instances of DCNs.

Since the underlying technology to provide both syntactic and semantic interoperability for the OCF is the OPC UA (OPC 10000-1), this document is written in the format of a “Companion Specification” as defined by the OPC Foundation in order to build on the fundamental capabilities of the OPC UA. For readers unfamiliar with the OPC UA, Appendix B provides an overview, and Appendix C describes OPC UA conventions used in this document.

1.3 Conformance

For the purposes of Part 4 of the O-PAS Standard, the conformance requirements (marked with “CRQ” identifiers) are defined in Chapter 5 through Chapter 7.

1.4 Normative References

The following standards contain provisions which, through references in this document, constitute provisions of Part 4 of the O-PAS Standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this document are encouraged to investigate the possibility of applying the most recent editions of the standards listed below.

• IEC 62439-3:2016: Industrial Communication Networks – High-availability Automation Networks – Part 3: Parallel Redundancy Protocol (PRP) and High-availability Seamless Redundancy (HSR); refer to:https://webstore.iec.ch/publication/24438
• IEEE 802.1AS-2011: IEEE Standard for Local and Metropolitan Area Networks – Timing and Synchronization for Time-sensitive Applications in Bridged Local Area Networks; refer to: https://standards.ieee.org/standard/802_1AS-2011.html
• IEEE 802.3-2018: IEEE Standard for Ethernet; refer to: https://standards.ieee.org/standard/802_3-2018.html
• IEEE 1588-2008: IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems; refer to: https://standards.ieee.org/standard/1588-2008.html
• IEEE 1588-2019: IEEE Approved Draft Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems; refer to: https://standards.ieee.org/standard/1588-2019.html
• IETF RFC 790: Assigned Numbers, September 1981; refer to: https://tools.ietf.org/html/rfc790
• IETF RFC 791: Internet Protocol – DARPA Internet Program – Protocol Specification, September 1981; refer to: https://tools.ietf.org/html/rfc791
• IETF RFC 1034: Domain Names – Concepts and Facilities, November 1987; refer to: https://tools.ietf.org/html/rfc1034
• IETF RFC 1035: Domain Names – Implementation and Specification, November 1987; refer to: https://tools.ietf.org/html/rfc1035
• IETF RFC 2119: Key Words for Use in RFCs to Indicate Requirement Levels, March 1997; refer to: https://tools.ietf.org/html/rfc2119
• IETF RFC 2131: Dynamic Host Configuration Protocol, March 1997; refer to: https://tools.ietf.org/html/rfc2131
• IETF RFC 3315: Dynamic Host Configuration Protocol for IPv6 (DHCPv6), July 2003; refer to: https://tools.ietf.org/html/rfc3315
• IETF RFC 8200: Internet Protocol, Version 6 (IPv6) Specification, July 2017; refer to: https://tools.ietf.org/html/rfc8200
• 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 6 – Information and Exchange Models, The Open Group Standard (C230-6), 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
• OPC 10000-1: OPC^® Unified Architecture – Part 1: Overview and Concepts, Version 1.04 (also IEC TR 62541-1:2020), OPC Foundation; refer to: http://www.opcfoundation.org/UA/Part1/
• OPC 10000-2: OPC^® Unified Architecture – Part 2: Security Model,Version 1.04 (also IEC TR 62541-2:2020), OPC Foundation; refer to: http://www.opcfoundation.org/UA/Part2/
• OPC 10000-3: OPC^® Unified Architecture – Part 3: Address Space Model, Version 1.04 (also IEC 62541-3:2020), OPC Foundation; refer to: http://www.opcfoundation.org/UA/Part3/
• OPC 10000-4: OPC^® Unified Architecture – Part 4: Services, Version 1.04 (also IEC 62541-4:2020), OPC Foundation; refer to: http://www.opcfoundation.org/UA/Part4/
• OPC 10000-5: OPC^® Unified Architecture – Part 5: Information Model, Version 1.04 (also IEC 62541-5:2020), OPC Foundation; refer to: http://www.opcfoundation.org/UA/Part5/
• OPC 10000-6: OPC^® Unified Architecture – Part 6: Mappings, Version 1.04 (also IEC 62541-6:2020), OPC Foundation; refer to: http://www.opcfoundation.org/UA/Part6/
• OPC 10000-7: OPC^® Unified Architecture – Part 7: Profiles, Version 1.04 (also IEC 62541-7:2020), OPC Foundation; refer to: http://www.opcfoundation.org/UA/Part7/
• OPC 10000-8: OPC^® Unified Architecture – Part 8: Data Access, Version 1.04 (also IEC 62541-8:2020), OPC Foundation; refer to: http://www.opcfoundation.org/UA/Part8/
• OPC 10000-9: OPC^® Unified Architecture – Part 9: Alarms and Conditions, Version 1.04 (also IEC 62541-9:2020), OPC Foundation; refer to: http://www.opcfoundation.org/UA/Part9/
• OPC 10000-10: OPC^® Unified Architecture – Part 10: Programs, Version 1.04 (also IEC 62541-10:2020), OPC Foundation; refer to: http://www.opcfoundation.org/UA/Part10/
• OPC 10000-11: OPC^® Unified Architecture – Part 11: Historical Access, Version 1.04 (also IEC 62541-11:2020), OPC Foundation; refer to: http://www.opcfoundation.org/UA/Part11/
• OPC 10000-13: OPC^® Unified Architecture – Part 13: Aggregates, Version 1.04 (also IEC 62541-13:2020), OPC Foundation; refer to: http://www.opcfoundation.org/UA/Part13
• OPC 10000-14: OPC^® Unified Architecture – Part 14: PubSub, Version 1.04 (also IEC 62541-14:2020), OPC Foundation; refer to: http://www.opcfoundation.org/UA/Part14/

1.5 Terminology

The key words “shall”, “shall not”, and “should” are used in the O-PAS Standard as defined below. These definitions are taken from IETF RFC 2119.

Shall Definition is an absolute requirement of the specification.

Shall not Definition is an absolute prohibition of the specification.

Should There may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

1.6 Future Directions (Informative)

A future version of the O-PAS Standard will address additional functionality such as common configuration information, portability of applications, and interchangeable devices. At that time, Part 4 and its contents will be revised and updated accordingly. See Section 7.3 for deferred control network topics.

The current OCF-001 Profile requires servers to register themselves with a Local Discovery Server (LDS), but at the same time requires that clients use a Global Discovery Server (GDS) to look up the server registrations. The OPC Foundation currently provides no standardized way to move registrations from an LDS to a GDS or for servers to register directly with a GDS. When the OPC Foundation eventually specifies this mechanism, Part 4 will be updated accordingly. In the meantime, O-PAS system integrators need to be mindful of the proprietary ways a GDS accepts registrations such that compliant OCF-001 servers can be accommodated.

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.

3.1 Prerequisites

Part 4 assumes a working understanding of the OPC Unified Architecture (UA) Specification. Readers unfamiliar with the OPC UA specification should read Appendix B and Appendix C first.

4.1 Overview

This chapter begins to define the information model for the O-PAS Standard, Version 2.1. The model defined here is a simple organizational structure (i.e., a folder) for containing nodes that conform to information models that are defined in O-PAS Part 6.

4.2 OPAS Folder

The OPAS node is formally defined in Table 1.

Table 1: OPAS Instance Definition

Attribute	Value
0:BrowseName	OPAS
Reference	NodeClass	BrowseName	DataType	TypeDefinition
Organized by the Objects Folder defined in OPC 10000-5: Information Model.
0:HasTypeDefinition	0:ObjectType	0:FolderType	Defined in OPC 10000-5: Information Model

This is the root folder for instances of some O-PAS defined objects. Additional details will be provided in other parts of the O-PAS Standard. The model is illustrated in Figure 1.

Figure 1: OPAS Folder Overview

5.1 Overview

Facets are named groupings of conformance units, conformance requirements, profiles, and other facets. Profiles are named groupings of conformance units, conformance requirements, facets, and other profiles that are combined together to define the complete functionality of an O-PAS component.

The following tables specify the profiles and facets available for components (physical or virtual) that implement the OCF specification. Figure 2 illustrates the relationship between profiles, facets, conformance units, and conformance requirements.

Some profiles, facets, and conformance units may not be implemented by all conformant products. Such optional functionality is indicated in the Mandatory/Optional columns in the tables in Chapters 5, 6, and 7. All functionality designated as mandatory shall be implemented as described to be O-PAS conformant. If a product chooses to implement functionality indicated as optional, it shall be implemented to conform to the chosen optional profile, facet, or conformance unit.

The underlying OPC UA profiles, facets, and conformance units may contain optional functionality that is not repeated in the O-PAS conformance tables here. If the optional functionality is not specified by the O-PAS Standard, and a product fails the OPC UA conformance test for that feature, the product will still be considered O-PAS conformant. Conversely, if the optional functionality is specified by the O-PAS Standard and a product fails the conformance test, then the product would not be O-PAS conformant.

Figure 2: The Relationship between Profiles, Facets, and Conformance Units

5.2 Namespace Metadata

Table 2 defines the namespace metadata Object for the O-PAS Standard. The namespace metadata consists of a set of properties that describe the unique namespace defined by the O-PAS Standard. The Object is used to provide version information for the namespace and an indication about static nodes. Static nodes are identical for all attributes in all servers, including the Value attribute. See OPC 10000-5 for more details.

The information is provided as an object of type NamespaceMetadataType. This object is a component of the Namespaces Object that is part of the server object. The NamespaceMetadataType ObjectType and its properties are defined in OPC 10000-5.

The version information is also provided as part of the ModelTableEntry in the UANodeSet XML file. The UANodeSet XML schema is defined in OPC 10000-6.

Table 2: Namespace Metadata Object for the O-PAS Standard

Attribute	Value
0:BrowseName	https://www.opengroup.org/open-process-automation/O-PAS/CF
Reference	BrowseName	DataType	Value
0:HasProperty	0:NamespaceUri	0:String	https://www.opengroup.org/open-process-automation/O-PAS/CF
0:HasProperty	0:NamespaceVersion	0:String	1.0
0:HasProperty	0:NamespacePublicationDate	0:DateTime	2018-10-03
0:HasProperty	0:IsNamespaceSubset	0:Boolean	True
0:HasProperty	0:StaticNodeIdTypes	0:IdType[]	Integer
0:HasProperty	0:StaticNumericNodeIdRange	0:NumericRange[]	0, 7000
0:HasProperty	0:StaticStringNodeIdPattern	0:String	Null

5.3 OCF Conformance Units

This section defines the conformance units for the OPC UA information model for the OCF.

5.3.1 OCF Information Model – Server

This section defines the conformance units for the OPC UA information model for the OCF on the server side (see Table 3).

Table 3: OCF Information Model Conformance Units – Server

Conformance Requirement	Category	Title	Description
CRQ-P4-0001	Server	O-PAS Base Folder – Server	The O-PAS server supports the OCF information model including the OPAS folder instance (Chapter 3).
CRQ-P4-0095	Server	O-PAS NamespaceMetadata Object – Server	The O-PAS server contains the namespace metadata object specified in Section 5.2.

5.4 OCF Facets

The following sections define OCF facets that, when implemented, are used to add additional functionality to the OCF-001 Profile defined in Section 5.5.1 and the OCF-002 Profile defined in Section 5.5.2.

Some conformance units appear in more than one Profile or Facet since the requirements may apply to both Clients and Servers.

5.4.1 OCF-F-001: OCF Security Server Facet

The OCF Security Server facet defined in Table 4 includes conformance units for servers that are not included in other OPC UA-defined facets and profiles. This facet is required to meet the security requirements of the O-PAS Standard.

Table 4: OCF Security Server Facet Definition

Conformance Requirement	Security Profile/Facet/Conformance Unit	Defined in	Optional/ Mandatory
CRQ-P4-0002	OPC UA Authority Profile	OPC 10000-7: Profiles	M
CRQ-P4-0003	Security Time Synch – NTP/OS-based Support	OPC 10000-7: Profiles	M
CRQ-P4-0004	Security Administration	OPC 10000-7: Profiles	M
CRQ-P4-0005	Security Role Server Restrict Applications	OPC 10000-7: Profiles	M
CRQ-P4-0006	Security Role Server Restrict Endpoints	OPC 10000-7: Profiles	M
CRQ-P4-0007	Security Role Server Role Permissions	OPC 10000-7: Profiles	M

5.4.2 OCF-F-002: OCF Security Client Facet

The OCF Security Client facet defined in Table 5 includes conformance units for clients that are not included in other OPC UA-defined facets and profiles. This facet is required to meet the security requirements of the O-PAS Standard.

Table 5: OCF Security Client Facet Definition

Conformance Requirement	Security Profile/Facet/Conformance Unit	Defined in	Optional/ Mandatory
CRQ-P4-0009	OPC UA Authority Profile	OPC 10000-7: Profiles	M
CRQ-P4-0010	Security Time Synch – NTP/OS-based Support	OPC 10000-7: Profiles	M
CRQ-P4-0011	Security Default Application Instance Certificate	OPC 10000-7: Profiles	M
CRQ-P4-0012	Security Policy Required	OPC 10000-7: Profiles	M
CRQ-P4-0013	Authorization Service Client	OPC 10000-7: Profiles	M

5.4.3 OCF-F-003: OCF Client Facet

The OCF Client facet defined in Table 6 includes facets and profiles used to add OPC client functionality to the OCF-001 Profile.

Table 6: OCF Client Facet Definition

Conformance Requirement	Profile/Facet/Conformance Unit	Defined in	Optional/ Mandatory
CRQ-P4-0014	Standard UA Client 2017 Profile	OPC 10000-7: Profiles	M
CRQ-P4-0015	Documentation – Client	OPC 10000-7: Profiles	M
CRQ-P4-0016	OCF-F-005 Alarms and Conditions Client Facet	Section 5.4.5	O
CRQ-P4-0017	Historical Access Client Facet	OPC 10000-7: Profiles	O
CRQ-P4-0018	Historical Events Client Facet	OPC 10000-7: Profiles	O
CRQ-P4-0019	AliasName Client Facet	OPC 10000-7: Profiles	M
Conformance Requirement	Security Profile/Facet/Conformance Unit	Defined in	Optional/ Mandatory
CRQ-P4-0020	OCF-F-002 OCF Security Client Facet	Section 5.4.2	M
CRQ-P4-0021	User Role Management Client Facet	OPC 10000-7: Profiles	M
CRQ-P4-0022	Security Time Synchronization	OPC 10000-7: Profiles	M
CRQ-P4-0023	Best Practice – Random Numbers	OPC 10000-7: Profiles	M
CRQ-P4-0024	Best Practice – Timeouts	OPC 10000-7: Profiles	M
CRQ-P4-0025	Best Practice – Administrative Access	OPC 10000-7: Profiles	M
CRQ-P4-0026	Best Practice – Strict Message Handling	OPC 10000-7: Profiles	M
CRQ-P4-0027	SecurityPolicy [A] – Aes128-Sha256-RsaOaep	OPC 10000-7: Profiles	M
CRQ-P4-0028	SecurityPolicy [B] – Basic256Sha256	OPC 10000-7: Profiles	M
CRQ-P4-0029	User Token – JWT Client Facet	OPC 10000-7: Profiles	M
CRQ-P4-0030	Global Certificate Management Client Facet	OPC 10000-7: Profiles	M

5.4.4 OCF-F-004: Alarms and Conditions Server Facet

The facets in Table 7 extend the base functionality of the OCF-001 Profile to include ability to expose Alarms per OPC 10000-9.

Table 7: Alarms and Conditions Server Facet Definition

Conformance Requirement	Profile/Facet/Conformance Unit	Defined in	Optional/ Mandatory
CRQ-P4-0032	A & C Acknowledgeable Alarm Server Facet	OPC 10000-7: Profiles	M
Conformance Requirement	Security Profile/Facet/Conformance Unit	Defined in	Optional/ Mandatory
CRQ-P4-0033	Best Practice – Alarm Handling	OPC 10000-7: Profiles	M

5.4.5 OCF-F-005: Alarms and Conditions Client Facet

The facets in Table 8 extend the base functionality of the OCF-001 Profile to include the ability to consume Alarms as a client as per OPC 10000-9.

Table 8: Alarms and Conditions Client Facet Definition

Conformance Requirement	Profile/Facet/Conformance Unit	Defined in	Optional/ Mandatory
CRQ-P4-0034	A & C Alarm Client Facet	OPC 10000-7: Profiles	M

5.4.6 OCF-F-006: OCF Subscriber Facet

The OCF Subscriber facet defined in Table 9 includes facets and profiles used to add OPC subscriber functionality to the OCF-002 Profile. Not all products implement a subscriber (e.g., an I/O DCN), but when a product does implement a subscriber it shall conform to the requirements of this facet.

Table 9: OCF Subscriber Facet Definition

Conformance Requirement	Profile/Facet/Conformance Unit	Defined in	Optional/ Mandatory
CRQ-P4-0036	Subscriber UDP UADP Flexible Layout Profile	OPC 10000-7: Profiles	M
CRQ-P4-0037	Subscriber UDP UADP Periodic Fixed Profile	OPC 10000-7: Profiles	M
CRQ-P4-0038	Subscriber UDP UADP Dynamic Profile	OPC 10000-7: Profiles	M
CRQ-P4-0039	Subscriber Information Model Facet	OPC 10000-7: Profiles	M
CRQ-P4-0040	Subscriber Component Configuration Facet	OPC 10000-7: Profiles	M
CRQ-P4-0041	Subscriber UADP Parameter Configuration Facet	OPC 10000-7: Profiles	M
CRQ-P4-0042	Subscriber Message Security Facet	OPC 10000-7: Profiles	M
CRQ-P4-0043	Key Credential Service Client Facet	OPC 10000-7: Profiles	M

5.5 OCF Profiles

5.5.1 OCF-001: OPC UA Client/Server Profile

Table 10 defines a profile for the minimum functionality necessary for a component that conforms to the OCF using the OPC UA client/server communication model.

Table 10: OCF-001: OPC UA Client/Server Profile Definition

Conformance Requirement	Server Profile/Facet/Conformance Unit	Defined in	Optional/ Mandatory
CRQ-P4-0100	Micro Embedded Device 2017 Server Profile	OPC 10000-7: Profiles	M
CRQ-P4-0101	Base Info GetMonitoredItems Method	OPC 10000-7: Profiles	M
CRQ-P4-0102	Base Info ResendData Method	OPC 10000-7: Profiles	M
CRQ-P4-0103	Base Info Type System	OPC 10000-7: Profiles	M
CRQ-P4-0104	Base Info Engineering Units	OPC 10000-7: Profiles	M
CRQ-P4-0105	Base Info Estimated Return Time	OPC 10000-7: Profiles	O
CRQ-P4-0106	Discovery Register	OPC 10000-7: Profiles	M
CRQ-P4-0107	Discovery Register2	OPC 10000-7: Profiles	M
CRQ-P4-0108	Session Cancel	OPC 10000-7: Profiles	M
CRQ-P4-0109	Attribute Write StatusCode & Timestamp	OPC 10000-7: Profiles	O
CRQ-P4-0110	Monitor Triggering	OPC 10000-7: Profiles	M
CRQ-P4-0111	Monitored Items Deadband Filter	OPC 10000-7: Profiles	M
CRQ-P4-0112	Security Default ApplicationInstance Certificate	OPC 10000-7: Profiles	M
CRQ-P4-0113	Security – No Application Authentication	OPC 10000-7: Profiles	O
CRQ-P4-0114	Security Role Server Authorization	OPC 10000-7: Profiles	O
CRQ-P4-0115	Security User X509	OPC 10000-7: Profiles	M
CRQ-P4-0116	User Token – X509 Certificate Server Facet	OPC 10000-7: Profiles	M
CRQ-P4-0118	Enhanced DataChange Subscription 2017 Server Facet	OPC 10000-7: Profiles	M
CRQ-P4-0045	Base Server Behavior Facet	OPC 10000-7: Profiles	M
CRQ-P4-0046	Sessionless Server Facet	OPC 10000-7: Profiles	M
CRQ-P4-0047	Documentation Server Facet	OPC 10000-7: Profiles	M
CRQ-P4-0048	Standard DataChange Subscription 2017 Server Facet	OPC 10000-7: Profiles	M
CRQ-P4-0049	Data Access Server Facet	OPC 10000-7: Profiles	M
CRQ-P4-0050	Auditing Server Facet	OPC 10000-7: Profiles	M
CRQ-P4-0051	Address Space Notifier Server Facet	OPC 10000-7: Profiles	M
CRQ-P4-0052	OCF-F-004 Alarms and Conditions Server Facet	Section 5.4.4	O
CRQ-P4-0053	Historical Raw Data Server Facet	OPC 10000-7: Profiles	O
CRQ-P4-0054	Base Historical Event Server Facet	OPC 10000-7: Profiles	O
CRQ-P4-0001	O-PAS Base Folder – Server	Section 5.3.1	M
CRQ-P4-0095	O-PAS NamespaceMetadata Object – Server	Section 5.3.1	M
CRQ-P4-0056	AliasName Server Facet	OPC 10000-7: Profiles	M
Conformance Requirements	Client Profile/Facet/Conformance Unit	Defined in	Optional/ Mandatory
CRQ-P4-0057	OCF-F-003 OCF Client Facet	Section 5.4.3	O
Conformance Requirements	Security Profile/Facet/Conformance Unit	Defined in	Optional/ Mandatory
CRQ-P4-0058	Security User Access Control Base	OPC 10000-7: Profiles	M
CRQ-P4-0059	Security Time Synchronization	OPC 10000-7: Profiles	M
CRQ-P4-0060	Best Practice – Audit Events	OPC 10000-7: Profiles	M
CRQ-P4-0061	Best Practice – Random Numbers	OPC 10000-7: Profiles	M
CRQ-P4-0062	Best Practice – Timeouts	OPC 10000-7: Profiles	M
CRQ-P4-0063	Best Practice – Administrative Access	OPC 10000-7: Profiles	M
CRQ-P4-0064	Best Practice – Strict Message Handling	OPC 10000-7: Profiles	M
CRQ-P4-0065	SecurityPolicy [A] – Aes128-Sha256-RsaOaep	OPC 10000-7: Profiles	M
CRQ-P4-0066	SecurityPolicy [B] – Basic256Sha256	OPC 10000-7: Profiles	M
CRQ-P4-0067	User Token – JWT Server Facet	OPC 10000-7: Profiles	M
CRQ-P4-0068	User Role Management Server Facet	OPC 10000-7: Profiles	M
CRQ-P4-0069	Global Certificate Management Server Facet	OPC 10000-7: Profiles	M
CRQ-P4-0070	OCF-F-001 OCF Security Server Facet	Section 5.4.1	M
CRQ-P4-0071	Authorization Service Server Facet	OPC 10000-7: Profiles	M
CRQ-P4-0099	Security Facet – SEC-F-001	O-PAS – Part 2	M

5.5.2 OCF-002: OPC UA Client/Server and PubSub Profile

Table 11 extends the base functionality of the OCF-001 Profile to include the ability to produce and consume data using OPC UA PubSub defined in OPC 10000-14. A publisher shall implement at least one of the UDP UADP publisher profiles. It is recommended that a publisher implement all of the UDP UADP publisher profiles to allow better interoperability.

Table 11: OCF-002: OPC UA Client/Server and PubSub Profile Definition

Conformance Requirement	Profile/Facet/Conformance Unit	Defined in	Optional/ Mandatory
CRQ-P4-0072	OCF-001: OPC UA Client/Server Profile	Section 5.5	M
Conformance Requirement	Publisher Profile/Facet/Conformance Unit	Defined in	Optional/ Mandatory
CRQ-P4-0073	Publisher UDP UADP Flexible Layout Profile	OPC 10000-7: Profiles	O
CRQ-P4-0074	Publisher UDP UADP Dynamic Profile	OPC 10000-7: Profiles	O
CRQ-P4-0075	Publisher UDP UADP Periodic Fixed Profile	OPC 10000-7: Profiles	O
CRQ-P4-0076	Publisher Information Model Facet	OPC 10000-7: Profiles	M
CRQ-P4-0077	Publisher Component Configuration Facet	OPC 10000-7: Profiles	M
CRQ-P4-0078	Publisher UADP Parameter Configuration Facet	OPC 10000-7: Profiles	M
CRQ-P4-0079	Publisher Message Security Facet	OPC 10000-7: Profiles	M
CRQ-P4-0080	Key Credential Service Server Facet	OPC 10000-7: Profiles	M
Conformance Requirement	Subscriber Profile/Facet/Conformance Unit	Defined in	Optional/ Mandatory
CRQ-P4-0081	OCF-F-006 OCF Subscriber Facet	Section 5.4.6	O

5.6 Handling of OPC UA Namespaces

Namespaces are used by the OPC UA to create unique identifiers across different naming authorities. Naming authorities include the local server, the underlying system, standards bodies, and consortia. It is expected that most nodes use the URI of the server or of the underlying system. The attributes NodeId and BrowseName are identifiers. A UA node in the UA AddressSpace is unambiguously identified using a NodeId. Unlike NodeIds, the BrowseName cannot be used to unambiguously identify a UA node. Different nodes may have the same BrowseName. They are used to build a BrowsePath between two nodes or to define a standard property.

Servers may often choose to use the same namespace for the NodeId and the BrowseName. However, if they want to provide a standard property, the BrowseName uses the namespace of the standards body although the namespace of the NodeId reflects something else; for example, the EngineeringUnits property. All NodeIds of nodes not defined in the O-PAS Standard do not use the standard namespaces.

Table 12 provides a list of mandatory and optional namespaces used in an OCF OPC UA server.

Table 12: Namespaces Used in an OCF Server

NamespaceURI	Description	Use
http://opcfoundation.org/UA/	Namespace for NodeIds and BrowseNames defined in the OPC UA. This namespace must have namespace index 0.	Mandatory
Local Server URI	Namespace for nodes defined in the local server. This may include types and instances used in an O-PAS OCF DCN represented by the server. This namespace must have namespace index 1.	Mandatory
https://www.opengroup.org/open-process-automation/O-PAS/CF	Namespace for NodeIds and BrowseNames defined in the O-PAS Standard. The namespace index is server-specific, but all implementations shall use this Namespace URI. [CRQ-P4-0095]	Mandatory
Vendor-specific types and instances	A server may provide vendor-specific types like types derived from ObjectTypes defined in the O-PAS Standard or vendor-specific instances of those types in a vendor-specific namespace.	Optional

Table 13 provides a list of namespaces and their index used for BrowseNames in the O-PAS Standard. The default namespace of the O-PAS Standard is not listed since all BrowseNames without a prefix use this default namespace.

Table 13: Namespaces Used in the O-PAS Standard

NamespaceURI	Namespace Index	Example
http://opcfoundation.org/UA/	0	0:EngineeringUnits

6.1 Overview

In order for DCNs to communicate with each other over the OCF, each DCN must run one or more active OCF instances (software that understands how to encode/decode and transmit/receive OCF packets). The OCF is highly decentralized by design where most communication is directly between OCF instances running in a collection of DCNs that make up an O-PAS system. However, some services on which the OCF relies are best supplied by a centralized system-wide service. An O-PAS system must have at least one Global Discovery Server (GDS) that provides:

• Location services (to discover other DCNs in the system)
• Alias name resolution services (to locate OPC UA items by name within the system)
• Authorization services (to manage and validate credentials used to access resources in the DCNs)

6.2 GDS-001: Global Discovery Server Profile

Table 14 defines a profile for the minimum functionality necessary for a component that provides system-wide GDSs.

Table 14: GDS-001: Global Discovery Server Profile Definition

Conformance Requirement	GDS Profiles/Facets/Conformance Units	Defined in	Optional/ Mandatory
CRQ-P4-0082	Global Discovery and Certificate Mgmt 2017 Server	OPC 10000-7: Profiles	M
CRQ-P4-0083	Global Service Authorization Request Server Facet	OPC 10000-7: Profiles	M
CRQ-P4-0084	Global Service KeyCredential Push Facet	OPC 10000-7: Profiles	M
CRQ-P4-0085	GDS AliasName Server Facet	OPC 10000-7: Profiles	M
CRQ-P4-0099	Security Facet – SEC-F-001	O-PAS – Part 2	M

7.1 Control Network – Required Items

An O-PAS control network describes the combination of edge devices defined as Physical Platforms (PPs) with networking devices such as routers, switches, or access points. The PP connections or interfaces to field equipment such as I/O equipment are discussed in O-PAS Part 7.

This chapter prescribes minimum networking capabilities of the PP (and in extension the DCN). This chapter does not cover the details of network technologies employed in the switches or routers.

7.1.1 Network Software Profiles

O-PAS Networking Profiles are listed in Table 15.

Table 15: O-PAS Networking Profiles

Profile	Time Sync	Network Redundancy	Description	Ethernet Port Count	Network Topology
NET-101	NET-F-011 Section 7.2.1 [CRQ-P4-0125]	None [CRQ-P4-0133]	Single-e2e: Single Ethernet with end-to-end measurement over Layer 3 (Internet Protocol) time sync.	1	Any
NET-102	NET-F-012 Section 7.2.2 [CRQ-P4-0126]	None [CRQ-P4-0133]	Single-p2p: Single Ethernet with peer-to-peer measurement over Layer 2 Ethernet time sync.	1	Any
NET-103	NET-F-013 Section 7.2.3 where: x = 1 for PRP redundancy x = 4 for L3E2E [CRQ-P4-0127]	PRP redundancy protocol (defined in IEC 62439-3:2016) [CRQ-P4-0134]	PRP-e2e: Dual Ethernet with end-to-end measurement over Layer 3 (Internet Protocol) time sync.	2 or more	Any
NET-104	NET-F-013 Section 7.2.3 where: x = 1 for PRP redundancy x = 8 for L2P2P [CRQ-P4-0128]	PRP redundancy protocol (defined in IEC 62439-3:2016) [CRQ-P4-0134]	PRP-p2p: Dual Ethernet with peer-to-peer measurement over Layer 2 Ethernet time sync.	2 or more	Any
NET-105	NET-F-013 Section 7.2.3 where: x = 2 for HSR redundancy x = 4 for L3E2E [CRQ-P4-0129]	HSR redundancy protocol (defined in IEC 62439-3:2016) [CRQ-P4-0135]	HSR-e2e: Ring topology Ethernet with end-to-end measurement over Layer 3 (Internet Protocol) time sync.	2 or more (bridged)	Ring
NET-106	NET-F-013 Section 7.2.3 where: x = 2 for HSR redundancy x = 8 for L2P2P [CRQ-P4-0130]	HSR redundancy protocol (defined in IEC 62439-3:2016) [CRQ-P4-0135]	HSR-p2p: Ring topology Ethernet with peer-to-peer measurement over Layer 2 Ethernet time sync.	2 or more (bridged)	Ring

Each network Profile is required to support the Time Sync Facet and Network Redundancy described in the corresponding “Time Sync” and “Network Redundancy” columns in Table 15. The hardware functionality listed the columns “Description,” “Ethernet Port Count,” and “Network Topology” is informative for the Profiles listed.

All networking Profiles in Table 15 shall conform to IEEE 802.3-2018 Ethernet for Layer 2 of the OSI Model and shall support the following Layer 3 protocols [CRQ-P4-0136]:

• IPv4 (IETF RFC 790, IETF RFC 791)
• IPv6 (IETF RFC 8200)
• DNS (IETF RFC 1034, IETF RFC 1035)
• DHCP (IETF RFC 2131, IETF RFC 3315 (IPv6))

The required time synchronization facets are defined in Section 7.2.

Each network profile shall conform to the security requirements in the Security Facet SEC-F-001 described in O-PAS Part 2 – Security [CRQ-P4-0099].

7.2 Time Synchronization Facets

7.2.1 NET-F-011: O-PAS Media-Independent Time Synchronization Facet

Table 16 formally defines the O-PAS Media-Independent Time Synchronization facet. At least one of the optional transports shall be implemented for each of the NET-F-00x facets [CRQ-P4-0140].

Table 16: Definition of the O-PAS Media-Independent Time Synchronization Facet

Conformance Requirement	Definition	Rationale	Optional/ Mandatory
CRQ-P4-0086	IEEE 1588-2008: Default Precision Time Protocol (PTP) profile for use with the delay request-response mechanism Version 1.0 Profile identifier: 00-1B-19-00-01-00	We require minimum support for the default profile in its end-to-end version of PTP. At least a software implementation of PTP using preferably UDP as transport mechanism across IP networks.	M
CRQ-P4-0087	IEEE 1588-2008: Annex D Transport of PTP over User Datagram Protocol over Internet Protocol, Version 4	This O-PAS time synchronization facet recommends implementing the PTP Profile J.3 and supporting at least one of the transport mechanisms within the time synchronization domain.	O
CRQ-P4-0088	IEEE 1588-2008: Annex E (Normative) Transport of PTP over User Datagram Protocol over Internet Protocol, Version 6		O
CRQ-P4-0089	IEEE 1588-2008: Annex F (Normative) Transport of PTP over IEEE 802.3 Ethernet		O

7.2.2 NET-F-012: O-PAS Ethernet-Based Time Synchronization Facet

Table 17 formally defines the O-PAS Ethernet-Based Time Synchronization facet.

Table 17: Definition of the O-PAS Ethernet-Based Time Synchronization Facet

Conformance Requirement	Definition	Rationale	Optional/ Mandatory
CRQ-P4-0090	IEEE 1588-2008: §J.4 Peer-to-Peer default PTP profile for use with the peer delay mechanism Version 2.0 Profile identifier: 00-1B-19-00-02-00	Specifies a higher-accuracy PTP profile requiring support of networking nodes such as switches and routers. Both edge nodes and networking nodes create a highly synched time domain.	M
CRQ-P4-0091	IEEE 1588-2008: Annex F (Normative) Transport of PTP over IEEE 802.3 Ethernet	This O-PAS facet recommends utilizing Ethernet as the transport mechanism for PTP. It is recommended to implement IEEE 1588-2008 Annex F alone or in combination with the PTP profile defined in the row above. This implementation requires support from the MAC layer. Alternatively, implement a MAC layer according to the IEEE 802.1AS profile (see row below).	O
CRQ-P4-0092	IEEE 802.1AS	This is an Ethernet-only profile that requires support from the MAC layer and is an alternative to the above PTP profile.	O

7.2.3 NET-F-013: O-PAS Advanced Ethernet-Based Time Synchronization Facet

Table 18 formally defines the O-PAS Advanced Ethernet-Based Time Synchronization facet.

Table 18: Definition of the O-PAS Advanced Ethernet-Based Time Synchronization Facet

Conformance Requirement	Definition	Rationale	Optional/ Mandatory
CRQ-P4-0093	IEC 62439-3:2016 Annex A Clocks synchronization over redundant paths in IEC 62439-3 Annex A	Defined as part of the network redundancy protocols PRP and HSR.	M
CRQ-P4-0094	IEC 62439-3:2016 Annex B PTP profile for Power Utility Automation – redundant clock attachment The profile specification of a singly or doubly attached clock according to Annex C shall be according to IEEE 1588-2008 §19.3.3: profileName: IEC 62439-3:2016 “Precision Time Protocol Profile for High-availability Automation Networks” profileVersion: 1.0 profileIdentifier: 00-15-4E-00-01-xy Where the first nibble of the sixth octet is a bit field: x = 1 for PRP redundancy x = 2 for HSR redundancy x = 4 for L3E2E x = 8 for L2P2P y = 0 (minor version) Example: 00-15-4E-00-01-50 supports L3E2E and PRP. organizationName: IEC Technical Committee SC65C Working Group 15 sourceIdentification: see Section 1.4	Defined as part of the network redundancy protocols PRP and HSR.	M

7.3 Control Network – Deferred Items

A future version of the O-PAS Standard will address:

1. Power over Ethernet usage on the control network
2. Wireless technologies used in the control network
3. FO details
4. Time-Sensitive Networking (TSN)
5. Advanced Physical Layer (APL)
6. Security add-ons in IEEE 1588-2008

Related to 4 and 6 above, the IEEE 1588-2019 standard defines a protocol that provides precise synchronization of clocks in packet-based networked systems. Synchronization of clocks can be achieved in heterogeneous systems that include clocks of different inherent precision, resolution, and stability. The protocol supports synchronization accuracy and precision in the sub-microsecond range with minimal network and local computing resources. Customization is supported by means of profiles. The protocol includes default profiles that permit simple systems to be installed and operated without the need for user management. Sub-nanosecond time transfer accuracy can be achieved in a properly designed network. This level of resilience and accuracy is critical in TSN.

A.1 Namespace and Identifiers for the OCF Information Model

This appendix is informative and defines the numeric identifiers for all of the numeric NodeIds defined in the O-PAS Standard. The identifiers are specified in a CSV file with the following syntax:

<SymbolName>, <Identifier>, <NodeClass>

where the SymbolName is either the BrowseName of a Type node or the BrowsePath for an Instance node that appears in the specification and the Identifier is the numeric value for the NodeId. Multiple NodeIds in the same CSV file are separated by newline characters.

The BrowsePath for an Instance node is constructed by appending the BrowseName of the Instance node to the BrowseName for the containing instance or type. An underscore character is used to separate each BrowseName in the path.

The NamespaceUri for all NodeIds defined here is https://www.opengroup.org/open-process-automation/O-PAS/CF.

The CSV of O-PAS numeric NodeId values released with the O-PAS Standard, Version 2.1 can be found here:

http://open-process-automation.projects.opengroup.org/twg/part-4-connectivity/code/v01.00.00/opas_part4.csv

A computer-processable version of the complete information model defined in the O-PAS Standard is also provided. It follows the XML information model schema syntax defined in OPC 10000-6.

The information model schema released with the O-PAS Standard, Version 2.1 can be found here:

http://open-process-automation.projects.opengroup.org/twg/part-4-connectivity/code/v01.00.00/opas_part4.nodeset2.xml

A.2 Profile URIs for the OCF Information Model

Table 19 defines the profile URIs for the profiles defined in O-PAS Part 4. All implementations must use the defined URIs to uniquely identify the corresponding profile.

Profile	Profile URI
Connectivity Framework Security Server Facet	https://www.opengroup.org/open-process-automation/O-PAS/ConnectSecurityServer
Connectivity Framework Security Client Facet	https://www.opengroup.org/open-process-automation/O-PAS/ConnectSecurityClient
Connectivity Framework Client Facet	https://www.opengroup.org/open-process-automation/O-PAS/ConnectClient
Alarms and Conditions Server Facet	https://www.opengroup.org/open-process-automation/O-PAS/AandCServer
Alarms and Conditions Client Facet	https://www.opengroup.org/open-process-automation/O-PAS/AandCClient
Connectivity Framework Subscriber Facet	https://www.opengroup.org/open-process-automation/O-PAS/ConnectSubscriber
OCF-001: OPC UA Client/Server Profile	https://www.opengroup.org/open-process-automation/O-PAS/OCF-001
OCF-002: OPC UA Client/Server and PubSub Profile	https://www.opengroup.org/open-process-automation/O-PAS/OCF-002
GDS-001: Global Discovery Server Profile	https://www.opengroup.org/open-process-automation/O-PAS/GDS-001

B.1 Introduction

For those who may not be familiar with the OPC UA, this appendix is informative and provides a brief overview of information modeling in the OPC UA. The OPC UA is an open and royalty-free set of standards and companion specification(s) designed as a universal OCF. While there are numerous communication solutions available, the OPC UA has key advantages:

• A state-of-the-art security model (see OPC 10000-2)
• A fault-tolerant communication protocol
• An information modeling framework that allows application developers to represent their data in a way that makes sense to them

The OPC UA has a broad scope which delivers economies of scale for application developers. This means that a larger number of high-quality applications at a reasonable cost are available. When combined with semantic models such as the OCF defined in this document, the OPC UA makes it easier for end users to access data via generic commercial applications.

The OPC UA model is scalable from small devices to Enterprise Resource Planning (ERP) systems. OPC UA servers process information locally and then provide that data in a consistent format to any application requesting data; for example, ERP, Manufacturing Execution System (MES), Production Management System (PMS), maintenance systems, HMI, smartphone, or a standard browser. For a more complete overview see OPC 10000-1.

B.2 Basics of OPC UA

As an open standard, the OPC UA is based on standard Internet technologies, like TCP/IP, HTTP, Web Sockets.

As an extensible standard, the OPC UA provides a set of services (see OPC 10000-4) and a basic information model framework. This framework provides an easy manner for creating and exposing vendor-defined information in a standard way. More importantly, all OPC UA clients are expected to be able to discover and use vendor-defined information. This means OPC UA users can benefit from the economies of scale that come with generic visualization and historian applications. This O-PAS Standard is an example of an OPC UA information model designed to meet the needs of developers and users.

OPC UA clients can be any consumer of data from another device on the network. OPC UA clients range from simple browser-based thin clients to complex ERP systems. The full scope of OPC UA applications is shown in Figure 3.

Figure 3: An Example for OPC UA within an Enterprise

The OPC UA provides a robust and reliable communication infrastructure having mechanisms for handling lost messages, failover, heartbeat, etc. With its binary encoded data, it offers a high-performing data exchange solution. Security is built into the OPC UA as security requirements become more and more important, especially since environments are connected to the office network or the Internet and attackers are starting to focus on automation systems.

B.3 Information Modeling in OPC UA

B.3.1     Concepts

The OPC UA provides a framework that can be used to represent complex information as nodes in an AddressSpace which can be accessed with standard web services. The AddressSpace consists of multiple UA nodes connected to each other by references (a form of graph-structured data in computer science terms).

For example:

• A Variable node represents a value that can be read or written

The Variable node has an associated DataType that can define the actual value, such as a string, float, structure, etc. It can also describe the Variable value as a variant data type.

• A Method node represents a function that can be called

Every UA node has a number of attributes including a unique identifier called a NodeId and a text string called a BrowseName.

Figure 4 represents a Heater.

Figure 4: A Basic Object in an OPC UA Address Space

Figure 4, like the other figures in this section, uses a graphic notation described in OPC 10000-3.

• Nodes (things, and kinds of thing) are represented by specific shapes: oval, rectangle, etc.
• Relationships between nodes are called references, and shown by specific kinds of lines

The meaning of Figure 4 for the Heater object is:

• The Heater object has two component objects: Sensor and Heating Element; it also has a component method, which can carry out the Start behavior

(The relationship line from an object to one of its components has a single hash mark at the component end.)

• Moving down a level, the Sensor object has two variables: Temperature and Pressure; the Heating Element also has two variables: Temperature Setpoint and Status

(The relationship line from an object to one of its variables has a double hash mark at the variable end.)

• The diagram shows the current values of each variable; for example, Temperature = 90 and Status = “Off”

Object and Variable nodes are called Instance nodes and they always reference a TypeDefinition (ObjectType or VariableType, respectively) node which describes their semantics and structure. Figure 5 illustrates the relationship between an instance (BoilerUnit1) and its TypeDefinition (BoilerType).

Type nodes are templates that define all of the children that can be present in an instance of the type. In the example in Figure 5, the BoilerType ObjectType defines two sensors: Pressure and Temperature.

All instances of BoilerType have the same (mandatory) children with the same BrowseNames. Instances optionally contain additional children defined by the type, or even children not defined by the type.

Within a type the BrowseNames uniquely identify the child. This means client applications can be designed to search for children based on the BrowseNames from the type instead of NodeIds. This eliminates the need for manual reconfiguration of systems if a client uses types that multiple devices implement.

The OPC UA also supports the concept of subtyping. This allows a modeler to take an existing type and extend it. There are rules regarding subtyping defined in OPC 10000-3, but in general they allow the extension of a given type or the restriction of a DataType. For example, the modeler may decide that the existing ObjectType in some cases needs an additional Variable. The modeler can create a sub-type of the Object and add the Variable. A client that is expecting the parent type can treat the new type as if it was of the parent type. With regard to DataTypes, if a Variable is defined to have a numeric value, a sub-type could restrict the value to a float. The O-PAS Standard adds additional rules for extensions.

Figure 5: The Relationship between Type Definitions and Instances

References allow UA nodes to be connected together in ways that describe their relationships. All references have a ReferenceType that specifies the semantics of the relationship.

Applications can define their own ReferenceType by creating sub-types of the existing ReferenceType. Sub-types inherit the semantics of the parent but may add additional restrictions. Figure 6 shows a set of ReferenceTypes and sub-types, and then uses these types to depict relationships between different objects. Note that both the base ReferenceTypes (e.g., Organizes) are used directly as well as the more specific sub-types.

Figure 6: Examples of References between Objects

As noted previously, the figures above use a notation that was developed for the OPC UA specification. The notation is summarized in Figure 7. Unified Modeling Language™ (UML^®) representations can also be used; however, the OPC UA notation is less ambiguous because there is a direct mapping from the elements in the figures to UA nodes in the AddressSpace of an OPC UA server.

Figure 7: The OPC UA Information Model Notation

A complete description of the different types of UA nodes and references can be found in OPC 10000-3, and the base OPC UA AddressSpace is described in OPC 10000-5.

The OPC UA specification defines a very wide range of functionality in its basic InformationModel. It is not expected that all clients or servers support all functionality in the OPC UA specification. The OPC UA includes the concept of profiles, which segment the functionality into testable certifiable units. This allows the development of companion specifications (such as this document) that can describe the subset of functionality that is expected to be implemented. The profiles do not restrict functionality, but generate requirements for a minimum set of functionality (see OPC 10000-7).

The OPC Foundation also defines a set of InformationModels that provide a basic set of functionality:

• The Data Access specification (see OPC 10000-8) provides a basic InformationModel for typical process or measured data
• The Alarm and Condition specification (see OPC 10000-9) defines a standard InformationModel for Alarms and Conditions
• The Programs specification (see OPC 10000-10) defines a standard InformationModel for extending the functionality available via Method calls and state machines
• The Historical Access specification (see OPC 10000-11) defines the InformationModel associated with Historical Data and Historical Events

The Aggregates specification (see OPC 10000-13) defines a series of standard aggregate functions that allow a client to request summary data. Examples of aggregates include averages, minimums, time in state, standard deviation, etc.

Implementors of OPC UA applications are free to persist their OPC UA information models in any way they wish; however, OPC defines a standard XML format for describing information models called Nodeset files. The XML schema for Nodeset files is defined in OPC 10000-6. OPC UA information models described in specifications are always accompanied by a corresponding Nodeset file.

B.3.2     Namespaces

The OPC UA allows information from many different sources to be combined into a single coherent AddressSpace. Namespaces are used to make this possible by eliminating naming and Id conflicts between information from different sources. Each namespace in the OPC UA has a globally unique string called a NamespaceUri, which identifies a naming authority, and a locally unique integer called a NamespaceIndex, which is an index into the server’s table of NamespaceUris. The NamespaceIndex is unique only within the context of a session between an OPC UA client and an OPC UA server – the NamespaceIndex can change between sessions and still identify the same item even though the NamespaceUri’s location in the table has changed. The services defined for the OPC UA use the NamespaceIndex to specify the Namespace for qualified values.

There are two types of structured values in the OPC UA that are qualified with NamespaceIndexes: NodeIds and QualifiedNames. NodeIds are locally unique (and sometimes globally unique) identifiers for nodes. The same globally unique NodeId can be used as the identifier in a node in many OPC UA servers – the node’s instance data may vary, but its semantic meaning is the same regardless of the server in which it appears. This means OPC UA clients can have built-in knowledge of what the data means in these nodes. OPC UA information models generally define globally unique NodeIds for the TypeDefinitions defined by the information model.

QualifiedNames are non-localized names qualified with a Namespace. They are used for the BrowseNames of UA nodes and allow the same names to be used by different information models without conflict. TypeDefinitions are not allowed to have children with duplicate BrowseNames; however, instances do not have that restriction.

B.3.3     Companion Specifications

An OPC UA companion specification for an industry-specific vertical market describes an information model by defining ObjectTypes, VariableTypes, DataTypes, and ReferenceTypes that represent the concepts used in the vertical market, and potentially also well-defined Objects as entry points into the AddressSpace. For example, O-PAS Part 4 (this document) is an OPC UA companion specification addressing the market of process automation.

B.3.4     Additional Details on Node Attributes

The following is an informative description of attributes that all nodes can possess (because they are part of the base NodeClass):

• NodeId – a unique identifier for the node

The NodeId can be a string, integer, GUID, or ByteString. The choice of which to use is usually based on the underlying system. NodeId should allow the server to easily access the node from the underlying system. If the underlying system has no preference, then an integer is recommended to improve performance on the OPC UA communication side.

• NodeClass – always one of the available classes: Object, ObjectType, Variable, VariableType, ReferenceType, DataType, Method, or View
• BrowseName – the QualifiedName that serves as the symbolic name of the node

The BrowseName can be used to programmatically navigate from one node to another.

• DisplayName – a localized string that an operator/engineer or anyone that is looking at the node would see

The server can store multiple DisplayNames, one for each language that is supported by the server.

• Description – an optional localized string to provide a longer description of the node

The server can store multiple Descriptions, one for each language that is supported by the server.

• WriteMask – provides a mask of attributes that are writeable (by any user)
• UserWriteMask – provides a mask of attributes that are writable by the current user
• RolePermission – provides the permissions that apply to this node for all roles that have access to the node (an array of RolePermissionType structures) (optional)
• UserRolePermission – provides the permissions that apply to the node for all roles granted to the current session (optional)
• AccessRestrictions – provides an option set that describes any access restriction that apply to this node (i.e., a connection with signing or encryption is required to access the node) (optional)
  5.     Additional Details on Variable Attributes

The following is an informative description of attributes that are part of a Variable (defined in OPC 10000-3):

• Value attribute is required on all nodes that are of the Variable NodeClass

It contains the value associated with the variable. The data type of the Value is described by the DataType attribute. The attribute does not have a fixed data type assigned to it. This is the only attribute that does not have a fixed data type. The value contains the actual value and it can also contain a status code, and up to two timestamps (which can include picoseconds):

—  The SourceTimestamp is the timestamp that is assigned to the variable at the lowest/first location that can assign a timestamp; sometimes this is the underlying system; sometimes it is assigned when the value is processed in the first server

—  The ServerTimestamp is the time that the current server received the value

• DataType – a NodeId that indicates a data type; it might be one of the well known data types (e.g., int16, Float, etc.) or it might be a custom type (sub-type of structure or sub-type of enumeration)
• ValueRank – an int32 that indicates if the variable value is an array and if so how many dimensions (–1 is scalar, –2 is any, –3 is scalar or 1 dimension, 0 is one or more dimensions, all other numbers are the actual number of dimensions)
• ArrayDimensions – an array of Uint32 where each entry provides the maximum size of the corresponding array dimension; 0 means unknown
• AccessLevel – provides information about how the value of the variable can be accessed (Read/Write/HistoryRead/HistoryWrite/SemanticChange/StatusWrite/TimestampWrite)
• AccessLevelEx – is an extended version of the AccessLevel (that adds additional bits for array access and atomicity)
• UserAccessLevel – provides information about how the current user can access the value of the variable (Read/Write/HistoryRead/HistoryWrite/SemanticChange/StatusWrite/TimestampWrite)
• Historizing – indicates if the Value is being actively collected for history
• MinimumSamplingInterval – the minimum rate at which the value can be updated by the underlying system; this might be 0, which indicates no minimum or exception reported value

C.1 Scope and Purpose

This appendix uses normative language (“shall”) that paraphrases normative requirements from the OPC UA specification. This appendix is informative because the normative statements here do not imply the need for additional OPAS conformance tests; however, implementations will need to conform indirectly to this appendix by conforming to the OCF Profiles described in Chapter 5.

C.2 Conventions for UA Node Descriptions

The following conventions are used in this document.

UA node definitions are specified using tables (see Table 20).

An attribute is defined by providing its name and a value, or text describing the rules for setting the value.

A reference is defined by providing the ReferenceType name, the BrowseName of the TargetNode, and its NodeClass.

• If the TargetNode is a component of the UA node being defined in the table, the attributes of the composed UA node are defined in the same row of the table
• The TypeDefinition is specified for Objects and Variables
• The TypeDefinition column specifies a symbolic name for a NodeId; in actuality the resulting model is that the specified UA node points with a HasTypeDefinition Reference to the corresponding UA node
• The ModelingRule of the referenced component is provided by specifying the symbolic name of the rule in the ModelingRule column; in the AddressSpace, the UA node shall use a HasModelingRule Reference to point to the corresponding ModelingRule Object

If the NodeId of a DataType is provided, the symbolic name of the UA node representing the DataType shall be used.

UA nodes of all other NodeClasses cannot be defined in the same table; therefore, only the used ReferenceType, their NodeClass, and their BrowseName are specified. A reference to another part of this document points to their definition.

Table 20 illustrates an example Type Definition table. If no components are provided, the DataType, TypeDefinition, and ModelingRule columns may be omitted and only a Comment column is introduced to point to the UA node definition.

Table 20: Type Definition Table

Attribute	Value
AttributeName	Attribute value. If it is an optional attribute that is not set, “--“ shall be used.
Reference	NodeClass	BrowseName	DataType	TypeDefinition	ModelingRule
ReferenceType name	NodeClass of the TargetNode.	BrowseName of the TargetNode. If the Reference is to be instantiated by the server, then the value of the TargetNode’s BrowseName is “--“.	DataType of the TargetNode, only applicable for Variables.	TypeDefinition of the TargetNode, only applicable for Variables and Objects.	Referenced ModelingRule of the referenced Object.

Components of UA nodes can be complex; that is, recursively containing other components. The TypeDefinition, NodeClass, DataType, and ModelingRule can be determined from the TypeDefinitions of the contained components. Therefore, those contained components are not explicitly specified; they are implicitly specified by their TypeDefinitions.

C.3 Common Attributes

The attributes of UA nodes, their DataTypes, and descriptions are defined in OPC 10000-3. Attributes not marked as optional are mandatory and shall be provided by a server. The following tables define if the attribute value is defined by the O-PAS Standard or if it is server-specific.

For all UA nodes specified in the O-PAS Standard, the attributes named in Table 21 shall be set as specified in the table.

Table 21: Common UA Node Attributes

Attribute	Value
NodeId	Section A.1 provides a link to the actual NodeId definition required for implementations of the O-PAS Standard. This document, however, substitutes symbolic names for the actual NodeIds. The symbolic name of each UA node defined in the O-PAS Standard is its BrowseName, or, when it is part of another UA node, the BrowseName of the other UA node, a “.”, and the BrowseName of itself. In this case “part of” means that the whole has a HasProperty or HasComponent reference to its part. Since all UA nodes not part of another UA node have a unique name in the O-PAS Standard, each symbolic name is unique. The Namespace for all NodeIds defined in the O-PAS Standard is defined in Appendix A. The NamespaceIndex for this Namespace is server-specific and depends on the position of the Namespace URI in the server Namespace table. Note that the O-PAS Standard not only defines concrete UA nodes, but also requires that some UA nodes shall be generated; for example, one for each session running on the server. The NodeIds of those UA nodes are server-specific, including the namespace. The NamespaceIndex of server-generated UA nodes shall not be the NamespaceIndex used for the UA nodes defined in the O-PAS Standard.
NodeClass	Shall reflect the NodeClass of the UA node.
BrowseName	The text part of the BrowseNames for all UA nodes defined in the O-PAS Standard is specified in the tables defining the UA nodes. The NamespaceIndex for all BrowseNames defined in the O-PAS Standard is defined in Appendix A. If the BrowseName is not defined by the O-PAS Standard, a NamespaceIndex prefix like ‘0:EngineeringUnits’ or ‘2:DeviceRevision’ is added to the BrowseName to clearly denote the alternate naming authority.
DisplayName	The DisplayName is a LocalizedText. Each server shall provide the DisplayName identical to the BrowseName of the UA node for the LocaleId “en”. Whether the server provides translated names for other LocaleIds is server-specific. Localized text is text in a language specified by the LocaleId. For example, “de” for German; “de-AT” for Austrian German. The default LocaleId is “en” for English.
Description	Optionally a server-specific LocalizedText description is provided.
WriteMask	Optionally the WriteMask attribute can be provided. If the WriteMask attribute is provided, it shall set all non-server-specific attributes to not writable. For example, the Description attribute may be set to writable since a server may provide a server-specific description for the UA node. The NodeId shall not be writable, because it is defined for each UA node in the O-PAS Standard.
UserWriteMask	Optionally the UserWriteMask attribute can be provided. The same rules as for the WriteMask attribute apply.
RolePermissions	Optionally server-specific role permissions can be provided.
UserRolePermissions	Optionally the role permissions of the current session can be provided. The value is server-specific and depends on the RolePermissions attribute (if provided) and the current session.
AccessRestrictions	Optionally server-specific access restrictions can be provided.

C.4 Objects

For all Objects specified in the O-PAS Standard, the attributes named in Table 22 shall be set as specified in the table. The definitions for the attributes can be found in OPC 10000-3.

Table 22: Common Object Attributes

Attribute	Value
EventNotifier	Whether the UA node can be used to subscribe to Events or not is server-specific.

C.5 Common OPC UA Types

The O-PAS Standard makes use of a number of common ObjectType and VariableTypes defined in OPC 10000-3 and OPC 10000-8. They are briefly described here for clarity.

• AnalogItemType is a VariableType (defined in OPC 10000-8) that is used to represent a value in a system that usually has engineering units, limits, and other typical properties that are associated with something that is measured in a system
• TwoStateDiscreteType is a VariableType (defined in OPC 10000-8) that is used to represent a value that has two possible states; it includes localized text for each of the states
• MultiStateDiscreteType is a VariableType (defined in OPC 10000-8) that is used to represent a value that has multiple possible states; it includes an enumeration for the possible states
• MultiStateValueDiscreteType is a VariableType (defined in OPC 10000-8) that is used to represent a value that has multiple possible states; it includes an enumeration for the possible states, where the state values (the enumeration) need not consist of consecutive numeric values (may have gaps) or where the enumeration is not zero-based

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