Keywords

1 Introduction

In discrete manufacturing, processes get more complex and organizations strive to manage and orchestrate their operations. Activities on a factory shop floor should also be integrated with business functions for a seamless, end-to-end process management [1]. Business Process Management (BPM) is a paradigm that is often employed to help with process orchestration and improve cross-functional integration. While BPM has proven its strength in business sectors where information processing is dominant, e.g. finance [2], it has also been extensively applied in healthcare [3] and transportation [4], where physical entities are included as well. Without surprise, the application of BPM in manufacturing has increasingly gained attention [5], especially in the Industry 4.0 era, where many advanced robots and automated guided vehicles (AGV) have been introduced. That is because the need for orchestration of the activities of all the versatile actors is more imperative.

Modelling and supporting the execution of processes, is a core part in applying BPM concepts. BPMN, as the de-facto standard for business process modelling [6], is widely used for business processes [7]. Its interdisciplinary understandability [8, 9] and the expressiveness with respect to integration to execution [10], together with the need of integration of business processes and manufacturing operations [1, 11, 12], make it a promising candidate for use in the discrete manufacturing domain. Various extensions of BPMN for manufacturing processes have already been proposed [13, 14] and the comparison to other languages [15] shows the language’s strengths.

Despite its maturity and the recent interest of applying the notation in manufacturing, BPMN has inherent limitations. One of these is the fact that process models in BPMN are designed from a single, isolated process instance perspective, disregarding possible interactions among instances during execution [16, 17]. Often, process instances need to interact and collaborate based on information that is outside of the scope of one single instance. This collaboration is more important in manufacturing processes, where physical objects, and not only data information, are under consideration. Think of example of buffering points, where inventory is kept at an intermediate stage of a process, or the situation of bundling or batching products (multiple entities) for further processing as single entity (e.g. placing a number of items in a box for transporting). There should be hence, synchronization points where a process instance, representing the flow of activities of entities, waits or sends information regarding the state from or to other instances, commonly from different process definitions. BPMN provides basic synchronization with elements such as Signals or Messages. But the former is a broadcast message without any payload while the latter sends a payload message (with e.g. process instance identifiers or process definition keys) to only one instance. There is a lack of dynamic synchronization expressibility and functionality in the sense that the synchronization of the control flow of process instances cannot currently be decided based upon runtime state and content information of other process instances.

Buffering of entities and (un)bundling of entities and activities are constructs frequently encountered in the physical world of manufacturing processes. Using BPMN for manufacturing processes, entails explicit support for these constructs. Thus, we present in this paper an approach, called recipe system, to address the dynamic synchronization issue described in the previous paragraph. The approach uses standard BPMN 2.0 elements to form a dynamic controller that works as a correlation mechanism for synchronization points amongst independent process instances.

In Sect. 2 we discuss related work of the synchronization shortcoming of BPMN. In Sect. 3, we discuss the characteristics of the manufacturing concepts that we aim to support in terms of modeling and execution. In Sect. 4, the correlation mechanism is described and formalized. The implementation of the mechanism, its application and evaluation are discussed in Sect. 5. Finally, we conclude and reflect on the presented work in Sect. 6.

2 Background and Related Work

In the introduction, we briefly discussed the increasing interest of applying BPMN in manufacturing. More studies make it prominent [18,19,20,21,22]. The fact though that BPMN originates from the service industry, indicates that the notation cannot fully support concepts occurring in the physical, manufacturing world and consequently in the manufacturing sector. Various extensions have been proposed to capture the specific manufacturing characteristics, e.g. manufacturing activities, resource containers and material gateways [13], sensory event definitions, data sensor representations and specific smart manufacturing task types [23], sensing and actuating tasks [24], assets, properties and relationships among these entities [25].

