Microsense: A Unified Sensor Framework for IoT SoC's for Simplified Data

Analysis, Visualization and Access

Dr. K.G. Srinivasa

Ganesh Hegde

Head of Department,

Dept. of Computer Science and Engineering

M S Ramaiah Institute of Technology (Affiliated to VTU)
Bangalore, India
xgt008@gmail.com

Dept. of Computer Science and Engineering

M S Ramaiah Institute of Technology (Affiliated to VTU)
Bangalore, India
kgsrinivasa@gmail.com

Ashwin Ramanand
Dept. of Computer Science and Engineering
M S Ramaiah Institute of Technology (Affiliated to VTU)
Bangalore, India
winash77@gmail.com
AbstractThis paper involves the idea of creating a common,
unified framework that will provide a robust set of guidelines for
sensors with varied degree of complexities connected to common
set of System-on-Chip (SoC)s to ease the monitor, control and
visualization of real time data coming from sensors of different
type connected to these SoCs.
In the prototype built based on the idea we define a standard
API that will be followed by sensors for sensor registration to the
server and for the data streaming in real-time. This API which is
currently at the revision v0.1 will be constantly revised with the
project progress. This API will be the standard to which the
sensors will comply while streaming data when connected to the
client platforms. This will involve the implementation of the
following:
a) A Central Server Infrastructure: this supports HTTP requests
for sensor and platform registration and sockets for streaming
the data in real time.
b) Client programmes with GPIO support: This will directly
merge with the client programmes that do the actual data
gathering from the sensors.
c) Sample Ecosystem: This will primarily involve the testing of
the above two infrastructure with a broad range of platforms
(the SoCs) and sensors for validation.
Keywords- Internet of Things, Applications, Sensors, Data
Gathering, Data Visualization

I.

INTRODUCTION

The Internet of Things (IoT) received its rst attention in

late 20th century. The term was coined in 1998 [1] and later
dened as The Internet of Things allows people and things1
to be connected Anytime, Anyplace, with Anything and
Anyone, ideally using Any path/ network and Any service[2].
The IOT field of computational sciences is rapidly expanding
with the upcoming powerful embedded platforms such as Intel
Galileo, Raspberry Pi, Odroid XU3 and Google Glass. The
need of the hour is to ensure there is a unified framework that

supports data extraction, data visualization and minimal

platform control along with social sharing of the data.
Deploying large-scale sensor networks in real-world settings is
a challenging issue.[13][14][15][16][17][18]

II.

SCOPE OF THE FRAMEWORK

The sensor framework aims to bridge the void that exists in

the scattered Internet of Things (IOT) field especially in the
SoC platforms with their various sensors and extended
modules. The obvious lack of a uniform framework that
handles the data, provides a coherent form of sensor data
indexing, platform handling, social integration and dynamic
data visualization of the data is the goal of this project.
III.

RESEARCH CHALLENGES

The current sensor framework Microsense deals with the

problem of diverse SoC platforms and their connected sensors.
The problem is how to harvest and present the data in a way
that is understandable even to a layman without having
him/her to undergo the intricacies of connecting and mining
data from a digital sensor connected to the SoC. The major
challenges faced during the development of the sensor
framework can be summarized as follows, Provide a way to
visualize, mine and share the data extracted from SoC
platforms, while also being able to display information about
the SoC. Importantly to present a standard API for developers
to provide access to the data without having them to go
through all the hassle of connecting the wires. One of the most
important challenges faced by the developer is to provide
Robust, Simple and flexible Designs One critical obstacle in
sensing and behavior modeling is privacy. The Big Data
generated by such detailed and 24/7 sensing can scale up to

several Gigabytes per day for a user. In order to guarantee

scalability and energy efficiency, several solutions based on
dividing the sensor network into different clusters have been
proposed [8][9][10][11].
IV.

PROPOSED FRAMEWORK FOR SENSORS

The framework for the sensors should be able to support the

