![](bg3.png)
developments. The main features of these devices
are displayed in Chart 1.
Device
Clock
speed
RAM-Flash Features
Oracle
Sun SPOT
400
MHz
1Mbytes-
8Mbytes
Capable of
running
HTTP
MEMS
IC Iris
8
MHz
8Kbytes-
128Kbytes
Java or
nesC
lan
ua
es
Arduin
o Uno
16
MHz
2Kbytes-
32Kb
tes
Sensor
flexibilit
Chart 1: Device layer components relevant data.
The device layer is conceived as a Wireless
Sensor Network with the following components:
a) Base station/Sink, which is directly connected
to the device that has the web browser and the GUI
installed and running. Base station/Sink must be
capable of managing information at the application
layer, as HTTP requests will have to be attended by
it and sent to the devices that cannot handle
information at layers as high as this. Since this node
will behave as a bridge between the HTTP and the
IEEE 802.15.4 domain, most of the petitions can
involve obtaining data of different nature. Among
the already mentioned devices, Sun SPOT Base
station/Sink usage is mandatory here, for it is the
only device present in our proposal with a HTTP
client. Besides, as it must be always attached to a
computer to be powered, it remains unaffected by
energy issues typical of Wireless Sensor Networks.
b) Slave nodes, which are connected to the Base
station/Sink wirelessly by using standard IEEE
802.15.4. These nodes receive the requests that are
meant to be answered by them; the requests will be
sent by the Base station/Sink as soon as there is a
petition at the web browser-enabled device. One
very important feature of Slave nodes is that they
can notify several issues that they may be suffering
from; RRAP has a specific PDU that will be sent
from a Slave mote to the most powerful-emitting
node if it detects any performance strangling issue
(for example, the battery is almost completely
depleted). It must be noted that although nodes are
physical devices, roles are purely made up by
software, and their functionalities can be transferred
from one node to another. According to the
capabilities of the used devices, roles can be either
activated if they are dormant (a more efficient option
if energy consumption is taken into account) or
being programmed Over-The-Air (OTA
programming). In this case, either Sun SPOT motes
or MEMSIC Iris ones can be used, as application
layer features are not required at this part of the
topology. Having equipment from different vendors
communicating to each other at the same level can
be a feature especially prone to interoperability
issues: as it is known (Akribopoulos et al., 2011)
there may be incompatibilities due to payload sizes
or addresses lengths, regardless of claiming that they
are all using the same standard, as IEEE 802.15.4.
Fortunately, any trouble that may be encountered
should have been solved before by the RRAP
implementation, and the work done at that point will
be interesting to be considered for future
interoperability challenges.
c) Auxiliary sensing devices. Nodes are made by
actual devices that have several built-in sensors and
actuators used for information provisioning;
nevertheless, if they can be expanded so as to supply
some information of different nature, then the end
users will have more information at their disposal.
The system capacities can be improved by using
electronic devices with low capabilities, as the only
requirement for them will be measuring data and
delivering it to its requester, without any other need
of routing it anywhere. Consequently, available
interfaces of the nodes can behave as ports for
external data coming from other sensors and/or
actuators alien to the node. More specifically,
Arduino Uno boards are a very suitable option for
this challenge; their capabilities are low enough to
guarantee that they will not require a huge amount of
power but, at the same time, will be able to store any
small program –or sketch, as they are referred to-
able to retrieve data. Provided that the needed
elements –photoresistors, thermoresistors, etc- are
available, obtaining readings from them can be done
by plugging any element to a breadboard, mapping
power references (power supply and ground) to the
breadboard and getting the element reading as an
analog or digital input for the Arduino Uno,
provided that the pin mapping has been previously
programmed. As displayed in Figure 2, an Arduino
board can be turned into a sensing/actuating device;
in the shown case, a switch is used to change from
one sensor to another and to the actuator, thus
having a LED, a photoresistor and a thermistor
taking turns to execute their actions whenever the
switch is pressed. In the proposed system, either
cabling to a port available at a node or, as shown in
Figure 2, adding a 802.15.4 XBee communication
module can be used if a mote is wanted to be
augmented with an Arduino board -as it may come
in handy to test a service of similar nature in devices
placed differently, and soldering may not be
AProposalforanInternetofThings-basedMonitoringSystemComposedbyLowCapability,OpenSourceandOpen
HardwareDevices
89