chapter 4.pdf

41
CHAPTER 4
EVENT COLLABORATION BASED SENSOR DATA AS
SERVICE
Any IoT system basically comprises of input, output and a processing unit. The
input spectrum comprises of many sensors that are used to measure various
environmental parameters such as temperature, humidity, pressure, noise, leak and
many more. The sensors can be digital or analog as already introduced, as in the case
of a DHT11, a Digital Temperature and Humidity sensor, and can also be analog, such
as LM35 temperature sensors.
The processing unit of these systems is microcontrollers. The sensors, actuators
and the communication devices are interfaced with the microcontrollers and the
application code is flashed onto the microcontroller.
A typical IoT system contains multiple sensors and actuators. There is a large
amount of data that is being generated from these IoT systems. This data can be used
in multiple ways such as simple monitoring, or different types of analytics can be
performed such as pattern recognition, prediction, to name a few. These analytics can
be performed by data scientists, data engineers, data analysts from around the world.
The learning curve involved to exploit these systems is too high as they need to enhance
their skills beyond their domain expertise. This learning curve would consist of learning
about the sensors required, how they work and interface with a microcontroller,
learning about the microcontroller and writing the microcontroller code that runs on it,
learning about the protocols involved in IoT and the implementation of the same to
create the application that generates the required data [44].
This research work provides a solution for this problem by providing the data
generated from these sensors as a service to all end users of the said data locally as well

42
as remote. This would provide the analysts an abstracted source of data, free from the
complexities of the underlying infrastructure, thus letting them focus on what they do
best, i.e. working with the data. Also the dynamic resource discovery and orchestration
via control plane will help us achieve sensor being offered as service with enhanced
availability and reliability.
4.1 BACKGROUND
The basic objective behind every IoT system is to leverage the available local
data at a global scale. The availability of local data through small and cheap sensing
devices capable of sensing, monitoring variety of environmental factors like
temperature, humidity, air pollution, road traffic has been underexploited due to lack of
interoperability and reusability patterns. The advent of IoT, cloud and big data has
opened new possibilities which were never imagined since then. Every object
monitored can be made smarter and connected to cloud and offered as service to the
end users or developers or data analyst. The idea was to provide web interface through
which users can query the needed data stored in cloud like storage. As already discussed
in literature survey many commercial services exist that supports data transfer from IoT
devices to the cloud framework. Reseaches have been reported on exploiting services
like ThingSpeak and Service Science to provide the sharing of the collected data. Of
late, ThingSpeak have started support for MQTT protocol along with traditional HTTP.
But, the limitation is the user has to have skill in developing his/her application to push
the data to the cloud and thereafter it would be available for shared access. There is no
support of application support reusable API. Though this provides access to data from
anywhere, this is still a scope for improvement whereby reducing burden on analyst.
The proposed research work attempts to resolve this with service offering through
downloadable APIs. This relieves analyst and other users from burden of developing or
implementing a system from scratch.
Moreover cloud offerings like ThingSpeak operate with help of channels, but
the channels do not categorize based on sensors, but based on fields. For example, a
channel contains data from multiple sensors, like DHT11 which measures humidity and
temperature, Gas Sensor which detects gas leakage, etc., Then the data is categorized

