Evaluating BPMN Extensions for Continuous Processes Based on Use Cases and Expert Interviews

Abstract

The majority of (business) processes described in literature are discrete, i.e., they result in an identifiable and distinct outcome such as a settled customer claim or a produced part. However, there also exists a plethora of processes in process and control engineering that are continuous, i.e., processes that require real-time control systems with constant inlet and outlet flows as well as temporally stable conditions. Examples comprise chemical synthesis and combustion processes. Despite their prevalence and relevance a standard method for modeling continuous processes with BPMN is missing. Hence, the paper provides BPMN modeling extensions for continuous processes enabling an exact definition of the parameters and loop conditions as well as a mapping to executable processes. The BPMN modeling extensions are evaluated based on selected use cases from process and control engineering and interviews with experts from three groups, i.e., process engineers and two groups of process modelers, one with experience in industrial processes and one without. The results from the expert interviews are intended to identify (i) the key characteristics for the representation of continuous processes, (ii) how experts evaluate the current usability and comprehensibility of BPMN for continuous processes, and (iii) potential improvements can be identified regarding the introduced BPMN modeling extensions.

1 Introduction

Especially in industrial processes, the process knowledge of experts can be essential for the error-free and, above all, safe operation of production plants. The transformation of this expert knowledge into digital constructs, such as digital twins (Bevilacqua et al. 2020) of a process plant or a control system, has therefore gained in importance (Feichtinger et al. 2022). This not only allows process knowledge to be made explicit, but also allows this knowledge to be integrated into the process operation (process-aware modeling) at runtime (Fur et al. 2023). Process mining has already established itself in various life cycle phases of digital twins. As the concept of digital twins is gaining more and more importance, their automated engineering is also coming to the fore. An interesting application of process mining in this context is the collection of process-inherent relationships based on event logs as a means for the automated implementation of a digital twin (Bano et al. 2022).

Process mining is a relevant and established tool for analyzing and identifying potentials for process optimization and enhancement (Badakhshan et al. 2022). “Globally operating companies (such as BMW and Siemens, among many others) use process mining to monitor their daily operations” (Badakhshan et al. 2022). Garcia et al. (2019) identify manufacturing as one of the most relevant fields for the application of process mining. Especially as support for decision processes, decision mining can draw relevant insights from event logs and thus support the automation of manufacturing processes. In this context, process mining can be used for the predictive control of processes. In the sense of the analytical process industry (Krumeich et al. 2014) predictions can be made about the properties of the end products and further build the foundation for the decision whether to apply specific measures in good time. Shifting the focus from engineering to the optimization phase, process mining in combination with model-driven digital twins was highlighted as a key approach (Brockhoff et al. 2021).

While the concept of model-driven digital twins has been successfully applied in (discrete) manufacturing, the process industry has not taken full advantage of this concept. As a possible reason, in the process industry and in process engineering, not only discrete but also continuous processes and combinations of both play a decisive role (Dietzsch et al. 2007). In this field, the design of control systems focuses on the formal description of industrial processes that deal with measuring and controlling complex systems, such as chemical reactors (Hertwig and Martens 2007), real-time machining hardware, or heat exchangers (Khare and Singh 2010). Such systems are typically applied in mining, production, electricity, gas and water supply as well as waste management and accounted for, e.g., 19.2% of Austria’s gross domestic product in 2021.¹

As emphasized in Pötter et al. (2017), the concept of digital transformation should also be explored for process industry due to the following reasons: (i) Advancing developments in digitalization also make it necessary in the process industry to pursue optimization of control processes to improve quality characteristics and process key figures (yield, cycle time). (ii) The correlations in the adjustment of specific process parameters can be made explicit and collected, not only over a unit operation, but over the entire plant. (iii) An extensive data collection and the explicit description of process-inherent interrelationships (contextualization) enable the comprehensible documentation of even complex processes. This is increasingly required by regulatory authorities, especially in the pharmaceutical sector. (iv) Well-maintained models as well as control systems based on previous analyses can be used not only during the operation of a process plant but over the complete life cycle (design, commissioning, operation, maintenance). (v) Standardized modeling approaches that lead to comprehensible models simplify communication between engineers with different technical backgrounds. Hence, in this work, we aim at investigating the question of whether and how continuous industrial processes can be supported by process-aware modeling in order to facilitate techniques such as process mining and overall contribute to digital transformation in the process industry.

For modeling industrial processes, in addition to standardized notations, Petri nets are increasingly being used to provide a simplified representation of the processes in the form of states and transitions for comprehensible verification (model checking). Petri nets play a significant role as they are one of the most widespread notations used to represent control designs (Ovatman et al. 2016).

Despite their verification power, Petri nets can quickly become unwieldy and less user-friendly, depending on the complexity of the process. In this study, hence, the authors analyze how Business Process Modeling and Notation (BPMN)² can be used for modeling processes in the field of process engineering, especially continuous processes, not instead, but complementary to Petri nets. This proposition is based on several factors: (i) BPMN is a widely adopted standard for modeling business processes (Kalenkova et al. 2016), (ii) its graphical notation and extensibility offer potential for abstraction (Stroppi et al. 2011), (iii) it can be processed by various workflow tools due to its widespread adoption, and (iv) BPMN has already found applications in the modeling of discrete manufacturing processes (Mangler et al. 2019; Köcher et al. 2022).

In order to create a basis for this work, the definitions for discrete and continuous processes are first taken from process engineering, since an explicit distinction is essential here. Discrete processes work on identifiable distinct items, and have an identifiable output. In other words, of a countable number of process instances, each produces an identifiable outcome, such as manufactured items, or distinct customer interactions. Continuous processes, by contrast, are characterized by the cyclic processing of inputs, which is only interrupted by defined conditions (Hertwig and Martens 2007). In industrial processes, the choice of process depends on various factors, such as yield, the quantity of raw materials to be processed, available resources, or product quality specifications. Hertwig and Martens (2007) emphasize that for this type of process control, appropriate control technology is indispensable. Some processes require the integration of discrete elements into a continuous process environment. The combination of both approaches leads to more complex control mechanisms than purely continuous processes. In a work in which the differences between the two types of processes are described in a comprehensible way, the following definitions can be found:

• Discrete Processes: “The raw material(s) is charged into the system at the beginning of the process, and the product is discharged all at once sometimes later. No ingredients cross the system boundaries between the time the raw material(s) is charged and the time the product is discharged.” (Lee et al. 2015, p.191)

• Continuous Processes: “The material(s) and product are continuously charged into and discharged from the system, respectively, throughout the duration of the process.” (Lee et al. 2015, p.192)

As an example for a thermal process, which can be operated in both ways – as batch process or continuously – rectification is introduced. Rectification is a sequence of distillation processes and therefore also known as continuous distillation. For the batch process, a receiver tank is mounted to the bottom of the column, in which the feed mixture is uniquely fed to the system (Düssel and Warter 2000). For continuous rectification the feed addition as well as the product and waste extraction from the system including return flows run simultaneously during the complete process as soon as the column has reached a steady state. A combination of both systems is a batch rectification with a continuously added entrainer substance (Köhler et al. 1995). The difference lies in the type of temporal progression that is aimed for in the parameter management of the process. Both processes are displayed in Fig. 1.

Fig. 1

Batch and continuous rectification process flow diagram (Köhler et al. 1995)

According to Bindel and Hofmann (2009) batch or discrete process controls are realized with event-discrete control systems while control systems for continuous processes include closed-loop controls. Closed-loop controls keep processes parameters at a defined value, the set point. Open-loop controls, on the other hand, issue instructions without implicitly considering the state of the system (Tröster 2005). The temperature control knob on a radiator is an open-loop system; the amount of water that runs through the radiator is controlled, the current temperature is not taken into consideration. A thermostat is a closed-loop system as it checks if a certain temperature is reached and controls the water flow accordingly.

