202 Int. J. Sensor Networks, Vol. 28, No.

3, 2018

SmartData: an IoT-ready API for sensor networks

Antônio Augusto Fröhlich

Software/Hardware Integration Lab,
Federal University of Santa Catarina,
Florianópolis, SC, 88040-900, Brazil
Email: guto@lisha.ufsc.br

Abstract: Despite intense research on wireless sensor networks (WSN) in the last two decades,
programmers still do not have a cohesive and expressive application programming interface (API)
to model their applications and to connect them to the internet of things (IoT). In this paper, we
introduced SmartData, a high-level API for WSN aiming at leveraging the myriad of features available
on such networks while delivering a common abstraction for sensed data that facilitates application
development without incurring significant overhead. SmartData is enriched with enough metadata
to become self-contained regarding semantics, spatial location, timing, and trustfulness. It is meant
to be the only application-visible construct in the platform and therefore implicitly mediates all
system services, including communication, synchronisation, and the interaction with transducers
and actuators, local or remote. Reading a SmartData implies in sensing. Writing to it defines a new
setpoint for actuators. We demonstrate the concept through the automation of a solar building with
a set of SmartData in C++.

Keywords: WSN; wireless sensor network; IoT; internet of things; sensing API; application
programming interface; sensing data management.

Reference to this paper should be made as follows: Fröhlich, A.A. (2018) ‘SmartData: an IoT-ready
API for sensor networks’, Int. J. Sensor Networks, Vol. 28, No. 3, pp.202–210.

Biographical notes: Antônio Augusto Fröhlich is a Full Professor at the Federal University of
Santa Catarina (UFSC), where he leads the Software/Hardware Integration Lab (LISHA) since 2001.
With a Ph.D. in Computer Engineering from the Technical University of Berlin, he has coordinated
several R&D projects on embedded systems, including the ALTATV Open, Free, Scalable Digital
TV Platform, the CIA2 research network on Smart Cities and the internet of things (IoT), and the
Smart Campus project at UFSC. Significant contributions from these projects materialised within the
Brazilian Digital Television System (SBTVD) and IoT technology for Energy Distribution, Smart
Cities, and Precision Agriculture. He is a Senior Member of ACM, IEEE, and SBC.

1 Introduction management systems intended to handle the produced data

(Hulbert et al., 2016). We are currently connecting these
Wireless sensor networks (WSN) have been the focus of networks to the IoT, which will bring into scene many of
intense research for well over a decade by now. Several the cloud-based big data tools being used for analytics and
physical layers have been proposed, along with a myriad of machine learning (Marjani et al., 2017).
medium access and routing protocols (Huang et al., 2013; Nevertheless, most of the WSN platforms currently
Patil and Biradar, 2012). Such protocols have been made available consider sensing to be part of the applications’ duties
energy-aware (Lonare and Wahane, 2013); aggregation and and therefore do not feature an application programming
fusion strategies have been devised (Levis et al., 2004); interface (API) modelled around high-level abstractions meant
infrastructures have been enriched with location (Golestanian at exporting sensors in a ready-to-use manner for application
et al., 2017), timing (Djenouri and Bagaa, 2016), and security developers. Despite efforts such as the IEEE 1451 Smart
protocols (Granjal et al., 2015); cross-layer optimisation have Transducer Interface for Sensors and Actuators standard
been proposed (Mendes and Rodrigues, 2011; Fu et al., 2014); (IEEE Instrumentation and Measurement Society, 2007a),
operating systems have been designed to support higher-level most sensing devices still use incompatible, proprietary
abstractions (Dixon et al., 2012), along with large-scale mechanisms to mediate physical transducers. Not rarely, only

Copyright © 2018 Inderscience Enterprises Ltd.

 SmartData: an IoT-ready API for sensor networks 203

Figure 1 SmartData SI unit encoding