basic function of data retrieval from the Platform to the central
server for both live and static data formats. The data should
also be available for visualization through the server side
sample webapp to demonstrate the data pattern and variations.
In addition to this, manual platform addition and basic
administration via the web interface has to be featured to
achieve control of multiple Sensor Platforms via a single
Server Side GUI while easing out the process as much as
possible for developers to retrieve the data. Social integration
to share the obtained data in visualization snapshot of the data
as well as in textual format should be made available. API
server for data retrieval for developers as well as for the basic
operations: GET, POST and PUT.
A. Design Goals
The framework is designed to be of modular in terms
of architecture base and has three important components,
Platform, Server and Client. The former two are the actual
core of the Microsense framework and are essential for the
functionality. The latter module is for demonstration and can
be replaced with or extended by third party applications as
deemed fit for the purpose. The platform has the essential
functionality of streaming data to the server in real time that is
obtained from the sensors connected to the platforms. The
server retrieves the stream and provides the necessary backend
infrastructure for the above mentioned functionalities while
hosting a standalone API server as well. Depending on the
scaling needs, the API server might be separated eventually.
The webapp handles data visualization as well as manual
platform administration tasks and is an extension of the server.
The client of Microsense architecture can be a client side
webapp that is feeding the data from the server, performing
visualizations or can be a receiver for a program that takes the
incoming data as the input and performs further tasks
depending on the requirements.
B. Expansion Based on Requirements
While the above mentioned requirements for the design of
Microsense framework is something we deem fit for most
situations, the framework could be unfit for some specific
needs. For this purpose, the API must be robust and scalable
enough in terms of handling data requirements. A trivial as a
need for a specific API rewrite should be able to be
implemented without having to rewrite the core infrastructure
of the Backend Server. In another example scenario the server
side UI might be solely inadequate for the requirements of the
intended application which could just be achieved by a simple
UI rewrite without breaking the API or the Backend
Infrastructure.

Figure 1: Sample Design Architecture

C. Sample Design
The sample design architecture tries to meet all the aforementioned without being overly complex. This sample design
architecture tries to be as minimalistic as possible, reducing
the overhead of the maintainers without compromising on the
functionality and the possible scope of example. In the sample
design, the platform sends data in through sockets depending
on if the data is static or real time. The server must handle this
data through web sockets and also allows connection to
various clients through the same for developer access. These
requirements can be easily achieved with usage of Flask
Server which has support of external Flask-SocketIO
extensions without having to deal with the intricacies of a
more complex Server model.

V.

IMPLEMENTATION

Figure 2: Data Flow

Figure 1: Structural Decomposition

The implemented prototype of the system offers basic
functionalities of the proposed framework. The prototype is a
2-tier platform-server-client architecture, where the client is
essentially a developer system gaining access to the sensor
data. It could also be a simple client program that reads data
from the Initially the extraction of data from the platform
through GPIO programming involving python libraries for
raspberry pi, the data extracted is streamed to the server
through python sockets.
Platform: A system on chip (SOC) that supports interfacing
with various sensors via GPIO, USB or wirelessly, while
having the ability to run a full-fledged operating system such
Ubuntu Linux. The projects working prototype is completely
based on Raspberry Pi GPIO sensor interfacing.
Sensor: A sensor in this context is any digital measurement
device that produces digital data that pertains to a real life
entity such as temperature, humidity, distance, Wi-Fi signal or
anything. The requirement here has to be that it provides a
extractable form of data that can be put to use in the
framework.

Server: The server is written using Flask Micro Framework. It

contains both the API server and the server side for the
platform. For the prototype we have implemented web
interface for the server as a proof of concept of the webapp
which can be run separately from the server. The Flask server
receives the stream of data from the platform and broadcasts it
to the webapp using Flask sockets. Flask Sockets is a server
backend for HTML5 sockets. The data is transmitted
instantaneously to the webapp as the data stream is received
from the platform. The reception is done through the normal
python socket while the broadcast is sent to webapp using
Flask sockets extension
Platform information is retrieved using Paramiko library for
python which is a native SSH implementation in python. This
library unlike others is not a wrapper around normal SSH
binaries and is rather a native implementation of open SSH in
python. The login credentials of the platform is pre-saved and
the system information query script on the platform is run
remotely using Paramiko. The resultant string is displayed on
the webpage after the output is redirected through STDOUT.
Paramiko creates an output channel which allows the direct
execution of commands.
Webapp: The webapp handles platform information real-time
graphing and social sharing. Platform information displaying
is done through Paramiko output as explained earlier. Realtime graphing is achieved through d3.js library which is a
graphing tool in JavaScript. The data because is instantaneous
has to be plotted in real-time. Therefore real-time path
translation is used in d3 to reflect changing datasets. The X
co-ordinate is dragged behind by one data point to allow
instantaneous reflection of data changes.
Social Integration: The social integration is achieved through
native SDKs from Twitter and Facebook on the webapp the
data points as well as the graph snapshot can be shared
instantaneously. It is a point to mention that the socket is run
on a background thread to ensure that the server doesnt come
to a halt while receiving the data from the platform.
Front end: The front end uses two key JavaScript libraries to
achieve good looking results. Semantic UI is used to get a

