Module Type Package (MTP): A Reference Architecture for Modular Process Automation

For sixty years the process industries have engineered automation the same way: a monolithic distributed control system (DCS) is configured, tag by tag, against a fixed plant that has already been built. That model breaks the moment the market rewards speed and flexibility over scale. When a specialty-chemical producer needs to bring a new molecule to a customer in weeks, or a pharmaceutical manufacturer wants to move a process from a lab skid to a production line without re-engineering every interlock, the DCS-first workflow becomes the bottleneck. The module type package architecture exists to break that dependency. It treats a physical process module as a self-contained, self-describing product whose entire automation interface travels with it in a single portable file — so the plant becomes something you compose rather than something you wire.

What this covers: the VDI/VDE/NAMUR 2658 model, the anatomy of an MTP file, the four MTP aspects, the service state machine, the OPC UA information model, the Process Orchestration Layer (POL), and where modular automation actually breaks in the field.

Context and Background

Conventional process automation is vertically integrated by design. A DCS vendor supplies the controllers, the engineering tools, the I/O, and the operator HMI as one coupled stack, and the plant’s control logic is authored centrally against that stack. This works well for a world-scale continuous plant that runs one product for twenty years. It works badly for the emerging reality of the chemical and pharma sectors: smaller batch sizes, faster product turnover, contract manufacturing, and processes that must be redeployed across sites. Every re-use of a piece of equipment means re-engineering its automation from scratch, because the equipment carries no machine-readable description of what it can do.

NAMUR — the international user association of automation technology in process industries — framed this problem years ago through its concept of the Module Type Description (MTD), later crystallised as the Module Type Package. The core idea is inversion of control: instead of the DCS knowing everything about the equipment, the equipment describes itself to whatever orchestrator sits above it. A vendor who builds a filtration skid, a reactor, or a distillation column ships it with an MTP file that declares its services, parameters, alarms, HMI symbols, and communication endpoints. The plant owner imports that file into a Process Orchestration Layer and composes a process from modules the way a software architect composes a system from libraries.

This is standardised. The governing document set is VDI/VDE/NAMUR 2658, a multi-part guideline that defines the MTP file format and its semantics, developed jointly by VDI/VDE-GMA and NAMUR and championed commercially through ZVEI’s MTP initiative. The file itself is built on two open standards: AutomationML (IEC 62714) as the container and modelling language, and OPC UA (IEC 62541) as the runtime communication contract. If you already run an OPC UA over TSN deterministic backbone, MTP is the layer that gives that transport a semantic vocabulary for process equipment. For the standards themselves, NAMUR publishes the guideline set and worksheets through its own body at namur.net.

It is worth being precise about the historical lineage, because the vocabulary is easy to muddle. The economic driver was articulated most sharply in the process industry’s discussion of “the plant of the future” and “modularity” — the recognition that time-to-market, not capital efficiency, was becoming the dominant competitive lever in specialty chemicals and pharma. A world-scale ethylene cracker amortises a two-year engineering effort over decades; a contract manufacturer serving a dozen customers cannot. NAMUR’s response was to demand that automation become composable, which is only possible if equipment describes itself. The MTP is the concrete artefact that delivers that self-description, and the 2658 series is the contract that makes one vendor’s self-description legible to another vendor’s orchestrator.

MTP Reference Architecture

The MTP reference architecture is a two-tier separation of concerns. Each physical Process Equipment Assembly (PEA) — the real skid, reactor, or unit operation — carries a machine-readable MTP file describing its automation interface. Above them sits a single Process Orchestration Layer (POL) that imports those files, instantiates each module, and sequences their services into a running process. The DCS is no longer the integrator; it becomes, at most, one consumer among several.

Figure 1: The layered MTP reference architecture — physical Process Equipment Assemblies expose themselves through MTP files, which the Process Orchestration Layer imports and sequences before reporting up to the UNS, MES, and any brownfield DCS.

