A Spreadsheet Approach to Programming and ManagingSensor Networks

Alec Woo

Arched Rock Corp.657 Mission St. Ste. 600San Francisco, CA 94105

alecwoo@acm.org

Siddharth Seth

Dept. of EECEIndian Institute of Technology

Kharagpur, India

siddharth.seth@iitkgp.ac.in

Tim Olson, Jie Liu,Feng Zhao

Microsoft ResearchOne Microsoft Way

Redmond, WA 98052

{timol,liuj,zhao}@microsoft.com

ABSTRACTWe present a spreadsheet approach to simplifying the pro-cess of managing, programming, and interacting with sen-sor networks and visualizing, archiving and retrieving sen-sor data. An Excel spreadsheet prototype has been builtto demonstrate the idea. This environment provides Excelusers, who are already familiar with spreadsheet applica-tions, a convenient and powerful tool for programming anddata analysis. We discuss the architecture of this prototypeand our experience in implementing the tool. We show twodifferent classes of sensor-net applications built using thisplatform. We also present performance data on the scala-bility of the tool with respect to data rate and number ofdata streams.

Categories and Subject DescriptorsH.4.1 [Office Automation]: Spreadsheets

General TermsExperimentation

KeywordsNetworked sensors, Excel, SQL server, data streams

1. INTRODUCTIONToday, one of the hurdles in deploying a sensor network

is the difficulty of programming and running the entire sys-tem. It involves programming and managing the sensors,programming the gateways, interpreting and processing thedata streams, and setting up servers for data archival andretrieval. The truth is that even experts in the field find thisentire process difficult and troublesome.

The underlying challenges arise from the inherent dis-tributed nature of sensor networks that cross multiple tiersof computing platforms: sensors, gateways, and servers. Inaddition, the unpredictability of the physical phenomenon

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.IPSN’06, April 19–21, 2006, Nashville, Tennessee, USA.Copyright 2006 ACM 1-59593-334-4/06/0004 ...$5.00.

being monitored often requires much iteration of data anal-ysis and algorithmic or processing changes. This “in-situ”property is unique to sensor network since deployment-specificconstraints can impact the entire programming design andprocess; the deterministic behavior generally assumed in tra-ditional programming is rare here.

Recent research efforts in simplifying sensor programminghave led to a few interesting macro-programming frame-works [8, 7, 9, 11, 5]. The general approach of these worksfocuses on designing a high-level language primitives thatcan abstract away programming individual sensor nodes andlow-level system details. These abstractions build up theimportant foundation and representation for defining pro-gramming specifications that aim to span multiple nodes.The high-level description of logic is very useful for pro-gramming and managing sensor systems composed of manynodes. However, sensor-net programming involves hurdlesbeyond building richer abstractions. The “in-situ” natureof sensor networks requires a joint real-time data acqui-sition, processing and programming environment. Systemmanagement support that allows users to (re-)configure and(re-)program part or entire sensor system is also important.Therefore, a sensor network programming environment re-quires three concurrent components: data acquisition andprocessing, in-situ programming, and run-time system man-agement and reconfiguration support.

The contribution of this work is to allow users to achievethese three requirements using the familiar and widely usedspreadsheet environment — Microsoft ExcelTM. Using spread-sheet to organize sensor data is not completely new. Thework in [2] explores the use of a spreadsheet interface tohelp scientists to visualize data and perform some limitedprocessing. The main idea is to provide a pivot-table inter-face so that users can visualize the data relationships fromdifferent perspectives. Instead of using Excel, they build acomplete spreadsheet tool from scratch. The work also pro-poses to let users write simple expressions to define eventtriggers that will eventually be compiled down to the sensor-tier acting as low-level filters.

Our environment extends the popular office software pack-age and builds upon the abstractions and run-time supportdeveloped by the macro-programming effort and the sensor-net tools like TinyOS1. The ultimate goal is to provide asimple user experience for interacting with sensor networks,in terms of both data management, and programming. Al-

1http://www.tinyos.net

Figure 1: A multi-tier architecture for sensor net-

work deployments.

though processing is currently performed centrally in thespreadsheets, it can be distributed in the future for scalabil-ity reasons with appropriate run-time support.

