1 Electronic Blocks -- The “Wood and Nails” of Sensor-Based Embedded Systems Frank Vahid Professor Dept. of Computer Science & Engineering, University of California, Riverside (Also with the Center for Embedded Computer Systems, UC Irvine) Graduate Students: Susan Cotterell (Lysecky), Ryan Mannion, David Sheldon, Kelly Stephenson (graduated MS) This work is being supported by the National Science Foundation (CCR )
April 2005 Frank Vahid, UC Riverside2 of 28 Introduction 1998: Simple Problem Garage door open at night Simple system If garage open at night, blink LED in bedroom receive LED light sensor contact switch AND transmit
April 2005 Frank Vahid, UC Riverside3 of 28 Investigated Solutions -- None Easy Basic components Contact switch, light sensor, logic IC, microcontrollers, wireless tx/rx, LED Issues: electronics, programming, development and test equipment Home-automation components (X10) Electric outlet oriented, home automation focused, non-intuitive Off-the-shelf solution Costly (~$75), hard to find, not customizable (two garage doors?) Gave up, but noticed missing technology Why can’t I just connect a contact switch, light sensor, logic, transmitter, receiver and LED?
April 2005 Frank Vahid, UC Riverside4 of 28 Noticed Similar Problems for a Few Years Applications Sleepwalker detector (from friend, then nursing home employee) Conference room occupied status system (company) Temperature logging system (department, proof of building AC problems) Endangered species video system (colleague in environmental science) Carpooler arrived notifier (friend) Second home water leak detector (insurace underwriter) Large domain, all buildable with right sensor-based blocks
April 2005 Frank Vahid, UC Riverside5 of 28 Revisited in 2001 Electronic Building Blocks -- senior design project Two A students Did terrible Blocks not intuitive, not power efficient, limited applications Problem was harder than originally thought Previous research didn’t help Educational blocks Logiblocs, MagicBlocks, Logidules Board based, non-intuitive, not low power Electronic Blocks (Legos) Simple toy for young kids Programming for novices Lego Mindstorm (MIT research), Phidgets, Robobrix Teaches programming using robot, several-day learning curve
April 2005 Frank Vahid, UC Riverside6 of 28 Observation and Solution Courtesy of Joe Kahn Observation: Microprocessors cheap/smaller Solution: Put microprocessor in “dumb” components (sensors, buttons, LEDs) to enable easy connection eBlocks Easy-to-use matchbox-sized embedded system building Blocks -- just connect No voltage issues, programming, development tools. Garage-open-at-night buildable in minutes. Huge variety of applications. Lasts for years or more The “wood and nails” of embedded systems Enables novices to build useful systems Skilled users can do even more 2003: NSF project began
April 2005 Frank Vahid, UC Riverside7 of 28 Research Issues 1.Human-computer interfacing Block set for novices Design individual blocks 2.Communication Need new digital abstraction 3.Mass producible but tunable nodes 4.CAD tools for novices
April 2005 Frank Vahid, UC Riverside8 of 28 Block set for novices Tradeoff Coarse-grain blocks: simple library, intimidating block Fine-grain blocks: simple blocks, intimidating library (and networks) Built ~100 physical prototypes Observed dozens of people (college, high-school, senior citizens, kids) Built simulator -- more people 1. HCI -- Block Set Definition Programmable eBlock vs
April 2005 Frank Vahid, UC Riverside9 of HCI: Block Set Definition Yes/no blocks Block set Sensors (motion, light, button,...) Output (LED, buzzer, electric relay, logger) Compute Combine, Invert, Yes Prolonger, Toggle, Once-yes Stays-yes, Pulse Generator Result of several iterations and refinements Combine AND OR yes no When A is yes no B is then the output is yes yes time out in Yes Prolonger out in rst Once yes, stays yes no time yes time out in Pulse Generator yellow means ERROR green means YES red means NO Button yes Button no Found yes/no better than 0/1, true/false, on/off Found users need to see yes/no values in out prolong time in out in Toggle rst in out Was “logic” Was “delay”Was “tripper” out in Invert
April 2005 Frank Vahid, UC Riverside10 of HCI -- Design of Individual Blocks (Logic) Previous research -- Everyday people “don’t do logic,” confuse AND/OR Young, D. and Shneiderman, B. A Graphical Filter/Flow Representation of Boolean Queries: A Prototype Implementation and Evaluation. Journal of American Society for Information Science 44 (1993). Pane, J. and Myers, B. Tabular and Textual Methods for Selecting Objects form a Group. Proc. Visual Languages (2000). We wanted a single block: easier to change, fewer blocks in network Collaborated with Crista Lopez, HCI researcher (UC Irvine); studies ongoing A B Out noyesno yesnoyes noyes no yes Logic Block configurable DIP switch AB Out Original logic block -- Complete failure ABOutput noyesno yesnoyes noyes no yes Logic Block Slightly better, still <20% success A B Combine A is yes, B is yes A is yes, B is no A is no, B is yes A is no, B is no The output shouldbe yes when: yes no: Phrased truth table yes no the output should be AB When the input is out Combine A is yes, B is yes A is yes, B is no A is no, B is yes A is no, B is no Phrased truth table embedded in sentence yes no The output should be When the input is out AB AB AB AB AB Combine Colored truth table embedded in sentence Combine AND OR yes no When A is yes no B is then the output is yes Logic Sentence #1 #2 50%-60% success (90% with some training), but not general Work ongoing for “integer” blocks
April 2005 Frank Vahid, UC Riverside11 of Communication Continuous voltage between blocks -- too much power Need packets; microprocessor can sleep between Need new digital abstraction mapping packets to Boolean signals Like mapping of voltage levels to Boolean signals Shannon, C. A Symbolic Analysis of Relay and Switching Circuits. Trans. AIEE, Vol. 57, 1938, pp , Dissertation, Electrical Engineering Department, MIT, Cambridge, 69, SourceSink packets containing “true” or “false” channel (wires or wireless) time 0 1 falsetruefalse time continuous voltage, two levels SourceSink channel (wire)
April 2005 Frank Vahid, UC Riverside12 of Communication -- Digital Abstraction Mapping packets to a continuous model desired signal packets sent on signal changes only sending packets on signal changes and within maximum inter-packet time would result in the desired signal being received maximum inter-packet time violation causes error values in the received signal time f t f ft f ff < < error << Problem: What if source fails or is disconnected -- indistinguishable from continued false Solution: define maximum inter-packet time constraint
April 2005 Frank Vahid, UC Riverside13 of Communication -- Digital Abstraction Problem: sink node designer must know minimum packet separation, lest he/she overdesign Solution: define minimum inter-packet time Creates tradeoffs for source node designers too input sensed by source node packets sent by source node obeying the minimum inter-packet time alternative packets sent, creating a delayed signal logic signal perceived by sink ftf > fttf >> > f Several similar issues (e.g., treatment of errors, startup conditions, block latency, etc.). Resulting constraints define a node technology library Solid basis for node design, composition, and operation -- work ongoing
April 2005 Frank Vahid, UC Riverside14 of Mass Producable but Tunable Nodes Node performance (lifetime, reliability,...) heavily impacted by parameters Packet constraints, baud rate, voltage levels, frequency, error checking bits,... Observed by us and others Adlakha et al 2003; Yuan/Qu 2002; Tilak et al 2002, Heinzelman et al Applications’ performance goals differ Lifetime, reliability, responsiveness,... Solution Design highly-parameterized node Develop methodology for Node developer Application developer (node user) Software Configurable Node Parameters Voltage Clock Frequency Baud Rate … 0xFF 0xC3 0x1A Sleepwalker at Night Alarm A’B Endangered Species Videoing System A+B xFF0xC 0x1 0xFF0xC 0x1 0xFF0xC 0x1 0xFF0xC 0x1 0xFF0xC 0x1 0xFF0xC 0x1 0xFF0xC 0x1 0xFF0xC 0x1 0xFF0xC 0x1 0xFF0xC 0x1 0xFF0xC 0x1
April 2005 Frank Vahid, UC Riverside15 of 28 3.Mass Producable but Tunable Nodes -- Methodology Node Characterization Explore Design Space System Evaluation Application Characterization Design Metric Objective Functions Overall Objective Function Computation and Communication Parameter Definition Design Metric Evaluation Equations Parameter Interdependence Design Metric AchievementSystem Compute and Communicate Protocol Network Deployment 0xFF0x1A0xC3 0xF10x120xC0 0x000x120xC3 Configure Node Parameters CAD Tool Application Developer
April 2005 Frank Vahid, UC Riverside16 of 28 Done by node developer Consists of 3 stages Computation and Communication Parameter Definition Design Metric Evaluation Equations Parameter Interdependence 3. Node Characterization 5V 4.5V 3V 4 bits 1 byte crc 0.25s 10 m hamming parity 1M Hz 100k Hz 32k Hz 1m 0.5s 3s k 100k 200k 300k 455k 800k … 5.3M 7.4M 8M 10M 10.4M 16M 20M K 28.8K Based on datasheets, determine interdependencies between parameters Determine parameters based on hardware options (uC, sensors, etc) and software options (protocols, application requirements, etc)
April 2005 Frank Vahid, UC Riverside17 of 28 Done by Application Developer 2 Types of objective functions Overall Objective Function Weighted sum F overall = (A * F lifetime ) + (B*F reliability ) + (C * F latency ) + (D* F responsiveness ) Designer specifies the relative weight (importance) of each metric Design Metric Objective Functions High-level metrics considered – lifetime, latency, reliability, responsiveness Designer must specify what values are good and bad for each metric (1-good, 0-bad) 3. Application Characterization F lifetime 1 0 Lifetime (years) Mean time between corrupted packets (days) 1 0 F reliability Block latency (seconds) 1 0 F latency Disconnect response (seconds) 1 0 F responsiveness Connect response (seconds) 1 0 F responsiveness Lifetime below 1.5 years bad Lifetime beyond 2.5 years yields minimal improvement Block latency until 0.05 seconds generally meets systems requirements Block latency 0.05 to 0.14 seconds quickly degrades, beyond 0.14 seconds system latency is unacceptable
April 2005 Frank Vahid, UC Riverside18 of 28 Automated exploration Simulated annealing search Feedback to application developer Ultimately yields tuned parameter values Downloaded onto nodes 3. Feedback to Application Developer Config. A Config. B voltage = 5V frequency = 32k Hz … ecc = hamming1 voltage = 4V frequency = 300k Hz … ecc = crc F lifetime 1 0 Lifetime (years) Mean time between corrupted packets (days) 1 0 F reliability Block latency (seconds) 1 0 F latency Disconnect response (seconds) 1 0 F responsiveness Connect response (seconds) 1 0 F responsiveness Prototype tool built, work submitted to upcoming conference
April 2005 Frank Vahid, UC Riverside19 of CAD Tools for Novices Problem 1 Application developer may not have full set of blocks Solution Allow computer-capture using full set, use technology mapping techniques Problem 2 Application developer may create inefficient solution Solution Allow computer capture, optimize network Combine both techniques into CAD tool Prototype tool built, work submitted to upcoming conference
April 2005 Frank Vahid, UC Riverside20 of New Research Direction -- Spatial Programming of Basic Sensor Networks Sensor networks evolving Programming is hard [e.g., Horton, SECON’04 keynote] Sensor network programming languages are for expert programmers, e.g.: SQTL - Shen, C., C. Srisathapornphat, C. Jaikaeo. Sensor Information Networking Architecture and Applications. IEEE Personal Communications, August Sensorware - Boulis, A., M. Srivastava. A Framework for Efficient and Programmable Sensor Networks. Open Architectues and Network Programming Proc., But many sensor network developers are not programmers Scientists, engineers, healthcare workers, homeowners, etc. Programming is difficult for ordinary people Pane, J. & Myers, B. (1996), McIver, L., & Conway, D. (1996), Patil, B., Maetzel, K., & Neuhold, E. (2001), Soloway, E., Bonar, J., & Ehrlich, K. (1983). Fortunately, low-end sensor networks require only simple “programming” High-end sensor networks Expert programmers Low-end sensor networks Non-programming developers
April 2005 Frank Vahid, UC Riverside21 of “Spatial” Programming using eBlocks Spatially-Oriented Paradigm eBlocks µCµC Programmable eBlock Temporally-Oriented Paradigm LEGO Mindstorms C Code µCµC RCX Brick bool inputA = P0^1; bool inputB = P0^2; bool output = P0^3; void main() { if (inputA == YES || inputB == YES) { output = YES; } else { output = NO; } Novices had great success build eBlock systems (physical and on computer) -- use as programming paradigm
April 2005 Frank Vahid, UC Riverside22 of Spatial Programming using eBlocks Tested 20 recent high school graduates Asked them to build equivalent systems using temporal (LEGO Mindstorms) and spatial (eBlocks) programming paradigms 30 minutes to build 6 designs Design Number Type Mindstorms Success Rate eBlocks Success Rate 12-input logic (OR)0 %87.5 % 22-input logic (AND)0 %25 % 3state (toggle)0 %62.5 % 4state (tripper)0 %50 % 5state (on/off)0 %37.5 % 6state (prolong)0 %62.5 %
April 2005 Frank Vahid, UC Riverside23 of 28 User captures design using eBlocks Simulator Synthesis tools partition design based on types and number of programmable blocks available Synthesis tools generates C code for each partition 5. Spatial Programming -- Only Minutes to Program #include #include “sci.h” #include “io.h” #include “constants.h” Unsigned char data_val = ERROR;... main(void) { unsigned I, j; TRISB = 0;... } main(void) { ORTA = 0xff; CMCON = 0x07; TRISA = 0x00; TRISB = 0x02; asm("CLRWDT");... } R. Mannion, H. Hsieh, S. Cotterell, F. Vahid System Synthesis for Networks of Programmable Blocks. Design, Automation and Test in Europe (DATE), March 2005.
April 2005 Frank Vahid, UC Riverside24 of 28 After synthesis, user can program a physical programmable eBlock via a PC cable Synthesis Program a Programmable eBlock 5. Spatial Programming -- Only Minutes to Program
April 2005 Frank Vahid, UC Riverside25 of Programming Directions Increasingly abstract behavior capture Are you trying to detect open at night? Yes Physical nodesGraphical blocksVirtual blocksOnline assistanceUser statement I want to detect any of 3 doors opened at night LED Open-at- night LED Combine Light sensor Contact sensor Combine Light sensor Contact sensor Light sensor Contact sensor x3 Combine LED Open-at- night x3 Combine LED Open-at- night Automatically generated
April 2005 Frank Vahid, UC Riverside26 of 28 Future Work – Extending eBlocks to Integers Extend to integer eBlocks Sensors Temperature, speed, distance, sound, etc. Display LCDs (of varying sizes), data logger, etc. Communication Integer Logic, wireless rx/tx, etc. Number of potential embedded systems we can design increases tremendously Configuration problem becomes harder More options than just yes/no Design space becomes larger
April 2005 Frank Vahid, UC Riverside27 of 28 Applications Tremendously diverse applications buildable with just a dozen blocks Present applications being considered At-home monitoring of aging parent to detect trends or daily situation with Intel Customizable victim notification system With ADV, proposal in final stages with DOJ Localized organic pesticide meterer based on insect counts With ISCA Corp. Endangered species videoing system With UCR environment science colleagues
April 2005 Frank Vahid, UC Riverside28 of 28 Conclusions Everyday people can use eBlocks to build basic but useful systems Required careful block set definition and block design Extensive ongoing and future research Integer blocks Digital abstraction Mass producable tunable nodes CAD for node users eBlocks as a spatial programming paradigm