1. Berkeley NEST Wireless OEP David Culler, Shankar Sastry, Eric Brewer, Kris Pister, David Wagner Unversity of California, Berkeley

2. 2/6/2002NEST PI Meeting - Berkeley OEP Administrative Secure Language-Based Adaptive Service Platform (SLAP) for Large-Scale Embedded Sensor Networks PM: Vijay Raghavan PIs: –David Culler, culler@cs.berkeley.edu –Eric Brewer, brewer@cs.berkeley.edu –David Wagner, daw@cs.berkeley.edu –Shankar Sastry, sastry@eecs.berkeley.edu –Kris Pister, pister@eecs.berkeley.edu University of California, Berkeley Award Start Date: 6/1/01 Award End Date: 10/31/04 Agent Name and Organization:Juan Carbonell, AFWL

3. 2/6/2002NEST PI Meeting - Berkeley OEP Subcontractors and Collaborators Crossbow –manufactures & tests node and sensor boards –offers for sale beyond initial contract run UCLA –development of networking algorithms, coordination services, testbed development Intel Research –application studies, base-station support, ubicomp usage, language design –potential next generation design and manufacturing collaboration Kestrel, UCI –miniproject synthesis and composition USC, U Wash., UIUC, UVA, Ohio State, Bosch, Rutgers, Dartmouth, GATECH, Xerox

4. 2/6/2002NEST PI Meeting - Berkeley OEP Problem Description and Program Objective Develop a platform for NEST research that will dramatically accelerate the development of algorithms, services, and their composition into applications –allowing algorithmic work to move from theory to practice at a very early stage, without each group developing extensive infrastructure –Critical barriers are scale, concurrency, complexity, and uncertainty. Permit demonstration of fine-grain distributed control Define series of challenge applications to drive the program components Metric of success –rate of development of new algorithmic components –degree of reuse of platform components –scale of integration across program –number of novel factors influencing algorithm design revealed through hands-on empirical use

5. 2/6/2002NEST PI Meeting - Berkeley OEP Secure Language-Based Adaptive Service Platform for Large-scale Embedded Sensor Networks New Ideas Small, flexible, low-cost, low-power, wireless embedded sensor devices Tiny event-driven, robust, open component OS for NEST devices - mcast, AM, prune algorithmic primitives FSM high-concurrency prog. env. Resilient aggregation - for security and other noise Macroprogramming unstructured aggregates Adversarial Simulation Impact Enable creation of embedded distributed syst. of unprecedented scale and role - 1,000s of tiny networked sensors Enable new classes of applications integrated with physical world - Greatly simplify creation of distributed systems at extreme scale (HW & SW) - fine-grained distributed control Accelerate prototyping and evaluation of new coord. & synthesis algorithms Enable new, robust basis for distributed, embedded software thru platform design & novel tools for simulation and visualization Drive NW sensor challenge applications Schedule June 01 Start June 02June 03 Oct 04 End June 04 OEP1 10x100 kits OEP2OEP3 OEP1 defn OEP1 eval OEP2 proto FSM on OEP1 OEP2 analysis chal. app defn log & trace adv. sim macro. lang design OEP2 platform design OEP3 platform design lang based optimize & viz final prog. env chal app & evaluation David Culler, Eric Brewer, David Wagner UC Berkeley

6. 2/6/2002NEST PI Meeting - Berkeley OEP Project Status: on-schedule Completed design, manufacturing, and testing of MICA low-power wireless platform Refined extension connector specification Completed design and prototyping of rich sensor card for MICA (production to complete April 1) Mechanical design of compact package Evaluation and structured redesign of TinyOS stack Code release of TinyOS 0.6 with new MICA 40 kbps stack, flash logger Adapted ATMEL studio Preliminary static command/event analysis Demonstration of RC5 encryption in < 2kB Demonstration application of environmental monitoring, tracking, and social network –energy efficient time synchronization and multihop networking

7. 2/6/2002NEST PI Meeting - Berkeley OEP Platform: Ahead of Schedule or Unplanned Developed TOSSIM for detailed simulation up to 1000s of nodes (uniform application) Demonstration of initial aggregation operators Prototype Implementation of Geocast Prototype visual TinyOS programming tool Development and calibration of RF-based localization components Implementation of general actuator control (with SDR pgm) Studies of large-scale algorithm dynamics

