Ravel: Programming IoT Applications as Distributed

Models, Views, and Controllers

Laurynas Riliskis, James Hong & Philip Levis

Stanford University
[email protected]

ABSTRACT
The embedded sensor networks are a promising technology
to improve our life with home and industrial automation,
health monitoring, and sensing and actuation in agriculture.
Fitness trackers, thermostats, door locks are just a few ex-
amples of Internet of Things that have already become part
of our everyday life. Despite advances in sensors, micro-
controllers, signal processing, networking and programming
languages, developing an Internet of Things application is a
laborious task.
Many of these complex distributed systems share a 3-tier
architecture consisting of embedded nodes, gateways that
connect an embedded network to the wider Internet and
data services in servers or the cloud. Yet the IoT applica-
tions are developed for each tier separately. Consequently, Figure 1: An example of common IoT architecture.
the developer needs to amalgamate these distinct applica-
tions together.
This paper proposes a novel approach for programming 1. INTRODUCTION
applications across 3-tiers using a distributed extension of
The Internet of Things (IoT) encompasses a huge variety
the Model-View-Controller architecture. We add new prim-
of applications, ranging from fitness trackers, home automa-
itive: a space - that contains properties and implementation
tion to health monitoring, sensing and actuation in agricul-
of a particular tier.
tural environments. These ultra-low-power networks bridge
Writing applications in this architecture affords numerous
to the larger Internet through gateway: a mobile phone or
advantages: automatic model synchronization, data trans-
a device running embedded Linux. Back-end servers in the
port, and energy efficiency.
cloud store data transmitted by gateways and render it to
users via web interfaces.
Categories and Subject Descriptors A subset of these applications operates across three tiers
C.2.4 [Computer-Communication Networks]: Distributed of devices as shown in Fig. 1: embedded, gateway and cloud.
Systems; D.1.0 [Software]: Programming Techniques; Gen- Each tier has different storage, computation, energy resources
eral and diverse user interfaces (e.g. a blink sequence and tap-
ping input on Fitbit or a web page). One or more low-power
Keywords embedded devices sense and actuate with the physical en-
vironment. These devices can be personal and mobile (e.g.
Internet of Things; Programming Distributed System; Pro- smart watch), shared and stationary (e.g. door lock), or
gramming Paradigm; Wireless Sensor Network some mixture of the two. Embedded sensing devices of-
ten share a similar set of challenges and limitations, in-
cluding ultra-low power operation, low duty cycles, sensing,
actuation, and low-power personal area wireless protocols
(802.15.4 or Bluetooth).
IoT apps must manage energy carefully, deal with delay-
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
tolerant networking, run on three different processor archi-
for profit or commercial advantage and that copies bear this notice and the full cita- tectures and three different operating systems. Changing a
tion on the first page. Copyrights for components of this work owned by others than small detail in one part of the application (e.g. the format of
ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or re- a data value) requires propagating this change across many
publish, to post on servers or to redistribute to lists, requires prior specific permission languages and components that run on each tier.
and/or a fee. Request permissions from [email protected].
Programming such sensor network applications has always
IoT-App’15, November 1, 2015, Seoul, South Korea.
c 2015 ACM. ISBN ACM 978-1-4503-3838-7/15/11.̇.$15.00. been difficult. While there has been tremendous progress in
DOI: http://dx.doi.org/10.1145/2820975.2820977. operating systems [13, 4], programming models [11, 5], and
networking for low-power embedded devices, these advances the model instances would only store a subset of the data
are only part of a much larger puzzle – an IoT programming (e.g. the embedded device current heart rate, mobile device
model consisting of many different types of devices. the latest hour, while the server maintains the full history).
Despite these efforts, each tier is developed separately: Models can be durable or volatile, and apply data opti-
converting data between different schemas manually. We mizations (e.g., allocation, caching, compression) appropri-
notice that Model-View-Controller is a software architec- ate to the limited resources of embedded and gateway de-
ture that dominates modern web application development in vices. It is the controller of the model that create records,
frameworks such as Rails, Django, and Meteor. Many desk- moves data from in-memory buffers to flash, apply data op-
top applications follow such an architecture too (XEmacs: timization, move and convert data between schemas and
synchronize multiple windows with the same buffer). As a spaces.
result, MVC’s abstractions and approaches are well under- Models and controllers are device-independent, but the
stood by the majority of developers today. Therefore we views are space-specific: the interface of a shower sensor
ask, how can we make the development of IoT appli- with a few LEDs is different from that of a mobile phone
cations as easy as the modern web? or web application. Ravel provides unified API to fetch the
This paper presents Ravel, a programming framework for data from models and pass it to a template implementing
IoT applications following the three-tier architecture. A the view for a particular space.
Ravel developer writes code in a single language (in our im- A space is a set of rules, templates, and code snippets
plementation, Python) across all tiers of the system. First, for a particular platform (e.g., an Android phone, a TinyOS
an application is written with a Distributed Model-View- sensor, a Django server). For example, a TinyOS space has
Controller architecture. Then, the developer assigns the information about nesC data types (such as nx uint16 t),
models and views across spaces– the devices that comprise uses ActiveMessages, runs transforms within tasks, and uses
the three-tier application. Finally, Ravel generates static TinyOS’s storage component for durable models. Rather
code for each of the spaces that can be compiled and de- than individually write code for each tier, Ravel develop-
ployed to the devices. ers assign same models to spaces and adds views to them.
Ravel’s programming abstractions allow a developer to Each space specification has all the logic necessary to trans-
take a complex, distributed sensor network application and late Ravel application code into the code for that particular
write it as a series of models with views and controllers. space. For some spaces, such as Python-based Django, this
Ravel fills in all of the intervening pieces, such as network translation is straightforward because Ravel is implemented
protocols that synchronize models across devices, storage, in Python, the developer writes an application similarly to
and scheduling. The high-level description of the system is the Django framework. For more constrained environments,
simultaneously concise and semantically expressive. such as TinyOS/nesC or Contiki, this translation is more
This paper has three contributions: (1) A novel Distributed complex. Ravel generates the code from space templates
Model-View-Controller programming paradigm for IoT ap- and code snippets: by mapping data types from internal to
plications that follow a 3-tier architecture. (2) The con- the particular space types and using that to create buffers,
cept of spaces, which allow a programmer to distribute the communication routines, initialize the main function.
data processing pipeline across multiple devices, with the
Ravel automatically handling data synchronization, encryp- 2.1 Water Saving Application
tion, and other networking across spaces. (3) An implemen- To ground the above concepts in a concrete example, we
tation and an evaluation of the framework based on how well develop a sensor network application. The application’s goal
the system enables simple, high-level programming of dis- is to collect fine-grained water use data on the students living
tributed applications with little overhead over native, hand- in a large dormitory. Currently, the university only knows
written implementations. how much the entire building uses water daily. Without
Paper organization follow. Section 2 provides an overview finer-grained data, it is hard to formulate policies to reduce
of Ravel, that is detailed in Section 3. Section 4 describes water use (a tremendous concern in California, given the
the evaluation of the framework. Section 5 gives an overview severe drought).
of programming paradigms for IoT and Section 6 concludes We mount a sensor between the water pipe from the wall
this article. and the fixture to monitor water flow and temperature from
the showers and sinks in the dormitories. The sensor has
2. SYSTEM OVERVIEW a rechargeable battery that is charged by harvesting en-
ergy from water flow using a small turbine. The sensor de-
A Ravel application is a set of models, views, and con-
vice communicates using Bluetooth Low Energy (BLE) to
trollers, distributed across different devices. Ravel’s model
a smartphone gateway (either Android and iOS). When the
define the data types that an application collects, processes,
gateway is close to a sensor, the application on the smart-
stores, and displays to a user. In web frameworks, a model is
phone connects to and requests data from the sensor. The
typically bound to a particular database table: they repre-
gateway stores this data and asynchronously sends it to a
sent a schema and an instance of that schema. Ravel appli-
python-service (Django) running in the cloud. The sensor
cations are distributed; thus, a model has multiple instances
encrypts the data that is decrypted only on the cloud. Sen-
across different spaces; each with a to space specific schema.
sors hold onto records until they receive an end-to-end ac-
For example, the model instance on the embedded device
knowledgment from the cloud.
is represented as a Cstruct, on the Android gateway as a
class, and in the backend as a table. Each instance of the
model will have distinct storage sizes characteristic to the 3. PROGRAMMING WITH RAVEL
space. An embedded device, smartphone, and a backend Fig. 2 shows Water Sensing Application in Ravel’s prim-
might have the same model of heart rate. However, each of itives. The main data flow (shown in blue) goes from two
 stored either in memory or in flash depending on defined
