1 Introduction and Background

Modern production information systems are generally computerized and are designed to collect and present the data which operators need in order to plan operations within the production [1]. The connection between production and information technology leads to an ubiquity of digitally supported information processing systems. This way, all participating production objects are able to communicate based on a digital, potentially mobile infrastructure. Such a production system represents a typical Internet of Things (IoT) system where electronic hardware, e.g., sensors and actuators are tightly integrated with human operators. One way of integrating human users into a cyber-physical system seamlessly is to equip them with Wearable Computing Systems (Wearables) like smartwatches [2]. These mobile devices support users in their operative tasks by directly proving them with most recent information about the production process.

A business process is a collection of activities and decisions that involves a number of (human) resources. To support processes at an operational level, a BPM system (BPMS) can be used. A BPMS deals, a.o., with the enactment of models that define the interplay between environmental circumstances and activities to be executed. With the emergence of IoT, data is generated from physical devices sensing their manufacturing environment that reflects certain aspects of processes. Accordingly, sensing and perception the process environment via sensors constitutes the fundamental task of the IoT. Sensor data then must be aggregated, interpreted and made available to the BPMS in order to trigger activities. The resulting user tasks of the triggered activities must then be send in real time to responsible individuals that receive tasks on mobile user interfaces.

Consider a production process where material is processed by machines under the supervision of human operators. In case of product quality issues, human involvements are necessary. Operators must be aware of sensor data to decide on tasks to be executed next. Such a scenario might be better manageable when linking digital production data with human operators as enabled by the integration of IoT and BPM. The necessity of human activities can be triggered by a BPMS through the reference of IoT sensor data in the underlying process model [3]. This way, operators can be notified seamlessly without any loss of time on wearable devices while leveraging current context specific information. As a consequence, the integration of IoT and BPM technology could lead to efficiency gains by reducing reaction time and enhance the quality of task execution. For this purpose, we introduce a toolset for an IoT-aware process execution system that exploits IoT for BPM by providing IoT data in a process-aware way, considering IoT data for interaction in a pre-defined process model, and providing wearable user interfaces with context specific IoT data provision. The prototypical implementation has been evaluated extensively in production industry.

This paper is structured as follows: Sect. 2 describes the requirements and preliminaries for an IoT-aware process execution. In Sect. 3 we describe the prototypical implementation of our approach based on well-known communcation protocols. In Sect. 4 we describe the application of the tool in production industry. Section 5 gives an overview of related work and Sect. 6 concludes the paper and gives an outline on the tool demonstration.

2 Requirements for an IoT-Aware BPMS

In this section, we describe fundamental requirements preliminaries and that we considered in our tool. The first step is connecting IoT objects and their latest values to a BPMS. In the second step, process models need to be extended with data variables participating in the process stemming from IoT objects such as machine status or actor positions. The resulting process models must be applicable by default contemporary execution engines. This way, organizations can reuse existing process models, without having to learn new languages and remodel processes from scratch. The third step is to establish a real time notification interface of triggered activities to process participants by means of mobile devices. In the fourth step, context relevant information stemming from connected objects must be selected and provisioned to users.

Fig. 1.
figure 1

IoT data acquisition, visualisation and analysis

Full size image

We assume that a process model is defined as BPMN conform process diagram, one of the most used formalisms for process modeling, representing the IoT aware process to be executed. A BPMN process diagram specifies which activities are executed in a process as well as their control flow relationships. However, to be able to infer when activities start or end based on the state of IoT sensor values, the diagram must capture this information. Therefore, this step requires the process designer to enrich the given BPMN diagram by including information on how and where the connected IoT sensor data influences the process.

It is important that operators are seamlessly notified when human interaction is required, independent of where the user is located. This requires a real time notification on mobile devices of responsible users. Therefore, it is necessary to define a mapping of users to corresponding mobile devices that serve as wearable, user-specific process cockpits and task lists, respectively. This is achieved by specifying a dedicated mobile device identifier for each defined user in the BPMS. During process execution, the currently available tasks for a specific process participant are then directly sent to the specified mobile device. The actual operator to device mapping and the task distribution is described in detail in Sect. 3. Alongside with activities, context-specific and process relevant information must be provisioned to operators to improve the quality of task execution.