Our current implementation of the prototype with Excelis built on top of a service-oriented abstraction architectureprovided by SONGS [6]. Although there are other ways tointerface Excel with sensor networks, this service-orientedabstraction layer and the XML Web Service interface it pro-vides are flexible and easy to work with. Its extensibility isalso crucial when we distribute data processing in the future.

The paper is organized as following. Section 2 discusseshow spreadsheet fits within the multi-tier architecture typi-cally found in sensor network deployments. Section 3 walksthrough a high-level description of the implementation of ourprototype and how it addresses our programming and man-agement goals. Section 4 presents two application scenariosshowing how our prototype helps building sensor-net appli-cations. Section 5 evaluates the scalability of our spread-sheet prototype. We discuss our experiences in designingthis toolkit in Section 6 and related work in Section 7, andwe conclude and address future work in Section 8.

2. THE ROLE OF SPREADSHEETFigure 1 shows the architectural overview of a sensor net-

work deployment that is typically seen in scientific data col-lection, environmental monitoring, and event detection ap-plications.

The lowest-tier of computing at the bottom of Figure 1consists of sensors deployed over a field. The sensors self-organize into a single or multiple-hop network streamingdata towards the gateways (also called microservers in someliteratures), the next tier of computing. The gateway nodesmay either be wireless or wired, but typically will havehigher link bandwidth and better reliability. They can beprogrammed to further process the data streams or even op-erate as delegates for querying the sensor tier. The gateway,as its name suggests, also acts as an entry point to the Inter-

net for the sensor nodes. The data streams from the gate-ways can be aggregated and archived for further processingby more powerful servers or databases at the next tier. Thislast tier of computing at the top of Figure 1 supports anInternet-scale sensor system. Managing and programmingeach of the tiers are difficult, not to mention integratingthem together to form a complete system. Therefore, thedesign space crossing these different tiers is large and manyof the issues are out of the scope of this paper. In this sec-tion, we focus on identifying the roles of spreadsheet relativeto Figure 1.

Users typically interact with the sensor system off-line atthe top tier or in real-time at the middle tier. Thus theboundary between the top and the middle tiers is particu-larly important. Spreadsheet can play the roles of simplify-ing data acquisition, data organization, programming, andrun-time system management and reconfiguration interfacesfor the users at the middle tier. Since it is already a familiarprogramming and data organization interface for scientificand business purpose, applying the same spreadsheet pro-gramming model for processing incoming data streams inreal time would be very useful for everyday computer userswho do not know or want to learn sensor network details.The same built-in statistical functions and data visualiza-tion tools in a spreadsheet can be reused for analyzing datastreams in the sensor-net context.

Another advantage of using the spreadsheet model is theeasiness of combining streaming real-time data with staticinformation such as node locations, configurations, and non-sensor related information. This is useful for system man-agement and reconfiguration to have a customized view ofvarious information sources. For example, one can overlaythe deployment map and bind the spreadsheet cells to thesensor node positions on the map. This allows users to bothmanage the node and its data stream like manipulating in-dividual cell on a spreadsheet. Changing the values in thecell of a node can automatically configure or even reprogramthe node.

This integration of spatial deployment information withdata analysis, data programming and system managementdirectly addresses the “in-situ” nature of sensor networks.Spreadsheet naturally positions itself between the user andthe gateway and sensor tier as shown in Figure 1. Fur-thermore, the ease of integration of spreadsheet with webservices and databases at the highest-tier makes spread-sheet a very convenient integration tool. To preserve thedistributed nature of the system, data processing withinspreadsheets can fall back to other nodes, the gateways, oreven the sensor-net tiers. However, this goes beyond thecurrent scope of this paper.

3. SYSTEM IMPLEMENTATIONThe implementation of the spreadsheet prototype has two

parts. The first involves augmenting Excel for sensor net-work management. The second involves making Excel han-dle streaming data. In our prototype, we use Tmote skyfrom Moteiv2 sensor nodes, PC gateways with a microserverruntime (called µSEE3), a user PC machine with Excel 2003and Visual Studio 2005, and a Microsoft SQL Server.

2http://www.moteiv.com.3Available at http://research.microsoft.com/nec/msrsense

Figure 2: Downloading Tmote programs through

Excel.

