Hi All,
Since we do have all the basic components which are required to build a
fully fledged real world analytics story with IoT Analytics Framework,
there was a suggestion that we need to build some analytics stories in the
context of IoT Analytics. So along with that, this is one of the examples
we are going to build.
In this use case, we are mainly focusing on analyzing sensor data in a
timely manner. So when sensors are publishing data it may be required to do
analytics in real time and do some decision making on a particular event
stream and so on. Then it goes on with batch processing in order to
summarize sensor data for later usage. Once raw data is available we will
be able to do some predefined machine learning tasks so as to perform
some sort of real work scenarios like model learning, anomaly detection
and so on. So this explains how the high-level architecture of this
project is.
[image: homeAutomationSystem.jpg]
Figure 01: High-level architecture
In the initial cut, we are to take a wide variety of dataset which contains
several types of sensor data from real sensors. This resource[1] is
provided datasets that have been collected for two successive months. So it
seems to match our requirement as well.
So these are the selected sample sensor information with some sample
dataset.
1.
Circuits
CircuitName,CircuitNumber,TimestampUTC,RealPowerWatts,ApparentPowerVAs
WashingMachine,14,1341047872,1.262,1.963
FridgeRange,15,1341047872,5.196,8.41
2. Individual energy meters
MeterName,TimestampUTC,RealPowerWatts,CircuitNumber
livingroom:subwoofer,1341047975,10,4
basement:washingmachine,1341048003,0,14
3. Dimmable and non-dimmable switches
SwitchName,TimestampUTC,MaxRealPowerWatts,DimProportion,
CircuitNumber
kitchen:sink,1341047877,65,0,18
Kitchenhall:lights1,1341047880,195,0,18
4. Voltage and frequency data on both electrical phases
TimestampUTC,FrequencyHz,VoltageVolts
1338887835,59.978,121.832
1338887836,59.978,121.832
5. Environmental data (indoor and outdoor)
TimestampUTC,insideTemp,outsideTemp,insideHumidity,outsideHumidity,windSpeed,windDirectionDegrees,windGust,windGustDirectionDegrees,rainRate,rain,windChill,heatindex
1341048000,73.580002 ,59.180004 ,45.0,83.333336 ,0.0 , ,0.0 , ,0.0 ,0.0
,59.180004 ,59.180004
6. Door open/close
DoorSensorName,TimestampUTC,OpenOrClosed
kitchen:refrigerator,1341054545,1
kitchen:refrigerator,1341054552,0
7. Motion detector data
MotionSensorName,TimestampUTC,MotionOrNoMotion
kitchen:corner,1341056647,0
livingroom:corner,1341056652,1
Requirement Analysis Phase :
- - - - - - - - - - - - - - - - - - - - - - - - -
[a] Key contextual areas, currently identified as important for showing
analytics related data :
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[1] Sensors based on each household view analytics
[2] Sensors based on each floor view analytics
[3] Sensors based on custom group view analytics
[4] Analytics related for individual sensors. This might be varied from
sensor to sensor.
[b] Dashboard Types, currently on consideration :
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
Based on the data analyzed and based on users who would interact with a
dashboard, we can define a generic dashboard which will be filtered based
on users.
[1] Generic User Dashboard - Dashboard for a user
view all the sensor details and its current status and group level
analytics in a hierarchical manner.
[c] Analyzed user stories:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
User Story Relevance - { Role : End User }
User Story 1 (with 1st highest prominence) :
A user should be able to see sensor counts which belong to the given system
appropriate graph views with respect to following states of connectivity.
[1] Active - Meaning a sensor has been able to communicate with the server
at least once within a specified threshold of time
[2] Inactive - Meaning a sensor has not been able to communicate with the
device at least once within the specified threshold of time
[3] Blocked - Meaning the communication in between a sensor and the device
has been blocked due to either being inactive for a long period of time
In here sensors communicate with the device. So sensors current status are
updated through the device.
User Story 2 (with 2nd highest prominence) :
A user should be able to see counts appropriate graph views with respect to
sensors with following states of alerts.
[1] Ok - Meaning sensors with this alert type shouldn’t be given any
prominence upon devices with other alert types
[2] Warning - Meaning sensors with this alert type should be given less
prominence upon devices with "Danger" alert type
[3] Danger - Meaning devices with this alert type should be given more
prominence upon devices with other alert types
After getting sensor information from each sensor then this information
needs to be summarized in a hicheiracial manner: floor level, home level
and so on.
User Story 3 (with 3rd highest prominence) :
A user should be able to see sensor counts with appropriate graph views
with respect to following groups.
[1] User defined groups - Meaning sensor counts, the summary of current
status of sensors and reasons for being malfunctioned based on custom
groups defined by users.
[2] Sensor group based on each floor - Meaning what are the sensors which
are installed into a given floor as well as the summary of current status
of sensors and reasons for being malfunctioned.
[3] Also based on houses
User Story 4 (with 4th highest prominence) :
Viewing group level analytics and individual sensor analytics
There should be a mechanism for viewing group level analytics and
individual sensor analytics. Because each sensor may contain a different
way of representing its analytics. Also, data retrieval from sensors also
might vary from sensor to sensor. So group level analytics would be
summation of individual analytics views or some sort of aggregation of
them.
User Story Relevance - { Role : Device plugin developer }
User Story 5 (with 5th highest prominence) :
A user should be able to install new sensors which already been registered
under given user into any appropriate location.
When device plugin developer is creating device type which may includes
several types of sensors. If a user is required particular device type
instance, then it needs to be registered under requested user, Afterward,
he will able to pick existing sensors and install into any appropriate
location. Upon sensor is being installed into a proper location, meta
information such as sensor coordinates, floor number needs to be provided
in order to fulfill installation process. Also update, remove and replace
functionality are required for particular sensor type.
1. http://traces.cs.umass.edu/index.php/Smart/Smart
Thanks,
Geesara
--
Geesara Prathap Kulathunga
Software Engineer
WSO2 Inc; http://wso2.com
Mobile : +940772684174
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