3 Toolset Architecture and Implementation

The IoT-aware BPMS is implemented as a three layer architecture that is visualised in Fig. 3. It consists of the following layers: (i) IoT objects, i.e., sensors as well as wearable devices; (ii) IoT infrastructure and communication middleware; and (iii) the BPMS. The layers are connected based on standard communication protocols. To allow IoT objects at layer (i) to communicate with the IoT middleware at layer (ii) and the BPMS, a Message Queue Telemetry Transport (MQTT)Footnote 1 Broker is used. MQTT is a publish/subscribe protocol, which is especially suited for applications where computing power and bandwidth are constrained. The used MQTT topics are listed in Table 1. IoT objects, i.e., sensors or actuators, represent publishers. They are connected to an IoT gateway using specific architectures such as Profibus, LAN, WLAN or Bluetooth. A specific IoT variable \(v_x\) is acquired and published on a MQTT topic /\(v_x\)/data.

Fig. 2.
figure 2

IoT data distribution to BPMS and specific processes

Full size image

Through a MQTT Broker the acquired data is sent to an acquisition application at layer (ii) that stores IoT data into a high performant NoSQL database. We used the latest version of the Apache Cassandra database. Figure 1 shows the interface of the C# based IoT data analysis desktop application where different IoT sensors can be configured. The application supports the acquisition of data stemming from PLC devices as well as from devices that communicate via MQTT. The acquired data can be visualised, accumulated and analysed. Within this application, a distribution module keeps the BPMS updated with the latest IoT values. The configuration interface is shown in Fig. 2. Here, the user can select the process definitions where a certain IoT sensor variable should be send to. All running instances of the selected processes receive the corresponding data value. The application cyclically acquires the values from the database in a Key-value structure and sends them to the BPMS. In our architecture we used the latest version of the Camunda BPMS and therefore communicated with the workflow engine by means of the Camunda Rest APIFootnote 2, i.e., PUT, POST and GET HTTP requests as described in Fig. 3. The tools at layer (ii) ensure that process relevant information stemming from the IoT is up-to-date. Through the acquistion tool, IoT data meta information is provided that makes clear where the data stems from. Given the current IoT data values, the engine calculates available activities. As a mobile user interface we implemented an Android based smartwatch application that subscribes to specific MQTT topics. The distribution application cyclically requests the current user tasks from the Camunda API for each defined user and publishes to the correct MQTT topic, given the mobile device identifier, i.e., smartwatch device, configured on the BPMS. The process of the device recognizing its configuration is implemented as follows: the distribution application cyclically checks the user configuration in the BPMS. When a change is detected, it publishes the new configuration to the topic /{\(actor\_id\)}. The smartwatch of a certain actor subscribes to the topic of its specific device identifier. Having established such connections, the smartwatch communicates with the MQTT broker by subscribing to the following topics: the current tasks for a specific operator are published on the topic /{\(actor\_id\)}/tasks. The device sends operators commands, such as complete task to the topic /{\(actor\_id\)}/command. The content of the message is forwarded straight to the BPMS using a POST request. Context-specific IoT data is sent to actors on topic /{\(actor\_id\)}/{\(variable\_id\)}. To prevent the MQTT service at the watch to be killed, we implemented a keep alive communication (topic = /keepalive).

Table 1. MQTT communication between IoT objects and BPMS
Full size table
Fig. 3.
figure 3

Integrated communication architecture for IoT and BPMS

Full size image

4 Industrial Use Cases and Prototypical Applications

