xxx

1. 67
CHAPTER 5
ACTUATOR, PLATFORM AND API AS SERVICE
There are many of a technology as large and as pervasive as IoT. To develop
these applications many software developers of different knowledge bases and skill sets
are involved. These developers should not be expected to have the hardware knowledge
required to work with and develop IoT applications that can get sensor data and can
control actuators over the internet and such applications can be deployed anywhere
according to the will of the developer. This research work provides a solution to this
problem by providing a development environment cum testbed to the developer or user
to exploit as his/her need demands.
Virtualization is the process of making optimal use of the available resources,
and the development environment provided here achieves virtualization of sensors and
actuators by ensuring their reusability from different places around the world over the
internet.
There are developers who have the skill set of developing microcontroller codes.
There are several reasons as to why the developer may not have microcontroller at
his/her disposal. The person may not be able to afford one, or the one possessed by them
can be damaged, and they need something to work with meanwhile or one may need just
to experiment on a temporary basis. The sensors needed by them may not be available
in their country or may be too costly to work with. The software developer may not
know (and is not expected to know) how to interface the sensors with the
microcontroller, some sensors may be too sensitive to minute fluctuations of current and
may need a special circuitry to stabilise the current. For example, there are breakout
boards designed specifically to deliver the correct voltage and current requirements of
an ESP8266 Wi-Fi module, and such breakout boards may or may not be available to
the developer depending upon his location. A solution to this problem is proposed here
by providing a testbed to the developer as a service over the internet. The testbed will

2. 68
have all of these requirements taken into consideration and interface the sensors,
actuators, platforms appropriately and the software developer can concentrate on
developing the microcontroller code without worrying about these details.
Simulation tools like Fritzing/123dcircuits may look like a tempting solution for
the problems mentioned in the previous paragraph but at the end of the day the code is
not being deployed on the actual microcontroller, the simulation tools simply mimic the
functionality of the hardware are and are not the actual thing, for example you cannot
expect the simulation tool to send an SMS from the GSM module you have added in it.
This work provides two services to developers, one being a development
environment provided in the form of an API through which sensor data can be accessed
from anywhere in the world and actuators can be controlled from anywhere in the world.
The other service provided to the developers is a testbed provided in the form of a
microcontroller platform as a service over the internet.
One major motivation behind this research work is that neither of the users of
this system mentioned earlier in this section should be expected to know how to work
with the hardware and embedded systems associated with IoT. Software developers
creating end user IoT application for their clients must not be expected to go through the
learning curve of the hardware associated with it and their time is better utilized in
designing out the business logic of the application [114] . Other motivations include
socially relevant issues pertaining to the availability and the cost of the sensors and
actuators. Academic institutions can utilize this testbed to teach students without the
burden of significant costs associated with the hardware or its availability.
5.1 BACKGROUND
In most of the research papers, the IoT testbeds are mostly extensions of WSN
beds. The point is most of the boards employed are proprietary, there by leading to
obvious interoperability problems [57]. The main aim of these testbeds is to check how
various network level protocols and applications perform and not developed with IoT in
mind. Repeatability or reusability was huge challenge as the environment keeps varying

3. 69
due to various external activities or human intervention. The initial thought process was
to rectify the issues listed, but later understood that it is almost obsolete to think of sensor
networks in terms of motes, a new paradigm shift of open source everywhere made to
rethink and develop the proposed architecture.
In 2008, researchers attempted to incorporate testbeds in to education domain,
through which they brought out the importance of real experimental testbeds over
simulated testbeds. These authors were proactive in hinting on the importance of real
testbeds over virtual for various reasons including lack of real data. They have discussion
about how proprietary tools like LABView or internet ready languages like Java or Web
services can be employed. Also, there is huge complaint towards complexity and biasing
towards large software vendors or integrators and not supporting open source
implementation. Some amount of research was also found reported in developing IoT
based device profiles for web services [115]. Also researchers have attempted IoT based
e-healthcare for students [116].
In late 2010, attempts have been made by researchers to stress on the importance
of unified approach for IoT and the importance to overcome the limitation of
fragmentation. They have also emphasized the need for standardization [69].
A. Gluhak, S. Krco, M. Nati, D. Pfisterer, N. Mitton, T. Razafindralambo [37]
has explored the existing difficulties in evaluating IoT solutions under real external
situations which is mandatory to decide the feasibility of the system. They have
identified few gaps and provided some directions towards the requirements and facilities
which are paramount importance in rolling out a research testbed. These authors have
boldly signified the importance and to think beyond the WSN. As far now most of the
testbeds revolve around intra-net extended to outside world but not in its real sense of
inter-net of things. This was because of so many proprietary WSN in island. The real
challenge is in how the developed IoT solutions which were once tested in these kinds
of testbeds will cope with the scaling in real world.
There has been research reported on lab based experimental testbeds and
importance of real time users in the loop. They have implemented with TelosB motes,
which makes it proprietary [74].