Figure 1 reads bottom-to-top. At the field layer, three process modules each exist as a PEA with its own local controller — typically a PLC or embedded controller supplied by the module vendor. Each PEA emits an MTP file that combines an AutomationML description with an OPC UA server address space. Those files are imported into the POL, which becomes the single point of orchestration. The POL publishes process state and results upward into the unified namespace and MES, and — critically for brownfield sites — can coexist alongside a legacy DCS rather than replacing it wholesale. The decisive property is decoupling: the module vendor and the plant integrator no longer need to share a common DCS platform, an engineering tool, or even a controller brand.

The MTP File — AutomationML Container, OPC UA Contract

An MTP file is not a document; it is a structured, self-describing package. Physically it is an AutomationML (.aml) file — an XML dialect built on IEC 62714 — optionally packaged with supporting artefacts. AutomationML supplies the object model: a hierarchy of InternalElements, RoleClasses, and SystemUnitClasses that describe the module’s structure and its automation aspects. The MTP guideline defines specific role classes and reference designations so that any conformant POL can parse any conformant MTP without prior agreement between vendor and integrator.

The AutomationML side describes what exists — the services, parameters, alarms, and HMI elements — in a static, vendor-neutral form. It does not carry live data. Live data flows over OPC UA at runtime: the MTP declares OPC UA node identifiers and endpoint information, and the POL connects to the PEA’s OPC UA server to read and write those nodes. This separation is deliberate and worth internalising: AutomationML is the design-time interface description, OPC UA is the runtime binding. A single MTP therefore contains both a semantic model you can reason about offline and the addressing you need to talk to the equipment online.

Why AutomationML rather than a bespoke schema? AutomationML is itself a composite of established formats — CAEX (IEC 62424) for the topology and object hierarchy, with references out to COLLADA for geometry and PLCopen XML for logic where needed. For MTP the CAEX object model does the heavy lifting: the guideline defines a library of RoleClasses (semantic types such as a service, a parameter, an OPC UA server) and SystemUnitClasses, and a conformant MTP populates InternalElements that reference those roles. Because the semantics live in a shared, published role library rather than in a vendor’s private convention, a POL can walk the CAEX tree and understand each element’s meaning — this element is a service, that one is its configuration parameter, this attribute is the OPC UA node ID that binds it to a live value. The design-time/runtime split also has an operational payoff: an integrator can import an MTP, inspect the entire module interface, and even build and simulate recipes against it before the physical PEA is on site and powered, because the full interface is knowable from the file alone. The OPC UA endpoints are simply left unbound until commissioning.

The Four MTP Aspects

VDI/VDE/NAMUR 2658 organises the description into four aspects, each a separate part of the guideline series and each mappable to a distinct engineering concern:

HMI — the operator interface. The MTP carries process-picture information: symbols, dynamic elements, texts, and their linkage to live OPC UA values, so the POL or a supervisory HMI can render a faithful faceplate for the module without the vendor’s proprietary graphics package.
Services — the functional heart. A service is a named, parameterised operation the module offers — Dose, Heat, Empty, CIP-Clean — each with a governed state machine and its own configuration and procedure parameters. Services are the units of orchestration.
Communication — the OPC UA binding. This aspect lists the server endpoints and the node IDs for every dynamic value, mapping the abstract model to concrete addresses.
Safety and Alarm — the diagnostic and safety-relevant signalling: alarm definitions, their priorities, and the process-safety information the operator must see. Note that MTP describes alarm signalling; it does not by itself constitute a safety-instrumented function, a distinction that matters enormously in validation.