43
as temperature, humidity and gas leakage being the fields and are provided individually
or the entire data is provided as a whole, without the categorization based on the type
of sensor like DHT11 and Gas Sensor's data. Hence the analyst would again be forced
to develop his/her own system for the generation of the required data, or hire someone.
The management of channels is offloaded to the client side i.e. the service provider does
not guarantee the constant availability. The proposed research ensures categorization
based on sensors as well as fields, which eliminates the existing limitation. Also the
management of data is taken care of from the server side through the time stamped
history database update algorithm.
Most of the services including ThingSpeak updates data every 15 seconds [28].
This may not be a dynamic or an optimized model. There are some applications which
will require more frequent updates, while others sparse updates. The proposed research
work has addressed this and has overcome by updating the data only when there is a
change involved. This gives us an optimized approach on either ways of demand
requirements.
Though it is not a serious drawback but many frameworks provide only spline
charts, which is addressed in the proposed work to provide customized visualization
through line charts as well as pie charts, depending upon the type of sensor.
Also, many of the existing open source IoT platforms or API’s will demand a
minimal coding knowledge, which is eradicated in this proposed research work by
providing the data needed to the end user directly. Many of the open source IoT
frameworks often do not reveal how long the data is being stored in the servers. But
the proposed research work have achieved transparency in this regard by providing the
data from the point at which the system was deployed and provide a timestamp for
every record so that the analyst knows when the data was added.
Many more community oriented platforms like SenseWeb [17], Global Sensor
Network, SensorBase [19], IrisNet [20] and Semantic Sensor Web [21] have been
established which allowed users to share the data from varied data sources. But these
platforms are not developed with IoT in mind.

44
SenseWeb, a Microsoft’s creation [17] provides a generic platform to share,
query and visualize sensor data. SenseWeb provides various tools for data owners and
data users to publish and subscribe the data respectively. SensorMap is a geographical
web interface provided by SenseWeb to query the needed data and get the visualization
of the same.
Global Sensor Network (GSN) [18] offers a general-purpose infrastructure
which can be programmed based on user needs as against usual collection only model
from a central repository. The GSN middleware infrastructure attempts to address
heterogeneity by integrating heterogeneous sensor networks and this is achieved by
deploying the GSN middleware on any computer which is interested in interacting with
one or more sensor networks.
SensorBase [19] is centralized data storage to log sensor network data in a blog
style. SensorBase not only provides way to store and access data consistently to users
but also maintains. It is also referred as “slogging data” to denote sensor log and to
provide a blog like structure.
IrisNet [20] (Internet-scale Resource-Intensive Sensor Network Services) aims
at providing a sensor web which can be accessed from anywhere, anytime fulfilling the
requirement of an IoT based system. This attempt provided multitude of sensors openly
accessible to users from all walks of life. But, this module suffers the constraint of
proprietorship.
Semantic Sensor Web (SSW) [21] enables interoperability and advanced
analytics for situation awareness and other advanced applications from heterogeneous
sensors. The sensor networks these days can measure almost everything on earth. The
unaddressed gaps between various proprietary heterogeneous networks have created a
new problem of “data isolation”. Though everything is available, but because of the
lack of open framework standards, the fullest exploitation has not happened at its best.
This has lead to reinventing the wheel by various sectors, which need to be
addressed. SSW achieves interoperability by providing meta-data along with the
contextual information essential for situational knowledge. It achieves interoperability

45
more suitable for heavyweight internet based systems and its implications with resource
constrained devices are not explored to its depth.
All of the above-mentioned frameworks provided on-demand resource sharing
and facility for developing value added services but the issue of interoperability was
not addressed fully. Semantic Sensor Web is an exception which addresses
interoperability, but employs additional metadata to achieve it adding a bit more
complexity to an already constrained system. Hence this research work attempts to
achieve interoperability in simpler terms by using topic registration model, abstracting
the complexities about the co-existing nodes/devices. Zhang J et al. developed a
federated platform for mobile data centric service development and sharing as an
attempt to address interoperability through virtualization [22]. The issue in their
proposal is they have abstracted the virtual sensors or nodes either to represent an
average or group of sensors as temperature, humidity and noise. This approach has
drawbacks like it would indulge more cost during sending if the readings of any one of
it changes very rarely or if any one of the reading is faulty then the whole set has to be
resent. Also, this model requires the developer or user to write a script which is capable
of parsing the received data to suit his/her needs.
Silvia Santini and Daniel Rauch proposed Minos (Message Identification and
Online Storage) - a generic tool for sensor data acquisition and storage as part of
Desthino (Distributed Embedded Systems Online) project [23]. It is a java based
software tool hence it is lightweight and portable. The limitation is that it can interact
only with TinyOS supported motes making it platform dependent. The user apart from
mentioning the message type the tool should listen to, he or she is also expected to
provide the java class representing the incoming messages. This java class generation
again needs MGI (Message Generating Interface) a TinyOS utility.
Sensor Data Service defaults in Windows 10 [24] delivers data from a variety
of sensors, but this service has to started manually by the users but is based on a
proprietary operating system Windows 10.
Having described all these frameworks and APIs capable of offering sensor data
as service in wide variety of ways, the point most of the approaches missed was to
justify on optimized ways of reaping data from billions of sensors. Collecting and then