8. 2/6/2002NEST PI Meeting - Berkeley OEP The MICA architecture Atmel ATMEGA103 –4 Mhz 8-bit CPU –128KB Instruction Memory –4KB RAM 4 Mbit flash ( AT45DB041B) –SPI interface –1-4 uj/bit r/w RFM TR1000 radio –50 kb/s – ASK –Focused hardware acceleration Network programming Same 51-pin connector –Analog compare + interrupts Same tool chain Provides sub microsecond RF synchronization primitive Cost-effective power source 2xAA form factor Atmega103 Microcontroller TR 1000 Radio Transceiver 4Mbit External Flash 51-Pin I/O Expansion Connector Power Regulation MAX1678 (3V) DS2401 Unique ID 8 Analog I/O 8 Programming Lines SPI Bus Coprocessor Transmission Power Control Hardware Accelerators Digital I/O

9. 2/6/2002NEST PI Meeting - Berkeley OEP Rich Sensor board PHOTO TEMP MAGNETOMETERACCELEROMETER MICROPHONE SOUNDER Mica PINS ADC Signals (ADC1-ADC6) I 2 C Bus On/Off Control Interrupt X Axis Y Axis Gain Adjustment Mic Signal Tone Intr 2.25 in 1.25 in Microphone Accelerometer Light Sensor Temperature Sensor SounderMagnetometer

10. 2/6/2002NEST PI Meeting - Berkeley OEP Protoype Boards – beyond platform Motor-Servo board interfaces any combination of two motors, servos, and solenoids to a toy car platform Sensor boards are currently being prototyped, including a whisker board for obstacle detection and a digital accelerometer (ADXL202) board for crude odometry Low-level software components written to abstract hardware Motor-Servo Board Whisker-Accel Board GPS Board

11. 2/6/2002NEST PI Meeting - Berkeley OEP Project Status: Challenge Appln level field (400-2500 m 2 ) with 5-15 tree-like obstacles Pursuers’ team –400-1000 nodes –3-5 ground pursuers, –1-2 aerial pursuers Evaders’ team –1-3 ground evaders Self organization of motes Localization of evaders –Evaders’ position and velocity estimation by sensor network –Communication of sensors’ estimates to ground pursuers Design of a pursuit strategy Minimize capture time and energy –accuracy of localization & synch –stability of network and dist. alg Localization Communication Synchronization Tracking Wor ld Sensor Interface Scheduler

12. 2/6/2002NEST PI Meeting - Berkeley OEP Project Plans Complete 1.0 release of TinyOS Support facility for project groups using the platform Logging and analysis of platform usage, failure modes, energy profile. Analysis of hardware design and TinyOS relative to evolving project needs Develop simulation environment Design specification for robust version of TinyOS Design of low-level programming language for FSM component Preliminary Analysis of techniques for resilient aggregation and random sampling Demonstration of distributed control loops

13. 2/6/2002NEST PI Meeting - Berkeley OEP Project Schedule and Milestones Next Six Months –Complete TinyOS 1.0 (network programming, rssi, time synch) –Deliver sensor board –Tracking demonstration –Challenge App. Spec –FSM programming –OEP 1 evaluation June 01 Start June 02June 03June 04 OEP1 10x100 kits OEP2OEP3 OEP1 defn OEP1 eval FSM on OEP1 chal. app defn log & trace adv. sim macro. lang design OEP2 platform design OEP3 platform design final prog. env chal app & evaluation lang based optimize & viz

14. 2/6/2002NEST PI Meeting - Berkeley OEP Technology Transition/Transfer All HW and SW open and web-accessible –several groups building new boards & components –source forge Crossbow is manufacturing and marketing current platform –plan to incorporate ATMEGA 128 in spring –exploring chipcon radio BOSCH exploring use for intelligent alarms Intel Research collaborating on platform design and use –potential avenue for Silicon Radio and MEMS efforts –may collaborate on development of next generation platforms

15. 2/6/2002NEST PI Meeting - Berkeley OEP Program Issues Is the partitioning into platform / application / coordination services / synthesis services / composition services natural? Appropriate? Is there a common understanding of what it means? Is is clear who is responsible for what? Many seem to be “the stuff that glues together what others develop” rather than identifiable “meat”