0% found this document useful (0 votes)

437 views49 pages

The Open Group Preliminary Standard: O-PAS™ Standard, Version 2.0 - Technical Architecture Overview (Informative)

Uploaded by

Ievgen Vasylenko

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

437 views49 pages

The Open Group Preliminary Standard: O-PAS™ Standard, Version 2.0 - Technical Architecture Overview (Informative)

Uploaded by

Ievgen Vasylenko

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 49

Evaluation Copy

The Open Group Preliminary Standard

O-PAS™ Standard, Version 2.0

Part 1 – Technical Architecture Overview (Informative)

Copyright © 2020 The Open Group, All Rights Reserved

Evaluation Copy. Not for redistribution
Evaluation Copy

Copyright © 2020, 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 Preliminary Standard

O-PAS™ Standard, Version 2.0: Part 1 – Technical Architecture Overview (Informative)
Document Number: P201-1

Published by The Open Group, February 2020.

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:
[email protected]

ii The Open Group Preliminary Standard (2020)

Contents
1 Introduction ............................................................................................................... 1
1.1 Objective ......................................................................................................... 1
1.2 Overview......................................................................................................... 1
1.3 Conformance................................................................................................... 2
1.4 Normative References..................................................................................... 2
1.5 Terminology ................................................................................................... 2
1.6 Future Directions ............................................................................................ 3
2 Terms and Definitions ............................................................................................... 4
2.1 Terms .............................................................................................................. 4
3 Technical Architecture Concept Overview ............................................................... 5
3.1 O-PAS Connectivity Framework (OCF) ........................................................ 6
3.2 Distributed Control Node (DCN).................................................................... 6
3.3 Application Types ........................................................................................... 6
3.4 Equipment using the O-PAS Communication Interface (OCI) ...................... 8
3.5 Business Function Connectivity ..................................................................... 9
3.6 Internal and External OT Data Centers ........................................................... 9
4 O-PAS Interface Overview ..................................................................................... 10
4.1 Components and Interfaces ........................................................................... 10
4.2 O-PAS Interfaces .......................................................................................... 11
4.2.1 Layer-F Import/Export and Download/Upload Formats ............... 13
4.2.2 Configuration Management Interface............................................ 14
4.2.3 Application Management Interface ............................................... 14
4.2.4 Connectivity Framework Interface ................................................ 14
4.2.5 System Management Interface ...................................................... 14
5 O-PAS Connectivity Framework (OCF) ................................................................. 16
6 System Security....................................................................................................... 18
7 Planned Platform-Independent Application Interfaces ........................................... 19
7.1 Security Management Interface .................................................................... 22
7.2 Security Services Interface ........................................................................... 23
7.3 Connectivity Framework Software Interface ................................................ 23
7.4 Application Services Interface ...................................................................... 23
7.5 Configuration Information Interface ............................................................. 23
7.6 Platform Services Interface ........................................................................... 24
7.7 Platform I/O Physical Interface .................................................................... 24
7.8 Typical Layer-L Application and Service Functions .................................... 25
7.9 Platform-Dependent Applications ................................................................ 25
A Use-Cases ................................................................................................................ 27
A.1 Small Systems ............................................................................................... 27
A.1.1 DCN Only ..................................................................................... 27

O-PAS™ Standard, Version 2.0: Part 1 – Technical Architecture Overview (Informative) iii
Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
Evaluation Copy

A.1.2 DCNs and Legacy PLC ................................................................. 27

A.1.3 DCNs and PLC with OCI .............................................................. 28
A.1.4 DCN with Legacy DCS and Field Networks ................................ 28
A.2 Medium and Large Size Systems.................................................................. 29
A.2.1 Medium Size Brownfield Example ............................................... 29
A.2.2 Medium Size Greenfield Example ................................................ 29
A.2.3 Large Greenfield Example ............................................................ 30
A.3 Integrated Device Example ........................................................................... 31
A.4 Integrated Device Example with Layer-F Application Support ................... 32
B Application Types and Layers ................................................................................ 34
C Rationale ................................................................................................................. 36
C.1 Interoperability.............................................................................................. 36
C.2 Modularity .................................................................................................... 36
C.3 Standard Conformance ................................................................................. 36
C.4 Scalability ..................................................................................................... 37
C.5 Portability ..................................................................................................... 37
C.6 Technology Support ...................................................................................... 37
D Abbreviations .......................................................................................................... 38

iv The Open Group Preliminary Standard (2020)

Preface
The Open Group

The Open Group is a global consortium that enables the achievement of business objectives
through technology standards. Our diverse membership of more than 700 organizations includes
customers, systems and solutions suppliers, tools 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 1 of the O-PAS™ Standard, Version 2.0, a Preliminary 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 (of the anticipated 13 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™ Standard, Version 2.0: Part 1 – Technical Architecture Overview (Informative) v

 O-PAS Part 6.2 – Information and Exchange Models: Basic Configuration

 O-PAS Part 6.3 – Information and Exchange Models: Alarm and Events Configuration
(planned for Version 2.1)
 O-PAS Part 6.4 – Information and Exchange Models: Function Blocks
 O-PAS Part 6.5 – Information and Exchange Models: IEC 61499 Distributed Function
Blocks (planned for Version 2.1)
 O-PAS Part 6.6 – Information and Exchange Models: IEC 61131-3 Programs (planned for
Version 2.1)
 O-PAS Part 7 – Physical Platform

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

The O-PAS Standard, Version 2.0 is being published initially as a Preliminary Standard since it
addresses an emerging area of technology; therefore, it may change before being published as a
full Standard of The Open Group. In such a case it will be made as upwards-compatible as
possible with the corresponding Preliminary Standard, but complete upwards-compatibility is
not guaranteed.

Once this document becomes a full standard, it will supersede 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.

vi The Open Group Preliminary Standard (2020)

Trademarks
ArchiMate®, DirecNet®, Making Standards Work®, Open O® logo, Open O and Check®
Certification logo, OpenPegasus®, Platform 3.0®, The Open Group®, TOGAF®, UNIX®,
UNIXWARE®, and the Open Brand X® logo are registered trademarks and Agile Architecture
Framework™, Boundaryless Information Flow™, Build with Integrity Buy with Confidence™,
Dependability Through Assuredness™, Digital Practitioner Body of Knowledge™, DPBoK™,
EMMM™, FACE™, the FACE™ logo, IT4IT™, the IT4IT™ logo, O-AAF™, O-DEF™, O-
HERA™, O-PAS™, Open FAIR™, Open Platform 3.0™, Open Process Automation™, Open
Subsurface Data Universe™, Open Trusted Technology Provider™, O-SDU™, Sensor
Integration Simplified™, SOSA™, and the SOSA™ logo are trademarks of The Open Group.

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

UML® is a registered 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.

O-PAS™ Standard, Version 2.0: Part 1 – Technical Architecture Overview (Informative) vii
Copyright © 2020 The Open Group, All Rights Reserved
Evaluation Copy. Not for redistribution
Evaluation Copy

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

viii The Open Group Preliminary Standard (2020)

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

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

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)
 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
 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
 O-PAS Standard, Version 2.0: Part 2 – Security, The Open Group Preliminary Standard
