## 4 Dyversify Architecture
### High-Level Overview  
To understand the flow of data throughout the system, it is easiest to consider measurement data and event data (created by processing measurements) separately. Both flows are shown in Figure 1.  
The left of Figure 1 shows the flow of measurements throughout the system. Measurements originate from individual Healthcare devices, as described in Section 2.2, and are received by a gateway on Renson premises. The Healthboxes have an internal memory to buffer measurements to prevent data loss in case of connectivity issues to the gateway. The gateway forwards all measurements to the _Obelisk_ component, which serves as the ingestion and long term storage system. Obelisk pushes all measurements in a JSON format to a _Kafka message bus_ that is consumed by other components. Two _event detection_(ED)_ and two _anomaly detection (AD)_ components consume all measurements and output an event message when a specific condition or pattern is observed. The _RML_ component is responsible for mapping measurements to their semantic form, which are needed by the expert rules and dashboard components. The _dynamic dashboard_ component is intended for user interaction: it can visualize the data streams for all devices, updating as new measurements flow in. We utilize the term _dynamic_ as the dashboard suggests visualization widgets based on the semantic annotations of the metrics that are to be visualized. The event stream is shown on the right of Figure 1. Events are generated by the anomaly and event detection components whenever they find a relevant pattern in the incoming measurements. All components output events in a JSON format which are converted to a semantic format by the RML component, except for the expert-rules component, which works internally using semantics as well. The semantic events are ingested by three different components. The dynamic dashboard triggers (or updates) user notifications whenever an event is ingested. Whenever the MP-events component receives a labeled event, it will start a new pattern detector to find that specific pattern in new measurements. Finally, the Stardog component is a database that permanently stores the semantic events and can be used by the dashboard and MP-events component to retrieve historical events. Note that the dashboard also outputs events; these are in fact previously ingested events that have been updated by user interaction, such as the labeling of an anomalous pattern. The precise definition of \"anomaly\" varies from source to source. Some consider anomalies as _strictly undesired_ (e.g., a malfunction), others prefer _outside of normal conditions_ (e.g., machine maintenance), or simply as _previously unknown_ (e.g., higher power consumption for a specific configuration). In this work, we use the term \"anomaly\" to indicate a previously unknown pattern, which may be undesired (e.g., malfunction) or normal behavior (e.g., opening a window for the first time), and we use the term \"event\" to indicate patterns recognized using some known rule (e.g., a humidity peak in a bathroom indicates a shower). However, when discussing the Kafka message bus, the _event topic_ contains both events and anomalies, as hinted by Figure 1.  
Figure 1: Flow of measurement (**left**) and event data (**right**) throughout the different microservices or microservice-based components (rectangles). Events are generated by the services after processing measurements. The thick bands represent data flow through Kafka topics, while arrows represent flow through HTTP API calls. Light colors indicate non-semantic (JSON) data; dark colors indicate semantic (JSON-LD) data. Measurements are ingested and persisted by Obelisk. The event detection (ED) and anomaly detection (AD) services process the measurements and produce messages for certain observed patterns. The RML component maps non-semantic data to a semantic format and Stardog is a semantic database that is used to store the semantic events.