OpenOpcUa Runtime Model Architecture

OpenOpcUa / OOUAMiddleware is a model-driven OPC UA execution engine designed since 2012 to interpret NodeSet models at runtime.
It is not a code-first SDK server and not an Information Model Compiler (IMC) system.
It is a runtime-interpreted industrial middleware architecture.

In most OPC UA implementations, the information model is either embedded into code or translated into generated artifacts. OpenOpcUa follows a different architectural path: the model remains external, explicit and executable by the runtime itself.

Why Runtime Interpretation Changes the Architecture

In most OPC UA implementations, the information model is either embedded into application code or transformed into generated artifacts. This creates structural coupling between semantic design, software maintenance and deployment workflows. As a result, any model evolution propagates into code changes, rebuild cycles and increased system complexity.

OpenOpcUa follows a different architectural principle: the NodeSet remains external and is interpreted directly by the runtime at execution time. The diagram below illustrates this model-driven execution, where the NodeSet acts as the source of truth, the runtime core interprets it dynamically, and acquisition, storage and execution layers operate independently around it.

OpenOpcUa / OOUAMiddleware – Runtime NodeSet Architecture (Since 2012) NodeSet Model Layer Types • Instances • Historian Config • Alarm Config • Methods OOUAMiddleware Runtime Core Runtime Model Interpreter • Dynamic Loading • Model / Runtime Separation VPI Virtual Protocol Interface Connectivity / Acquisition (OT & IT) +100 VPIs parallel VFI Virtual File Interface Historian / Archiving / Services +10 VFIs parallel LUA Engine Multi-rate Scripts Simulation / Orchestration / Method Logic Middleware Layering – LineMiddleware → PlantMiddleware → Enterprise Industrial Assets PLC • CNC • Robots • Equipment IT / Cloud Connectivity MQTT • Cloud • Edge Gateways Files / Streams CSV • Parquet • Logs RDBMS / TSDB PostgreSQL • SQL Server • Timeseries Data Lake / Analytics Pipelines • BI • AI/ML

The runtime interprets the NodeSet directly while VPI, VFI and LUA remain execution layers around the model.

Need help designing your OPC UA information model? → Contact us

What This Architecture Enables

  • No rebuild cycle when the model evolves
  • Independent evolution of model, acquisition and storage
  • Runtime reconfiguration without system redeployment
  • Consistent behavior from edge to enterprise layers

For the broader role of middleware in industrial systems, see OPC UA Middleware.
For the platform-level architectural view, see OPC UA Middleware Architecture.

NodeSet as the Source of Truth

The NodeSet is not a configuration artifact. It is the executable system definition.

In OpenOpcUa:

  • Types are loaded at runtime
  • Instances are loaded at runtime
  • Alarm configuration is declarative
  • Historian configuration is declarative
  • Methods are declared in NodeSet and implemented via LUA or VPI

There is:

  • No model compilation
  • No code generation
  • No static type binding

The runtime interprets the model directly.

NodeSet Model Layer

  • Types (Standard + Custom)
  • Instances (Plant / Line / Assets)
  • Alarm configuration
  • Historian configuration
  • Methods

The NodeSet is the authoritative contract.

OOUAMiddleware Runtime Core

  • Runtime model interpreter
  • Dynamic AddressSpace construction
  • Strong Model / Runtime separation
  • No recompilation required

VPI – Virtual Protocol Interfaces

  • Industrial protocol connectivity
  • PLC, CNC, Robots, Equipment
  • MQTT, Cloud, Edge connectivity
  • Scalable: +100 VPIs in parallel

VPI decouples acquisition from the model.

VFI – Virtual File Interfaces

  • Historian engines
  • CSV, Streams, Files
  • RDBMS / TSDB
  • Data lake integration
  • Scalable: +10 VFIs in parallel

VFI executes storage services independently from model logic..

Embedded LUA Engine

  • Multi-rate execution
  • Simulation
  • Orchestration
  • OPC UA Method implementation

Model-Driven Method Execution

This runtime model is not limited to static structure. It also governs executable behavior, including methods, alarms, events and historian interactions.

In the ProductionCell demo:

  • The method InjectFault is declared in the NodeSet.
  • The method is implemented in LUA.
  • The runtime binds it dynamically.
  • Alarm conditions are evaluated declaratively.
  • Events are generated automatically.

Flow:
NodeSet Method → Runtime → LUA → Variable Update → A&C Engine → Event → Historian
This demonstrates strict separation between:

  • Model
  • Execution logic
  • Functional services

Why Code-First and IMC Architectures Break at Scale

Code-first and model-compiler approaches introduce structural constraints that limit scalability, maintainability and long-term evolution.

CapabilityCode-First SDKIMCOpenOpcUa
Runtime Type Loading✖✖✔
Runtime Instance Loading✖✖✔
NodeSet as Source of Truth✖Partial✔
Declarative Alarm ConfigurationRareLimited✔
Declarative Historian ConfigurationRareLimited✔
Embedded Scripting✖✖✔
Runtime Model Evolution✖✖✔
Industrial Plug-In ArchitectureLimitedLimited✔

Architectural Consequence

Because the model is interpreted at runtime, OpenOpcUa eliminates the traditional dependency between model evolution and software lifecycle.

This is not an implementation detail. It is a structural shift in how industrial systems are designed, deployed and maintained.

OpenOpcUa is not a generic OPC UA server and not a generated-code OPC UA stack. It is a runtime-interpreted industrial middleware engine where the NodeSet remains the authoritative model and the runtime executes it directly. This is the architectural difference that makes long-term model evolution structurally easier.

OPC UA Server mistakes
OPC UA Middleware
OOUAMiddleware
Download
4CE INDUSTRY