(P201-2), February 2020, published by The Open Group; refer to:
www.opengroup.org/library/p201
 O-PAS Standard, Version 2.0: Part 3 – Profiles (Informative), The Open Group
Preliminary Standard (P201-3), February 2020, published by The Open Group; refer to:
www.opengroup.org/library/p201

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

 O-PAS Standard, Version 2.0: Part 4 – O-PAS Connectivity Framework (OCF), The Open
Group Preliminary Standard (P201-4), February 2020, published by The Open Group;
refer to: www.opengroup.org/library/p201
 O-PAS Standard, Version 2.0: Part 5 – System Management, The Open Group
Preliminary Standard (P201-5), February 2020, published by The Open Group; refer to:
www.opengroup.org/library/p201
 O-PAS Standard, Version 2.0: Part 6.1 – Information and Exchange Models: Overview
and Interfaces, The Open Group Preliminary Standard (P201-6a), February 2020,
published by The Open Group; refer to: www.opengroup.org/library/p201
 O-PAS Standard, Version 2.0: Part 6.2 – Information and Exchange Models: Basic
Configuration, The Open Group Preliminary Standard (P201-6b), February 2020,
published by The Open Group; refer to: www.opengroup.org/library/p201
 O-PAS Standard, Version 2.0: Part 6.4 – Information and Exchange Models: Function
Blocks, The Open Group Preliminary Standard (P201-6d), February 2020, published by
The Open Group; refer to: www.opengroup.org/library/p201
 O-PAS Standard, Version 2.0: Part 7 – Physical Platform, The Open Group Preliminary
Standard (P201-7), February 2020, published by The Open Group; refer to:
www.opengroup.org/library/p201
 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

x The Open Group Preliminary Standard (2020)

1 Introduction

1.1 Objective
The objective of Part 1 of the O-PAS Standard is to define the components that make up the
O-PAS specification. This document lays out the overall Technical Architecture, developed by
the Open Process Automation™ Forum, a Forum of The Open Group, of an O-PAS conformant
system through a set of interfaces to the components. The detailed interface specifications are
defined in the other parts of the O-PAS Standard and contain the associated conformance
criteria. The objective of the Technical Architecture is to meet the requirements of a federated
and secure process automation system using an open and interoperable architecture. The O-PAS
Standard is defined to allow development of systems consisting of components from multiple
vendors, without requiring custom integration.

Part 1 of the O-PAS Standard is informative and intended to provide a general overview of a
system composed of O-PAS conformant components and to describe the general functionality of
the interfaces.

The contents and security scope of Part 1 of the O-PAS Standard are related to the scope and
overall objective of the O-PAS Standard, Version 2.0.

1.2 Overview
The Technical Architecture allows for construction of safe, reliable, secure process automation
systems that are scalable from very small to very large, which do not require system shutdown to
perform updates and extensions, and which can be applied to existing systems and to new
construction. The Technical Architecture has been defined to not compromise the safety,
resilience, reliability, maintainability, or security of a process automation system.
 To support safety and resilience, the Technical Architecture has been defined so that
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
 To support resiliency, the Technical Architecture has been defined so that it provides the
environment for m-to-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
 To support reliability and maintainability, the Technical Architecture is defined so that 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, except for components
being repaired or replaced
 To support reliability and maintainability, the Technical Architecture is defined to allow
incremental upgrades by replacement of components with the same or additional
functionality, without system redesign

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

 To support reliability and maintainability, the Technical Architecture is defined to provide

the ability to move applications across control elements without modifications, allowing
recovery from control element failure
 To support security, the Technical Architecture has security 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
 To support interoperability, the Technical Architecture is defined through interface
functions and information models, using existing standards where feasible and The Open
Group standards, extensions, or profiles where needed
 To support process automation, control strategies on multiple levels can be easily
integrated, without extensive integration services
 To support scalability, the Technical Architecture is designed such that the end user is
only required to buy the capability and capacity they need
 To support existing systems, the Technical Architecture does not require replacement of
existing instruments or wiring

1.3 Conformance
Part 1 of the O-PAS Standard is informative, and no conformance requirements have been
defined in this part. Normative requirements and conformance criteria are defined 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
For the purposes of the O-PAS Standard, the following terminology definitions apply:

Can Describes a possible feature or behavior available to the user or application.

May Describes a feature or behavior that is optional. To avoid ambiguity, the opposite of
“may” is expressed as “need not”, instead of “may not”.

Shall Describes a feature or behavior that is a requirement. To avoid ambiguity, do not

use “must” as an alternative to “shall”.

Shall not Describes a feature or behavior that is an absolute prohibition.

Should Describes a feature or behavior that is recommended but not required.

Will Same meaning as “shall”; “shall” is the preferred term.

2 The Open Group Preliminary Standard (2020)

1.6 Future Directions

A future version of the O-PAS Standard will address additional functionality such as platform-
independent applications and the hardware physical platform. See Chapter 7 for details on
planned future extensions. At that time, Part 1 and its contents will be revised and updated
accordingly.

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

2 Terms and Definitions

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

2.1 Terms
For the glossary of terms, see the definitions here.

4 The Open Group Preliminary Standard (2020)

3 Technical Architecture Concept Overview

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 device or software that is
conformant to a profile defined in the O-PAS Standard. The primary conformant components
described in this document are Distributed Control Nodes (DCNs) connected via the O-PAS
Connectivity Framework (OCF).

The OCF provides for determinism and quality of service required for data exchanges that are
sufficient to support a distributed control logic execution environment. An O-PAS system is a
collection of O-PAS conformant components all exchanging information using the OCF.

