Process module engineering

Subscribe to ABB Review

ABB is in an industry/academic consortium that develops concepts for automating modular process plants. This article discusses the function-oriented – in contrast to traditional tag-based – architecture of modular plants. A companion article, in a future ABB Review, will describe pilot applications.

Katharina Stark, Mario Hoernicke ABB Corporate Research Ladenburg, Germany, katharina.stark@de.abb.com, mario.hoernicke@de.abb.com; Axel Haller ABB Automation GmbH Industrial Automation, Mannheim, Germany, axel.haller@de.abb.com; Ralf Jeske ABB Automation GmbH Industrial Automation Minden, Germany, ralf.jeske@de.abb.com; Henry Bloch, Alexander Fay Helmut-Schmidt Univer­sity of Hamburg, 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

Since 2014, ABB, 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 →5 have been working together on concepts for automating modular process plants.

05 The Helmut Schmidt University in Hamburg, Germany, is one of one of the partners working with ABB on concepts for automating modular process plants. (Photo courtesy of The Helmut Schmidt University).
05 The Helmut Schmidt University in Hamburg, Germany, is one of one of the partners working with ABB on concepts for automating modular process plants. (Photo courtesy of The Helmut Schmidt University).

In contrast to traditional plants, modular plants are not assembled using tag-based engineering but instead employ a function-oriented approach, comparable to object- or service-oriented concepts from software development →1. This new automation system architecture requires new engineering and operation concepts.

01 Modern process plants are complex undertakings that require new engineering and operation concepts. A modular automation-enabled process automation approach overcomes many of the challenges of process plants.
01 Modern process plants are complex undertakings that require new engineering and operation concepts. A modular automation-enabled process automation approach overcomes many of the challenges of process plants.

To help supply these, this project has focused on a modular automation-enabled process automation solution. This article describes modular process plants and will show the results of research executed in this context. Pilot applications will be described in a companion article, to be published in a future edition of ABB Review.

About modular process plants
Modularization of process plants is seen as a promising way to solve upcoming requirements from the process industries, such as improved flexibility and interoperability between plant assets. For that reason, several working groups within the German user association of automation technology in process industries (NAMUR) have been established to work together with ZVEI (German association of automation technology vendors) to create requirements and concepts for the automation of modular plants. The expected result is a definition of a process module interface, the so-called module type package (MTP), that allows seamless integration of process modules into an orchestration system [1] →2.

