Module Type Package (VDI/VDE/NAMUR 2658)

The Module Type Package (MTP) is a vendor-neutral, file-based package format defined by the VDI/VDE/NAMUR 2658 multi-part series. An MTP describes a Process Equipment Assembly (PEA), a skid or module that arrives pre-engineered with its own internal control logic, in enough detail that a plant-level orchestrator can integrate it without bespoke engineering work for each new piece of equipment. The underlying file format is AutomationML (AML), and the runtime communication path between module and orchestrator is OPC UA.

For normative text, see the VDI/VDE/NAMUR 2658 standard itself.

What the standard covers

The series organizes a module's exposed surface into four aspects:

Aspect	Purpose
Process Control	The set of services a module offers, their parameters, and the state machine each service follows.
HMI	The graphical representation a module provides for a plant operator screen, including faceplates and process pictures.
Diagnostics and Maintenance	Diagnostic information, alarms, and maintenance interactions the module exposes for upkeep workflows.
Alarm Management	The alarms the module raises, their priorities, and how they are surfaced upward to the plant alarm system.

The package is a self-contained AML file. An orchestrator that implements an MTP-conformant integration point can in principle accept a module from any vendor whose product ships a valid package.

Service-based interaction model

MTP treats each PEA as a provider of named services. A service has parameters, one or more procedures (self-completing or continuous), and a mandatory, non-configurable state machine: 16 states in five levels, driven by ten commands with a fixed bitwise coding, defined normatively in VDI/VDE/NAMUR 2658 Part 4. The standard describes this model as similar to the ISA-88 concept, and the similarity stops short of identity. Two MTP commands (Restart, Complete) have no ISA-88 counterpart, and the joint NAMUR/ISA-88 working group's alignment of the two models is not yet unified. Cloud-Native DCS therefore carries the MTP vocabulary natively and declares its ISA-88 correspondence in one place (ADR 0045). The two models are never treated as interchangeable.

The orchestrator's job is to invoke services in the right order, with the right parameters, as a recipe is executed. The module's internal control logic (sequences, interlocks, lower-level loops) stays inside the module and is not the orchestrator's concern.

Adherence posture

Aligned at the architecture level. Native MTP package import is implemented. The Part 5.1 runtime binding, MTP export and certification are not. No round trip against a vendor PEA has been run.

Cloud-Native DCS is designed around the same service-based abstraction MTP uses to expose modules to an orchestrator. The mapping from MTP concepts to our CRDs is direct:

MTP concept	Cloud-Native DCS equivalent
ModuleTypePackage (PEA description)	Unit + EquipmentCapability
ModuleService	PhaseTemplate (phase definition)
MTP service state machine	pkg/mtpservice — the Part 4 vocabulary (16 states, 10 commands, Table 14 codings, Figure 3 transitions) with a declared correspondence onto the pkg/statemachine ISA-88 model
ServiceControl interface	Service-plane recognition signature in device discovery — a node exposing the ServiceControl variable shape pre-classifies as a Unit (ADR 0045) — and, once declared on the Unit, the addresses phase logic drives through MTP_COMMAND / MTP_STATE / MTP_COMMAND_ENABLED and the Unit detail reads back through GET /units/{name}/mtp-services
ServiceParameter	Phase parameter (recipe parameter binding)
HMI aspect	Gateway HMI runtime (Web UI)
Alarm Management aspect	alarm CRD group (Alarm Management)
Diagnostics and Maintenance aspect	Historian + audit trail (Historian, Batch Records)

When a recipe phase drives a module service, it does so through the standard's own interface, with no translation layer. A step action writes one of the ten Part 4 commands to the service's command channel with MTP_COMMAND, gated on the live CommandEn word the module publishes. The following transition guards on MTP_STATE, the state the module reports. The module keeps its state machine and we read its feedback, which is the POL role the standard describes. See Structured Text for the authoring shape and examples/smart-skid/phase-templates-mtp-dosing.yaml for a worked pair of phase templates, one per procedure kind.