In this work, at first, a structured literature review is performed to identify research gaps and potential for further development and patterns in the process life cycle of continuous processes from different perspectives. The insights gained from the literature review indicate that there is potential for applying methodologies from business process management for continuous processes in industry. As a reference on how to bridge both fields, characteristics of continuous processes are extracted from technical literature for industrial control systems, and evaluated based on a second structured literature review on the automation of continuous processes in industry. BPMN extensions for continuous processes³ are presented and illustrated through selected real-world scenarios. Moreover, the execution semantics of the proposed extensions is provided, along with implementation details. The BPMN extensions are the evaluated based on expert interviews in order to achieve results in terms of usability and openness of potential users to a new approach to the presentation of continuous processes. In order to obtain comprehensive results and to derive measures for the improvement or modification of the introduced BPMN modeling extensions, experts from process engineering and process modeling were consulted. At this point, the focus of the work is primarily on industrial processes. Nevertheless, the approach that shall ultimately be presented as a result is intended to serve as a basis for process flows from various fields.

The paper is structured as follows: In Sect. 2 the related work is discussed to be able to classify this paper in the current state of the art. Further, research gaps in the development and improvement of continuous processes in process engineering are referenced in the form of a literature study to describe the motivation for this topic. This work introduces a set of requirements for modeling continuous processes and provides an overview of the characteristics of continuous processes identified in literature of the last 20 years in Sect. 3. Section 4 presents BPMN modeling extensions, necessary to realize the requirements, along with application examples in the form of process models. The main contribution of this work is found in the form of insights gained from expert interviews along with a discussion in Sect. 6. Section 7 concludes with implications and an outlook.

2 Continuous Processes: Structured Literature Review and Industry Standards

In the interests of sustainability and cost savings, in both, the process and manufacturing industry, collecting data as efficiently as possible and generating insights from it using advanced methods are significant. Since process technologies such as process mining have already been successfully implemented in discrete manufacturing (Rinderle-Ma and Mangler 2021), it is worth considering whether these technologies can also be used for continuous processes in the process industry to generate corresponding added value. Hence, in Sect. 2.1, we conduct a structured review of literature at the intersection of continuous processes and (business) process technologies. The results of the review are supposed to motivate research on process technologies for continuous processes overall and specifically to identify open challenges. The literature review is followed by a discussion of scientific workflows due to their focus on data in Sect. 2.2 and of industry standards in Sect. 2.3.

2.1 Structured Literature Review

The review targets literature at the intersection of continuous processes/process engineering and process technologies. Hence, the search terms focus on continuous processes refined by the process development and implementation phases. The search terms are then compiled and evaluated based on scientific databases Scopus⁴ and dblp.⁵ Selection criteria comprise general ones such as English language, public availability, # citations> 5 before 2017, spanning a time period since 2002, and selecting work where the term “continuous” refers to the process. From 700 hits overall, 401 papers were selected based on the criteria, read, and analyzed. Descriptions of the search strategy and the results and summaries can be found in the supplementary material⁶ of this work in Appendix E.

The analysis of the selected literature is based on a two-dimensional classification in order to identify “white spots” indicating open research challenges. The first dimension reflects the process life cycle, inspired by literature (Weske 2007; Leitner and Rinderle-Ma 2014), covering phases Design, Configuration, Enactment, Evaluation, and Change. We interpret these phases for continuous processes as follows: Continuous processes are regarded to be in their Design phase if the paper focuses on the development, modeling, simulation, and validation of continuous process models. The Configuration phase is entered as soon as the implementation of the process or the commissioning is described. The Enactment phase comprises the execution of a continuous process. This also includes the execution on laboratory scale process plants that can server as a blue print for industrial-scale applications. The continuous process is monitored at run-time and process data is collected. In the Evaluation phase, the collected process data is evaluated and analyzed. Publications fall into this category if additional insights are derived from the collected data using specific methods. Change classifies publications which describe an approach to improve a continuous process based on the preceding collection and analysis of process data.

The second dimension covers the thematic focus of the research, which is derived from the process mining perspectives as described in van der Aalst and Carmona (2022); Yasmin et al. (2018). The Control perspective is chosen for papers which evaluate different process flows to reach the same or a similar final product. An example is the comparison of a discrete or batch and an equivalent continuous process. Papers have been assigned to Data if the collected process data has been the research focus. The class Time marks papers that concentrate on events or time as a process parameter. Resources can be used as a label for publications, that focus on the involvement of technical equipment and operators.

The results of the literature search classified along the dimensions process life cycle and process perspective are displayed as bubble chart shown in Fig. 2. Regarding the life cycle, most papers focus on the Design of continuous processes, followed by Change, Enactment, and Evaluation. The least number of papers is assigned to the Configuration phase, although it refers to important topics such as commissioning of continuous process systems and assistance systems.

Regarding the process perspectives, most approaches focus on Data overall and across all life cycle phases. This differs from discrete processes where “[t]he control-flow description is the backbone of any process model” (van der Aalst et al. 2011) as it captures the behavior of a process. Also Time and Resources seem a bit under-represented given their significance for continuous processes driven by temporal constraint and requiring resources for their execution.

Fig. 2

Number of search results along life cycle phase and process perspective; bubble size represents number of paper for the class combinations; papers can be counted for more than one class

In order to analyze the combinations of life cycle phase and process perspective, Figs. 3 and 4 depict the relative numbers from the view point of the phases and the perspectives respectively. We can see that the data perspective plays an important role across all life cycle phases. This is not surprising, since process data is the basis for calculating and evaluating process performance and product quality. Monitoring process data gives insights into the state of the process and is therefore also relevant for safety. Resources seem important for the configuration phase and control-flow for the enactment phase, as well. The second observation can be also seen from the viewpoint of the perspectives where for control-flow the enactment phase seems even more important than the design phase which is “dominant” for the other perspectives. Aside design, for resources, the other life cycle phases seem equally important while for time and data, the change phase seems to be crucial. From this it can be interpreted that different operation modes for the same result were more often treated by experiments than by modeling and simulation in research. The execution of processes in a pilot or laboratory plant is more often implemented in a comparison of batch and continuous processes than just modeling and simulation.

Fig. 3

Relative representation of the process life cycle phases in the individual perspectives

Fig. 4

Relative representation of the perspectives in the individual process life cycle phases

Overall, we can conclude that applying process modeling and analysis techniques to continuous processes seems promising, in particular, to capture the process behavior through the control-flow perspective. Moreover, time and resources can emphasized as important perspectives that currently fall short behind the data perspective. From a life cycle phase point of view, configuration offers the most potential for further research, followed by enactment and evaluation.

2.2 Scientific Workflows

The purpose of scientific workflows is the description of data processing steps in the context of a scientific process (Sadeghibogar et al. 2023). Scientific workflows deal with the uniform description of executing scientific methodologies in order to achieve traceability and reproducibility of results and use progressively emerging and iteratively improved models which are mainly focused on the transport and processing of data (Barker and Hemert 2007). Existing approaches distinguish scientific workflows from business processes along the dominance of data flow (scientific workflow) and control flow patterns (business process) (Ludäscher et al. 2006) and the flexibility in design (Gil et al. 2007). Based on the previous descriptions of processes in the manufacturing industry, overlaps with scientific workflows can be identified. The choice between the process types discrete and continuous based on certain characteristics in process engineering already reveals connections to scientific workflows. Among others, scientific workflows can be characterized using metrics such as execution runtime, requirements for inputs and outputs as well as resource management (Juve et al. 2013). These metrics conform to the previously mentioned decisive factors such as yield, input materials, products, and availability of resources. Following the approach of using closed-loop control as a foundation for modeling continuous processes further overlaps become apparent. With scientific workflows, the repetitive execution of processes with different sets of parameters, which have partly been modified based on findings from the previous cycle, are found as well as automated error handling (Weiß et al. 2015). In the context of this work it is assumed that an instance of a continuous process with an end event is reached as soon as the cyclic execution is interrupted by specific conditions and the system is transferred to a defined state. In Weiß et al. (2015) on the other hand, the rewinding of complete process instances is described. In the process models described later in this paper, only a limited part of the process is repeated cyclically and can therefore be regarded as continuous. The complete process instance also includes the tasks for starting up and shutting down the process. An intersection to be mentioned between both topics can be found upon further research in the consideration of data streams. As described in Beaulieu-Jones and Greene (2017), continuous analysis is an essential component in numerous scientific experiments. In this context, reproducibility is cited as a goal, or its improvement. Once again, it is evident, even in the processing of continuous data streams within scientific workflows, that the cyclical processing of incoming data (PLC), here in the form of batch processing of data, is utilized (Olston et al. 2011). Nevertheless, there exists a distinct difference between continuous processes in the industry, which require, even during system shutdown and departure from continuity, transitioning the system into a defined and, above all, secure state. In the continuous analysis of data streams, the question arises whether a workflow focused solely on data processing also requires transitioning the underlying system into a secure state. It is important to emphasize that the characteristics of the underlying process environment play a significant role in assessing the necessity of this step. The continuous operation of a reactor is managed differently than the continuous analysis of data streams. Approaches to the continuous processing of data streams in scientific workflows can partly be integrated into the consideration of the continuous components of processes in process engineering. However, these need to be expanded with additional conditions and measures.