3.1 Network ManagementWe augment Excel with its built-in VBA scripting capa-

bility to provide a user interface that eases the process ofprogramming (i.e. downloading code to) the sensor tier.The first step involves discovery of deployed sensor nodes.If nodes are connected directly to the USB port of the ExcelPC, discovery simply means invoking corresponding TinyOStools, such as “motelist”, to query for the sensor nodes.If nodes are configured on an Ethernet network, through,for example, Tmote Connect, discovery often means goingthrough a lookup table that contains information of all de-ployed sensor nodes. If nodes are deployed in a multi-hopmesh, we can rely on tools, such as Nucleus [10], for nodediscovery and display it in Excel.

Once node discovery is done, each sensor is represented asa cell, as shown in Figure 2. Users select the cells that repre-sent motes for programming. All TinyOS applications in thetinyos-1.x/apps directory are shown as a list in Excel forusers to select. Sending programs to the motes can be donethrough USB, Ethernet, or wireless (with e.g. Deluge [3]).

Once the motes and a program is selected, the VBA scriptwill invoke external shell commands to recompile the pro-gram, to set the node IDs, and to download the programonto the corresponding motes.

3.2 Sensor Data Stream ProcessingWe use Visual Studio 2005 with .NET 2.0 to augment Ex-

cel to act as an agent to query the gateway tier for incomingsensor data streams. This version of Visual Studio integrateswell with Excel development using Visual Studio Tools

for Office System. This Visual Studio tool allow us toimplement an extension of Excel in C# to handle streamingdata.

Figure 3 shows the key components in implementing sen-

SelectData

Connection

Microserver SQL Server

Packet Buffer

Play

Record

Sensor Network

XSLTView

Building

XML Map

Figure 3: The flow chart of a typical data processing

application.

sor data stream processing applications. Sensor nodes com-municate with microserver gateways, which feed data intoExcel. Using an action panel, users can select data sources— either real-time data from the sensor network, or archiveddata from a SQL server. Streams of data are first queued bya packet controller in a buffer. A separate display thread pe-riodically takes data out from the buffer and concatenatesmultiple packets into a data view using XSL transforma-tions, which assigns each data stream a unique namespace.The view is then displayed using the built-in XML mappingfeature.

The gateway tier runs a service-oriented microserver, calledµSEE. The microserver provides a service abstraction overthe gateway and sensor tiers. A XML script called MSTMLis used by µSEE for defining service composition over thegateway and the sensor tiers. Our current implementationuses a pre-defined MSTML file to task the two tiers. In thefuture, the construction of the service composition can alsobe done within Excel.

The microserver uses XML as the basic gluing logic andstructure definition for service composition and data streamobjects. That is, the gateways have services to automat-ically convert data streams from the lower-tier, platform-dependent sensor data format into platform-independent XMLstreams. Here is an example of the XML data for Oscilloscopemessages produced by the gateways:

<?xml version="1.0" encoding="utf-8"?>

<ArrayOscopeMsg

xmlns:xsd= "http://www.w3.org/2001/XMLSchema"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<sourceMoteID>236</sourceMoteID>

<lastSampleNumber>13782</lastSampleNumber>

<channel>2</channel>

<data>

<unsignedShort>474</unsignedShort>

<unsignedShort>475</unsignedShort>

...

<unsignedShort>472</unsignedShort>

</data>

</ArrayOscopeMsg>

The schema for this XML stream is then mapped to Excelcells using the built-in XML Map feature. XML mapping isa process of dragging and dropping a particular element fromXML schema on to a cell, which informs Excel to bind dataassociated with that element to the cell upon loading futuredata. A limitation of this approach is that each elementmapping must be unique in the XML Map definition. Forthis reason, we extended Excel by representing the data foreach data stream as a unique namespace.

