Keywords

1 Introduction

Business Process Management (BPM) is nowadays a well-recognized discipline in academia and practice in order to define, improve, and manage business processes (BP). In the last decades, a plethora of BPM tools and systems, which enable process-oriented Human-to-Human, Human-to-System, and System–to–System interaction, has emerged  [1]. With the advent of the Internet of Things (IoT), where physical world objects are always connected to the Internet through ubiquitous smart devices, novel interactions during BP, e.g. Human-to-Thing or Thing–to–Thing, are possible  [2]. However, current BPM systems are not fully capable of integrating and utilizing smart devices as BP resources [3].

In light of this, the main contribution of this paper is a concept for a service-oriented IoT-aware BPM system architecture which enables to model, implement, and execute BP that use sensing and actuation capabilities of smart devices in smart building as well as smart home environments. Furthermore, we present a software prototype as a proof of concept. The paper is structured as follows: First, we briefly discuss some aspects on how both businesses and customers could benefit from BPM in conjunction with the IoT and touch upon related work (Sect. 2). We then present our concept on how to integrate and utilize smart devices as BP resources (Sect. 3). The corresponding software prototype is introduced in (Sect. 4). The paper concludes with a short summary and an outlook for future research (Sect. 5).

2 Motivation and Related Work

The total number of smart devices connected to the Internet is estimated to increase to around 24 billion (without smartphones and tablets) in 2020 [4]. This will lead to massive amounts of data which can be utilized by businesses to improve their BP [5]. For instance, high-frequently recorded sensor data from smart devices can serve as a basis for faster and improved decision making during BP execution, e.g. the early detection and handling of delivery problems in logistics networks through detailed package tracking. Furthermore, performance weaknesses and bottlenecks of BP can be identified resp. prevented, e.g. using predictive maintenance techniques in order to avoid cost–intensive unscheduled downtimes in production systems.

In the context of smart building and smart home environments, customers may benefit from new products and services in the areas of entertainment, convenience, security, health care, and energy efficiency [6]. Businesses, in turn, have the possibility to gather and analyze more detailed data about their customers in order to individualize and improve their products and services [2].

All of this requires that services, data, and events are appropriately orchestrated among businesses, smart devices, and customers. A task BPM systems seem to be well suited for [3]. However, there are many challenges current BPM systems are not fully addressing. For example, the heterogeneity of smart devices which includes different hardware specifications, communication protocols, data exchange formats, and discovery mechanisms [7]. As a first step towards holistic IoT-aware BPM systems, we found it fundamental to provide a system architecture which is able to integrate different smart devices as BP resources, hence, overcoming the heterogeneity issue.

Research in this field is still at its beginning. A literature survey conducted by [7] revealed that numerous publications focus on modeling IoT-aware BP without discussing technical details concerning the integration of smart devices. They also provide no further information on the implementation and execution of IoT-aware BP. Some solutions take into account implementation aspects; however, only concentrate on the integration of sensors or tags, which do not provide actuation capabilities. Other research work depends on the presence of gateway topologies or additional hardware required on the local network site which prevents 1:1 communication between, for instance, mobile devices and the BPM system. Furthermore, most solutions lack a monitoring component that provides transparency on BP execution. For this reason, we designed a BPM system architecture that enables the integration of smart devices for modeling, implementing, and executing IoT-aware BP.

3 Concept