02 Engineering workflow of modular process plants [1].
02 Engineering workflow of modular process plants [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.

Scope of the research project
Each partner was accountable for a specific part of the project: The universities selected the useful technologies and developed concepts; ABB then developed the prototype based on these concepts, integrating it into the ABB tool landscape, using the ABB Extended Automation System 800xA and the ABB Freelance DCS (distributed control system). Working together with INVITE the prototype was then used to run a pilot based on a Bayer plant to show that the overall concepts fit the given requirements.

The prototype led to a product that is usable for a modular automation system [2]. The input given to the working groups of NAMUR, ZVEI and VDI/VDE led to the specification of a standard – VDI/VDE/NAMUR Guideline 2658 “Automation Engineering of Modular Systems in Process Industry” – which specifies the MTP.

Modular automation layers
A modular automation system has two layers: the module layer, which is a small controller executing the logic of a single process module, and the orchestration layer, which integrates process modules in order to combine them into one process plant. For each layer, different automation systems have been chosen. A network connects the layers →3.

03 Architecture of ABB’s modular automation system.
03 Architecture of ABB’s modular automation system.

A specialty of modular process plants, compared to conventional plants, is that the modules are not orchestrated in a tag-based way. Every module provides a set of encapsulated process functions, called services, that can be orchestrated from a supervisory control system. Every service describes a process function, such as mixing, tempering or heating. By controlling the services in the correct order, the integrated modules will work together and fulfill the requirements for the specific plant.

The engineering is done differently, too. First, the module types are engineered. These module type descriptions can later be integrated into the supervisory system; instances can be created. By re-using modules of the same type, the engineering effort for the plant can be dramatically reduced →6 .

06 By re-using modules of the same type, the engineering effort involved in automating plants such as the one shown here can be dramatically reduced.
06 By re-using modules of the same type, the engineering effort involved in automating plants such as the one shown here can be dramatically reduced.

The MTP facilitates integration of the modules. Even though the pilot application only uses ABB components, it would be possible to integrate third-party modules. The system is fully compliant with VDI/VDE/NAMUR 2658 part 1 – 3 [3 – 5].

The communication between the module layer and the orchestration layer is done using OPC UA. Every module provides an OPC UA server that exposes the module’s services and tags to the supervisory control system.

The supervisory control system is an OPC UA client that connects to the modules’ OPC UA servers and uses those to communicate the required commands to the module. For the module layer, where usually only a few I/Os have to be controlled, a smaller automation system, like a Freelance AC700F controller or the B&R X20 family, can be used, for instance.

For the orchestration layer, System 800xA has been chosen. In a first step, System 800xA is used for the visualization and supervisory control of the modular plant. When the specification of the MTP is developed further, with System 800xA, the new features (like alarm and event handling, information and history management) can be added easily.

Module layer
The module layer represents the functions that the process plant needs to fulfill its purpose. The module layer is assembled from the needed module types, which can be chosen by the engineer.

In a first engineering step, the modules have to be engineered. The module type engineering is based on the standard [3 – 6] in a vendor-neutral way and later, when the engineering has finished, the required automation system is chosen.

Module type engineering
The engineering of the module types has been designed to fit with the different aspects that are described in the MTP. At present, the aspects that are already (partly) defined within the community are:
• Definition of communication with a module [3]
• Definition of HMIs (human-machine interfaces) of modules [4]
• Definition of tags of modules [5]
• Definition of services of modules [6]

In future, the guideline will include further aspects, such as alarm management and safety, which is not defined at present. Nevertheless, the general concepts should work for those aspects, as well.

For the module type engineering process, a four-step, top-down approach is proposed →4. Unlike the engineering of conventional plants, the HMI is engineered first.

04 Proposed engineering workflow for a module.
04 Proposed engineering workflow for a module.

The HMI consists of symbols and lines that visualize the equipment and process flow →7.

07 HMI editor for a module.
07 HMI editor for a module.

While defining the symbols and giving them a tag name, the tag list with the used process equipment is automatically generated. After the creation of the HMI, the tag list contains all required tags and the tag parameters can be engineered →8. This is done within a tag list editor, similar to a tag list of a conventional plant.

08 Tag editor for a module.
08 Tag editor for a module.

Based on the information engineered for a module type, the automation logic for the target system (here, Freelance) and the module type package can be automatically generated from the tool.

For Freelance, several code fragments are generated that can be imported into a Freelance project and immediately downloaded to a controller.

From the service definition, the automation logic for Freelance can be generated. For each service, a state-machine is produced that implements the states defined in the editor. In order to define the logic to be executed in every state, an extended cause and effect (xC&E) editor can be used to engineer the service behavior. The state logic is automatically generated and can be executed immediately after the import, with no further manual effort. Since the module HMI is shown in the process orchestration layer (POL), there is no need to generate an HMI for the module automation system. The module automation system only consists of the control for the equipment and the services.

By using this method, fully functional software for the automation system is generated without having any manual effort.

The future of modular automation
The techniques presented here for automating modular process plants dramatically reduce engineering effort. The project has delivered valuable input for MTP standardization and the software products resulting from the project will further facilitate the roll-out of this approach to modular process plants across wider sections of the industry. Future research will investigate further aspects of modular automation systems – for example, alarm management, history management, advanced process control, intermodule communication, change management and simulation and testing of modular plants. Those topics will shape the future of the process industry.

References
[1] Jens Bernshausen et al., “NAMUR Module Type Package – Definition,” atp edition, 58 (1–2), pp.72–81, 2016.
[2] ABB launches world’s first commercial modular enabled process automation solution.” Available: https://new.abb.com/news/detail/5035/abb-launches-worlds-first-commercial-modular-enabled-process-automation-solution
[3] VDI, The Association of German Engineers, “VDI/VDE/NAMUR 2658: Automation Engineering of modular systems in the process industry. Part 1: General concept and interfaces,”
January 2018.
[4] VDI, The Association of German Engineers, “VDI/VDE/NAMUR 2658 (Draft): Automation Engineering of modular systems in the process industry. Part 2: Modelling of HMIs.”
[5] VDI, The Association of German Engineers, “VDI/VDE/NAMUR 2658 (Draft): Automation Engineering of modular systems in the process industry. Part 3: Base library.”
[6] VDI, The Association of German Engineers, “VDI/VDE/NAMUR 2658 (Draft): Automation Engineering of modular systems in the process industry. Part 4: Services.” Within the third step, the services of the module type are engineered. Every service is used to fulfill a process function of the module. A module might have just one or several services in order to fulfill its process step(s) or part of a process step.

Links

Contact us

Downloads

Share this article

Facebook LinkedIn Twitter WhatsApp