2.3 Standards Known from Process Engineering

Two elementary standards in the process industry are ISO Central Secretary (2010), the specification for diagrams for process industry, and ISO Central Secretary (2015), schemes for the chemical and petrochemical industry. The standard ISO Central Secretary (2015) describes how process plants in chemical and petrochemical industry and their elements are to be depicted in diagrams, while ISO Central Secretary (2010) provides the specification for a wider range of industrial processes. As stated in ISO Central Secretary (2010), diagrams following the introduced specifications shall be used not only for the construction of the process environment (process plant), but also during the complete operation of the system as means to represent the individual hardware elements. The differentiation into overview and function diagrams as described in ISO Central Secretary (2010) serves a similar purpose as the differentiation of a process model in BPMN into an overview process and multiple sub-processes. While overview diagrams give a general view of the complete process environment (e.g., complete plant or reactor including sensors and actuators) and point the user to more detailed sections, the functional diagrams give insight into the functionality of the respective elements. However, according to ISO Central Secretary (2010), overview diagrams can be depicted in form of network maps, block diagrams, process flow diagrams, and piping and instrumentation diagrams. This variety of different ways of presentation offers the possibility to individually depict and consider the specific aspects of a process system. However, these standards for chemical engineering focus on hardware description and do not describe the control logic that is necessary for execution of the process. This aspect is covered by programming languages specified in International Electrotechnical Commission (2013). Here, graphical notations such as function block diagrams, function charts and ladder diagrams, but also textual languages such as structured text and instruction list are defined. Despite the variety of these standards engineers still need to transform these standards into low-level equivalents for model checking purposes Ovatman et al. (2016). Issues such as the representation of time constraints and cyclic execution of process flows while examining the complete control system as a whole as well as maintenance of process models of higher complexity in a PLC are discussed. Since SFCs are well suited for modeling parallel processes, they have been widely used in recent years. Petri nets and timed automata in particular have become established for temporal processes (Ovatman et al. 2016).

In this work, control cycles were deliberately chosen as the basis for representing continuous processes as these are used for the description of control flows in continuous processes. Since previous scientific work has mostly focused on the design phase in the process life cycle, specifically with an emphasis on data, bridging the gap between business process management and chemical engineering can build a basis for new approaches in other process life cycle phases (e.g., configuration, enactment and evaluation) and also allows to deal with other perspectives (e.g., time and resources) in more detail. Modeling approaches and process-awareness as known from business process management enables to capture the behavior and hence to gain new insights based on process mining methods.

3 Modeling Requirements

Due to the distinction between discrete and continuous operation in the design of processes in process engineering, approaches for the design of continuous processes are used as a basis for their modeling in this field of expertise. For enabling the process-oriented modeling of relevant control sequences, at first, characteristics for modeling continuous processes have to be identified. Based on the findings from technical literature, characteristics for continuous processes were extracted, which in this work form the basis for the formulation of a hypothesis for a first set of basic modeling requirements. These requirements are intended to provide initial indications for the representation of basic properties of continuous processes. To evaluate the requirements, a second literature study is carried out using the search term “automation industry continuous process” in the Scopus database. The search term is chosen in order to yield approaches for the implementation of continuous processes in industrial setting. Note that the requirements are not intended to provide a guideline for differentiation from discrete processes.

3.1 Technical Literature

In terms of process engineering, processes are divided into two groups, i.e., batch and continuous processes. A characterizing description of continuous processes in comparison to batch processes is given in a Siemens manual.⁷ According to this manual, a continuous process is characterized by a "Continuous product flow" the main differences between continuous and batch processes can be found in properties such as process types, quantification of products, predictability, operating time, and level of operator interference. Continuous processes are characterized by a continuous mode of operation, whereby a specified state is always to be reached or maintained (Continuity).⁷ Operator intervention is rare but possible, and the degree of automation in such systems is high (Dietzsch et al. 2007). Since individual steps of the process are run through simultaneously during operation due to this continuity, it must also be possible to display or arrange them in parallel in a model (Parallelism), in a similar way as for the parallel execution of control loops (Ovatman et al. 2016). According to Tröster (2005) continuous systems are characterized by parameters which may take any value in a defined boundary. Further, Tröster (2005) conclude that the frequency, in which data access and control tasks are performed, determines a discontinuous behavior which needs to be counteracted by finding a fitting control strategy (Real-time). Due to hardware performance constraints truly continuous behavior may not be realized as physical sensors can only provide data in short time intervals. Therefore, characteristics of continuous processes include state queries and control tasks based on the state queries. Further, the timing of control processes in this context is of particular importance. Due to a high level of automation, elements must also be provided to allow the process to run or shut down in a controlled and safe manner in the event of exceptional circumstances such as emergency cases or maintenance (break conditions, exception handling) (Schmid 2015). Finally, understanding the process and, consequently, the comprehensibility of the presentation of the process (limited complexity) in question are the basis for checking and finding errors (Ovatman et al. 2016). Based on functional descriptions from technical literature (Schmid 2015; Dietzsch et al. 2007; Tröster 2005; Ovatman et al. 2016), a series of characteristics for representing continuous processes is proposed. From these elements, requirements for modeling continuous processes have been derived.

• Requirement 1 – Continuity: Continuity in industrial processes in the context of this work is defined by the repetitive simultaneous execution of the same set of process steps. A continuous process is characterized by uninterrupted operation after initial start-up. Operation is interrupted only by exceptional circumstances (e.g., maintenance work) and is not limited in time.⁷ Starting materials are continuously fed into the process while the finished products are continuously removed (Dietzsch et al. 2007).

• Requirement 2 – Break Conditions: In order to be able to completely describe a real-world continuous process, it must also be possible to define conditions that allow a breakout from continuity. In the case of a real-world process plant, safety measures can be seen as an example of such conditions (Schmid 2015) as well as maintenance work or operator intervention (Dietzsch et al. 2007).

• Requirement 3 – Real-Time Process: As explained in Tröster (2005), simultaneously occurring process signals have to be processed in time by a real-time system. In order to be able to specify these conditions in the model, it must be possible to define time conditions accordingly with the help of the notation.

• Requirement 4 – Parallelism: A continuous process is characterized by a continuous flow of material.⁷ However, the material flow that is about to leave the process environment passes through different process steps than the material that is just being fed in. These steps need to be performed in parallel as material is fed in and out all the time. The hardware for process control is designed accordingly for several simultaneous processes (Schmid 2015).

• Requirement 5 – Exception Handling: If unpredictable events occur in a real-world process, it is necessary to react to these new conditions as in a discrete process. Since continuous processes cannot be reacted to in the same way as discrete processes, it must be possible to define measures. A workpiece can be removed and the machine can be stopped, but a heated reactor cannot immediately cool down to room temperature. In a continuous process the process equipment should be shut down or handled in a controlled manner after exceptional events (Schmid 2015).

