The third ARC Industry Leadership Forum Singapore brought together more than 200 industry professionals under the theme How AI Is Driving the Future of Industrial Operations and Supply Chain on August 27, 2026. SMAR participated as a Global Sponsor. Octávio Paschoal, Electronic Intelligence Agent, SMAR, delivered a presentation titled Software-Defined Applications in O-PAS Architectures.
Octávio explored how the Open Process Automation Standard (O-PAS) could support applications that are less dependent on dedicated hardware and predefined vendor libraries.
O-PAS defines the interfaces between components and the functionality required through them, but not how each component must provide that functionality. This separation gives developers and end users greater freedom to determine the algorithms operating behind standardized interfaces.
SMAR is exploring two applications based on this principle. The O-PAS flow computer examines a more scalable approach to flow computing, while the User Defined Function Block (UDFB) is intended to let users create application logic beyond the functions available in existing libraries.
The full presentation is available here on YouTube:
From Standardized Interfaces to Software-Defined Applications
Initial O-PAS applications have largely focused on familiar process-control functions. Standard function blocks provide analog, discrete, and other control capabilities similar to those used in proprietary systems, but through standardized O-PAS interfaces.
Octávio presented this as a starting point rather than the limit of the architecture. He described an O-PAS component as a “black box”: the standard defines how it communicates with other components, while the designer determines what happens inside it.
This provides the basis for software-defined applications. Specialized algorithms can operate within an O-PAS environment while continuing to exchange information with other components through standardized interfaces.
Making Flow Computing More Scalable
Flow computers perform standardized calculations for applications such as fiscal metering and custody transfer, where measurement accuracy can determine the value of commercial transactions.
Conventional flow computers are specialized standalone systems and can be difficult to scale. An additional oil or gas measurement stream generally requires another flow computer rather than simply extending the existing system.
O-PAS offers another deployment model. Software applications can run in containers on distributed control nodes, allowing additional instances to be replicated when required. This led Nova SMAR to explore whether flow-computing algorithms could be implemented as a software-defined O-PAS application.
Based on an end-user requirement, the company developed a proof-of-concept for oil-flow measurement. An O-PAS distributed control node received the I/O, while a computing node ran the flow-computer application. It was tested in parallel with a certified conventional flow computer using the same inputs.
According to Octávio, the proof-of-concept produced matching instantaneous flow and correction-factor calculations, with a long-term totalization error of approximately 0.0025 percent after around two weeks of continuous testing.
Comparison of instantaneous flow values from the O-PAS application (left) and certified conventional flow computer (right), showing matching results.
The application is not yet ready to replace a certified flow computer. SMAR’s roadmap includes validation using a real measurement stream, resolving signal-integration gaps, developing function blocks for gas metering and proving, and addressing certification requirements.
The main significance is the potential scalability. By implementing the algorithm as a containerized O-PAS application, users could eventually add application instances instead of installing another standalone flow computer for each measurement stream.
Creating Functions Beyond Existing Libraries
The UDFB addresses a different limitation. Existing function-block libraries allow engineers to build applications from predefined functions, but they may not contain the logic required for every process or interlock.
SMAR’s Function Block Builder allows developers to write an algorithm in Structured Text, define its inputs and outputs, and map its variables to O-PAS signal types. The code can then be encapsulated within an O-PAS-compliant function block and processed by a distributed control node.
Users can therefore define the logic inside the block while its connections to the wider automation system continue to follow standardized O-PAS interfaces. SMAR’s Function Block Builder maps variables from user-created IEC 61131-3 logic to O-PAS objects.
Mapping IEC 61131-3 variables to O-PAS objects in SMAR’s Function Block Builder
The UDFB remains under development. SMAR is currently testing it with smaller algorithms, while its roadmap includes larger-scale implementation, end-user proof-of-concept projects, and eventual commercial release.
End Users as Co-Authors
The flow computer and UDFB apply the same software-defined principle to different requirements. The flow computer explores a more scalable way to deploy an established industrial function, while the UDFB allows users to create functions not provided by existing libraries.
In both cases, O-PAS standardizes how the application connects with other components without prescribing the algorithm behind the interface.
End-user participation is therefore important. The flow-computer proof-of-concept originated from an end user requirement. As Octávio emphasized:
The most important part is for end users to participate, bring ideas, and act as co-authors of the solution.
The wider opportunity is not simply to reproduce conventional process control within a more open architecture. It is to use standardized O-PAS interfaces as a foundation for developing software-defined applications around specific industrial requirements.