Modularization of plants is seen as the way to solve challenges faced by the process industry. ABB, with others, has developed concepts and products for the automation of modular process plants. Complementing the article in the previous edition of ABB review, plant orchestration and pilot study experience are now discussed.
Mario Hoernicke, Katharina Stark ABB Corporate Research Ladenburg, Germany, firstname.lastname@example.org, email@example.com; Axel Haller ABB Industrial Automation Mannheim, Germany, firstname.lastname@example.org; Ralf Jeske ABB Industrial Automation Minden, Germany, email@example.com; Henry Bloch, Alexander Fay Helmut Schmidt University Hamburg, Germany; Alexander Wittenbrink Invite GmbH Leverkusen, Germany; Torsten Knohl Bayer AG Leverkusen, Germany; Stephan Hensel, Leon Urbas, Anna Menschner Technical University of Dresden, Dresden, Germany
For process plant owners, modularization is seen as a promising technology that will solve many of the challenges they face, such as improved flexibility and interoperability between plant assets. For that reason, ABB has been working with several groups (Bayer, the Technical University of Dresden, INVITE – a public-private partnership of TU Dortmund and Bayer Technology Services GmbH – and the Helmut Schmidt University of Hamburg) since 2014 on ways to effectively automate modular process plants.
A modular automation system has two layers, connected by a network.
• The module layer: a small controller executing the logic of a single process module. • The orchestration layer: here, process modules are integrated and combined to form one p
Unlike a traditional plant that may be based on many thousands of tags, a modular plant is more like an object-oriented software environment, but with a function-oriented approach, based on modules. One achievement of the joint project is the definition of the process module interface, the so-called module type package (MTP), that allows seamless integration of process modules into an orchestration system  →1.
Within the MTP, the automation interfaces required for the communication between the module automation system and the overlying orchestration system are specified. The MTP is used to identify the functionality and communication interfaces of a modular automation system and is, therefore, the key to the low automation engineering effort promised by modular plant architectures.
The module layer is assembled from the needed module types, which can be chosen by the engineer. Every module provides a set of encapsulated process functions, called services, that can be orchestrated from a supervisory control system. These services describe process functions, such as mixing, tempering or heating. The modules work together to fulfill the requirements of the plant.
When building a new system, the module types are first engineered then integrated into the supervisory system. By re-using modules of the same type, the engineering effort for the plant can be dramatically reduced.
The communication between the module layer and the orchestration layer is via OPC UA. The supervisory control system is an OPC UA client that connects to the modules’ OPC UA servers and uses them to communicate the required commands to the module.
For the more modest requirements of the module layer, a smaller automation system, like a Freelance AC700F controller or the B&R X20 family, can be used, for instance. For the orchestration layer, ABB’s Extended Automation System 800xA has been chosen.
On top of the modules is the orchestration layer. The orchestration layer controls the modules and the services they contain – starting, stopping and visualizing them – and shows the module’s HMI, according to the module specification as defined in the MTP. A typical orchestration layer does not use another controller but controls the modules using OPC UA via, for example, a normal PC. Since the modules are defined in a very convenient manner in the MTP, the engineering of an orchestration system is very simple and fast.
Orchestration layer engineering
Orchestration layer engineering has three parts: a module type library, the definition of the plant structure and the definition of the control philosophy.
An essential part of the concept is the extensible module type library. Every module type used is imported into the library and is accessible for the other parts. Import is done by simply selecting an MTP file. No further configuration is needed.
Once the required module types are added to the library, the engineer can use them to define the plant structure. Every module type exposes its boundaries within the MTP. The boundaries can be treated as being connection points of the module, either for the material connection (connecting a pipe) or an information flow connection (connecting a signal). This information can be used for engineering the plant topology. For each module, a symbol is dropped into the topology editor and thereby an instance of the module is created →2. The modules are interconnected using their inputs and outputs, as designed in the MTP. Every module has a unique tag name so it can be identified in the supervisory control system.
The last step is the definition of a control philosophy. For the engineering of the control philosophy, an approach based on a sequential function chart (SFC) is used. Within the SFC, it is possible to define steps, transitions, and parallel and alternative branches, as described in IEC 61131 Part 3. The major difference to standard SFCs is the definition of the control logic behind the steps and transitions. Instead of having IEC 61131 Part 3 code, a list of the modules, the module’s services and the possible commands are used. The modules that are usable are automatically included in the tables based on the previously engineered plant structure.
With the quite simple engineering concept as described, a large portion of the runtime can be generated. The runtime consists of two major parts: visualization and orchestration of the modules.
From the engineering tool, the information required for the plant is imported into System 800xA. In System 800xA, all relevant information for the operators and plant engineers is automatically generated →2 – 4.
With the described generation of the orchestration System 800xA, engineering of the modular plant and setting up the orchestration runtime is almost completely automated. The user gets a fully functional operation environment that is immediately able to orchestrate the modules, once an online connection has been established.
To check the concepts work, a prototype has been applied to two situations: one in conjunction with NAMUR (the German user association for automation technology in process industries) and one – a real-life pilot case – together with the pharmaceutical company, Bayer AG.
The NAMUR application consists of three different module types, each having a set of between two and four functions that can be used:
• Feeder (BPxx), used four times in the plant. Functions: inertization, dose, discharge and fill.
• Mixing reactor (RPxx), used once in the plant. Functions: inertization, run and tempering.
• Distillation (KWxx), used once in the plant. Functions: inertization and run.
The modules are connected as shown in →5. Three of the feeder modules represent a dosing system for the mixing reactor. The mixing reactor feeds its product into a distillation stage that is also connected to a feeder module.
Also, there are heaters connected (HKxx in →5). These were neglected in the pilot application. Furthermore, the reactor can be exchanged for a continuous reactor (CM05 in →5). This module is very similar to the RP reactor and has not been used within this pilot application.
The process has to be inerted, so that there are no unwanted contaminant reactions, before the other functions can be executed. Thus, these other functions of the module types have to be interlocked with the inert function.
For each module type, an HMI must be provided. The HMIs were derived from the piping and instrumentation diagrams delivered by NAMUR for the case study.
A description of the modules and the modular plant was also delivered. Based on this information, the modules of the case study have been implemented using ABB components and the prototype. For each module type, an MTP has been created.
These MTPs have been used to engineer the plant topology and a sequence has been developed that is used for startup of the plant. The sequence stops once the plant has reached steady state.
Bayer pilot application
The pilot application provided by Bayer is a filtration plant system that produces active pharmaceutical ingredients. For the pilot use case, two of the modules have been equipped with ABB Freelance controllers and one will be equipped with a B&R X20 Controller. The engineering was done using the prototype and Freelance engineering software.
The services for every module type have been derived based on the piping and instrumentation diagrams, functional descriptions, sequences, code examples and tag lists provided. The conventional engineering documents were taken as input and converted into a service-based description.
Afterwards, the MTPs were created and added to the MTP library in the orchestration engineering tool. In this tool, the topology of the modular plant and the sequences to run the plant have been designed. One of the resulting modules can be seen in →6 .
Both pilot applications show that the concepts are working and deliver the targets of reduced engineering effort, reduced commissioning time and fast time-to-market.
Modular automation makes for speedy engineering
The pilot applications show that the modular automation concepts for modular plants, including operation and supervisory control, work. The engineering effort required to set up the system using this new approach was seen to be substantially less than traditional methods. Additionally, once a module has been commissioned, it is then available for re-use, which speeds future engineering and commissioning of a modular plant. Overall, effort for plant engineering and commissioning is greatly reduced.
The project delivered valuable input to MTP standardization efforts. Results gained within the project have also been fed into the community from different perspectives (university, corporate research, product development and plant owner). Thereby, the standard, which will be further maintained by the project partners, could be driven forward significantly.
The final result is a software product that can be used for the automation of modular plants. This will be further developed by ABB and partners to meet the latest requirements, integrate missing features and be compliant to the newest parts of the standard.
 Jens Bernshausen et al., “NAMUR Module Type Package – Definition,” atp edition, 58(1–2), pp.72–81, (2016).
 ABB, “Modular automation solution for life science company Bayer AG.” Available: new.abb.com/life-sciences/references/modular-automation-solution-for-life-science-company-bayer-ag