A DCN resides on a physical platform (see O-PAS Part 7 – Physical Platform) or a virtualized
platform conforming to the O-PAS profiles and optionally contains applications. A component
which does not have a conforming physical platform (for example, Distributed Control System
(DCS), Programmable Logic Controller (PLC), analyzer, etc.) may also conform to O-PAS
profiles and communicate using the OCF Communication Interface (OCI).

Applications are single indivisible components comprised of a program and associated

configuration and data that performs a set of coordinated and 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 OCI.

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 components.
On-Premise External Enterprise
OT Data Center OT Data Center IT Data Centers
(Executing IEC 62264 Level 2 & 3 Functions) (Executing IEC 62264 (Executing IEC 62264
Level 2 & 3 Functions) Level 4 Functions)
Advanced Computing Platform External Data Centers
Virtual Virtual Virtual may run physical or
Business Non O-PAS
DCN DCN DCN Virtual DCN virtual DCNs that are
Platf orm Environments
connected to the OCF
Application Application Application DCN
through a f irewall. OCI

Application Application Application Stand-alone

environments may be Business Platf orm
used f or f unctions such communicates
Application Application through Apps
as of f line engineering APP Legend
and simulation. running in a DCN,
not directly to the O-PAS
DCN Conformant
OCF
Component

O-PAS Connectivity Framework (OCF) Non O-PAS

Conformant
Component

APP APP APP APP APP

DCN
DCN

DCN

Virtual
DCN

DCN
DCN

APP APP DCN

DCN

DCN DCN Virtual

APP
Saf ety, DCN
OCI OCI Electrical, APP Field
& Machinery Network
Physical I/O: AI, AO, DI, DO, Twisted Pair, … DCS PLC DCS PLC Systems Analyzer Interface

Distributed Control Nodes (DCNs)

OCI – O-PAS Communication Interface
(Executing IEC 62264 Level 1, 2, & 3 Functions)
Figure 1: Concept Diagram of a Process Automation System of O-PAS Conformant Components

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

3.1 O-PAS Connectivity Framework (OCF)

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

While the OCF is shown as a single network in Figure 1, actual implementations will usually
consist of segmented networks in order to support security, performance, and quality of service
requirements.

3.2 Distributed Control Node (DCN)

A Distributed Control Node (DCN) is a type of conformant component that connects to the OCF.

DCN types include the following, possibly overlapping types:

 DCNs with physical I/O
 DCNs without physical I/O
 Virtual DCNs which execute DCN functionality within a computing environment
 Advanced Computing Platforms (ACPs)
An ACP is a computing platform which may implement multiple virtual DCN
functionalities with scalable computing resources (memory, disk, CPU cores) to handle
applications or services that require more resources than are typically available on a small
profile DCN.
ACPs may also be used for applications which cannot be easily or efficiently distributed.
The O-PAS Standard does not prevent additional functionality not defined in the standard
from being available in an ACP.
 Gateways
A DCN which provides OCF interoperability to a software component, device, or system,
which is not natively O-PAS conformant.
For example, a DCN acting as a gateway may be connected to a legacy DCS, legacy PLC,
smart device, Highway Addressable Remote Transducer (HART) device, Foundation
Fieldbus device, or a network of such devices.
 Equipment, such as DCSs, PLCs, analyzers, etc., containing an OCI are visible through
the OCF as if they were DCNs, even though they have different physical form factors

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, with
no excessive manual configuration to specify the role of the new DCN.

3.3 Application Types

An application is a single indivisible element comprised of a program and associated
configuration and data that performs a set of coordinated and related functions. Its three parts
can be represented graphically as illustrated in Figure 2.

6 The Open Group Preliminary Standard (2020)

Application

Configuration Program Data

Figure 2: Parts of an Application

The three contained boxes are:

 Configuration information: the parameters and initial settings for the program
 Program code: the instructions to be executed
 Data store: 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.1

Application F For example, Function Block

application using IEC 61131-3
structured text written by a
Configuration Program Data System Integrator or End User

Uses services & f eatures of Layer I

Application I For example, Function Block

and IEC 61131-3 ST execution
engines written by a
Configuration Program Data Software Supplier

Uses services & f eatures of Layer L

Application L For example, OPC UA Services

Component and database
services written by a
Configuration Program Data Software Supplier
If needed, additional layers above
and below the FILO listing can
Uses services & f eatures of Layer O
also be identified using alphabetic
ordering.
A B C D E F
Application O For example, UNIX O/S written
or ported by a Software or
G H I Hardware Supplier
J K L Configuration Program Data
M N O

Figure 3: FILO Model of Applications

Layer-F applications are those that are defined via the O-PAS configuration specifications
defined in the subparts of O-PAS Part 6 – Information and Exchange Models. 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 – Information and
Exchange Models: Basic Configuration. The Layer-F applications may also include Layer-F

1
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 to applications and services.

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

functions that follow the same configuration structure. These functions could be provided as
function block libraries that can be used in the construction of Layer-F applications or to build
additional Layer-F libraries.

Layer-I applications are defined in a typical IT programming language (such as C#, C++,
Python, GO, ADA, etc.). Layer-I applications commonly execute the Layer-F applications and
operate on the Layer-F configuration information. Layer-I applications are generally platform-
dependent, in that they have been compiled into a binary format for a specific CPU architecture
and O/S. 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++, Python, 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 O/S.

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

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

A system may contain equipment with O-PAS Communication Interface (OCI) functionality,
defined as a type of DCN in Section 3.2. This is equipment which does not conform to a DCN
hardware profile but does provide the capability of participating in OCF communication and
potentially hosting applications. Equipment with OCI functionality is visible through the OCF as
if it were DCNs. Possible examples are PCs, field instruments, DCSs, PLCs, analyzers, safety
systems, and electrical systems.

The OCI is a functional unit that provides a configurable interface to the OCF. It can be applied
to equipment other than DCNs.

The OCI services are defined in multiple places in the O-PAS Standard. Conformant
components using the OCI:
1. Support the interfaces defined in O-PAS Part 2 – Security
2. Participate in OCF communications using the services defined in O-PAS Part 4 – O-PAS
Connectivity Framework (OCF)
3. Support the System Management Interface defined in O-PAS Part 5 – System
Management
4. Support the Configuration Management Interface defined in O-PAS Part 6.1 –
Information and Exchange Models: Overview and Interfaces
5. Support basic configuration information defined in O-PAS Part 6.2 – Information and
Exchange Models: Basic Configuration

