Module Type Package (MTP) and Modular Production: VDI 2658, POL Orchestration and OPC UA Process Modules

A classic process plant is engineered as one organism. The piping and instrumentation diagram, the control logic, the operator graphics and the alarm lists are all written against a single distributed control system (DCS), and every change ripples through all of them. That model works for a refinery that runs for thirty years. It works badly for a specialty-chemical or pharmaceutical plant that must be re-plumbed for each new product campaign, because the automation engineering becomes the critical path of every change.

The module type package (MTP) is the process industry’s answer: a vendor-neutral, machine-readable description of what a self-contained skid can do and how to talk to it, standardised in the VDI/VDE/NAMUR 2658 guideline family and heading into the IEC 63280 series. Instead of programming the skid into the DCS, you import its MTP file into an orchestration layer and compose recipes from the services it advertises.

This article explains how that works at mechanism level: the roles of the process equipment assembly (PEA) and the process orchestration layer (POL), the structure of a service and its state machine, the OPC UA mapping, the engineering workflow compared with a classic DCS project, and the places where adoption still hurts.

What this covers: the standard landscape and its status, the PEA and POL architecture, services and procedures, the OPC UA runtime, an illustrative MTP snippet and client code, the engineering workflow, failure modes, and a practical adoption checklist.

Context and Background

Modular production in the process industry grew out of a commercial pressure rather than a technical curiosity. Product lifecycles in specialty chemicals, active pharmaceutical ingredients and food ingredients have shortened, batch sizes have shrunk, and plants are expected to be built and reconfigured faster than a bespoke DCS project allows. The mechanical answer was the modular plant: standardised, pre-fabricated process modules (reactors, dosing units, filtration skids, distillation units) that can be added, removed and re-sequenced. The automation answer had to follow, otherwise each module would arrive with its own PLC, its own protocol and a pile of proprietary documentation that a system integrator then re-engineers from scratch.

The working group that took on this problem is the joint effort of NAMUR (the user association of automation technology in process industries), with ZVEI, VDMA, ProcessNet and later PI (PROFIBUS and PROFINET International). The output is the guideline family VDI/VDE/NAMUR 2658, titled around automation engineering of modular systems in the process industry. According to the June 2024 MTP status roadmap published by PI, the guideline is split into parts: general concept and interfaces (Part 1), HMI modelling (Part 2), a data object library (Part 3), service-based process control (Part 4), runtime and communication including OPC UA (Part 5 and 5.1), alarm management (Parts 6 and 7), plus further parts for diagnosis and maintenance (NE 184), qualification (NE 185) and requirements for the orchestration layer (NE 187). That same roadmap describes the document set as partially inconsistent across versions, which is an honest summary of how a decade of incremental publication feels from the implementer’s chair.

Two status points matter in 2026. First, the consolidated MTP 2.0 document set was announced by PI in February 2025 as a profile-based, harmonised revision with a final version planned from summer 2025; it keeps the basic concepts of MTP 1.0 so that existing PEAs can work with future MTP 2.0 orchestration systems. I could not verify from the sources I reviewed the exact publication state of each part today, so check the current NAMUR and PI download pages before citing a part number in a specification. Second, IEC technical committee 65 working group 14 held its kickoff in February 2024 to bring the specification into the IEC 63280 series, starting with the general concept as Part 1. A conference presentation from 2025 calls MTP “soon international standard IEC 63280 MTP 2.0”, which is the right way to read it: the direction is clear, the finished international text is not something I can confirm.

This post takes a different angle from our earlier architectural overview in MTP and modular process automation architecture. That one frames the architecture; here we dig into the service model, the runtime contract on the wire, the engineering economics, and what breaks in practice. If you need the transport background first, our OPC UA protocol technical guide covers the address space and subscription model that MTP builds on. For the surrounding plant-information hierarchy MTP plugs into, see the ISA-95 and ISA-99 standards guide. The official sources for the standards are the NAMUR and PI publications, and OPC UA itself is specified in IEC 62541.

Reference Architecture: PEA, POL and the MTP Contract

In short: a module type package is a standardised description file that lets a process orchestration layer (POL) integrate a process equipment assembly (PEA) without custom programming. The PEA keeps its own local control and exposes services, process values and operator-graphics instructions via an OPC UA server. The POL imports the MTP, acts as OPC UA client, and orchestrates services from recipes.

