A Value Added Device Gateway Architecture for

Sensors and Actuators

Michael Glienecke
#1
, David Lewis
#2
, Declan OSullivan
#3

#
KDEG (Knowledge and Data Engineering Group)
School of Computer Science and Statistics
Trinity College Dublin, Ireland
1
glienecm@tcd.ie
2
dave.lewis@cs.tcd.ie
3
declan.osullivan@cs.tcd.ie

Abstract As the Internet of Things (IoT) becomes more and
more reality, the need for a straightforward, logical and easy to
implement connectivity between devices (sensors and actuators)
and applications, often even without knowing details about each
other, becomes crucial. In addition, there is demand from the
business side to provide not only protocol conversion (as this has
been done for quite some time already) but in addition added
value.
To address these needs, this paper proposes a new design for
device gateways, which provide easy connectivity to the gateway
as well to sensors and actuators using standard protocols and
also provide added value. Targeted at environments where more
emphasis is put on controlling devices (by means of setting values
in actuators and / or running workflows) than to just visualize
data like in environmental sensor data environments, different
demands and needs, and therefore design issues arise. Speed
requirements for the availability of data, the correctness of data
according to pre-defined rules, device scan cycles and reactions
to data events all influenced the proposed design. Provisioning of
computed values on the fly (virtual sensor data) and mechanisms
to provide autonomous control of the data (filtering / adaption /
rejection of invalid or non-calibrated data, etc.), as well as
workflows, based on trigger definitions, are provided in the
design as added value to the user and consumer.
Therefore the proposed gateway design acts as a script based
data source which combines sensor data with operational logic,
therefore allowing consumers of the gateway to focus on the
application layer instead of focusing on integration and / or data
issues. With the workflows running in the gateway based on
trigger definitions an autonomous control of the environment can
be achieved.
The structure of the paper is as follows: section II discusses
related work. While section III provides an overview of the
proposed architecture, sections IV through to section VI focus on
particular features. Section VII then describes the reference
implementation and section VIII the conclusions and next steps.
I.

INTRODUCTION