8 The Open Group Preliminary Standard (2020)

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

Connectivity to business software is through applications running in DCNs. 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.

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

4 O-PAS Interface Overview

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 subparts of
O-PAS Part 6 – Information and Exchange Models
 The download/upload formats for the Layer-F applications and configurations are
specified in the subparts of O-PAS Part 6 – Information and Exchange Models
 The dark blue interfaces to the components are specified in O-PAS Part 4 – O-PAS
Connectivity Framework Interface, O-PAS Part 5 – System Management, the subparts of
O-PAS Part 6 – Information and Exchange Models, and O-PAS Part 7 – Physical Platform
 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

10 The Open Group Preliminary Standard (2020)

Layer-F Application Editing Tools

Layer-F
Import/Export
Format Configuration Application System
Management Management Management
Services Services Services

Layer-F
Download/Upload
Information

DCN

Layer-F Applications/Configuration

Distributed
Control
Distributed
Layer-I Applications
Node Control
(DCN)
Distributed
Distributed
Node Control
(DCN)
Node (DCN)
Control
Node (DCN) Layer-L Applications/Services

Layer-O Applications/Services

OCF Networking Infrastructure Field Terminations

Blue Arrows = O-PAS Standard, Version 2.0 Specifications Folded corner figures represent
Red Arrows = Future Interface Specifications physical or virtual files

Figure 4: Principal Components and Interfaces

4.2 O-PAS Interfaces

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

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 defining the interface. The “cup” is
connected to the object or system using 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 “+”

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

Layer-F
Import/Export
Interface
Layer-F Application Editing Tools
Import/Export
Format Import/Export Conf iguration Application System
Interface Management Management Management
Services Services Services

Configuration Application
Management Management System
Interface Interface Management
(Layer-F Upload/Download) (start, stop, …) Interface

O-PAS
Connectivity
Other O-PAS Framework
Conformant Interface+
O-PAS
Components Conformant Component
O-PAS
Connectivity
Framework
Interface+
Physical Platform
Networking
Interface Physical Platform
Networking Interface

OCF Networking Infrastructure

The interf aces shown have the f ollowing meanings:
• Interf aces with “+” are network interf aces provided using OCF f unctionality
• Interf aces with solid lines indicate sof tware interf aces
• Interf aces with dashed lines and solid black circles indicate physical interf aces

Figure 5: O-PAS Defined Interfaces

The interfaces defined in the O-PAS Standard, Version 2.0 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
 The Application Management Interface defines the application management services used
to manage applications in an O-PAS conformant component by application management
services
 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 O/S software in an O-
PAS conformant component by system management tools
 The Platform Networking Physical Interface defines the physical layer interface to the
network

12 The Open Group Preliminary Standard (2020)

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 purposes of the two Layer-F formats are to allow basic DCN
configuration to be interoperable across different vendor implementations, and to provide a
common mechanism for communicating the information with 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.

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

1 Layer-F applications and

configuration defined using
Layer-F Import/Export Format configuration editing service
Configuration
Imported, modif ied, Editing 2
and exported Configuration management
Services
service selects information
to be downloaded to each component
Configuration
Read by Management
Services 3
Information downloaded in
5 Layer-F download format using
Configuration Configuration Management Interface
Run-time data exchanged using Management
corresponding OCF information models Interface
and OCF access methods
O-PAS 4
Conformant Component Downloaded data loaded into local
storage that is exposed using an
Connectivity OCF information model
Framework
Interface+
Local Data with
OCF Mapping
Connectivity
Framework
Interface+

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 to allow for real-time DCN communication in a system of components
from multiple vendors, the Connectivity Framework Interface is defined in O-PAS Part 4 –
Connectivity Framework Interface.

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

14 The Open Group Preliminary Standard (2020)

support, in this highly distributed environment requires common system management

functionality to be specified.

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

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

5 O-PAS Connectivity Framework (OCF)

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

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.

Distributed Control Node (DCN)

Layer-F Applications/Configuration

Layer-I Application
Data Access Route (Local)

Layer-L Application/Services

Layer-O Application/Services

Platf orm I/O

Physical Interf ace

Field Terminations

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.

16 The Open Group Preliminary Standard (2020)

Distributed Control Node (DCN)

Layer-F Application/Configuration
Distributed Control Node (DCN)
Layer-I Application

Data Access Route (Remote)

Layer-L Application/Services

Data Access

Data Access
Layer-O Application/Services

Platf orm Networking Platf orm Networking Platf orm I/O

Physical Interf ace Physical Interf ace Physical Interf ace

OCF Networking Network Data OCF Networking

Field Terminations
Infrastructure Access Route Infrastructure

Figure 8: Network Data Access Route

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

6 System Security

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, O/Ss, network devices
(switches, routers, etc.). See O-PAS Part 2 – Security for additional information. Specific
requirements for security functionality are defined in O-PAS Part 4 – O-PAS Connectivity
Framework (OCF) and O-PAS Part 5 – System Management.

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 meet the requirement to be able 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.

18 The Open Group Preliminary Standard (2020)

7 Planned Platform-Independent Application Interfaces

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 9 in black text are in Version 2.0, and the interfaces in gray text are planned for a future
version to support platform-independent Layer-I and Layer-L applications. Figure 9 is an
extension to Figure 5.

Import/Export Layer F Application Editing Tools

Layer-F Interface
Import/Export
Format Conf iguration Application System Security
Import/Export
Interface Management Management Management Management
Services Services Services Services

Configuration Application System Security

Management Interface Management Management Management
(using Layer-F Upload/Download Format) Interface Interface Interface
(start, stop, …)

O-PAS Conformant Component

Layer-F Applications/Configuration
O-PAS
Connectivity
Other O-PAS Framework Layer-I Applications
Interface+
Conformant Connectivity Application Configuration Security
Components Framework Services Information Services
Software Interface Interface Interface
O-PAS Interface
Connectivity
Framework Layer-L Applications/Services
Interface+
Platform
Service
Interface
DCP Networking
Physical Interface Layer-O Applications/Services

Platform Networking Platform I/O

Physical Interface Physical Interface

