Key points
Experiences from the demonstration project Module Automation with Safety-MTP
Faster planning, easier commissioning and, above all, significantly lower costs: both operators and engineers have high hopes for modular automation. For two years, HIMA, together with researchers from TU Dresden and other industry partners, discussed technology and opportunities at various events using a demonstration project, gaining important experience in the process.
Constant adaptations to new requirements are par for the course in the operation of process plants. Conversion and optimisation projects are usually started immediately after a new plant in the chemical-pharmaceutical industry has gone into operation.
On the one hand, this is because production must be optimised when market conditions and demand change, and on the other hand, it is done to change or improve product characteristics. The increasing demand for small batch sizes and fast product changes also leads to more and more upgrade and conversion measures.
However, the need to adapt automation as well as safety loops in classically automated plants requires significant modification effort: If, for example, a separation step consisting of a filter module is added, not only must the control technology for the automation functions be adapted, but the safety technology (functional safety) must as well. Functional safety refers to the part of the safety concept of a plant or system that brings a plant back to a safe state under all circumstances.
In order to simplify and standardise the integration of automation systems in the process industry, modular automation was developed with so-called Module Type Packages (MTP). MTP is an open standard that enables cooperation between different manufacturers of automation components and facilitates the exchange of data between the individual components.
The Module Type Package is a digital container that contains all relevant information about a system module: Function descriptions, configuration files, process variables, etc. By using MTP-compatible modules, plant builders and operators can configure, integrate and maintain automation systems quickly and easily. Modular automation thus supports the efficient construction as well as the flexible conversion of process plants.
However, though the advantages of modular automation may seem to be many and obvious, the new approach must also be fitted into the existing automation processes or the latter must be modified, to say nothing of the technical implementation of the MTP standard.
Moreover, functional safety also plays a decisive role in modular automation, because it forms the basis for safe operation and is a prerequisite for the issuance of the plant operating licence.
From safe module to safe system
In order to gain practical experience and demonstrate the feasibility of safe modular automation, industrial partners together with the P2O-Lab of TU Dresden started to plan and build a demonstration project in 2020.
Since 2021, the demonstration project has been shown at various events, including the NAMUR Annual General Meeting 2022, and at the Hannover Messe and ACHEMA, and it has served as a starting point for many technical discussions.
Before we report on the concrete experiences with the demonstration project in this article, let's start with a few basics: Modular plants consist of several prefabricated modules. Each of these modules carries out a process step and is therefore called a Process Equipment Assembly (PEA).
By interconnecting several PEAs at a higher process control level, the so-called Process Orchestration Layer (POL), the PEAs can be interconnected to form an overall plant. In this way, the PEAs can be orchestrated beyond their boundaries to execute complex procedural processes.
Using the standardised information technology interface – the Module Type Package (MTP) – the PEAs can be efficiently integrated into the POL and interconnected, which simplifies the implementation of plant configurations.
To implement functional safety in modular plants, the PEAs must be designed in advance to be safe and independent of the plant environment, so that as little as possible needs to be changed or expanded when they are interconnected.
Safety systems must be pre-planned on PEAs and, when interconnected, brought together as a functional safety orchestration layer (fSOL). In order to make this process as efficient as possible and similar to operational interconnection, the MTP must be extended to include safety-related considerations. This is done using a so-called Safety-MTP.
The fSOL orchestrates the safety services offered by the respective PEAs – as contained in the Safety-MTP – into one or more Safety Instrumented Functions (SIF). Safety services follow a state machine in which it is semantically described whether a safety service is, for example, “In operation” (the SIF is active and monitors the process parameters), “Triggered” (the SIF was triggered) or “Deactivated” (the output is inactive or bypassed).
Demonstration project highlights strengths and weaknesses of the Safety-MTP concept
So much for the theory and the goal of the Safety-MTP approach. But can it also be validated in practice? To answer this question, industrial companies together with the P2O-Lab of the TU Dresden have investigated as part of the demonstration project whether the components and systems available on the market have reached operational maturity. In addition, the researchers also wanted to know whether the standardised safety life cycles could also be transferred to modular plants.
The demonstration project forms a process consisting of a double-dosing PEA – i.e., two functional units – and a reactor PEA with stirrer. The ratio of the two dosed media is monitored for safety parameters using flow measurements. Each tank has an overfill protection, and each pump is protected against dry-running.
The dosing PEAs are additionally monitored for overpressure and the reactor PEA for overtemperature. These SIFs guarantee the intramodular safety of the PEAs for their designed functionality, which is the task of PEA manufacturers at modular plants.
The states of the safety services described in the Safety-MTP are provided by the PEAs and can be monitored and switched using the superordinate logic. In the example of the demonstration project, the process is as follows: The fSOL constantly checks the safety services for state changes.
If, for example, the safety service “overfill protection” is triggered – changes to “triggered” – on the reactor PEA, then a command to trigger safety services for pump shutdown is written to the double-dosing PEA.
For the demonstration project, the interconnection of the safety services, a process known as “Functional Safety Orchestration” (FSO), proved to be the crux of the matter. This criterion determines how easy it is, for example, to put a plant back into operation after modifications. For the orchestration of distributed safety systems, the existing programming tools must be expanded.
The goal: to integrate the safety-oriented module description into the system via the standardised interface description of the modules (Safety-MTP) and then logically interconnect the process units. This makes it possible to encapsulate the complexity for the user in functional blocks (state machines) within the individual modules, thereby keeping the task of interconnecting the modules simple. The demonstration project could show that this concept works.
Safety engineering: Configuration instead of programming
The interconnection can be performed using the SILworX programming tool from HIMA, for example. The upcoming version with the SILworX API already supports an user-friendly interface, allowing users to connect process units very easily.
The aim is to simplify safety engineering in this way to such an extent that it is ultimately reduced to a module selection process (“zero-safety-engineering”). The previous need to program safety functions can thus be reduced to just a simple configuration task at the interconnection level.
In module automation, the individual safety functions of a system can thus be based on the engineering services for the individual modules, and the module manufacturer ensures functional safety in conformity with standards.
When engineering the demonstration project, the participants at TU Dresden particularly appreciated the intuitive usability of the SILworX programming tool and HIMA's pioneering spirit in adapting functional safety methods to address the new challenges of modular automation.
The further development of the engineering tool is part of HIMA's digitalisation strategy under the motto “#safetygoesdigital”, where safety systems become a data hub. In doing so, the digitalisation of functional safety delivers added value, and implementation is seen as a holistic process: from engineering to operation to extensions and modifications. Digitalisation thus offers the opportunity to make the handling of safety technology more efficient and significantly simpler for plant operators.
But how can this approach be integrated into existing safety design processes in the future? Is it conceivable that the interconnecting of safety services will be evaluated as a waste product by a plant’s risk assessment in the future?
And how will tasks be distributed between operators and engineers in process industry plants? These and other organisational questions must be discussed to help modular automation succeed.
Another consideration is the design of the standardised process engineering modules (PEA) themselves. The question of which potential risk a module should be designed for essentially determines the module price: a design for the maximum risk – for example, Ex zone 0 or 2 and SIL 3 – would lead to high costs.
The aim here is to differentiate between “standard modules” for the widest possible use and “special modules” for rare applications and requirements. The example illustrates that more intensive cooperation between automation engineers, process engineers and operators is necessary for module automation.
Another finding from the demonstration project concerns space requirements: each PEA uses its own safety controller and an extended I/O module. But the space available in the modules is limited. This is another reason why compact safety controllers from HIMA were chosen for the demonstration project.
These can be dimensioned based on the I/O points required to perform the safety functions. HIMA's broad portfolio of solutions, ranging from the compact HIMatrix used in the demonstration project to extensive safety controllers with many I/Os, already makes it possible to implement almost all safe module automation applications.
The orchestration of the superordinate safety function at the plant level is handled by an additional independent user program. This superordinate safety controller communicates with the safety services available in the PEAs and secures the entire demonstration project by executing appropriate shutdowns.
Networking via OPC UA
Exchanging data between the PEAs themselves and between the PEAs as well as orchestration require a safe communication standard. While this is usually not a problem for safety controllers made by the same manufacturer, it can limit the choice of PEAs when integrating safety controllers from different manufacturers.
For this reason, the networking of the PEAs in the demonstration project was based on the manufacturer-independent communication standard OPC Unified Architecture (OPC UA). In the future, the safety-oriented option OPC UA Safety should be used for this purpose, although it is not yet available as a product. During an additional step, it is planned to implement and test safe communication as part of the demonstration project.
The demonstration project did show that module manufacturers can already start using Safety-MTP today: it was successfully demonstrated that variables can be exchanged using proprietary protocols. In addition to the already successfully tested communication via SafeEthernet from HIMA and the non-safe option OPC UA, the use of PROFIsafe for communication between safety controllers from different manufacturers will now be tested.
In order for the concept to finally reach operational maturity, the project team plans to implement safe communication and safe hardware for the entire orchestration during the next step. In light of this, it also makes sense that the management of the Safety-MTP Taskforce is now being transferred from TU Dresden to an operator.
Conclusion:
During the demonstration project, it became clear that the engineering of new plants and the modification of existing plants will not be made more complicated with Safety-MTP, but rather easier for the operators. The Safety-MTP increases the flexibility of plant operation. In addition, digital access to the functional safety components enables their information to be evaluated at the orchestration level. This can be used in the future, for example, in order to optimise proof tests.
Additional Authors:
