Representative End User Clients
Representative Automation Clients
Representative Software Clients
SMAR, a Global Silver Sponsor of ARC Advisory Group’s 24th Annual ARC Industry Forum in Bengaluru, was represented by Octávio Paschoal, Electronic Intelligence Agent. In his presentation, Software Defined Applications in O-PAS Architectures, Paschoal explored how the Open Process Automation Standard (O-PAS) can support a broader software-defined application ecosystem, allowing developers and end users to create new industrial functionality without tying applications as closely to specific hardware platforms.
At the center of this approach is the separation of interfaces from implementation. O-PAS defines how components interact and exchange information, while leaving developers greater freedom to determine the functionality implemented within those components. Paschoal argued that this principle creates opportunities to extend O-PAS beyond conventional process-control applications into more specialized industrial functions.
Two examples highlighted this potential: a software-defined flow computer developed for oil flow measurement and a user-defined function block approach designed to give users greater flexibility to create their own O-PAS-compliant applications.
Paschoal’s presentation can be viewed on YouTube or here:
O-PAS as a Software-Defined Application Ecosystem
Hardware and software decoupling is a fundamental part of the O-PAS approach.
The O-PAS Standard defines interfaces intended to support interchangeability, interoperability, portability, and modularity. While the functionality required by an interface is defined, how an individual component provides that functionality is left to the designer.
This distinction creates an important foundation for software-defined automation. Standardized interfaces establish how components connect and communicate, while developers retain greater flexibility over the algorithms and capabilities operating behind those interfaces.
O-PAS also provides standardized mechanisms for information exchange between components. Applications can therefore combine different functions within an open architecture while configuration, orchestration, and runtime environments manage how those components are deployed and executed.
The result is an application environment in which standardization does not necessarily mean prescribing every element of the underlying functionality.
Moving Beyond Traditional Process Control
Many industrial O-PAS applications today remain focused on familiar process-control functions, including standard analog and discrete function blocks. Compatibility mechanisms can also help bring function blocks and functionality associated with legacy control applications into an O-PAS environment.
Paschoal positioned these applications as an important starting point, but not necessarily the limit of what the architecture can support.
If O-PAS standardizes interfaces without defining the algorithms behind them, developers can potentially use the same architecture for specialized industrial applications that have traditionally depended on dedicated automation systems.
Flow computing provides one example.
Flow computers are used for fiscal metering and custody transfer applications, where measurement accuracy is particularly important because the measurements can determine the value of commercial transactions. They use specialized, standardized algorithms based on requirements from organizations and standards such as ISO and API.
Conventional flow computers are also relatively difficult to scale. A measurement stream will typically require a dedicated flow computer, meaning that the number of systems and associated costs can increase as additional streams are added.
O-PAS offers a different architectural possibility. Containerized applications can be replicated across distributed control nodes, while the standard defines the interfaces surrounding the application rather than the algorithm itself.
This led Nova SMAR to explore whether the functionality of a flow computer could be implemented as a software-defined application within an O-PAS architecture.
Testing a Software-Defined Flow Computer
Nova SMAR developed a proof of concept for oil flow measurement based on an end-user requirement.
The validation compared an O-PAS flow-computer structure, consisting of a DCN IO Engine and DCN Flow App, with a certified HFC302 flow computer. The two implementations were evaluated by comparing instantaneous calculated flow, correction factors, and longer-term totalization results.
According to Nova SMAR, the proof of concept produced matching instantaneous flow and correction-factor calculations, with a long-term totalization error of approximately 0.0025 percent.
Nova SMAR compared an O-PAS-based flow-computer implementation with a certified HFC302 flow computer as part of an oil-flow measurement proof of concept
The example demonstrates the potential to move specialized industrial calculations away from dedicated systems and toward software-defined applications that can operate within a scalable open architecture.
However, the work remains under development. Nova SMAR’s roadmap includes completing validation using a real stream, developing additional function blocks for gas-flow metering and proving, and addressing flow-computer function-block certification requirements associated with local regulations.
Giving Users More Freedom to Develop Applications
Paschoal’s second example focused on the User Defined Function Block (UDFB).
O-PAS implementations can already include vendor runtimes, execution engines, and function-block libraries. The UDFB concept addresses situations in which an end user or developer requires functionality that is not available in an existing library.
Nova SMAR is developing an integrated Function Block Builder that allows users to create application logic using Structured Text, define the necessary interfaces, map variables to O-PAS type definitions, and generate the information needed to create an O-PAS-compliant function block.
A user-created Structured Text file can be encapsulated within an O-PAS function block, with defined inputs and outputs linked to O-PAS signals and the resulting application processed within a distributed control node.
This could give developers greater freedom to create specialized control logic, interlocks, equipment applications, or other functions while retaining standardized interfaces to the wider O-PAS environment.
The underlying User Defined Function Block work has also been described in the research paper Design and implementation of O-PAS user-defined function blocks.
Nova SMAR’s O-PAS Function Block Builder provides an environment for creating and managing user-defined function blocks for O-PAS applications
The same principle applies to both the UDFB and flow-computer examples: customized functionality can be developed behind standardized interfaces rather than requiring the entire application to remain tied to a predefined vendor implementation.
Expanding the O-PAS Application Model
Paschoal argued that process control should be viewed as a starting point for O-PAS rather than its only application domain.
If developers can create algorithms behind standardized interfaces, the architecture could potentially support a much broader range of specialized industrial applications. The challenge is identifying operational requirements where this flexibility provides practical value.
That makes end user participation particularly important. Instead of relying entirely on automation suppliers to determine which applications should be developed, operating companies can identify specific requirements within their facilities and work with suppliers and developers to turn those requirements into software-defined functions.
Nova SMAR’s roadmap reflects that approach. In addition to further flow-computer validation and certification, the company plans larger-scale implementation of its User Defined Function Block approach, proof-of-concept projects with Open Process Automation Forum end user members, and eventual commercial release of both solutions. Nova SMAR plans to make its Function Block Builder available at no cost.
The broader opportunity lies in what this development model could enable. By separating interfaces from implementation, O-PAS provides a framework in which applications can become less dependent on individual hardware platforms and proprietary architectures.
The flow-computer and user-defined function-block examples illustrate two possible directions: transferring specialized industrial functionality into scalable software-defined applications and giving end users and developers greater freedom to create applications around their own operational requirements.