To enable an easy, reliable and as simple as possible device
(can be any sensor or actuator, which can be accessed using
any kind of protocol) integration into any kind of application,
an interface towards the device must be realized and / or
utilized. In service oriented architecture (SOA), this will most
likely be implemented as a device-gateway of some kind,
which acts as a service providing data sources (the sensor
values) and data destinations (the actuator values to be set).
Currently this is done by existing gateways mainly to shield
applications from the according to my own experience -
very often cumbersome, time-consuming and error-prone
tasks (usually associated with developing and / or
implementing the physical communication details and
protocols involved in device communications. This is mainly
due to limited debugging possibilities (often low level
hardware protocol analysers are needed), testing interfering
with protocol timing constraints and in general the
reproducibility of events which leads to lengthy and therefore
cost intensive development cycle. Therefore quite a lot of
development potential in order to provide additional value (in
terms of additional benefits over the core functionality a
device-gateway has to offer in terms of connecting and
sending data to and from devices) to the consuming
applications is lost.
Additionally device gateways - to varying extents - provide
an abstraction layer of the underlying device infrastructure as
well as the physical and logical connection of the device(s) to
the gateway as an added functional feature to the applications
using them. This abstraction layer could range from simple
knowledge about device characteristics like measurement
units, physical connection protocol to use, real-world device
coordinates and so on, to full meta-information (like which
device is associated with which device and in what way) as
suggested in [11]and [12].
As there are many different usage areas and application
environments for such device-integration, usage-patterns for
consuming applications as well as device-integration and
device-gateway architecture changes. These usage areas range
from hard-real-time industry automation or SCADA-systems
(SCADA =Supervisory control and data acquisition), with
monitoring and controlling client-applications to Web based
applications, portals or mashups (see [3]) mainly used for
data visualization.
Several approaches currently exist for device-integration:
one approach advocates the direct integration of devices into
the consuming applications using REST (or other http-based
communication protocols) (see [3], [5], [15], [16]), a second
approach promotes the usage of de-centralized smart
gateways ([13]), a third approach proposes the use of
gateways with a centralized repository (Pachube [6] and
International Journal of Sensor and Related Networks (IJSRN)
Volume 1,Issue1 , February 2013
http://ijsrn.info/article/IJSRNV1I104.pdf
31
SenseWeb [7] as the main players) and optionally data storage;
a fourth approach (mainly people with a cloud computing
background) goes a step beyond and tries to integrate
everything utilising a centralized service-bus using software
as a service (SaaS) approach.
Device gateways communication from the consuming
application to the gateway, is currently achieved mostly using
either REST or SOAP and from the gateway to the device in
whatever software and / or hardware-protocol that is necessary.
In addition there is a tendency to have REST-based
communication (especially in the area of Wireless Sensor
Networks) between gateway and device as well, which is
mainly due to the fact that these (very often more modern)
devices are capable of TCP/IP communication as well as
being programmable with some web server component to
handle and process REST-requests.
Considering all of the above, several device gateway
solutions have been developed (see related work), which are
very often similar in some ways (communication protocols
mainly) and totally dissimilar in others (data storage, data
handling mainly), reflecting technological and conceptual
changes over time.
Now, with new emerging terminologies and concepts like
Internet of Things (see [12] for an overview in a larger
context) or globally inter-connected sensor-systems ([9]), the
demand is rising for a new gateway architecture, which
provides new approaches to integration, communication and
data handling, as well as providing added value for consumers.
This demand for new approaches, together with the increased
demand from the business side for efficiency gains as well as
(completely) new business processes or even business models
(see [14]), lead us to propose a new Value Added Device
Gateway Architecture and reference implementation, which
is described in this paper.

In summary, our architecture addresses the challenging
requirements through several features:
Consuming application get offered the device gateway as
a reliable service (SOA-style) with several choices by
which communication method the integration and
communication can be achieved. Not only REST, like
most gateways, but SOAP or optionally alternative
approaches (OData being an example) are available by
means of a pluggable communication layer in the
architecture.
More than plain WSN or smart devices (like mobile /
smart phones) issues are considered by the gateway
despite the current enthusiasm in these areas (and in IoT
in general). Rather the design of the architecture also
addresses classical industry control devices (e.g. PLCs)
and devices connected using very low-level and
sometimes old-fashioned approaches (like RS-485, RS-
232) as well as devices capable of a high degree of
independent intelligence (e.g. SunSPOT, .NET Micro
Framework Devices). Therefore all devices using any
communication method can be connected (once a device
integration module for the gateway has been developed).
On the fly data analysis can be provided by the
architecture to prevent invalid or illegal values (e.g. mis-
readings, de-calibrations) to propagate up to the
application layer by means of triggers and filters in the
gateway (either as scripts or compiled modules). This
feature makes an application easier to develop since less
logic for data errors has to be developed as well as the
data intelligence being kept in the gateway. In addition
this feature removes the need, like other gateway
solutions, to store and then retrieve / filter values later, as
illegal / invalid values are never considered at all.
Furthermore many implementations would publish such
wrong or invalid values as well, thus leaving the
consuming application responsible for a proper handling
(e.g. not issue an alarm, etc.).
Permanent reliable data provisioning to the gateways
consumers is guaranteed through the architecture by
means of providing last usable values and / or default
values, thus shielding the device status (offline, downtime,
illegal readings, de-calibrations, etc.) from the application.
With most gateways when a device is offline this means
no current (in terms of actual) values can be retrieved,
which usually means waiting for a timeout for the
application. In contrast with the proposed gateway
architecture default values (or last usable value) can be
served immediately.
By providing calculated (virtual) values (e.g. running
mean) thus values derived by computation from
dependent values to the application, the application has
to worry less about these computational or data-intense
values. Normally an application interested in (for
example) the running mean, has to keep the value
internally and must never lose any update in order to keep
the mean synchronised. With our proposal this work is
done at the gateway and the application can just request
the value, being assured that it is correct.
Finally a feature is included in the architecture to provide
an optional ability to include workflows running on the
gateway directly in the process of data acquisition (in the
form of a trigger with an attached workflow which is
fired, when the trigger is hit). This feature achieves
control closest to the actual device as possible (as no
asynchronous monitoring applications are needed) and an
autonomous gateway can be easily configured in this way.
In contrast, in most existing gateway implementations a
consumer would listen to any data changes and then
whenever the scanning cycle is given react to a data
change. In this way critical events might be lost as well,
as perhaps a critical data value going unnoticed.
II. RELATED WORK
Device gateways are neither new, nor is their underlying
technology and principal functioning, research has been on-
International Journal of Sensor and Related Networks (IJSRN)
Volume 1,Issue1 , February 2013
http://ijsrn.info/article/IJSRNV1I104.pdf
32
going for 30+ years in this area (for a comprehensive
overview see [19]). The current debate is mostly about the
manner in which integration of the device gateways into
application environments is undertaken (with either REST or
WS* being the two main candidates).
While the WS* camp was very active and pre-dominant
during the early 2000s where WS* was the approach to do
SOA, now REST is forcefully making a point due to ease of
integration, more straightforwardness and especially because
REST uses the WWW the way it was intended not by means
of http as a transport protocol, but as a resource access (for
discussions see [2]). Another indicator towards this trend for
REST is that WS* based gateways are usually not specifically
designed for devices, but more for general integration, where
devices are just a special kind of data source. In contrast, pure
device gateways like sMAP [5], Pachube [6], SenseWeb [7]or
[13] are REST-based (or use a different protocol altogether).
A very neutral comparison of both approaches can be found
in [3] which briefly depicts scenarios where either approach
would be the better one. As for us, both approaches are valid
and useful and therefore have their respective place, the
decision in our proposed architecture is to support both of
them equally in addition to others like OData initially. More
can be added by means of additional presentation layer
modules later.
An alternative approach to connect devices by means of
gateways and / or directly to applications, has been proposed
in [9] by Microsoft. Here the devices connect to the MS Azure
Service Bus (a reliable, secure messaging infrastructure in the
cloud guaranteeing delivery), sending events when new data is
propagated and the consumers act on behalf of these events
(they are listening for them) by specialized actions. The
message bus (any messaging infrastructure could be used
actually) is the connection between data producers (sensors)
or device consumers (actuators) and data consumers
(applications) without additional logic (while it would be
technically possible to modify the message internally). As
these message bus based architectures are very useful for very
large scale device integrations with thousands of devices
connected to hundreds of thousands of consumers like in
home energy control monitoring systems, especially due to
their scale out approach and nearly unlimited growth
potential, they have a huge complexity as well as high
infrastructure needs and costs. To see a possible example with
the servers and infrastructure involved (and thus complexity
and cost derivable) in such an environment refer to [9] and
[10]. These complexities and costs combined with the
complexity of operations and integration, e.g. for the
Microsoft approach any device participating must be able to
communicate in https, and with our goal in mind of achieving
a simple straightforward operational model, we decided not to
include this approach in the architecture.
Connecting devices to the gateway directly by WS*
technologies as proposed in [22] would be an option, but
considering the very tight integration this implies and the deep
API-knowledge needed on the device-side (due to the SOAP
structure) we opted against incorporating such an approach.
The burden on the device by the SOAP handler (if present at
all) and the additional handling logic needed is quite
significant especially compared to simpler and easier
protocols. This approach is by and large used in environments
where the participants do not change, devices are capable and
powerful enough (and thus expensive) to be able to
communicate in this manner and therefore the benefits of this
tight coupling can be utilized.
Our approach in communication with the device (when
speaking about WSN and smart devices) would be REST
(which could be considered state of the art) or CNDEP (see
[23] and for usage scenarios [24]) as a binary, non-verbose
alternative to it. Other approaches like DPWS (limited WS*
implementation for devices) are still there, but have not gained
much momentum and perhaps will not, due to their
complexity and implications on the device and the consumer
as well, which is enough reason to not consider it at the
moment. In addition to these advanced devices, connecting to
more classical devices can be done (like most device gateways
do here sMap would follow a similar approach) by means of
specialized modules which are dynamically loadable, usable
and provide the necessary protocol support (e.g. R3964, L1 or
H1 for Siemens PLC).
III. DEVICE GATEWAY SOFTWARE DESIGN
Several core requirements (deriving either from current
state of the art, best practice or experience and literature)
were considered when designing the gateway architecture:
The device gateway shall be usable for control- as well as
visualization-biased environments to make it as versatile
as possible. Therefore support for sensors (read) and
actuators (write) must be present
Integration of the gateway shall be possible by REST and
/ or SOAP and optionally different protocols to allow any
integration model needed. The protocol shall present the
internal simple, straightforward API in an efficient way to
allow for fast integration without a big learning curve
A layered architecture with presentation, control, device
abstraction and data storage layer, where each layer can
be utilized on a different physical instance (thus
providing scalability and exchangeability and following
modern design standards). In addition, to make
adjustments easier, a pluggable module approach
(configuring e.g. the data access layer) is required
Support for PUSH-, PULL- or mixed model to retrieve
sensor data must be present to allow device
communication optimized for the kind of device as well
as its usage scenario. In addition this allows to utilize
specific device features like e.g. local storage as well as
battery cycle considerations (communication is quite
battery cost intensive)
Support for trigger and filter chains in the gateway so that
values for sensors can be filtered / modified in different
stages of the consumption process in the gateway and to
guarantee that only valid values are used internally and
served to the consumers. This is an important requirement
as it simplifies the consuming application as well as
International Journal of Sensor and Related Networks (IJSRN)
Volume 1,Issue1 , February 2013
http://ijsrn.info/article/IJSRNV1I104.pdf
33
allows to specify a contract for the value ranges which is
obeyed
Support for computed sensor values (virtual sensors)
which allows dynamically generating new data based on
existing values (e.g. running mean, running counters, etc.).
With this requirement one of the main added values of the
gateway is achieved as now the virtual value has the same
data quality as the direct sensor reading from a physical
sensor, thus allowing the consuming application to treat
both equal and from the same source.

Considering these assumptions the following architecture
model was designed:

Fig. 1: High-Level Layered Architecture of the Device Gateway
In the presentation layer the communication with the
outside world in terms of applications (either data consuming
and / or controlling) is handled using REST and / or SOAP
(.NET Remoting could be used as well when connecting
directly to the core).
The control layer contains the device gateway core with
the triggers / filter chain handler as well as the dynamic value
calculation, which both work together with the sensor value
management as a core data management structure (for
historical as well as actual data).
The data layer contains the actual data access code as well
as data house holding tasks (e.g. purging of expired or invalid
data, backup of old data to an external store, etc.).
The device abstraction layer contains the scanner tasks for
those devices, which are to be scanned (PULLed) and the
handlers for the device communication as such (either PUSH
or PULL).
In a simplified picture only considering typical usage
scenarios there are the applications that communicate with
the device gateway. In the gateway the handling of the
centralized logic, together with the data storage and the virtual
sensors (data computation) is done. The devices are then
connected using the supported and provided (but extendable)
communication protocols.
DeviceGateway
REST
SOAP
Application1
Application2
Applicationn
Sensor1
Sensor2
Sensor3
Sensor4
Sensorn
1 2 3
Actuator1
Actuator2
Actuatorn
SPI
REST
CNDEP
RS485
ControlLogic
DataStore
VirtualSensors/
ComputedData

NewXXX

Fig. 2: High-Level Block diagramof the Device Gateway Functionality
In the next sections the specific and novel features of the
design are being discussed in more detail.
IV. VIRTUAL SENSOR VALUES
One of the most unique and value added features of our
gateway architecture is the ability to generate virtual sensor
data (computed data) based on other (virtual) sensor data in a
dependency checked way. Thus a value, which exists only
virtually, is based on other values (dependent upon them).
When a virtual value is evaluated these dependencies (which
could be virtual values as well) are evaluated at that moment
(when accessed) as well, resulting in an always correct and
accurate delivered value.
These virtual sensors, whose value calculation would have
to be done outside of a device gateway by most other gateway
implementations (and then not be accessible as sensor values
at all, but as alternative associated data), are very important.
This is important as very often dynamic values, based on
existing ones, are needed and not all data, which is required to
calculate the value, can or should be transported over the
network. So as an example - it does not make sense to
retrieve once every minute the last 10 samples for a sensor
from a database (as most systems only provide the actual last
value in memory) to dynamically determine the running mean
or the difference to a standard value in an external system.
The calculation can and should be done on the gateway as all
data is present there (so no data movement and additional
external logic is needed). In addition some values might only
arise (or make sense) as a reaction (trigger) to a change of
another value.

As an example the following scenario could be imagined:
A temperature sensor generates data every second
Average, min and max temperature values could be
defined as virtual sensor values, based on the last 10
physical values of the sensor (which are kept in
memory on the gateway). So whenever the temperature
sensor delivers a new value the virtual sensor values
would also calculate new values.
sd System Ov erv i ew
Presentation Control Data Storage Device Abstraction
DeviceGateway Core
Data Storage
+MySQL
+SQL Server
+XML file
+ DataStorage
Device Scanner Tasks
(PULL)
Dev i ceProtocol Handl er
+CNDEPDevice
+RESTDevice
+RS485Device
+SPIDevice
+ Devi ceCommuni cati on
Application Interface
Virtual Value
Computation
Trigger / Filter
Evaluation
Appl i cati onCommuni cati onHandl er
+RESTHandler
+SOAPHandler
+ Communi cati onHandl er
Runti meEv al uati on
+DllCode
+DotNetAssemblyCode
+PythonCode
+RubyCode
+ Executabl eBl ock
SensorValueManagement
DataCleansingTasks
Sensor
Actuator
WorkflowExecution
Workfl owExecuti on
+WindowsWorkflowFoundation
+ Workfl ow
handle requests
PUSH data
PUSH
data
PUSH data
store / retrieve
trace
trace
Scan &Retrieve
International Journal of Sensor and Related Networks (IJSRN)
Volume 1,Issue1 , February 2013
http://ijsrn.info/article/IJSRNV1I104.pdf
34
A virtual sensor value with 0 or 1 could be defined,
which delivers 1 (true) if the value exceeds 300 Kelvin.
So the virtual value would be recalculated every time
new data from the physical sensor arrives

Internally the virtual sensor values would be defined as
triggered by a change in the temperature sensor value.
Whenever the sensor values change, the triggers fire and the
corresponding values are automatically updated as well. This
could as a way of automated control trigger a workflow as
well, which sends a signal to an actuator to close (for example)
a valve.
Optionally a virtual value can be declared as evaluate on
query which means that for each request the value is
computed anew to yield the actual data value.
To be independent of a data change (which might never
happen) cyclic tasks, which just re-evaluate the virtual values,
are provided as well.
Whenever new physical data arrives, the sensor definition
(the current value part) is updated, which causes a triggering
of the trigger evaluation and value calculation process. This
process, by means of the virtual sensor value evaluation
engine, then calculates a value and delivers it to the process
that uses it as input value for the virtual sensor.
In addition the virtual sensor update task performs updates
for those sensors which have a timer based auto-update
specified as well.
In order to use an as flexible as possible approach, the
definition for the virtual sensor value evaluation must be
enabled to use:
Evaluations in a dynamic loadable external
executable (like a .NET assembly) which would be
the fastest execution method
Evaluations of an internal script in a dynamic
language like Ruby or Python
Evaluations based on SQL (so as to easily use
existing data from the database)
V. FILTERS
With filtering it is possible to inspect, alter and possibly
reject values that do not conform to the specification of the
particular device or application environment. Each value from
a sensor is passed through several sets of filter chains (which
can be different for each sensor) and each filter can fully
modify the value or reject it.
These sets of filter chains are for the various stages a value
can be in: newly arrived, ready to be used for computation for
dependent values or ready to be stored. This is necessary as
e.g. a value might need filtering in terms of min / max checks
after arrival, whereas before being used for computation some
adjustments (e.g. rounding) should be implemented.
The filters themselves can be, like the virtual sensor
evaluation, in any of the provided environments (compiled
assembly, script or SQL), Python as a scripting language
perhaps being the predominant candidate.
VI. PUSH / PULL-MODEL FOR SENSOR READING
As sensors can have different characteristics (latency, time
it takes for a value to change, importance of the value for the
application) as well as intelligence (in terms of ability to
store data locally and / or to transmit on its own behalf),
different models to connect them to the gateway must be
present. While a temperature sensor for the outside
temperature barely needs reading more than once a minute
and thus can be comfortably pulled (or even store the values
locally and thus be queried just once a day), a temperature
sensor controlling an acids temperature in a chemical process
might need a reaction time within several hundred
milliseconds and could even be in an alarm state which needs
immediate propagation.
The device gateway therefore supports PULL-mode with
different pulling frequencies for sensors (configured when the
sensor is registered) and PUSH-mode where the gateway
reacts to data from the sensor. In addition a bi-directional
mode is present which allows for PULL, but a PUSH (in case
of e.g. an emergency) as well.
To provide mass transport of data (when a sensor has e.g.
collected hundreds or thousands of samples) a burst mode in
PULL is present as well which is just a bulk import.
VII. REFERENCE IMPLEMENTATION
The reference implementation, which is available as open
source, was implemented using C# in the .NET 4.0
environment using available free of charge products (like SQL
Server Express as a database), and so all parts of the solution
can be run without using royalty based software (except
Windows as such here Mono might be an alternative). For
Python and Ruby the corresponding packages IronPython and
IronRuby were used.
As a handler for the WS* and REST-requests the WCF
(Windows Communication Foundation) infrastructure in IIS
was utilized to have an easy, declaration based (contract first)
development environment, which is much easier to maintain
and extend. Should the need arise this can be changed easily
to a more classical request-handler-loop approach.
All implementation specific parts can be exchanged as
dynamic handlers are used which would e.g. allow to
exchange SQL Server to mySQL, and so on.
Initial tests, were done in several areas with the following
preliminary results:
4 different .NET Micro Framework boards were used
successfully for REST-based communication to the
gateway (CNDEP is currently in testing) with data
being PULLed, PUSHed and bulk loaded; so device
communication and server-side scanner tasks work
fine
A simulator for setting and getting values shows that
the gateway (running on modern year 2011 server
hardware) is capable of handling more than 100,000
sensors with 100 data items in memory for each with
more than 10 billion sensor readings in the database
and still delivering values to 1000 clients in parallel in
2.6 msec as average to 16 msec as maximum / request
International Journal of Sensor and Related Networks (IJSRN)
Volume 1,Issue1 , February 2013
http://ijsrn.info/article/IJSRNV1I104.pdf
35
WS*, REST and OData as client protocols work
reasonable fast and stable
Triggering (using Python and .NET Assembly tests)
works in the range of 10 milliseconds even for
complex trigger chains and value evaluation on
request (using Python) shows a decrease in response
time (for simple to moderate scripts) of around 10%
allowing this to be used for many sensors as well
Running the server in an extended simulation over
several days with billions of set / get operations
(device and client) showed no memory leaks /
performance degradations
VIII. CONCLUSION AND FUTURE WORK
In this paper we have shown a working architecture for an
extendable device gateway, capable of being integrated into
applications environments by means of WS* (SOAP), REST,
OData and other (future) protocols, which provides additional
value by means of dynamically computed values, triggers,
filters and autonomous control using workflows.
Especially by using CNDEP and / or REST as a
communication protocol from the gateway to highly
intelligent devices with independent computational power
(e.g. .NET MicroFramework boards, SunSPOT, J ava-based
devices or Smart Devices in general), a powerful option for
the future is present.
After having the initial reference implementation ready, the
next steps involve several extensions, implementations in
reference environments to gain critical insight into perhaps
existent problems and needed enhancements
Various timing measures especially in the trigger / virtual
value evaluation and workflow execution have to be made to
make sure that a stable environment exists which executes in a
determinable way and gracefully handles errors and problems.
Another area of experiments will be the broader device
integration (scanner tasks / general device tasks) as well as
handling data internally to the server.
The option to load mass data from external sources, not
generated by sensors, but used for computations (e.g. cost of
energy per kWh as a basis to generate power cost as a virtual
value; a demand shown by [18] as well) has to be
implemented.
Another major task for a future improvement will be the
extension of the internal data types to cover more sensor types
(getting closer to SensorML or perhaps even adopting it) and
the provisioning of additional sensor protocols to make sensor
integration (especially industry sensors) much easier. This
includes pre-configured additional scanner tasks and enhanced
configuration in this area as well.
REFERENCES
[1] Aberer, K., Hauswirth, M. & Salehi, A., 2006. A Middleware for Fast
and Flexible Sensor Network Deployment. In VLDB 2006. VLDB
2006. Available at:
http://portal.acm.org/citation.cfm?id=1182635.1164243 [Accessed
October 14, 2010].
[2] Schramm, P. et al., 2004. A Service Gateway for networked sensor
systems. Pervasive Computing, 1(3), 66-74.
[3] Pautasso, C., Zimmermann, O. & Leymann, F., 2008. RESTful Web
Services vs Big Web Services. In Proceeding of the 17th international
conference on World Wide Web. International World Wide Web
Conference.
Available at: http://portal.acm.org/citation.cfm?id=1367606 [Accessed
September 29, 2010].
[4] Guinard, D. & Trifa, V., 2009. Towards the Web of Things Web
Mashups for Embedded Devices. In WWW 2009. Available at:
[Accessed August 19, 2010].
[5] Stirbu, V., 2007. Towards a RESTful Plug and Play Experience in the
Web of Things. In International Conference on Semantic Computing.
IEEE Dawson-Haggerty, S. et al., 2010. sMAP - a Simple
Measurement and Actuation Profile for Physical Information. In
SenSys 2010.
[6] Pachube - data infrastructure for the Internet of Things. Available at:
http://www.pachube.com/ [Accessed March 21, 2011].
[7] Kansal, A. et al., SenseWeb: An Infrastructure for Shared Sensing.
Available at:
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4354151
[Accessed November 9, 2010].
[8] Open Data Protocol (OData). Available at: http://www.odata.org/
[Accessed March 21, 2011].
[9] Vasters, C., 2012. Internet of Things - Using Windows Azure Service
Bus for ... Things! [WWW Document]. Using Windows Azure Service
Bus for ... Things! URL http://msdn.microsoft.com/en-
us/magazine/jj133819.aspx
[10] Internet of Things - A Smart Thermostat on the Service Bus [WWW
Document], 2012. . URL http://msdn.microsoft.com/en-
us/magazine/jj190807.aspx
[11] SENSEI - Home [WWW Document], 2012. . URL http://www.sensei-
project.eu/
[12] Internet of Things - Architecture IOT-A: Internet of Things
Architecture [WWW Document], 2012. . URL http://www.iot-
a.eu/public
[13] Trifa, V., Wieland, S., Guinard, D., Bohnert, T.M., 2009. Design and
implementation of a gateway for web-based interaction and
management of embedded devices. Submitted to DCOSS.
[14] Haller, S., Magerkurth, C., n.d. The Real-time Enterprise: IoT-enabled
Business Processes, in: IETF IAB Workshop on Interconnecting Smart
Objects with the Internet (March 2011).
[15] Prehofer, C., van Gurp, J ., di Flora, C., 2007. Towards the web as a
platform for ubiquitous applications in smart spaces, in: Second
Workshop on Requirements and Solutions for Pervasive Software
Infrastructures (RSPSI), at Ubicomp.
[16] Debaty, P., Caswell, D., 2001. Uniformweb presence architecture for
people, places, and things. Personal Communications, IEEE 8, 4651.
[17] Extended Environments Markup Language: EEML [WWW Document],
2010. . URL http://www.eeml.org/
[18] Dawson-Haggerty, S., Krioukov, A., Culler, D.E., 2012. Experiences
Integrating Building Data with sMAP ( No. Technical Report No.
UCB/EECS-2012-21). Electrical Engineering and Computer Sciences
University of California at Berkeley.
[19] Aslam, M.S., O Regan, E., Rea, S., Pesch, D., 2009. Open Framework
Middleware: An Experimental Middleware Design Concept for
Wireless Sensor Networks. Presented at the MUCS2009.
[20] Debaty, P., Caswell, D., 2001. Uniformweb presence architecture for
people, places, and things. Personal Communications, IEEE 8, 4651.
[21] Vazquez, J .I., De Ipina, D.L., Sedano, I., 2007. Soam: A web-powered
architecture for designing and deploying pervasive semantic devices.
International J ournal of Web Information Systems 2, 212224.
[22] Priyantha, N.B., Kansal, A., Goraczko, M., Zhao, F., 2008. Tiny web
services: design and implementation of interoperable and evolvable
sensor networks, in: Proceedings of the 6th ACM Conference on
Embedded Network Sensor Systems. pp. 253266.
[23] Kakanakov, N., Stankov, I., Shopov, M., Spasov, G., 2006. Controller
Network Data Extracting Protocoldesign and implementation, in: Proc.
CompSysTech.
[24] Spasov, G., Stankov, I., Petrova, G., n.d. WIRELESS REAL-TIME
GATEWAY (WRTG) FOR EMBEDDED DEVICES.
[25] Guinard, D., Trifa, V., Mattern, F., Wilde, E., 2011. Fromthe Internet
of Things to the Web of Things: Resource-oriented Architecture and
Best Practices. Architecting the Internet of Things 97129.
International Journal of Sensor and Related Networks (IJSRN)
Volume 1,Issue1 , February 2013
http://ijsrn.info/article/IJSRNV1I104.pdf
36