46
creating solutions from data is nothing new. What is important is defining rules of
optimized retrieval and ease of access. Hence this research proposal not only discusses
methodology to achieve sensor data as service, but also highlights optimized ways of
achieving it and also highlighting scenarios to describe who can use and how much
benefits it can offer. This research proposal gives insight of how the message is packed,
period of data collection, error handling and providing appropriate visualizations for
each sensor data.
Thus, this proposed research work attempts to address all the aforementioned
issues as to reduce the learning curve the data analysts or other users have to undergo,
to provide categorization based on sensors, better visualization and removing the
dependency of any coding skills or hardware knowledge required to create the
application that generates the data.
4.2 PROPOSED MODEL
This research work realizes the need for a bridge between the worlds of apps to
world of devices. This is achieved in existing systems through request-response model.
But this model is handicapped in many instances when the network is down or
specifically suffers in IoT based scenarios where there is need for data to
communication whenever a change happens. Hence this research work aims to propose
event collaboration model as against existing request response model implemented in
testbeds. The user who is interested in sensor service needs to request the proposed
testbed in order to access the sensor they are concerned. The idea formulated here is
data as service as against sensor as service in literal sense, for the fact that sensor is all
about data. Hence the user requests for service from the testbed. The existing testbeds
data is not up to date, unless queried, in other words it needs continuous polling. So the
users request is mapped to a query and it is targeted towards the interested sensor and
the data is sent back as response. This adds up complexity considerably enough on
inclusion of more interconnected services. This is followed in existing testbeds, but
what this proposed research work intend is event collaboration model whereby the
event is triggered only when there is a change in the data and the data is stored in the
database which can be queried up on. In other words, event collaboration is a model

47
which does not require being provoked to speak (i.e. send data), it will speak
automatically when there is something new to convey (i.e. any change). For instance,
whenever there is change in temperature sensor, the data is pushed to, irrespective of
the need for request. Thus when a user demands, the query need not travel all the way
till sensor, update to database server and return back the response to user, but instead
read directly the already ready existing data. But in case of issue in the network
connectivity, there is chance of working with stale data. The issue also exists in REST,
where the query fails, but this needs to be addressed. Hence, there is a watchdog timer
set to a threshold to initiate a check message, in case of no event reported on prolonged
time.
The proposed system will contain a number of sensors and the data generated
from them will be stored in a database. The system is meant to be maintained by the
service provider to ensure a constant source of data. The analyst would only have to log
in to the system with his credentials, and can use the data generated from the sensors
via the interface. The sample update from the sensor is shown in Figure 4.1 and
visualizations of the data generated from the sensors in the form of graphs are shown
in Figure 4.2 and Figure 4.3.
Figure 4.1 Sample record database displayed in the Web UI

48
Figure 4.2 Visualization of DHT11’s temperature data
Figure 4.3 Visualization of DHT11’s humidity data
The interface will also let the end users download the entire history of data
generated by the sensor in CSV (Comma Separated Variable), JSON (JavaScript Object
Notation) and XML (Extensible Markup Language) formats as shown in Table 4.1