4. 70
The authors S. Nikoletseas, M. Rapti, T. P. Raptis, K. Veroutis [117] have
extended their previous work of Smart building testbed with several sensor motes, where
they have attempted to reinforce IoT perspective to their existing test-bed. They have
added Smart phones, Raspberry Pi’s and NFC tags. Again, the underlying limitation
happened to be the choice of commercial mote, TelosB.
In 2013, researchers have developed a device, which facilitates conventional
appliances to join IoT framework via CoAP. The authors have brought out the intensity
of work needed in developing unique resource to support specific device. They have
agreed on the underlying hardware limitations and the need to optimize them. They have
chosen TinyOS and have admitted the need for great extension in the CoAP
implementation of TinyOS.
Authors C. M. Angelopoulos, O. Evangelatos, S. Nikoletseas, T. P. Raptis, J. D.
Rolim and K. Veroutis have presented an IoT testbed for Smart Buildings [83] following
an architecture that enables a scalable integration of crowd-sourced resources. Their
focus is on mobile crowd sourcing with various incentivized plans for motivation. In
order to enable the devices for direct communications with each other without the need
for intermediate web services, they have developed a networking device that acts as a
protocol bridge. This device is built around a Raspberry Pi micro-computer equipped
with a USB wireless card and a TelosB sensor mote. Its role in the testbed is to set up
both a wireless sensor/actuator network and a local Wi-Fi while providing connectivity
with the Internet. Consequently, by relaying traffic between the two radio interfaces and
performing IPv4-to-IPv6 translation, the protocol bridge enables the ad-hoc
communication among the smartphones and the control cubes.
There were researches reporting the cross benefits of simulation and real
testbeds. The substantiation being simulation tools provides scalability at ease when
compared to real testbeds [118] . They have used Contiki operating system which is a
lightweight protocol with µIP and µIPv6. This requires a manual reconfiguration of
buffer size, data rate and traffic priority. They have provided QoS provisioning
functions, but still the interoperability of these virtual simulators with the real physical
setup and also their impact on performance [119] on complete IoT based systems is still
pale. Their work may guide to some extent, to choose among the existing development
frameworks and test before adopting the same to be deployed in real field, as IoT cannot

5. 71
be based on mere virtual or simulation based setup. These can only help to the extent of
testing a prototype, before venturing in real time deployments. Moreover, it has to be
kept in mind the percentage of approximation that may have gone in and how to carefully
mitigate that in real scenarios.
Hence attempting to consolidate, this research work have investigated testbed
papers of varied goals be it educational or industrial or testing or development, all of
them had one issue in common, they all used proprietary hardware or software or both.
This left the major challenge of interoperability unattended. And also the specific issues
involved in handling output based devices like actuators have not been addressed in
depth. Thus this research work attempts to provide a testbed as proof of concept to
demonstrate that use of open source boards and technologies takes care of the prime
requirements of IoT (as stated by many authors) like heterogeneity, interoperability,
reusability appreciably well.
5.2 INSTANCE BASED ACTUATOR AS SERVICE
Actuator being the output device, complicates the task of conceptual
virtualization i.e. creating instances of an actuator will not solve parallel usage of the
resource. It could be achieved either through sequential allocation model like round
robin or an algorithm employed to find its usage pattern and allocate dynamical, the
concept employed in single core CPU’s. Actuator being offered as service creates
complications of conflict and overloading with requests beyond the capacity it can
handle. This work considers and resolves all the issues that will pop up with the help of
proposed algorithm.
5.2.1. Actuator Clients
Actuator clients are devices which are meant to host the set of actuator units.
This research work has employed open source boards variants of Arduino like Arduino
Mega 2560. Actuators in general use digital pins or PWM pins which most of the
controller boards have in plenty.