the I/O ports (e.g., ADC, UART, SPI, I2C) are exported at brings an overhead analysis of the proposed API. In Section 4
system-level, fully ignoring the transducers that might be we describe a case study about the automation of a Solar
connected to them. Furthermore, and even more important, Building, which was used to validate the SmartData concept
most sensing platforms also do not provide high-level means through a real IoT deployment. Section 6 finishes the work
to operate the network and to integrate it with the IoT. Duty with our final remarks.
cycling, the impact of sampling frequencies on the network,
naming and location of sensors, time-stamping, tagging,
aggregation, long-term storing, and many other tasks that are 2 SmartData
usual for sensing applications are left up to them, without much
support for interoperability from the platforms (Kumar et al., SmartData was conceived to be the primary (if not the only)
2015; Papadopoulos, 2015). abstraction used by application programmers to interact with
In this paper, we introduce SmartData, a high-level API for the physical world on a network of sensors and actuators. A
sensor networks that aims at leveraging the myriad of features SmartData is a piece of data enriched with enough metadata to
available on such networks while delivering a common, make it self-contained regarding semantics, spatial location,
consistent, semantic abstraction for sensed data that facilitates timing, and trustfulness. The semantic aspects of a SmartData
the development of sensing applications without incurring in is described using a strategy inspired by the Transducer
significant overhead. A SmartData is a piece of data enriched Electronic Data Sheets in the IEEE 1451 standard (IEEE
with enough metadata to make it self-contained in terms of Instrumentation and Measurement Society, 2007a). Each
semantics, spatial location, timing, and trustfulness. It is meant piece of data is tagged with a 32-bit type identifier designating
to be the only application-visible construct in the sensing either an SI Physical Quantity or plain digital data. Physical
platform and therefore implicitly mediates all system-level quantities are identified by the corresponding SI Unit as
services, including communication, synchronisation, and the illustrated in Figure 1. Derived SI units are expressed in terms
interaction with transducers and actuators. An application of SI basic units, as for instance Volt in the figure. Digital data
reads a sensor simply by accessing the data contained in a are simply classified at this level, with actual encoding being
SmartData through its interface. The data is automatically specific to each defined class.
updated from the network according to the parameters Besides a Value and a Unit, each piece of SmartData carries
specified at instantiation-time. Actuation happens through along the coordinates of the location where it was produced
the same interface: changing a SmartData causes messages (Origin(x,y,z)), a high-resolution timestamp identifying the
to be propagated over the network to command actuators moment in which it was produced (Origin(t)), the validity
accordingly until the new value is observed. It, therefore, bears of the data expressed relatively to the time it was produced
the notion of a setpoint for a network-wide controller when (Expiry), and a message authentication code (MAC) that can
seen as a writeable object. be used to verify its authenticity (MAC). Figure 2 depicts a
SmartData relies on the underlying run-time support SmartData from the perspective of communication protocols.
system to implement the set of protocols needed to achieve The actual encoding of SmartData attributes in a network
trustfulness, precise time synchronisation, and spatial location packet is protocol-dependent. For the TSTP implementation
across the network. For the discussions in this paper, an of SmartData, for instance, an adaptive scheme is used in
implementation of SmartData for the trustful, space-time which field lengths vary according to the deployment scenario.
protocol (TSTP) (Resner and Fröhlich, 2015) was used, Additional fields describe the encoding and protocol version
however it could have been done on top of any other run- of each package (Resner et al., 2017).
time system implementing similar features. We detail the The SmartData interface is depicted in Figure 3. Although
SmartData concept in Section 2, addressing each of its straightforward and easy to deploy, this interface encapsulates
major facets: semantic data, network abstraction, timing, a complex and powerful mechanism to abstract any sort of
georeferencing, security, and cloud integration. Section 3 sensor and actuator on the network. Instances of SmartData
204 A.A. Fröhlich

can be created using one of two constructors: the first one is first (MLLF) algorithm (Oh and Yang, 1998), such that objects
used to abstract local transducers, while the second is used closer to becoming invalid are updated first. In this sense,
to create local proxies of remote transducers. In either case, SmartData is similar to the Interface construct in the time-
the binding of a SmartData object with the corresponding triggered architecture (TTA), which is used by Actors to
transducer is done via the Transducer class parameter. Every access (eventually remote) data (Kopetz and Bauer, 2003).
transducer is supposed to declare a constant named UNIT, Accessing an expired SmartData immediately triggers an
initialised following the scheme presented in Figure 1. update. For most cases, the update operation is just a register
SmartData uses that constant to personify the corresponding read, but for complex sensors, which require calculations in
SI quantity. For instance, a SmartData object instantiated with order to produce the output data, SmartData presents the same
a transducer specifying K (Kelvin) as UNIT represents the SI limitations of TTA Interfaces: the time to update the data must
quantity Temperature. This SmartData can abstract either a be taken into account while defining the expiry.
temperature sensor or an air conditioning (i.e., a temperature We believe that requiring application programmers to
actuator). An accelerometer would be exported as a SmartData provide an Expiry for SmartData is a better option than
representing the SI quantity Acceleration bound through the requiring them to provide WCET for the Tasks that access
SI unit m.s−2 . We will now describe the two constructors in such data. Firstly, because an expiry can be directly derived
detail, returning to the remaining methods that comprise the from sampling frequencies in physical models, which are
SmartData interface in Section 2.3. widely available in the literature. Moreover, the fact that
expiry is defined per-data instead of per-task enables a
Figure 2 SmartData encapsulated in a network packet better domain decomposition. Proving the schedulability of
a system using SmartData is out of scope for this work, but
provided WCET tools are available, it would be accomplished
through the schedulability analysis of MLLF with tasks’
deadlines being derived from the expiry of the SmartData they
Figure 3 SmartData encapsulated in a network packet use. Application tasks in a system using SmartData can be
mostly aperiodic, with a periodic behaviour being implicitly
accomplished by the wait() blocking method that is used
to wait for a SmartData update. If a value different from
zero is given as the constructor parameter period, then the
associated transducer will be periodically sampled to update
the SmartData and wait() will block until the next period.
Otherwise, the object encapsulating the transducer will be
invoked on every SmartData access. Transducer objects can
also use interrupts to interact with the hardware containing
the physical transducer. In this case, their access methods
must block until new data availability is signalised through
the interrupt. Finally, accessing expired SmartData can be
2.1 Local transducers as SmartData configured to produce logs that are useful during development.
This scheme was originally modelled as the Concurrent
Local transducers are abstracted using SmartData objects Observer design pattern (Ludwich and Fröhlich, 2015).
instantiated with the first constructor depicted in Figure 3. Expiry is refreshed on every SmartData update, so the
The constructor’s first parameter, dev, is used to differentiate constructor parameter is taken as a relative value, just like
multiple instances of the same transducer available on a the period. Specifying an expiry smaller than the period
given node. The second parameter, expiry, is an innovative is invalid. If distinct SmartData objects using the same
answer to a long recurring issue in embedded systems Transducer are created with different periods, then the greatest
design: timeliness. Ordinary embedded systems usually rely common divisor is used for sampling, but wait() on each
on classic real-time task scheduling algorithms to ensure object respects the originally specified periods and so does the
timeliness. However, powerful modern microcontrollers and expiry. Dissonant periods, such as prime numbers, can impose
growing users demands for advanced functionality make it a high penalty on energy consumption and network bandwidth
difficult for developers to determine the worst-case execution utilisation and should be avoided.
times (WCET) required by most of these algorithms.1 The implicit scheduling of tasks based on the expiration
Alternatively, SmartData objects are tagged with an Expiry time of the SmartData they use does not directly affect the
representing the last moment in time their values can be used characteristics of the MLLF algorithm and therefore does not
without misleading associated computations to produce wrong imposed any additional jitter on such tasks. However, since
results. Different components, tasks, or even functions can SmartData is meant to be used in the context of the IoT,
instantiate SmartData objects bound to the same physical additional jitter certainly will be caused by the underlying
transducer with different expiry times. It is, therefore, a per- communication protocols. Therefore, expiry-based timing is
instance attribute. usually not adequate for jitter sensitive applications, which
The internal functions responsible for updating SmartData will probably find better supported on priority-based protocols
objects are implicitly scheduled using the modified least laxity such as those based on CAN.
 SmartData: an IoT-ready API for sensor networks 205