good looking web interface while socket IO is the receiver for

the Flask socket broadcast.
VI.

FUNCTIONALITY REQUIREMENTS

The data transmission between the platform to the

server must be instantaneous with minimum latency. Via the
webapp, users should be able to register and unregister SoC
platforms. The control functionality of the platform is
quintessential. The framework should have minimal footprint
on the server as well as by the webapp. The framework needs
to work on Wi-Fi as well as LAN networks.
The functions that are satisfies by the implemented prototype
are as follows
1. Data visualization: Visualization of data which is
acquired through these platforms connected to the
sensors in real-time.
2. Social Sharing: Sharing the visualization or the raw
data itself to mediums like Facebook, Twitter
3. Platform Support: Providing support to wide array
of Platforms and their sensors, starting with the
Raspberry Pi.
4. API Access: Support for both live streamed data and
static data through the sensors via the centralized API
server.
The unique feature of the framework is the interoperability
between different platforms with the same server and console
offering centralized data visualization for the users. The
Sensor Framework will also aim for high availability and
minimal downtimes and will also add support to additional
platforms as and when they become available with their lowlevel interfaces.

VIII. TESTING
A. Software Environment
The platform is connected to the server using servers
own private network. This is achieved by running a DHCP
server on the machine hosting the server to be able to connect
to the platform without any external network router. Testing
can be done either on Linux/ Mac or Windows machine.
Windows requires installation of Python separately along with
a suitable package manager like pip. Because direct package
management is difficult we recommend installing all the
packages in a python virtual environment or use a Python IDE
which supports in-built package management. PyCharm
Community Edition which is free software and is licensed
through GPL lets us do the same.
The entire framework can also be set on a virtual
machine running on windows given network sharing between
the host and the guest is done through NAT and not a bridge
connection. Linux on the other hand merely involves installing
the packages using the distributions package management
system.
The Flask server runs on the local host port 5000 by
default. The platform script which starts the data broadcast is
started remotely through SSH and the data broadcast is begun.
When the Flask server is launched it receives the broadcast
and the data points are displayed on the webapp along with
maxima and minima of the data point the data visualization
tab plots a real-time graph of the data.
However according the testing results the only
downside being high CPU utilization because of the webapps
JavaScript plotting this can only be alleviated using either a
static graph or improvements done in the upstream d3.js
library.
B. Unit Testing

VII. PERFORMANCE REQUIREMENTS

The principal functional requirement of the reference
implementation is the need for the data to be available to
dependent client applications as well as through the API for
the developers all the time. This requirement has to be met by
ensuring the Sensors and the Platforms are connected to the
Server through a Public IP or through a Dynamic DNS. The
server here should be connected to the Platform and be
available all the time guaranteeing the maximum possible
uptime, this could be possible by hosting the Server code on a
provider like AWS, Heroku or Google App Engine.
Depending on the economic viability of the organization
intending to use this framework, they could test and plan the
deployment through various means.
On the UI front, the visualizations often tend to be taxing
on the CPU even though not being based on upon Flash
rendering which traditionally churns up more CPU cycles.
This has to be further investigated and improvised upon by
using improvised multithreading performance and using GPU
rendering supporting libraries wherever possible.

Unit testing is a software verification technique that