6. 72
Figure 5.1 Actuator client-an experimental prototype
The implemented system uses, but is not limited to the following actuators. They
are LED, RGB LED, Buzzer, Fan, LCD and a GSM module. The LED can turn on and
off and the implemented system has two instances of the LED. The RGB LED is capable
of emitting light of any color in the visible spectrum. The buzzers produce sound of
different levels and uses PWM pins. There are two instances of the buzzer in the
implemented system.
The GSM module uses the SIM900A chip and can make calls and send messages
to other mobile phones and landline numbers and interfaces with the Arduino Mega via
the serial communication port. The LCD used here is a 16 x 2 LCD and can display
messages on it. It is interfaced with the Arduino Mega in the 4-bit mode. An option is
available in the user interface which will allow the end user to request the addition of
any actuators that are not currently available in this system. The circuit diagram of the
Actuator Client is shown in the Figure 5.1 depicts an experimental prototype for actuator
client. Figure 5.2 illustrates the sequence of steps when accessing the requested actuator
instance from an available actuator client.

7. 73
Figure 5.2 Request response of actuator client
5.2.2 Resource Requisition Algorithm
As mentioned earlier, due to the nature of actuators it is difficult to exploit the
same level of reusability that can be achieved out of sensors.
Hence each actuator has several instances and each instance can be controlled
by an application at a time through the resource requisition mechanism so as to ensure
that the microcontroller controlling the instance does not end up responding to the
actuation commands from multiple sources. The acutatorLock plays a crucial role in
this resource requisition mechanism.
The actuatorLock is used to ensure that multiple users don't control the same
actuator instance at the same time which can lead to havoc in the system. Each actuator

8. 74
module is provided with a function to get an actuator lock, actuator.getLock() which
checks if an instance of the actuator is not locked, and if available will create a unique
actuator lock value and store it in a common table for the actuator in the database and
returns the value at the end of the function. The actuate function,
actuator.actuate(actuatorLock, actuationCommand) will check the actuatorLock value
and determine the instance of the actuator to which the command has to be sent and
sends the actuationCommand as the payload on the corresponding topic for the actuator
instance. The function to release the actuator lock, actuator.release(actuatorLock),also
accepts the actuator lock as a parameter and clears the corresponding lock value in the
table. Each actuator will have its own table and each instance of the actuator will have
its own record. The table will consist of columns lockValue and instance number.
5.2.2.1 Algorithm for Resource Requisition
The algorithm attempts to resolve two prime issues namely conflict resolve and
request optimization. Many existing works have attempted to resolve the conflict using
hit or miss model as there is no ways to stop multiple requests being directed to the
existing actuators. There is no such methodology or analysis which has performed an
analysis of how many requests are being targeted on an actuator, which can practically
accept only one request at a time. If measured the percentage hit or miss, it will give an
idea of percentage of success that the actuator is actually actuated. The proposed
algorithm for resource requisition illustrates as how the payload interprets to actuation
command.
For every actuator 𝑨𝒊 ∈ {A𝑖(1, 𝑛)} 𝑡ℎ𝑒𝑟𝑒 𝑒𝑥𝑖𝑠𝑡𝑠 𝑎𝑛 𝑖𝑛𝑠𝑡𝑎𝑛𝑐𝑒 𝑲𝒋 ∈ {Kj(1, 𝑚)}

9. 75
Figure 5.3 Resource access through resource requisition algorithm
Thus the proposed resource requisition algorithm is created in such a way that
the quantity of actuators is counted dynamically and updated in a look up table. Every
time a request is posted to an actuator and many instances exist of the same actuator,
the underlying detail of which actuator is abstracted from the user as it will be least
interest to an end user. Meanwhile, internally the algorithm creates a lock on the
instance captured by the user. This continues till all of the actuators are captured for
use. Once the usage completed, lock is released and updated in the resource pool. Also
there is a parallel update which is made available to user about the availability of
resources if any, thereby eliminating unnecessary traffic to the unavailable resource.
Figure 5.3 shows how the resource requisition algorithm works in case of more than
one instance requested of an actuator.