The usage of this tool requires no special knowledge of thepacket stream or of XML maps as the user only needs to loadthe Excel worksheet, define the XML maps to use by loadinga network configuration file, which automatically creates thenecessary XSL transformations for the data streams. Then,the user would utilize the built-in XML Maps feature of Ex-cel to drag elements from the list to the appropriate cellwhere they would like to bind the data. For any elementsthat have an unbounded size attribute, our extension to Ex-cel will automatically grow lists when new data is added tothe document. Once the maps are defined, a data connec-tion is created by either specifying a real-time connectionto the gateway or to SQL Server for previously recordeddata. Once data streams are mapped onto the Excel lists,processing on the data is the same as usual spreadsheet pro-gramming. Notice that Excel has an event-driven model ofcomputation built in. Whenever the value of a cell changes,all dependent formulas and plots are reevaluated and re-freshed automatically. This allow uses to always have themost recent view of the processing results without managingdata propagation manually.

3.3 Database ServerWhile spreadsheet provides a data programming and visu-

alization environment to the users, the archival of the datarequires a database, especially when data streams are con-tinuous for a long period of time.

Our prototype can store each data stream and its corre-sponding processed values into the database. To ease the in-tegration effort between Excel and the database, we use SQLServer 2005 because it natively supports XML data types.With this XML capability, XML streams can be stored di-rectly in the database without knowing the packet structurea priori. XML query processing is thus possible over boththe raw data streams and the processed data streams fromthe spreadsheet. We use XML as the key of simplifying theintegration process for the different tiers as we believe thatfuture databases and data streams will widely support andexploit XML.

With a database, the spreadsheet becomes a cache for themost recent data streams. This cache size is especially lim-ited if processing is done centrally. In our current implemen-tation, Excel lists of the data and processing streams have alimited size defined by the user. That is, each list signifies afixed time window of the most recent data, with the currentsample being at the bottom of the list. The stale samples,already stored in the database, will be automatically purgedby Excel as the lists are bounded by their maximum length.The choice of this size is a balance on the amount of his-tory that it needs to maintain for processing versus scalableperformance as the amount of streaming increases. Thissize and the refresh rate are two key performance metrics tocontrol the scalability of our tool.

Figure 4: A spreadsheet illustration of sensor loca-

tions.

4. APPLICATION SCENARIOSWe apply our prototype to two different classes of sensor-

net applications. One involves event detection for the pres-ence of a vehicle in a parking lot and the other is a typicalenvironmental data collection application within an officebuilding.

4.1 Data CollectionOur first application involves collecting environmental data

within a typical office building. The deployment consists of9 sensor nodes that are capable of sensing ambient light,photo-synthetic light, temperature, and humidity. Thesesensor nodes are deployed across seven offices and a hard-ware laboratory. We use Excel to maintain the spatial in-formation of the deployment as shown in Figure 4.

Deployment specific information of each node can be de-scribed using XML and stored as cell values in the spread-sheet. The information may include node ID, types of sen-sors on the node, and location of the node. Depending onhow the sensor program is created, this information can di-rectly be mapped to Nucleus in TinyOS or abstracted bya SONGS service for management and reconfiguration pur-poses. The tool-tip box in Figure 4 shows the XML descrip-tions for one of our deployed node.

The XML elements, including HOST, IP, SFPort, Prog-Port, and MoteSerial, describe the test-bed information aboutthe mote. The rest of the elements specifically describe thedeployment information and the services provided by thesensors. The deployment information is expected to be de-fined by the users while the node services can also be dy-namically discovered.

To visualize and process the sensor data streams with Ex-cel, users can select a subset or all of the sensors discoveredand shown on the spreadsheet. The users can simply selectthe cells corresponding to the nodes to subscribe for theirdata streams. The selected data streams will be shown au-tomatically on a different worksheet.

Excel can automatically infer the schema of incoming XMLobjects and display them on the spreadsheet. However, thisis often not desired because users may want to have the con-trol to layout and select important fields from the XML datastreams. Our current prototype manually filters for the in-teresting part of the data streams and lays them out on thespreadsheet from left to right, with user-defined processing

Figure 5: A spreadsheet data collection scenario.

Figure 6: Real-time sensor data overlayed on sensor

locations.

lists interleaving between them. In the future, we plan touse a wizard to guide users to control such a process.

Figure 5 shows an example of the filtered real-time datastreams from two sensor nodes in Figure 4, with the mostrecent samples located at the bottom of each list. In thiscase, each processing list simply converts the unit of rawhumidity data from the list on its left into Celsius.

