1 Introduction

It is estimated that in 2020 around 20 billion devices will be connected to the internet, forming the Internet-of-Things (IoT). Traditionally, networks connected computers with each others and facilitated the exchange of data among distributed nodes. With the advent of the IoT many heterogeneous devices joined these networks that were not computers in the traditional sense: GPS sensors built into cars, smart meters, fitness tracking wristbands, smart fridges, NFC readers, and many more. These devices provided capabilities that computers did not offer: sensing the world around them and acting towards the world. These connected devices facilitated business scenarios that were not possible before, like tracking of containers with GPS sensors, remotely controlling the heating at home, or coordinating thousands of devices in a smart factory. Most of these scenarios center around collecting data employing distributed sensors, exchanging, processing and visualizing this data, as well as acting on it.

In several implemented IoT scenarios concepts from the domain of Business Process Management (BPM) have been successfully used [1]. However, not all IoT scenarios benefit equally from BPM concepts. The single app-controlled Phillips Hue lampFootnote 1 will not profit from BPM concepts, while a scenario that schedules maintenance appointments for a fleet of cars might. The diversity of existing scenarios poses a problem, when trying to decide whether to apply BPM concepts for a projected IoT application [2]. To answer that, we need to understand the IoT world better, with several features it might offer. Unfortunately, a classification of IoT scenarios with regard to supporting them with BPM concepts has not been undertaken so far.

Looking at the other direction – supporting business processes with IoT – one obvious scenario is to use the events produced by sensors to drive execution of processes, e.g. by starting a new case, adding case data, or making routing decisions [3]. The process model can be considered “IoT-enabled” and is enhanced by the events. In this case, the process model just needs to know the expected events, which “abstract” from the devices, while the devices themselves are transparent. The situation changes, when actuators are added to the mix, which need to be triggered by the case. Here, it is important to find a good abstraction layer, instead of communicating with multiple, heterogeneous devices directly. The possibilities as well as the challenges of integrating complex event processing and BPM are discussed extensively in [4].

In this contribution we describe a variety of implemented or projected IoT scenarios and analyze them for commonalities and differences in Sect. 2. From this description we derive criteria, e.g. number and type of involved devices or locus of control, that enable a classification of IoT scenarios. The classification framework with these criteria is presented in Sect. 3. Next, in Sect. 4, we look at how various BPM concepts [5] can help to realize them. In addition, we consider flexible process execution as provided by the fragment-based case management approach Chimera [6] as a mean to support the realization of IoT applications. Finally, we conclude in Sect. 5.

2 Evolution of IoT

Internet of things started gaining popularity during 1980s. During the last two decades, many more applications based on IoT are coming into the play. However, even if the term was coined later in 1999 [7], the concept of interconnected objects has been introduced much earlier. This section gives a brief history of IoT and also sketches the future trends of IoT with the help of example applications.

2.1 The Beginning of the IoT

A good way to get an overview of the possibilities of the IoT is to have a look at various scenarios and how these evolved over time. Therefore, this section covers the beginnings of connected devices and their more recent developments in different domains. While the possibility to access funds almost everywhere is taken for granted today, the first ATMs were based on static tokens, which could be exchanged for cash [8]. In 1972, IBM developed a platform [9] that allowed cash machines to work as connected devices enabling the current system of accessing customer’s bank account via machines. Therefore, ATMs can be considered as the earliest IoT devices [10]. The concept of ‘product as a service’ proposes a shift to usage based payment instead of ownership of products [11], although the concept existed before sensors could transmit operational data to the manufacturer in real-time. Examples include turbines as a serviceFootnote 2, product based car sharingFootnote 3 and bike sharingFootnote 4. The introduction of connectivity in these services enabled much more convenient versions afterwards, e.g. by tracking the location via phone.

2.2 Towards Smarter Solutions – the Status Quo of the IoT

While phone-based mobile paymentFootnote 5 platforms are a much more recent development than the credit card, their functionality still closely resembles their ancestors. However, information about the account balance or past transactions is additionally available through the smartphone apps. The smart car cockpitFootnote 6 takes this a step further: instead of numerous analogue dials and gauges, there is only one display for all relevant information from various systems. As part of the sharing economy, platform based car sharingFootnote 7 uses the existing smartphones of its users for data collection (e.g. location) and interaction (e.g. find a car). Unlike product based car sharing, where the operator owns the vehicles, all kinds of cars can be seamlessly integrated with the platform service. Therefore, supply and demand for mobility can be matched in a novel way. A recurring theme among IoT applications is the so-called smart home, where previously unconnected devices are equipped with additional remote monitoring and control capabilities. Examples include the smart fridgeFootnote 8, smart ovenFootnote 9, or the smart thermostatFootnote 10, where one can check and set the temperature from anywhere. Instead of monitoring the internal operations of one device, other scenarios rather follow a tangible asset. This ranges from tracking individual parts in intelligent automotive manufacturingFootnote 11 over the completed product to arbitrary valuable objects in luxury freight trackingFootnote 12. On the other hand, it can also be desirable to use a smart parking meterFootnote 13 to find and manage a spot for the car.