The last constructor parameter, mode, designates the region of space for a given interval of time. SmartData objects
SmartData mode of operation. Three modes are defined: matching the criteria will reply to the interest in accordance
with parameters period and fuser. A zero period means that all
• Private: The local SmartData is private to the process updates on the remote nodes will be reported, determining an
that created it. It does not get advertised to the network event-based mode of operation. Other values require matching
and therefore cannot be monitored nor controlled objects to periodically send a response every period units
remotely. of time, starting at t0 and repeating until tf . This defines a
time-triggered operation for the network. Different periods
• Advertised: The local SmartData is advertised on the
are handled just like for local transducers, so values for this
network and therefore can be remotely monitored.
parameter must be carefully chosen (see the previous Section).
• Commanded: The local SmartData is advertised to the If fuser is not provided, then objects matching the criteria
network and can be remotely controlled. will respond to the interest if they haven’t yet listened to a
response from another node. Note that this does not ensure a
The first two modes are common to many other sensing single response: hidden nodes might concurrently respond to
infrastructures. The third one, however, brings about a new the same interest. The value of the SmartData will be that of the
way to interact with cyber-physical environments. Instead last response received and expiry will be adjusted accordingly.
of sending commands to actuators, SmartData users simply If a fuser function is given, however, then all transducers
specify a new setpoint for their controllers by writing a value matching the criteria across the network will respond to the
to it. Actuators bound to the corresponding SI unit located interest. Every new response will be handed over to the
in the designated region will collectively react to reach that function for data fusion and the function’s return value will
new setpoint. It is possible to bind a single SmartData to define the SmartData value.
multiple sensors and actuators at the same time by declaring Similarly to local transceivers, remote ones abstracted as
it (ADVERTISED | COMMANDED). Nevertheless, it is more SmartData also have an Expiry. Once again, it is a client-side
usual to have multiple, independent SmartData objects bound information, so several SmartData objects acting as proxies to
to the same SI unit in the same region. For example, the the same transducer can have different expiration times. Nodes
temperature of a controlled room is adjusted by having with SmartData exported as ADVERTISED will manage proper
some Temperature SmartData objects instantiated with a response messages to match all interests. The shortest of the
temperature sensor as the class parameter and others receiving expires is used in the network packet depicted in Figure 2 and
air conditioning actuators as parameter. All these SmartData is can be used for expedite routing on the network.
abstracted as Temperature objects, they are physically placed
in the same region, they are all bound to the K SI unit,
2.3 SmartData value, location and time
but sensors would be declared as ADVERTISED, while air
conditioners would be declared as COMMANDED. Remote Independently of how a SmartData is created, three common
read requests are answered by the ADVERTISED SmartData methods can always be invoked on it: a native type conversion
in the specified region, while commands are be executed by operator, location(), and time().
the matching COMMANDED SmartData. The actual control
algorithm is implemented at the level of Transducer objects
and is out of the scope of this work.
2.3.1 Conversion operator
A native type conversion operator is provided so SmartData
2.2 Remote transducers as SmartData can be used just like the native type used to hold its
value. This operator is summarised as operator Value() in
Remote transducers are also abstracted using instances of Figure 3. The actual type depends on the N field of UNIT as
SmartData. Objects created with the second constructor defined in Figure 1. Each transducer can select the numeric
depicted in Figure 3 are local proxies to remote transducers. representation that better fits its own nature from 32-bit integer,
All the system-level procedures needed to ensure a consistent 64-bit integer, float or double.
semantic for such objects is transparently carried out by the
implementation, including communication, synchronisation,
2.3.2 Location
and scheduling. The constructor’s first parameter is used to
specify a Space-Time region of interest as: Returns the location where the data was produced. Either
the current node’s location for local transducers or the
Space-Time Region(x, y, z, r, t0 , tf ) coordinates of the remote transducer that produced the
data. Coordinates are expressed as (x, y, z) triples in a
where x, y, z designates the centre of the interest region, Cartesian system centred at the local network gateway to
r designates its radius, [t0 , tf ] designates the interest’s time the internet. This method converts such relative coordinates
interval. The interest region is used in combination with to an absolute representation whenever the gateway absolute
the SI Physical Quantity associated to a SmartData object location is known. The Earth’s centre is the default origin for
through the UNIT constant defined by the Transducer given as absolute coordinates. The Heuristic Cooperative Calibration
parameter. The instantiation of a remote SmartData implies Positioning System (HeCoPS) (Reghelin and Fröhlich, 2006)
the announcement of interest for a given SI Quantity in a given protocol can be used for this purpose.
206 A.A. Fröhlich

