Skip to content

NAMUR NE 148

NAMUR NE 148 is the NAMUR recommendation that defines the automation requirements a plant-level control system must meet to orchestrate modular plants. Where the MTP / IEC 63280 series tells a module vendor "this is the package your module must ship," NE 148 tells an automation supplier "this is what your orchestrator must be able to do with that package." The two are complementary halves of the modular-automation story.

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

Scope

NE 148 covers, at a summary level:

  • Module integration. Consuming the MTP/AML package shipped with a Process Equipment Assembly and binding the module into the plant topology.
  • Service invocation. Calling the module's exposed services with the right parameters and respecting the service state machine.
  • Recipe orchestration across modules. Coordinating sequential and parallel service invocations across several modules to execute a plant-level procedure.
  • Alarm aggregation. Collecting alarms from each module and presenting them at the plant level with consistent prioritization.
  • Batch reporting. Producing the per-batch evidence record that ties recipe, equipment, and the resulting data together.
  • Lifecycle management. Managing module instances over time as modules are added, swapped, retired, or reconfigured.

Cloud-Native DCS as the NE 148 orchestrator

Cloud-Native DCS is positioned as the automation system NE 148 describes. The following table maps NE 148 requirement areas to the capabilities we provide today.

NE 148 area Cloud-Native DCS provision
Module integration ISA-88 physical model (Enterprise, Site, Area, ProcessCell, Unit) plus EquipmentCapability define module attachment points; Unit.spec.serviceBinding (ADR-0001 (asset dissolution)) binds module instances to companion-spec-aligned device data over OPC UA.
Service invocation ISA-88 phases dispatched from recipes invoke module services; the gateway REST API and the dcs CLI both expose service-level commanding.
Recipe orchestration across modules Recipes are the unit of orchestration above the module boundary; recipe execution coordinates parallel and sequential service invocations across multiple modules, with ISA-88 procedure / unit procedure / operation / phase nesting.
Alarm aggregation The alarm CRD group (Alarm Management) collects alarms from each module's runtime and surfaces them at the plant level.
Batch reporting ISA-88 Part 4 batch records (Batch Records) plus the historian collect the per-batch evidence the NE 148 lifecycle implies.
Lifecycle management The change-control workflow (Change Control) and the recipe lifecycle states cover the configuration management surface for modules and procedures over time.

The component split (gateway, operators, unit runtimes, historian, audit trail) was chosen with NE 148's data-flow expectations in mind: a thin, regulated control path with a separate monitoring plane alongside it.

Adherence posture

Substantially Aligned on the orchestrator-side capabilities.

The orchestrator role NE 148 defines is the role Cloud-Native DCS plays in a modular plant. Every requirement area above is backed by a real CRD, controller, and runtime path. The boundaries of that posture are worth stating explicitly:

  • Module-side requirements are out of scope. NE 148 also imposes requirements on the module vendor (e.g., that the module ship a conformant MTP package, expose services correctly, raise alarms in the prescribed form). Those are the integrating party's responsibility. The DCS cannot enforce them from the orchestrator side.
  • No third-party conformance test. The system has not been put through an independent NE 148 audit. Posture is based on architectural mapping alone, and no certification claim is made.

Roadmap

  • Formal NE 148 conformance checklist — published clause-by-clause mapping suitable for an NE 148 audit response.
  • NE 148 audit mapping document — referenced from the compliance index alongside the existing ISA-88 / ISA-95 / IEC 62443 / 21 CFR Part 11 traceability matrices.
  • Module Type Package (MTP) — the module-side counterpart to NE 148.
  • NAMUR NE 175 (NOA) — the parallel data-flow recommendation that sits alongside NE 148 in the modular stack.
  • Architecture — component-level view of the orchestrator, including the split between control and monitoring planes.
  • MES Integration — Level 3 / Level 4 data flow consistent with NE 148 batch reporting expectations.