The Open Process Automation Standard takes flight

Fast Forward

A detailed look at O-PAS™ Standard, Version 1.0

By Dave Emerson

Process automation end users and suppliers have expressed interest in a standard that will make the industry much more open and modular. In response, the Open Process Automation™ Forum (OPAF) has worked diligently at this task since November 2016 to develop process automation standards. The scope of the initiative is wide-reaching, as it aims to address the issues associated with the process automation systems found in most industrial automation plants and facilities today (figure 1).

It is easy to see why a variety of end users and suppliers are involved in the project, because the following systems are affected:

In June 2018, OPAF released a technical reference model (TRM) snapshot as industry guidance of the technical direction being taken for the development of this new standard. The organization followed the TRM snapshot with the release of the OPAS™ Version 1.0 in January 2019. Version 1.0 addresses the interoperability of components in federated process automation systems. This is a first stop along a three-year road map with annual releases targeting the themes listed in table 1.

Table 1. The O-PAS Standard three-year release road map addresses progressively more detailed themes.

Version

Target date

Theme

1.0

2019

Interoperability

2.0

2020

Configuration portability

3.0

2021

Application portability

By publishing versions of the standard annually, OPAF intends to make its work available to industry expeditiously. This will allow suppliers to start building products and returning feedback on technical issues, and this feedback-along with end user input-will steer OPAS development. O-PAS Version 1.0 was released as a preliminary standard of The Open Group to allow time for industry feedback.

The OPAF interoperability workshop in May 2019 is expected to produce feedback to help finalize the standard. The workshop allows member organizations to bring hardware and software that support O-PAS Version 1.0, testing it to verify the correctness and clarity of this preliminary standard. The results will not be published but will be used to update and finalize the standard.

Figure 1. A broad sampling of suppliers and end users are highly interested in the scope of the OPAS under development by OPAF, because it touches on all the key components of industrial automation systems: hardware (I/O), the communication network, system software (e.g., run time, namespace), application software, and the data model. 

For clarity, a summary of the terminology associated with the OPAF initiative is:

Creating a "standard of standards" for open, interoperable, and secure automation is a complex undertaking. OPAF intends to speed up the process by leveraging the valuable work of various groups in a confederated manner.

The OPAS Standard will reference existing and applicable standards where possible. Where gaps are identified, OPAF will work with associated organizations to update the underlying standard or add OPAS requirements to achieve proper definition. Therefore, OPAF has already established liaison agreements with the following organizations:

Additionally, OPAF is in discussions with AutomationML and the ISA Security Compliance Institute (ISCI) as an ISA/IEC 62443 validation authority. In addition to these groups, the OPC Foundation has joined OPAF as a member, so no liaison agreement is required.

As an example of this cooperation in practice, OPAS Version 1.0 was created with significant input from three existing standards, including:

Configuration portability, now under development for OPAS Version 2.0, will address the requirement to move control strategies among different automation components and systems. This has been identified by end users as a requirement to allow their intellectual property (IP), in the form of control strategies, to be portable. Existing standards under evaluation for use in Version 2.0 include:

O-PAS Version 3.0 will address application portability, which is the ability to take applications purchased from software suppliers and move them among systems within a company in accordance with applicable licenses. This release will also include the first specifications for hardware interfaces.

The five parts that make up O-PAS Version 1.0 are listed below with a brief summary of how compliance will be verified (if applicable):

Part 1 - Technical Architecture Overview (informative) describes an OPAS-conformant system through a set of interfaces to the components. Read this section to understand the technical approach OPAF is following to create the O-PAS.

Part 2 - Security (informative) addresses the necessary cybersecurity functionality of components that are conformant to OPAS. It is important to point out that security is built into the standard and permeates it, as opposed to being bolted on as an afterthought. This part of the standard is an explanation of the security principles and guidelines that are built into the interfaces. More specific security requirements are detailed in normative parts of the standards. The detailed normative interface specifications are defined in Parts 3, 4, and 5. These parts also contain the associated conformance criteria.

Part 3 - Profiles  defines sets of hardware and software interfaces for which OPAF will develop conformance tests to make sure products interoperate properly. The O-PAS Version 1 profiles are:

The term "Level" in the profile names refers to profile levels.

Part 4 - Connectivity Framework (OCF) forms the interoperable core of the system. The OCF is more than just a network, it is the underlying structure allowing disparate components to interoperate as a system. The OCF will use OPC UA for OPAS Versions 1.0, 2.0, and 3.0.

Part 5 - System Management covers foundational functionality and interface standards to allow the management and monitoring of components using a common interface. This part will address hardware, operating systems and platform software, applications, and networks-although at this point Version 1.0 only addresses hardware management.

Conformance criteria are identified by the verb "shall" within the O-PAS text. An OPAF committee is working on a conformance guide document that will be published later this year, which explains the conformance program and requirements for suppliers to obtain a certification of conformance.

The OPAS Standard supports communication interactions that are required within a service-oriented architecture (SOA) for automation systems by outlining the specific interfaces the hardware and software components will use. These components will be used to architect, build, and start up automation systems for end users.

The vision for the OPAS Standard is to allow the interfaces to be used in an unlimited number of architectures, thereby enabling each process automation system to be "fit for purpose" to meet specific objectives. The standard will not define a system architecture, but it will use examples to illustrate how the component-level interfaces are intended to be used. System architectures (figure 2) contain the following elements:

Distributed control node (DCN): A DCN is expected to be a microprocessor-based controller, I/O, or gateway device that can handle inputs and outputs and computing functions. A key feature of O-PAS is that hardware and control software are decoupled. So, the exact function of any single DCN is up to the system architect. A DCN consists of hardware and some system software that enables the DCN to communicate on the O-PAS network, called the OCF, and also allows it to run control software.

Distributed control platform (DCP): A DCP is the hardware and standard software interfaces required in all DCNs. The standard software interfaces are a common platform on top of which control software programs run. This provides the physical infrastructure and interchangeability capability so end users can control software and hardware from multiple suppliers.

Distributed control framework (DCF): A DCF is the standard set of software interfaces that provides an environment for executing applications, such as control software. The DCF is a layer on top of the DCP that provides applications with a consistent set of O-PAS related functions no matter which DCN they run in. This is important for creating an efficient marketplace for O-PAS applications.

OPAS connectivity framework (OCF): The OCF is a royalty-free, secure, and interoperable communication framework specification. In O-PAS Version 1, the OCF uses OPC UA.

Advanced computing platform (ACP): An ACP is a computing platform that implements DCN functionality but has scalable computing resources (memory, disk, CPU cores) to handle applications or services that require more resources than are typically available on a small profile DCP. ACPs may also be used for applications that cannot be easily or efficiently distributed. ACPs are envisioned to be installed within on-premise servers or clouds.

Within the OPAS Standard, DCNs represent a fundamental computing building block (figure 3). They may be hardware or virtual (when virtual they are shown as a DCF as in figure 2), big or small, with no I/O or various amounts. At the moment, allowable I/O density per DCN is not settled, so some standardization in conjunction with the market may drive the final configuration.

DCNs also act as a gateway to other networks or systems, such as legacy systems, wireless gateways, digital field networks, I/O, and controllers like DCS or PLC systems. Industrial Internet of Things (IIoT) devices can also be accessed via any of these systems.

Figure 2. OPAS establishes a system architecture organizing process automation elements into interoperable groupings.

End users today must work with and integrate multiple systems in most every process plant or facility. Therefore, the OPAS Standard was designed so users can construct systems from components and subsystems supplied by multiple vendors, without requiring custom integration. With the OPAS Standard it becomes feasible to assimilate multiple systems, enabling them to work together as one OPAS-compliant whole. This reduces work on capital projects and during the lifetime of the facility or plant, leading to a lower total cost of ownership.

By decoupling hardware and software and employing an SOA, the necessary software functions can be situated in many different locations or processors. Not only can software applications run in all hardware, but they can also access any I/O to increase flexibility when designing a system.

One set of components can be used to create many different systems using centralized architectures, distributed architectures, or a hybrid of the two. System sizes may range from small to large and can include best-in-class elements of DCS, PLC, SCADA, and IIoT systems and devices as needed.