2.3.3 Time node Id. Thus, when a gateway receives a SmartData from the
Cloud for auditing, it searches the log for an entry comprising
Returns the time in which data was produced as an offset in the received Data P oint to recalculate the MAC using K and
µs from an Epoch. By default, this is the UNIX’s Epoch, that Id. The result is then compared with the provided MAC.
is, 00:00:00, January 1st, 1970. The precisely synchronised
clocks used to timestamp data can be accomplished using Figure 4 WSN gateway capable of handling SmartData
the speculative precision time protocol (SPTP) (Resner and (see online version for colours)
Fröhlich, 2016).

2.4 Storage and retrieval

SmartData objects can be stored in collections as time series,

since each of the values they assume along their lifetimes is
tagged with a high-resolution timestamp. These collections
can also be handled from the perspective of Geographic
Information System (GIS), since each data point is also tagged
with spatial coordinates. Each time series is identified by the
interest to which it was a response:

Time Series Id(unit, x, y, z, r, t0 , tf )

and each data point is stored as a tuple as follows:

Data Point(value, x, y, z, t, M AC)

In this way, series ids can be used for geographic queries 3 SmartData overhead
typical of GIS, with regions being added and subtracted,
or with virtual regions that contain several of the ones In order to assess the overhead incurred by the proposed
stored. Data points from the resulting series can be retrieved SmartData API, we evaluated an implementation of it for
considering specific time intervals. The M AC field will be the embedded parallel operating system (EPOS) and its
explained next. trustful space-time protocol (TSTP). The interaction between
the API and the run-time system was implemented in C++
2.5 Security and compiled with GCC 4.4.4 for the EPOSMote III IoT
platform, which features a Texas Instrument’s CC2538 SoC
SmartData requires the underlying run-time support with an ARM Cortex-M3 processor running at 32 MHz, an
system to implement the Poly1305-AES (Bernstein, 2005) IEEE 802.15.4 transceiver, and an AES hardware accelerator.
cryptographic MAC. The key used in this algorithm can be Table 1 shows the code size of each component. The source
derived using Elliptic Curve Diffie-Hellman (ECDH) (Raso code is available at https://xxxx. It’s important to notice that
et al., 2015). The precisely synchronised clocks used to the 7,434 bytes added by the API would not be brought
timestamp data can be used along with both algorithms: for to zero without it: to interact with EPOS for sensing and
Poly1305-AES, timestamps can serve as one of the input communicating purposes, the application programmer would
parameters; for ECDH, they can define a narrow time window have to write his own code.
for sensor deployment. Individual node Ids also serve as input
to ECDH. Table 1 Code size (in bytes) for EPOS components related to
This symmetric cipher scheme is meant to be used only SmartData
in the WSN, which can be connected to the Cloud through Component Size
gateways that make use of asymmetric algorithms within MAC 7644
protocols such as transport layer security (TLS) or secure Routing 3606
sockets layer (SSL) as illustrated in Figure 4. Therefore, SPTP 3728
SmartData objects must be reciphered at gateway, so the HeCoPS 3048
keys used in the WSN do not have to be shared with the Poly1305-AES + ECDH 8322
cloud. In order to confirm the authenticity of a SmartData, SmartData 7434
the corresponding gateway must be contacted and the MAC Total 33,782
presented. Gateways, therefore, keep track of every symmetric
key they have used to communicate with nodes. Key logs are
maintained with entries like this: In this implementation, SmartData is handled at system-level
as zero-copy buffers (dos Santos and Fröhlich, 2005). Apart
Key Log Entry(x, y, z, r, t0 , tf , K, Id) from the IEEE 802.15.4 PDU and the protocol metadata, the
buffer also features a lock, an owner pointer, and a byte size
where [t0 , tf ] and (x, y, z, r) denote the time interval and the counter. All these fields are defined and used by TSTP. They
spatial region in which key K is (or was) used to interact with are simply reused by the SmartData construct, so there is no
 SmartData: an IoT-ready API for sensor networks 207