10. 76
5.2.3 Platform Independent API
Application Programming Interfaces are libraries in other words which provides
an analogy to plug and play model. Many third party API’s are available for various
purposes which eases the code development reducing the burden on the developer and
providing him or her more time to focus on the business logic. It also helps avoid
reinventing of wheel, increases reusability and abstracts unwanted details.
This work aims at developing optimized API’s which can be offered as service
to users. It can also be offered as a third party offering to facilitate data analyst, novice
developers and users ease of exploiting the service.
The proposed model is achieved through implementation of proposed algorithm
which is detailed. The algorithm is categorized in to two types, one which serves the
sensor package and other the actuator package.
5.2.3.1 Algorithm for Parameter Retrieval
For every sensor Si {S | 1 ≤ i ≤ n)} there exists a Parameter Pj {P | 1≤ j ≤ m) }
and has its own getParameterj() function. Since there are n sensors and m parameters
per sensor there will be n modules with m functions per module. Client in this function
refers to the application that uses this API. The proposed algorithm for parameter
retrieval in sensor package illustrates how the demanded service is served to the user.
To get the value of a particular Parameter 𝑷𝒋 ∈ {P𝑗(1,𝑚)} 𝑜𝑓 𝑎 𝑠𝑒𝑛𝑠𝑜𝑟 𝑺𝒊 ∈
{Si (1, 𝑛)}

11. 77
The “+” in the MQTT topic acts as a wildcard to ensure that the client will
subscribe to the broker on the said topic irrespective of the value of +. This is used by
the sensor client to send the id of the reading, and is used by the message broker to
update the data in the database in a synchronized manner to avoid inconsistencies in the
data store, it does not affect the functionality of the API in any manner.
5.2.3.2 Algorithm for Modules in the Actuator Package
Every actuator has its own module with the package and has one getLock()
function , several acutate() functions depending upon the capabilities of the actuator,
and one releaseLock() function. For every actuator Ai {A | 1 ≤ i ≤ n)} there exists an
instance Kj {K | 1≤ j ≤ m}. Every actuator Ai {A | 1 ≤ i ≤ n)} has one table in the
database and each instance of the actuator has its own record thus the database contains
n tables of m records each. Each table has one column named lockValue and instance
number. The proposed lock acquire algorithm illustrate the steps involved in
implemented the getLock() API functionality. Figure 5.4 explains the sequence of steps
involved in the process of acquiring a lock.
To get a lock on one instance 𝑲𝒋 ∈ {K𝑗(1,𝑚)} 𝑜𝑓 𝑎 particular actuator

12. 78
Figure 5.4 Acquiring lock through getLock API
The function actuate(actuatorLock,actuationCommand) takes the value of
actuatorLock and the actuation command as parameters. Client in this function refers
to the application that uses this API. This function takes the value of actuatorLock and
the actuation command as parameters. Actuation command to appropriate actuator
instance is achieved through the series of steps starting from verifying valid lock value
till the publication of command via payload to the available actuator instance. This is
depicted via the algorithm for actuate() in actuation package.

13. 79
Once the actuation is complete, the lock acquired on the corresponding actuator
instance needs to be released. The proposed algorithm on lock release facilitates
releasing the actuator instance back to the pool by applying lock value reset. The
function releaseLock(actuatorLock) takes the actuatorLock as a parameter. The
function checks if it’s a valid lock value and releases the lock. Figure 5.5 illustrates that
the releaseLock(actuatorLock) API which resets the lock value to zero in order to
release the actuator back to the resource pool.
Figure 5.5 Lock release through releaseLock API

14. 80
5.3 OTA PLATFORM AS SERVICE
The testbed consists of multiple microcontroller boards with which sensors and
actuators are interfaced. This testbed also provides the microcontroller platform as a
service to the developers over the internet. This platform will be available to use over
the internet for the developer who wishes to upload the microcontroller code to the
platform. The platform can be accessed via the Web UI. By design, microcontrollers
generally do not support multiple applications running over them limiting the number
of users who can upload their code to the microcontroller platform at a time to one.
The proposed system uses a time slot basis to allow developers across the world
to use testbed. The developers have to book a timeslot with the system in advance and
are allowed to access the platform only in their booked time slots. Once the developers
log into the Web UI in the booked time slot they will be provided with an interface
through which they can write and upload the microcontroller code into the
microcontroller platform. The Web UI will also list the available sensors and actuators
in the testbed and also the pins with which they are interfaced to the microcontroller
platform.
The Web UI provides a live video stream of the testbed allowing the developers
to see the output of their code. The Web UI also provides a serial monitor similar to the
serial monitor provided by the Arduino IDE, which can be used to debug the
microcontroller code.
5.3.1 Platforms
The testbed platform consists of microcontroller platforms. Microcontroller
platforms include open source boards like Arduino Mega 2560, Raspberry Pi 3 Model
B etc., The experimental set up comprises of Raspberry Pi’s and variants of Arduino
interfaced with LEDs and buzzers, gas Sensors, DHT11 sensors etc., The live video
streaming of the platform in done via YouTube live streaming, the encoder used for the
same is XSplit_Broadcaster. Figure 5.6 gives an idea of the platform offered as service
with various sensors and actuator units interfaced to them.

