Orchestration Requirements for Modular Process Plants in Chemical and Pharmaceutical Industries
Abstract
The increased flexibility resulting from the modularization of process plants requires an advanced strategy to supervise the distributed control systems (DCSs). The connection and coordination of multiple process equipment assemblies (PEAs) into a modular plant (MP) is called orchestration and conducted in a so-called process orchestration layer (POL). Standardized interfaces enable a seamless integration of PEAs into an MP. Current process control systems do not yet meet all required features regarding to interfaces and possibility of import/export of different data structures. Several aspects are presented which shall be taken into account when designing a POL. The POL's several layers are described in detail, resulting especially in flexibility and reusability of modular plants.
1 Motivation
With increasing digitalization and the Industry 4.0 Initiative in Germany, the chemical and process industries experience changing requirements, e.g., individualized products with shorter product life cycles. A promising approach for meeting these requirements is the modularization of process plants 1-3. The requirements are described in detail in the status report of ZVEI (German Electrical and Electronic Manufacturers' Association) entitled “Process INDUSTRIE 4.0: The Age of Modular Production – On the doorstep to market launch” 4 and in a ProcessNet white paper on modular plants 2.
An essential element in implementing the concept of modularization is the orchestration of the individual modules. In order to operate efficiently a modular plant, the deployed modules, so-called process equipment assemblies (PEAs), need to be interconnected to each other, coordinated, and controlled in a meaningful way. In contrast to conventional plants, the individual field level components are not addressed directly anymore – their control is now realized via services. Services therefore encapsulate the control of the individual components in order to realize the automation of the PEAs. The necessary steps for the arrangement of a modular plant can be summarized as orchestration.
Modularization enables process plants to quickly and efficiently adapt to changing market requirements. However, the process industry is confronted with new questions regarding to dependency of assemblies, data integration, and regulatory approval. The ORCA project (Efficient Orchestration of Modular Plants), funded by the German Federal Ministry of Economics and Technology (BMWi) and part of the ENPRO2.0 initiative (Energy Efficiency in the Process Industry), is working to answer some of these questions. Within the project, requirements for a possible realization of the orchestration in the form of a superordinate control layer were developed. This layer is the process orchestration layer (POL), which takes the overall orchestration functions and thus becomes a process control system for modular plants. In analogy to today's conventional process control systems, it is conceivable to implement a POL as a highly integrated system, which allows the fulfillment of a variety of functions within a company.
Fig. 1 gives an overview of the vertical integration of the orchestration layer. The orchestration layer can be seen as a link between the PEA's administration and management as well as the ready-to-produce plant on the production layer. As described in 5, the layers can also partially merge into each other. The orchestration's main aspects remain the configuration, control, and supervision of the modular plants. Nevertheless, the orchestration layer can execute aspects of manufacturing execution systems (MES), such as PEA pool management over their entire life cycle 6.
The NAMUR open architecture (NOA) operates parallel to the layers shown 7. This closes the loop to the industrial internet of things (IIoT). Further aspects to be considered are the engineering of PEAs, process development, and the selection of suitable PEAs for the implementation, as well as the optimization and data integration of the processes.
1.1 Gaps and Challenges of Conventional Process Control Systems
Current process control systems are well advanced and are robust and capable to supervise and control complex plant structures within diverse processes. Up to now, they were designed to work monolithically within automation systems of specific vendors. The use of diverse automation systems often comes with increasing efforts for integration when possible at all. This is caused due to the lack of standardization of interfaces among automation systems of different vendors. This gap is closed with the standardization of an interface for the automation, the module type package (MTP). The current state of MTP development is described in 4.
With a defined description of which variables have to be implemented and in which manner, the efforts for a manufacturer-independent integration of subsystems are reduced to a minimum. The standard does not only describe the way in which the interface of PEAs has to be designed, it also challenges current process control systems to interact with the defined interfaces. The interaction between process control systems and the PEAs is executed via predefined process functionalities, so-called services. This replaces the efforts for reconfiguration of the automation system by a simplified orchestration, which also increases the reusability of PEAs. Interoperability of literally any automation system becomes possible by adopting the MTP standards.
The requirements resulting from these changes are summarized in this paper. The concepts and implementation proposals for the process orchestration layer for modular plants, which are briefly explained in this paper, were developed and discussed in several expert workshops. Hence, development approaches around the orchestration of modular plants can also be derived from the requirements. Some of these approaches will be created in the ORCA project and in other research projects within the ENPRO2.0 initiative.
2 Categories of Orchestration
Orchestration is the configuration of a specific modular plant topology with the associated interconnection of services, which are offered by the PEAs for an efficient operation of a chemical process. This includes importing descriptions of PEAs, configuring service parameters, and connecting automation and logical links. When the configuration is completed, the existing services can be either started manually or and run automatically as part of a recipe. Thereby interdependencies between services must be considered during the configuration. After completion of the orchestration, the modular process plant is ready for operation.
The requirements can be categorized into four categories, which represent the workflow of the orchestration of a modular plant (Fig. 2). All these categories are necessary for the complete orchestration of a modular plant. The sequence in which one category is fulfilled is limited by information from previous categories, as it is reused at a later point in time. However, it is possible to modify individual aspects within one category without changing other categories, assuring reusability within modularization. By changing single aspects like the process configuration, all previous steps should remain unchanged.
A special characteristic to be considered is the adaptation of the modular plant structure. All aspects, which are unaffected by the change on the plant topology, remain unchanged and would not need further validation. This is particularly important, as the PEAs are conceived to run independent of each other.
Within all four categories, there are various cross-linking aspects, which appear in all categories (Fig. 2, bottom).
Interfaces are required for the data exchange between different systems such as design and orchestration tools, administration shell 8, concepts of NAMUR open architecture framework and conventional manufacturing execution systems (MES). Plant and PEA configuration address the coordination and configuration of the individual PEAs into a modular plant. Process configuration addresses all configuration and parametrization related to the process. Monitoring/operating/executing address the actual plant operation. A complete overview of the structure of the POL is given in Fig. 3. Subordinate to the POL are both, the physical PEAs (those in operation and those stored in the PEA garage), and the infrastructure. Special focus of this visualization lays on the connection of the different layers and the aspects inside the POL. A main difference to the conventional engineering lays in the usage of pre-engineered PEAs. Existing information is combined and logical connections are linked to build up a ready-to-use modular plant in the production layer.
Some requirements are relevant to all categories, e.g., permission and user management, documentation, and visualization. The respective characteristics of these common aspects are outlined in the last section of this paper.
3 Interfaces
The fundamental category of the POL consists of standardized interfaces. Via these interfaces, the necessary data can be imported into the POL and the resulting information is made available to other systems. Data can be exchanged for example with external engineering programs, with other data science applications for the evaluation of structured data, or even between different POL systems. The main part of the automation interface, the MTP, is specified in the technical guideline VDI 2658. Parallel, a guideline VDI 2776 specifies the process engineering view of modular plants. A summary of the ongoing development is given in 4. In principle, POL can export and import everything in order to increase reusability. Interfaces can be further classified into import and export interfaces.
3.1 Data Import
3.1.1 Module Type Package (MTP)
The MTP is the basic description file of a PEA and is used for the integration of a PEA into a POL. It provides all necessary information of the PEAs regarding automation, communication, and operation via POL. It includes all services offered by the PEA, a human machine interface (HMI), and information about the process values in the PEA. The POL could also provide the possibility to control and monitor directly automation components such as valves or sensors without an MTP in addition to the PEAs.
The POL shall be able to import the MTP and interpret and process the information provided. The POL may not change the data of the MTP. However, the implementation of engineering functionalities in the POL to supplement an MTP is not excluded.
The MTP does not contain information on the process engineering requirements of the PEA according to current concepts. These requirements can, however, be described in separate data exchange formats such as DEXPI.
3.1.2 Data Exchange for the Process Industry DEXPI
DEXPI (data exchange for the process industry) is a data exchange standard for the process industry 1. It can be used to exchange process engineering information across different engineering and planning tools. Since this information is not directly contained in the MTP, it is desired have a respective DEXPI interface in the POL. The combination of process and automation information can be highly beneficial in future for enhanced assistance functions during the orchestration steps of a modular plant.
3.1.3 PEA Administration
For the logistical planning of the construction and modification of a modular plant, it is essential to know which PEAs are available. It is relevant to know both the global availability, like a general catalog (catalog of MTPs) of already built PEAs and the local availability (PEA instances), i.e., the current usage within a production site. On a global perspective, the respective PEA types and their available versions are relevant. On a local perspective, specific PEA instances and information about the state of the respective PEA (e.g., available/in use/not available/out of service) are also relevant. Such information must be made available to the POL. This could be done with a PEA administration tool.
The status of existing PEAs can be displayed in a list or table, made accessible via a local discovery service or a complex database system. The POL must display which PEAs are integrated into a plant topology. It is possible that a PEA, e.g., one for feeding a reactant, serves in more than one plant. Therefore, the management of availability must not only refer to a PEA alone, but also include information about the connected process media and information flow. Ultimately, the POL itself could carry out the PEA administration.
3.1.4 Infrastructure
In addition to information about the PEAs, information about the available infrastructure at the location of the modular plant is required as well. This information includes the existing connections to process water and process gases, as well as exhaust gas, electrical energy, other auxiliary media, the available space or the connected traffic routes. An indication of possible aspects is given in Fig. 3 in form of green boxes. This information could also be available to the POL via MTP, which is generated for the infrastructure. However, this depends on which information can be stored in the MTPs. As described in the section PEA administration (Sect. 3.1.3), the POL shall indicate which parts of the infrastructure are used by which modular plant. By providing this information to the POL, it is possible to execute scheduling as well as consumption and capacity planning by the POL.
3.1.5 Other Files
In addition to the essential data for orchestration, planning data from the plant engineering phase, such as operating instructions, user manuals, general safety instructions, or flow charts, should be importable into the POL. This data should then be reasonably combined with the other data in the POL and be accessible throughout the orchestration steps.
3.2 Export and Import
3.2.1 PEA Configuration
The parameter configuration of the individual PEAs is carried out as part of the orchestration (cf. Sect. 4). It must be possible to export and import these parameters to re-integrate similar or identical PEAs into further modular plants. Thereby, reconfiguration of a plant can be avoided and the shift between two previously configured processes can be accelerated.
3.2.2 Interlock Matrix
The interlock matrix describes which services are dependent on each other plant-wide. Possible dependencies are “allow”, “prohibit”, “change”, and “sync” 9. The export of an interlock matrix generated and verified in the POL for a plant topology enables fast and error-free duplication of (partial) plants. It could also be possible to integrate an interlock matrix from external sources, e.g., a modular HAZOP, into the POL.
3.2.3 Plant Topology
The plant topology describes the process flow connections and relationships between PEAs within a modular plant. These connections are created during plant/PEA configuration (cf. Sect. 4). To enable the reuse of already orchestrated plants, export and import of the plant topology must be possible.
3.2.4 History/Operating Data
During operation of the modular plant, data is recorded and processed and can be used for online optimization of the process. In order to shorten the data acquisition phase, operating data, i.e., process values as well as service calls and commands, from former orchestrations should be available. For that, the recorded operating data must exportable so that it can be reused. Data filters or compression, e.g., by approximation with functions, shall be necessary due to the potentially very large amounts of data. The export can take place either as a special log file readable by the POL, or via standard formats such as *.txt, *.csv or *.xls. The exported historical data can then be processed by external data analysis tools before returning it in the process.
3.2.5 Placeholders
To enable an easy exchange of PEAs, placeholders can be used during the orchestration. That means, the configuration is detached from specific PEA instances or MTPs, instead it is done with the help of placeholders that contain the same required process functionalities. This enables the replacement of a specific PEA by another PEA with a different structure but the same functionality with little effort. The PEA can then be exchanged within a superordinate grouping only by configuring the links to other PEAs within that grouping. The surrounding configuration remains unchanged. This kind of placeholder is configured and integrated like a PEA, as well as filled in the later course of the orchestration with appropriate PEAs to fulfill the functionality. Hence, a description for the placeholder in form of an MTP is required.
Within such a placeholder, several PEAs could be combined to fulfill the functionality. The connection and configuration then take place only within the placeholder. To the outside world, no difference should be visible compared to a normal PEA. Thus, the placeholder PEA must offer services, which are then mapped inside the placeholder to the services of the subordinate PEAs. The creation of placeholders could be a functionality of the POL, and so their export should also be supported.
4 Plant/PEA Configuration
During the plant/PEA configuration, the service parameters (ServiceParameter) shall be set so that compatibility among PEAs within a modular plant is ensured. This category is comparable to the conventional engineering approach. An overview of the aspects of this category is provided in Fig. 4.
4.1 Linking a PEA
At this point, the PEAs must have been selected from the administration tool (PEA pool). For the selection a description of the PEAs logistics status is necessary, e.g., “available”, “in use”, “service required”, “in repair”, “defect”, “cleaning required”, “in use from [date/time]” etc. A scheme of how the availability can be displayed is presented in Fig. 4. After selecting the PEAs, the PEAs are then connected to each other, which is an essential part of the plant configuration. Thereby the outputs and inputs of both the process flows (process media; blue dotted lines in Fig. 4) and the automation links (signal, information, process values, output values, etc.; red 0/1 in Fig. 4) are connected. The automation connections are used to enable data flow between the PEAs. In addition, data sources and sinks determine which PEA connections are in use and which are available. This information is essential for the PEA management (cf. Sect. 2). The connections in use must be displayed in the POL. The connections in use could be validated by virtual commissioning, where process and automation connections are analyzed and checked for compatibility.
4.2 Service Configuration
For operation of a modular plant, the service parameters of the deployed PEAs shall be configured to ensure compatibility with both the other PEAs and the process itself. A window of operation can be achieved for the desired topology through limiting the maximum and minimum operating parameters of the individual PEAs. The parameters must be set via the POL if they have not already been set via the MTP. The parameters must therefore be accessible by the POL configuration mode. Thereby they can be adapted manually to match the boundary conditions imposed by the surrounding PEAs (Fig. 4, center right).
Service configuration also includes the definition of interlocks. If an interlock matrix has been imported in machine-readable form, the interlocks can be set automatically. However, it must also be possible to add or change the interlocks manually.
Parameters that are specific to the process, such as maximum throughput or minimum temperature, must always be defined via the POL. This can be done manually as well as automatically via an import from external sources, e.g., a parameter recipe. Finally, an automated consistency check, e.g., based on the virtual commissioning, can be used to validate the parameters.
4.3 Placeholder
The placeholders described in Sect. 3.2.5 play an important role in plant configuration. These placeholders can be used to perform the plant configuration, even if it is not yet known which PEA types or PEA instances are available to be used. If no placeholder PEAs are available for import, the POL should offer the possibility to create one during plant configuration. Such as for regular PEAs (with an existing MTP) it must be possible to configure the PEA placeholders.
4.4 PEA-Linking Services
To achieve the desired functionality in a modular plant, it may be necessary to combine services of more than one PEA, e.g., in placeholder PEAs. The combination and coordination of these superordinate services must be described during orchestration and implemented by the POL.
4.5 Copy Function
It shall be possible to copy individual PEAs/plant parts to enable fast numbering-up during plant configuration. Not only the visualization but also the background information and configuration should be copied. Ideally the POL shall check if copying the respective plant part is possible, and which new requirements would arise as a result, e.g., if the required connections to infrastructure and/or upstream/downstream are available.
4.6 Display of PEA Status
For optimal operation and monitoring of the modular plant, it should be possible to display the status of all PEAs. The rules for determining the PEA states should be configurable via the POL. According to the NE 107 10, possible states of a PEA are: running, warning, and offline. An indicator for the PEAs status could be given by the worst quality code (WQC) of its services. However, further states could be possible, e.g., a time span until the next maintenance tasks or specific process values/KPIs. The POL should offer the function to display the status of each PEA.
4.7 Function Blocks
Process parameters from one PEA may not be processed directly by another PEA. Therefore, the POL must offer a functionality for processing such parameters. Function blocks that are configured or newly defined in the POL (Fig. 4, yellow boxes) can serve for this purpose. In addition to the conversion of process parameters, the POL shall also offer process-independent function blocks such as for counting the number of service calls of a specific PEA or for logging the operating time of the plant.
5 Process Configuration
During the process configuration (Fig. 5), process-related adaptations and extensions are made and the sequences of parameterized services (recipes) for the automatic operation of the plant are set up.
5.1 Service Configuration
For the process configuration, the service parameters must be further adapted to match the constraints given by the chemical process (see Fig. 5, bottom left). This adaption can only be made within the limits of the service parameters defined during the plant/PEA configuration (see Sect. 4). These limits are further specified according to the chemical process itself. By this two-step approach, a later adjustment, e.g., for the introduction of a new product on the same plant, is facilitated.
5.2 Creating Recipes/Service Sequences
In order to run chemical processes automatically, e.g., for the manufacturing of a specific product, the POL must offer the functionality to create service sequences (recipes) (Fig. 5, center left). The POL must restrict the use of certain service combinations based on the previously configured service dependencies (see Sect. 4.1 and Sect. 4.2) in order to prevent critical/hazardous situations in the modular plant.
5.3 Deviation Monitoring (Alarm Management)
In process plants, undesirable situations can arise, leading to danger for people, environment, or the modular plant. Warnings in form of alarms can prevent such situations (Fig. 5, top). These alarms can be triggered if the parameters of a system are changing in an undesirable direction. If PEAs provide alarms via the MTPs, the user must be able to prioritize them in the POL. It must also be possible to configure further alarms for the specific requirements of chemical reactions or processes in addition to those specified in the MTP.
5.4 KPI and Additional Calculations
Key performance indicators (KPIs) are used to monitor processes. The POL should offer the functionality so that the user can define the calculation of KPIs from the process values provided by the PEAs. These KPIs can be used posteriorly.
In addition to KPIs, it must be possible to perform further calculations in the POL (Fig. 5, bottom right). For instance, calculations can be used for the conversion of process variables to derive set points for other PEAs (PEA-overarching control) or to sum up the number of cycles that a service has already been run. The functions that were used or created during the plant/PEA configuration (see Sect. 4.7) may be applied here.
5.5 Dashboard Configuration
For an overview of the entire plant, there should be some kind of dashboard in which the states of the PEAs and services are displayed and manual operation is possible (Fig. 5, center right). It should be possible to configure this dashboard arbitrarily from the available human machine interface (HMI) and further information, e.g., display of the level development in a PEA together with the pump power intake of the upstream PEA, display of the trend of KPIs in comparison with older batches. For the dashboard configuration it should be possible to import external visualization and operation elements in addition to those containing in the POL.
6 Monitoring/Operating/Executing
The POL shall provide information to the operator during the operation of the plant. The functions required for this are described in the following and are displayed in Fig. 6.
6.1 Human Machine Interface
The POL must offer the functionality to operate the modular plant manually via an HMI, which was configured previously (see Sect. 5.5 and Fig. 6, center). This includes operation of actuators, call of services, and execution of previously configured recipes.
6.2 Alarms/Trends/Histories (Monitoring)
The POL must display and highlight alarms and warnings according to their priority, e.g., by using a color scheme as indicated in Fig. 6, top). Online analysis of process values trends shall also be possible. A further functionality could be the estimation of KPIs and parameter trends for a certain period (Fig. 6, bottom).
The trends and logged process values for past time instances and batches should be displayed upon request. The logs should also display interventions and parameter changes like the manual reset of a service or the change of a set point (Fig. 6, bottom left).
6.3 Automated Batch Documentation (Batch Record)
For batch processes, in particular a documentation of the operation of the plan (parameters, process values, interferences, etc.) is necessary in order to track back the product quality. The POL should offer the functionality for the automatic creation of documentation (batch record) with the data collected during operation.
7 Cross-Linking Aspects
Some further aspects are common to all the categories mentioned before. These include user and permission management, documentation, visualization, versioning, validation, audit trail, and change management. These topics are discussed in more detail below.
7.1 Permission Management
The POL shall allow the creation of various user groups. The user groups have different permission regarding to configuration and operation. Not every user group should be able to import files, since essential parts of the configuration could be changed easily and security aspects such as the protection against manipulation would be reduced. Likewise, the export of data should only be possible for previously designated user groups in order to protect process knowhow.
Some users could thereby be made responsible for the configuration of the plant, the PEAs or the process, while others could take care of the operation of the plant. By assigning the appropriate permissions, a clear definition of responsibilities is ensured, preventing incorrect operation. The HMI shall be adapted automatically according to the user group. Functions that a user cannot operate could be hidden or tagged with contact details of the person responsible.
7.2 Documentation
An appropriate documentation shall be supported by the POL to comply with legal regulations, to be able to trace occurrences and, if necessary, to reuse the configuration. The documentation must be exportable and importable via the interfaces.
For example, the plant topology, the actually used PEA instances and their conditions, which error messages were issued, which recipes have been run or the configuration of the dashboard as template for future plants could be documented. In addition, unusual events that occurred during operation shall be documented. All this information is supplementary to the automated batch documentation (see Sect. 6.3) and is applied for the evaluation of plant performance and planning of maintenance (predictive maintenance).
7.3 Visualization
The POL must illustrate graphically the aspects of the four categories for the user. For example, a clear display during configuration helps to reduce errors and the time required for error detection. Likewise, messages and user requests must be displayed. User confirmation after a successful import or inconsistencies during the connection of PEAs must be made apparent and highlighted, according to the priority. Furthermore, operation across all steps described above shall be as intuitive as possible. This could be done by implementing various menu bars or a command line, which could be displayed or hidden depending on the respective project step.
7.4 Audit Trail/Change Management
During the work with the POL changes like the addition or removal of modules, changes to the plant configuration, service parameters or process conditions will inevitably take place. These changes must be traceable. A documentation of who made which changes and when must be available. It shall also be possible to jump back to previous configurations.
7.5 Versioning
In order to maintain an overview of the before mentioned changes, especially considering different versions of the POL, PEAs, MTPs, and MTP tools, it shall be possible to provide representation of these changes. Additionally, the restoration of previous versions must be possible. For this purpose, it is adequate to apply a method for versioning, such as R43ples 11. The access permissions of user groups to the version management system should be deliberate to minimize operating errors.
7.6 Validation
Before the implementation and after changes in the created configurations, a procedure for validation must be provided to detect any errors made. This can be done automatically by previously defined algorithms or by virtual commissioning. With the virtual commissioning linked information can be checked for consistency. Extended process models of the respective PEAs could also be used to check the created service sequences (recipes).
In general, it is recommendable to work according to the four-eye principle. The responsible persons could therefore receive a message to pass on their approval. Without validation, it must not be possible to operate the plant.
8 Summary
The catalogue of requirements and suggestions presented in this report can serve as a basis for creating a process orchestration layer (POL). The requirements were developed in several expert workshops, including the presence of various manufacturers, operators, and universities. It should give insights for new, adapted process control systems (PCS) which are suitable for modular plants. Some of the aspects are already relevant for conventional PCS while others need new concepts and methods. Some of these new concepts are developed in the project ORCA (Efficient Orchestration of Modular Plants), which is part of the ENPRO2.0 initiative.
The requirements for a POL can be divided into four different categories with various steps, which need to be fulfilled in order to run a modular plant. While interfaces are necessary for the import and export of different data, the other categories deal with the configuration and operation of one or more modular plants. The PEAs must be interconnected and their offered services must be parameterized followed by a further configuration that adapts the modular plant to the requirements of the processes. With the ready-to-use plant, the orchestration is complete. Monitoring, operation, and execution then take place via a previously created dashboard. Furthermore, several cross-linking aspects, such as permission management and change management, need to be considered. These aspects are required to support the main functions during the modular plant lifecycle to ensure an efficient plant management.
Compared to conventional approaches of process control systems, the POL combines the whole configuration of a modular plant with its execution and control as well. The reusability of pre-engineered PEAs and their automation can potentially save a lot of time and costs when planning and commissioning modular plants as the programming of automation is no longer required when combining the PEAs.
Since the MTP has reached a certain degree of maturity, where visualization and services are described, first prototypes for a POL by different companies/universities have been already developed. The communication and control of three modules from different manufacturers have been presented, e.g., at the ACHEMA fair in 2018. In order to get a higher acceptance in the industry, it is highly recommended to publish other demonstrations of the successful control of several modules by different manufacturers via the POL. Further demonstrators with real industry relevance are set up within the framework of the ENPRO2.0-ORCA project and results will be published soon. Current challenges facing the POL are, e.g., the ongoing refinement in the MTP standardization process and the upcoming versioning of the manufacturer-independent description. Another challenge is coming up in the way process engineers are building the PEAs. Compared to conventional plants additional requirements regarding safety and automation arise. The way these challenges and requirements are met will be described in further publications and demonstrations.
To summarize, a solid and well-coordinated POL ensures the efficient operation of modular plants.
Acknowledgements
The German Federal Ministry for Economic Affairs and Energy (BMWi) is acknowledged for funding this research as part of the ENPRO2.0 initiative (reference code 03ET1517A-I).
The authors have declared no conflict of interest.
Abbreviations
-
- DCS
-
distributed control system
-
- DEXPI
-
data exchange for the process industries
-
- HAZOP
-
hazard and operability analysis
-
- HMI
-
human machine interface
-
- IIoT
-
industrial internet of things
-
- KPI
-
key performance indicator
-
- MES
-
manufacturing execution system
-
- MP
-
modular plant
-
- MTP
-
module type package
-
- NOA
-
Namur open architecture
-
- PCS
-
process control system
-
- PEA
-
process equipment assembly
-
- POL
-
process orchestration layer
-
- WQC
-
worst quality code
