Skip to content

NAMUR NE 175 (NOA)

NAMUR NE 175 publishes the NAMUR Open Architecture (NOA). NOA's central proposal is that a plant should run two data planes in parallel, in place of a single regulated control loop carrying all data flow:

  • The core process control path carries the regulated commands and feedback that keep the plant safe and produce on-spec product. Changes inside this boundary are heavyweight: qualification, validation, change control, the full pharma rigor.
  • A second Monitoring and Optimization (M+O) plane carries high-volume telemetry, analytics, machine-learning workloads, cloud connectivity, and adjacent optimization tools. The M+O plane reads core control data freely. Writes from M+O back into the core control path require explicit verification through a defined information model.

The result is that pharma plants can adopt cloud analytics, PAT tooling, and broader data science workflows without expanding the qualified, validated control footprint to cover every new consumer.

For normative text, see the NAMUR NE 175 recommendation itself.

Key NOA concepts

  • M+O domain. The parallel plane that consumes core-control data for monitoring, analytics, and optimization.
  • NOA Information Model. An OPC UA companion specification that defines the typed objects (including the "Verification of Request" pattern) used when M+O wants to push a change back into core control.
  • NOA Security Gateway. A dedicated boundary component responsible for enforcing the direction-and-verification rules between the two planes.
  • Asymmetric flow. Data flows freely from core control to M+O. Flow back into core control is constrained and audited.

Cloud-Native DCS architectural fit

Cloud-Native DCS already separates these two planes at the component level. That separation is a property of the architecture and predates the NOA mapping.

Core control plane (regulated)

The components that carry the regulated control path:

  • The gateway and the operators (physical, procedural, batch, control). They materialize ISA-88 commands as Kubernetes objects and dispatch them.
  • The unit runtimes on each edge device, which execute the function-block and SFC logic against real I/O.
  • The control-plane CRDs (physical, procedural, batch, control, alarm).

This is the path that needs to live inside the qualified boundary.

Monitoring and Optimization plane (parallel)

The components that carry everything else:

  • The historian (TimescaleDB) — long-term time-series storage of process tags.
  • The MQTT telemetry bus — real-time fan-out of tag values to external subscribers (MQTT Telemetry).
  • The data interface REST API — read-only programmatic access to process data (Data Interface).
  • The audit trail — immutable record of state-affecting events, available for export to external quality systems.

These components consume the same source data the control plane generates, but they are physically separate processes (and in production, separately scheduled, separately scaled, separately networked). Exposing the monitoring plane externally (to a cloud analytics platform, a PAT model, an MES) does not require touching the components that run the validated control loop.

See Architecture for the full component map and SCADA Integration for the external surfaces a monitoring or supervisory consumer can use.

Adherence posture

Substantially Aligned by architecture.

The fundamental NOA topology (two physically distinct data planes, with the monitoring plane consuming and the control plane authoritative) is how the system is built. Specific NOA artifacts named in NE 175 are not yet implemented:

  • NOA Information Model — the NOA Information Model is an OPC UA companion specification, and the gateway has no northbound OPC UA server at all today (OPC UA in Cloud-Native DCS is southbound only: the unit runtime is an OPC UA client toward field devices). There is therefore no surface for the Verification objects to live on. An M+O consumer that wanted to push a verified write today would do it through the existing change-control workflow, which is structurally similar but does not advertise itself as the NOA model.
  • Dedicated NOA Security Gateway — the system relies on the IEC 62443 zone/conduit boundary (IEC 62443 traceability) and standard network policy enforcement for the same isolation NOA describes. No separately-branded NOA gateway endpoint ships.

Both gaps are on the roadmap. Neither blocks a real-world M+O deployment today: the data flows that NOA depends on already work.

Roadmap

  • NOA Information Model surface — build a northbound OPC UA server in the gateway (none exists today) and expose the NOA Verification object set on it, so that an M+O consumer can use the standard pattern for verified write-back.
  • NOA Security Gateway endpoint — a labeled, NOA-conformant edge for monitoring-plane consumers, layered on the existing IEC 62443 zone enforcement.
  • NE 175 conformance checklist in the compliance index.
  • NAMUR NE 148 — the orchestrator-side recommendation NOA is most often deployed alongside.
  • MQTT Telemetry — the high-volume telemetry channel that carries M+O traffic today.
  • Historian — long-term M+O storage.
  • Data Interface — programmatic read surface for M+O consumers.
  • SCADA Integration — REST, WebSocket, and SSE endpoints available to external systems.
  • MES Integration — Level 3 / Level 4 flow that frequently rides the M+O plane.
  • IEC 62443 traceability — the zone/conduit enforcement that provides today's equivalent of the NOA security boundary.