Figure 1: PEAs expose services through OPC UA servers; the POL imports each PEA’s MTP file at engineering time and acts as OPC UA client at runtime.

The figure shows two time axes that are easy to conflate. At engineering time the MTP file travels from the module vendor to the POL, much as a device description file travels to a fieldbus master. At runtime the POL and the PEA exchange live data over OPC UA. The MTP file itself is never on the runtime path; it tells the POL what to expect when it connects.

The PEA: a module that owns its own control

A process equipment assembly is a self-contained unit with a defined process function, such as a stirred reactor with heating, a dosing skid or a crossflow filtration unit. Critically, the PEA contains its own automation: a PLC or small controller that closes the control loops, runs the interlocks and drives the actuators. The POL never executes loop control for the module. This is the design decision that makes the whole approach scale: control stays local and deterministic, while coordination moves up a level and is allowed to be slower.

The PEA’s PLC is accompanied by an OPC UA server. In the MTP model the controller exposes a defined set of nodes: data assemblies representing sensors, valves and drives; service objects with their command and state variables; and the supporting diagnostic items. A learning page from the CENA demo project describes the contract succinctly: the MTP describes all variables the PEA’s OPC UA server communicates, and its normative parts define how data assemblies and services communicate with the POL and react to input.

The POL: orchestration without loop control

The process orchestration layer is the higher-level control system into which MTP files are imported and from which the plant is operated. A pharma-industry presentation from OPC Day Finland 2025 lists what the POL carries: user management, operation, audit trail, historian and trending, alarm acknowledgment and history, reporting, calibration and maintenance. It also states that the PEA HMI is not used, shown as “No HMI at PLC” in the source diagram. That last point is a strong claim with consequences: the operator experience lives wholly in the POL.

Any DCS vendor can offer a POL, and the roadmap quoted earlier counted 10 POL systems from 8 vendors and 12 PEA automation solutions from 11 vendors as of mid-2024, with more than 25 MTP products and over 50 proof-of-concept projects. Those are vendor-association figures from a status slide, not an independent market survey, but they indicate that the ecosystem is real rather than theoretical.

The MTP file: what it carries

The MTP is not one thing. It is a package built on AutomationML (the CAEX-based XML exchange format standardised as IEC 62714), and it carries several aspects of the module:

Topology and data objects: instances of the data assemblies from the Part 3 library (analog and binary indicators, valves, drives, controllers, and so on) with the OPC UA node identifiers where each can be reached.
Services: the list of services the module offers, their procedures and parameters, and the node identifiers of each service’s command and state interface (Part 4).
HMI description: instructions for how the POL should draw the module, including object placement, shapes and symbol references such as an optional eClass identifier (Part 2). MTP 2.0 adds support for custom SVG graphics for process displays, according to the roadmap.
Communication description: which OPC UA server, endpoint and mapping the POL should use (Part 5).
Alarm and diagnostic information: the alarm concepts of Parts 6 and 7, including the ManagedAlarms profile introduced for MTP 2.0.

A useful mental model is the device driver: the MTP plays the role that a GSD or EDDL/FDI package plays for a field device, except that the “device” is a whole process module and the interaction pattern is service invocation rather than cyclic I/O.

Why services, not signals

The deepest change versus a classic DCS project is the abstraction level. A conventional integration maps tags: the integrator imports a tag list, builds faceplates, and writes sequencing logic that sets setpoints and watches feedback. MTP integration maps capabilities. The POL does not know that the module’s agitator speed is node 4711; it knows that the module offers a service called “Mixing” with a “Slow” and a “Fast” procedure, a speed parameter with limits, and a defined state machine. The sequencing logic inside that service remains in the PEA, written once by the module vendor who understands the process equipment.

This is the original thesis worth stating plainly: MTP shifts the integration boundary from the signal to the service, so the unit of reuse becomes validated behaviour rather than copied code. That is why the pharmaceutical sector, which pays heavily for every line of code it must validate, is among the most interested adopters.

Standards stack at a glance

