MacroLab: A Vector-based Macroprogramming Framework
for Cyber-Physical Systems
Timothy W. Hnat, Tamim I. Sookoor, Pieter Hooimeijer, Westley Weimer, and
Kamin Whitehouse
Department of Computer Science, University of Virginia
Charlottesville, VA, USA
{hnat,sookoor,pieter,weimer,whitehouse}@cs.virginia.edu
ABSTRACT
We present a macroprogramming framework called Macro-
Lab that offers a vector programming abstraction similar to
Matlab for Cyber-Physical Systems (CPSs). The user writes
a single program for the entire network using Matlab-like op-
erations such as addition, find, and max. The framework
executes these operations across the network in a distributed
fashion, a centralized fashion, or something between the two
– whichever is most efficient for the target deployment. We
call this approach deployment-specific code decomposition
(DSCD). MacroLab programs can be executed on mote-class
hardware such as the Telos [24] motes. Our results indicate
that MacroLab introduces almost no additional overhead in
terms of message cost, power consumption, memory foot-
print, or CPU cycles over TinyOS programs.
Categories and Subject Descriptors
C.3 [Special-Purpose and Application-Based Systems]:
Real-time and Embedded Systems; D.1.3 [Programming
Techniques]: Concurrent Programming–Distributed pro-
gramming
General Terms
Design, Languages, Performance
Keywords
Cyber-Physical Systems, Embedded Networks, Macropro-
gramming, Programming Abstractions
1. INTRODUCTION
Cyber-Physical Systems (CPSs) combine low-power ra-
dios with tiny embedded processors in order to simultane-
ously cover large geographic areas and provide high-resolution
sensing/actuation. This revolutionary technology has begun
to deliver a new generation of engineering systems and sci-
entific breakthroughs. However, CPSs are extremely diffi-
cult to program; building even a simple application entails
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 for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
SenSys’08, November 5–7, 2008, Raleigh, North Carolina, USA.
Copyright 2008 ACM 978-1-59593-990-6/08/11 ...$5.00.
several complex tasks such as distributed programming, re-
source management, and wireless networking. CPSs have
reached a reasonable degree of technological maturity, but
their impact and widespread adoption is limited by the com-
plexity of their software.
In this paper, we present the MacroLab framework for
CPS software development. We call MacroLab a macropro-
gramming system because the user writes a single macro-
program for the entire CPS and the framework automati-
cally decomposes it into to a set of microprograms that are
loaded onto each node. MacroLab provides a vector pro-
gramming abstraction using syntax similar to Matlab, which
already has broad adoption among scientists and engineers.
Data from sensors and actuators are manipulated just like
other numerical vectors, making MacroLab programs sim-
ilar to and easy to integrate with existing scientific soft-
ware. Its traditional, imperative programming model sup-
ports general-purpose programming and is a natural way to
encode CPS applications involving both sensing and actua-
tion.
MacroLab introduces a new data structure called a macro-
vector which can be used to store in-network data such as
sensor readings. Conceptually, each element of a macro-
vector corresponds to a different node in the network, but
macrovectors can be stored in different ways. Each ele-
ment can be on its corresponding node, all elements can
be on a central server, or all elements can be replicated on
all nodes. No matter how a macrovector is stored, it can
support standard vector operations such as addition, find,
and max. These operations may run in parallel on a dis-
tributed macrovector, sequentially on a centralized macro-
vector, or somewhere in between. Thus, by changing the
representation of each macrovector, MacroLab can decom-
pose a macroprogram in the way that is most efficient for a
particular deployment. For example, it may use centralized
representations for small star topologies and distributed rep-
resentations in large mesh networks. We call this approach
deployment-specific code decomposition (DSCD).
In contrast to systems like TinyOS [15], the MacroLab
programmer specifies application logic in terms of abstract
computation and does not need to explicitly control data
partitioning or message passing from within the source code.
Instead, these tasks are performed automatically as compile-
time and run-time optimizations. By separating application
logic from program decomposition, MacroLab can improve
code portability, increase code reuse, and decrease overall
development costs. Furthermore, it can reduce overall re-
source consumption. Our results show that automatically