Information technology (IT) can also be incorporated deeper into industrial automation operational technology (OT). For example, DMTF Redfish is an IT technology for securely managing data center platforms. OPAF is adopting this technology to meet OPAS system management requirements.

Each industrial automation supplier offers a variety of devices and systems, most of which are proprietary and incompatible with similar products from other vendors and sometimes with earlier versions of their own products. End users and system integrators trying to integrate automation systems of varying vintages from different suppliers therefore have a challenging job.

To address these issues, OPAF is making great strides toward assembling a comprehensive, open process automation standard. Partially built on other established industry standards, and extending to incorporate most aspects of industrial automation, the O-PAS Standard will greatly improve interoperability among industrial automation systems and components. This will lower implementation and support costs for end users, while allowing vendors to innovate around an open standard.

For more information on OPAS Version 1.0, please download the standard at https://publications.opengroup.org/p190. Submit feedback by emailing ogspecs@opengroup.org. 

Figure 3. DCNs are conceived as modular elements containing DCP (hardware) and DCF (software), both of which are used to interface field devices to the OCF.

We want to hear from you! Please send us your comments and questions about this topic to InTechmagazine@isa.org.

Smart Africa and The Open Group Join Forces to Formulate a Government Enterprise Architecture Guide for Africa

KIGALI, Rwanda — In a significant stride toward advancing its digital economy initiatives, the Smart Africa alliance and The Open Group have signed a Memorandum of Understanding (MoU) to develop a unified Enterprise Architecture guide for the African continent.

Article content

By working together, The Open Group and the Smart Africa alliance will aim to promote, guide, and build capabilities on the development of a cohesive Government Enterprise Architecture framework. Both organizations will collaborate to conduct a nationwide survey and host focus groups to comprehensively grasp the present status of Government Enterprise Architecture within the member states.

Article content

They will also jointly devise a strategy for enhancing capabilities and proposing targeted actions pertaining to Government Enterprise Architecture and associated domains to foster capacity development.

This partnership emphasizes the Smart Africa central objective to pave the way for a unified single digital market.

Commenting on the partnership, Mr. Lacina Koné, CEO of Smart Africa, highlighted: “Another key step towards achieving a single digital market in Africa has been made by joining forces with The Open Group today to build a Government Enterprise Architecture guide for the continent. This is another testament of our multi-stakeholder approach.”

“Global collaboration is at the heart of The Open Group, and we’re delighted to be partnering with Smart Africa to advance digital transformation practices on the continent. Our partnership will bring together the collective expertise of our Members as we aim to accentuate architecture-based approaches to digital transformation in order to form a single, open, digital market,” said Steve Nunn, President and CEO of The Open Group.

This strategic partnership is a milestone in the ongoing commitment of both organizations to propel the digital transformation journey of the African continent. The collaboration will leverage their collective expertise, resources, and networks to create a significant and lasting impact on the region.

About Smart Africa

Smart Africa is an alliance of 39 African countries, international organisations and global private sector players tasked with Africa’s digital agenda. The alliance is empowered by a bold and innovative commitment by African Heads of State to accelerate sustainable socio-economic development on the continent and usher Africa into the knowledge economy through affordable access to broadband and the use of ICTs. With a vision to create a single digital market in Africa by 2030, the Smart Africa Alliance brings together Heads of State who seek to accelerate the digitalization of the continent and create a common market. Launched in 2013 by seven (7) African Heads of State, the Alliance now has 39 member countries, representing over 1 billion people and over 50 Private Sector members committed to the vision and the advancement of Africa. (Partners of the Smart Africa Alliance include the African Union, the ITU, World Bank, the African Development Bank, the United Nations Economic Commission of Africa, the GSMA, ICANN and Companies.)

Share this article in your social network

Architecture Research Group

The Architectural Research Group (ARG) utilises highly innovative methods to deliver excellence in teaching, research and best practice development. Using a multidisciplinary approach, the ARG is composed of four highly specialised design led research clusters across design, arts & humanities, social & environmental science, practice & architectural technology.

This enables more robust design solutions to meet tomorrow challenges along with delivering the skills industry is asking for today.