OCF Networking
Field Terminations
Infrastructure
The interf aces shown have the f ollowing meanings:
• Interf aces with “+” are network interf aces provided using OCF f unctionality
• Interf aces with solid lines indicate sof tware interf aces
• Interf aces with dashed lines and solid black circles indicate physical interf aces

Figure 9: 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.

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

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

Security
Management
Services

Security
Management
Interface

Distributed Control Node (DCN)

Layer-F Applications/Configuration

Layer-I Applications
Connectivity Application Configuration Security
Framework Services Information Services
Software Interface Interface Interface
Interface

Layer-L Applications/Services

Platform
Service
Interface

Layer-O Applications/Services

Platform I/O
Physical Interface

Field Terminations

• Interf aces with solid lines indicate sof tware interf aces
• Interf aces with dashed lines and solid black circles indicate physical
interf aces

Figure 10: Future Possible Application Interfaces

20 The Open Group Preliminary Standard (2020)

Figure 11 illustrates all of the Version 2.0 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
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

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

Layer-F Import/Export Format

Configuration Application Security

Management Management Management
Interface Interface Interface

Layer-F Application/Configuration
Layer-I Application
Connectivity Application Configuration Security
Framework Services Information Services
Software Interface Interface Interface Consumer of other services as needed
Interface

Connectivity Application Configuration Security Configuration Application Security

O-PAS Framework
Connectivity Software Services Information Services Management Management Management
Framework Interface Interface Interface Interface Interface Interface
Interface
Interface

Layer-L Applications/Services
O-PAS
Connectivity Platform
Framework Services
Interface Interface Consumer of other services as needed

Platform System Security

Services Management Management
Interface Interface Interface

Layer-O Applications/Services Protocol A/D, D/A

Conversion Conversion
Platform Networking Platform I/O
Physical Interface Physical Interface
Consumer of other services as needed

Figure 11: O-PAS Version 2.0 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.

22 The Open Group Preliminary Standard (2020)

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

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

Layer-F Configuration
Import/Export Used by Management
Format Services

Layer-F
Download/Upload
Format

Configuration
Management
Interface

O-PAS Conformant Component

Layer-I Application

Configuration
Information
Interface

Layer-L Services Internal

Data Store

Figure 12: Example of Configuration Information Flows

7.6 Platform Services Interface

The Platform Services Interface is a software interface that provides access to the underlying
O/S 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 hardware specification that defines the interface to I/O
termination points and specifies Size, Weight, and Power (SWaP) physical platform profiles.

The Platform I/O Physical Interface is a specification of the hardware interface to connect
physical I/O signals to a DCN. It will also be a specification of the hardware interface to connect
DCNs with and without I/O into a physical frame or backplane with power and network
connections.

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.

24 The Open Group Preliminary Standard (2020)

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.

The planned Platform I/O Physical Interface will define the following items:
 I/O termination standards, such that a standard removable terminal assembly will be
usable with any O-PAS conformant I/O module
 DCN form factor, such as SWaP requirements and heat duty
 DCN mounting structures, with power and network connections
 DCN I/O standard types

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 O/S services, services defined in the Application
Services Interface, services defined in the Configuration Information Interface, or services
defined in the OCI.

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

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

26 The Open Group Preliminary Standard (2020)

A Use-Cases

This appendix 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 13 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.

O-PAS Connectivity Framework (OCF)

APP APP
DCN
DCN

DCN

AI/AO/DI/DO
Twisted Pair

Figure 13: DCN-Only Configuration

A.1.2 DCNs and Legacy PLC

This is an example of a system with DCNs and a legacy PLC. Figure 14 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.

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

O-PAS Connectivity Framework (OCF)

APP APP

DCN
DCN

DCN
APP

DCN

PLC

AI/AO/DI/DO
Twisted Pair

Figure 14: 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 15 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.

O-PAS Connectivity Framework (OCF)

APP APP
DCN
DCN

DCN

APP

DCN

OCI
PLC
PLC
AI/AO/DI/DO
Twisted Pair

Figure 15: 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 16 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.

28 The Open Group Preliminary Standard (2020)

O-PAS Connectivity Framework (OCF)

APP APP

DCN
DCN

DCN

DCN
APP

DCN

Field
DCS Networks

AI/AO/DI/DO
Twisted Pair

Figure 16: 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 compliant components. In the example in Figure 17, 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.

Advanced Computing Platform

Virtual Virtual
DCN DCN

Application Application

O-PAS Connectivity Framework (OCF)

APP
DCN

DCN

DCN
DCN

OCI
Machinery Safety
PLC
DCS Monitoring Systems

AI/AO/DI/DO
Twisted Pair, …

Figure 17: Medium Size Brownfield Example

A.2.2 Medium Size Greenfield Example