durability. Because changes to the model can occur on any
of tiers while being disconnected, the framework enforces
directed data flow: records appearing earlier in the flow are
synchronized to later models but not vice-versa.
Ravel models support differing data durability require-
ments between applications and models within the same de-
vice tier. The standard mode is durable, persisting data on
flash while the light-weight mode only keeps a RAM buffer.
In the latter mode, data may be lost to a system reboot or
overflowed buffer.
Figure 2: An application spanning three tiers of eMbeded- 3.2 Views and Controllers
Gateway-Cloud architecture represented in Ravel primitives.
Views present an external interface (a GUI, JSON) for a
set of records drawn from one or more models. View speci-
fications are solely device (and therefore space) specific. On
sources (the temperature and flow sensors) to the sink (the
an iOS gateway, the interface might be a native applica-
cloud with database) via Measurement model. We distin-
tion; in the cloud it might be a web page or JSON data;
guished notation of source and sink models because they
on the embedded device it might be a small LED or LCD.
are space specific (they represent a particular hardware or
For this reason, views are the one device-specific component
software) and cannot be moved. For example source model
in Ravel. The framework provides a clean set of interfaces
for temperature is a sensor on the embedded device. Hence,
that translate data into local representations for feeding into
moving it to the gateway would result in a completely dif-
a view.
ferent model.
Controllers respond to pushes from other controllers and
The Measurement model is distributed over all three tiers,
interface requests (such as displaying a record). They read
thus Ravel will initialize needed storage and communication
and modify their models and invoke views. Ravel controllers
links to synchronize data between the spaces. The green flow
extend standard MVC by sending data across spaces; con-
shows a Average Temperature model with a view; Ravel cre-
trollers typically do not modify or compute on data as this is
ates this model from the Measurement model in the gateway
done by the model. The developer has the flexibility to spec-
space. Because Average Temperature is in only one space, it
ify option such as value update time, sensor reading interval,
does not need synchronization.
timeout. Ravel generates controllers as series of timers and
When the developer runs Ravel’s build command, the
interrupt handlers. For example, the temperature sensor
compiler will generate static code for each of the tiers: in-
would be periodically read, but the data transmission would
cluding, buffering, storage and communication protocols.
be contingent upon an available connection.
The resulting static code can be edited or directly compiled
and deployed. The resulting application will read sensors, 3.3 Spaces and Templates
transmits data to the gateway, show the mean values and
Ravel spaces describe the properties and technical de-
forward the measurements to the cloud for storage.
tails of underlying devices. Technically, a space contains
3.1 Models file, function, Makefile and include templates together with
software components. Ravel uses templates and software
Essentially, each Ravel model is s set of fields that repre-
components to assemble controllers, models and views that
sents data. We use metaprogramming to overrides standard
map them to the underlying OS native types in a partic-
class initialization and add necessary fields for the system
ular language. Internally, Ravel builds a graph with the
meta information, class signatures and convenience function-
data types and structure particular to space’s programming
ality. For example, each model will get automatic fields such
system. For example, a temperature model component will
as node id, timestamp, sequence number. The distributed
contain initialization function, includes, build and linking
models can be either best-effort or reliable. In the reliable
dependencies. Also a controller to read the sensor and write
case, a model synchronizing data from the embedded space
to the Measurement – a model in our example.
to the cloud space will not delete a record until it receives
Ravel uses a templating approach similar to that of pop-
an end-to-end acknowledgment from the cloud.
ular modern web frameworks. To reduce runtime overhead
The fields are represented by Ravel’s data type (such as
Ravel generates static code before deployment that allows
Integer, Float, TimeStamp, and so on) that compiler maps
to inspect and modify code manually.
to the type used in each space. For example, if we decide
to represent sensor reading as uint32 t rather then uint16 t
the change needs to be performed only in one place – Ravel 4. EVALUATION
will propagate this change to all three tiers. Such an ap- This section describes Ravel evaluation. Firstly, we exam-
proach is tremendously useful when models span multiple ine implicit benefits of developing IoT application in the Dis-
spaces: instead of having to redefine the schema for each tributed Model-View-Controller in a data flow architecture.
device and system, the developer only needs to maintain Secondly, using previously described the water saving appli-
one specification. Additionally, a holistic data types prevent cation as the example, we to compare the required workload
one of the most common causes of security vulnerabilities: (Lines of Code, LoC) to implement the sensor application
wrong type-casting [12]. manually in C to one written in Python using Ravel.
Ravel automatically synchronizes model instance between A team of 4 Ph.D. students, one undergraduate, and one
spaces when networking is available. Prior that, records are post-doctoral researcher developed this application over a
period of 6 months, encountering numerous engineering chal- Application O1 O3 Os Ravel LoC (C)
lenges in the process. For example, Android and iOS have Hand written 20308 21936 17180 - 1025
very different Bluetooth interfaces (and programming lan- Ravel 13100 13328 10300 80 1201
guages), forcing completely separate gateway implementa-
tions. Developers for each component of the system must Table 1: Size of water saving application using Ravel as
decide on data representations and bridge those represen- well as the hand-written implementation, both in bytes of
tations across programming languages and architectures: C compiled code and lines of source code.
to Swift, C to Java, Swift to Python, and Java to Python.
Moving functionality across devices (compression or encryp- data gathering that requires durable models, and their syn-
tion) requires entirely new, and separate implementations, chronization.
and changing the placement of data processing requires new Ravel model has optional meta class parameters that al-
data formats as well as marshaling code. As a result, early lows specifying details for synchronization and durability.
design decisions made about how to distribute the applica- Enabling the durability flag will automatically initialize flash
tion across devices are effectively set in stone, preventing us on embedded device, store data there and read it for trans-
from making several desired changes before deployment. mission. On the gateway, for instance, it would create a
database (for example SQLite on Android). Enabled syn-
4.1 Benefits of the Single Data Model chronization produces necessary buffers and controllers to
Having one single data model spanning all three tiers is move the data from the embedded device to the gateway
tremendously helpful. In our example application the data is and further to the cloud. For example, MeanTemperature
(1) read from a sensor as uint32t , (2) stored in a buffer (as a model is only stored on the gateway to store it on the cloud
C − struct containing timestamp uint32t , sequence number the developer needs to implement database storage on the
and node id both uint16t ), (3) moved to the durable medium cloud and communication handlers. A robustly and scalable
(flash). Upon available connection, a record is read from implementation would require tens to hundreds of lines in
the flash drive, (4) converted to a radio compatible buffer Python, Java or C/C++ while inRavel it is sufficient with
(uint8t byte array) and transmitted. When the gateway only one.
receives the data (uint8t byte array), the application (5) 4.3 Complete Application
cast byte array to the expected data types (two uint32t and
two uint16t unmangled in the right order). Stored them in In our comparison, the Ravel developer required to write
(6) typed class and (7) writes to a durable storage. Finally, 80 lines of code for the entire application. That resulted
the data is transmitted to the backend server (8); where it is in generated 1201 lines of C code for the embedded device,
cast from text/JSON to the appropriate type (9) and stored 2393 for Android (1470 XML, 908 Java and 15 IDL), and
in the database fields (10). 136 Python for Django. That is fewer than the hand written
In Ravel changing data type for from 16 to 32 bits is version, but this difference is not significant: it is mostly due
achieved by one line of code. Whereas manually, it would to how Ravel partitions functions and performs local variable
require changes in ten different places, on three different de- initialization.
vices, in three different programming languages as described When compiled, the Ravel version uses significantly less
above. Additionally, such change may require splitting data code space than the hand-written one, namely 20308 B vs.
packets on embedded device (because of the limited radio 13100B as detailed in Tab. 1. The difference took us by
message size) which would complicate reliable synchroniza- surprise - given the somewhat equal lines of code, we would
tion further. expect somewhat equal code size. The larger code size in the
Another notable advantage of Ravel is the ability to define hand-written version is because of its build process: there
valid ranges or checks for data: check temperature between were some unnecessary object files included in the final ex-
0 and 100C, else alert. Alternatively, monitor invariants ecutable, left over from prior versions of the application.
that data must satisfy: verify that battery percent increased Once these were removed and the same compilation options
while water flow is active. To apply such sanity checks and were used, the hand-written version had roughly equal code
add testing code to our non-Ravel implementation across all size to the Ravel one. However, this points at the bene-
three-tier manually (via hacks) has led to numerous bugs as fit of using a framework, which can automatically minimize
parts of the system were evolving separately. In Ravel, this is not only code but also use toolchains intelligently and in an
automated and does not require additional effort, leading to optimizing way. Ravel helps avoid many common mistakes
a system that is not only easier for developers to understand, that only many years of practice and experience prevent.
but also to debug, maintain and detect errors. Noticeably, this evaluation is indicative because of LoC
as a main metric. However, it is evident that the time to
4.2 Model Synchronization and Durability develop applications in Ravel is significantly shorter. Our
approach is more feasible for applications intended for in-
A traditional sensor application often periodically streams dividual use rather than mission critical cyber-physical sys-
data to the permanent gateway. Hence, storing data values tems.
on the device is optional, which simplifies the application.
In our scenario, we encountered two challenges with such
approach: firstly, BLE devices have short communication 5. RELATED WORK
range thus deploying gateway in each shower would increase SQL-like query interfaces [15, 16, 2] enable data retrieval
cost. Secondly, to connect these gateways to the electrical from a distributed sensor network as if it were a database.
outlet requires special casings and certification for electron- A single query can retrieve data from multiple nodes in the
ics in wet environments, which made deployment more ex- network. Users or applications query data from a heteroge-
pensive and complicated. Hence, we decided to crowdsource neous sensor network via the gateway, retrieving results in
an endpoint. For example Cougar [25] adds a query proxy ture. For example, SQL-like programming assumes that the
layer on top of the application’s runtime. The burden to system output will have correct and homogeneous data types
write the complex code for each tier of the application: in- or that they will be cast correctly even without reprogram-
dividual nodes, gateway, and backend system – is on the ming. Thirdly: the newly uploaded programs, scripts or
developer. executed queries have to be “standardized” or they will re-
Rather than sending queries, macroprograming focuses on quire the gateway and cloud to be reprogrammed, which is
writing a high-level app for groups of nodes [1, 18, 19, 14, 3, not addressed by these systems. Finally, these systems do
8]. The paradigm hides communication, storage, and run- not address application requirements for user interaction,
time complexity allowing the developer to focus on the appli- networked and distributed functionality at each device tier:
cation’s data and logic. For example, EcoCast [24] is an in- embedded, gateway, and cloud.
teractive object-oriented macroprograming framework. The In contrast, Ravel addresses current limitations. Changes
developer writes Python code that is later compiled into C in Ravel model are propagated to the code for each of three
code and distributed to nodes. Similar to an SQL-like ap- tiers. Ravel generates static code from templates for each
proach, these systems assume that a particular OS, libraries tier in the architecture. Firstly this reduces dependencies on
the run-time is available on the node. Macroprogramming a particular OS, libraries or runtimes. Secondly, it permits
systems do not address cross-tier programming issues: the the developer to implement and use any existing system and
developer must manually program and change the gateway its desired functionality. Finally, Ravel retains the benefits
and cloud, ensuring that the data schemas are compatible of developing a single application for a three-tier architec-
after the changes in node applications. ture.
Numerous systems have proposed to simplify development
using data streams, which enable the developer to concen- 6. CONCLUSIONS
trate on data models and information flow rather than low-
This paper presented Ravel, a novel programming frame-
level programming [17]. These approaches allow users to
work allowing developers to program 3-tier architecture ex-
specify computation on existing data flows and deal with a
plicitly in a manner very similar to web applications today,
variety of particular type of stream. For example, MISSA
via models, views, and controllers. Ravel introduces concept
[10] implements a middleware for provisioning generic stream-
of space, which bind particular models, controllers and views
based services, while SPITFIRE [20] focuses on enabling
to a specific devices. The networking complexities between
access to the data from connected sensors as a semantic
devices are hidden by the distributed model that automati-
web. Yet, these approaches assume either a secondary de-
cally synchronizes whenever possible.
veloper [23] (who implements the system according to the
Programming an entire embedded sensor network in a
specification) or the existence of the enterprise infrastruc-
high-level language has been a long-term goal of sensor net-
ture with deployed code for each tier.
work research. Ravel suggests that perhaps we should con-
Other systems, for example, SNACK [7], propose a config-
sider programming at an even larger scale, encompassing the
uration language, with a library and compiler for the devel-
gateways and cloud that are part of almost every applica-
opment of Wireless Sensor Networks. Instead of creating a
tion.
new language, WuKong [21, 22] uses a flow-based program-
ming paradigm in a familiar Java environment. The devel-
oper constructs an application from logical components in Acknowledgement
WuKong’s library and later distributes the application as This work was supported, in part, by generous gifts from Er-
binary executable for embedded Java VM. icsson, VMware, SAP, and Panasonic, as well as the Okawa
To address three-tier programming, Exemplar [9] allows Foundation and the Wallenberg Foundation. This material
the developer to demonstrate the desired physical interac- is based upon work supported by the National Science Foun-
tion and bind it to a resulting action. The system ana- dation under Grant No. 1505728 (CNS: CPS Security) as
lyzes the sensor traces and classifies different interactions well as the Intel Corporation.
(tilting a head left or right). Similarly, Fabryq [6] allows
a developer to write an embedded-gateway-cloud applica- 7. REFERENCES
tion as a centralized Javascript application that interacts [1] A. Awan, S. Jagannathan, and A. Grama.
with the cloud and embedded device through RPC function Macroprogramming heterogeneous sensor networks
calls. These and many other techniques allow a developer to using cosmos. In Proceedings of the 2Nd ACM
explore quickly and prototype an MGC application. How- SIGOPS/EuroSys European Conference on Computer
ever, they lack deployability: the implementation is tied to a Systems 2007, EuroSys ’07, pages 159–172, New York,
particular hardware that supports the subset scripting lan- NY, USA, 2007. ACM.
guage. Also, the primary goal is prototyping. Thus, there is [2] P. Bonnet, J. Gehrke, and P. Seshadri. Towards sensor
no way to transition an Exemplar or Fabryq prototype to a database systems. In K.-L. Tan, M. Franklin, and J.-S.
working system (scale it, move to different hardware, or add Lui, editors, Mobile Data Management, volume 1987
new sensors or actuators) besides developing it again from of Lecture Notes in Computer Science, pages 3–14.
scratch. Springer Berlin Heidelberg, 2001.
The exiting programming paradigms have a set of lim-
[3] A. Boulis, C.-C. Han, and M. B. Srivastava. Design
itations for the IoT. Firstly: existing frameworks assume
and implementation of a framework for efficient and
access to the data (e.g. nodes) through a central always-
programmable sensor networks. In Proceedings of the
connected gateway. Secondly: they require that the data
1st International Conference on Mobile Systems,
schemas, communication protocols, other components and
Applications and Services, MobiSys ’03, pages
data types are static in the different tiers of the architec-
187–200, New York, NY, USA, 2003. ACM.
 [4] A. Dunkels, B. Gronvall, and T. Voigt. Contiki-a sensor networks. SIGOPS Oper. Syst. Rev.,