Users can utilize Excel’s built-in plotting ability to graphreal-time statistics of the data streams similar to the Os-cilloscope tool from the TinyOS distribution. In addition,users can reuse the deployment specific information layoutin Figure 4 to visualize the spatial distribution of the data.For example, Figure 6 shows a very simple spatial contourgraph of the temperature variations among the different lo-cations. The color spectrum range is adjusted dynamically,depending on real-time data as shown in cells L3 and L4.Clicking on the node will display a callout box showing theaverage temperature of that location.

4.2 Vehicle Event DetectionThe second application involves detecting vehicles and

counting them within a parking lot infrastructure. We use

Figure 7: A spreadsheet program detection vehicle

events.

the same deployment setup as discussed in [6]. Infraredbreak-beam sensors and their reflectors are deployed in theparking lot. Whenever the line of sight between a sensor andits reflector is physically blocked by an obstacle, such as avehicle, the sensor will report a low-level binary detectionevent to the gateway. A vehicle passing over these sensorswill generate streams of events, which are time-stamped bythe gateway and sent to Excel. Figure 7 shows a screenshotof the data streams in Excel.

In this case, an “OnEvent” means that the break-beamsensor has an event detected. The XML representation forOnEvent contains the location of the break-beam sensor andthe time stamps for the rising and falling edges. In our de-ployment, sensors are strategically placed along the roadsidesuch that a typical vehicle would block at least two of thesensors during crossing. One simple mechanism in detect-ing a vehicle is to count if two or more sensor events withina given physical location overlap in time. The list on theright with a thick border in Figure 7 shows how users canspecify such processing using conventional spreadsheet arrayformula.

For each raw data detection event, we calculate the num-ber of events that overlap with it in time using the fol-lowing Excel array formula: {=SUM((falling time<=$F6)

*(falling time>$E6))}. In this case, the current row is6. Therefore, F6 represents the falling-edge timestamp andE6 represents the rising-edge timestamp of the current On-Event. Variable falling time is the name of column F de-fined by the user a priori. It signifies the falling-edge times-tamp of all the events in the worksheet. The action of theformula is to sum up the number of events in the list thathas the falling-edge timestamps within the rising-edge andfalling-edge of the current event at row 6. This is an arrayformula, as denoted by {}, because it has to process theentire falling time (F th) column. Expanding the formulato include location information in Figure 7 can filter outevents that are not spatially correlated. As the raw datalist grows, the processing list grows as well with the relativecell addressing, such as F6 and E6, in the formula adaptingautomatically.

The next column defines a threshold for vehicle detection;if the number of overlapping detections equals or exceedsa threshold of 2, a vehicle is detected. This logic is trans-lated to the following Excel expression in cell J6 in Figure 7:=IF(num overlaps>=2, 1,0). This is not an array formulasince we are not processing the entire num overlaps column.Variable num overlaps simply refers to the cell in column (I)on the same row numbered 6.

This simple example demonstrates how users can use thebuilt-in Excel functions and expressions to derive more high-level statistics, such as vehicle speed and traffic flow infor-mation within the parking lot. The naming convention inExcel can be confusing when writing formulas since it de-pends on the context of the formula, which is one limitationof the Excel programming model.

Notice that incoming raw data streams do not follow atemporal order in Figure 7. However, the amount of buffer(list size), which determines how far back the spreadsheetcan go in time, is adequate to absorb these issues for oursimple application. However, users need to explicitly pro-cess the unordered streams if tight temporal processing isrequired.

5. PERFORMANCE EVALUATIONKey questions to ask about the scalability of this Excel

toolkit are how many concurrent input streams and at whatrates it can process data received from a sensor network. Toevaluate the performance, we use a data collection exampleas described in Section 4.1. by running the application undera various number of data streams.

We programmed a set of motes with the Oscilloscope ap-plication that comes with TinyOS-1.1.13 distribution. Dataare sent at roughly one packet per second per channel. Eachpacket contains 10 samples of unsigned 16-bit integers. Amicroserver gateway converts received TinyOS packets toXML packets as shown in section 3.2. On a desktop PCwith Intel P4 2.80 GHz CPU and 2GB of RAM, we run ourExcel spreadsheet that displays all incoming data, one sam-ple per cell. Each sensor channel is a separate column in thespreadsheet.