Layer	Standard	Role in MTP
Guideline family	VDI/VDE/NAMUR 2658	Concept, HMI, data objects, services, runtime, alarms
International track	IEC 63280 (in preparation)	Intended international form of the specification
Exchange format	AutomationML, IEC 62714	Container for topology, services and HMI description
Runtime protocol	OPC UA, IEC 62541	Live data and service commands between POL and PEA
Process model	ISA-88 concepts	Recipe and procedural-control vocabulary the service model echoes
Context	ISA-95	Where the POL sits relative to MES and ERP

The IEC 63280 row is deliberately hedged: the working group exists and plans to base the series on the MTP parts, but I did not find a source confirming a published edition.

Where the digital twin angle comes in

For readers following this site’s digital twin theme, the MTP is effectively a design-time twin of the module: a machine-readable description of its interface, behaviour contract and visualisation. It is not a simulation model, and it carries no physics, but it is the structured metadata a twin platform needs to attach live data to the right semantic slot. Our comparison of AAS, DTDL and OPC UA information models is the place to weigh MTP’s approach against asset-administration-shell style descriptions. The two are complementary more than competing: AAS describes an asset across its lifecycle, while MTP describes how to operate one specific class of asset inside an orchestrated process.

Services, Procedures and the State Machine in Depth

A service represents a capability of the module, for example mixing, dosing, heating or filtering. A procedure is one alternative way of delivering that capability: the CENA demo documentation uses slow, fast and cold mixing as the example, and states that only one procedure can be active within a service at a time. Both services and procedures can carry parameters, which are themselves data assemblies, so a mixing procedure might expose a speed setpoint with engineering limits and units.

Figure 2: A simplified view of the service state machine, showing the Execute, Pause, Hold and Complete loops. Real services also handle Stopping, Stopped, Aborting, Aborted and Resetting; those are omitted here for legibility.

The figure is intentionally a subset. The OPC Day Finland 2025 material describes the service states in five tiers of increasing capability: the minimum level has Execute, Pausing, Paused and Resuming; higher levels add Starting, Completing and Unholding; then Holding and Held; then Stopping and Stopped; and the fullest level adds Idle, Completed, Resetting, Aborting and Aborted. The tiered presentation reflects a practical truth: a simple dosing service may not need pause semantics, while a reaction step with a safety-relevant hold must implement the full set.

Wait states and acting states

If you know ISA-88 or PackML, the shape will be familiar. The state names split into two kinds. Acting states (Starting, Pausing, Holding, Completing, Stopping, Aborting, Resetting and the like) end by themselves when the module’s internal sequence finishes; the PEA signals that the work is done. Wait states (Idle, Paused, Held, Completed, Stopped, Aborted) persist until a command from the controlling side arrives. The POL’s job is to issue the right command from the right wait state and watch for the acting state to resolve.

The design pays off in error handling. A recipe step that issues Start and then sees the service go to Held rather than Execute has a precise, standardised signal that something happened locally, without needing to understand why. The module may report the cause through alarms and report values, but the orchestration engine can already apply a generic policy such as “pause the recipe and notify the operator.”

Control source and operation mode

A service can be controlled from different sources: the operator at a local panel, an external control system, or the PEA itself. MTP models this with operation and source modes, which MTP 2.0 documents more precisely according to the PI announcement. The reason is safety and maintainability. A technician running a cleaning sequence locally on a skid must not be overridden by an orchestration command arriving from the plant network, and the orchestration layer must know when it has been locked out. If you have lived through a commissioning where someone left a module in manual and the recipe silently hung, you understand why this matters.

Process values, report values and parameters

Three kinds of data accompany a service in practice:

Parameters: values the POL writes before or during execution, such as target temperature or batch quantity.
Process values: live measurements the operator watches, such as actual temperature and level.
Report values: results the module produces when it completes, such as the total mass dosed, which feed the batch record.

The OPC Day source notes that recipes are built from PEA automation services and that operations are managed through “standardized, pre-defined PEA services, procedures, parameters and report values”. That sentence describes the whole value proposition: if the vocabulary is standard, the POL can generate recipe steps, faceplates and batch reports from the metadata without per-module code.

Data assemblies from the Part 3 library

