In the past few years, different sectors within the process industry – such as pharmaceuticals, fine chemicals, and the food & beverage sector – have encountered a shared and comparable set of emerging challenges. These challenges include:

• Demand for new products in rapid succession, 
• Pressure for faster delivery and lower prices,
• More customized products,
• Smaller batch sizes – down to a batch size of one.

Collectively, these factors necessitate a shift in the traditional approach to plant design.

Modular automation, Plug & Produce, Industry 4.0

The traditional approach – where a plant is designed specifically for a single process/product (or family of products) – although very efficient for mass-scale production and hence dominant in the process industry for decades, was found not well suited to these modern challenges. The need for continuous adaptation, quick customization, and flexibility has driven a new paradigm – modular automation.

With modular automation, the plant manufacturing process is divided into smaller parts that can be realized by individual modules, each module equipped with its own control logic. The modules are connected to a plant control system, where the plant owner can orchestrate the modules & manage the overall process. The modules can be added, reassigned, or removed like Lego blocks, depending on current production needs, ideally without re-programming. Plant control system can recognize new configurations – including new modules & their functions – and easily integrate new modules into the plant process – as the manufacturing recipes can be composed in a drag-and-drop manner using the functions exposed by the modules. This vision of modularity in process automation is called “Plug & Produce” and similar concepts lie at the heart of Industry 4.0.

Need for a common language

 “Plug & Produce” is a promising concept, but it brings forward new requirements – specifically:

• Plant control systems must:
  • Be able to recognize new modules and their capabilities in a plug-n-play manner,
  • Allow to easily integrate new modules into the plant process.
• Process modules must:
  • Expose necessary information about themselves to plant control systems. 

As follows, plant control systems and process modules must “speak the same language”. This language must be standard, vendor-independent, and cover all the information needed to integrate a module into the plant. The widely acknowledged candidate for such a standard is the Module Type Package (MTP).

Figure 1. The POL control screen shows the states and process values of the individual modules.
(Content Source: NAMUR, ProcessNet, VDMA, ZVEI)

Module Type Package

Module Type Package (MTP) is a series of standards produced by VDI / VDE(Society for Measurement and Automatic Engineering) together with NAMUR (User Association of Automation Technology in Process Industries) and ZVEI(the German Electrical and Electronic Manufacturers’ Association). 

Original concepts for MTP were introduced in 2013, with the first MTP standard documents published in 2017. The standards have evolved & matured since, with many active supporters from different areas:

Figure 2. MTP supporters as per Wago Nederland B.V.

Maturity

Today, the first module vendors already offer MTP-compliant modules ([1]). At the same time, the first vendors of plant control systems (e.g.: Emerson, Siemens, CopaData, and others) have showcased versions of their systems that can seamlessly integrate MTP-compliant modules into the plant. Thus, the MTP standard can be considered market-ready. Although not yet a widely adopted standard, it has the potential to rapidly become one.

Basic concepts

The MTP standard defines the following basic concepts:

• MTP-compliant process modules are called Process Equipment Assemblies (PEA), 
• MTP-compliant plant control systems are called Process Orchestration Layer (POL),
• Each PEA:
  • Must provide an MTP file – a manifest covering all information needed to integrate a PEA by the POL: HMI definitions, description of module elements & functions, alarms, maintenance, security & safety.
  • Exposes an MTP interface over a supported protocol (most commonly OPC UA), which must be compliant with the provided MTP file.
• A POL system:
  • Must be able to digest the MTP file to “onboard” a PEA,
  • Based on the information provided in the MTP file, POL can visualize & control the PEA.
    

PEA integration

MTP – New possibilities, new business cases

In the MTP world, you can handle scenarios that were previously difficult to achieve, for example:

MTP brings different benefits to different target groups: plant and lab owners, PEA producers, POL vendors.

Plant and lab owners

For plant and lab owners, MTP implementation promises the following benefits:

• Reduced costs, risks & time
  • Zero time and cost of new module integration,
  • Minimal testing / validating is required, as it was already done by the vendor.
• Easy to swap module X with an analogous module, even from another vendor,
• Production flexibility – especially for small batches:
  • Already used modules can be re-used for future processes,
  • New modules can be added almost immediately.
• Unified look & feel of plant-level HMI:
  • Same look and feel, even with different module vendors.

MTP may be particularly well-suited for:

• Labs, where the very nature of the business requires flexibility, small batches, quick time to deliver & rapid succession of products.
• Greenfield, where you start MTP from scratch, consume all the benefits immediately, and don’t have to worry about legacy non-MTP systems & modules.

Brownfield scenarios

In brownfield scenarios, the plant owners expect new versions of their existing control systems (DCS, SCADA, etc.) to gain POL capabilities. After that, it should be possible to gradually MTP-upgrade the modules and consume the first benefits – initially by reducing the time needed to integrate new modules. Finally, when all plant modules become PEAs, you can fully leverage all the MTP benefits in the plant.

Module manufacturers (PEA producers)

For module manufacturers, we can think of the following advantages of switching to becoming PEA producers:

• You can now expose only one standard interface instead of supporting many interfaces for different customers,
• Reduced time of integration of your module in the customer plant,
• Standardization of module elements according to industry best practices:
  • Module elements can be represented as MTP Data Assemblies with standard control logic,
  • You can reuse the module elements in different modules without any changes in controlling code,
  • You can build modules from a standard library of building blocks, like from Lego.
• PEA local HMI can be generated based on MTP standard – single-time effort, and it will work for every module, with a look & feel compatible with POL HMI view,
• You can easily enhance your modules with missing subcomponents from other vendors (provided those subcomponents are MTP-compliant),
• It is possible to expose only specific parts of your module in the MTP file,
• Opportunity to gain share in the new growing market when/if MTP gets widely adopted,
• If you don’t offer MTP, your competition might do it first and gain a competitive advantage.

Plant control system vendors (POL vendors)

For plant-level control systems providers – e.g.: DCS / SCADA providers, we can enumerate the following good reasons to become POL vendors:

• For big players in DCS/ SCADA e.g.: Siemens, Emerson, etc.:
  • Opportunity to gain share in a new growing market when/if MTP gets widely adopted.
• For smaller players:
  • You can provide a truly MTP-standard-driven POL solution and gain the potentially green market, especially for greenfield scenarios, where big players are not so flexible and not so ready to change their solutions.
• If you don’t offer MTP, your competition might do it first and gain a competitive advantage.

Potential for disruption

MTP has the potential to become a disruptive change.

For example, the MTP concept can be seen as a threat to the system integrators – because system integration is no longer needed if PEA provides the MTP file and the whole integration effort required is downloading this file to POL. Still, the current system integrators and new players can think of exploiting a possible niche, as there will still be many legacy non-MTP modules, that would be worth connecting to POL, preferably not in the old DCS/ SCADA way, but so that they are visible in the MTP world. 

The “MTP integrators” might offer to upgrade legacy non-MTP modules to PEAs by either reworking the OT code of such modules or providing an additional software/ box that would serve as an MTP adapter for the legacy modules to the MTP world. Similarly, the module vendors may choose to provide MTP adapters for their own legacy modules that they do not decide to convert to PEAs.

Wide adoption of MTP may also be disruptive for module vendors. As in the MTP world, the effort to integrate a new module is minimal, nothing prevents plant owners from replacing a module with a better / cheaper device from a different vendor.

Similarly, process control systems will be more easily interchangeable in the MTP world, as the PEAs are not tightly coupled to any specific POL system.

Even though module vendors and process control systems  providers may see those potential threats, they cannot afford to not implement MTP, fearing that otherwise they may be left behind when others implement it and provide it in their offering.

Adoption challenges

The outlined above stalemate position of MTP players may be one of the reasons why MTP does not move forward so quickly. Also, in brownfield scenarios, MTP implementation brings forth some considerable challenges – for example, you must decide on a strategy to manage the legacy non-MTP modules and PEAs. Should the non-MTP modules be integrated into the POL system in a traditional, DCS/SCADA way? But then you probably won’t be able to see such legacy modules in the MTP world, and the plant-level orchestration might become cumbersome. Alternatively, you may choose to upgrade legacy modules to MTP world using MTP adapters or exchange the non-MTP modules with analogous MTP-compliant modules from the same or different vendor.

Recap

Let’s summarize the most important points.

MTP concept is market-ready:

• mature enough to allow PEA implementation by module vendors, 
• the first existing POL systems can already ingest MTP files and handle such PEAs.

MTP is not yet a widely adopted standard, but it can rapidly become one. When that happens, those who are not ready will be left behind while others gain a competitive advantage.At A4BEE, we have the people, experience, and skills needed to support you in your MTP journey – see the A4BEE MTP offer for details.