Skids that plug into the batch system: what MTP changes for integration and qualification

The chromatography skid arrived on time, with its own controller, its own operator panel and a document listing several hundred tags. The automation team then spent weeks rebuilding in the distributed control system what the supplier had already built in the skid: the tags, the alarm texts, the screens, and a sequence to start, hold and stop it from the batch recipe. At the site acceptance test (SAT), “hold” turned out to mean something different on each side of the interface.

That scene is a composite, and anyone who has integrated purchased equipment into a pharmaceutical plant will recognise every step of it. The Module Type Package (MTP) is the process industry’s attempt to stop paying for that work twice. The supplier describes the skid’s functions, data and screens once, in a standard file, and the plant’s control layer imports it. For a site under good manufacturing practice (GMP) the saving is real, and it moves the qualification effort rather than removing it.

Modules, services and an orchestration layer

MTP is defined by the VDI/VDE/NAMUR 2658 series, written in Germany by the engineers’ association VDI, the electrical engineering association VDE and NAMUR, the user association of automation in the process industries. Part 1, published in October 2019, sets out the general concept and interfaces. A revision of Part 1 was issued as a draft in January 2022.

Three terms carry the whole idea. A process equipment assembly (PEA) is the module: a skid with its own controller, able to run on its own. The process orchestration layer (POL) is the plant-level system that coordinates the modules. The MTP is, in the words of Part 1, what “defines and describes the interfaces and functions of the automation technology of modules”, so that a module can be integrated into the orchestration layer.

The central shift is service-based control. The orchestration layer does not drive the skid’s valves and pumps. It calls services that the module offers, with parameters, and the module runs its own procedure and reports its state. Anyone who knows batch control will see the family resemblance with an ISA-88 phase, and the InTech report that started this article describes the aim exactly that way: unit operations integrated into the ISA-88 procedural engine of a GMP plant’s supervisory system.

The series grew part by part. Part 2 (November 2019) models the operator displays, Part 3 (September 2020) defines a library of data objects for sensors, actuators and interlock logic, and Part 4 (October 2022) models the module services: their states, parameters and procedures, and the behavioural contract between a service and the orchestration layer. Part 1 describes the manifest of the package in AutomationML, and uses OPC UA (OPC Unified Architecture) as the example of the module’s communication interface.

The 2019 edition of Part 1 is explicit about what it left for later. Its introduction lists diagnosis, alarm management, functional safety and the “validation of MTPs and modules” as topics planned for further standards, and names secure communication between modules among the subjects to be added. For a regulated site that sentence matters more than any brochure: the validation of a modular plant stays with the people who run it.

What the plugfest tested

Interoperability is only worth something if modules from one supplier run under the orchestration layer of another. BioPhorum, the biopharmaceutical industry collaboration, has tested exactly that in plugfests. InTech reported in June 2021 on the session held in May 2021, run remotely: services of bioreactor, chromatography and filtration modules from three equipment suppliers were driven from three different orchestration layers, with six executions running at once on two modules.

The same report says issues were found and documented, and that this was the point of the exercise. That is the right reading. A plugfest proves that the standard can work between vendors. It does not prove that a given skid, with a given package version, behaves as your process requires, which is the question qualification answers.

Where the qualification effort moves

With a conventional skid, the site tests the supplier’s logic and its own integration code together, mostly at the site acceptance test. With a module, the two separate cleanly. The services are the supplier’s product and can be tested at the factory acceptance test (FAT), against the user requirements, as a closed unit. The site then tests what is genuinely new: the import into the orchestration layer and the way the recipe uses the services.

EU GMP Annex 15 (2015) already allows the saving. Clause 3.6 lets documentation review and some tests be performed at the FAT “without the need to repeat on site at IQ/OQ” where appropriate and justified, “if it can be shown that the functionality is not affected by the transport and installation”. A module whose services were tested against a frozen package version, and whose package is imported unchanged, is close to the textbook case. FAT and SAT: what the supplier’s tests can prove for you sets out the conditions.

That only works if the user requirements specification (URS) asks for it. Write into it that the skid is delivered with an MTP to the VDI/VDE/NAMUR 2658 parts in force, which services it must offer, with which parameters and limits, and what the module does when the orchestration layer stops talking to it. A URS that drives the qualification explains why each of those lines must be testable.

The package is a configuration item

An MTP file is a description of a validated interface. When the supplier fixes a bug or adds a parameter, a new package arrives, and importing it changes what the orchestration layer can command. Annex 15 clause 11.4 asks that planned changes be evaluated with quality risk management for their impact on validation, among other things, and an MTP version is no exception.

In practice: record the package version and a checksum of the file at the FAT, keep the file under document control, and compare it with what the orchestration layer imported before each campaign or at the periodic review. A package edited on site to make an import work is a change like any other, with a record, an owner and a test.

The batch record needs the same attention. Decide where each value is recorded and time stamped: in the module, in the orchestration layer, or in both. A set point changed on the skid’s local panel during a run must leave the same trace as one sent by the recipe, since Annex 11 clause 9 asks for an audit trail of GMP-relevant changes based on a risk assessment. Metadata makes the number explains what a value loses when its context stays behind in the module.

Every module is a server on your network

The orchestration layer talks to each module over OPC UA, so every skid brings an OPC UA server into the plant network. OPC UA defines three message security modes in Part 4 of its specification: “No security is applied” (None), messages signed but not encrypted (Sign), and messages signed and encrypted (SignAndEncrypt). Which one a module uses is a configuration choice, and on commissioning day None is the one that connects first.

Put the answer in the purchase specification: signed and encrypted sessions, named user accounts rather than anonymous access, a defined way to install and renew certificates, and no other services open on the module’s controller. Then treat the modules as a zone and the link to the orchestration layer as a conduit, as in zones and conduits: start from the risk.

On the projects we see, the security of purchased skids is discussed after the FAT, when the configuration is frozen and every change has a price. A modular plant multiplies that problem by the number of modules, which is why it belongs in the first version of the specification.

Where to start

1. Ask the question in the next request for quotation. For one skid, ask whether the supplier delivers an MTP, to which parts of VDI/VDE/NAMUR 2658, and which services it contains. The answers sort suppliers faster than any demonstration.
2. Check your orchestration side. Ask your control system supplier whether it imports MTP files, which versions, and what it does with services it cannot map.
3. Write the package into change control. Before the first module arrives, decide who owns the file, where it is kept, and how a new version is assessed and tested.

Five common mistakes

1. Taking a plugfest as a qualification. It proves interoperability between vendors, not fitness for your process.
2. Buying the skid before writing the services. Without services and parameters in the URS, the package describes whatever the supplier had.
3. Leaving the package outside change control. A new MTP file changes what the orchestration layer can command, even when no line of plant code changes.
4. Accepting “None” as the OPC UA security mode. It is the quickest to commission and the hardest to change once the module is qualified.
5. Forgetting the local panel. Changes made on the skid while it runs under the orchestration layer still belong in the batch record.

The package does not remove the integration. It moves it to the supplier, into a file that becomes part of your validated state, and it should be specified, tested and controlled like one.

References

• Bill Lydon, “BioPhorum Plugfest Tests Plug-and-Play Equipment Interoperability”, InTech (ISA), June 2021, Industry Update: isa.org
• VDI/VDE/NAMUR 2658 Part 1:2019-10, Automation engineering of modular systems in the process industry – General concept and interfaces: vdi.de
• VDI/VDE/NAMUR 2658 Part 2:2019-11, Modeling of human-machine interfaces: vdi.de
• VDI/VDE/NAMUR 2658 Part 3:2020-09, Library for data objects: dinmedia.de
• VDI/VDE/NAMUR 2658 Part 4:2022-10, Modelling of module services: dinmedia.de
• OPC Foundation, OPC 10000-4 Part 4: Services, release 1.04, §7.20 MessageSecurityMode: reference.opcfoundation.org
• EudraLex Volume 4, Annex 15: Qualification and Validation (2015), clauses 3.6 and 11.4: health.ec.europa.eu
• EudraLex Volume 4, Annex 11: Computerised Systems (2011), clause 9: health.ec.europa.eu