• Requirement 6 – Limited Complexity: An obvious requirement that must not be missing from this list is comprehensibility of the representation of processes. Since the representation of continuous processes can become complex for extensive processes, care must be taken to ensure that the models are easy to understand for users. BPMN was chosen as the means of modeling because of its expressive standard and simplicity (Zarour et al. 2020).

3.2 Literature Study

In addition to the extraction from technical literature, a literature study was carried out to underline the importance of the requirements. A detailed description of how the literature study has been conducted can be found in the supplementary material⁸ in Appendix E. A literature study has been conducted on publications from the last 20 years, searching for the keywords “automation industry continuous process” using the Scopus database. This search generated 336 of initial results. Search criteria are a publication date from 2002, written in English as well as the search terms had to appear in the title, in the abstract or in the keywords. The final selected results were examined to determine whether the requirements listed here were addressed in the work. For example, real-time processing is represented by the reference to time dependency of parameters and the emphasis on real-time data collection and control commands. Exception handling refers to the need to be able to react automatically to various unforeseen conditions without endangering people or equipment. Break conditions indicate that even in continuous processes, a start-up and shut-down phase must be observed or maintenance work must be carried out. Continuity was given if explicit reference was made to the continuous operation of the processes under normal conditions. Simplicity refers to the influence of operators and the optimal presentation of the processes. Parallelism is represented if the simultaneous execution of control tasks or the parallel planning of plant components was described in the publication. Table 1 displays the number of approaches that feature each of the six identified modeling requirements. The corresponding list of references along with details about the further selection process can be found in the supplementary material in Appendix E.

Table 1 Modeling requirements for continuous processes with number of supporting approaches

Each of the Requirements 1 – 6 can be found in scenarios in the process industry. The description of a scenario is illustrated based on the example of a temperature control system using a PI controller based on explanations from “The MathWorks® Support” documentation for version R2022a.⁹ The example is shown in Fig. 5 and was modeled with standard BPMN using Signavio.¹⁰ Basically, constructs to model Requirements 1–6 are available in standard BPMN, but they cannot be implemented explicitly. An example process is modeled in three different styles in order to demonstrate the differences using standard BPMN (see Fig. 5) and BPMN in combination with the suggested extensions (see Fig. 6). The third model version as implemented in the Cloud Process Execution (CPEE) engine¹¹ (see Fig. 7) as used as example in the expert interviews in Sect. 4. Figure 5 shows that cancel as well as measure and control tasks have been inserted, but they do not differ graphically. Besides reading the labels, there is no visible difference between the section for measuring tasks and the section for control parts. Using the suggested extensions, the measuring, control and cancel tasks are preceded by the appropriate and visually distinctive event. Further, instead of a sub-process with multiple exclusive gateways for a breakout from continuity that can happen at any time a new gateway is introduced to (1) explicitly mark the continuous part of the process, (2) automatically include cancel events with conditions to break out from continuity, (3) start every line for measure and control tasks with specified timer events, (4) automatically initiate parallel modeling of measure, control and cancel tasks, (5) enable modeling of “Clean-up” tasks after a cancel event has been triggered and (6) reduce multiple exclusive gateways and cancel end events. Hence, BPMN modeling extensions enabling the characteristics and clear representation of continuous processes are elaborated in Sect. 4. The end user should be enabled to model processes and generate executable code from them. This model-driven approach builds a bridge to the automation of processes in a similar way as described by Drave et al. (2022). A process is modeled using BPMN. Then, the execution code is developed based on this model (i.e., in a model-driven manner) with the help of a suitable execution semantics. The execution code then enables the automation of the process.

Fig. 5

BPMN Model of a temperature control process, Standard BPMN, in Signavio

Fig. 6

BPMN Model of a temperature control process, Standard BPMN and extensions, from Signavio with adaptations

4 BPMN Extensions for Modeling Continuous Processes

Based on the requirements elicited in Sect. 3, in the following, BPMN as standard process modeling notation is assessed. Building on this assessment, modeling extensions in the form of new BPMN elements are proposed and illustrated using selected real-world scenarios.

In general, the model of a continuous process should imply a continuous flow without having to set a limited number of repetitions or a time limit from the beginning since continuous processes in industry are intended to run indefinitely. Continuity needs to be presented in form of a loop. BPMN supports loop characteristics for tasks and sub-processes (Object Management Group IO 2011). However, this modeling option is confined to individual tasks and sub-processes and thus may lead to complex, multi-level process flows (Req. 1). Conditions to break out of the continuous flow can also be applied to tasks and sub-processes with loop characteristics (Object Management Group IO 2011). In case the break conditions are met, the looping of the defined tasks stops which leaves open the question of where to insert clean-up routines. For defining the exception handling of a continuous process and allowing the option to define clean-up sequences, Cancel Events can be used. However, for Intermediate Cancel Events only Boundary Interrupting Events are defined (Req. 2). According to (Tröster 2005), a real-time system reacts to simultaneously occurring process signals in time with a corresponding output. This implies that each task needs to be manageable according to the priority level in the timeline of the process in order to guarantee real-time operation of the system. Some control mechanisms are designed to work faster than others. Therefore it must be possible to define and limit the time sequence of tasks and also for complete iterations. BPMN supports Timer Events which need to be applied correctly and comprehensibly in order to understand the implied constraints and to display them correctly (Req. 3). Parallel processing of tasks and task sequences needs to be supported by the chosen modeling environment. In addition, it must be possible to incorporate specifications defined for continuity and real-time processing. Parallelism can be modeled in a way similar to loops in form of attributes for tasks and sub-processes (Object Management Group IO 2011). The orientation of the attribute marker indicates whether the multiple sequences are processed in parallel or sequentially (Req. 4). Again, an increasing complexity of the process leads to an incomprehensible model. For exception handling BPMN already implies the usage of Intermediate Events (Object Management Group IO 2011). Timer events can be applied to deal with time restrictions which are fundamental for continuous processes (Req. 5). If all necessary details of a continuous process are included in the model, the level of complexity must not exceed a point at which users no longer understand the process behind the model. To prevent this danger, modeling conventions need to compensate complex relations, while still leading to a detailed and comprehensible process model (Req. 6). To make continuity visible, an element needs to be defined that allows several parallel branches to run in a loop without a confined number of cycles. For this purpose a gateway is useful. Looking at the existing gateways, the following considerations arise. Using an Inclusive Gateway, the available branches are traversed based on conditions whose query must return true. By contrast, after an Exclusive Gateway one or more paths can be traversed in parallel.

A new gateway may be defined to allow the representation of a continuously running loop with parallel branches. Contrary to common Event-based Gateways, which do not allow the use of Cancel triggers for Intermediate Events in branches after the gateways, the new gateway lets tokens traverse each branch which allows for the processing of multiple parallel branches simultaneously (Object Management Group IO 2011). Since the BPMN modeling extensions are developed on the basis of concepts from control engineering, corresponding events are introduced for the various tasks in a control process. These include events in simple form to measure the state of the system (measure), events to influence the system if necessary (control) and events to indicate under which conditions the continuity will be broken (cancel).

The BPMN extensions for continuous processes are specified by introducing new elements while following guidelines from literature revolving around the quality of notations. Moody (2009) describes how the factor of cognitive effectiveness helps to evaluate the quality of a notation. The author further introduces principles for defining a notation, which can be summarized in the following way: clear mapping between semantics and symbols, the possibilty to distinguish symbols, recognizable meaning behind the symbols, regulation of complexity, information processing from different graphical sources, usage of visual variables, integration of text, regulation of the number of different symbols, and considering to use different visual dialects.

Although BPMN is a generic modeling notation which can be used to model processes from different fields, for some scenarios it seems necessary to bring specific domain concepts into BPMN by extending the standard (Braun and Schlieter 2014). However, BPMN is considered a notation that allows for extensions while maintaining the specifications of core elements (Stroppi et al. 2011). Following the example of Braun and Schlieter (2014), the domain specific characteristics are analysed in this work and extensions have been formulated.

