As some products’ lifecycles shorten, the need to rapidly design and construct chemical and pharmaceutical production plants is growing. This rapid change is making a case for modular plant production. The value of such modular production, encompassing a modular automation system and engineering approach, has already been successfully demonstrated in pilot applications [1,2], where up to 50 percent of engineering and commissioning time can be saved. Although 25 percent of future process plants in both of these industrial sectors are expected to be built utilizing modular fabrication and automation by 2030 [3], ABB pondered how modular automation could be leveraged to streamline engineering in the remaining 75 percent. Here, ABB presents a concept for modular engineering of conventional process plants, those plants that are not assembled based on modular production using Module Type Package (MTP), and introduces a new concept, Function Modules (FM). A use case from the oil and gas industry is also presented that validates the modular engineering approach and FM concept.

Modular production basics and the current situation

Pre-engineered, and pre-manufactured modules, defined as Process Equipment Assemblies (PEA), or skids, can fulfill a process function in modular production. For use in multiple applications, interoperability of PEAs is a must: The Module Type Package (MTP) makes this possible. MTPs are a standardized, manufacturer--neutral description of a PEA [2] that includes information necessary to seamlessly integrate a module into a modular plant, eg, descriptions of communication, services, HMI, etc. MTPs allow PEAs to be integrated into a supervisory control system, the Process Ochestration Layer (POL) where functions are abstracted eg, into a service layer. Every PEA has, as a result, its own intelligence. The integration of MTPs and service-based process design make process function possible. In this way, engineering efforts and commissioning time can be reduced [4]. For conventional plants, those not using MTPs yet, off-site prefabrication of large modules in so-called module fabrication yards is gaining ground, eg, COOEC-Fluor Heavy Industries [5], EPC-M Group [6]. And yet such modules typically include only mechanical parts and instrumentation, not the all-important automation system. Why is this so? Simply explained, large-scale plants of global firms are usually constructed for a specific purpose. Process design is rarely altered after commissioning; including PEAs in the design phase would generate excessive costs because smart modules require a control system in every module. Nevertheless, for plants built in harsh environments eg, upstream gas facilities, it would be advantageous to fabricate larger parts off-site, assembling them on-site later, as partly done for the Hammerfest LNG plant in Norway [7].

Demand for standardization and cost pressures is leading plant operators to seek concepts that foster reuse of molules across multiple sites. For example, ­ExxonMobil, introduced the “It Just Happens 2 (IJH2)” [8] initiative, to define the modularized functional container for software, the smart standard controller and standard type-based engineering for the upstream oil and gas industry. Nowadays, these plants are not entirely built in a modular manner; they integrate PEAs and conventional structures in plant production and are known as hybrid plants [9].

For the application of modularization more broadly, to conventional plants yet to employ MTPs, a new modular engineering concept is required. Ideally, this concept would contain an automation system-agnostic way of describing reusable module types with the possibility of integrating ready-made modules that can then be -instantiated¹ to create module instances that represent a physical module.

Function Module concept

To satisfy these aforementioned requirements, ABB developed the concept of FMs: a software description of a module type. In contrast to PEAs, FMs do not bind to a specific hardware type, they are a description of the functionality that the resulting automation system should contain, ie, parameters, views, variables and alarms that are executed by calling methods, setting signals and replying with events and signals →01. FM functionality, however, is comparable. During engineering of a module type, the automation software for the FM is described and the corresponding MTP is generated. Because the resulting MTP is embedded in the plant engineering process →02, the generated MTP can be used immediately. Thus, FMs are engineered in the same way as are PEAs, eg [10].

Type-based engineering

Following a type-based engineering approach, the FM is engineered before creating the actual instance of a process function. Because the automation software relevant parts are described generically, no automation system-specific information is required.

Once completed, the resultant type can be instantiated during the plant engineering phase. Every FM instance of a type has identical behavior and can be bound to an automation system in a later step with suitable controllers, eg, Freelance or System 800xA family, depending on the process and automation system requirements.

For every FM instance, instrumentation can be assigned to the FM’s instrumentation connectors. For practicality, for the same measurement value of different FM instances that belong to the same FM, different sensor types can be used within the FM instance. If a different measurement principle is required, another instrument type can be used for a specific FM instance. Thus, FMs are neither bound to specific instrumentation nor equipment type.

While an automation system-specific MTP is needed to describe automation system-specific information, only a generic MTP is required for the description of the FM. Thus, the concept of MTP is generalized; this means that the target system-specific information is not contained in the MTP for the FM.

Engineering workflow of the automation system

The engineering workflow can be divided into two different, yet not necessarily sequential, conceptual phases: phase A; FM engineering, and phase B: plant engineering; both can follow alternating or concurrent phases in the workflow.

FM engineering is initiated in step 1 with the description of the FM-type using HMIs, tags, services, etc. →02, while the generic MTP of the FM type is generated in step 2; thereby concluding phase A →02.