However, all the aforementioned studies do not touch the synchronization problem that BPMN lacks to support. This shortcoming of the language has already been studied, but rather as a general problem, not targeting at the physical and manufacturing world. In general, we see two different paradigms; activity-centric ones (e.g. what BPMN follows) focusing on describing the ordering of activities, and artifact-centric ones focusing on describing the objects that are manipulated by activities [26,27,28,29,30]. From a BPMN perspective, artifact-centric modeling support is limited, though extension elements to support the artifact-centric paradigm have been defined [31]. Fahland et al. [32] approach the process synchronization from a dualistic point of view, both from the activity-centric and the artifact-centric paradigm perspectives. The study argues that processes are active elements that have agents, actors that execute activities. These actors drive the processes forward. Artifacts, on the other hands, are passive elements that are object to the activities. The activities are performed on these objects. While Petri nets are used as a means of process specification, Fahland argues that locality of transitions, which synchronize by “passing” tokens, are at the core of industrial process modeling languages, just like BPMN. Steinau et al. [33] also consider many-to-many process interactions in their study, proposing a relational process structure, realizing many-to-many relationship support in run-time and design-time. Earlier work on process interactions by van der Aalst et al. [34] (e.g. proclets), allowed for undesired behavior in many-to-many relations [35]. Pufahl et al. [36] put forward the notion of a “batch activity”, which is an activity that is batched over multiple process instances of the same process definition. The batch is activated upon the triggering of an activation rule. The concept is similar to the approach presented in this paper, but our study includes a strong focus on the correlation of process instances of different process definitions, that typically contain different activities. Finally, Marengo et al. [37] study the interplay of process instances and propose a formal language, inspired by Declare [38], for process modeling in the construction domain.

The importance of BPMN and the still ongoing research on the issue of multi-instance synchronization, is the motivation of our work on supporting frequent manufacturing patterns with this specific language. Our presented approach enriches BPMN and allows practitioners to use the notation for modeling and enactment of their manufacturing processes. In the next section, we first discuss the characteristics of the manufacturing constructs that this paper aims to support with BPMN, namely buffering, bundling and unbundling.

3 Characteristics and Limitations of Manufacturing Constructs

This section introduces the buffering, bundling and unbundling constructs. Due to their similar but inverse relationship, the bundling and unbundling constructs are jointly discussed. Limitations of BPMN to express them is also discussed.

3.1 Manufacturing Constructs Characteristics

Buffering

From an operations management perspective, buffering is considered as maintaining excess resources to cover variation or fluctuation in supply or demand [39]. The concept is also referred to as decoupling inventory between process steps, as these can be performed independently from each other [40]. Buffering, as an operations type of storage, is covered by the manufacturing operations taxonomy, under the Inventory operations category [41]. From [42], we can define buffering as “a form of (temporary) storage with the intention to synchronize flow material between work centers or production steps that may have unequal throughput”. From the five types of inventory from [43], we focus on the decoupling inventory/buffers in this study.

In the BPM field, van der Aalst [44] had already argued that places in Petri nets correlate to physical storage locations, in his effort to use high-level Petri nets to describe business processes. Thus, from a process management perspective the notion of a buffer can be explained as follows. An instance enters the buffer and is kept in a holding state. Once a condition is met (e.g. capacity becomes available in the downstream production step), one or more entities are released. The selection of which entity to be released can be based on multiple queuing policies, e.g. the First-In-First-Out (FIFO) policy. Once an entity is released, control flow continues as normal.

The above explanation though, considers the buffering from a single process instance perspective, leading to the process instance isolation issue we described in the previous sections. There is a need to approach the construct from a process control perspective, as such that buffer-level attributes and information from many process instances are captured and managed, as illustrated in Fig. 1.

Fig. 1.
figure 1

Buffering construct from both process control and process instance perspective.

Full size image

Bundling and Unbundling

Manufacturing operations literature recognizes operations that bundle, merge, unitize and package entities, as well as their inverse counterparts, but to the best of our knowledge no literature exists that describes how these entities are selected during operations. This is assumed to be described by the modelers in another part of the models or in different models. In this paper we define bundling as “the synchronization of instances that are grouped in some way, either physically or virtually, whose control flow shall continue or terminate simultaneously as a group”. Note this is a process-oriented definition and caution should be taken for generalization.

Examples of bundling are commonly encountered when physical entities need to be grouped into some sorts of a container. Imagine for instance products being produced and put in a packaging box. Once the capacity of the box is reached, the box can be transported as a single entity. Upon arrival of the box to a distribution center, entities are unbundled again. We use the term bundling, as a more generic term than batching, since the latter normally refers to putting together entities of the same type, while in bundling we can merge entities of different types. Bundling is often encountered together with buffering, as quite often, (sub-)entities are buffered before the bundling operation can take place, to ensure all (sub-)entities are present.

3.2 BPMN Limitations