explicit overhead in terms of data structure footprint. The time encrypted, timed, and georeferenced messages in a resource-
overhead for allocating buffers for SmartData was measured efficient way (Resner and Fröhlich, 2015). TSTP natively
on two EPOSMote III devices, one acting as a gateway implements the timing, location, and security concepts
and the other as an IoT device. The two nodes allocated a required by SmartData along with a greedy, fully-reactive,
total of 260,548 SmartData, taking on average 2.31 µs for geographic routing strategy.
each allocation. For this experiment, interrupts were disabled
during the execution of the code parts being assessed. Figure 5 Assessment of energy overhead for SmartData security
The mechanism for propagating received buffers (see online version for colours)
throughout the components up to the SmartData API was
evaluated on the same EPOSMote III platform. The time a
buffer enters and leaves each component was recorded to find
the propagation overhead in relation to the total processing
time. For 278,800 measurements, the average time for each
buffer to move from the MAC up to the application was
108.57 µs. From this time, on average 12.60 µs were spent
between the end of a component’s duties and the start of
the next, accounting for the overhead of the notification
mechanism itself, which represented 11.60% of the total
SmartData processing time. Table 2 summarises these
measurements.
To validate the SmartData concept, we automated a Solar
Table 2 Assessment of time overhead for internal SmartData Building using motes that feature an IEEE 802.15.4
management transceiver. All of the automated components in the building
are abstracted as SmartData as illustrated in Figure 6:
SmartData handled 260,548 smart plugs, led lights, air conditioners, and sensors such
Average allocation time 2.31 µs as temperature, humidity, luminosity, and CO2. Each smart
Received SmartData processed 278,800 object in the building is able to monitor its own energy
Average processing time 108.57 µs
consumption and report it to a high-level controller. They are
Average notify time 12.60 µs
Notify time / processing time 11.60%
also able to react to commands issued by those controllers. For
instance, actuating on a room’s temperature is accomplished
by the air conditioners installed in the room after considering
In addition to the overhead, we also assessed the time spent temperature measurements from the sensors in the room. They
with the security operations required by SmartData, namely, are collectively abstracted as a Temperature SmartData bound
encrypt, decrypt, and authentication code checking of each to Kelvin. Reading that SmartData returns the temperature
packet. The experiment was run on the same platform, using measured by the sensors, while writing to it defines a new
the AES hardware accelerator available on EPOSMote III. setpoint for the air conditioners.2
Times are summarised in Table 3 and demonstrate that the
associated operations have little impact on this platforms, Figure 6 Solar building sensor network overview (see online
which bears an AES accelerator that is also present in most version for colours)
IoT-oriented microcontrollers.

Table 3 Assessment of time overhead for SmartData security

Encrypt Decrypt Check MAC

Time 17 µs 15 µs 12 µs

Figure 5 shows the energy consumed by the security operations

intrinsic to SmartData. For comparison purposes, two versions
were used: one with hardware-accelerated AES and another Examples of SmartData used to automate the building are
with such operations disabled (no security). The small shown in Figure 7. SmartData temperature1 abstracts a
increase in energy consumption for the version using security temperature sensor from the perspective of the node that
accumulated to less than 1 J after 400 s. contains the transducer (i.e., a local transducer in our terms).
It is meant only to be accessed remotely, since it was
instantiated with period and expiry equal to zero and mode
4 Case study: building automation = ADVERTISED, designating that no samples will be used
locally. The SmartData will wait for remote requests before
The SmartData construct described in the previous section engaging the transducer accordingly. The declaration on lines
was implemented for the trustful, space-time protocol (TSTP), 4–5, instantiates a SmartData to abstract an air conditioner that
a cross-layer protocol designed to deliver authenticated, is also only meant to be commanded remotely. A light sensor
208 A.A. Fröhlich

is instantiated on lines 7–8 and an automatic led light, with 5 Related work
a dimmer and a light sensor, is instantiated on lines 10–13.
This lamp is automatically dimmerised every 5 s based on the The IEEE 1451 Smart Transducer Interface for Sensors and
amount of incident light on its sensor with the following code: Actuators standard (IEEE Instrumentation and Measurement
Society, 2007a) is one of the most significant efforts
1 while (1) { toward a semantic API for sensor networks. Its Transducer
2 illuminace2 . wait (); Electronic Data Sheets (TEDS), which are used to
3 illuminace2 = DESIRED; characterise transducers using SI units was actually the
4 }
original inspiration for SmartData. The annex 5 of
SmartData temperature3 on lines 15-17 declares a proxy for the standard (IEEE Instrumentation and Measurement
remote SmartData temperature1 and temperature2, requiring Society., 2007 b), which defines Transducer Interface
updates from that region every 10s, from T0 until Tf, with Module Initiated Messages (TIM-IM) that enables Wireless
the local value being valid for 60s after each update. The Transducer Interface Modules (WTIM) to take the lead
SmartData on lines 19-21 declares a proxy for illuminace1 while communicating with a Network Capable Application
and illuminance2, requiring updates from that region whenever Processor (NCAP), breaks free from the restrictive polling
they occur (period = 0), from T0 until Tf. The proxied data scheme used for wired transducers (Rufino et al., 2014).
never expires (expiry = 0). The standard, however, does not encompass timing and
location, nor security. These recurring requirements of WSN
Figure 7 Examples of SmartData used to automate the solar applications are fully delegated to the applications themselves.
building (see online version for colours) The Java Specification Request (JSR) 256 of a Mobile
Sensor API (Java Community Process, 2006) specifies an
interface that allows Java ME applications to fetch data from
sensors. However, the interface does not feature methods to
control sensors. It also does not explicitly addresses timing,
location, security, and data semantics. The WSN API proposed
in Juntunen et al. (2006) combines ideas from IEEE 1451, from
TinyDB (Madden et al., 2002), and from JSR 256 to specify
an API that features service discovery and data queries. It also
considers location, tagging data with the node’s coordinates
similarly to what we do for SmartData. It is, therefore, one
of the most comprehensive efforts towards an application-
oriented API for WSN in the past decade. However, it does
not address timing nor security.
The work in Suba et al. (2008) analyses the APIs of distinct
commercially available sensor networks, aiming at identifying
common means to inter-operate them. The considered APIs
Most of the effort to automated the building took place follows the traditional web service approach and pay little
while defining the transducer classes, which interact with the attention to data semantics, timing, location, or security.
physical world and implement the control strategy to reach Authors confirm that many operational parameters are indeed
a setpoint. The work, however, was well isolated from all so diverse that bringing them under a single API was not
the aspects already taken care by SmartData, resulting in possible. The ULLA API proposed in Rerkrai et al. (2007)
concise, well-encapsulated, reusable classes. The overhead of abstracts the sensor network as if it were a distributed database,
mediating the underlying run-time support system through enabling data to be retrieved using SQL-like queries. The API
SmartData implemented in C++ is too small to be measured is targeted at the link layer, aiming at enabling interoperability
precisely. SmartData is a template class and uses static among networks using different technologies, but the same
metaprogramming to bind its client classes to the encapsulated scheme can be used for sensed data. The result is similar to
transducers, so virtually no additional code is generated in the a TinyDB (Madden et al., 2002) deployment in which link-
process. Reading from a SmartData encapsulating an analogue level network information is accessed along with sensed data.
transducer, for instance, results in the client class directly It supports a sophisticated notification mechanism similar
accessing the corresponding ADC. The same is true for the to database triggers. Some of the ideas behind ULLA are
threads created to handle SmartData and about the interaction achieved for SmartData through the database engines used to
with the communication protocol: bindings are resolved at store Collections as described in Section 2.4. ULLA does not
compile-time and the resulting template instances bear no define any sort of semantics sensed information, it only defines
additional overheads in comparison to directly accessing such means to access it. It also does not addresses timing, location,
constructs manually from the application. nor security.
 SmartData: an IoT-ready API for sensor networks 209

The ParaSense API described in Srinivasa et al. (2015) on any embedded operating system enriched with wireless
is defined around a three-tier architecture (sensor, server, communication support for which a modern C++ compiler is
client) focused on IoT integration. It supports a centralised available. The integration of this data-centric WSN view into
management system similar to the setup described in the cloud still presents challenges concerning security, since
Section 2.4. Their concept of application, however, is more SmartData must be brought back to clear-text on gateways
target at APPs running on mobile devices than on the before reaching the internet, but the current stage already
applications that actually run on the sensor nodes of the corroborated its viability.
WSN. Their databases also store raw data, leaving the burden
of semantic consistency to applications. The API proposed
in Sneps-Sneppe and Namiot (2015) address WSN integration References
from the perspective of software-defined networks (SDN),
and it is mostly orthogonal to the issues addressed while Bernstein, D.J. (2005) ‘The poly1305-aes message authentication
modelling SmartData. Their assumption of REST and JSON code’, Proceedings of Fast Software Encryption, Paris, France,
as technologies intrinsic to sensor nodes, however, breaks with pp.32–49.
many of the timeliness requirements that guided the design Dixon, C., Mahajan, R., Agarwal, S., Brush, A.J., Lee, B.,
of SmartData. This requirement is more promptly addressed Saroiu, S. and Bahl, P. (2012) ‘An operating system for
by the work in Gohane and Khekare (2015), which defines an the home’, Proceedings of the 9th USENIX Conference on
API to operate reconfigurable industrial sensor networks with Networked Systems Design and Implementation, NSDI’12,
a strong focus on fault tolerance. Many of the ideas in this USENIX Association, Berkeley, CA, USA, pp.25-25.
work could drive extensions of SmartData towards robustness.
Djenouri, D. and Bagaa, M. (2016) ‘Synchronization protocols and
To the best of our knowledge, none of the efforts taken implementation issues in wireless sensor networks: a review’,
so far to devise a common API for WSN encompasses all of IEEE Systems Journal, Vol. 10, No. 2, pp.617–627.
the aspects address in SmartData: semantic, timing, location,
dos Santos, T.R. and Fröhlich, A.A. (2005) ‘A customizable
security, and cloud integration.
component for low-level communication software’, 19th Annual
Symposium on High Performance Computing Systems and
Applications, Guelph, Canada, pp.58–64.
6 Conclusion
Fu, B., Xiao, Y., Deng, H. and Zeng, H. (2014) ‘A survey of cross-
layer designs in wireless networks’, Communications Surveys
In this paper, we introduced SmartData, a high-level API for
Tutorials, IEEE, Vol. 16, No. 1, pp.110–126.
sensor networks aiming at leveraging the myriad of features
Gohane, S.P. and Khekare, G.S. (2015) ‘Reconfiguration of industrial
available on such networks while delivering a common,
embedded system in WSN’, 2015 IEEE 9th International
consistent, semantic abstraction for sensed data that facilitates
Conference on Intelligent Systems and Control (ISCO), IEEE,
the development of sensing applications without incurring in
Coimbatore, India, pp.1–5.
significant overhead. The main motivation for the proposed
API is the fact that, despite intense research on the field for Golestanian, M., Siva, J. and Poellabauer, C. (2017) ‘Radio
frequency-based indoor localization in ad-hoc networks’, in
almost two decades, programmers still do not have a cohesive,
Ortiz, J. (Ed.): Ad Hoc Networks, InTech, Chapter 6.
highly expressive API to model their sensing applications
and to connect them to the IoT. The primary idea behind Granjal, J., Monteiro, E. and Silva, J.S. (2015) ‘Security for the
SmartData is to enrich data with enough metadata to make it internet of things: A survey of existing protocols and open
self-contained in terms of semantics, spatial location, timing, research issues’, IEEE Communications Surveys Tutorials,
and trustfulness. It is meant to be the only application-visible Vol. 17, No. 3, pp.1294–1312.
construct in the sensing platform and therefore implicitly Huang, P., Xiao, L., Soltani, S., Mutka, M.W. and Xi, N. (2013)
mediates all system-level services, including communication, ‘The evolution of mac protocols in wireless sensor networks:
synchronisation, and the interaction with transducers and A survey’, IEEE Communications Surveys Tutorials, Vol. 15,
actuators. An application reads a sensor simply by accessing No. 1, pp.101–120.
the data contained in a SmartData through its interface. The Hulbert, A., Kunicki, T., Hughes, J.N., Fox, A.D. and Eichelberger,
data is automatically updated from the network according C.N. (2016) ‘An experimental study of big spatial data systems’,
to the parameters specified at instantiation time. Actuation IEEE International Conference on Big Data (Big Data),
happens through the same interface: changing a SmartData Washington DC, USA, pp.2664–2671.
causes messages to be propagated over the network to IEEE Instrumentation and Measurement Society. (2007a) IEEE
command actuators accordingly until the new value is Standard for a Smart Transducer Interface for Sensors and
observed. It, therefore, bears the notion of a setpoint for a Actuators - Common Functions, Communication Protocols, and
network-wide controller when seen as a writable object. Transducer Electronic Data Sheet (TEDS) Formats.
The case study on the utilisation of SmartData to IEEE Instrumentation and Measurement Society (2007b) IEEE
automate a Solar Building demonstrated the effectiveness Standard for a Smart Transducer Interface for Sensors and
of the API and the possibility of implementing it using Actuators - Wireless Communication Protocols and Transducer
template metaprogramming with virtually no overhead on Electronic Data Sheet (TEDS) Formats.
the path between applications and the underlying run-time Java Community Process (2006) JSR 256 - Mobile Sensor API
support system. We believe SmartData can be implemented Specification Version 1.0.
210 A.A. Fröhlich

Juntunen, J., Kuorilehto, M., Kohvakka, M., Kaseva, V., Reghelin, R. and Fröhlich, A.A. (2006) ‘A decentralized location
Hannikainen, M. and Hamalainen, T. (2006) ‘WSN API: system for sensor networks using cooperative calibration
Application programming interface for wireless sensor and heuristics’, 9th ACM/IEEE International Symposium on
networks’, 2006 IEEE 17th International Symposium on Modeling, Analysis and Simulation of Wireless and Mobile
Personal, Indoor and Mobile Radio Communications, IEEE. Systems, Torremolinos, Malaga, Spain., pp.139–146.
Kopetz, H. and Bauer, G. (2003) ‘The time-triggered architecture’, Rerkrai, K., Riihijarvi, J., Wellens, M. and Mahonen, P. (2007)
Proceedings of the IEEE, Vol. 91, No. 1, pp.112–126. ‘Unified link-layer API enabling portable protocols and
Kumar, A., Srivastava, V., Singh, M.K. and Hancke, G.P. (2015) applications for wireless sensor networks’, 2007 IEEE
‘Current status of the IEEE 1451 standard-based sensor International Conference on Communications, IEEE, Glasgow,
applications’, IEEE Sensors Journal, Vol. 15, No. 5, pp.2505– UK, pp.3237–3243.
2513. Resner, D. and Fröhlich, A.A. (2015) ‘Design rationale of
Levis, P., Patel, N., Culler, D. and Shenker, S. (2004) ‘Trickle: a a cross-layer, trustful space-time protocol for wireless
self- regulating algorithm for code propagation and maintenance sensor networks’, 20th IEEE International Conference on
in wireless sensor networks’, First Symposium on Networked Emerging Technologies and Factory Automation (ETFA 2015),
Systems Design and Implementation, San Francisco, USA, Luxembourg, Luxembourg, pp.1–8.
pp.2–2. Resner, D. and Fröhlich, A.A. (2016) ‘Speculative precision time
Lonare, S. and Wahane, G. (2013) ‘A survey on energy efficient protocol: submicrosecond clock synchronization for the IoT’,
routing protocols in wireless sensor network’, 2013 Fourth 21st IEEE International Conference on Emerging Technologies
International Conference on Computing, Communications and and Factory Automation (ETFA 2016), Berlin, Germany.
Networking Technologies (ICCCNT), IEEE, Tiruchengode, Resner, D., de Araujo, G.M. and Fröhlich, A.A. (2017) ‘Design
India, pp.1–5. and implementation of a cross-layer IoT protocol’, Science of
Ludwich, M.K. and Fröhlich, A.A. (2015) ‘Proper handling of Computer Programming page to appear.
interrupts in cyber-physical systems’, 26th IEEE International Rufino, L.M., Steiner, R.V., Raimundo, R.V. and Fröhlich, A.A.
Symposium on Rapid System Prototyping, Amsterdam, The (2014) ‘Improvements in wireless communication and support
Netherlands, pp.83–89. for WMSN in IEEE 1451’, Brazilian Symposium on Computing
Madden, S., Szewczyk, R., Franklin, M. and Culler, D. (2002) Systems Engineering, Manaus, Brazil, pp.109–114.
‘Supporting aggregate queries over ad-hoc wireless sensor Sneps-Sneppe, M. and Namiot, D. (2015) ‘Metadata in SDN
networks’, Proceedings Fourth IEEE Workshop on Mobile API for WSN’, 2015 7th International Conference on New
Computing Systems and Applications, IEEE Comput. Soc. Technologies, Mobility and Security (NTMS), IEEE, Paris,
Marjani, M., Nasaruddin, F., Gani, A., Karim, A., Hashem, I., France, pp.1–5.
Siddiqa, A. and Yaqoob, I. (2017) ‘Big iot data analytics: Srinivasa, K., Siddiqui, N. and Kumar, A. (2015) ‘ParaSense –
Architecture, opportunities, and open research challenges’, a sensor integrated cloud based internet of things prototype
IEEE Access, Vol. PP, No. 99, pp.1–1. for real time monitoring applications’, 2015 IEEE Region 10
Mendes, L.D. and Rodrigues, J.J. (2011) ‘A survey on cross-layer Symposium, IEEE, Ahmedabad, India, pp.53–57.
solutions for wireless sensor networks’, Journal of Network and Suba, F., Prehofer, C. and van Gurp, J. (2008) ‘Towards a common
Computer Applications, Vol. 34, No. 2, pp.523–534, Efficient sensor network API: practical experiences’, 2008 International
and Robust Security and Services of Wireless Mesh Networks. Symposium on Applications and the Internet, IEEE, Turku,
Nowotsch, J., Paulitsch, M., Buhler, D., Theiling, H., Wegener, S. and Finland, pp.185–188.
Schmidt, M. (2014) ‘Multi-core interference-sensitive WCET
analysis leveraging runtime resource capacity enforcement’,
2014 26th Euromicro Conference on Real-Time Systems, IEEE.
Oh, S-H. and Yang, S-M. (1998) ‘A Modified Least-Laxity-First Notes
scheduling algorithm for real-time tasks’, Proceedings of the
1
5th International Conference on Real-Time Computing Systems Even simple real-time scheduling algorithms, such as single-
and Applications, Hiroshima, Japan, pp.31–36. core Rate Monotonic and Deadline Monotonic, depend on CPU
Papadopoulos, G. (2015) ‘Challenges in the design and utilisation estimates in order to be deployed with schedulability
implementation of wireless sensor networks: a holistic confidence. Such estimates are often impracticable for the
approach-development and planning tools, middleware, speculative, out-of-order, superscalar processors that are now
power efficiency, interoperability’, 2015 4th Mediterranean becoming common in the embedded realm (Nowotsch et al., 2014).
2
Conference on Embedded Computing (MECO), IEEE. The actual control loops involved in thermal and luminous comfort
Patil, M. and Biradar, R.C. (2012) ‘A survey on routing protocols are out of the scope of this paper.
in wireless sensor networks’, 2012 18th IEEE International
Conference on Networks (ICON), IEEE, pp.86–91.
Raso, O., Mlynek, P., Fujdiak, R., Pospichal, L. and Kubicek, P.
(2015) ‘Implementation of elliptic curve diffie hellman in
ultra-low power microcontroller’, 2015 38th International
Conference on Telecommunications and Signal Processing
(TSP), IEEE, Prague, Czech Republic, pp.662–666.