15. 81
Figure 5.6 Platforms as service-a prototype
5.3.1.1 Algorithm to Access Platform as Service
The algorithm of user interaction with the testbed explains the steps involved in
order to access the platform as service.

16. 82
One of the objectives of the proposed work is to offer OTA based IoT testbed
platform as service. The proposed algorithm for platform access enables users to access
the platform through scheduled bookings, code upload and storage at testbed, result
storage at testbed, multiple code runs via background threads. The feature of multiple
code runs opens up the possibility for multi user access, thereby increasing the service
availability.
5.3.2 Experimental Set Up
The part of the experimental set up for platform as service is provided in Figure
5.7. The experimental set up is designed, configured and successfully implemented.
The set up shows as Raspberry pi, Arduino Mega, sensors and actuators which are
offered for platform as service. Figure 5.8 illustrate the slot based interaction between
user and the web UI. Figure 5.9 is the snapshot of the WebUI interface which is used
to access the platform as service.
Figure 5.7 A module of experimental setup for platform as service

17. 83
Figure 5.8 Slot based interaction between user and the web UI
Figure 5.9 WebUI interface

18. 84
5.4 API AS SERVICE
API computer programming, an application programming interface is a set of
subroutine definitions, communication protocols, and tools for building software. In
general terms, it is a set of clearly defined methods of communication between various
components. A good API makes it easier to develop a computer program by providing
all the building blocks, which are then put together by the programmer. An API may be
for a web-based system, operating system, database system, computer hardware,
or software library. An API specification can take many forms, but often includes
specifications for routines, data structures, object classes, variables, or remote
calls. POSIX, Windows API and ASPI are examples of different forms of APIs.
Documentation for the API is usually provided to facilitate usage and implementation.
5.4.1 Proposed API Service
The API is developed in Python and can be downloaded from the Web UI. It
has to be downloaded, extracted and installed using the setup.py Python script. The API
has two dependent Python libraries. The first library is the paho-mqtt library developed
by Eclipse and the second library is MySQLdb.
The public IP Addresses of the Raspberry Pi and the laptop are linked to a
hostname using a Dynamic DNS service [30] 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.
5.4.1.1 Algorithm for Usage of API Functions
API functions can be used to access various services offered by the testbed.
Sensors and actuators have been provided with appropriate API functions. If one wants
to use the services offered by the testbed, they need to download the appropriate API
package offered and access services with the provided API calls. The sensor service
can be acquired with get parameter method. But access of actuators can be achieved
only after acquiring the appropriate lock and release. The services of the proposed

19. 85
testbed are made available to users via API implementations of all the offered services.
The API implementations are grouped as sensor and actuator package to enable ease of
access. Thus the requested resources will be offered via appropriate package import.
The algorithm for API based resource requisition of sensors and actuators exemplifies
the protocol or procedure to be followed for the same. Figure 5.10 is the sequence
followed in use of API functions. Figure 5.11-5.12 illustrates the snapshot
demonstrating API download and API function usage respectively.
For every sensor 𝑺𝒊 ∈ {Si (1, 𝑛)} there exists a Parameter 𝑷𝒋 ∈ {Pj (1, 𝑚)}
For every actuator 𝑨𝒊 ∈ {Ai (1, 𝑛)} there exists an instance 𝑲𝒋 ∈ {Kj (1, 𝑚)}
Figure 5.10 Illustration of a sample API call

20. 86
Figure 5.11 Snapshot demonstrating API package download
Figure 5.12 Snapshot to demonstrate the use of sample API functions