49
Table 4.1 Example of CSV, JSON & XML data generated by the interface
Format Example
CSV "timestamp","celsius","fahrenheit","kelvin", "humidity"
"2018-10-22 20:24:44.844621","23","73","296","60"
"2018-10-22 20:24:54.753128","22","71","295","50"
.
.
.
"2018-10-22 23:23:35.697389","23","73","296","60"
JSON [{"timestamp":"2018-10-22
20:24:44.844621","celsius":"23","fahrenheit":"73","kelvin":"296","hum
idity":"60"},
{"timestamp":"2018-10-22
idity":"50"},
.
.
.
{"timestamp":"2018-10-22
idity":"60"}]
XML <?xml version="1.0"?>
<dht11>
<row>
<timestamp>2018-10-22 20:24:44.844621</timestamp>
<celsius>23</celsius>
<fahrenheit>73</fahrenheit>
<kelvin>296</kelvin>
<humidity>60</humidity>
</row>
<row>
</row>
.
.
.

50
<row>
</row>
</dht11>
4.2.1 Sensors
The implemented system uses, but is not limited to the following sensors. A
DHT11 Digital Humidity and Temperature sensor was used for measure the humidity
and the temperature of the environment. A rainfall sensor is used to categorize rain
falling on it into “No rainfall”, “rainfall” and “Drenching rainfall”. A MQ-2 gas sensor
is used to detect the presence of any flammable gases in the environment. A color sensor
is used to determine the color of the light incident on the surface of the sensor.
4.2.2 Sensor Clients
Sensor clients are open source boards to which sensor units are hosted. The
sensor client was implemented using open source boards like Arduino Uno R3, and the
MQTT client code is uploaded onto it which will implement the proposed algorithm for
the sensor client. More sensor clients can be added to the system and more sensors can
be interfaced with the same to increase the variety of sensors for which the data is
provided to the end user. An option is available in the user interface which will allow
the end user to request the addition of any sensors that are not currently available in this
system. The proposed system consists of multiple sensor clients. Each sensor clients
consist of multiple sensors interfaced to a microcontroller. For every sensor Si ∈{S | 1
≤i ≤n}, an MQTT topic of the format “data/Si ” is assigned. The reading from the sensor
is sent as the payload of the message on this topic. There are some sensors, such as a
MQ2 gas sensor, which will measure only one parameter, and there are also sensors
which can detect multiple parameters, such as a DHT11 Digital Humidity and
Temperature sensor. The DHT11 temperature can detect two parameters temperature
and humidity.

51
Figure 4.4 Experimental prototype for sensor client.
In such cases the value of both parameters will be sent on the same payload and
the message broker will receive the message and parse the payload to extract the value
of the individual parameters. The microcontroller runs a MQTT client code that
publishes the sensor data on the appropriate topics to the MQTT protocol broker. The
experimental prototype for sensor client is shown in Figure 4.4.
4.2.2.1 Algorithm for Sensor Client
Let S be a set of sensors and P be a set of Parameters for every sensor. For every
sensor Si ∈{S | 1 ≤i ≤n} there exists a Parameter Pj ∈{P | 1 ≤ j ≤ m) }. The proposed
algorithm for sensor client module is provided herewith. Figure 4.5 illustrates the
communication model for sensor client.

52
For every sensor 𝑺𝒊 ∈ {S𝑖(1, 𝑛)} 𝑡ℎ𝑒𝑟𝑒 𝑒𝑥𝑖𝑠𝑡𝑠 𝑎 𝑃𝑎𝑟𝑎𝑚𝑒𝑡𝑒𝑟 𝑷𝒋 ∈ {Pj(1, 𝑚)}
Figure 4.5 Communication model for sensor client

53
4.2.3 Brokers
There are two brokers in this system. One is a MQTT protocol broker that
coordinates the publishing and subscribing of messages on various topics amongst
various clients simultaneously. Other broker is a message broker which subscribes to
the protocol brokers for every sensor topic and receives the message as and when the
sensor client sends the data. The payload of the message is parsed to extract the value
of each parameter, and is then updated in the database creating an archive of the sensor
data, which acts as the source of data for the users. Each sensor has its own table in the
database. The MQTT protocol broker used in this system is the Mosquitto MQTT
protocol broker [26] that runs on a Raspberry Pi 3 model B [27], clocked at 1.2 GHz
with four cores, and 1GB of RAM. The Raspberry Pi is an inexpensive minicomputer
that is capable of running a full-fledged operating system. The OS used in the Raspberry
Pi is the Raspbian Jessie, which is an open source OS provided by the Raspberry Pi
foundation. The message broker is a Python script that runs on the Raspberry Pi.
4.2.3.1 Algorithm for Message Broker
Let S be a set of sensors and P be a set of Parameters for every sensor. For every
sensor Si ∈{S | 1 ≤i ≤n} there exists a Parameter Pj ∈{P | 1 ≤ j ≤ m) }and a table in the
database named Si, which has columns Timestamp followed by a column per Pj. The
proposed algorithm for message broker illustrates the functionality carried out to parse
the parameters of respective sensor data. Figure 4.6 illustrates the conversation flow
between the protocol broker, message broker and the database.

54
Figure 4.6 Conversation flow between the protocol broker, message broker
and the database
4.2.4 User Interface and Database
The end user of the data interacts with the system only through the UI. There
are several types of UI that can be developed for this purpose. It can be a smart phone
application, or a desktop application or a web UI. This research work uses responsive

55
web UI so that it can be accessed from any device that has a web browser. Once the
user logs into the UI with their credentials they will be provided with a webpage that
displays the most updated record for each sensor with its timestamp, and appropriate
visualizations for each sensor. The interface also allows for the archived data of each
sensor to be downloaded in CSV, JSON and XML formats.
The user interface of this system is developed using PHP and deployed using
Apache. It is a responsive web user interface that can adapt to any screen size, and this
user interface can be accessed by any device on the world that can support a web
browser, covering laptops, desktops, smartphones and many more.
The database used here is Maria DB. The web UI and the database is hosted
using XAMPP on a laptop running Windows 10 clocked at 2.8 GHz with 8 cores and
16GB of RAM. The UI and the database can also be hosted on web hosting sites such
as Hostinger. Visualization of the sensor data has been implemented using the Google
Charts API.
The public IP Addresses of the Raspberry Pi and the laptop are linked to a
hostname using a Dynamic DNS service called No-IP. The public IP address of the web
UI and the protocol broker are mapped to a hostname with a dynamic DNS service
called No-IP and the appropriate ports are forwarded in the router to ensure they are
available to access from the outside network, thus allowing the service provided by the
system to be accessed from anywhere via the Internet.
4.2.5 Methodology for Data Flow and Storage
As mentioned previously, each sensor in the sensor client is given its own topic.
This section explains in detail the reason behind the proposed choice.
Let us consider a scenario where in the sensor client publishes data in only one
topic and will append the readings of all the sensors as a single message and publish it,
and that there is only one table that stores the data of all the sensors. The sensor client
would continuously take the reading from all sensors and keep publishing it in the same
topic and the message broker would have to parse the message and upload it into the
table that contains the data for all the sensors. This is not an efficient solution

56
considering sensors whose readings hardly change, especially those residing inside a
controlled environment, as the records will have the same redundant readings on
different timestamps.
An alternative for this would be to publish the data on the topic only if there is
a change in the readings of the sensor, by storing the previous reading in the sensor
client, and comparing the new reading against it. If the sensor client were to publish the
message only if the readings of all the sensors were different from their previous
readings, then it would result in the changes of some sensors not being updated,
especially if the sensors were reading parameters independent of each other like
temperature and gas leakage. Hence the sensor client would have to publish the message
if there is a change in the reading of any one sensor attached to it. The message broker
would then receive the message, parse it and update the values in the table.
By using separate topics for each sensor, the sensor client can publish the
readings on each sensor’s topic, only the readings of that sensor changes. The message
broker would then have to receive the messages from individual topics and then update
the readings in the table. Since there is only one table for all the sensors, the rest of the
fields that correspond to the values of other sensors would have to be kept null, which
is of no use to the analyst. Therefore, each sensor has its own table in the database. This
solution will also result in a considerably less number of records for sensors. The proof
for the same is illustrated in Table 4.2. The major concern here is the number of
unnecessary messages and records required for those sensors that hardly update.
This work uses scenario 4 as its data flow [113] and storage mechanism. This
not only helps in reducing the number of messages and records, but also proves to be
the most helpful in the event of a reading error in the sensor.
If there is an error in reading the parameter from the sensor, in cases 1 and 2,
the client would have to wait till the error is cleared or send the message with an error.
The former will affect the updation of readings of other sensors, and the latter will not
be useful to the analyst. In case 3 and 4, the sensor client can wait till the error is cleared
and then publish the reading on the sensor’s topic when the error gets resolved. Since
case 3 uses a single table, it would affect the updation of readings of the other sensors
in the event of an error. Case 4 would not update a record in the table in case of an error,

57
and will not affect the readings of the other sensors in any manner in the event of an
error. Table 4.2 is the sample set of 10 consecutive readings to demonstrate the impact
of various scenario based approaches. Table 4.3 provides the scenario based
comparison table, which clearly shows scenario 4 (case 4) outperforming the other
approaches.
Table 4.2 Sample set of 10 consecutive reading
Reading Number Sensor 1 Sensor 2 Sensor 3
1 10 15 30
2 10 15 30
3 10 15 30
4 10 15 31
5 10 15 31
6 10 15 31
7 10 15 31
8 10 15 31
9 10 16 31
10 10 16 31
11 11 17 32
Now let us compare the number of messages and number of records involving
sensor 1 which has updated only after 10 consecutive readings.
Scenario 1: Sensor client publishes as and when the reading comes, single topic.
Scenario 2: Sensor client publishes only upon change in any sensor reading, single
topic.
Scenario 3: One topic per sensor and message is published in that sensor’s topic only
upon change in that sensor. One table is provided for all its sensors.
Scenario 4: One topic per sensor and message is published in that sensor’s topic only
upon its change and one table per sensor to store the readings.

58
Table 4.3 Scenario based comparison table
Scenario Number of messages Number of records
Scenario 1 11 11
Scenario 2 4 4
Scenario 3 2 4
Scenario 4 2 2
The table structure for sensors with a single parameter is shown in Figure 4.7
and for sensors with multiple parameters is shown in Figure 4.8a-b.
TIMESTAMP PARAMETER 1
2017-03-23 18:24:34.484941 Gas Leakage
Figure 4.7 Structure of the table for sensors with single parameter.
TIMESTAMP PARAMETER 1 PARAMETER 2
2017-03-23 18:24:34.484941 Temperature Humidity
Figure 4.8a Structure of the table for sensors (DHT11) with multiple parameters
TIMESTAMP PARAMETER 1 PARAMETER 2 PARAMETER 3
2017-03-23 18:24:34.484941 Color_RED Color_GREEN Color_BLUE
Figure 4.8b Structure of the table for sensors (Color) with multiple parameters
Let us consider a sensor that has multiple parameters, such as a color sensor. It
can be used to detect the color of light that is incident on it. It has three parameters red,
green and blue. If the incident color is red, then the value of the red parameter will be
the greatest amongst the three. The readings of the three parameters will be appended
and published as the payload of the color sensor’s topic if there is a change in at most
one parameter. The message broker will receive the message, parse it and update the
table accordingly. If there is an error in reading any one of the parameters of such

59
sensors, the message won't be published because a record with missing parameters is
useless. Let us consider the same color sensor; the incident color cannot be determined
with only the values of the green and blue parameters.
There are no two consecutive records in the table for each sensor exactly the
same. The end users are safe to interpret that for the time in between the two consecutive
records, there was no change in readings from any parameter of the sensor and work on
their analytics accordingly.
4.2.6 Experimental Setup
The testbed comprising of sensor clients, actuator clients and platform with
various sensors and actuators is designed, configured and has been successfully
implemented. Figure 4.9 is the snap shot of a part of the setup. The snapshot shows a
router, 2 sensor clients, sensors and actuators.
Figure 4.9 Experimental setup of the proposed system (sensors interfaced with
sensor client and connected to the Router)

60
4.3 RESULTS AND DISCUSSION
4.3.1 Event Collaboration vs. Traditional Request Response
The testbed is implemented only using open source platforms. The experiment
was conducted using both event collaboration and traditional request-response models,
and the empirical results have shown that the event collaboration model out performs
traditional request response model in terms of response time and latency. The
experiment was repeated 100 times and the necessary graphs are provided in Figure
4.10. The results clearly shows that the proposed model request response time spans
less than 1 sec, where as the existing methods spans between 1 to 7 sec.
Figure 4.10 Event collaboration model vs. traditional request response model
4.3.2 Change Driven Per Topic Model
Applying all the scenarios to the sample data set, it was very clear that scenario
4 provides optimum results. Thus, adopting scenario 4 the proposed approach (one
MQTT topic per sensor parameter and one table per sensor), there is no excessive
unused payload, no excessive computational cycles as individual parameters have
individual MQTT topics. getParameterj() function would have to subscribe to the topic
only once, get the payload and return it without any parsing. Figure 4.11 shows the

61
updation time via one MQTT per parameter takes less time to update when compared
to all sent in one (800ms)
Figure 4.11 Comparison on updation time: Approach 4 outperforms
The experimental set up is developed to prove as part of the proposed research
objective as to measure the impact of polling which shows the following observations.
The setup updated value to global variable at the rate of 2 to 8 messages per second
varying with respect to sensor. It is observed that the data receiving rate/sec was as
follows: Gas sensor – 3.0182/s, Rainfall sensor – 3.0147/s, DHT11 – 2.0825/s, Color
sensor – 7.5236/s.
These values getting updated into global variable goes waste for the API user
and reduce the processing speed. Single table for all sensor data with the one parameter
per topic scenario, will lead to null values in more parts of table. This occurs because,
only one sensor data will be received from sensor client at that particular instance and
other sensor data will be null as primary key for all the tuples is timestamp. This
increases the table size three times (for 4 sensors) than the normal table size.
Consecutively, search time will increase. Figure 4.12 shows the Gas sensor table
updation time.

62
Figure 4.12 Gas sensor table updation time
In the existing research models, considering 4 sensors, in approach 1 to 3, the
search time would be four times greater because of single table. The proposed research
with approach 4 uses separate tables for sensors, thereby achieving O(log n) from O(log
4n). The search is based on the timestamp which is the primary key. The searching data
in index dataset will have O(log n). The dataset without index have to be done with
linear search, which is O(n). The proposed approach is better because n is less compared
to other whole data sets. All the tables are O(log n) as every table has index as
timestamp. "sensor_data" is table with all the sensor and parameter in single row
n=339885. "_history" tables are from the database. "colorsensor_history" n=209385,
"dht11_history" n=49275, "gassensor_history" n=66619, "rainfall_history" n=66964.
Thus, if a user is interested in only dht11, he needs to search among 49275 records as
against 339885. Moreover, any sensor detail needed, one needs to search n times the
same database which increases the time complexity further, which is avoided in our
proposed model.

63
Figure 4.13 Sensor database entries
4.3.3 Updation Metrics
Another issue in single table for all sensors is it will lead to null values in more
parts of table. This occurs because, even if sending sensor data on change is adopted, it
will not favor any saving. In worst case, if one sensor data changes at every instance of
time among n sensors in each sensor client available, only one data will be received per
sensor client at that particular instance and other sensor data will be null as primary key
for all the tuples is timestamp. This increases the table size three times (for 4 sensors)
than the normal table size as shown in Figure 4.13. Consecutively, search time will
increase.
Table 4.4 shows the rate at which the data is sent from the respective sensors.
The table illustrates the readings observed on 100 trials for four different types of
sensors and “All” indicates all data sent together from a sensor client.

64
Table 4.4 Message receiving and updation rate
DHT11 Gas Color Rainfall All
317.437 266.4 110.083 265.663 800.1444
561.532 307.75 209.149 312.674 801.555
313.203 376.047 150.834 370.033 801.7971
583.769 253.145 133.257 267.263 801.5025
268.063 297.061 207.817 300.017 810.586
482.755 283.738 199.788 325.684 794.1052
283.813 323.528 157.914 299.85 801.7758
773.377 342.705 142.386 350.767 803.0154
341.708 290.435 150.98 259.122 799.3412
658.502 417.475 177.076 431.457 802.6984
316.85 349.795 261.072 537.545 801.584
607.54 589.053 271.621 420.903 802.1688
308.817 318.722 80.573 283.403 801.4493
609.042 434.723 94.041 450.752 801.1879
299.324 274.672 95.261 257.303 801.8593
741.066 265.934 88.131 283.329 801.5407
359.56 283.572 112.35 288.178 801.8848
891.423 286.013 108.11 294.453 801.5117
399.917 295.564 160.714 263.744 801.0125
583.27 312.763 116.928 320.639 801.1978
299.587 332.237 108.029 343.818 801.5061
558.565 282.602 89.302 255.62 802.1981
308.712 282.509 106.63 283.845 802.0165
632.553 234.403 82.645 258.614 802.5508
283.062 323.822 85.645 307.351 802.1474
Average
Rate/sec
471.3379 320.9867 140.0134 321.2811 801.6935
2.12162 3.115394 7.142171 3.112539 1.24736
Thus, with the average time taken computed and with the help of the script it
was observed the number of messages which gets updated to the database varies notably
in the last column which is approximately 1 message per second. It is the least compared
to individual entry model. Figure 4.14 shows the snapshot of the database showing the
table content for DHT11 sensor.

65
Figure 4.14 Snapshot of the database showing the table content for DHT11
sensor.
4.4 CONCLUSION
In conclusion, the entire system is implemented successfully. No two
consecutive records in the table are the same. By using this service, the end users of the
data generated from IoT systems do not have to implement the systems that generate
the data analyzed by them, and thus avoid an unnecessary learning curve. Since the UI
is available for everyone to use, those who wish to get the sensor data only need to
register to the system with the required credentials and start viewing the most updated
reading from the sensor on the website, use the visualizations for a better understanding
of the data, and download the archived data in a CSV, JSON or XML format and start
using the same in their analysis tools directly.
The service provided in this system caters to the end users of the data for the
time being. It reduces to a great extent the expectation on the analysts to learn the
hardware and the software that goes into developing these IoT systems. Still there are
many traditional software engineers developing applications for their customers who
do not know (rather not expected to know) the details of the hardware that goes into
making an IoT system. A service that abstracts this complexity involved with

66
developing IoT applications is provided to them so that they can develop IoT
applications by undergoing a considerably smaller or nil learning curve.
A service can also be provided that targets academicians and industrialists which
allows them to port their own code onto a microcontroller platform provided by this
system, thus providing a remote testbed to work with. This can come in handy for
people who cannot afford certain microcontrollers, or for those people the
microcontroller is not available where they work at, or just need something to provide
a proof of concept and the list of uses goes on.

chapter 4.pdf

Recommended

Recommended

More Related Content

Similar to chapter 4.pdf

Similar to chapter 4.pdf (20)

More from Sami Siddiqui

More from Sami Siddiqui (20)

Recently uploaded

Recently uploaded (20)

chapter 4.pdf