As will be explained later, different symbols were used in the modeling extensions for two events (measure and control) that have different meanings but similar semantics. On a higher level, however, they can be assigned to the same class with reference to standard BPMN. One event processes cyclically incoming data, the other initiates the overwriting of data or the corresponding write commands to external systems. Due to the importance of data in this process-aware approach, it makes sense to consider insights from data modeling. In data modeling, entities, their relationships and also categories find application in order to offer a structure that allows to make connections visible and clear. Without support for sub- and super-classes, the grouping of entities using categories allows an improved handling of cardinality and dependency properties (Elmasri et al. 1985). In data models, update methods that work in accordance to cardinality constraints, should leave the correct further structure untouched. By using these constraints and appropriate execution semantic, data models can remain consistent but also be extended with little risk (Balaban and Shoval 2002, 2002a). Also, in the case of using the extensions and updating data, the extent to which cardinality constraints should be included to avoid inconsistencies must be considered. Going back to modeling the overall process, (Figl 2017) determine influence factors on the comprehensibility of process models, including presentation medium, notation, and model characteristics. Mendling et al. (2019) provide an overview of factors that influence the viewers’ understanding of process models as described in various publications. Here, experience stated in years, self-evaluation regarding familiarity, and knowledge of the domain and problem-solving skills are listed among others. In their work, participants have been confronted with different BPMN models to test comprehensibility. For the quantitative and comprehensible description of the participants, variables have been introduced which take the individual knowledge, experience and education into account.

Taking the discussion of existing literature into consideration, the BPMN modeling extensions (i.e., elements) for continuous processes are designed with the goal to be simple in their graphic presentation and to correspond to their envisioned functions. The number of new elements has been kept to a minimum, while making them easy to distinguish. Moreover, the elements are designed similar to modeling elements in standard BPMN in order to support the mental map of users. The Closed-Loop Sub-System Gateway, for example, is modeled using a diamond shape (see Table 2) such as in BPMN gateways and the Intermediate Catching Events are characterized by a circle with different contents (see Table 4). For the implementation of the new elements in the CPEE process engine, we opt for placing an element’s label next to the element due to clarity reasons.

Closed-Loop Sub-System Gateway As a combination of an Inclusive and an Event-Based Gateway, the gateway for a Closed-Loop Sub-System holds advantages of both and represents continuity and parallel execution of multiple simultaneously running process flows. The symbol with a short description can be seen in Table 2.

Table 2 Closed-loop sub-system gateway

A Closed-Loop Sub-System Gateway allows the modeler to model a separate process section for the continuously running process steps (Req. 1). In this system, the modeler can insert tasks to query the state of the system as well as to regulate it. Specially defined timer events (Req. 3) are provided for this purpose as indicators for the time conditions of the process and indicate the start of a new cycle for a specific process line (Req. 4). An additional possibility to define how the whole system behaves when the time limit is exceeded is the attribute “Interval duration over-run”. The attribute “Measure-control cycle execution”, on the other hand, defines how state queries and regulations are related to each other. A more detailed explanation of these attributes can be found in Table 3. For breaking out of the continuous process loop, Cancel Events can be defined (Req.2). As soon as one of the conditions of the events defined in this way occurs, the clean-up tasks modeled after this event are executed (Req. 5) and the Closed-Loop Sub-System is exited. This method of presentation is intended to summarize all the characteristics of a continuous process in a way that is clearly understandable to the user (Req. 6).

Intermediate Catching Event Types To indicate which tasks are executed in one of the parallel branches under the Closed-Loop Sub-System Gateway, three new symbols based on Intermediate Catching Events are proposed in this work. The symbols are shown and described in Table 4.

Table 3 Closed-loop sub-system attributes and model associations

Table 4 Intermediate catching events for continuous processes

Application to real-world scenarios In this work, the approach for modeling continuous processes known from process industry uses common control loops and control algorithms as a template for the description of the process logic. In order to determine what type of continuous processes can be modeled using the described extensions, common types of control algorithms need to be addressed. The following controller types are used in the automation of process plants: P, I, PI, PD, PID, PT1, PT2 (Winter and Böckelmann 2015; Schmid 2015; Wellenreuther and Zastrow 2005). These therefore form the basis of the functions that are to be mapped onto the extensions. The controller types differ in their description in mathematical formulation and have different objects. As long as the controllers can be described in a script and a manipulated variable is supplied, these elements can be integrated into the process graph and exchanged at will. With the use of the extensions, common control sequences from process technology can be mapped.

To demonstrate how the BPMN modeling extensions can be applied for continuous processes, two process examples taken from educational material have been modeled and used as illustrative material for the expert interviews. Both examples are heating processes in the form of feedback control loops with different controller types and differently defined conditions, which also influence the scope of the respective model. The control of temperature values are part of many industrial processes (Winter and Böckelmann 2015).

The first process example is based on explanations from “The MathWorks® Support” documentation for version R2022a¹² and describes the temperature control in a tank via a heat exchanger. The documentation describes the impact of a disturbance in the form of the varying temperature of the incoming liquid flow. The temperature of the fluid in the tank is measured and compared to a set point value. The difference of these two values is used to calculate the necessary input voltage for the valve which controls the steam flow through the heat exchanger pipe using a PI controller. The respective process model shown in Fig. 7 consists of a Closed-Loop Sub-System Gateway with the attributes Interval duration overrun set to wait and Measure-control cycle execution set to sequential. These settings have been chosen since the example does not contain any timing specifications for the execution of the control system such as a maximum cycle time. Thus, in this case, sequential could also be replaced by parallel. Inside the sub-system, two Measure events are modeled parallel to each other for measuring the current temperature of the system, tank_T1, and the temperature of the inflow, d_T2. After the task Get tank_T1 a conversion script is inserted in order to demonstrate that further steps necessary to process the incoming value can be integrated into the flow as required. Both values are used to calculate the necessary control voltage for the valve in the script task PI controller, again a conversion step can be integrated and the final signal can be sent to the actuator using a service call Send PI_Controller.MV. The condition for the termination of a continuous process like this is not specified in a block diagram and would be relevant for the execution of the system in a process plant. For this example, the condition StopActivated == true was chosen as a trigger for the transition of the system to a consistent state by executing the script Execute shutdown sequence. After the execution of the script, the Closed-Loop Sub-System is terminated.

Fig. 7

Heating process with PI controller (Process Model Example 1)

The second process example is also a heating process based on an example from Siemens teaching materials.¹³ The example from the teaching materials should be seen as a practical basis and not a direct template for the process model (Fig. 8). As described in the documentation, in this example the temperature of the medium in a reactor is controlled using a heating element. For this purpose, a PID controller is used in this example. Although manual operation is mentioned, we assume for this example that the process is running in automatic mode and one of the cancel conditions is switching to manual mode. Other cancel conditions, according to the document, include an deactivated main switch, an activated emergency switch, and operation outside specified limits such as process values below the minimum fill level and above the maximum temperature. The following values are recorded here for the state queries: current temperature in the reactor (T_Reactor_In), the current level of the medium inside the reactor (Level_Reactor_In), current operation mode (OperationMode), status of the emergency switch (EmergencyStop) and status of the main switch (MainSwitch). The attributes for the Closed-Loop Sub-System Gateway are cancel and sequential. Since the documents serve to familiarize students with working with controllers with real-time conditions, the functionality of a PLC is to be depicted here. A current image of the inputs is made (measure events and tasks), these are processed and finally corresponding outputs are issued to the actuators (control events and tasks). Since in PLCs calculation cycles are subject to time conditions and may otherwise be aborted if exceeded, cancel is selected here. Sequential is used because inputs are collected and processed at defined times in a single process flow without parallel activities. Due to the amount of detailed information that can be derived from the Siemens training documents, the second process model is considerably more extensive than the first.

Fig. 8

Heating process with PID controller and additional Measure and Cancel events (Process Model Example 2)