lightweight and flexible operating system for tiny 36(SI):131–146, Dec. 2002.
networked sensors. In Local Computer Networks, 2004. [16] S. R. Madden, M. J. Franklin, J. M. Hellerstein, and
29th Annual IEEE International Conference on, pages W. Hong. Tinydb: an acquisitional query processing
455–462. IEEE, 2004. system for sensor networks. ACM Transactions on
[5] A. Dunkels, O. Schmidt, T. Voigt, and M. Ali. database systems (TODS), 30(1):122–173, 2005.
Protothreads: simplifying event-driven programming [17] R. Newton and M. Welsh. Region streams: Functional
of memory-constrained embedded systems. In macroprogramming for sensor networks. In
Proceedings of the 4th international conference on Proceeedings of the 1st International Workshop on
Embedded networked sensor systems, pages 29–42. Data Management for Sensor Networks: In
Acm, 2006. Conjunction with VLDB 2004, DMSN ’04, pages
[6] M. Etemadi, W. McGrath, B. Hartmann, and S. Roy. 78–87, New York, NY, USA, 2004. ACM.
Fabryq: Using phones as smart proxies to control [18] A. Pathak and M. K. Gowda. Srijan: A graphical
wearable devices from the web. 2014. toolkit for sensor network macroprogramming. In
[7] B. Greenstein, E. Kohler, and D. Estrin. A sensor Proceedings of the the 7th Joint Meeting of the
network application construction kit (snack). In European Software Engineering Conference and the
Proceedings of the 2Nd International Conference on ACM SIGSOFT Symposium on The Foundations of
Embedded Networked Sensor Systems, SenSys ’04, Software Engineering, ESEC/FSE ’09, pages 301–302,
pages 69–80, New York, NY, USA, 2004. ACM. New York, NY, USA, 2009. ACM.
[8] R. Gummadi, O. Gnawali, and R. Govindan. [19] A. Pathak, L. Mottola, A. Bakshi, V. Prasanna, and
Macro-programming wireless sensor networks using G. Picco. Expressing sensor network interaction
kairos. In V. Prasanna, S. Iyengar, P. Spirakis, and patterns using data-driven macroprogramming. In
M. Welsh, editors, Distributed Computing in Sensor Pervasive Computing and Communications
Systems, volume 3560 of Lecture Notes in Computer Workshops, 2007. PerCom Workshops ’07. Fifth
Science, pages 126–140. Springer Berlin Heidelberg, Annual IEEE International Conference on, pages
2005. 255–260, March 2007.
[9] B. Hartmann, L. Abdulla, M. Mittal, and S. R. [20] D. Pfisterer, K. Romer, D. Bimschas, O. Kleine,
Klemmer. Authoring sensor-based interactions by R. Mietz, C. Truong, H. Hasemann, A. KroÌĹller,
demonstration with direct manipulation and pattern M. Pagel, M. Hauswirth, M. Karnstedt, M. Leggieri,
recognition. In Proceedings of the SIGCHI Conference A. Passant, and R. Richardson. Spitfire: toward a
on Human Factors in Computing Systems, CHI ’07, semantic web of things. Communications Magazine,
pages 145–154, New York, NY, USA, 2007. ACM. IEEE, 49(11):40–48, November 2011.
[10] S. Kang, Y. Lee, S. Ihm, S. Park, S.-M. Kim, and [21] N. Reijers, K.-J. Lin, Y.-C. Wang, C.-S. Shih, and
J. Song. Design and implementation of a middleware J. Y. Hsu. Design of an intelligent middleware for
for development and provision of stream-based flexible sensor configuration in m2m systems. In
services. In Computer Software and Applications SENSORNETS, pages 41–46, 2013.
Conference (COMPSAC), 2010 IEEE 34th Annual, [22] N. Reijers, Y.-C. Wang, C.-S. Shih, J. Hsu, and K.-J.
pages 92–100. IEEE, 2010. Lin. Building intelligent middleware for large scale cps
[11] K. Klues, C.-J. M. Liang, J. Paek, systems. In Service-Oriented Computing and
R. Musaloiu-Elefteri, P. Levis, A. Terzis, and Applications (SOCA), 2011 IEEE International
R. Govindan. Tosthreads: thread-safe and Conference on, pages 1–4, Dec 2011.
non-invasive preemption in tinyos. In SenSys, [23] S. Tranquillini, P. Spieç, F. Daniel, S. Karnouskos,
volume 9, pages 127–140, 2009. F. Casati, N. Oertel, L. Mottola, F. Oppermann,
[12] B. Lee, C. Song, T. Kim, and W. Lee. Type casting G. Picco, K. RÃűmer, and T. Voigt. Process-based
verification: Stopping an emerging attack vector. In design and integration of wireless sensor network
24th USENIX Security Symposium (USENIX Security applications. In A. Barros, A. Gal, and E. Kindler,
15), pages 81–96, Washington, D.C., Aug. 2015. editors, Business Process Management, volume 7481 of
USENIX Association. Lecture Notes in Computer Science, pages 134–149.
[13] P. Levis, S. Madden, J. Polastre, R. Szewczyk, Springer Berlin Heidelberg, 2012.
K. Whitehouse, A. Woo, D. Gay, J. Hill, M. Welsh, [24] Y.-H. Tu, Y.-C. Li, T.-C. Chien, and P. Chou.
E. Brewer, et al. Tinyos: An operating system for Ecocast: Interactive, object-oriented
sensor networks. In Ambient intelligence, pages macroprogramming for networks of ultra-compact
115–148. Springer, 2005. wireless sensor nodes. In Information Processing in
[14] L. Luo, T. F. Abdelzaher, T. He, and J. A. Stankovic. Sensor Networks (IPSN), 2011 10th International
Envirosuite: An environmentally immersive Conference on, pages 366–377, April 2011.
programming framework for sensor networks. ACM [25] Y. Yao and J. Gehrke. The cougar approach to
Trans. Embed. Comput. Syst., 5(3):543–576, Aug. in-network query processing in sensor networks.
2006. SIGMOD Rec., 31(3):9–18, Sept. 2002.
[15] S. Madden, M. J. Franklin, J. M. Hellerstein, and
W. Hong. Tag: A tiny aggregation service for ad-hoc