The execution time is measured using the StopWatch classin the .NET 2.0 Framework. This class allows us to captureelapsed time for a code section. The primary code analyzedis the display thread for each stream. The activation of thethread is controlled by a refresh rate parameter as describedbelow. Upon activation, it takes a fixed number of pack-ets from the packet buffer, applies the XSL transformationto merge them into a single XML document with a uniquenamespace, and display the data in Excel GUI through XMLbinding. There is no further processing or plotting of thedata in Excel. So, essentially, we only collect the overheadof consuming raw data into Excel from streams. We call thisthe processing time in the following discussions.

There are several parameters that users can control howdata are consumed by Excel. They are keys to understandthe performance metrics:

• Timeline (T) – The timeline, or window size, is themaximum number of packets displayed in Excel fora particular stream. For example, if the timeline is300 packets and the data are coming at a rate of onesecond per packet with 10 samples per packet, thenExcel roughly caches 5 minutes of data that occupies3000 cells. Once the timeline is reached, the packetcontroller removes old packets from the beginning ofthe buffer and adds new packets to the end, essentiallysliding the time window in the direction of movingtime.

• Refresh rate (RR) – The refresh rate, measured innumber of packets per refresh, is used by the packet

controller to notify the display thread to consume lat-est data and to update the display. For example,RR = 1 is the fastest refresh rate, such that the GUIresponds to every incoming packet. If RR = 10, thenthe packet controller will wait until receiving 10 newpackets before notifying the display thread. Since in-coming packets are queued in the packet buffer, batch-processing them with a low refresh rate (or a highpacket number) can give Excel more time to transformand display packets, thus improve scalability.

• Sub-packet – Sometimes, a user may only want to dis-play a subset of data contained in the receiving pack-ets. For example, Oscilloscope packets in our examplehas 10 samples in each input packet, this parameterallows users to downsample them in the user interface,even though all samples are archived in the database.We use the parameter samples-per-packet-to-display(SPP) to control how much data to display in Ex-cel. SPP=10 means all samples are displayed, whileSPP=1 means only one sample per packet is displayed.

Figure 8 shows the processing time of various numbers ofpackets. The refresh rate is 1 and SPP is 10. The curve is thesame under different system load, varying from 1 to 9 datastreams. The line in the plot is y = x, in order to illustratethat the processing time is nearly a slow exponential withrespect to the length to the timeline.

Figure 8: Average processing time over the number

of XML packets to be binded, RR = 1, SPP = 10.

Figure 9 shows a histogram of the processing time for 600packets in one stream with RR = 1 and SPP = 10, whichcorresponds to 6000 rows in the spreadsheet. The histogramplots 2000 runs. We see the same statistics in 8 hours ofstress test. So, it takes Excel roughly a second to process600 packets, which is about 10 minutes of raw oscilloscopesamples with 10Hz sampling rate.

The data also indicates that when Excel is processingmore than one data streams, the total timeline has to beshorter, otherwise the receiving packets will accumulate inthe packet buffer and Excel loses real time property. Wehave observed that when the packets in the buffer accumu-late too much, the Excel UI becomes non-responsive. Toavoid this problem, one can reduce the refresh rate or re-duce the samples per packet to be displayed.

850 900 950 1000 1050 1100 1150 12000

100

200

300

400

500

600

700

Processing time for 600 packets (milliseconds)

coun

ts

Histogram for processing time in 2000 runs

Figure 9: A histogram of the processing time for 600

packets, RR = 1, SPP = 10.

0 100 200 300 400 500 6000

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Number of packets to be processed

Rat

io o

f pr

oces

sing

tim

e an

d re

fres

h in

terv

al

Duty cycles of processing packets from 6 data streams

RR=10, SPP=10

RR=1, SPP=10

RR=2, SPP=10

RR=5, SPP=10

RR=1, SPP=5

RR=1, SPP=2

RR=1, SPP=1

Figure 10: The effectiveness of adjusting refresh rate

and samples to display parameters.

Figure 10 shows the effectiveness of adjusting RR andSPP. We define

DutyCycle =processing time per refresh

refresh interval.