Control loops can differ in the controller type (P, PI, PID, etc.) and in the way in which parameters are measured and processed. To show further examples in the application of the BPMN modeling extensions, three typical control types are discussed here. Besides the common feedback control loop as seen in Fig. 7 and 8, feed forward control can be used to additionally improve the action of the controller and for example to compensate overshoot (Khare and Singh 2010). In addition to these two variants, an example of cascade control for the position control of an axis in a machine tool is presented. The model is based on the description of Schmid (2015). Cascade control can be found in use with inertial systems (Winter and Böckelmann 2015).

Feed forward Control – Heat Exchanger II Feed forward control is another option for controlling a heat exchanger. A feed forward system is mostly coupled with a feedback system. The feed forward controller reacts to disturbances before they influence the system. The feedback controller compensates the remaining errors (Khare and Singh 2010). In contrast to feedback control, feed forward control does not necessarily need a measured value for its function. The process model in BPMN in combination with the introduced BPMN modeling extensions is shown in Fig. 9 on the left.

Cascade Control - Position Control in Machine Tool For the position control of drives in machine tools, the cascade control method is usually used. The control model consists of control loops that are nested within each other (Schmid 2015). The output variable of one control loop is the input variable of the following control loop. Therefore, a direct time dependency between the individual control loops is evident and must be displayed in the workflow. The BPMN workflow model of the control procedure including the BPMN modeling extensions is shown in Fig. 9 on the right.

Fig. 9

BPMN model of a feedforward control system for a heat exchanger (Khare and Singh 2010) (left) and a cascade control system for position control (Schmid 2015) (right), taken from Strutzenberger et al. (2021)

5 Execution Semantics

The purpose of execution semantics is as follows: (1) When creating a process model, the meaning of every element is important; (2) When implementing a process engine that can execute the process models, each modeling element and its interaction have to be unambiguous; (3) It must be possible to prove that the execution is correct.

There are multiple accepted ways of describing the execution semantics (Mosses 2006). One accepted way is by translation into an executable language. Another one is to describe execution semantics through the Structural Operational Semantics SOS framework. The evaluation of the execution semantics is typically either formal (e.g., by describing the exact behavior as mathematical behavior; complex) or informal (e.g., through manuals and examples; simple).

For the purpose of this paper we deem the understandability of the approach important, and thus will focus on (a) the translation into an existing language, and (b) an informal description where necessary. In order to describe the semantics, we use the elements and relations depicted in Table 5.

Table 5 Elements and relations

The gateway S is a combination of loop and parallel gateway. Based on the implementation (and the properties on the gateway), each event (that is the first element of each branch) can be triggered. The generic relationship between elements is as follows: $\{S \rightarrow B^+\}$ and $\{B \rightarrow (M^+ C^+ \mathcal {E}^+)\}$ and $\{M \rightarrow X\}$ and $\{C \rightarrow (X^+,C^*)\}$ and $\{\mathcal {E} \rightarrow X\}$. X denotes the possibility to insert any possible BPMN gateway, activity or event. The idea of $\mathcal {E}$ is, that as soon as a cancel condition evaluates true, cleanup X happens, and then the loop finishes. Table 6 explains how the properties influence the execution.

Table 6 Event properties

The BPMN extensions introduced in Sect. 4 have been partially implemented in the CPEE process engine (Mangler et al. 2019). All process models depicted in Fig. 7 – 9, for example, are modeled in the CPEE process engine. A full implementation consists of several steps, all relying on the execution semantics described above:

• Extending a process modeler to support the graphical elements: the CPEE BPMN modeler only allows the insertion of elements that lead to syntactically correct process models. The execution semantics serves as a rule-base for checking consistency on insertion, deletion or change.

• Extending a process execution engine so support the elements: As discussed in Sect. 3 and exemplified in Fig. 5, the extensions can be translated to plain BPMN. So for the CPEE process engine, which internally works with model transformation, the implementation is rather straight-forward, as all the BPMN primitives are already supported. But this approach has also disadvantages, as all aspects of the extension that work with time-guarantees can not be enforced.

• Extending a process execution engine to support real-time: For a process engine to fully support the extensions, it has to have real-time capabilities, which are only supported through proper hardware / operating system integration. In this case no translation to plain BPMN can occur, but instead the extensions have to be supported through new primitives in the execution engine that implements the aforementioned hardware/operating system integration. This step (in contrast to the two previous steps) has not been realized yet, but is feasible for real-time linux and the several existing real-time windows flavors.

6 Expert Interviews

The introduction of BPMN modeling extensions for continuous processes, with a focus on processes from a specific field of engineering, requires an evaluation by experts from relevant fields. Findings gained from presenting the BPMN modeling extensions to potential users as well as people from relevant stakeholder groups provide the opportunity to build on the advantages as well as to address weaknesses in this phase of development. Three survey variants were compared in order to collect feedback and derive measures for further development steps, i.e., focus group discussions, Delphi techniques and expert interviews. Brown (2018) provides an overview of the advantages, disadvantages, and approaches to these methods and is used as a basis for selecting a methodological approach in this work. Focus group discussions offer advantages (that large amounts of data can be collected and critical issues can be addressed). Disadvantages, however, are that individual opinions can easily be lost and dominant participants may come to the fore. The Delphi method is suitable for exploratory research and allows re-assessment of opinions while being a comparatively time-consuming method as the interviews can extend over several rounds. Expert interviews offer the possibility to proceed flexibly and to easily regulate the course of the conversation and the time required, which can be long, with the help of an interview guide.

6.1 Expert Selection

As described by Gläser and Laudel (2009), experts in the context of expert interviews are selected based on their knowledge of a specific subject that sets them apart from other colleagues. In this case, the decisive criteria for the selection of experts are their professional background as well as their practical experience in the context of the subject area. In this work, the modeling of continuous processes is considered the subject area. The group of interviewees should be composed of people with detailed knowledge of continuous processes and knowledge in process modeling. Due to the objective, it is also taken into account that people from a purely industrial environment may have never used BPMN, and people dealing with the modeling of business processes have never come into contact with industrial continuous processes. In order to obtain a comprehensive picture of the current status of the BPMN modeling extensions and their current potential, three groups were formed for the selection of experts, defined as follows:

• Group 1 “Engineers” – Process Engineers/Control Engineers: Experts with background in process engineering, control engineering and automation technology are assigned to this group.

• Group 2 “Allrounders” – Process Modelers with experience in industrial processes: This group forms the link between the process industry and business process modeling. People in this group have already gained experience with modeling industrial processes using BPMN.

• Group 3 “Modelers” – Process Modelers without experience in industrial processes: This group includes individuals with experience in business process modeling in various fields, but lacking experience with industrial processes.

For the interviews 4 people per group were invited. The final set of twelve experts consists of national and international professionals from the industrial and research sector.

6.2 Interview Preparation and Conduction

The interview guide was constructed following the instructions described in Bogner et al. (2014). A more detailed description of how the guide was compiled can be found in Appendix B¹⁴ of the supplementary material to this work. It was compiled based on the research questions listed in the introduction of this work and is divided into three parts: in the first part of the interviews, the experts are asked about key features as well as graphical features for the representation of continuous processes. In the section dealing with the evaluation of the BPMN modeling extensions with regard to usability and comprehensibility, among other things, examples of process models are shown to the experts, which they are to evaluate according to the following criteria: Comprehensibility, clarity, simplicity, logic and extensibility. In the third part of the interview, the experts are asked about challenges, weaknesses, and opportunities for improvement in the BPMN modeling extensions. These three parts of the interviews are not sharply separated from each other. The questions on the individual sections are partly intermixed in the interview guide. The interviews were conducted using two versions of the interview guide. Additional material to this work such as the interview guides, transcripts, and more detailed description to individual sections in this work can be found in the supplementary material.¹⁵

6.3 Evaluation

For the analysis of the interviews, the auditory recordings were transcribed. During the course of the interview with “Engineer” 3, there was an interruption resulting in a part of the responses to questions Q6 through Q10.6 not being recorded. The corresponding data is therefore missing in the following evaluation and classified in the graphical representation under “N/A” with the meaning “not available”. The transcription is done according to a set of rules that can be found in the supplementary material to this paper. Transcripts were sent to the appropriate experts for approval.