If a supervisory control is required, step 3 of phase B can be employed. In step 4, the automation system software for all instances and the specific automation system is created automatically. The MTPs for the instances are customized based on the automation system information →02.

Project execution workflow

ABB’s engineering concept, using FMs, makes distributed off-site engineering for conventional process plants possible. Module fabrication yards can continue constructing modules for the plants, including I/O, while the corresponding counterparts, on the automation side, are created off-site and later assigned to the I/O, as per →03.

Critically, testing is performed at every stage. A type test is performed for every FM. Once the FM instances are created and assigned to the modules in the module fabrication yard, a virtual factory acceptance test (FAT) can be performed using a virtual control environment already connected to the I/Os of the modules. The mechanical parts can then be transferred with the corresponding FM instances on-site. Here, a site acceptance test (SAT) can be executed with the installed real-world control system.

Thanks to the project workflow methodology, the plant engineering can be performed in the office, tested in the virtual environment with the FM instances and finally transferred on-site. To foster reuse, the FMs could then be stored in an FM library and be reused in other projects.

Variant management using FMs

To enable reuse of larger parts of a plant, management of variants by means of optional functionality and nesting (the nesting of other FMs and PEAs) might be useful, especially whenever it is desirable to develop a multi-functional type that can be parameterized for every instance separately, at a later time →04 [10,11].

Plant engineering using parameterizable FMs

Since FMs can be used to create instances and their parameters according to the needs of the process plant, whenever an instance of an FM is created during plant engineering, all nested FMs →04, PEAs, and optional functionality →04 are enabled by default, thereby streamlining the process. The instances are connected as for standard modular plants: by using material flow (pipes) and information flow (signal) connections, →05 [12].

Importantly, the engineer can decide which FM functionality to disable by deselecting it →05. Following parameterization, the code for the instance can be generated automatically, eg, [13], but only for the enabled functionality (and those for nested FMs); disabled parts are excluded from code generation.

Industrial case study

For proof of concept, ABB conducted an industrial use case for a 3-phase, 4-stage oil separation process, containing four oil-separators →06a.

A multi-functional FM was implemented, including optional functionality for water separation and a nested FM for gas treatment. Moreover, an oil heater function was implemented using a third-party PEA, described as a MTP. In this use case, the high-pressure separatior (HP) cannot separate water from the crude oil; the oil water separator (O/W) lacks a gas treatment functionality but can separate oil from water →06b. In contrast, the medium pressure (MP) and low pressure (LP) separators contain functionality for separation of all three phases →06b.

Engineering the separator FM

The separator is engineered as an FM starting with a piping and instrumentation diagram-like HMI as for a PEA, [10], which models the inner structure of the separator →04. The nested FM for gas treatment is added as a symbol, the water separation is marked as an optional functionality, indicated by the blue-marked area, which can be enabled or disabled in the FM instances later. Once HMIs are defined, tags are configured as per [10] using default values, which are adaptable for every instance later.

In contrast to the fixed state-machine of services defined in [10], ABB’s new concept allows state-machines to be adapted according to needs. Here, three services are required: ‘Produce’, ‘Commissioning’, and ‘Maintenance’. ‘Produce’ is the normal operation of the plant with the modes of operation: Idle, Startup, Execute, Shutdown, PSD and ESD. ‘Commissioning’, executed during plant commissioning, can only be started or completed, basically. ‘Maintenance’ is used by the engineer during plant maintenance.

For all services, the state-machine is adapted accordingly as for the service ‘Produce’ →07a. Thus, the different modes of operation can be mapped to the states of the standard state-machine →07b. Additionally, the services of the embedding module are configured to control the services of the embedded gas treatment FM. The states of the VDI/VDE/NAMUR 2658 state-machine [14] are mapped to the modes of operation from the service ‘Produce’ →07b.

Based on the services and tag configurations, an initial alarm set is generated. Here, all activated alarms from the tag list are included in the module’s alarm configuration list, even those configured for the service transitions. For every alarm, depending on the type, a default message and a default severity is assigned. These can be altered as needed. By default, all alarms are enabled and must be acknowledged. To retrieve a service-based alarm for the separator, alarms are assigned to the services, where they can be activated.

When the service enters the startup state, the service-specific alarm configuration is set; when it enters the reset state, the alarm configuration is switched back to default. Hence, a service-based alarm capability is provided. Subsequently, the generic MTP is generated and can be used during plant engineering.

Engineering plant topology and supervisory control

During plant engineering, four instances of the separator FM are created from the generic MTPs: HP separator, MP separator, LP separator, and oil/water separator. Additionally, a preheater (OilHeater) is included using a third-party PEA →05.

For supervisory control, a simple startup sequence, which starts the ‘Produce’ services of all instances, and a shutdown sequence, which completes and resets all ‘Produce’ services, is engineered. The separator instances are parameterized: for the O/W separator, the gas treatment nested FM is disabled; for the HP separator, the optional functionality water separation is disabled.