The plot shows the duty cycles for processing 6 streams ofinput under either slowing down the refresh rate (to 2, 5,or 10 packets/refresh) or down sampling the packets (to 5,2, and 1 samples per packet to display). It is clear thatadjusting refresh rate is more effective than down-samplingthe packets. In fact, the effect of changing refresh rate isalmost linear. This is due to the savings on redrawing allthe cells in Excel.

We have also stress tested the robustness of the tool byrunning it for days and over various mote connection mecha-nisms: through local USB ports, through local area network,and through corporate intranet. We have not found anymemory management problems in handling long streams.

Consider the rate that human consumes information indata streams, our Excel prototype is scalable to meet most

users’ requirements. At a once per 10 seconds refresh rate,it can easily display 6000 rows from a single data stream.There is enough time left to perform many further process-ing and plotting.

6. DISCUSSIONSOur prototype allows us to gain a lot of first-hand ex-

perience in evaluating this spreadsheet approach to sensornetworks. We discuss our programming and implementationexperiences in this section.

6.1 Programming ExperiencesFor developers who are used to imperative languages for

programming, spreadsheet programming may feel restrictivein the beginning. It is easy to arrive with an early judgmentthat “this can’t be done in a spreadsheet!” This is becausespreadsheet may provide less flexibility with its simple ex-pression language and its requirement of the data to be in atabular format. For sophisticated data processing, whichwe haven’t evaluated with our two application scenarios,spreadsheet programming may be cumbersome. For exam-ple, list-to-list processing primitives, which are very commonfor data streams, are not supported by Excel. Data namingis also weak as the reference of the list’s name depends on thecontext of the formula. While VBA can be used to providea rich functional language programming platform, it breaksthe spreadsheet programming model. Non-VBA functionalprogramming on Excel is possible as demonstrated by thework in [4], but it is still an early research prototype. Atthe current stage, we have not explored using spreadsheetfor programming complex processes.

However, the very point of a spreadsheet is to provide asimple programming platform for non-computer scientists,who will be the main users of sensor networks. Although ourapplication scenarios are simple, the demonstrated process-ing is fundamental and common to many potential sensor-net applications. Furthermore, the formula expression lan-guage in Excel is fairly general and supports a rich set ofstatistical functions for scientific studies. Finally, the pro-gramming logic and the associated buffer usage are quiteexplicit on a spreadsheet. This can be advantageous sincesuch information is useful in delegating the processing to thesame or lower tiers.

6.2 Implementation ExperiencesWe found that the built-in VBA capability in Excel pro-

vides a simple way for users to customize user interfacesand automate data processing for each application, which isimportant since sensor network is often application-specific.

Our design choice of relying on XML for integrating thedifferent pieces of the system together is crucial as it allowsus to decouple the implementation platform details amongthe individual pieces and thus, simplify the process of in-tegration. The trend that business logic integrations andInternet applications are converging to web services is clear.We believe that the same trend will penetrate the sensornetwork deployments so that static and dynamic data canbe easily combined.

The Visual Studio Tools for Office Systems is very usefulto our implementation. There are numerous built-in opti-mizations in Excel and .NET2.0 for processing XML doc-uments. It allows us to easily build a prototype withoutgetting Excel source code. We can treat Excel components

as an object library and implement our extension in C#.Our extension mainly consists of socket interfaces for com-munication with the gateway and with the SQL server.

7. RELATED WORKThe idea of using the tabular or spreadsheet interface for

managing and processing data is not new; it is used in ev-eryday business, scientific, and industrial settings. It is thisreason why we advocate the spreadsheet approach to man-aging and programming sensor networks. Our contributionis in developing a prototype that demonstrates the poten-tial of this approach for “in-situ” sensor data management.Several other research works have taken similar paths tosimplify sensor data processing and visualization.

TinyDB [7] provides the tabular interface for users to visu-alize collected sensor data. It presents a SQL query interfacefor data processing and provides a primitive tool for datavisualization. Its main goal is to perform in-network pro-cessing in the sensor tier in response to a given SQL query.Tinker [1] is a methodology and framework for data cen-tric sensor network applications. The Excel data processinginterface can be a front end for Tinker.

Moteview from Crossbow4 is a sensor network manage-ment and data collection tool. It supports visualization ofthe physical deployment and maps it with the correspond-ing sensory data. The tool is oriented towards visualizationof sensor data and network statistics such as network topol-ogy. It does not present a programming interface for usersto process the incoming data streams.