We applied and evaluated the approach and toolset by means of two exemplary applications in production industry. At first we applied the prototype in the field of corrugation industry, where paper is glued to corrugated paper that depicts the basis for cardboard boxes. Due to increasing automation and staff reduction, less operators are available to control a production line. Interactions between users and machinery requires several location changes of users between control panels that result in delayed information flows. These delayed reaction times are frequently the reason for increased deficient products. To directly notify operators when human actions are needed, plant personal has been equipped with smartwatches as shown in Fig. 4. Furthermore, a user-group model has been defined in the BPMS. Here, available operators were assigned to a specific area of production that depicts their area of responsibility. Thus, depending on the area operators are working, the BPMS assigns a different set of tasks. Operators are then pointed to new human tasks through visual, acustic and, in case of noisy environments through haptic signals like vibration alarms. Furthermore, operators are used more effective because low priority work is aborted in order to perform high priority work that could lead to machine stops. In addition to currently available human tasks the IoT infrastructure provides diverse context-specific information on the smartwatch interface of operators. Depending on the specific group a user is assigned to, the wearable device offers diverse context information to operators: at the Dry-End (the area where produced corrugated paper leaves the plant), e.g., the remaining time of current production job, the remaining time to next stack transport, or the current production speed. Users at the Wet-End (the area where original paper is inducted to the plant) receive continuously information w.r.t. the next necessary roll change or occurring error and defects of machinery modules. In addition, operators receive error messages and environmental information from the different plant modules. This way, concrete and goal-oriented information in error cases or warning messages for supply shortfalls can be transmitted to operators and enhance the over all process transparency and thus the quality of task execution. Through the described implementation it was possible to significantly reduce reaction time intervals. The amount of deficient products was decreased and the overall quality of the produced corrugated paper has been improved. The overall equipment downtime was significantly decreased, since problems have been prohibited or recognized in advance and were solved proactively. Hence, the overall equipment efficiency could be increased effectively.

Fig. 4.
figure 4

Wearables: (a) unclaim/complete task; (b) tasks; (c) info; (d) processes

Full size image

In a second scenario, we modelled and executed a typical warehouse process that has been enhanced with IoT technology. Here, a transportation robot is called to a certain position in the warehouse by starting a specific process from the smartwatch as shown in Fig. 4d. Having started the process, a BPMN ServiceTask is called that sends a HTTP request to the wireless connected robot. The requests header contains the position of the watch that initiated the process.

5 Related Work

Several approaches have been proposed to relate IoT objects with business processes. [4] presents the Internet-of-Things-Aware Process Modeling Method (IAPMM) that covers requirements analysis. It extends the BPMN meta-model to model IoT-aware processes. The approach in [5] (BPMN4CPS) also describes an extension of BPMN in which the process logic is split into the cyber part, the controller and the physical part. Furthermore the authors extended BPMN by new task types. Some more notation concepts in BPMN for IoT are described in [6, 7]. The main focus is on the modeling of real world properties. None of the described approaches provides details on how to execute these models. In [8] an approach for implementing an IoT-aware execution system given in WS-Business Process Execution Language (WS-BPEL) is introduced. It extends BPEL by context variables which are automatically updated. The authors implemented a prototype which is compliant with every WS-BPEL engine. Other approaches implementing BPEL extensions are presented in [9]. The variables are updated using the publish/subscribe paradigm. Another extension for WS-BPEL (Context4BPEL) with features to manage context events to allow the asynchronous reception of events, query context data and evaluate transition conditions based on context data is described in [10]. In [11] the authors integrate distributed resources into WS-BPEL by formalizing a fragment of WS-BPEL together with the WSRF (Web Services Resource Framework). In [12] the authors propose an approach for enabling IoT-based agile business processes. They provided concepts for extending models by triggers for variance. The approaches in [13, 14] rely on the information coming from artifacts involved in the process to understand how a process evolves. By adopting an extension of Guard-Stage-Milestone (GSM), it is possible to monitor the process even when the control flow is not respected. The work presented in [15] introduces a process engine for enabling mobile applications. However, this work does not comprise IoT related aspects.

6 Conclusion and Tool Demonstration Outline

In this paper, we described a toolset for IoT-aware process execution. The prototype has been implemented as a three layer architecture, i.e., IoT objects, data acquisition middleware and BPMS. The layers are connected based on the protocols MQTT and HTTP. The process cockpit has been implemented by means of wearable user interfaces with configurable context specific IoT data provision. The tool demonstration will show the acquistion of life data from IoT sensors and the distribution to several running processes on a Camunda BPMS. Based on IoT based conditional events, human tasks will be triggered and sent to smartwatches of users that can subsequently claim and execute activities.