The Part 3 library defines the standard building blocks. The 2019 Yokogawa summary of the release describes them as a data structure library with a minimum data set for each structure: for a valve, mandatory type (analog or digital), HMI position and rotation, and about 20 minimum parameters such as setpoint with range, feedback position and operating mode. Common elements cover data quality and security level, analog and binary basics, and the operation modes. Later versions added items such as three-way valve assemblies (TriPosVlv and MonTriPosVlv) in MTP 2.0, per the PI roadmap.

Treat the “about 20 parameters” figure as an order of magnitude from a 2019 secondary source and a specific valve structure; the library has been revised since then, and the normative document, not a blog, defines the actual attribute lists.

The Runtime Contract: OPC UA Between POL and PEA

The POL acts as the OPC UA client and each PEA acts as an OPC UA server, per the pharma-oriented source. Each module is a separate server, which keeps failure domains small: a module that reboots disrupts its own session, not the rest of the plant. It also means the POL must manage many concurrent client sessions, certificates and subscriptions.

Figure 3: A service invocation. The recipe engine selects a procedure, the OPC UA client writes request and command nodes, and subscription data changes report state, process values and the final report values.

What the sequence shows

Three details in the sequence carry the design. First, the interface is write-command, observe-state: the client does not call a remote method that blocks until completion; it writes a command variable and then watches the state variable change through a subscription. This tolerates slow modules, network interruptions and session restarts far better than a blocking call would. Second, the POL selects the procedure before commanding Start, so the module knows which sequence to run. Third, the result arrives as report values read at completion, not as the return value of a function call.

Choosing variables and subscriptions over methods is a pragmatic decision. OPC UA methods are synchronous from the client’s perspective and awkward across reconnects, while variables with monitored items give you queued data changes with a defined sampling and queue behaviour. If you want detail on that mechanism, our OPC UA protocol guide explains monitored items and publishing intervals.

Security considerations

Because every PEA is its own server, certificate management scales with the module count. A plant with forty modules has forty server application instance certificates to issue, trust, renew and revoke, plus the POL’s client certificate. Our OPC UA security and GDS trust-list guide covers the global discovery server approach that makes this tractable. The MTP does not remove this burden; it concentrates it. A prudent design uses signed and encrypted sessions, per-module trust lists and a documented certificate lifetime, and treats a module swap as a security event as well as an engineering one. For the broader zone-and-conduit view, see the ISA-95 and ISA-99 guide.

Alarms

The roadmap announced alarm handling in two profiles for MTP 2.0: a basic profile and managed alarms transported via OPC UA. The design question is who owns alarm state. In a modular plant the module detects the condition, but the operator acknowledges it in the POL. A managed-alarm approach standardises how the module reports condition, priority and acknowledgment, so the POL can apply a common alarm philosophy across modules from different vendors. Without that, a plant ends up with forty different alarm behaviours and a flooding problem.

Illustrative MTP fragment

The following is a deliberately simplified, illustrative AutomationML-style fragment to show the idea. It is not valid against the real MTP schema, and element names, attribute names and role class paths must be taken from the current specification and your vendor’s export.

<!-- ILLUSTRATIVE ONLY: not schema-valid MTP -->
<InternalElement Name="MixingService" ID="svc-001">
  <Attribute Name="ServiceName" AttributeDataType="xs:string">
    <Value>Mixing</Value>
  </Attribute>
  <InternalElement Name="ProcedureSlow">
    <Attribute Name="ProcedureId" AttributeDataType="xs:int"><Value>1</Value></Attribute>
    <InternalElement Name="SpeedSetpoint">
      <Attribute Name="Unit" AttributeDataType="xs:string"><Value>rpm</Value></Attribute>
      <Attribute Name="Min" AttributeDataType="xs:double"><Value>20</Value></Attribute>
      <Attribute Name="Max" AttributeDataType="xs:double"><Value>120</Value></Attribute>
    </InternalElement>
  </InternalElement>
  <ExternalInterface Name="CommandOp" RefBaseClassPath="OPCUAItem">
    <Attribute Name="Identifier"><Value>ns=3;s=Mixing.CommandOp</Value></Attribute>
  </ExternalInterface>
  <ExternalInterface Name="StateCur" RefBaseClassPath="OPCUAItem">
    <Attribute Name="Identifier"><Value>ns=3;s=Mixing.StateCur</Value></Attribute>
  </ExternalInterface>