Qualitative content analysis is used to evaluate the transcripts. Our approach is based on the instructions by Kuckartz (2014) and its execution is similar to the procedure depicted in Hopf et al. (1995), which is also described in Kuckartz’s overview. These steps include the initial review of the transcripts and thus an initial categorization based on the material, classification of text sections according to the formed categories, preparation of tables for the summary of results, graphical representation as well as a discussion of the individual interviews, of the three groups, and as an overall comparison. The reason for choosing this method of analysis is the heterogeneity of the available data. This heterogeneity is partly due to the differences in the two interview guide versions, in which questions are partly formulated differently and thus generate divergent answers. Also, some of the expert’s answers are incomplete caused by the course of the interview and some technical failures (missing answers from “Engineer” 3 due to a lack of audio recording for some sections). The basic procedure in this work for the content analysis follows the explanations of Mayring (2015) as well as additional selectively applied instructions of Kuckartz (2014).

Due to the partly open questions and the pre-formulated questions in the interview guide, we apply the inductive category formation which falls under summary (Mayring 2015). In addition to the categories which can be implicitly derived from the questions of the interview guide, inductive category formation allows us to address unpredictable statements and to evaluate the information in the context of the interviews.

6.3.1 Summarizing the Material

Due to the the amount of material (230 DIN A4 pages), the first steps of summarizing, i.e., paraphrasing, generalization and selection, are performed in one step according to the rules described by Mayring (2015) (Z1–Z3). Table 7 gives an overview of how the research questions for the interviews and a set of predefined conditions influence the definition of the main categories.

When assigning the categories, only passages that contain some form of feedback are considered. Comprehension questions by the experts, for example after an explanation by the interviewer, are not taken into account. However, if these passages contain a statement which expresses an opinion of the expert, they are relevant for this work. The level of abstraction for category formation depends on the particular research question. In case of questions with a point or rating scale, there is sometimes no numerical rating, which is why the answers to these questions were ascribed to the categories ’positive’, ’negative’, ’neither’ and ’not available’ for evaluation. Note that ’Not available’ generally marks missing input in order to better represent the quantitative correlations between the individual interviews. A detailed description of the category formation and application (Initial and final categorization, formulating the categories) on the transcripts can be found in Appendix F.¹⁶

Table 7 Definition of categories

6.4 Results

In this section, the results derived from the content analysis of the interviews (see methodology description in Sect. 6.3ff. above) are presented and discussed. In the following, the results are broken down into three parts as in the listing in Table 7, i.e., Part 1 presents general features of continuous processes with a focus on the graphical representation, Part 2 presents the evaluation of the comprehensibility and usability of the BPMN modeling extensions based on two process examples, and Part 3 presents the interpretation of the statements on challenges, weaknesses and recommendations for improvement of the BPMN modeling extensions. To give an overview of the knowledge gained, the results are shown in raw numbers in Table 8.

Table 8 Overview of found results in numbers

6.4.1 Part 1: General Features

Part 1 is intended to discuss general features important for description and graphical representation of continuous processes based on modeling requirements previously formulated with the experts. The requirements  (see Sect. 3) are transformed into features, using a feature-oriented mapping approach (see  Liu and Mei (2003)), in order to derive a simple interview guide that is understandable for all domain experts. The derived features are depicted in Fig. 10. As can be seen in Fig. 10, most of the features were rated positively and therefore can be considered as significant. The evaluation of feature ‘K5 – Importance of bringing system into consistent state’ stands out. Here, all respondents shared a similarly positive opinion. Temporal conditions were partly rated as a less important feature in the models. However, the definition of temporal conditions becomes important for the execution of process models.

Fig. 10

Features of continuous processes

The comprehensibility of the process models is partly assessed as situation-dependent, as experts pointed out that it depends on the users. In the supplementary material the results regarding the characteristics of continuous processes are depicted in the form of a bar chart in Appendix F.

6.4.2 Part 2: Comprehensibility and Usability

The results regarding comprehensibility and usability of the BPMN modeling extensions for continuous processes are listed in Table 8. The first column shows results regarding Process Model Example 1 in the interview guide while the second column shows the results referring to Process Model Example 2. The following topics of the process models were evaluated in detail, i.e., ‘comprehensibility’, ‘clarity’, ‘simplicity’, ‘logic’, ‘extensibility’ and the representation or description of the respective process example in form of a model. In Table 8 it is apparent that positive responses were predominant for the evaluation of Model 1. However, it should be noted that predominantly “Modelers” provided positive feedback. The two groups with a technical background tended to be more critical here. It was confirmed by all three groups that the model could still be extended.

Example 2 is a larger, more complex model, which is also reflected in the evaluation (see Table 8). For Model 2, the positive reviews decreased noticeably, while the ratings for the topics ‘comprehensibility’ and description of the real-world process were again predominantly positive.

Basically, the results indicate that the larger the model becomes, the more details need to be added in order to increase the information content. Negative feedback regarding the rapidly increasing complexity in the presentation of processes points to the need for improvements in the direction of clearer and more concise presentation. “Engineer” 4 pointed out that for a small control process a complete A4 page was needed here. It should also be emphasized that the topics ‘comprehensibility’ and the description of the real-world process were least affected by the increasing complexity of the model.

6.4.3 Part 3: Challenges, Weaknesses and Recommendations

Since a central goal of the interviews was to find out how experts evaluate the BPMN modeling extensions and how the BPMN modeling extensions can be further improved, Part 3 focuses on data from the interviews from which measures for further enhancements can be derived. Specifically, statements on the topics of ‘challenges’, ‘weaknesses’ and ‘recommendations for improvement’, are addressed here. Rating the recommendations by importance is difficult due to the open-ended nature of the question. A recommendation mentioned by only one expert can still add value to the presented BPMN modeling extensions. Another criterion for evaluating the statements was the distribution among the three groups. A statement gained significance if at least one person from each group was represented among the answers. In order not to completely exclude individual comments due to self-defined thresholds, they were treated in the context of named challenges, weaknesses as well as graphical and general features for continuous processes in the supplementary material of this work.

6.4.3.1 Part 3.1 – Challenges in Modeling Continuous Processes

The experts were asked to name challenges in the modeling of continuous processes that they have already encountered or that would occur to them. Table 9 provides an overview of the relevant challenges that were mentioned.

Challenge to keep models simple for users The most represented challenge was the ‘Challenge to keep models simple for users’ and was mentioned only by representatives from groups with modeling background. Although comprehensibility for users has been rated low among features for continuous processes (see Fig. 10), keeping the model simple for users is the challenge mentioned by the most experts.

Challenge to foresee every scenario for transition into consistent state/ exception handling The second most represented challenge has been the only challenge mentioned by at least one person of each group. This indicates that in each group there is an awareness of the complexity of the processes under consideration.

Challenge to integrate time constraints Although time constraints are a feature, that has been rated low by the experts, the integration of time constraints has also been identified as a challenge by an “Allrounder” and a “Modeler”.

Challenge to display WHY something happens, decision making In third place were the ‘Challenge to integrate time constraints’ and the ‘Challenge to display WHY something happens, decision making’. The integration of the BPMN modeling extensions should enable corresponding continuous processes to be mapped as completely as possible with the help of process models. In this respect, the aim is to map the handling of different scenarios as well as the decision-making process when selecting measures. The remaining statements were made by individual experts and are therefore not discussed in detail.

Table 9 Challenges in the representation of continuous processes and weaknesses and missing features of the extensions

6.4.3.2 Part 3.2 – Weaknesses of the BPMN modeling Extensions

During the interviews, questions were asked about weaknesses or missing elements. The relevant answers to these questions are summarized in Table 9. Note that, among the complete set of answers, “Engineers” were strongly represented here. Of a total of 21 points mentioned, this group is represented in 18 statements.