In this example a new system is being built using O-PAS compliant components. In the example
in Figure 18, DCNs with and without I/O provide computing capability, other devices (such as

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

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.

Advanced Computing Platform

Virtual Virtual
DCN DCN

Application Application

OCF Connectivity Framework (OCF)

APP APP APP APP APP

DCN

Virtual Virtual Virtual Virtual Virtual

DCN

APP APP DCN APP

DCN DCN DCN DCN DCN
DCN DCN DCN APP APP APP APP APP
APP APP APP APP
APP Field
Machinery Network Safety Electrical
Analyzer Monitoring Interface System System
AI/AO/DI/DO AI/AO/DI/DO
Twisted Pair, … Twisted Pair, …

Figure 18: Medium Size Greenfield Example

A.2.3 Large Greenfield Example

In this example a new large system is being built using O-PAS compliant components. In the
example in Figure 19, 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 DCF 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.

30 The Open Group Preliminary Standard (2020)

On-Premise Enterprise External

OT Data Center IT Data Centers OT Data Center
(L2  L3 Functions) (L4 Functions) (L2  L3 Functions)

Advanced Computing Platform Business Platform

Transactional
Virtual Virtual Virtual DCNs
Computing Platf orm
DCN DCN

Application Application

Application Application
Business Platform communicates
APP to OPA Apps running in a DCF
using Ethernet, not the OCF
DCN

OCF Connectivity Framework (OCF)

APP APP APP APP APP

DCN

Virtual Virtual Virtual Virtual Virtual

DCN

APP APP DCN APP DCN DCN DCN DCN DCN

DCN DCN DCN APP APP APP APP APP
APP APP APP APP
APP Field
Machinery Network Safety Electrical
Analyzer Monitoring Interface System System
AI/AO/DI/DO AI/AO/DI/DO
Twisted Pair, … Twisted Pair, …

Figure 19: 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 20
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.

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

Layer-F Configuration Application System

Import/Export Used by Management Management Management
Format Services Services Services

Configuration Application System

Management Management Management
Interface Interface Interface
(start, stop, …)
Connectivity
Framework
Interface
Integrated Platform-Dependent Application
O-PAS Conformant Component
Connectivity
Framework
Interface
Platform Networking Proprietary I/O
Physical Interface Physical Interface

• Interf aces with solid lines indicate sof tware interf aces
• Interf aces with dashed lines and solid black circles indicate physical interf aces

Figure 20: 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 21, where the configuration information
includes a function block program, and a platform-dependent application provides a function
block execution environment.

32 The Open Group Preliminary Standard (2020)

Layer-F Import/Export Format

and Download/Upload Format
Configuration Application System
Used by Management Management Management
Services Services Services

Configuration Application System

Management Management Management
Interface Interface Interface
Connectivity
Framework
Interface Integrated Device with Layer-F Application Support
Layer-I Application
Connectivity
Framework
Interface

Platform Networking Proprietary Platform

Physical Interface I/O Interface

• Interf aces with solid lines indicate sof tware interf aces
• Interf aces with dashed lines and solid black circles indicate physical interf aces

Figure 21: Integrated Device with Layer-F Application Support

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

B Application Types and Layers

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

For example, Function Block

application using IEC 61131-3
structured text written by a
Application F Portable when built on a language defined in a
Layer-F import/export and download/upload
format.
System Integrator or End User Configuration Program Data

Uses services & f eatures of Layer I

For example, Function Block

and IEC 61131-3 ST execution
engine written by a
Application I May be ported if using the standard Layer-L
services only, or not portable if using unique
O/S services.
Software Supplier Configuration Program Data

Uses services & f eatures of Layer L

For example, OPC UA Services

Component and database
services written by a
Application L May be ported if using the Layer-O software
interface only, or not portable if using unique
O/S services.
Software Supplier Configuration Program Data

Uses services & f eatures of Layer O

For example, UNIX O/S written

or ported by a Software or
Hardware Supplier
Application O
Configuration Program Data

Figure 22: Example of Applications Layers

Figure 23 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® O/S provided by the platform supplier.

34 The Open Group Preliminary Standard (2020)

For example, Java Program

written by an End User
converted to Java Byte Code
Application F Portable when built on a language defined in
Java conformant syntax.

Configuration Program Data

Uses services & f eatures of Layer I

For example, JVM Execution

Engine written by a
Software Supplier
Application I May be ported if using the standard Layer-L
services only, or not portable if using unique
O/S services.
Configuration Program Data

Uses services & f eatures of Layer L

For example, Java libraries

and services written by a
Software Supplier
Application L May be ported if using the Layer-O software
interface only, or not portable if using unique
O/S services.
Configuration Program Data

Uses services & f eatures of Layer O

For example, UNIX O/S written

or ported by a Software or
Hardware Supplier
Application O
Configuration Program Data

Figure 23: Application Layering Using Java Example

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

Example Deployment Environments

Containers Virtual Environments
Native O/S
Apps/Libs Configuration Configuration
(Layer-F) (Layer-F) Configuration Configuration Configuration Configuration
Bare Metal App App
(Layer-F) (Layer-F) (Layer-F) (Layer-F)
Configuration Configuration
Apps/Libs (Layer-F) (Layer-F) (Layer-I) (Layer-I) App App App App
(Layer-I) (Layer-I) (Layer-I) (Layer-I)
App App Library Library
Configuration (Layer-I) (Layer-I) (Layer-L) (Layer-L) Library Library Library Library
(Layer-F)
(Layer-L) (Layer-L) (Layer-L) (Layer-L)
Library Framework Framework
App (Layer-L) (Layer-L) (Layer-L)
(Layer-I) Guest OS or RTOS Guest OS or RTOS
(Layer-O) (Layer-O)
Library Native OS or RTOS Native OS or RTOS
(Layer-L) (Layer-O) (Layer-O)
Hypervisor/Separation Kernel

UEFI Hardware
BOOT
BIOS Processor Memory Peripherals Network Interface

Derived from information provided by IIC – IISF (Industrial Internet Security Forum)

Figure 24: Example Deployment Environments for Applications

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

C Rationale

In order to provide a stable architecture which meets the requirement for a multiple decade life-
time, the architecture is defined to realize the quality attributes described below.

C.1 Interoperability
Interoperability is defined as the ability of two or more systems or components to exchange
information and to use the information that has been exchanged (ISO/IEC/IEEE 24765:2017). It
is achieved in the Technical Architecture through the OCF and associated information models
defined in the Layer-F import/export and download/upload formats.

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.

C.2 Modularity
Modularity is defined by 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 (ISO/IEC/IEEE 24765:2017). This is achieved using DCNs as the modular
architecture components:
 The architecture is defined such that DCNs can be replaced with equivalent DCNs,
without impacting the operation of other components
 The DCN architecture includes the virtual DCNs and platform-independent applications;
this allows applications to be changed and moved without impact on other components
 The concept of “profiles” is used to define DCNs as the components of modularity, such
that components with the same profiles from different vendors have the same minimal
functionality
 The DCN architecture is defined such that components can be replaced with equivalent
conformant components, without impacting other parts of the system

C.3 Standard Conformance

Standard conformance is defined as developing or certifying components to meet all normative
requirements of the published Standard. 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 compliance tests are met to
provide evidence of conformance.

36 The Open Group Preliminary Standard (2020)

C.4 Scalability
Scalability is defined as the degree to which a system can have its capacities adjusted to meet
system requirements. 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.

C.5 Portability
Portability is defined as the ease with which a system or component can be transferred from one
hardware or software environment to another (ISO/IEC/IEEE 24765:2017). In this document,
portability is defined as platform-independence. It is achieved through the Layer-F import/export
and download/upload format specifications.

C.6 Technology Support

It is expected that network communication standards will be the longest living interoperability
element, therefore the Technical Architecture is defined such that DCNs and embedded OCIs,
implemented with original technology mappings (such as Ethernet IP, 5G, Wi-Fi) can easily be
integrated with newer technology mappings through communication gateways.

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

D Abbreviations

For the glossary of abbreviations, see the definitions here.

38 The Open Group Preliminary Standard (2020)

Index
ACP ...................................................... 6 Layer-F import/export ........................ 13
ANSI/ISA 62443 standards .................. 9 Layer-I applications ............................. 8
application ............................................ 7 Layer-L applications ............................ 8
Application Management Interface .... 14 Layer-O applications ............................ 8
Application Services Interface ........... 23 maintainability ..................................... 1
applications......................................... 34 MRP ..................................................... 9
business functions................................. 9 OCF ............................................ 5, 6, 16
components......................................... 10 OCI ................................................... 5, 8
concept diagram ................................... 5 OT data center ...................................... 9
Configuration Information Interface .. 23 Platform I/O Physical Interface .......... 24
Configuration Management Interface . 14 Platform Services Interface ................ 24
conformance ......................................... 2 platform-dependent applications ........ 25
Connectivity Framework Interface ..... 14 platform-independent interfaces ......... 19
Connectivity Framework Software PLC ...................................................... 5
Interface ......................................... 23 PLM ..................................................... 9
DCN ................................................. 5, 6 process automation ............................... 2
DCS ...................................................... 5 reliability .............................................. 1
ERP ...................................................... 9 resilience .............................................. 1
FILO ..................................................... 7 safety .................................................... 1
gateway ................................................ 6 scalability ............................................. 2
IIC ...................................................... 35 SCM ..................................................... 9
interfaces ...................................... 10, 11 security ........................................... 2, 18
interfaces, planned .............................. 22 Security Management Interface ......... 22
interoperability ..................................... 2 Security Services Interface ................. 23
JVM .................................................... 34 SWaP.................................................. 24
Layer-F applications ............................. 8 System Management Interface ........... 14
Layer-F download/upload .................. 13 Technical Architecture ......................... 1
Layer-F formats .................................. 13 UML ................................................... 11

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

Complete Java Notes
No ratings yet
Complete Java Notes
154 pages
Rest Web Services
100% (1)
Rest Web Services
121 pages
Unifier Integration Interface
No ratings yet
Unifier Integration Interface
646 pages
Data Analyst, CareConnect
No ratings yet
Data Analyst, CareConnect
2 pages
Rishabh - Mishra - Resume - Template
No ratings yet
Rishabh - Mishra - Resume - Template
1 page
Test Your Skills in Python
No ratings yet
Test Your Skills in Python
308 pages
Procurement Impl Rel10 StudentGuide
No ratings yet
Procurement Impl Rel10 StudentGuide
577 pages
Stakeholder and Financial Reporting
No ratings yet
Stakeholder and Financial Reporting
3 pages
CorpF Revise
No ratings yet
CorpF Revise
5 pages
DataStax Ebook The 5 Main Benefits of Apache Cassandra PDF
100% (1)
DataStax Ebook The 5 Main Benefits of Apache Cassandra PDF
12 pages
Tristan Needham, Roger Penrose - Visual Complex Analysis - 25th Anniversary Edition-Oxford University Press (2023)
No ratings yet
Tristan Needham, Roger Penrose - Visual Complex Analysis - 25th Anniversary Edition-Oxford University Press (2023)
720 pages
Conso Sugar
No ratings yet
Conso Sugar
4 pages
RESTFUL Web Services and Their Use in Telecommunications
No ratings yet
RESTFUL Web Services and Their Use in Telecommunications
46 pages
Gaffneycline Mature Field Optimisation Brochure
No ratings yet
Gaffneycline Mature Field Optimisation Brochure
7 pages
Individual Assignment
No ratings yet
Individual Assignment
22 pages
Applied Microsoft Analysis Services 2005
100% (1)
Applied Microsoft Analysis Services 2005
713 pages
Hawkinge Employment Contract
No ratings yet
Hawkinge Employment Contract
7 pages
Rir'Z/: Department of Public Works and Highways
No ratings yet
Rir'Z/: Department of Public Works and Highways
2 pages
Kscope19 - Essbase Deep Dive - Block Creation
No ratings yet
Kscope19 - Essbase Deep Dive - Block Creation
24 pages
Tigar Isya Prasta - 6101619074
No ratings yet
Tigar Isya Prasta - 6101619074
7 pages
Before Spark Interview
No ratings yet
Before Spark Interview
18 pages
Content-Whale Private Limited - Wise - Transaction - Invoice - Transfer - 1406879431 - 4796372668 - en
No ratings yet
Content-Whale Private Limited - Wise - Transaction - Invoice - Transfer - 1406879431 - 4796372668 - en
2 pages
Paper 4
No ratings yet
Paper 4
3 pages
BGP Mind - Map Part
No ratings yet
BGP Mind - Map Part
7 pages
Power Iaas
No ratings yet
Power Iaas
227 pages
Indian Standard Designation of Steels
75% (4)
Indian Standard Designation of Steels
1 page
Negotiation Skills-Chapter 3: Prof. Ouijdane Iddoub 2018-2019
No ratings yet
Negotiation Skills-Chapter 3: Prof. Ouijdane Iddoub 2018-2019
12 pages
3.snowflake Architecture
No ratings yet
3.snowflake Architecture
8 pages
Paleo Vegetarian Diet
No ratings yet
Paleo Vegetarian Diet
1 page
IBM Power Virtual Server Guide For IBM AIX and Linux
100% (1)
IBM Power Virtual Server Guide For IBM AIX and Linux
204 pages
Chapter 2: Literature Review
No ratings yet
Chapter 2: Literature Review
3 pages
The Definitive Guide To Modern Network Decryption
No ratings yet
The Definitive Guide To Modern Network Decryption
36 pages
Maintain Cubes - Document 2136813.1
No ratings yet
Maintain Cubes - Document 2136813.1
4 pages
Issue 67 Full
No ratings yet
Issue 67 Full
108 pages
Synergetics Inc Leased A New Crane To M K Gumowski
No ratings yet
Synergetics Inc Leased A New Crane To M K Gumowski
1 page
CH3 Numerical Problems
No ratings yet
CH3 Numerical Problems
9 pages
Evaluate Enterprise Architecture Frameworks Using Essential Elements
100% (1)
Evaluate Enterprise Architecture Frameworks Using Essential Elements
31 pages
Student Guide
No ratings yet
Student Guide
231 pages
JDK, JVM and JRE
No ratings yet
JDK, JVM and JRE
11 pages
WHT Certificate
No ratings yet
WHT Certificate
1 page
BICC
No ratings yet
BICC
2 pages
Placement
No ratings yet
Placement
4 pages
"Slow Is Smooth. Smooth Is Fast." - by George Morris - Medium
No ratings yet
"Slow Is Smooth. Smooth Is Fast." - by George Morris - Medium
12 pages
AJM Journal Latest Issue
No ratings yet
AJM Journal Latest Issue
134 pages
AWS Account: Virtual Private Cloud (VPC)
No ratings yet
AWS Account: Virtual Private Cloud (VPC)
3 pages
Az900 Dump
No ratings yet
Az900 Dump
18 pages
ArchiMate Modeling Language
No ratings yet
ArchiMate Modeling Language
194 pages
Business Statistics: Shweta Iyer BFM-1 College of Fashion Design and Merchandising
No ratings yet
Business Statistics: Shweta Iyer BFM-1 College of Fashion Design and Merchandising
29 pages
System Programming Concept
No ratings yet
System Programming Concept
175 pages
OLM - Implementation Guide - 120olmig
No ratings yet
OLM - Implementation Guide - 120olmig
62 pages
VPC-Neal Davis
No ratings yet
VPC-Neal Davis
18 pages
Designing Enterprise Architecture Using TOGAF Arch
No ratings yet
Designing Enterprise Architecture Using TOGAF Arch
9 pages
Linux Architecture
No ratings yet
Linux Architecture
6 pages
Onion Pi: Created by Lady Ada
No ratings yet
Onion Pi: Created by Lady Ada
19 pages
Fusion - Roles Concept in Fusion Application
No ratings yet
Fusion - Roles Concept in Fusion Application
3 pages
Pfhomologation
No ratings yet
Pfhomologation
31 pages
IPsec (Internet Protocol Security) - Network
No ratings yet
IPsec (Internet Protocol Security) - Network
20 pages
Artificial Intelligence The Time To Act Is Now - McKinsey
No ratings yet
Artificial Intelligence The Time To Act Is Now - McKinsey
12 pages
Design Thinking Stanford
No ratings yet
Design Thinking Stanford
36 pages
Process Groups Full
No ratings yet
Process Groups Full
1 page
Data Streams: Models and Algorithms
No ratings yet
Data Streams: Models and Algorithms
372 pages
Extending Oracle Fusion SaaS With OCI
No ratings yet
Extending Oracle Fusion SaaS With OCI
10 pages
PRTC HOs List
No ratings yet
PRTC HOs List
4 pages
Value Chain Analysis PDF
No ratings yet
Value Chain Analysis PDF
7 pages
Awsclf-C02studyguide Hirokonishimura 12 2023
No ratings yet
Awsclf-C02studyguide Hirokonishimura 12 2023
10 pages
SQLSentry - Optimizing SSAS
No ratings yet
SQLSentry - Optimizing SSAS
18 pages
Amazon CLF c02 Dumps by Lamb 04 10 2023 11qa Ebraindumps
No ratings yet
Amazon CLF c02 Dumps by Lamb 04 10 2023 11qa Ebraindumps
20 pages
VPC Dark
No ratings yet
VPC Dark
1 page
Maven Essentials - Sample Chapter
No ratings yet
Maven Essentials - Sample Chapter
19 pages
Instant Node Package Manager
From Everand
Instant Node Package Manager
Juzer Ali
2/5 (2)
Snowflake Database Structures and DML - Snowflake
No ratings yet
Snowflake Database Structures and DML - Snowflake
50 pages
Instant Jsoup How-to
From Everand
Instant Jsoup How-to
Pete Houston
No ratings yet
Implementation of Webservices Ex - No:: D Aim
No ratings yet
Implementation of Webservices Ex - No:: D Aim
14 pages
Snowflake Latest 231
No ratings yet
Snowflake Latest 231
44 pages
Exercises On Introduction To Cost Accounting
100% (1)
Exercises On Introduction To Cost Accounting
4 pages
ANSWER KEY Discounted Cash Flow Method
No ratings yet
ANSWER KEY Discounted Cash Flow Method
10 pages
Successful Project Management in the Digital Age: Learn simple steps to succeed within a day
From Everand
Successful Project Management in the Digital Age: Learn simple steps to succeed within a day
Natarajan Thangaraju
No ratings yet
The Critical Scrutiny of TOGAF
No ratings yet
The Critical Scrutiny of TOGAF
9 pages
Journey To Enterprise Agility
No ratings yet
Journey To Enterprise Agility
1 page
Learning Apache Cassandra - Sample Chapter
No ratings yet
Learning Apache Cassandra - Sample Chapter
20 pages
Essbase Coding Standards
No ratings yet
Essbase Coding Standards
21 pages
Partnership
No ratings yet
Partnership
24 pages
A Comparative Study On Supply Chain Management With Reference To Himalaya and Dabur'
No ratings yet
A Comparative Study On Supply Chain Management With Reference To Himalaya and Dabur'
26 pages
WP Togaf Bian Rev4 en
No ratings yet
WP Togaf Bian Rev4 en
41 pages
CFO Insights:social Analytics: Tapping Prediction Markets For Foresight
No ratings yet
CFO Insights:social Analytics: Tapping Prediction Markets For Foresight
4 pages
Hyperion Essbase Interview Questions
No ratings yet
Hyperion Essbase Interview Questions
7 pages
Finance Interview Questions
No ratings yet
Finance Interview Questions
15 pages
Maximize Your Investment: 10 Key Strategies for Effective Packaged Software Implementations
From Everand
Maximize Your Investment: 10 Key Strategies for Effective Packaged Software Implementations
Grady Brett Beaubouef
No ratings yet
Shielded Metal Arc Welding of Carbon Steel (M-1/P-1/S-1, Group 1 or 2), 1/8 Through 1-1/2 Inch Thick, E7018, As-Welded or PWHT Condition
100% (4)
Shielded Metal Arc Welding of Carbon Steel (M-1/P-1/S-1, Group 1 or 2), 1/8 Through 1-1/2 Inch Thick, E7018, As-Welded or PWHT Condition
25 pages
Instant Pentaho Data Integration Kitchen
From Everand
Instant Pentaho Data Integration Kitchen
Sergio Ramazzina
No ratings yet