The Nucleus management console project at Berkeley5

provides a spreadsheet web interface for showing system in-formation of each sensor node provided it has the TinyOSNucleus run-time installed. The system information canrepresent networking statistics or even the internal statesof each node. The console provides a tabular interface forusers to view and alter such information, thus, performingsystem-wide management and reconfiguration support.

8. FUTURE WORK AND CONCLUSIONWe have successfully built a spreadsheet prototype in Ex-

cel to address three important issues of sensor-net “in-situ”programming, which include real-time data programming,data analysis, and system management and reconfiguration.We built two different classes of applications to demonstratethe feasibility of the spreadsheet approach and presented ourexperience.

Systematic performance and robustness studies on thedatabase connections and full system integration are neces-sary. They allow us to explore the crossover point in offeredload between centralized and distributed stream processingwith Excel. We plan to do such evaluation using our test-bed and grow the scale incrementally.

Beside performance and stability, we should conduct us-ability study of our prototype to guide us on the interfacedesign. We also plan to build other applications to drive thefurther development of the tool.

We only explored some of the data analysis, programmingand system management issues with our current prototype.

4http://www.xbow.com5http://www.tinyos.net/ttx-02-2005/developments/Nucleus%20NMS.ppt

A few interesting and important directions remain to be ex-plored. They include user-interface design on manipulatingmany data streams, new ways of data and network visu-alization, identification of useful statistical functions, andprocess delegation and service composition for the gatewaysand sensor-tier.

9. REFERENCES[1] Elson, J., and Parker, A. Tinker: A tool for

designing data-centric sensor networks. In Fifth Intl.Conf. on Information Processing in Sensor Networks(IPSN 2006), SPOTS track. Nashville, TN. (April2006).

[2] Horey, J., Bridges, P., Maccabe, A., and

Mielke, A. Work in Progress: The design of aspreadsheet interface for sensor networks. In Proc. ofInformation Processing in Sensor Networks(IPSN’05), Los Angeles, CA (April 2005).

[3] Hui, J. W., and Culler, D. The dynamic behaviorof a data dissemination protocol for networkprogramming at scale. In Proc. 2nd ACM Conferenceon Embedded Networked Sensor Systems (SenSys’04),Baltimore, MA (November 2004).

[4] Jones, S. P., Burnett, M., and Blackwell, A. Auser-centred approach to functions in excel. In Proc.of Intl. Conf. on Functional Programming (ICFP’03),Uppsala (Sept 2003), pp. 165–176.

[5] Liu, J., Chu, M., Liu, J., Reich, J., and Zhao, F.

State-centric programming for sensor-actuatornetwork systems. IEEE Pervasive Computing 2, 4(Oct–Dec 2003), 50–62.

[6] Liu, J., and Zhao, F. Towards semantic services forsensor-rich information systems. In Proc. of the 2ndIntl. Workshop on Broadband Advanced SensorNetworks (Basenets’05), Boston, MA (October 2005).

[7] Madden, S. R., Franklin, M. J., Hellerstein,

J. M., and Hong, W. TAG: a Tiny AGgregationService for Ad-Hoc Sensor Networks. In OSDI(December 2002).

[8] Newton, R., and Welsh, M. Region streams:Functional macroprogramming for sensor networks. InProceedings of the First International Workshop onData Management for Sensor Networks (DMSN),Toronto, Canada (Augest 2004).

[9] Ramakrishna Gummadi, Omprakash Gnawali,

R. G. Macro-programming wireless sensor networksusing Kairos. In Proc. of the Intl. Conference onDistributed Computing in Sensor Systems (DCOSS),Marina del Rey, CA (June 2005).

[10] Tolle, G., and Culler, D. Design of anapplication-cooperative management system forwireless sensor networks. In Proc. 2nd EuropeanWorkshop on Wireless Sensor Networks (EWSN),Istanbul, Turkey (January 2005).

[11] Whitehouse, K., Zhao, F., and Liu, J. Semanticstreams: a framework for the composable semanticinterpretation of sensor data. In Proc. EuropeanWorkshop on Wireless Sensor Networks (EWSN’06),Zurich, Switzerland (Feb. 2006).