</InternalElement>

What matters is the pairing: a semantic description (service, procedure, parameter with limits) bound to concrete OPC UA node identifiers. Everything the POL needs to generate a recipe step and a faceplate comes from that binding.

Illustrative client code

To make the write-command, observe-state pattern concrete, here is a minimal Python sketch using the open-source asyncua library. Node identifiers, enumeration values and the command encoding are illustrative placeholders; in a real project they come from the imported MTP file and the numeric command and state codes defined in the specification.

# ILLUSTRATIVE sketch: node ids and codes are placeholders, not normative values.
import asyncio
from asyncua import Client

URL = "opc.tcp://pea-reactor-01:4840"
CMD  = "ns=3;s=Mixing.CommandOp"
STATE = "ns=3;s=Mixing.StateCur"
PROC_REQ = "ns=3;s=Mixing.ProcedureReq"

START, RESET = 4, 2          # placeholder command codes
COMPLETED = 131072           # placeholder state code

class Handler:
    def __init__(self, done): self.done = done
    def datachange_notification(self, node, val, data):
        print("state ->", val)
        if val == COMPLETED:
            self.done.set()

async def run_service():
    done = asyncio.Event()
    async with Client(url=URL) as c:
        sub = await c.create_subscription(500, Handler(done))
        await sub.subscribe_data_change(c.get_node(STATE))
        await c.get_node(PROC_REQ).write_value(1)   # select procedure 1
        await c.get_node(CMD).write_value(START)    # then command Start
        await asyncio.wait_for(done.wait(), timeout=600)
        await c.get_node(CMD).write_value(RESET)

asyncio.run(run_service())

The sketch omits what production code must add: security policy and certificates, reconnect handling that re-reads the current state rather than assuming it, command acknowledgment checks, timeouts per state, and a policy for control-source arbitration. Those omissions are exactly where hand-written integrations tend to fail, and exactly what a commercial POL is paid to handle.

Engineering Workflow: MTP Versus a Classic DCS Project

Figure 4: The MTP engineering loop. Work is split between the module vendor, who owns PEA behaviour, and the plant owner, who owns recipes and topology.

In a classic DCS project, the integrator receives P&IDs, I/O lists and functional specifications, then writes the control modules, sequences, graphics and alarms in the DCS vendor’s engineering tool. Module vendors deliver skids with a vendor PLC, and the integrator either re-implements the logic or builds a custom gateway. The knowledge of how the skid should behave is split between the people who built it and the people who program the DCS around it.

In the MTP flow shown above, the split is cleaner. The module vendor engineers the PEA, including its control logic, and exports the MTP file from their tooling. The plant owner verifies that file, imports it into the POL, arranges modules into a topology and writes recipes. When a module is revised, the loop returns to the vendor.

What the claimed savings look like

The OPC Day Finland 2025 presentation attributes figures to NAMUR, ProcessNet, VDMA and ZVEI: up to 60 percent reduction in on-site CSV and equipment qualification, up to 80 percent more flexibility, up to 50 percent shorter time to market, up to 70 percent less engineering effort, and up to 50 percent smaller PEA requirement specifications by moving data-integrity, electronic records and audit-trail requirements to the POL. Read these correctly: they are association-sourced upper bounds (“up to”), not measured averages, and they depend on a mature module catalogue. I would plan a first project using none of them.

A worked, illustrative example shows why the direction is plausible even if the exact magnitude is unknown. Suppose a plant integrates six modules, and each classic integration requires 120 engineer-hours for gateway, sequencing, faceplates and testing. That is 720 hours. If MTP import plus verification of a pre-qualified module takes 40 hours each, the total is 240 hours, a reduction of two thirds. The numbers are invented for arithmetic only. The real lever is that the 120 hours collapse mainly where the module is a repeat of a known type and verification is lighter than re-implementation, not on the first, one-off module.

Verification replaces re-programming

The 2025 pharma source states that MTP files should be explicitly verified, covering service execution, critical-process-parameter alarm states and parameter and report values, and that separate computer-system validation should be avoided for automated manufacturing equipment. That is a statement about a regulated-industry quality approach, conditional on the company’s quality management system, as the same source notes. The practical translation: you replace reading and testing custom code with executing a structured acceptance test of every service against its declared contract. The MTP’s machine-readable nature makes that test automatable, and the PI announcement mentions test specifications and conformity-testing tools as the next step for accredited labs.