choosing a decomposition for each deployment can reduce
message passing by up to 50 percent over using a single de-
composition for all deployments.
MacroLab provides a clear cost model so that the pro-
grammer can write code that produces efficient and opti-
mized decompositions. This is analogous to the idea in Mat-
lab that vectorized code is more efficient than for loops.
MacroLab does not compromise on power or memory ef-
ficiency in order to provide a high-level vector program-
ming abstraction and our results indicate that MacroLab
programs are just as efficient as normal TinyOS programs.
2. BACKGROUND AND RELATED WORK
The predominant way to program a CPS today is with
node-level programming. The user writes a microprogram
that is loaded onto each node that specifies when it should
sense, actuate, or send messages and how to respond to
incoming messages or hardware events. This is a difficult
and error-prone way to design a system and would be simi-
lar to an architect designing a building by generating step-
by-step instructions for each construction worker instead of
generating blueprints. Node-level programming is so diffi-
cult that many so-called macroprogramming systems have
recently been proposed: the user writes a single program
that specifies global operations for the entire CPS and the
framework automatically decomposes this into a set of mi-
croprograms for each node.
Macroprogramming systems have been proposed with a
wide variety of abstractions and programming models, each
of which is designed to make programming easier for some
class of applications. For example, database-like systems
such as TinyDB [18] and Cougar [34] allow the user to specify
the desired data using declarative SQL-like queries. These
systems are most suitable for data collection applications
where the desired data can be described with a declarative
query. Several systems such as Hood [32], Regions [30], and
Proto [2] are designed for spatial applications and allow users
to specify operations over groups, neighborhoods, or regions
in space. Other systems such as Semantic Streams [31],
Flask [20], and Regiment [22] allow users to specify global
operations in terms of stream operators. These are most
suitable for defining a static set of long-running operations
over streams of sensor data. MacroLab is perhaps most sim-
ilar to imperative macroprogramming abstractions like Mar-
ionette [33], Pleiades [14], and Kairos [10]. These systems
support general-purpose programming with a traditional im-
perative programming model. MacroLab is the first macro-
programming system for CPSs to provide vector program-
ming, a powerful and concise abstraction that already has
wide adoption among scientists and engineers.
Several existing systems allow users to write imperative
programs that can then be distributed across multiple pro-
cessors for the purposes of high performance computing.
These include High Performance Fortran (HPF) [26], For-
tran D [11], and Split-C [5]. The fundamental difference be-
tween these approaches and MacroLab is their dependence
on the user to specify how the data and operations should be
distributed. For example, Fortran D uses the statments de-
composition, align, and distribute to specify how to exe-
cute a program on multiple processors. In contrast, Macro-
Lab programs do not specify how to map the computation
onto the network. In fact, the system will create a different
mapping for each network on which the program is executed.
Several existing systems such as MagnetOS [16], Coign [12],
and J-Orchestra [29] can automatically decompose a pro-
gram and distribute it across a network in order to mini-
mize network traffic. Similar to MacroLab, these systems
use program profiling to tailor the decomposition to a spe-
cific network topology. In contrast to MacroLab, these sys-
tems decompose programs at the object level. MagnetOS
and J-Orchestra break a program up at the boundaries of
Java objects and use Java RMI between segments of the pro-
gram. Coign requires programs to conform to Microsoft’s
Component Object Model (COM) and breaks them up at
the boundary of the COM objects. MacroLab introduces
parallelism at the level of individual operations instead of at
the level of objects or software components.
Several existing systems allow the user to specify paral-
lel operations using parallel data structures. SET Language
(SETL) [27] provides primitive operations such as set mem-
bership, union, intersection, and power set construction,
which can be applied in parallel to elements of unordered
sets. Starlisp (*Lisp) can apply vector operations such as
vector addition and multiplication over Parallel Variables
(PVARS) which are vectors with one element per proces-
sor. Similarly, NESL allows parallel operations on sequences.
These are similar to MacroLab’s parallel vector operations
on macrovectors. However, MacroLab goes beyond these
systems by employing multiple underlying representations
of a macrovector. Unordered sets, PVARS, and sequences
can only be decomposed in one way while macrovectors are
decomposed in one of many different ways depending on
the topology over which the program is executed. To our
knowledge, MacroLab is the first system that can perform
automatic, topology-specific decomposition on programs de-
scribing parallel operations on parallel data structures.
3. MACROLAB
MacroLab allows the user to write a single program that
is simple, robust, and manageable and then automatically
decomposes it depending on the target deployment. A pro-
gram decomposition is a specification of where data is stored
in the network and how messages are passed and compu-
tations are performed in order to execute the program. A
macroprogram may be decomposed into distributed opera-
tions for a large mesh network, where data is stored on ev-
ery node and network operations are performed in-network.
It could also be decomposed into centralized operations for
a small star topology, where all data is collected to a cen-
tral base station. A program may also be decomposed into
many points on the spectrum between purely centralized or
purely distributed code. The implementation could also use
group-based data processing or in-network aggregation.
MacroLab’s overall architecture is depicted in Figure 1. A
macroprogram (described in Section 3.1) is passed to the de-
composer (Section 3.2) which generates multiple decompo-
sitions of the macroprogram. Each decomposition is passed
to the cost analyzer (Section 3.3) which calculates the cost
of each with respect to the cost profile of the target de-
ployment. This cost profile must be provided by the user
and may include information such as the topology, power
restrictions, and descriptions of the radio hardware. The
cost analyzer chooses the best decomposition and passes it
to the compiler and run-time system (Section 3.4) which
converts the decomposition into a binary executable and ex-
ecutes it. While it executes, the program and the run-time