validates software components in isolation of each other based
on a test specification. Unit testing can be used at several
different granularities, including individual functions, objects
or subsystem. In sensor networks (WSNs), the process of unit
testing is complicated by several factors. First, many software
modules for sensor networks are tightly coupled with the
hardware and therefore must be loaded onto a sensor node, in
this case the Raspberry Pi.
The Unit Testing phase involves successful reception
of verbose messages for the server unit, which is read via the
Unix Shell in Ubuntu and PyCharm console in Windows. For
the API and Socket component respective debug messages are
enabled by passing app.debug = True flag in the Flask server
module.
The unit testing for the Raspberry Pi component
involves printing a message on successful communication
with the GPIO port. If the GPIO port is already engaged, the
error message is displayed appropriately. When the connection
to the Raspberry Pi is established successfully, the data values
are mirrored in the SSH terminal.

C. Functional Testing
Functional testing is a quality assurance (QA) process
and a type of black box testing that bases its test cases on the
specifications of the software component under test. Functions
are tested by feeding them input and examining the output,
and internal program structure is rarely considered (not like in
white-box testing). Functional Testing usually describes what
the system does.
The functional testing scenario in Microsense
involves, testing the Raspberry Pi for successful boot, which is
achieved by running Top process. The preliminary boot is
verified
via
all
blinking
lights
in
LED.
For the server functional testing, upon successful
connection with the Raspberry Pi, the graph is established in
the Data Viz section and the live data is mirrored in the Live
Data section of the Web UI.

X.

D. Integration Testing
Integration testing (sometimes called integration and
testing, abbreviated I&T) is the phase in software testing in
which individual software modules are combined and tested as
a group. It occurs after unit testing and before validation
testing. Integration testing takes as its input modules that have
been unit tested, groups them in larger aggregates, applies
tests defined in an integration test plan to those aggregates,
and delivers as its output the integrated system ready for
system testing. We follow the Bottom-Up Integration testing
module with the test scenario starting with the Raspberry Pi
unit ending with the browser.
In Microsense, integration testing involves testing
the Raspberry Pi for successful connection via the SSH. This
is followed by checking the server for already engaged
sockets, and testing connection with the Raspberry Pi via the
server module. The server module upon successful stream to
the Web App UI has an inbuilt test case for successful
connection of server module with the active browser stack.
This can be verified through the browser console in both
Firefox and Chrome. Finally the API is also tested via a third
party system and a dummy entry is received via the CURL call
as the part of the integration testing.
IX.

But there are certain operating environment constraint

specifications that are The framework will run on normal PC's
with platform client code running on the respective platforms
in their Linux distributions.
The server code will be running on any suitable
Linux/Windows/Mac with a proper Python 2 environment.
The client webapp can run in the following browsers: Internet
Explorer 9 and above, Firefox, Chrome and Safari with all of
them being their respective desktop versions. The webapp and
the mobile app must be able to share the data and allow user
comments on the same to share on social media. The
following social media are being targeted at the moment:
Twitter, Facebook and Google+. This will of course require
handling of authorization into these social networks done on
our side of infrastructure.

APPLICATION

This sensor framework is intended to be the next standard in

the field of Internet of Things, similar to how Microsoft's
DirectX platform pertains itself to GPU's. The following user
classes are primarily identified.
Casual Enthusiasts: Who want a simple to use framework
that does all the heavy lifting and provides simplified data
visualization and sharing.
Developers: who want direct control over the data and want to
play around with the data through the stream instead, through
the APIs
End User: Developer created apps using the sensors APIs
will power real life applications of the sensor.

RELATED WORK

There are many previous proposals including design of