It helps to map these aspects onto the structure of the guideline itself, because the module type package architecture is not one document but a deliberately partitioned series. VDI/VDE/NAMUR 2658 is published as sequential parts, and the partitioning mirrors the aspects. Part 1 establishes the general concept and the overall modelling approach — the AutomationML foundation, the reference-designation rules, and the role-class philosophy that everything else builds on. Subsequent parts specialise: one part governs the HMI aspect and how process pictures and their dynamic linkage are expressed; another governs the services aspect, the state machine, and the parameter model; a further part governs the communication aspect and the OPC UA mapping; and later parts extend into diagnostics, alarm handling, and topics such as maintenance and modular type descriptions. The value of this partitioning for an implementer is that conformance can be scoped and staged — a vendor can ship a services-and-communication-complete MTP early and add richer HMI and diagnostic content as the relevant parts mature and as its own tooling catches up. It also explains the uneven ecosystem noted later: the parts did not all stabilise simultaneously, so real products implement the earlier, services-and-communication parts more completely than the later ones. When you evaluate an MTP for conformance, you are really evaluating it part-by-part, not against a single monolithic checkbox.

A subtlety worth stating plainly: the four aspects are not four separate files but four views over one AutomationML object model. A single service element in the CAEX tree is simultaneously a services-aspect entity (it has a state machine and parameters), a communication-aspect entity (its parameters bind to OPC UA nodes), an HMI-aspect entity (its faceplate symbols reference its live values), and potentially a safety-aspect entity (it raises alarms). The aspects are the lenses through which a POL reads the shared model, which is why a well-formed MTP is internally cross-referenced rather than four loosely stapled sections. Integration problems very often trace back to an MTP whose aspects were generated by different tools or teams and never reconciled — the services view declares a parameter the communication view never bound, or an HMI symbol points at a node that the export dropped.

Services, PEA vs MTP, and the State Machine

The conceptual pivot is the service. A PEA does not expose raw tags to the orchestrator; it exposes services, each of which behaves as a small, governed program. This is where MTP borrows the discipline of packaging-machine automation: the service state machine is closely modelled on the ISA-88 / OMAC PackML state model, the same lineage of Idle → Starting → Running → Complete states used across discrete packaging lines. Each service advances through a defined set of states and only accepts commands that are legal in its current state, which is what makes remote orchestration safe.

Keep the terminology precise. The Process Equipment Assembly (PEA) is the physical thing plus its local automation. The Module Type Package (MTP) is the file that describes that PEA’s interface — the “type” in the name signals that one MTP can describe a class of module, instantiated many times in a plant. You engineer against the MTP; you operate the PEA.

The type/instance distinction is not pedantic — it is the same one that separates a class from an object in software, and it carries the same benefits. A vendor who supplies four identical buffer-preparation skids ships one MTP type; the POL instantiates it four times, and each instance binds to a different OPC UA server endpoint on a different physical PEA. Recipe logic written once against the type applies to every instance. When the vendor issues a corrected MTP type, the change propagates to all instances that adopt the new version. This is precisely the leverage that makes modular automation scale: the engineering effort is proportional to the number of module types, not the number of module copies, whereas in a classic DCS every copy is re-tagged and re-engineered by hand. A parameter deserves its own vocabulary too. MTP distinguishes configuration parameters (set once before a service runs — a target temperature, a batch size), procedure parameters (bound to the specific procedure variant selected), and report values (live outputs the service publishes back). Getting these categories right in the module’s engineering tool is what determines whether the exported MTP is genuinely orchestrable or merely a bag of tags.

Deeper Analysis

The MTP Service State Machine

Every MTP service is governed by a state machine, and understanding it is the key to understanding how the POL controls equipment it did not engineer. Figure 2 shows the canonical states and transitions.

Figure 2: The MTP service state machine. A service moves through active and quiescent states under command from the POL, with dedicated paths for pausing, holding, completing, and aborting — mirroring the ISA-88 / PackML state discipline.

