Archetype-Based Design: Sensor Network Programming for ApplicationExperts, Not Just Programming ExpertsLan S. Bai† Robert P. Dick† Peter A. Dinda‡{lanbai, dickrp}@umich.edu [email protected] of Michigan† Northwestern University‡ABSTRACTSensor network application experts such as biologists, ge-ologists, and environmental engineers generally have littleexperience with, and little patience for, general-purpose andoften low-level sensor network programming languages. Webelieve sensor network languages should be designed for ap-plication experts, who may not be expert programmers. Tofurther that goal, we propose the concepts of sensor net-work application archetypes, archetype-specific languages,and archetype templates. Our work makes the following con-tributions. (1) We have examined a wide range of wirelesssensor networks to develop a taxonomy of seven archetypes.This taxonomy permits the design of compact languages thatare appropriate for novice programmers. (2) We developeda language (named WASP) and its associated compiler fora commonly encountered archetype. (3) We conducted userstudies to evaluate the suitability of WASP and several alter-natives for novice programmers. To the best of our knowl-edge, this 56-hour 28-user study is the first to evaluate abroad range of sensor network languages (TinyScript, Tiny-SQL, SwissQM, and TinyTemplate). On average, users ofother languages successfully implemented their assigned ap-plications 30.6% of the time. Among the successful comple-tions, the average development time was 21.7 minutes. Usersof WASP had an average success rate of 80.6%, and an av-erage development time of 12.1 minutes (an improvement of44.4%).1. INTRODUCTIONWireless sensor networks have the potential to allow in-expensive, real-time, and broadly-distributed data collectionand analysis for the first time in history. Application experts,such as geologists, entrepreneurs, civil engineers, and biol-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’09, April 13–16, 2009, San Francisco, California, USA.Copyright 2009 ACM 978-1-60558-371-6/09/04 ...$5.00.ogists have the most to gain. However, these applicationexperts generally have little experience with, and little pa-tience for, the general-purpose, node-level languages avail-able for sensor network programming. As a result, appli-cation experts are forced to rely on embedded system ex-perts to implement their ideas. Almost all existing sensornetwork deployments are implemented by embedded systemexperts. This approach is costly. Separating design and im-plementation in this way can also lead to errors due to mis-communication between application experts and embeddedsystem experts. Application experts generally have limitedawareness of the constraints on sensor network capabilitiesimposed by hardware and software limitations. On the otherhand, embedded system experts know little about the appli-cation requirements, which are tightly related to the mea-sured objects and the working environments. In addition,since application experts’ and embedded system experts’ do-main languages differ significantly, this can cause confusionand misunderstandings that lead to incorrect implementa-tions. Consequently, a collaboration between application ex-perts and embedded system experts requires a large amountof communication, negotiation, redesign, and reimplemen-tation. Many potential users of wireless sensor networksconsider them because they have the potential to save timeand money. When these potential benefits are outweighedby substantial increases in implementation complexity com-pared to the bulky and expensive, but often easy-to-deploy,sensing solutions already in use, wireless sensor networkswill remain unused.We believe that appropriate high-level programming lan-guages and compilers have the potential to make wirelesssensor networks accessible to the application experts whohave the most to benefit from their use. We propose design-ing sensor network languages with the novice programmer inmind, hence the following language features are desirable.1. The languages should support specifying application-level requirements, not just node-level behavior.2. The languages should not expose low-level implemen-tation details, such as resource management, commu-nication protocols, and optimizations, to users. Usersshould need only specify application requirements.3. The languages should be compact and easy to use. Peo-ple with limited or no programming experience shouldbe able to almost immediately learn and use them tospecify correct sensor network applications.The first step to designing a programming language is todetermine the scope of applications it will support. Thereare two extremes of the range of design philosophies a lan-guage designer might adopt: a language might be entirelygeneral-purpose or entirely application-specific. General-purpose languages can be used to specify any application.However, all other things being equal, this flexibility is ob-tained at the cost of increased language complexity. General-purpose languages have advantages: once such a language islearned, one can write any application with it. However, anovice programmer may never be willing to expend the timeto learn it. In contrast, application-specific languages areusually simple and compact, but support one type of appli-cation. This makes it more difficult for a novice programmerto select the appropriate language for an application, and re-quires the design of numerous languages – one for each typeof application. Designers need to learn a new language witheach new application. We believe the optimal design philos-ophy for sensor network programming languages is some-where between these extremes: a moderate number of spe-cialized languages that together cover most of the sensor net-work application domain. Ideally, each of these languagesshould be easy to learn and use for novice programmers.The question remains, “what is the appropriate granular-ity of the application groups?”, i.e., “how specialized shouldthe languages be?” To find the best tradeoff