Who owns what after commissioning

Ownership gets blurry in operations. If the module vendor updates the PEA firmware and the service interface changes, which party re-verifies, and who holds the MTP baseline? Good practice is to treat the MTP file as a controlled configuration item with version, hash and change record, bound to the PEA software version it describes. This is the same discipline you would apply to a recipe, and it is the first control to break in organisations that treat the file as “just an export”.

Trade-offs, Gotchas, and What Goes Wrong

MTP is not a free lunch, and the failure modes are instructive because they cluster at the seams between organisations rather than inside the technology.

Specification churn and partial inconsistency. The PI roadmap itself called the many document versions partially inconsistent. A PEA vendor implementing 1.0-era documents and a POL vendor implementing a later draft can both claim MTP support yet fail to interoperate on a detail such as operation-mode handling. MTP 2.0’s profile approach and conformity-testing plans are aimed squarely at this, but until testing is routine, “MTP-capable” is a claim to be verified in a pilot, not assumed from a datasheet.

The orchestration layer is a new single point of coordination. Because the POL owns the operator experience, audit trail and alarm handling, its outage removes visibility over every module at once, even though each PEA keeps running its local control safely. Design for degraded operation: what does each module do when the POL session drops mid-service? A module that continues to Execute indefinitely, or one that drops to a safe state after a timeout, are very different behaviours, and the MTP does not decide which is right for your process.

Loop-coupled processes do not fit. The model assumes modules with clear service boundaries and slow coordination. Tight cross-module control, where one module’s fast loop depends on another’s measurement, is awkward through a client-server round trip with subscription latency measured in hundreds of milliseconds. Those couplings belong inside one PEA or need a different design. Modularisation is a process-engineering decision first; automation merely follows it.

Lowest-common-denominator risk. Standard data assemblies and a standard state machine make heterogeneous modules look uniform, and uniformity hides detail. A sophisticated analytical module may have capabilities that the standard library cannot express, pushing vendors toward proprietary extensions, which then defeat the plug-and-produce goal. The energy-data paper by Reiche, Gehlhoff and Fay on arXiv is a good example: the authors find that energy data is not explicitly considered in the current MTP status, that only an analog indicator element can show energy values, and that adding a richer data object requires extending the library, with their proposal validated on a single laboratory example. It is a reminder that the library is finite.

Safety is out of scope for orchestration. MTP orchestrates; it does not replace a safety instrumented system. Interlocks and emergency shutdown stay in the PEA’s safety layer. The pharma source says NAMUR and PNO work on PEA diagnosis and safety information is still in progress, so do not assume a standard safety interface exists.

Cybersecurity surface multiplies. Forty OPC UA servers means forty attack surfaces, forty certificate lifecycles, and a POL client with broad write access to all of them. Segmenting module networks and restricting the POL’s write permissions to service command nodes is advisable. The upcoming alignment of the NAMUR second-channel idea, covered in our NAMUR NOA tutorial, is a complementary pattern: NOA gives read-only monitoring and diagnostics access without touching the core control path, whereas MTP is the core control path for modular units. Mixing the two roles on one connection is an anti-pattern.

Brownfield assumptions. A 2019 summary described a brownfield use case in which a package unit is bought, connected over Ethernet, its MTP exported and imported into the DCS. That works when the unit’s vendor ships an MTP. For legacy skids that do not, wrapping them with an MTP-compliant gateway reintroduces the custom engineering the approach was supposed to remove.

Validation savings are conditional. Both claims in the pharma source, reduced on-site validation and pre-qualified smart modules, depend on the regulated company’s quality management system. A quality unit that insists on re-testing every module in full will give you the engineering benefits and none of the validation ones.

Data-model gaps at the edges. Batch genealogy, material tracking and unit-procedure naming sit across the PEA/POL boundary and the MES above it. Where ISA-95 style information flows are needed, plan the mapping explicitly, because the MTP defines how to run a service, not how to describe the lot.

Practical Recommendations

