Atualizado: Jul 23
With the prevalence of IoT sensors, a large volume of data is being produced non-stop. A moderately sized smart building can have hundreds of sensors that generate new data every few minutes. This clearly exceeds the capacity of human supervision, meaning that truly exploiting this data requires the support of automated methods.
Anomaly detection is an automated application that is particularly interesting in time series data, like the ones continuously generated by a smart building. It involves real-time analysis of data streams from devices/sensors to identify the "odd-one-out": abnormal behaviors or potential problems.
There are several types of time series anomalies that we might be interested in:
Point or subsequence: We can examine individual sensor readings or entire sequences of them. A subsequence may be suspicious even if the comprising values by themselves are not.
Contextual or not: Data from a sensor can be analyzed in combination with contextual data (e.g. weather, calendar, etc.) to spot more subtle anomalies.
Single or multi-dimensional: We may analyze individual sensors as separate data streams, or combine them into multidimensional data streams that capture the interplay between sensors.
At Bandora, we are interested in robust anomaly detection (AD) that can be readily applied to any smart building without tailoring. This requires the AD to be source agnostic, adjustable, and adaptable.
AD must be source agnostic because different sensors/devices can generate radically different values (in terms of range, magnitude, and regular operating modes). As an example, below we see the power levels of two different devices along with the detected point anomalies (red markers). Being able to automatically detect a device's common operating modes enhances the interpretability of anomalies.
A source agnostic AD does not mean an inflexible AD; adjustability to particular preferences is still a desirable characteristic. For instance, it would be practical to allow the user to dial in the sensitivity of the AD (e.g. depending on the importance of what is being monitored). Below we see an example of the total number of detected anomalies for various sensitivity levels of AD applied to the power level of a device.
Finally, we require adaptable AD that does not need manual updates or maintenance. Behaviors (or even devices/sensors) are subject to change; therefore, what was once considered an anomaly might become the norm. A repeated anomalous value will eventually stop being flagged as anomalous and start being seen as normal. Furthermore, old observations may stop informing the AD as they become irrelevant. A powerful tool in this matter can be feedback from the user, e.g. confirming a value as anomalous can prevent the AD from ever "getting used to it".