eBlocks – An Enabling Technology for Basic Sensor Based Systems Susan Cotterell, Ryan Mannion, Frank Vahid *, Harry Hsieh Department of Computer Science and Engineering University of California, Riverside {susanc, rmannion, vahid, * Also with the Center for Embedded Computer Systems at UC Irvine This work is being supported by the National Science Foundation (CCR )

2 of 15 Introduction  Sensor networks are emerging as an important general computing domain Small inexpensive battery-powered sense and compute nodes Tens to thousands of nodes Wired or wireless communication Stringent requirements (power, cost, size) Home Automation Environmental Monitoring Military Applications Medical Monitoring Structure/Building Monitoring

3 of 15  Potential sensor network application developers may not be computer programmers Instead, engineers, scientists, office workers, homeowners, etc.  Existing programmable nodes Flexible, but require programming  Existing off-the-shelf end applications Specialized, so hard to customize Expensive due to small volumes  Our solution – eBlocks Enables non-programming users to create simple but useful customized sensor network applications Introduction Photo: Jason Hill Flexible, hard to program Easy to use, inflexible

4 of 15 eBlocks Overview  eBlocks (UC Riverside) Began as low-cost reusable basic building blocks Enables non-programmers to create basic but useful sensor-based applications Function of each block is pre-defined Block types: Sensors – motion, light, contact, etc. Output – led, electric relay, beeper, etc. Compute – logic, prolong, toggle, etc.  Basic configuration required (dials, switches) Communicate – wireless point-to-point link Users merely connect blocks to create working customized application Evolving into a “spatial” programming methodology for sensor networks with programmable nodes CODES/ISSS’03, SECON’04, CHI’05, DATE’05 Toggle Electric Relay Magnetic Contact Switch Light Sensor Splitter Tripper Motion Sensor 2-Input Logic Button LED

5 of 15 Configure Logic Block to turn led on when it’s night and when door is open Need a function of light sensor output and contact switch output – use Logic Block Creating an application with eBlocks Light Sensor We want to know if garage door open – use contact switch Magnetic Contact Switch 2-Input Logic A’B’ Need something to indicate garage open at night – use led LED Create an application to detect if the garage door is left open at night Choose which blocks to use Plug blocks together using standard plugs Configure blocks if needed (e.g. logic block) We want to detect night – use light sensor Block Connectors

6 of 15 Building eBlocks Systems  The same basic blocks can be used in a variety of applications 2-Input Logic A’B’ Light Sensor Magnetic Contact Switch LED Garage Door Open At Night Detector Motion on Property Detector Motion Sensor 2-Input Logic A+B Prolonger Beeper Sleepwalker at Night Alarm Tripper Motion Sensor 2-Input Logic A’B Light Sensor Button Beeper Animal Videoing System Motion Sensor 2-Input Logic A+B Prolonger eBlock to Camera Interface Light Sensor

7 of 15 Inside eBlocks: Technology  Tiny computer in every block Even the simplest button Enables low-power, and easy connection Block “asleep” >99% of time But user doesn’t notice Communicates tiny computer packets, < 0.1% of time Connecting eBlocks actually creates a computer network Use PIC microprocessor costing <$1, consumes little power Same processor as in blinking tennis shoes Currently in the process of patenting eBlocks Method of adding computing intelligence to previously passive components, method of using such computers to reduce power. button wireless tx

8 of 15 Design Entry/Simulation  User specifies and tests block design  Java-based simulator Blocks added to workspace by dragging blocks from “Available eBlocks” tray Connections created by drawing lines between blocks User can create, experiment, test and configure design

9 of 15  Mapping of pre-defined blocks to programmable blocks Problem – map pre-defined blocks to minimum number of programmable blocks Intermediate blocks (non-sensor, non-output) We assume 2-input/2-output programmable block available  Partitioning problem differs from existing problems Classic bin-packing or knapsack algorithms But we need to be conscious of two constraints – number of inputs and number of outputs Two-dimensional bin-packing problem (cutting stock problem) But number of inputs and outputs of programmable block are mutually independent FPGA synthesis, namely DAG covering But we do not require all nodes to be covered Our goal is to minimize block count, many focus on minimum-delay solutions or approximations Many solutions permit replications – contrary to our goal of minimizing block count Synthesis -- Partitioning Button 2-Input Logic Inverter Splitter Prolonger Prolonger LED Button Splitter LED PROG

10 of 15 Synthesis -- Partitioning Strategies  Exhaustive Search every combination of n blocks into n programmable blocks Extremely long run times (hours)  Aggregation Clusters nodes into subgraphs, continue adding blocks until unable to fit into programmable block Unable to take advantage of convergence thus yields non-optimal results 1-input / 2-output input / 2-output input / 3-output Invalid configuration - packing terminated  Developed a new heuristic – PareDown Based on a decomposition method Takes advantage of convergence Unconstrained by depth at which heuristic looks ahead Runtime complexity O(n 2 )

11 of 15  For each partition a syntax tree is generated to represent equivalent functionality of the partition Able to generate C code for each partition to download unto a programmable block Simulator’s interpreter able to evaluate syntax tree and simulate corresponding behavior Synthesis -- Code Generation Button Splitter LED PROG C Code

12 of 15 Experiments  Conducted numerous experiments in Physical Prototypes Nobody reads/follows the instructions Re-designed blocks to be self- explanatory Added debugging lights to indicate block status Simulator Allows rapid iterations of eBlock design Eliminates hardware ambiguities (i.e. power switch, crossed connections) Enables a wider participations Enables us to save various user-defined systems for later analysis

13 of 15 Physical Prototype and Simulator Usage Summary Date# of Participants PrototypeSimulatorDescription Non-computing users02/09/0413Usability of physical block interfaces Non-computing users04/06/044Usability of physical block interfaces Non-computing users05/10/0441Usability of various logic block interfaces Non-computing users05/20/0440Usability of various logic block interfaces Non-computing users05/21/0467Usability of various logic block interfaces Non-computing users06/29/0410Usability of various logic block interfaces Non-computing users06/30/0416Usability of various logic block interfaces Non-computing users08/03/0418Usability of various state based block interfaces Non-computing users08/06/048Usability of physical, logic, and state block interfaces Non-computing users10/12/049Usability of various logic and state block interfaces Non-computing users10/19/049Usability of physical block interfaces Beginner computing users05/18/0421Usability of various logic block interfaces Beginner computing users06/01/0484Usability of various state based block interfaces Beginner computing users07/08/0422Usability of various logic block interfaces Beginner computing users08/04/0414Usability of various state based block interfaces Intermediate computing users06/03/0450Usability of various logic block interfaces Advanced computing users02/09/046Usability of physical block interfaces Advanced computing users05/27/0439Usability of various state based block interfaces Advanced computing users10/27/0421Usability of physical block interfaces Miscellaneousvaried5Usability of physical, logic, and state block interfaces Total Participants:497  Non-computing users - non-science, non-engineering users (psychology, business, etc. majors)  Beginner users - Students in their first introductory to programming course (<10 weeks)  Intermediate users - Students with 2-3 programming courses  Advanced users - Students with both programming and electronics experience  Miscellaneous - Middle school or high school kids, non-engineering adults

14 of 15 Usability of eBlocks Categories of eBlock SystemsPercentage Success Number of Students Sensor-to-output56%91 Sensors-with-logic54%281 Sensors-with-state66%168 Sensors-with-logic-and-state12%39 Overall 55%579 * * Total number of students is higher than previous table because individual students may have participated in multiple tests  Student participants of various expertise levels None of the students had previous experience with eBlocks  More than half of the students were able to build the first three systems in less than 10 minutes Compared to the days to weeks required by advanced students to build similar systems without the benefit of eBlocks

15 of 15  Summary Presented physical prototypes and graphical tool that can be used by non-computing specialists to develop basic sensor/actuator applications Summarized usage in a large variety of user experiments  Present/Future work includes  Extend eBlocks to integers (presently Boolean)  Deployment of real systems  Proactive health care (Intel)  Insect monitor and automated pesticide deployment (Isca Corporation) Conclusions and Future Work