The state machine distinguishes deliberately between pausing and holding. Pausing is an operator-initiated, orderly suspension from which the service resumes cleanly. Holding is a process-condition response — a safe-state retreat triggered when a monitored condition goes out of bounds — from which the service is later un-held back to running. Aborting is the fast, non-graceful path to a safe abort state. Because these transitions are standardised, the POL can command Pause or Hold on any conformant service without knowing anything about the vendor’s internal logic; the module owns the how, the POL owns the when. This is the property that makes true vendor independence possible: orchestration logic written against the abstract state machine survives a change of module supplier.

The states carry commands and status in parallel. The POL issues commands — Start, Stop, Pause, Resume, Hold, Abort, Reset — by writing to command nodes, while the PEA reports its actual current state back through status nodes. The orchestrator never assumes a transition succeeded; it commands, then waits for the reported state to confirm. That request/confirm pattern is what keeps a distributed set of modules coherent.

A second concept the service model borrows from PackML is mode, orthogonal to state. A service can run in an automatic mode under POL command, an operator mode where a human at the faceplate drives it, or an offline mode. Command authority is arbitrated by mode: the POL can only sequence a service that is in automatic mode and has granted the POL command source, which prevents the dangerous situation of two authorities issuing conflicting commands to the same physical equipment. In practice this arbitration is what an operator interacts with when they “take” or “release” a module from the orchestration — a maintenance technician can pull a single PEA into operator mode to run it locally without the POL fighting them for control, then release it back to automatic when done. The interplay of state, mode, and command source is subtle, and it is the part of MTP that integration testing most often exposes as under-implemented in immature POL or PEA products.

The command mechanism itself repays a closer look, because it is where the standardisation earns its keep. Commands are not method calls; they are numeric codes written to a command variable, and the service exposes a companion variable that advertises which commands are currently permitted given its state. A POL that respects the model reads the permitted-commands mask before issuing anything, so it never fires a Resume at a service that is not paused or a Start at one already running. This bitmask-of-legal-transitions pattern is deliberately defensive: it lets the module remain the sole authority on what is legal, while the orchestrator discovers legality at runtime rather than hard-coding a state chart it might get wrong. A frequent immaturity in early PEA firmware is a command variable that accepts illegal codes silently — the service ignores the write but reports no error, and the POL, seeing no state change, stalls waiting for a transition that will never come. Robust orchestration therefore couples every command with a timeout and an expected-state assertion: issue Start, expect Running within a bounded window, and escalate to an operator if the reported state does not arrive. Treating the state machine as a promise the module might silently break — rather than a contract it will always honour — is the difference between a POL that survives a heterogeneous fleet and one that hangs on the first non-conformant skid.

Command-source arbitration deserves the same scrutiny. In a correctly modelled service the right to command is a resource that must be explicitly acquired and released: the POL requests command authority, the service grants it (or refuses, if a local operator holds it), and only then will the service act on POL-written command codes. This handshake is what prevents the “two operators” failure the trade-offs section describes, but it only works if both sides implement it. A PEA that always accepts external commands regardless of its declared command source is a latent hazard — it will obey a POL even while a maintenance technician believes they have taken local control. Verifying this arbitration under adversarial conditions — commanding from the POL while a local HMI holds authority, and confirming the command is refused — belongs on every factory-acceptance test plan.

The OPC UA Information Model and Node Mapping

At runtime the MTP resolves to an OPC UA address space. Figure 3 shows how the design-time model maps onto navigable OPC UA nodes.

Figure 3: MTP OPC UA node mapping. The MTP root exposes a ServiceSet and CommunicationSet; each service resolves to procedures, configuration parameters, report values, and a state-machine node, all bound to concrete OPC UA DataItems.

The MTP root object organises into a ServiceSet and a CommunicationSet. Each service node exposes its procedures (the selectable variants of how a service runs — for a Dose service, procedures might differ by dosing profile), its configuration parameters (set before the service starts, e.g. target mass), its procedure parameters (bound to the selected procedure), its report values (live process feedback the service publishes), and a state-machine node carrying the command and current-state variables from Figure 2. The communication aspect ties every one of these to concrete OPC UA DataItems with specific node IDs and endpoints.