In agriculture domain, some plants require a narrow range of conditions for optimal growth. However, it is not feasible for farmers to constantly check their fields in person. Hence, it makes sense to automate the monitoring of environmental conditions for cropsFootnote 14 by leveraging sensors to collect real-time information about weather conditions. By setting a threshold value for changes in temperature and humidity, farmers receive notifications via an app so that they can react quickly to ensure the well-being of their crops. When using more than one sensor, it is possible to correlate multiple input streams to infer more accurate predictions – e.g. while a single high temperature might be an outlier, rising temperatures across the field indicate a high probability of reaching the threshold value. By recognizing this, the farmer can be notified beforehand so he can proactively protect his plants.

In healthcare, medical professionals as well as personal fitness enthusiasts leverage small wearable devices (e.g. watches, bracelets) to constantly monitor vital information (e.g. hearth rate). For example, tele-ECGFootnote 15 for heart patients sends the current status to the doctor regularly to prevent accidents and for immediate medical support on demand. For medical professionals as well as personal fitness enthusiasts, real-time fitness trackingFootnote 16 gained popularity. In a physicians practice, the use of medical devices as a serviceFootnote 17 allows doctors to avoid high upfront payments and the logistics associated with an external laboratory. Instead, they can perform the analysis of samples directly in office. Combined with constant remote monitoring of the machines by the manufacturer, this provides sufficient data to create good estimates of downtimes. Consequently, repairs can be scheduled before problems occur. The same principle applies to smart gridFootnote 18 where utility providers can run a hosted grid, while their supplier can monitor the usage of all participants to support maintenance and product development.

2.3 Living in a Connected World – the Future IoT

Looking at predictions and products currently in development, it can be said that in spite of having several technical and social challenges, in near future, connectivity will become truly ubiquitous [12]. The start-up MyriotaFootnote 19 creates robust micro units to track the position and motion of assets, which are not covered by traditional means of communication. While not operating in real time, the system uses “Low Earth Orbit Satellites” to gather data from many devices at once every 90 min, thus enabling the monitoring of previously unavailable assets.

The EU project ecallFootnote 20 leverages the information from many cars on the road to find new opportunities to improve security and efficiency of traffic in cities, as well as to enable the adaptive redirection of drivers when a congestion threshold is met. Taking effect in 2018, ecall is concerned with the combination of emergency detection in cars with an automated notification of response personal. If the car’s sensors indicate a crash, the ecall device will establish a connection to an emergency hotline – depending on the situation of the driver, a voice call can clarify the situation. In all cases, the last available information from the car’s sensors is transmitted via a cellular data connection in order to enable an appropriate response. Another big application of IoT is the extended smart factory concept, namely the strategic initiative Industry 4.0 [13] where German Government promotes the digital structural change in industrial manufacturing and offers a framework to realize it.

3 IoT Classification Framework

In Sect. 2, several IoT scenarios have been introduced. Definitely, many other scenarios are already implemented or will be materialized in future. The classification framework is based on an analysis of the presented scenarios. It revealed the specific features shared by the IoT scenarios which are needed to be considered to understand the scenarios better, or one step ahead, to implement a scenario. In this section, the framework containing the features for classifying the IoT scenarios is presented.

Participants. The first aspect to be considered is to explore the participants in a particular scenario. This includes the number of components present as well as the type of components. In most of the cases, an IoT scenario includes a subset of the following type of participants:

  • Sensor: The thing or device that detects the change in the environment and sends the information to other thing(s) or a processor.

  • Actuator: The thing or device that receives information from a processor or other thing(s) and reacts on that to manipulate the environment.

  • Display: The device responsible for visualizing relevant information about the scenario such as the interactions among the things, change of status in the environment, failure of a thing and so on.

  • Controller: A central processor that sends and receives data and processes the information to control the next operations. It can be a central computer or a platform where the logic for interactions reside.

  • Complex Device: A device which can perform certain combination of the above functionality. For example, a smartphone can act as a sensor, an actuator, a display, and a controller at the same time.

  • Web Service: The services provided by the web applications which can be outsourced by the controller for processing data, if needed.

  • Human Beings: The human resources responsible for operating the controller and the end users receiving the benefit of the internet of things.

The scope of IoT applications ranges from single devices to complex systems spanning across continents and this influences the dynamics of executing interactions among them. Table 1 shows different scaling possibilities.