sensing matrix with the prior knowledge of the channel
between the signals and the sensors. We determine that full or
partial knowledge of the channel at sensors enables effective
sensing matrix design and supports a good signal recovery.
Compressive sensing (CS) [3][12] is used which is an
emerging signal acquisition technique that recovers a sparse
signal from few linear measurements. CS is currently applied
in many areas such as coding, signal processing and wireless
sensor networks CS framework for wireless sensor networks is
presented in this paper sensors are connected to a centralized
fusion center. Each sensor measures a desired sparse signal
and then compresses the sensed signal using a sensing matrix.
Measurements from different sensors are sent to the fusion
center for joint recovery of the sparse signals. We observe that
the signals thus acquired have a lot of redundancy which can
be handled efficiently by the proper design of sensing matrices
using the prior knowledge of the channel. But there are
various different challenges such as the design of a good
sensing matrix at each sensor. The conventional Gaussian
sensing matrix in may not be enough capture the maximum
information because the sensing matrix design now has to
depend on the characteristics of the channel.
Integrated framework for storing, processing and delivering
sensed data to people-centric applications [4]. Integrated
platform is the foundation of a new delivery model namely,
Mobile Application as a Service (MAaaS) in this model
connectivity is provided through a mobile client on the mobile
device and are platform independent
Mobile Sensing Framework: Mobile Cloud Application
(MCA) [4] a thin client that runs on mobile device collects
sensory data from mobile device minimizing energy
consumption. The rest of the system components is part of the
cloud infrastructure. The User Adaptation Module (UAM)
interfaces the MCA with the Mobile Cloud Engine (MCE) and
a storage module(SM) allows to save ad retrieve sensory data
The Application Interface Module (AIM) interacts with the
framework to get the required data. The Mobile Cloud Engine

(MCE) processes and controls the data flow in the framework.

The context-awareness (CA) module provides context
information to the different people-centric applications.
Proposed framework can reduce the energy consumption of
mobile devices, while satisfying the application requirements.
An integrated comprehensive security framework that will
provide security services for all services of sensor network is
proposed. Extra components i.e. Intelligent Security Agent
(ISA) [5] to assess level of security and cross layer
interactions many components like Intrusion Detection
System, Trust Framework, Key Management scheme and Link
layer communication protocol. This approach does not place
any trust assumption on the communication apart from the
obvious fact that there is a nonzero probability of delivering
messages to related destinations. But the following points are
addressed: Robust Trust Framework using Cross Layer
Approach. Trust Based Group Head Election. Key
Management Architecture. Adaptive Secure Communication
Protocol. Intrusion Detection System.
Mobile sensing Apps (CMU MobiSens and the MIT Funf1)
[6] run as services in the background and can constantly
collect sensor information from smart phones. We are able to
infer behavioral pattern of the user from the big data collected
using sensors.
Hybrid cloud trust framework: [6] User is given complete
control of his/her own personal big data and applications to
learn behavioral patterns from the raw sensor data can be
developed. No raw data is exposed to data consumers.
Application widgets are created to extract statistics from
users sensor data. One of the contributions of the proposed
framework is decentralized data aggregation using private
cloud. Trusted third-party data widget certification is key to
the framework. But the major challenges in hybrid cloud trust
framework are privacy. The Big Data generated by such
detailed and 24/7 sensing can scale up to several Gigabytes
per day for a user. Users become anxious of their private
data when they are unsure who may have access to their
personal data after being uploaded to the server and how it
will be used or shared.
The Integration Framework for Sensor Networks and Data
Stream Management Systems [7] allows the sensor network to
communicate its processing capabilities and constraints, along
with descriptions of the data. But the major challenges are
involves the aspects such as the processing capabilities of the
sensor network are much smaller than the capabilities of the
DSMS. Second, in contrast to a DSMS, in a sensor network
the same operator will be run on multiple nodes. The third
challenge is that a DSMS and a sensor network have different
and potentially conflicting goals. But there are many
advantages such as the ability to combine stored or streaming
data from the data stream management systems (DSMS) with
data. A single, integrated interface for interacting with both
the streaming database and the sensor network. The ability to
optimize between the database system and the sensor network.

XI.

CONCLUSION AND FUTURE WORK

Expansion of the framework by adding more number of

supported devices with addition of more number of platforms
and importantly Android. Standardization of the API and
further communication with hardware vendors to support the
API in their upcoming sensor models is something that is
closely being monitored. The future scope largely involves the
standardization of the API along with expansion of the
prototype to different type of devices. Extending this platform
for a social cause, such as of being of aid to physically
handicapped people. The standardization of the API can be
achieved only once there is decent array of sensors that is
tried and tested with different platforms.
Android Support: Implement a Android app that displays the
results in mobile as well as ways to extract Android Sensor
Information. This will act as much more common platform
than a UltraSonic sensor and should be much easier to
interface and extract data from. However the ever changing
Android APIs do pose a challenge. Current areas of interest
are Accelometer, GyroScope and GPS data, if they are
extractable. The same mapping and social share platform shall
be used to play around with these data sets.
Vendor Support: Looking forward to discuss with vendors
about the possibility of supporting the API so that it becomes a
de-facto standard for upcoming generation of IOT devices and
sensors. This will be a huge leap forward in the field of IOT if
properly done.
Data Analysis: The various types of data extracted should be
immensely useful for various objectives such as building
advertising profiles targeting the data, data mining, tracking
user preferences etc.
REFERENCES
[1]

