Mr. Mersch, Mr. Wetzel, the term Module Type Package (MTP) can scarcely be avoided in the context of Process Industry 4.0. What is behind it?
Wetzel: The MTP describes the interfaces of an associated process engineering module. This means that this file – in other words the MTP – can be used to integrate process engineering modules into an overall context. The modules and their functionalities are combined in a Process Orchestration Layer (POL) and orchestrated from there. The functionality of the POL can be represented, for example, by a DCS.
Mersch: The MTP therefore describes communication between the POL and the modules. The modules can be understood as intelligent units, which have their own control system and only communicate with the higher-level DCS via this control system. The MTP concept is described in the VDI/VDE/Namur 2658 guideline.
Even today, process engineering plants are frequently constructed in a modular way. What is the added value of using the MTP concept for this?
Wetzel: One of the traditional approaches for modular processing plants is their purely mechanical modularisation. In particular, this allows simple transport, since the plant can be disassembled into its modules and the modules can be transported individually and then reassembled. However, no flexibility is gained with regard to the process itself in this way. This means that while I can disassemble my plant into individual modules, they cannot be reassembled in a different way again or simply extended. Such flexibility is increasingly demanded, however, since shorter production lifecycles should mean that existing plants or modules can be reused to produce other products.
Mersch: Some sensors and actuators today are still connected to the DCS directly or via a system bus, which means that if a plant is repurposed, the process entities have to be configured individually in the modules – the MTP will change all this. Another essential step is therefore to modularise the automation and therefore the encapsulation of the control logic into the individual modules. This too is already frequently used today, though proprietary interfaces are required for this purpose, which are used to control the modules. The MTP completes this development by defining these interfaces in a uniform and vendor-neutral manner. This means that modular process engineering plants can be constructed in the shortest possible time from existing modules from different manufacturers. Such recombination has no major impact since only the orchestration and not the control logic has to be adapted.
With the introduction of the ELX terminal series in 2018, Beckhoff expanded its product portfolio for the process industry. To what extent does Twincat MTP contribute to this?
Wetzel: At Beckhoff, we see ourselves especially as a system provider for module manufacturers. With the introduction of the ELX terminal series, we offer module manufacturers the possibility to connect sensors and actuators directly from zone 0/20. In combination with our other I/O interfaces, controllers, and control panels, we offer module manufacturers a complete solution for the use of automation technology in explosion-sensitive areas. Moreover, Twincat represents an established engineering environment for programming the module. Twincat MTP now extends this environment with the option of module definition, MTP export, and automatic code generation for supporting module programming.
Where do you see the greatest challenges in module development?
Mersch: The crux of the MTP is the standardisation of the interfaces and therefore the possibility of interoperability. To ensure this, it is necessary to include relevant specifications concerning the behaviour of the individual elements of a module in the guideline. In turn, module manufacturers will then have to take account of and implement these specifications in their modules. However, it cannot be expected in practice that every module developer will have detailed knowledge of the guideline. The goal in developing Twincat MTP was therefore to minimise the guideline expertise required by the module manufacturer and have these requirements implemented automatically. This is done primarily through the automatic generation of a PLC template based on the previously defined module information of the MTP.
How can Beckhoff module manufacturers develop MTP-capable modules with Twincat?
Wetzel: The workflow for developing a module begins initially with the definition of the module in Twincat MTP Engineering. All module aspects, such as the services (functionalities) and their dependencies, can be defined in this environment. Because this information already adequately defines the interfaces of the module, the MTP can then already be exported. Furthermore, this information is now used to generate the PLC template based on the Twincat MTP library. This code generation can be adapted individually if necessary with the Twincat XCAD interface. The pre-engineered code can then be completed through state programming of the predefined services. Finally, Twincat then ensures automatically when the configuration is activated that communication can be established via OPC UA from the POL as described in the MTP.
How can module manufacturers incorporate their own P&ID and other planning data into the workflow?
Mersch: The MTP additionally offers the possibility to define a visualisation blueprint. The POL can then use this to generate an overall visualisation of all modules from the MTP descriptions in the same look & feel. It therefore makes sense to extract the information needed for this purpose from the P&ID of the module. Instead of likewise integrating the P&ID editor in Twincat and thus making the module manufacturer dependent on it, we have opted for an open approach to integrating the planning data in the workflow. Twincat MTP can be used to import an incomplete MTP, which was previously generated by a P&ID editor, and then complete it. Alternatively, the Twincat MTP automation interface can be used to integrate proprietary data sources. The interface provides an API for the module manufacturer, which allows programmatic access to the MTP project. Existing data from P&ID editors or data sources can therefore be used even if they have not already implemented a MTP export. As a result, the module manufacturers can continue to use existing tools and databases.
In your opinion, are there still aspects that could be improved in the MTP?
Mersch: The VDI/VDE/Namur 2658 guideline contains sheets 1 to 4 in the current version. Further topics will be dealt with in upcoming sheets and published as a supplement to the existing sheets. Important aspects will, for example, include module-to-module communication, the safety MTP, diagnostics/maintenance, and validation. However, even now the concept is at a sufficient stage to develop practical modules and fully exploit their flexibility. Thanks to our collaboration in the VDI-GMA expert committee 5.16, we not only know about these enhancements early on, rather we are involved in actively shaping them. Of course this also gives rise to enhancements for Twincat MTP – and possibly also to early evaluation.
Beckhoff Automation GmbH & Co. KG, Verl, Germany
„The MTP is based on a uniform and manufacturer-independent definition of the interfaces.“
