# An Interactive Method for Detection of Process Activity Executions from IoT Data +
## 6 Discussion
### Assumptions and Limitations  
With the proposed method we put focus on the detection of the sequence of activity executions, which are part of the _control flow_ perspective. Other elements of a business process in this regard (e.g., decision points, events) or of other perspectives cannot be derived. However, we are also able to identify the _resource_ (i.e., CPS component) that is responsible for the execution of an activity and its duration. _Formal Domain Knowledge:_ The proposed method relies on domain knowledge driving most of the steps. Here, we do not make any assumptions about such knowledge being formally encoded in some data structures but assume it resides in the mental model of the analyst. Clearly, this puts the burden of identifying concepts and relations solely on the analyst, which makes the method fully dependent on the analyst's cognitive capabilities. This limitation could be mitigated by integrating a formal representation of the domain knowledge, e.g., in the form of an ontology, coupled with automated reasoning capabilities for knowledge inference and with the potential for automatic identification of patterns. With this integration, the analyst could receive guidance in several steps of the method, with benefits in particular in the case of complex CPS requiring the analysis of large volumes of data. We will move in this direction with future work. _Parallel Activity Executions:_ Some of the basic assumptions in our work are that the execution of an activity is limited to one CPS component at a time and that one CPS component does not execute multiple activities in parallel (cf. Section 4.1). These assumptions are reasonable in discrete manufacturing and many other IoT domains that show a lower degree of automation and less complex activities than, for example, in high-throughput manufacturing settings. This allows us to reliably define the scope of one executed activity based on IoT data and relate it to the corresponding CPS component. With these assumptions, our method can also be applied in the case of parallel activity executions by different CPS components. However, the correlation with the corresponding process instance(s) becomes more difficult and requires additional process knowledge and context. Relaxing the assumptions would require adjustments to the proposed method. In case a CPS component executes more than one activity at a time, we may observe an overlay of activity signatures (in case the activities are independent of each other regarding sensor/actuators), completely different activity signatures (in case they are dependent) or the same activity signature (e.g., in case of batch production). To distinguish these activities from each other requires additional information (e.g., case or object identifiers), process knowledge and context. In turn, the execution of one activity by multiple involved CPS components would lead to activity signatures that span across components (e.g., the lifting of a heavy workpiece by two robots). For the proposed method this means that _Step 4_ (cf. Section 4) needs to be extended to not only consider the currently selected CPS component but also other relevant CPS components to identify the start and end of an activity. These types of correlations among CPS components have to be derived either as part of the domain knowledge or calculated (e.g., using clustering techniques). _Data Set:_ The data set used in the running examples to develop the method contains data from simplified models of real production machines (CPS components) [6]. The number of sensors and actuators being active in the execution of activities per component is limited to a maximum of 16, often less than only three or four sensors/actuators are relevant for activity signatures. This rather low number of sensors and actuators emitting data at a relatively low frequency (once per second) makes the interactive, visual analysis feasible for the process analyst.