21. 87
5.5 RESULTS AND DISCUSSION
The API is created for various actuators and sensor reads and the time taken for
execution is provided in Figure 5.13 and Figure 5.14a-5.14d respectively. The sensor
reading can be read by many at the same time. The real issue is when multiple users
attempt to access the same actuator at the same instance. This is resolved with the help
of the conflict resolve module. Every time prior to an API call, user need to call a lock
function and release after usage. In case, user forgets to release the lock, a watchdog
script resets after a specified interval. Thus, this proposed research work measured the
time taken for each acquiring and releasing lock which consumes 641.65ms (on
average). This is the extra cost (or overhead) incurred in this proposed framework to
avoid clash with other users. But in case this conflict is not resolved one device/second
will send 18244 requests (average of 100) to each actuator when sent in recursion. Any
actuation command through API takes 235ms (on average) to respond, which imply
that only 4-5 commands can only run per second even with all the requests filling in.
The percentage of success is less than 1% in existing systems without the resource
requisition algorithm void of the lock and release paradigm.
Figure 5.13 API for sensors and actuators

22. 88
Figure 5.14a API Execution time for sensors accessedlocally
Figure 5.14b API Execution time for actuators accessedlocally

23. 89
Figure 5.14c API Execution time for sensors accessedfrom remote
Figure 5.14d API Execution time for actuators accessedfrom remote
The proposed system has been implemented successfully. Figure 5.14a-5.14d
shows the execution time for all the functions provided in the API in both packages.
The execution time for functions in the sensor package include the time taken to connect
to the MQTT protocol broker, and time required to subscribe to the broker on the

24. 90
specific topic and receive the message close the connection, and return the payload as
the sensor reading. The execution time for functions in the actuator package include the
time required to connect to the database, update or read the table, and then connect to
the MQTT protocol broker and publish the command on the appropriate topic and close
all the connections. The graph shows the average execution time of each function for
100 consecutive calls. Local sensors and actuators are those that are in the same local
network as of the client executing the API. Remote sensors and actuators are those that
are not in the same local network as of the client executing the API functions. The
network hosting the sensors and actuators used an internet connection with an upload
speed of 6 Mbps and a download speed of 40 Mbps. The network hosting the client that
executed the API functions had an internet connection with an upload and download
speed of 100 Mbps. One can refer from the graph that the execution times did not cross
500 ms in either cases in either package.
The execution time for all the functions is provided in the proposed API for 100
consecutive calls. Figure 5.15 shows the snapshot of sample API call and response.
Figure 5.15 Snapshot of API call and response
Figure 5.16 shows the compilation and upload time required for different
microcontroller codes and compares the same between the time required in the Arduino
IDE and the time required in the testbed in this research work. The graphs show the
time required for different microcontroller codes in increasing order of memory

25. 91
occupied by them and one can infer from the graph that the testbed provided has
performed better for codes that occupy more than 10000 bytes of memory.
The time difference for those codes with a lesser memory occupancy has a
maximum of 4.28 seconds. The reason for this behavior is determined based on the
extent of buffering and reusability. The entire benchmarking was done with the
developer uploading the code not being in the same local network as of the testbed.
Figure 5.16 Compilation and upload time comparison between Arduino IDE and
the proposed testbed service
The compilation and upload time required for different micro-controller
codes was observed and compared the same between the time required in the Arduino
IDE and the time required in the test-bed provided in this research work. The result
shows that this research work equally performs better with increasing lines of code
upload. The observed delay of ~2s to ~4s is due to the porting of the code via remote
network and not because of the offered platform in the testbed.
5.6 CONCLUSION
The IoT service based testbed and a working platform was designed and
implemented. The system developed provides sensors, actuators and platform as service
through the indigenous API developed. The entire system is developed using open
source platforms in order to achieve interoperability, scalability and re-usability, the
prime challenges for IoT system development.

26. 92
The proposed system offers sensor data, actuator and platform as service with
novelty brought in at the level of service discovery, resource conflict, dynamic
orchestration and API. The end users of the data, generated from IoT systems do not
have to implement the systems that generate the data to be analyzed, thus avoiding
unnecessary learning curve as well. 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. Similarly, overhead in actuator command is also overcome. The API
developed have shown considerable improvement in request response time, hit ratio
(requests served vs. requests sent) and in code exports. The proposed algorithms for
resource discovery, actuator conflict resolve and orchestration have shown considerable
improvement in overall utilization performance, which the results have convincingly
illustrated.