The same feedback pair is readable outside a phase run. A smart Unit's detail page lists its declared services with the state the module reports and the commands its CommandEn word currently enables, read on demand. Nothing is mirrored into status. That is the surface an engineer uses to answer why a phase held on a command the module refused: the refusal is visible as the accepts-list that did not contain it. The panel reads only. Commanding a service is done from phase logic, where the run that owns the module is the thing issuing the command. See API Reference → MTP Module Services.

What is not yet implemented

The architectural alignment is in place, but specific MTP artifacts are not:

• The Part 5.1 runtime binding. Recognition and addressing key on the ServiceControl variable shape browsed from the live server. The manifest-declared node binding of Part 5.1 (currently a draft edition) plays no part yet. See ADR 0045 for what changes if that is adopted.
• MTP export. Producing an MTP package that describes a unit Cloud-Native DCS itself manages (so that another orchestrator could consume it) is also not implemented.
• Certification. The system has not been tested against an MTP conformance test lab. No certification claim is made.
• A proven round trip against a vendor PEA. Both halves are proven against real artifacts: the parser against two vendor manifests from different revisions of the format, and the generated resources against the live CRDs. What no test covers is a vendor PEA answering a declaration this product imported, because no such module has been on the bench. The gap belongs to the ServiceControl interaction, and it closes the first time a design partner puts a skid in front of it.

These are tracked as roadmap items. They do not block real-world integration with a vendor module today, because the underlying service surface is the same regardless of whether the description arrived as an AML file or as a hand-authored CRD set.

Reading a vendor's package

Package import landed in #1497. dcs mtp import and the gateway's POST /api/v1/import/mtp parse the AutomationML/CAEX container and generate the IOModule, Unit and ControlModule set an engineer used to transcribe. What the file declares and this product cannot represent is reported per item rather than dropped, because a partial import that silently discards a service is worse than a refusal. The engineer's walkthrough, including the four findings worth expecting, is on the OEM skids page.

Two properties of the format are worth recording here, since neither is obvious from the standard's prose and both were settled against real vendor exports.

A manifest carries a namespace URI. A namespace index is assigned by the server at startup, so a file written months earlier could not carry one. Imported addresses are therefore emitted in the URI form nsu=<uri>;s=<identifier>, which resolves against the server's NamespaceArray at connect time.

Files in the field speak two incompatible service vocabularies. The current revision declares a ServiceProcedure with a ProcedureID. The older one declares a ServiceStrategy with a StrategyID and renames the ServiceControl channels to match. The channels correspond one for one, and they are still not treated as aliases: the older file does not say which coding its state and command words use, and this product writes the mandatory Table 14 coding. Services from an older file are recognized and refused by name, which is a different outcome from a file that declares no services at all. Its control modules import normally.

One parser detail an integrator can hit. A manifest is read as UTF-8, US-ASCII or ISO-8859-1 (also spelled latin1). Any other declared encoding is refused by name. A Latin-1 file is transcoded on the way in, because Go's XML decoder reads UTF-8 and nothing else. Handing it those bytes unchanged ended the parse at the first accented character (#1515).

Import produces CRs the engineer then owns. Nothing re-reads the file and nothing binds to it, matching how the device discovery wizard already behaves. A live binding that tracks a vendor's revised package is a separate question and is not implemented.

Related Documentation

• ADR 0045 — the MTP service model decision: ServiceControl-shape recognition, the native vocabulary, and the conformance posture.
• IEC 63280 — the international IEC rollup of MTP.
• NAMUR NE 148 — the orchestrator-side recommendation that complements MTP's module-side scope.
• Control Modules — the device-level abstraction below the phase.
• Phases — the orchestrator's view of a service invocation.
• Structured Text — the builtins that drive a declared module service from phase logic.
• ISA-88 traceability — formal mapping of ISA-88 requirements to CRDs and code.