This mapping is why MTP and OPC UA are inseparable in practice. AutomationML gives you the tree; OPC UA gives you the live values at the leaves. When the POL wants to start a dosing service with a 12.5 kg setpoint, it writes the configuration parameter node, selects a procedure, writes the Start command node, and polls the state-machine node until it reports Running — all against node IDs it learned by parsing the MTP file, with no hard-coded tag list.

The interaction pattern in the OPC UA layer is worth spelling out, because it is where subtle races live. Consider that 12.5 kg dose. The POL first writes the configuration parameter, but MTP parameters carry an ownership flag — the module may reject an external write if a parameter is currently under internal or operator control, so the POL must confirm the value was actually accepted, not merely sent. It then selects the procedure, again confirming the selection took. Only then does it write the command node with the numeric command code for Start, and — crucially — it does not treat the write’s success as the service having started. It subscribes to (or polls) the current-state variable and waits for the reported state to advance to Running. If a monitored process condition later trips the service into Held, the POL sees that state change through the same subscription and can decide whether to un-hold, abort, or escalate. Every meaningful action is a write-then-verify round trip against typed nodes, which is exactly the discipline that lets a single orchestrator safely drive equipment it never engineered. Using OPC UA subscriptions rather than naive polling matters here: on a plant with dozens of PEAs each exposing tens of live values, subscription-based change notification is the difference between a responsive orchestrator and one drowning in read traffic.

Orchestration Recipes, UNS Integration, and the Engineering Workflow

The POL’s job is to turn a set of module services into a process. It does this with recipes — sequences (and parallel branches) of service invocations with their parameters, conditions, and transitions. A recipe might read: start the transfer service on Module A, wait for level-reached in the report values of Module B, start the heat service on Module B to 80 °C, hold until temperature stable, then start the reaction timer. The recipe is authored once at the POL and executed against whatever modules are bound to it, which is exactly how a batch recipe abstracts away equipment specifics in ISA-88 — MTP simply makes that abstraction portable across vendors.

Recipe execution is not merely a linear list. A realistic POL recipe includes parallel branches (start two services concurrently and synchronise on both completing), conditional transitions (proceed only if a report value crosses a threshold), and exception handling (on a service reporting Held, run a defined recovery path). This is the same expressive power ISA-88 defined for batch procedural control, but decoupled from any single control system. The recipe references services and their parameters by their MTP-defined names, so the same recipe can bind to a different physical PEA — say, a backup reactor — provided that PEA’s MTP offers services with the matching interface. That substitutability is what turns a modular plant into a genuinely flexible one: capacity can be re-routed around a module down for maintenance without rewriting the process logic.

Upward integration is where MTP meets the wider IIoT stack. The POL is a natural publisher into a unified namespace: every service state, report value, and alarm is already a well-typed, named entity, so mapping it onto UNS topics or an MES batch record is largely mechanical. There is also strong conceptual overlap with the Asset Administration Shell — both are self-describing digital interfaces for physical assets — and the standards communities have actively explored expressing MTP content as AAS submodels so that a module’s automation interface and its broader digital-twin metadata live in one framework. The pragmatic reading is that MTP is the process-automation-specific self-description, tightly scoped to services and their runtime binding, while AAS is the general-purpose asset self-description spanning nameplate, documentation, condition, and lifecycle; the two are complementary rather than competing, and a mature modular plant will likely carry both.

Figure 4 traces the end-to-end engineering workflow.

Figure 4: The MTP engineering workflow — the module vendor exports an MTP file from its own tooling, the plant integrator imports it into the POL, instantiates and maps services, builds a recipe, binds OPC UA endpoints, and executes with live reporting to the UNS and MES.

