# Semantic Microservice Framework for Digital Twins
## 4 Proof-of-Concept: Automatic Sensor Data Evaluation
### Results of the Sensor Evaluation Process  
Two scenarios, \"A\" and \"B\", are introduced for testing the sensor evaluation service. In both scenarios the mass flow, which is measured by the sensor \(m_{in}\), shows an anomaly. The anomalies of \(m_{in}\) are depicted in Figure 12 and marked with \"A\" and \"B\". The first scenario (\"A\") is caused by a clogged duct, which results in a reduced mass flow. Therefore, an additional flow resistor is used in the simulation, which is rapidly increased 220 min after the start. As the fan has no closed-loop control, the mass flow decreases rapidly. After 17 min, the resistance is removed so that the mass flow can increase to its normal value again. The second scenario (\"B\") is caused by a faulty mass flow sensor \(m_{in}\), which delivers the wrong values. To make things more difficult for the sensor evaluation service and show its capability, the faulty sensor values for the mass flow sensor \(m_{in}\) are exactly the same as for the anomaly \"A\", but in that case, the mass flow is not reduced in the simulation. Thus, the sensor evaluation service has to use context information to classify the occurred anomalies correctly. The faulty sensor data starts about 600 min after the start. Figure 11: Service orchestration for sensor data evaluation. Figure 10: Zeebe workflow engine infrastructure. The workflow shown in Figure 10 is invoked with a unique correlation ID, to assign messages to the workflow instance. With that correlation ID, the Data Anomaly Detection service is started. The deviations between the internal ARX model results and the measured values are visualized in Figure 13. The periods in time where the deviation is exceeding the threshold are marked as red area. As the internal models are executed in a serial-parallel manner, the unexpected values are propagating through the various models, as shown for the anomaly \"B\". The simulated values are used as input values within the simulation window. Thus, a clogged duct, which results in a reduced mass flow, shown by the discrepancy between the measured and simulated values of \(m_{in}\), has also influence on the simulated values of \(T_{hx}\), \(T_{sup}\), and \(T_{p}\) during the parallel operation. The detected anomalies are encoded in JSON-LD, based on the parts of PETIont and OWL-Time, as shown in Figure 7, and sent as response. The response is handed over to  
Figure 12: Scenarios: sensor fault (“A”) and clogged duct (“B”). Figure 13: Anomalies detected by the Sensor Anomaly Detection Service. the Sensor Evaluation Service by the workflow engine. The service analyses the detected anomalies based on causal relations derived from the topology information. The service clusters all identified anomalies into two groups, based on their timely occurrence. The first cluster or incidence contains only one anomaly (Scenario A). The other sensor values which are influenced by \(m_{in}\) are in line with the simulated output of the ARX models. Thus, the measurements are correct and the incident is classified as abnormal behavior of the plant, causing a reduced mass flow \(m_{in}\). For scenario B, a deviation between the measurement and the simulation is visible also at sensors which are influenced by \(m_{in}\) (Figure 13). This means there is a discrepancy between the measurements and the simulated ARX model. The causality information from the knowledge graph is used to identify the root cause of the deviations--in this case, a faulty sensor value of \(m_{in}\). A simplified visualization of the causal relations is shown in Figure 14. Based on this information, the root sensor \(m_{in}\) is identified and the incident is classified as a sensor fault. The identified incidences are classified based on the parts of PETIont, which is shown in Figure 9. In the presented use-case scenario, \"A\" is correctly classified as abnormal behavior and \"B\" as sensor fault. The result is encoded as JSON-LD and returned as a reply to the workflow engine over Kafka.