# BPMNE4 IoT: A Framework for Modeling, Executing and Monitoring IoT-Driven Processes +
## 5 BPMN24 IoT-A Holistic Framework for IoT-Driven BPs
### Metamodel  
To meet _Objectives O1_, _O2_, _and O3_, we decided to use BPMN 2.0 as a basis for modeling IoT-driven BPs. As BPMN 2.0 has shown several drawbacks in this context (cf. Section 1.1), we extend BPMN 2.0 with IoT-specific modeling elements. This extension is based on the procedure described in [57]: First of all, we describe the extension at the metamodel level (also called _Abstract Syntax_) and then present concrete examples utilizing our extension for the _Concrete Syntax_. Figure 3 shows the proposed extension of the BPMN 2.0 in UML. Note that the white classes are already part of BPMN 2.0, whereas the red classes reflect the BPMNE4 IoT extension. To cover the characteristics of IoT-driven BPs at the modeling level, we extended the BPMN 2.0 classes _Activity_, _Throw Event_, and _Catch Event_[20] with new subclasses (cf. Figure 3). The following is an abstract description of the artifacts and events.  
\begin{table}
\begin{tabular}{l c c c c c c} \hline \hline
**Approach** & **Modeling** & **Executing** & **Monitoring** & **Logging** & **User Interface** & **Domain Independent** \\ \hline uBPMN [26] & ✓ & ✗ & ✗ & ✗ & ✗ & ✗ \\ SPU [46] & ✓ & ✓ & ✓ & ✗ & ✗ & ✓ \\ BPMN4 WSN [47] & ✓ & ✓ & ✓ & ✗ & ✗ & ✗ \\ [PERSON] et al. [48; 49] & ✓ & ✗ & ✗ & ✗ & ✗ & ✓ \\ [PERSON] et al. [51] & ✓ & ✗ & ✗ & ✗ & ✓ & ✓ \\ BPMN4 CPS [53] & ✓ & ✓ & ✗ & ✗ & ✓ & ✗ \\ [PERSON] et al. [54] & ✓ & ✗ & ✗ & ✗ & ✗ & ✓ \\ [PERSON] et al. [55] & ✓ & ✗ & ✗ & ✗ & ✗ & ✓ \\ \hline \hline \end{tabular}
\end{table}
Table 1: Overview on related approach extending BPMN 2.0 for IoT-driven BPs.  
**Artifacts:**  
* _IoTActivity:_ To an _IoTActivity_, one or more IoT artifacts are attached.
* _IoTActuator(Group)Artifact_: The _IoTActuatorArtifact_ represents a physical actuator that contains the information required for the execution of the physical actuator. This artifact is also used for monitoring the state of the physical actuator. To increase its abstraction, an _IoTActuatorGroupArtifact_ may combine multiple _IoTActuatorArtifacts_.
* _IoTSensor(Group)Artifact:_ The _IoTSensorArtifact_ represents a physical sensor, containing the information required for querying the physical sensor. This artifact is also used for monitoring the state the of the physical sensor. To increase its abstraction, an _IoTSensorGroupArtifact_ may combine multiple _IoTSensorArtifacts_.
* _IoTCatch(Group)Artifact:_ An _IoTCatchArtifact_ allows for checking a condition based on a sensor value, i.e., it contains the information required for condition checking. An _IoTCatchGroupArtifact_, in turn, combines multiple _IoTCatchArtifacts_ to increase the abstraction level.
* _IoTObjectArtifact:_ An _IoTObjectArtifact_ represents a physical object (e.g., a robot or a smart machine), which may contain multiple _IoTSensorArtifacts_ and _IoTActuatorArtifacts_. Furthermore, this artifact is used for monitoring the state of a physical object.  
**Events:**  
* _IoTStartEvent:_ An _IoTStartEvent_ refers to a physical sensor and enables the start of an IoT-driven BP.
* _IoTEndEvent:_ An _IoTEndEvent_ represents a physical actuator that triggers the execution of an actuator, terminating the corresponding process instance.
* _IoTIntermediateTthrowEvent:_ An _IoTIntermediateTthrowEvent_ refers to a physical actuator, enabling the control of an actuator along the sequence flow.
* _IoTIntermediateCatchEvent:_ An _IoTIntermediateCatchEvent_ represents a sensor that enables the process instance to check a condition based on the received sensor data.
* _IoTBoundaryEvent:_ An _IoTBoundaryEvent_ represents a physical sensor being attached to a task. If the defined condition is fulfilled, the sequence flow is redirected.  
Figure 3: BPMNE4 IoT metamodel.