The workflow’s power is in its clean handoff. The module vendor works entirely in its own engineering environment and exports a conformant MTP. The plant integrator never touches the vendor’s controller code; it imports the file, instantiates the module in the POL, composes recipes, binds endpoints, and runs. Two organisations that share no common tool cooperate through one file format. That is the entire economic argument for MTP compressed into one diagram.

To make the leverage concrete, contrast the effort profiles. In a classic DCS project, integrating a new skid means the plant’s automation contractor receives the vendor’s I/O list and functional description as documents, then manually creates tags, builds control logic, draws faceplates, configures alarms, and tests every point — commonly hundreds to low-thousands of engineering hours for a non-trivial unit, repeated in full for the next near-identical skid because none of that work is portable. In the MTP model, the vendor does the equivalent work once inside its own tooling and captures it in the exported file; the integrator’s task collapses to import, instantiate, map, and recipe-build, a fraction of the original effort, and it does not grow linearly with the number of identical modules. The saving is not that any single step is magically cheaper — it is that the expensive, error-prone tag-and-logic re-creation step is deleted from the integrator’s critical path and moved, once, to the party who understands the equipment best. That reallocation of who does what, and when, is the real architectural change; the file format is merely its enabling mechanism.

There is a governance corollary. Because the module vendor now owns a machine-readable, executable description of its equipment’s behaviour, the quality of that description becomes a purchasing criterion. Plant owners increasingly write MTP conformance and completeness into procurement specifications — demanding all four aspects, a validated parse against a reference POL, and a documented versioning policy — the same way they once specified wiring standards. The MTP file becomes a deliverable with acceptance criteria, not an afterthought generated at handover.

Trade-offs, Gotchas, and What Goes Wrong

MTP is not free of friction, and pretending otherwise sets projects up to fail. The first hard limit is safety and GMP validation. MTP standardises alarm and diagnostic signalling, but it deliberately does not replace safety-instrumented systems — a safety function still needs its own IEC 61511-compliant design, and in a modular plant the boundary of the safety loop must be drawn carefully when equipment is composed dynamically. In regulated pharma, computer-system validation assumes a known, fixed configuration; a plant that recomposes modules on demand challenges that assumption, and the qualification strategy has to account for every valid module combination.

The second is vendor maturity. The standard is real and stable, but the ecosystem is uneven. Not every module vendor ships a complete, conformant MTP; not every POL product implements every aspect identically, and the HMI and safety/alarm aspects tend to lag the services aspect in real tooling. Conformance in principle does not guarantee interoperability in practice, and integration testing between a specific PEA and a specific POL is still mandatory.

Third, brownfield integration is rarely as clean as Figure 1 suggests. Existing plants have a DCS that owns interlocks, historian tags, and operator workflow, and slotting a POL alongside it means resolving overlapping responsibility for the same equipment. A common failure mode is the “two operators” problem: the DCS HMI and the POL faceplate both appear to control the same skid, and without a clear command-source arbitration policy the plant floor gets ambiguous authority — precisely the condition MTP’s mode/command-source model is meant to prevent, but only if it is actually configured and respected end to end.

Fourth, the POL can become a bottleneck: it is now the single orchestration authority, and its availability, latency, and scaling directly govern the whole plant — a concentration of risk the old distributed DCS did not have. Distributed control was, for all its rigidity, genuinely distributed; a POL re-centralises orchestration, and that demands the same redundancy, failover, and load engineering you would apply to any single point of control. A POL that pauses does not just stop showing data — it stops sequencing services, and any recipe mid-flight is now uncoordinated.

Finally, versioning is a live problem: when a vendor revises an MTP, the POL’s recipes bound to the old node structure may break, and there is no universal, industry-wide answer yet to MTP lifecycle and compatibility management. If a new MTP version renames or restructures a service’s parameters, every recipe that referenced them needs review. Treating MTP versions with the same rigour as an API contract — semantic versioning, deprecation windows, regression tests of recipes against the new file — is the pragmatic mitigation, but it is discipline the organisation has to impose; the standard does not enforce it for you.