[2]

[3]

[4]

[5]

[6]

[7]

K. Ashton. That internet of things thing in the real world, things matter
more
than
ideas.
RFID
Journal,
June
2009.
http://www.rfidjournal.com/article/print/4986 [Accessed on: 2012-0730].
P. Guillemin and P. Friess. Internet of things strategic research roadmap.
Technical report, The Cluster of European Research Projects, September
2009. http://www.internet-of-things research.eu/pdf/IoT Cluster
Strategic Research Agenda 2009.pdf.
J. Oliver and Heung-No Lee.A Realistic Distributed Compressive
Sensing Framework for Multiple Wireless Sensor Networks.
http://infonet.gist.ac.kr/wpcontent/uploads/papers/Oliver_SPARS11.pdf.
Rasool Fakoor, Mayank Raj, Azade Nazi, Mario Di Francesco and Sajal
K. Das. An Integrated Cloud-based Framework for Mobile Phone
Sensing.http://conferences.sigcomm.org/sigcomm/2012/paper/mcc/p47.
pdf.
Kalpana Sharma, M.K. Ghose, Kuldeep. Complete Security Framework
for
Wireless
Sensor
Networks
http://arxiv.org/ftp/arxiv/papers/0908/0908.0122.pdf.
Joy Ying Zhangy, Pang Wuy, Jiang Zhuyz, Hao Huz, Flavio Bonomiz.
Privacy-preserved Mobile Sensing through Hybrid Cloud Trust
Framework.
http://mlt.sv.cmu.edu:3000/papers/privacy-preservedsensing.pdf.
Daniel J. Abadi, Wolfgang Lindner, Samuel Madden, Jorg Schuler. An
Integration Framework for Sensor Networks and Data Stream
Management Systems. http://www.vldb.org/conf/2004/DEMP28.PDF.

W. Heinzelman, A. Chandrakasan, and H. Balakrishnan, An

application-specific protocol architecture for wireless microsensor
networks,IEEE Transactions on Wireless Communications, vol. 1, no.
4, pp. 660670,Oct. 2002.
[9] O. Younis and S. Fahmy, Distributed clustering in ad-hoc sensor
networks: A hybrid, energy-efficient approach, in Proceedings of IEEE
INFOCOM 2004, Hong Kong S.A.R., P.R. China, March 2004.
[10] V. Mhatre, C. Rosenberg, D. Kofman, R. Mazumdar, and N. Shroff, A
minimum cost heterogeneous sensor network with a lifetime constraint,
IEEE Transactions on Mobile Computing, vol. 4, no. 1, pp. 415, Jan.
2005.
[11] F. Kuhn, T. Moscibroda, and R. Wattenhofer, Initializing newly
deployed adhoc and sensor networks, in Proceedings of ACM
MobiCom 2004, Philadelphia, PA, September 2004.
[12] Richard Baraniuk, Compressive sensing, IEEE Signal Processing
Magazine, vol. 24, no.4, pp. 118-121, 2007.
[8]

[13] P. Buonadonna et al. Task: Sensor network in a box. In EWSN 2005.

[14] B. Greenstein et al. A sensor network application construction kit
(snack).Sensys2004.
[15] A. Mainwaring et al. Wireless sensor networks for habitat monitoring. In
WSNA2002.
[16] Padhy et al. Glacial environment monitoring using sensor networks. In
REALWSN 05.
[17] J. Polastre et al. Analysis of wireless sensor networks for habitat
monitoring. In Wireless Sensor Networks, chapter 18. 2004.
[18] N. Ramanathan et al. Sympathy for the sensor network debugger.
In SenSys 05.