Start with the question of whether your process genuinely benefits from modularity. The strongest cases are multi-product plants with frequent reconfiguration, capacity that is added in repeated identical units, and regulated production where validated, reusable behaviour is valuable. A single-product continuous plant with fixed topology will see little payoff and will pay the full cost of a new engineering paradigm.

Pick a pilot with two or three modules from different vendors, because multi-vendor interoperability is the actual claim to test. Insist that vendors state which MTP document versions they implement, and ask how they plan to follow MTP 2.0 and any future conformity testing. Define acceptance as an automated test of each service’s states and parameters rather than a demonstration.

Treat the POL as a strategic choice. Check that it supports your intended MTP version, imports the files you will receive, handles redundant OPC UA sessions and your security model, and exposes recipe and batch-record interfaces to your MES. Then treat each MTP file as a configuration-controlled artefact with a change process.

A short checklist for a first project:

Confirm which MTP document versions the POL and each PEA implement, and test cross-version behaviour.
Decide the loss-of-communication behaviour of every service and document it in the module specification.
Keep safety interlocks in the PEA’s safety layer and verify they function with the POL disconnected.
Issue per-module OPC UA certificates, restrict POL write access to command nodes, and plan renewal.
Define an MTP baseline process: version, hash, owner, and re-verification triggers on firmware change.
Automate service acceptance tests against the MTP contract.
Map report values to your batch record and MES before the first campaign, not after.
Budget the first project at full engineering cost; measure the second to see the savings.

If you work on the plant-network side, the Ethernet-APL reference architecture is relevant to how field-level devices inside modules will increasingly connect, which affects what a module can expose cheaply.

Frequently Asked Questions

What is a module type package (MTP)?

An MTP is a standardised, vendor-neutral description of a process module’s automation interface, defined in the VDI/VDE/NAMUR 2658 guideline family. It is built on AutomationML and describes the module’s services, data objects, operator-display instructions and OPC UA communication so that an orchestration layer can integrate the module without hand-written code. It works like a device driver file for a whole process skid, and it is moving toward the IEC 63280 series.

What is the difference between a PEA and a POL?

A process equipment assembly (PEA) is the self-contained module, with its own PLC and local control, that provides a process function such as dosing or reaction. The process orchestration layer (POL) is the higher-level control system that imports the MTP files, runs recipes, hosts the operator interface, and handles alarms, audit trail and historian functions. The POL acts as OPC UA client and each PEA acts as OPC UA server.

How does MTP use OPC UA?

Each PEA runs an OPC UA server exposing data assemblies and services. The POL connects as client, writes command and procedure variables, and monitors state and process values through subscriptions. Runtime and communication are specified in Part 5 and the OPC UA-specific Part 5.1, and OPC UA server profiles for MTP were clarified in MTP 2.0. The model favours variables and subscriptions over blocking method calls, which tolerates slow modules and reconnects.

What is the status of VDI 2658 and IEC 63280?

VDI/VDE/NAMUR 2658 exists as a multi-part family, and NAMUR, ZVEI and PI announced a consolidated, profile-based MTP 2.0 document set in February 2025, with a final version planned from summer 2025. IEC TC65 working group 14 started work on IEC 63280 in February 2024, beginning with the general concept part. I could not confirm a published IEC edition, so verify current status with NAMUR, PI and IEC before citing it.

Does MTP replace a DCS?

No. It changes how modules are integrated into one. The POL is typically a function of a DCS or a modular-automation product, and it provides operation, alarming, recording and orchestration. What MTP removes is the per-module re-engineering of control logic and graphics inside the DCS. Loop control, interlocks and safety stay in each PEA. A plant can run a conventional DCS section alongside MTP-integrated modules.

Is MTP only for pharmaceuticals?

No. The requirements came from process automation, hybrid applications such as food and beverage and pharma, and discrete manufacturing, according to the PI announcement, and the specification targets the process industry broadly. Pharma is a visible early adopter because validated, reusable behaviour is especially valuable there, and the 2025 pharma source names a first flexible modular GMP plant on the standard. Chemical and specialty plants with frequent reconfiguration are equally natural fits.

Module Type Package (MTP) and Modular Production: VDI 2658, POL Orchestration and OPC UA Process Modules (2026)