Nothing missing The most dominant statement on this topic, ‘Nothing missing’, was given by two “Allrounders” and three “Modelers”, indicating that the shown process models with the introduced extensions did not miss any relevant element.

Relations between measurements and controller not apparent Under this category, answers indicating that the relation between measure and control events in the process models were not visible, were combined. As control actions shall only follow the evaluation of the current state in form of state queries, control events are connected to one or more measure events.

Physical process behind model not apparent One outstanding statement was “Physical process behind model not apparent”, which came from one representative from each group. On the one hand, this is due to the selected notation. On the other hand, for the clarity of the physical process, the use of piping and instrumentation diagrams (P& ID) as well as control block diagrams is useful and well understood by experts, but do not per se show the physical process that takes place here. Both are standard methods in process and control engineering to describe processes. Therefore the question arises, whether it is necessary to visibly integrate the physical process in the model while working with standard BPMN and the BPMN modeling extensions.

Limits missing for controller The incomplete description of the modeled controller in the form of missing limits for the manipulated value was identified by two experts from different groups.

Long list of labels Two experts identified the long list of labels for the description of the tasks in the process graph as a weakness, although it provides further information on the process.

Not apparent in graphic parallel/sequential and wait/cancel As a specific weakness of the introduced extensions, the two variation options for the closed-loop sub-system gateway were not visible in the process model for two experts from different groups.

Tolerances ranges for measures are missing The tolerance ranges for the measure events, indicating whether the controller shall act or not, are missing for two “Modelers”.

Graphical properties of the process models and the BPMN modeling extensions are mentioned here on 4 occasions (relations between measurement controllers, long list labels, parallel/sequential and cancel/wait in model, difference cancel conditions). The main weaknesses include either missing information in the process models (e.g., missing limits and tolerance ranges for controller) or poor graphical representation (e.g., long list of labels or poor representation of parallel/sequential and wait/cancel).

6.4.3.3 Part 3.3 – Recommendations on Improvements:

In Fig. 11 recommendations for improving the BPMN modeling extensions coming from multiple experts are displayed. The most dominant statements were “More comprehensible if similar to common representation" and “Combine some elements together (Scripts, tasks)", with at least one person from each group represented in the second statement. The statements are described in greater detail in the column “Comment” in Table 10. Recommendations that were mentioned by only one person are discussed in the supplementary material in Appendix A.

General feedback on BPMN modeling extensions Individual statements made by the experts in the interviews can be seen as general feedback on the BPMN modeling extensions. Divided among the three expert groups, the statements can be summarized as follows: “Engineers” were critical of the new representation type for continuous processes, but one of the “Engineers” saw it as a helpful tool. “Engineer” 1 stated that BPMN and the BPMN modeling extensions were a beneficial form of design, because they could directly see without too much interpretative effort, what the process is all about. “Allrounders” and “Modelers” gave positive feedback.

Fig. 11

Recommendations from multiple experts

Table 10 Description of top recommendations

Group 2 sees this modeling method including the BPMN modeling extensions as valuable. Group 3 considered an extensive introduction to BPMN modeling extensions to be necessary but found the BPMN modeling extensions helpful. When the experts were asked if they would be willing to use this modeling method in their everyday work, 10 out of 12 gave a positive answer, with one answer missing. A more detailed description of the general feedback from the experts on the BPMN modeling extensions can be found in the supplementary material.

6.5 Discussion: Limitations and Threats to Validity

It should be emphasized that the obtained results give only a fraction of an insight into the opinions of the three defined groups of experts. Only 4 experts were interviewed for each group, with two experts each from the “Engineers” group also being asked different questions due to the two interview guide versions. In addition to the group size, influences originating from personal impressions and background of the experts must be taken into account. Effects such as the John Henry effect can influence the experts’ responses and bias the results (Saretsky 1972). The experts are aware that they were not the only ones to be interviewed in the context of this work. Furthermore, it can be assumed that due to the existence of standardized modeling methods in process engineering, the experts from the “Engineers” group responded with a more critical view. “Engineer” 2 stated that because it was a new presentation format, it was difficult to understand in a short amount of time what was depicted. Extensions of the existing standards may lead to an increased need for further training in this field, which can go hand in hand with increased effort and uncertainty in professional life. Another critical factor to consider here is the choice of specific process examples. While two thirds of the experts have at least moderate experience with industrial processes, the “Modelers” group is characterized by a lack of this knowledge and can therefore only provide limited feedback in this context. Generalizable results can only be expected if a larger number of experts is surveyed. Future evaluations with representatives of the described groups can be carried out with a larger number of participants but a smaller number of questions or topics in order not to strain the motivation of the participants and thus negatively influence the results.

7 Implications and Outlook

The overall goal of the research work is to investigate how the process industry, more precisely its continuous processes, can benefit from digital transformation in terms of process modeling using standard BPMN notation. The hypothesis is that process orientation in the process industry is promising understanding, verification, and automation of continuous processes as well as the required contextualization of data in order to apply analysis techniques such as process mining. To this end, BPMN extensions for modeling continuous processes have been proposed, together with their formal execution semantics, and an evaluation based on different examples from the process industry as well as expert interviews. In summary, the findings of the expert interviews are: the majority of the experts rates the extensions as valuable and helpful for process understanding. Engineers see a gap in their mental map between notations they are used to and BPMN. Allrounders with engineering and modeling background as well as modelers understand the BPMN extensions more seamlessly. The gist of the improvement recommendations is to keep the models as simple as possible by, e.g., using sub processes.

Additional findings with regard to the analysis of continuous processes which is facilitated by their process-aware modeling are outlined in the following. Continuous processes pose interesting analysis questions with respect to time. Each task in a continuous process is assigned a certain time slice for its execution, including the measurement to be taken. Exceeding the time slice is critical, i.e., the process execution will be immediately stopped. Process-aware modeling and execution enable an analysis of the behavior before the time slice was exceeded, i.e., which tasks were executed before. This supports root cause analysis for exceeding time slices and hence their explanation. Still it has to be investigated whether existing process mining and analysis techniques are already sufficient or if extensions/novel techniques are required. Using the proposed extensions, the cyclic processing of continuous sections of processes is explicitly modeled, and therefore, at least theoretically, it can be replicated in the form seen in industrial control systems. Based on this approach, entries for each cycle and any occurring events that trigger a deviation from continuity can be explicitly logged. This allows for a completely new approach to model checking, where the different states of a system can be traced. The existing combination of both domains, workflow modeling using BPMN, and model checking for control system design, is achieved through translation into Petri nets, thereby providing an additional level of verification. The different states or progressions of a process can be replicated in these process models, and based on pre-existing parameter profiles from real processes, impact analyses of the modeled measures can be conducted.

If the modeling approach proposed here, along with the described extensions or at least similar approaches, is adopted in the modeling of process engineering processes, this procedure could (i) help contextualize data based on implicit process knowledge (e.g., humidity is related to temperature), and (ii) as mentioned by a process engineer during an interview, provide support during the modeling process (e.g., Check completeness of data sources, frequency for sampling, verification of modeled actions based on data). As can be deduced from the interviews, although the findings cannot be applied to the entirety of the profession due to the number of process engineers interviewed, BPMN is still an unknown notation in this field. Users without a background in workflow management or without previous experience with BPMN will have to acquire initial basic knowledge. A mapping between known standards and BPMN can be supportive. However, data management and the scaling of temporal intervals remain a significant challenge in the planned use cases as described in this work. As mentioned in other works concerning the integration of AI for automatic decision-making processes, the collected data forming the basis for these analytical steps must be of appropriate quality. Therefore, further research needs to clarify the requirements for data collection and evaluation for the planned use cases. This can only be achieved with the assistance of domain experts. Future work will include the evaluation of the improvement actions based on the insights gained from the expert interviews. These actions will be implemented in the CPEE process engine. Moreover, we will investigate how to verify continuous process models, in particular with respect to potential conflicts between decision conditions. A proof of concept is planned by implementing a demonstrator for a continuous process on a laboratory scale.