Modular plant structures at greenfield and brownfield sites with PC-based control

The Module Type Package (MTP) is becoming increasingly widespread in the process industry, as evidenced by the successful implementation of its first industrial applications. Nevertheless, potential users face the challenge of having to familiarize themselves extensively with the standard in order to take full advantage of its benefits. A further issue is that the various application scenarios can quickly lead to confusion – especially in the context of brownfield applications. This comprehensive overview outlines the diverse ways in which modular plant structures can be easily implemented at greenfield and brownfield sites using PC-based control from Beckhoff.

The MTP concept allows users to benefit from a rapid time-to-market, short repair times, and cost-effective single unit production. This is particularly advantageous in greenfield settings, where the plants are fully modular in design. Comprising individual process equipment assemblies (known as PEAs or simply modules), this type of structure achieves maximum flexibility with minimal engineering effort thanks to its MTP-compliant interfaces. A packaged AML file describes all functionalities, individual control elements, communication aspects, and module structures in detail. The overarching process orchestration layer (POL) uses this information to automate the manufacturer-independent integration of the modules almost entirely and achieve plug-and-produce functionality in the process. In addition to tag mapping, this also includes the generation of user interfaces with a uniform look and feel. The only aspect that is handled manually is the orchestration of the functionalities, which is typically implemented using step chain programming.

The MTP concept is not only useful for greenfield plants, but can also showcase the advantages of automated integration into the control level in brownfield environments. The POL functionality is typically integrated into the existing SCADA or DCS systems. This means a software update can also provide existing plants with the ability to integrate MTP modules via plug-and-produce, thereby streamlining scalability in the process. The resulting hybrid architecture combines the best of both worlds and can be expanded on an incremental basis as required. It also means that complex integration using mapping tables and possibly even the additional development of control code in the DCS are no longer necessary. The modules can be integrated independently of the control system and replaced quickly if necessary to minimize downtime. The size of the modules is not fixed, but can vary depending on the application scenario. This means that several process steps can be combined into one larger module, while sophisticated analyzers such as those used in process analytical technology (PAT) can be standardized and integrated on a manufacturer-independent basis. The edge device integrated into the DCS with MTP ensures that analyzers from different manufacturers can be integrated without the need for reconfiguration. This is made possible by the standardized information model for field devices in process automation: PA-DIM.

In addition to the distinction between greenfield and brownfield at plant level, this analysis can also be carried out at a modular level. In terms of automation technology, a greenfield MTP module typically consists of the field devices, I/Os, a controller, and potentially also a control panel for local operation. A PLC program is implemented on the controller to instantiate the MTP interfaces and ensure compliance with MTP standards. The data points are made available to the POL via an integrated OPC UA server. As for the module itself, this can be made up of several functional units or functional equipment assemblies (FEA). Within different modules, an FEA may include elements such as a pump and its accompanying flow control sensor, presented in diverse configurations. In the event of an FEA malfunction within the module, the ability to replace it easily could also reduce the associated downtime without having to replace the entire module directly.

Modules with flexible functional units

It is not uncommon for modules to be designed to be flexible within themselves. This means that individual FEAs can be flexibly connected or removed without reprogramming the control system. These FEAs typically include IP67 remote I/O stations with sensors and actuators that can be flexibly integrated using EtherCAT hot connect or similar technologies. Smart devices can also be integrated directly into the module via Ethernet-APL.

For an MTP module to integrate these proprietary units, a fixed pool of compatible FEAs must be defined and pre-configured in the control program to allow the FEAs to be connected or disconnected as needed – even during operation. If this pool is defined at plant level, the FEAs can also be used across modules. It is essential for the overarching MTP of the module to support this inherent flexibility as fully as possible, with various approaches available for achieving this goal:

• Each supported configuration option has its own, customized MTP. The advantage here is that the functionalities offered always correspond exactly to reality; however, this is only possible for a manageable number of configurations. Furthermore, the appropriate MTP must be reconfigured in the POL after each configuration change.
• If there is a greater variety of configurations, the FEAs could be represented by dedicated operating screens so that the MTP contains a main operating screen and an additional operating screen for each FEA. Display elements could refer to the currently valid FEA operating screens. FEA-specific functionalities would be mapped using additional services or specialized execution types (procedures). Locking indicators can be used to diagnose whether the services or procedures are currently executable; however, this procedure can lead to the MTP becoming too confusing, as invalid elements have to be ignored. As things currently stand, there is also no option for dynamic jump labels between different operating screens, meaning that the operating screen change has to be carried out manually using the valid configuration displayed.

MTP gateway for retrofitting existing skids

In module brownfield situations, a common scenario is to retrofit an existing process technology skid to comply with MTP standards. This type of skid may already have its own controller or, as with the FEAs, it may simply represent a straightforward I/O solution. With an existing control system, there is often a requirement to adapt the current setup as little as possible. To achieve this, an additional controller is integrated as an MTP gateway, which maps the existing module to the MTP model. This allows information and behavior to be provided in line with the MTP standard.

Data is typically exchanged between the gateway and the existing controller via communication technologies such as EtherCAT, OPC UA, PROFINET, or an ADS interface. For example, existing LabVIEW™ controllers in laboratory automation can be extended with MTP functionality, and devices can be integrated via their serial interface. Depending on the performance and operating system of the existing control system, the gateway can also be implemented as a virtualized solution.

MTP hub for the implementation of several modules on a single controller

The classic structure of an MTP module includes a controller that makes the required data available to the POL via a dedicated OPC UA server; however, there are also various applications, particularly in brownfield contexts, in which this architecture is not desired and several modules are to be implemented on a single controller. Contributing factors may include the additional costs for multiple controllers, existing plant structures, and the advantages of streamlined deployment and program code maintenance. Although the modules are implemented on a single controller, they still need to be made available to the POL independently to maintain their plug-and-produce functionality and the ability to be flexibly added to or removed from the plant.

This behavior is achieved by combining the functionality of the MTP gateway with the flexible FEA approach and consolidating this into an MTP hub on a single controller. Within the MTP hub, a PLC runtime is instantiated for each lockable module, in which the specific process logic is implemented in line with MTP standards and an associated MTP file is exported in each case. The POL can continue to integrate the individual modules independently and flexibly via dedicated namespaces in the OPC UA server of the MTP hub and the generated MTP files.

Other than the modules sharing the same IP address, there are no differences to the conventional approach as far as the POL is concerned. The MTP hub therefore makes more sense in terms of both economic efficiency and implementation – especially in cases with many small modules. Another advantage is the ability to interconnect the different PLC runtimes in the real-time system – for example, to implement proprietary interlock or safety logic between the modules. Standardized communication between modules is only outlined in later sections of the MTP guideline.

By using the communication technologies of the flexible FEA approach, pre-configured modules can be connected to the MTP hub during operation without the need for reconfiguration. As with the MTP gateway, modules with I/O components only or with an existing controller can be integrated into the MTP hub. The concepts shown can, of course, be combined with each other at plant level.

PC-based control as the optimal framework

With its PC-based control architecture and native integration of the MTP concept into the TwinCAT development environment, Beckhoff provides a powerful and flexible platform that can be used to implement all the scenarios described. With TwinCAT MTP, module developers can benefit from an efficient workflow that reduces the required guideline knowledge and enables MTP export even before the module is programmed. As a result, the plant or module engineering can be parallelized and the MTP file can be used as a specification document, among other purposes. Based on the module definition, TwinCAT MTP can then automatically generate a large part of the required PLC program, as well as a web-based visualization.