PTQ Q2 2026 Issue

On-Premise OT Data Centre

External OT Data Centre

Enterprise IT Data Centres / Cloud

O-PAS conformant component O-PAS conformant component

Advanced Computing Platform

Business platform

Non O-PAS Environments

Virtual DCN

OCI

Application

DCN

Firewall

Application Application

Application

APP DCN

Application

Firewall

O-PAS Connectivity Framework (OCF)

DCN

Virtual DCN

DCN

APP APP DCN

APP DCN

DCN

Virtual DCN

APP

Safety, electrical & machinery systems

Field Network Interface

OCI

APP Analyser

DCS

PLC

DCS

PLC

Distributed Control Nodes (DCNs) Physical I/O: AI, AO, DI, DO, Twisted Pair, ......

OCI – O-PAS Communication Interface

Figure 4 O-PAS reference architecture is a hybrid system able to incorporate legacy products, along with compliant and even non-compliant products

computing functions. With hardware and control software decoupled, a system architect can design the specific func - tion of a particular DCN. Using a combination of hardware and system software, a DCN can communicate on the OCF and run control software. Since a DCN can be hardware or virtual, a given system can use any number of DCNs. Today’s cybersecurity threats are always evolving, so O-PAS has incorporated a ‘secure by design’ approach that differs greatly from the ‘defence in depth’ approach required with a traditional DCS. For example, secure device onboard- ing, role-based access, and certificate-based encrypted communications are part of an O-PAS-deployed system. Listening to user feedback Successful standard writing depends on input from the vendor’s adoption and the end user’s implementation. Consequently, OPAF committees are continually gathering feedback from a wide range of sources. This has enabled the organisation to identify high-priority feature sets, with ongoing discussions about their value and effort require- ments. The forum continues to receive feedback based on OPA implementations from end users (such as ExxonMobil, Petronas, Petrobras, Reliance) and system integrators and engineering firms (such as Yokogawa, Wood, COPA). These are prioritised, with requirements and directions set for future development in the technical working group. Several major items on the docket now include: • Standardised I/O services: Currently, I/O device configu - ration requires a proprietary tool from each vendor, so if two different vendor devices are used in a project, two very dif- ferent configuration tools are needed. There is a need for a standardised application programming interface (API) that can enable a vendor-agnostic tool to be developed, provid- ing seamless interchangeability of OPA I/O hardware. This is critical to achieve true interoperability and interchangea- bility within O-PAS.

• New OPC UA alarm profiles: Create new profiles in Part 6.3, which require optional conformance units related to alarm properties (such as different timestamps and state information), resulting in improved interoperability and interchangeability of alarm system products. • OCF Client Profile: In O-PAS, a profile is a documented set of conformance requirements defining the capabilities a product must support to be certified. Currently, there are several profiles for servers (such as OPC UA and Redfish) defined throughout various parts of the standard and sum - marised in Part 3. OPAF is planning to transform the current OCF Client Facet into an OCF Client Profile and investigate where additional profiles, facets, and conformance units may be needed. • Alias monitoring: O-PAS implementation requires the use of OPC UA aliases (defined in OPC 10000-17) for O-PAS signal data types and function blocks. An implementation gap is caused by a lack of documentation for the proper use of OPC UA aliases and for notifications of changes and updates. For example, client applications frequently require multiple queries to resolve alias names within the Global Discovery Server (GDS), and there is no clear method for notifying them when an alias has been deleted or changed. This issue was presented to the OPC Foundation, and its working group is addressing the problem. • Operational status: Currently, there is no standardised method that provides visibility into the operational status of an O-PAS engine. This can only be achieved with a propri- etary vendor-supplied engineering tool. The working group is developing a state model for the I/O, function blocks, and alarm engines, with interfaces to change state, take actions, and report diagnostic information. The interface should also provide information about the engine status, such as idle, initialise, running, stopped, and other states. The current information model of the O-PAS engines is in Part 6.2.

PTQ Q2 2026