# DataStream XES Extension: Embedding IoT Sensor Data into Extensible Event Stream Logs
## 2 Foundations and Related Work
### Process Mining
So, despite its noteworthy flexibility and closer conceptualization to the real-world in case of business processes supported by relational databases, the missing case notion in the OCEL format can become a liability. ### Data Analysis for BPM and IoT

In recent publications the temporal and spatial aspects of sensor readings are used for automatically connecting them to process execution [43]. Both, the sensor readings as well as the business processes, are seen as an integral part of application scenarios and their analysis in IoT [2; 44; 45]. Multi-perspective process mining [46] has evolved to, for example, use tree structured process event logs containing time-series data outside the XES BPAF lifecycle, as presented in [47]. Also, the analysis of this time series data is used as described in [47] for detecting concept drifts during runtime. A survey on outcome-oriented predictive process monitoring presented in [48] compares different techniques. [PERSON] et al. [49] propose to perform data-aware process discovery with IoT-based attributes. A data petri net is discovered from two real-life event logs, and rules behind some decisions are mined based on IoT-derived attributes. The proposed framework requires abstracting the IoT data to integrate them in an XES event log. For all of these approaches, datasets have been provided containing a wealth of context data in conjunction with process events. However, these datasets present slightly different granularity levels, slightly different formats, and slightly different semantics. [PERSON] et al. [50] recently proposed an approach named Amoretto to integrate IoT data into XES logs. They focus on a limited, well-established set of attributes from the BPM domain into process logs: physical object, location, time, identity, environment. They explicitly collect the data by adding collection tasks to existing process models, leading to a multitude of problems: (1) The data from the collection is indistinguishable from normal data flow from non-Amoretto event logs, so specialized analysis will be hard. (2) Their main context is the trace/process instance, if a sensor data collection is relevant for a particular task or set of tasks, it must be explicitly modeled as parallel to the task containing the business logic. This leads to complicated analysis as the tasks containing the business logic also have to have information about physical object, location, and environment to be connectable. (3) Unlike earlier work such as [51], they ignore IoT standardization efforts and classification. Finally, (4) when considering the real-world examples presented in this work with 50+ sensors, it becomes obvious that the resulting process models will violate all rules of good process modeling [52]. In contrast, the approach presented in our work, focuses on how IoT data can be connected to existing logs for unchanged process logs and process models, considering (a) intrinsic (process context) data, (b) extrinsic (non-process context), and (c) separate data, and focusing on connection to existing events, while acknowledging that many IoT events might occur while existing business logic is executed, both at instance and event level. ## 3 An XES-Extension for IoT-Enriched Event Logs

Based on our literature analysis presented in Section 2 we think, that XES is still the best starting point for representation and long-term storage of process data and all connected IoT data. As discussed above, (1) process and IOT data can have a different granularity (e.g., multiple sensor readings from multiple sensors per task), (2) IoT data might not be explicitly connected to the process, and often has to be connected to the process data ex-post from heterogeneous sources, and (3) the data-sources for sensors are potentially evolving (e.g., additional sensors, new replacement sensors, sensor firmware updates leading to changed data structures).