A buffering point between two activities (or process fragments), as shown with the triangle element in Process Instance 1 in Fig. 1, could be naively modeled in BPMN 2.0 with the use of conditional or (intermediate) message catching events. These elements can offer the “holding” state of the control flow. However, none approach is suitable. Conditional events use local-instance variables, ignoring information of other process instances. Message events are targeted to a specific, pre-defined instance, missing dynamic correlation information.

Bundling and unbundling constructs can be probably modeled with AND-gateways. But these gateways (un)merge control flows that can be modelled on the same definition, which is not always possible. In many scenarios, different processes have to be correlated and gateways cannot perform this. Erasmus et al. [41] discuss also the use of multi-instance activities (among the other BPMN patterns proposed for modeling manufacturing processes) for unitizing, as they call it, entities. The spawning of repeated instances can serve (un)bundling functionality. However, the isolation problem appears here as well. Each child process instance is unaware of the information of the rest child instances.

4 Concept and Functionality of a Recipe System

In this section we first present the approach to overcome the synchronization issues. The approach is later formalized.

4.1 The Recipe Controller

Having provided the definitions of the constructs under consideration, along with their attributes, and discussed the BPMN limitations to support them (in Sect. 3), we present here the solution of a recipe control system. The work of Spijkers [45] discusses also a list of functional and non-functional requirements for designing such a system.

Recipe

The central notion of the system is the recipe. It corresponds to a synchronization (or integration) point, where (previously uncorrelated) control flows in independent process instances may be synchronized. It consists of a set of input rules and output rules. A recipe is fulfilled once all input rules are satisfied. We link two important concepts in a recipe. The instance type and the selector attribute. The first is used to group process instances of the same type in a pool. Think for example a car assembly process. It requires a number of wheels, a number of doors and a chassis. Each of these elements are produced independently according to their process models. Thus, we can have three pools, one with “CarWheel” instance type, one with “CarDoor” type and one with “CarChassis” type. The selector attribute is used for discriminating instances that are of the same type, yet of a different variant. For example, the “CarDoor” instance type can have the color (e.g. blue/red) as attribute. A pool is a virtual “container” to keep homogenous process instances; homogeneous from an instance type perspective, as these can have different attributes. All the concepts are illustrated in Fig. 2. Process instances are denoted as shape figures.

Fig. 2.
figure 2

Illustration of the recipe concepts with an example (Color figure online)

Full size image

The configuration of each pool plays a crucial role for the fulfillment of a recipe. The following options are considered:

  • Genericity. A pool can be either generic or specific. In the first case, the pool does not consider the selector attribute of the buffered process instances (e.g. in Pool \( {\mathcal{P}}_{1} \) of Fig. 2). In the latter case, recipe fulfillment candidates are nominated based on the selector attribute (e.g. on the color in pools \( {\mathcal{P}}_{2} \) and \( {\mathcal{P}}_{3} \) of Fig. 2).

  • Availability mask. Pools can represent physical buffers but as such should account for physical availability, i.e. how instances/objects are accessed. This paper considers three availability masks:

  • ALL: All instances are available (e.g. in a virtual or physical pool that we do not care about the physical layout).

  • FIRST: The instance that was first placed in the pool is considered as available. Subsequent instances are marked as available if and only if they share the selector attribute value of the first instance, in one sustained sequence.

  • LAST: The instance that was placed last in the pool is considered as available. Subsequent instances are marked as available if and only if they share the selector attribute value of the last instance, in one sustained sequence.

  • Release policy. The release policy ranks instances for recipe fulfillment (and thus “release” from the pool). This paper considers three policies:

  • FIFO: instances that have been in the pool the longest are released first.

  • LIFO: instances that have been in the pool the shortest are released first.

  • ATTR: instances are released based on a selector attribute value.

Fulfillment Cardinality.

The fulfillment cardinality determines how many instances of a pool are needed to lead to recipe fulfillment. It can be a single value, i.e. all instances are nominated for fulfillment or it can take a minimum \( (n) \) and a maximum \( (m) \) value, i.e. the pools needs at least \( n \) and less than \( m \).

With the configuration options described above, the recipe can be specified with the following notation, shown in Fig. 3 (same example as in Fig. 2). Upon a recipe fulfilment, a process may continue its flow after the respective synchronization points or a new process instance (mainly from a different process definition) can start.

Fig. 3.
figure 3

Specification of a recipe (proposed notation)

Full size image

4.2 Formalization

Recipes \( ({\mathcal{R}}) \) are treated as sequences that contain Pools \( ({\mathcal{P}}) \) that are treated as sequences that contain instances. The notation \( \left| {\mathcal{P}} \right| \) is used to denote the number of instances currently in pool \( {\mathcal{P}} \). The notation \( {\mathcal{P}}\left( i \right) \), with \( i \in \left\{ {1, \ldots ,\left| {\mathcal{P}} \right|} \right\} \), refers to the \( i \)-th instance in the pool. Not to be confused with the powerset notation \( {\mathcal{P}}\left( A \right) \), referring to the powerset of set \( A \). Note that this instance indexing is based on the time at which an instance was added to the pool. In other words, from a mathematical perspective, a pool is an array of instances that is sorted on arrival timestamp. In general, the symbol \( i \) is used to either denote an array index (like in the \( {\mathcal{P}}\left( i \right) \) notation) or a process instance, like \( i \in {\mathcal{P}} \). The latter should be read as instance \( i \) in pool \( {\mathcal{P}} \). The mathematical model, which extends the content presented in the previous section, uses the following symbols:

  • \( {\mathcal{R}} \) a recipe.

  • \( {\mathcal{P}} \) a pool. Is a member of a recipe, i.e. \( {\mathcal{P}} \in {\mathcal{R}} \).

  • \( {\mathcal{S}} \) the (abstract) set of possible selector attributes.

  • \( s_{{\mathcal{P}}} \) the selector attribute for pool \( {\mathcal{P}}. \)

  • \( {\mathcal{V}}_{s} \) the (abstract) set of possible selector attribute values for selector attribute \( s \in {\mathcal{S}} \).

  • \( v_{i} \) the selector attribute value for instance \( i \in {\mathcal{P}} \).

  • \( c_{{\mathcal{P}}}^{ - } \) the minimum fulfillment cardinality for pool \( {\mathcal{P}} \).

  • \( c_{{\mathcal{P}}}^{ + } \) the maximum fulfillment cardinality for pool \( {\mathcal{P}} \).

  • \( \alpha_{{\mathcal{P}}} \left( i \right) \) availability mask function for pool \( {\mathcal{P}} \). \( \alpha_{{\mathcal{P}}} \left( i \right) \in \left\{ {0,1} \right\}\left| {\forall i \in {\mathcal{P}}} \right. \).

  • \( \rho_{{\mathcal{P}}} \left( i \right) \) release policy ranking function for pool \( {\mathcal{P}} \). \( \rho_{{\mathcal{P}}} \left( i \right) \in \left\{ {1, \ldots ,\left| {\mathcal{P}} \right|} \right\}\left| {\forall i \in {\mathcal{P}}} \right. \).

  • \( g_{{\mathcal{P}}} \) boolean whether pool \( {\mathcal{P}} \) is generic (1) or specific (0). \( g_{{\mathcal{P}}} \in \left\{ {0,1} \right\} \).

  • \( {\mathcal{S}}\left( {\mathcal{P}} \right) \) the set of selector attribute values for which at least \( c_{{\overline{{\mathcal{P}}} }} \) instances exist in pool \( {\mathcal{P}} \).

Formally defined as

$$ \begin{array}{*{20}c} {{\mathcal{S}}\left( {\mathcal{P}} \right)} & { \equiv \left\{ {v \in \left\{ {v_{p} :\,p \in {\mathcal{P}}} \right\}:\left| {\left\{ {v_{p} :\,p \in {\mathcal{P}} \wedge v_{p} = v} \right\}} \right| \ge c_{{\overline{{\mathcal{P}}} }} } \right\}} \\ \end{array} $$
(1)

Note that, by definition, \( {\mathcal{S}}\left( {\mathcal{P}} \right) \subseteq {\mathcal{V}}_{{s_{{\mathcal{P}}} }} \) holds.

\( m\left( {\mathcal{P}} \right) \) a map that maps an attribute value to a sequence of fulfillment candidate instances (of the same attribute value) in pool \( {\mathcal{P}} \).

$$ \begin{array}{*{20}c} {m\left( {\mathcal{P}} \right) :\,v \to I } \\ \end{array} $$
(2)

with \( v \in {\mathcal{S}}\left( {\mathcal{P}} \right) \) and set of instances \( I \subseteq {\mathcal{P}} \).

Later in the discussion, Fig. 4 introduces an example of such a mapping.

Fig. 4.
figure 4

Map generation \( m\left( {\mathcal{P}} \right) \) example

Full size image

Availability Mask Functions

Availability masking uses a boolean mask to indicate whether an instance is available for recipe fulfillment. The mask \( \alpha_{{\mathcal{P}}} \left( i \right) \) equals to 1 if and only if the instance argument \( i \) is available for recipe fulfillment (otherwise 0). Consequently, an instance may only be nominated for a fulfillment if \( \alpha_{{\mathcal{P}}} \left( i \right) \) = 1 holds for instance \( i \in {\mathcal{P}} \). There are three flavors of availability masks. First, there is the ALL mask, which means that all instances are available. Alternatively, there is the FIRST mask, which marks the first element as available. Subsequent instances are available if and only if they share the selector attribute value of the first instance, in one sustained sequence (as is often the case in physical stacks only accessible from the stacking direction). Somewhat inversely, there is the LAST mask. As the name suggests, this mask marks the last element as available. Preceding instances are available if and only if they share the selector attribute of the last instance, in one sustained sequence. All three masks are defined with the following equations:

$$ \begin{array}{*{20}c} {\alpha_{{\mathcal{P}}}^{\text{ALL}} \left( {{\mathcal{P}}\left( i \right)} \right) \equiv 1,} & {} & {\forall i \in \left\{ {1, \ldots ,\left| {\mathcal{P}} \right|} \right\} } \\ \end{array} $$
(3)
$$ \begin{array}{*{20}c} {\alpha_{{\mathcal{P}}}^{\text{FIRST}} \left( {P\left( i \right)} \right) \equiv \left\{ {\begin{array}{*{20}c} 1 & {{\text{if }}i = 1 \vee \left( {v_{{{\mathcal{P}}\left( i \right)}} = v_{{{\mathcal{P}}\left( {i - 1} \right)}} = \ldots = v_{{{\mathcal{P}}\left( 1 \right)}} } \right)} \\ 0 & {\text{otherwise}} \\ \end{array} \quad \forall i \in \left\{ {1, \ldots ,\left| {\mathcal{P}} \right|} \right\}\left( 4 \right)} \right.} \\ \end{array} $$
$$ \begin{array}{*{20}c} {\alpha_{{\mathcal{P}}}^{\text{LAST}} \left( {P\left( i \right)} \right) \equiv \left\{ {\begin{array}{*{20}c} 1 & {{\text{if }}i = \left| {\mathcal{P}} \right| \vee \left( {v_{{{\mathcal{P}}\left( i \right)}} = v_{{{\mathcal{P}}\left( {i + 1} \right)}} = \ldots = v_{{{\mathcal{P}}\left( {\left| {\mathcal{P}} \right|} \right)}} } \right)} \\ 0 & {\text{otherwise}} \\ \end{array} \,\forall i \in \left\{ {1, \ldots ,\left| {\mathcal{P}} \right|} \right\}\left( 5 \right)} \right.} \\ \end{array} $$

Release Policy Functions

Release policies use a ranking function to prioritize instances for fulfillment. A lower rank means the instance is preferred. First off, there is the First-In-First-Out (FIFO) release policy, which orders instances based on the timestamp \( t \) at which they were added to the recipe pool.

$$ \begin{array}{*{20}c} {i_{1} \prec i_{2} } & { \Leftrightarrow t_{{i_{1} }} \le t_{{i_{2} }} ,} & {} & {\forall \left( {i_{1} ,i_{2} } \right) \in {\mathcal{P}} \times {\mathcal{P}} } \\ \end{array} $$
(6)

Instance \( i_{1} \) is preferred over \( i_{2} \) for release, if and only if the time added to the pool of \( i_{1} \), \( t_{{i_{1} }} \) is smaller than or equal to that of \( i_{2} \), \( t_{{i_{2} }} \). In other words: the instances are ranked such that their timestamps are non-decreasing. The ranking function, \( \rho_{{\mathcal{P}}}^{\text{FIFO}} \) is therefore defined simply as the instance index of the time-sorted sequence of instances in a pool:

$$ \begin{array}{*{20}c} {\rho_{{\mathcal{P}}}^{\text{FIFO}} \left( {{\mathcal{P}}\left( i \right)} \right)} & { \equiv i,} & {} & {\forall i \in \left\{ {1, \ldots ,\left| {\mathcal{P}} \right|} \right\} } \\ \end{array} $$
(7)

Secondly, there is the inverse of FIFO, Last-In-First-Out (LIFO), again based on timestamp \( t \).

$$ \begin{array}{*{20}c} {i_{1} \prec i_{2} } & { \Leftrightarrow t_{{i_{1} }} \ge t_{{i_{2} }} ,} & {} & {\forall \left( {i_{1} ,i_{2} } \right) \in {\mathcal{P}} \times {\mathcal{P}} } \\ \end{array} $$
(8)

Notice that Eq. (8) results in the reverse ranking of Eq. (6). The resulting ranking function, \( \rho_{{\mathcal{P}}}^{\text{LIFO}} \) is therefore the inverse ranking of Eq. (7):

$$ \begin{array}{*{20}c} {\rho_{{\mathcal{P}}}^{\text{LIFO}} \left( {{\mathcal{P}}\left( i \right)} \right)} & { \equiv 1 + \left| {\mathcal{P}} \right| - i,} & {} & {\forall i \in \left\{ {1, \ldots ,\left| {\mathcal{P}} \right|} \right\} } \\ \end{array} $$
(9)

Lastly, there is the attribute based policy (ATTR), which sorts instances based on some attribute, denoted by #. As an example instantiation of this policy, one could think of a priority based policy.

$$ \begin{array}{*{20}c} {i_{1} \prec i_{2} } & { \Leftrightarrow \#_{{i_{1} }} \ge \#_{{i_{2} }} ,} & {} & {\forall \left( {i_{1} ,i_{2} } \right) \in {\mathcal{P}} \times {\mathcal{P}} } \\ \end{array} $$
(10)

To define the ATTR release policy ranking function, we first define the sequence \( {\text{sort}}^{ \downarrow } \left( {A,\# } \right) \subseteq A \) to be the result of sorting sequence \( A \) on some attribute \( \# \) in descending order (i.e. the result is nonincreasing). Furthermore, we define \( {\text{index}}\left( {i,A} \right) \in \left\{ {1, \ldots ,\left| A \right|} \right\} \) to return the index at which element \( i \) occurs in sequence \( A \). Using these intermediate definitions, we can arrive at the final definition:

$$ \begin{array}{*{20}c} {\rho_{{\mathcal{P}}}^{\text{ATTR}} \left( {{\mathcal{P}}\left( i \right)} \right)} & { \equiv {\text{index}}\left( {{\mathcal{P}}\left( i \right),{\text{sort}}^{ \downarrow } \left( {\left\{ {{\mathcal{P}},\# } \right\}} \right)} \right),} & {} & {\forall i \in \left\{ {1, \ldots ,\left| {\mathcal{P}} \right|} \right\} } \\ \end{array} $$
(11)

where # refers to the priority attribute to be sorted.

Given the properties of these functions, the discussion above can be generalized to

$$ \begin{array}{*{20}c} {i_{1} \prec i_{2} } & { \Leftrightarrow \rho_{{\mathcal{P}}} \left( {i_{1} } \right) \le \rho_{{\mathcal{P}}} \left( {i_{2} } \right)} & {} & {\forall \left( {i_{1} ,i_{2} } \right) \in {\mathcal{P}} \times {\mathcal{P}} } \\ \end{array} $$
(12)

This generalized form is used in the subsequent implementation. The function definition denoted by \( \rho_{{\mathcal{P}}} \) is to be replaced with an appropriate release policy function variant.

Note that, since output rules are released instantaneously once a recipe is fulfilled, the effect of these release policies is only observable if there is a choice which instances should remain in the pool. This choice is only there if there are more instances in the pool than the maximum fulfillment cardinality, i.e. \( \left| {m\left( {v \in {\mathcal{S}}\left( {\mathcal{P}} \right)} \right)} \right| > c_{{\mathcal{P}}}^{ + } \). Otherwise, exactly \( { \hbox{min} }\left( {c_{{\mathcal{P}}}^{ + } ,\left| {\mathcal{P}} \right|} \right) \) instances are selected in the fulfillment and the ordering is irrelevant, as becomes apparent in the following algorithmic discussion.

The Pool Algorithm

As mentioned before, a pool can produce a mapping \( \begin{array}{*{20}c} {m :\,v \in S\left( P \right) \to I \subseteq P} \\ \end{array} \) upon request. This mapping maps an attribute value \( v \) to a sequence of fulfillment candidate instances \( I \). A visual example that explains how that mapping works, can be found in Fig. 4. In this figure, the “CarDoor” pool from Fig. 2 is used as an example.

The pool’s mapping algorithm is listed in Fig. 5.

Fig. 5.
figure 5

Pool’s mapping algorithm

Full size image

The Recipe Algorithm

The recipe algorithm collects and analyzes pool maps to determine fulfillment feasibility. If a fulfillment can be achieved for a particular selector attribute value, the algorithm releases the appropriate instances from the pools and returns them in a list. The algorithm is listed in Fig. 6.

Fig. 6.
figure 6

Recipe’s fulfillment algorithm

Full size image

5 Prototype Implementation, Demonstration and Evaluation

This section discusses the technical implementation of the proposed synchronization approach, as it was prototyped, demonstrated and evaluated in a real use case.

5.1 Technical Implementation

The aforementioned mathematical model and algorithms are implemented in a digital artifact using the Java programming language. The classes of the model are also represented by a technical data model. The Java code interacts with the process engine of a BPM System that executes the process models. The code is embedded in a typical process model definition, which offers the functionality of the recipe controller. The high-level internal implementation of the controller in BPMN 2.0 is shown in the bottom part of Fig. 7. It receives Submit (or Cancel) messages from specific synchronization points from the main process definitions (e.g. after Production task A1 of Production Process A and at the end of Production Process B), evaluates the recipes based on the messages’ content and releases (via Release messages) the continuation of control flow once recipes are fulfilled.

Fig. 7.
figure 7

The recipe controller (BPMN 2.0 process model)

Full size image

5.2 Demonstration and Evaluation

The implemented recipe system was demonstrated in a real-world use case in the manufacturing printing domain, within the European EIT OEDIPUSFootnote 1 project. The scenario consisted of several printers, binding and trimming machines, and a robotic arm mounted on an AGV to grasp and transport paper and books between the devices and storage places. Activities performed by all these agents were modelled and enacted by a BPMS. Various synchronization points existed in the scenario, mapping to the buffering and un(bundling) constructs described in this paper. Recipes, using the notation of Fig. 3, were described and configured for supporting these points. The points were modeled in the process models as well. One such point was the output tray of a printer. There, sequentially produced books were placed and were ready for transportation to a binder. The corresponding recipe took care to synchronize the activities for bundling (and unbundling) of the books from the tray, onto the AGV, and then into the binder. For the sake of brevity, the complete process models are not presented here. Figure 8 shows a simpler example of independent process models interacting with the Recipe controller.

Fig. 8.
figure 8

Interaction of recipe controller with manufacturing processes

Full size image

The recipe controller system was primarily evaluated on its functionality to support the modeling in BPMN 2.0 of physical manufacturing constructs (i.e., buffering and (un)bundling). It was also evaluated in terms of usability by asking practitioners, through a structured survey, to define recipes and model synchronization points. In general, they find the approach useful.

6 Conclusion

This paper presents a solution for realizing dynamic process synchronization and correlation through a structured use of BPMN messages, with the goal to support manufacturing constructs, more specifically, buffering, bundling and unbundling. The solution is a novel approach to address the general dynamic synchronization issue, stemming from the process instance isolation, that the language fails to support. The recipe system that we propose is formally described, implemented and demonstrated in a real-world case study at a large, international firm in the printing industry. While this work does not claim complete suitability of the solution to all cases, the demonstration of the solution proves its feasibility. The usability was also evaluated by practitioners, engineers and researchers that modeled processes with the recipe system approach, who perceived it as useful.

However, there are limitations in the current work that are opportunities for further research. Assumptions in the definition of the models, such as that pools have infinite capacity or their cardinality is only expressed in units of process instances, may need to be relaxed. Workaround solutions exist, such as using an external knapsack problem solving engine, which passes group information to the recipe system in the form of selector attribute values, so that the recipe system can perform the appropriate bundling operations. Similarly, the assumption that a selector attribute is shared across all pools should be addressed by giving unique object identifiers to each pool. Furthermore, to make the system more dynamic and flexible, the recipes should be (re)configured during runtime and the fulfillment conditions should be variable instead of static. Not forget to mention that new BPMN elements can be crafted as extension to the notation for representing buffer and synchronization points.