Practical Recommendations

Treat MTP adoption as an architectural commitment, not a pilot feature. Start with a bounded, self-contained unit operation — a CIP skid, a buffer-prep module, a single reactor — where the module boundary is physically obvious and the safety scope is contained. Prove the vendor-to-POL handoff on that one module before scaling. Insist on conformance evidence, but budget for integration testing regardless, because conformance and interoperability are not the same thing.

Design the layers explicitly. Keep the POL’s orchestration logic strictly above the service state machines and never reach past a service into a module’s internal tags — the moment you do, you have re-coupled what MTP decoupled. Plan the safety architecture independently of MTP from day one.

A practical adoption checklist:

[ ] Choose a first module with a clear physical and safety boundary.
[ ] Require a complete MTP covering all four aspects, and validate it parses in your POL before contract sign-off.
[ ] Run PEA-to-POL integration tests; do not trust conformance claims alone.
[ ] Define the safety-instrumented functions separately, per IEC 61511, outside the MTP orchestration path.
[ ] Establish an MTP versioning and change-management policy up front.
[ ] Map POL outputs into your UNS/MES with typed, named topics from the first module.
[ ] Load- and failover-test the POL as a single orchestration authority.

Frequently Asked Questions

What is a Module Type Package in simple terms?

A Module Type Package is a standardised, machine-readable file that describes a process module’s complete automation interface — its services, parameters, HMI symbols, alarms, and communication endpoints. Think of it as a driver-plus-datasheet that travels with a physical skid or reactor. Any conformant orchestration system can read the MTP and control the module without prior engineering agreement with the module’s vendor. It is defined by VDI/VDE/NAMUR 2658 and built on AutomationML and OPC UA.

How does MTP differ from a traditional DCS?

A traditional DCS is the central integrator: it holds all the control logic and is engineered against a fixed plant, tightly coupling equipment, controllers, and tools from one vendor stack. MTP inverts this. Each module carries its own local automation and describes itself through an MTP file; a thin Process Orchestration Layer merely sequences module services. The DCS-centric model optimises for large, stable, single-product plants; MTP optimises for flexible, fast-changing, multi-vendor modular plants.

What standards define MTP?

The governing guideline is VDI/VDE/NAMUR 2658, a multi-part series developed by VDI/VDE-GMA together with NAMUR and promoted commercially by ZVEI. It specifies the MTP file format and its aspects. The file relies on two international standards: AutomationML (IEC 62714) as the XML-based container and modelling language for the design-time description, and OPC UA (IEC 62541) as the runtime communication contract that binds the model to live data.

What is the Process Orchestration Layer?

The Process Orchestration Layer (POL) is the software tier that imports MTP files, instantiates each module, and sequences their services into a running process using recipes. It replaces the integrating role of the DCS but stays deliberately thin: it commands services through their standardised state machines and never manipulates a module’s internal logic. The POL is also the natural point to publish process state upward into a unified namespace, MES, or higher-level analytics.

Is MTP suitable for safety functions?

Not directly. MTP’s safety-and-alarm aspect standardises alarm and diagnostic signalling — definitions, priorities, and operator-relevant safety information — but it does not implement safety-instrumented functions. A safety loop still requires its own IEC 61511-compliant design, and in a modular plant the safety boundary must be defined carefully because equipment is composed dynamically. Treat MTP as the process-orchestration and diagnostic layer, and design your SIS independently of it.

Can MTP work alongside an existing DCS?

Yes, and in brownfield sites it usually must. A POL can be introduced alongside a legacy DCS, taking orchestration responsibility for new modular units while the DCS continues to run existing equipment. The challenge is governance: you must clearly divide which system owns interlocks, historian tags, and operator workflow for each piece of equipment, because overlapping authority over the same asset is where integration projects tend to break.

Module Type Package (MTP) Reference Architecture for Modular Process Automation (2026)