Table 1. Levels of participation in an IoT scenario
Full size table

Control. The control logic for the interaction among the devices can be placed as per the need of the scenario. It can be distributed in the following ways:

  • Central: A central controller takes the decision. The devices execute instructions from a remote location. For example, a sensor in crop monitoring field only measures the temperature and sends it to the processor.

  • On Device: A local program directs the operations of the device. Note that this does not restrict external communication, it only means that decisions are made locally. An example can be a smart car.

  • Distributed: Though the controller is in charge, the devices have minimal logic to perform certain tasks by themselves. A smart fridge can serve as an example; it is part of a smart home, but can itself control the temperature inside the refrigerator.

Interaction. The interaction among the participants of an IoT scenario can be of the following types. Note that the interfaces of the display, web service or UI are not discussed, since they follow the same technicalities as a non-IoT setup.

  • Things to Things: Things (sensors/actuators) in one net talk to each other.

  • Things to Controller: The sensors send data to the controller and the controller sends instruction to the actuators. Often a gateway is used for such communication which is an entry point for the cumulative data gathered from sensors. Generally the protocol used to transfer information from the things to the gateway is different than the protocol used to communicate with the controller.

Data. Every IoT application is based on the data from the participating IoT devices. We distinguish between different types of data that can be communicated from the IoT device to the controller: (1) identifier, (2) location, and (3) sensor values. An identifier allows to connect the device with further data related to the device stored in the controller, e.g. the ID of an NFC card establishes contact with data of the card holder and can be used for access control. Location data allows to track devices in a spatial context, thus enabling asset tracking. Finally, data produced by sensors allows to gather information about the environment of a device. The data from devices is collected and stored, e.g. in a log file, either on the device itself or on the controller. Collected data can be further processed, as detailed in Table 2. The third aspect regarding data in IoT scenarios is their further usage.

  • Dashboard: the potentially aggregated data is visualized in a dashboard to provide information to human participants. Those will make decisions based on the data and trigger a reaction, which might potentially involve other IoT devices. We consider scenarios that involve sending notifications to human participants as part of this category.

  • Automated decisions: the collected and potentially aggregated data is used by the controller to make automated decisions, e.g. sending commands to actuators or starting business processes.

Table 2. Levels of data processing in an IoT scenario
Full size table

Automation. Modern technology connected with IoT devices can often ease or replace manual labor. This work considers the degrees of automation shown in Table 3.

Table 3. Levels of automation in an IoT scenario
Full size table

Ownership. The ownership details are needed to make the right design decisions like the data or device access control. The owner of an IoT scenario can be homogeneous where the end user decides the policies, such as a smart home application. In contrast, the ownership can belong to one or more heterogeneous private or public corporation. For example, a smart factory scenario would be controlled by the factory owner(s).

4 Application of BPM Concepts to IoT

This section discusses the relevant concepts from BPM that might be beneficial for implementing and managing specific IoT scenarios. Based on the analysis of scenarios in Sect. 2 and the classification dimensions discussed in Sect. 3, examples are provided for which certain BPM concepts will be suitable. Often, the traditional process model languages are not enough to represent the context-adaptiveness in a dynamic scenario [14]. We propose the case management approach for scenarios demanding high flexibility. Since BPM has more human-centric perspective than the automated device interactions required for IoT, the BPMN extension proposed in [15] can be applied for an efficient integration of IoT and BPM.

Business Process Management. Business process management (BPM) is an established mean for modeling, executing and improving organizational business processes. BPMN 2.0 [16] is the industry standard for modeling, implementing, and enacting business processes. A process has a specific set of goals and activities are executed, either automatically or by process participants, in a specific order to achieve those goals [5]. Communication with the environment is represented as events in a process model and a process execution can be hugely influenced by such environmental interactions [17]. Processes can consume events (catching events) as well as produce events (throwing events). These events can trigger a process (start event), abort certain activities (boundary event), and choose between many possible execution branches (event-based gateway). The information carried by events can be used to make decisions in the course of the process execution.

Often, several participants collaborate in a process. These participants can belong to one organization or can be separate entities, shown as swim-lanes and pools, respectively. Process participants can interact with each other by means of message exchange. In case only the interaction is needed to be visualized, choreography diagrams are useful.

Now, process models can be used for several purposes in an IoT setup. Being an expressive language, BPMN artifacts can be used to model the interactions among the things and with the controller. This allows designers to better understand and communicate the IoT scenario they are developing. For example, processes can show the internal behavior of an IoT setup with a group of devices, having a homogeneous owner, like in the smart car scenario. For scenarios like Car Sharing, the interactions in a city context can be modeled with message exchanges between different pools. On the contrary, with a wide range of devices owned by heterogeneous stakeholders, a choreography diagram will be more appropriate to show the interactions while abstracting from the internal processes.