The HP and O/W separator are executed on one controller, an ABB AC800M; the LP and the MP separator are assigned to another AC800M controller, and the preheater runs on a third-party MTP capable controller – a Freelance AC700 controller – the controller assignment and control code generation was not required.

Following separator assignment, the automation software is generated, automatically:

• The FM instance code is generated for AC800M controllers and automatically imported into a project, including the state-machines for the services, code for states, service parameters, FM instance internal interlocks; and the tags including parameters; the alarm configuration for the tags and the services; and the enabled nested modules.
• The supervisory control code is imported into an ABB System 800xA and the corresponding AC800M controller. This includes the sequences for controlling the FM instances, the FM instance to FM instance communication, the communication definition from System 800xA to the FM instances and the PEA, the tag definition from the FM instances and PEA, the HMIs for every FM instance and the PEA, a visualization for every state-machine from every FM instance or PEA adapted to the configuration of the service, and an overview HMI for the entire plant. This process successfully results in the automatically generated operator workplace →09.

This industrial use case validates ABB’s FM engineering concept: generation of generic MTPs that can be utilized to describe FMs. Testing and validation of the plant engineering concept also demonstrate that ready-made modules can be instantiated to form FM instances that accurately represent physical modules. An automation system-agnostic way of describing reusable module types is feasible.

Outlook

ABB’s presented FM concept creates the foundation for modular engineering methods to be used in conventional process plants. The feasibility of this concept has been tested in ABB’s separation use case, which successfully demonstrated how the engineering approach and workflow can be applied to the oil and gas industry. The engineering efficiency benefits gained from the modular engineering of modular production facilities will apply to conventional, world-class large production plants, too. Ongoing research is addressing how early engineering phases could be formalized so that I/Os of the FMs can be automatically and semantically specified and matched [15,16]; such focus will help foster the early and accelerated development of this technology.

_{References
[1] VDI/VDE/NAMUR 2658 part 1 (Edition 2.0 – Draft), “Automation engineering of modular systems in the process industry – General concept and interfaces.,” VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik, 2022.
[2] M. Hoernicke, et al., “Building Blocks – Modular Process Automation Pilots,” ABB Review, 03/2022, pp. 24 – 31.
[3] ZVEI, “Module-based Production in the Process Industry – Effects on Automation in the Industrie 4.0 Environment,” ZVEI.org, Frankfurt am Main, March 18, 2015.
[4] M. Hoernicke, et al., “Automation architecture and engineering for modular process plants – approach and industrial pilot application,” in IFAC World Congress, Berlin, 2020.
[5] COOEC-Fluor Heavy Industries, “COOEC Fluor Comletes Module Fabrication for Dongfang Gas Fields Development Project in China”, in Fluor Newsroom, 2019, [Online], Available: https://newsroom.fluor.com/news-releases/news-details/2019/COOEC-Fluor-Completes-Module-Fabrication-for-Dongfang-Gas-Fields-Development-Project-in-China/default.aspx [Accessed: Feb. 1, 2024.]
[6] epc-m, [Online], Available: http://epcm-industries.com [Accessed: Feb. 1,2024.]
[7] Hammerfest LNG plant from Equinor, [Online]. Available: https://www.linde-engineering.com/en/about-linde-engineering/success-stories/lng-production-in-permafrost.html [Accessed: Feb. 1,2024.]
[8] P. Studebaker, “ExxonMobil takes IJH challenge to new level,” Control Global, no. 10, 2019.
[9] A. Markaj, et al., “Requirements and conceptual design for hybrid process plants,” in 26th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA ), Västeras, 2021.
[10] K. Stark, et al., “Modular Process Plants: Part 1 – Process module engineering,” ABB Review, 02/2019, pp. 72 – 77.
[11] VDI/VDE/NAMUR 2658 part 2, “Automation engineering of modular systems in the process industry – Modeling of human-machine interfaces,” VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik, 2019, pp. 1 – 32.
[12] M. Hoernicke, et al., “Modular Process Plants: Part 2 – Plant Orchestration and Pilot Application,” ABB Review, 03/2019, pp. 30 – 35.
[13] M. Hoernicke, et al., “Steuerungsengineering für Prozessmodule – Standardkonforme Modulbeschreibungen automatisch erstellen,” atp edition, vol. 59, no. 10, 2017, pp. 18 – 29.
[14] VDI/VDE/NAMUR 2658 part 4, “Automation engineering of modular systems in the process industry – Modelling of module services,” VDI/VDE-Gesellschaft Messund Automatisierungstechnik, 2022, pp. 1 – 87.
[15] N. Schoch, M. Hoernicke and K. Stark, “Semantic Function Module Pipeline Generation,” at – Automatisierungstechnik, vol. 69, no. 12, 2021, pp. 1040 – 1050.
[16] A. Markaj, et al., “From intentions to services in modular process plants,” in 5th International Conference Proceedings ICPS, Coventry, UK, 2022}