In order to be able to use sensing and actuation capabilities of smart devices, we describe them at type and instance level. A device type (e.g. Temperature Sensor) represents a set of similar device instances. Device instances, in turn, are concrete occurrences of the respective device type (e.g. Temperature Sensor #1, Temperature Sensor #2, etc.). Each device type provides one or a set of service types (e.g. getTemperature) which may require to specify input, output, and configuration parameters (e.g. interval, unit). Device instances provide service instances (e.g. getTemperature from Temperature Sensor #1) whose parameters have concrete values (e.g. interval: 10, unit: seconds). Similar to smart devices, rules to identify events in data streams can also be described at type (e.g. value >22) and instance level (e.g. temperature value from Temperature Sensor #1 > 22 °C).

In the following, we introduce our first concept for a service-oriented BPM system architecture (see Fig. 1) that we derived from literature analysis, internal workshops, and software prototyping. It supports the modeling, implementation, and execution of IoT–aware BP and is based on a centralized orchestration model [7].

Fig. 1.
figure 1

UML component diagram of the IoT-aware BPM system

Full size image

A process designer component is provided for the graphical modeling of BP. The BP models are stored in the process repository (①). During BP modeling, only types of events, smart devices, and device services are available for use. This allows for the instance–independent composition and reuse of BP models at design time. Furthermore, it enables to deploy the same BP model multiple times for different smart devices. The process designer fetches device–related metadata (device and service types) from the device and service repository (②) which enables the unified access on heterogeneous devices by service abstraction. Event rule types, which represent event types and are defined by means of an event rule designer, are stored and retrieved from the event rule repository (③). This approach allows for event, device, and service types to be directly referenced by BP elements during modeling.

The process deployment component fetches executable BP models from the process repository (④) and examines if they contain event and/or device and service types. If this is true, the process deployment component retrieves eligible instances of all device and service types used in a BP model from the device and service repository (⑤). It then lets the user decide which specific device and service instances shall be utilized for a new BP deployment. The same applies to event types. The user defines which generic event rule types shall be applied on specific data streams of smart devices. Thereafter, the BP model is enriched with instance–related metadata and deployed to the process engine (⑥), which ensures that BP instances are executed according to the underlying model.

The BP service task execution is done by external task workers. They fetch pending jobs from the process engine and inform it as soon as the jobs have been completed so that it can proceed with the next BP step (⑦). External task workers invoke sensing and actuation services (e.g. getTemperature or turnOffLight) by using metadata of event, device, and service instances which is embedded in the deployed BP definitions. In case of executing an actuation service, an external task worker fetches the required service description from the device and service repository and sends a service request to the streaming platform (⑧). The streaming platform provides an interface by which platform connectors, that are responsible for handling the communication between the IoT–aware BPM system and edge devices, can fetch pending service requests and forward them to their counterpart in local networks, that is client connectors (⑨). Client connectors run on smart devices themselves or on gateway devices and represent one of the key components for overcoming the heterogeneity issue mentioned in Sect. 2. They are responsible for the registration and (auto-)discovery of smart devices and pass sensing data from local networks on to the IoT-aware BPM system. Furthermore, they forward requests to the service endpoints of smart devices. The platform connectors push incoming sensing data to the streaming platform where it can be filtered by events through the event processing engine. The event processing engine applies event rules on data streams and triggers events if corresponding rules are met. These events can be processed by the process engine, e.g. to start a new or to affect the control flow of a running BP instance. Finally, a process monitoring component accesses the interface of the process engine in order to obtain historical and operational data on BP instances (⑩). This includes, for example, the number of completed or running instances of a certain BP model, throughput times, or errors that might occur during BP execution.

4 Software Prototype

In order to provide a proof of concept of our architecture presented in Sect. 3, we implemented all system components (see Fig. 1) as an integrated cloud-based software prototype. This is part of an IoT platform that aims at the provisioning of tools which support the development of digital services in the area of home energy management.

The process designer component of our software prototype is based on bpmn.io, a BPMN 2.0 rendering toolkit and web modeler [8], which was extended to integrate with the device and service repository. We selected BPMN 2.0 as supported modeling language because it seems to be the best suited standard for mapping IoT concepts in BP [9]. Following [10], our solution intends that IoT-aware BP are modeled within BPMN pools. The lanes of a pool represent device types. Each service task that is placed on a lane is assigned to and handled by the respective device type. The user clicks on a service task and selects a supported service type from a dialog window. The label of the service task in question is automatically updated with the device-related metadata retrieved from the device and service repository to enhance the comprehensibility of the BP diagram.

In case of a new BP deployment, the process deployment component analyzes the BP definition and prompts the user to select concrete instances for every found event and/or device type. It then deploys the BP model to the process engine, which is based on the open-source platform Camunda [11]. This supports the external task pattern and, hence, provides more flexibility and scalability for executing BP service tasks [12]. The implementation of external task workers is independent from a specific programing language and additional source code for BP service task execution has not to be deployed to and executed by the process engine.

Most of the smart devices we use as BP resources for testing our approach support the wireless communication standards ZigBee or Z-Wave. Both are very popular and well suited for home energy management scenarios [13]. The smart devices are connected to local ZigBee or Z-Wave networks as well as to the Internet via gateway devices. We implemented lightweight client connectors and deployed them on the gateway devices. A software library, written in Python, is also available in order to integrate “things” which are not part of gateway topologies. Service requests from platform connectors, which address service endpoints of smart devices, are sent to client connectors over WebSocket connections. This allows the communication with local networks from the Internet without the need for cumbersome router configuration. With regard to the streaming platform, we use Apache Kafka and its publish-subscribe messaging system [14]. External task workers operate as producers and publish service requests to Kafka topics to which platform connectors are subscribed. The platform connectors are also producers and publish sensing data to topics which, in turn, can be subscribed by the event processing engine. This enables a high flexible and scalable handling of incoming resp. outgoing event and data streams.

5 Conclusion and Outlook

In this paper, we discussed potential use cases for BPM in conjunction with the IoT and outlined related work as well as the need for other research contributions. Furthermore, we presented a concept for a service-oriented BPM system architecture which supports the integration of smart devices as BP resources and introduced a first implementation as a proof of concept. In this context, we showed how we tackle the heterogeneity challenge by using connectors and metadata stored in the device and service repository for service abstraction in order to provide unified access to smart devices. Furthermore, system components which make use of these metadata and support the modeling, implementation, and execution of IoT-aware BP were described.

However, the results presented in this paper are work-in-progress and provide a basis for future research. The existing concept must be developed further towards a hybrid architecture which allows centralized as well as decentralized BP execution in order to tackle other challenges, such as privacy, security, and quality of service. In addition, tools and techniques for adaptive case management should be investigated in order to improve context awareness of process-oriented IoT applications. This will shift the utilization of BP from well–structured workflows to adaptive cases whose control flow is determined at run time based on context information.