Going beyond representation of the IoT scenario, a business process management system (BPMS) can be used to implement the application logic of the scenario. In this case the BPMS acts as the controller: It receives the environmental occurrences from the sensors using the catching event construct, stores the event payload for further processing, chooses the appropriate execution branch based on event data, and sends instructions to the actuators via the throwing event construct. For exceptional situations, the error event can be executed with the semantics of a boundary event to abort the ongoing activities and follow the exception handling path.

The authors previously suggested to decouple event sources, e.g. the sensors in an IoT scenario, from the process logic acting on event data that is implemented in the BPMS [18]. Instead, the BPMS should be connected to a complex event processing (CEP) system that analyzes the raw events received from sensors and aggregates them to generate the higher level business events required for the process. The benefit of this approach is that the BPMS does not have to deal with the management of subscriptions, which is a challenging task due to the heterogeneous technologies used by different event sources. This approach is also well suited for IoT scenarios, which include many, heterogeneous sensors that frequently send events, for which a reaction is not always required. For example in a smart home scenario, only if five consecutive thermostat events report the temperature to be above a certain threshold, should the air conditioner be turned on.

Case Management. Case management has been proposed to support flexible and knowledge-intensive business processes [19] that cannot be represented well using standard approaches like BPMN [16] and traditional process engines. We focus the discussion on the Chimera approach proposed in [6]. The Chimera approach captures business scenarios in a case model that consists of (a) a domain model, (b) a set of object lifecycles, (c) a set of process fragments, and (d) a goal state, also called termination condition. During runtime a case model is instantiated into a case that at any time is in a certain case state, which changes through knowledge workers performing activities, but also due to external events. Cases are similar to process instances in traditional workflow systems, however, contrary to those, cases can contain several concurrently running fragment instances, as well as data objects. Each fragment, just like a BPMN process model, consists of event, gateway, activity, and data nodes, connected by sequence and data flow arcs. The domain model defines the business objects relevant for the scenario as a set of data classes and their relations. To each data class an object lifecycle (OLC) is associated specifying valid behavior of its instances, i.e. data objects.

Since IoT is about integrating the physical world into digital systems, exceptions and uncertainty are a significant part of IoT scenarios [20]. Depending on the occurrence of (sensor) events, as well as user decisions for some IoT scenarios, the execution path gradually emerges over time. Thus, predefined processes might not be a good match for them. Instead, process fragments as defined in the Chimera approach can be used to represent possible execution variants, that are triggered by certain events.

When considering the high degree of uncertainty involved in some of the use cases, it is sensible to include case management in more advanced versions that go beyond plain tracking in scenarios like freight tracking or crop monitoring. If the distributed participants run their internal processes in individual process engines, a case management approach can be used to have an overview of the whole scenario.

Fig. 1.
figure 1

The IoT architecture

Full size image

The IoT Architecture. There are many variations of the architectural layers, the components and the interactions among them. In [21], the authors compared different architectures for several IoT applications and came up with a reference architecture, shown in Fig. 1a. The architecture contains the drivers where sensors and actuators are embedded, the gateway, the middleware where the processing logic is executed and the application that uses the processed information. The architecture (shown in Fig. 1b) proposed in [22] gives a similar overview of the IoT layers. The perception layer includes sensors and actuators whereas the transport layer can be mapped to the gateway. The additional business layer here takes care of the ownership and is responsible for the application management. Based on the IoT application scenario and required participants; the components, the layers or the interfaces can change. However, if the BPM concepts are to be applied in an IoT scenario, the processing layer can be mapped to the CEP engine and the application layer can be mapped to the BPMS.

5 Conclusion and Future Work

The explosion of IoT devices have been significant in past two decades. This new technology tries to digitize the physical world with the help of sensors and actuators embedded in the things around us. These things talk to each other and are controlled by one or more logical unit. New business scenarios emerged due to IoT can benefit from the existing concepts from the area of business process management. However, to implement the suitable BPM concepts to IoT, first it is needed to realize the IoT scenarios better. This work provides an elaborate analysis of the IoT scenarios implemented currently and going to be implemented in near future. The classification framework covers the dimensions to be considered while analyzing or realizing an IoT setup.

To this end, BPM concepts that might be beneficial for IoT are discussed along with the IoT reference architecture. The framework will ease the design decisions for setting up the interconnected things in future. The insight into IoT scenarios with its important features will strengthen the bridge between business processes and IoT. Future work includes clustering the scenarios according to the described levels of each dimension and prescribing the specific BPM concepts applicable to the clusters.