Electronic Blocks The Wood and Nails of SensorBased
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) http: //www. cs. ucr. edu/~vahid, http: //www. cs. ucr. edu/eblocks Graduate Students: Susan Cotterell (Lysecky), Ryan Mannion, David Sheldon, Kelly Stephenson (graduated MS) This work is being supported by the National Science Foundation (CCR-0311026) 1
Introduction w 1998: Simple Problem n Garage door open at night w Simple system n If garage open at night, blink LED in bedroom transmit AND receive light sensor April 2005 LED contact switch Frank Vahid, UC Riverside 2
Investigated Solutions -- None Easy w Basic components n Contact switch, light sensor, logic IC, microcontrollers, wireless tx/rx, LED l Issues: electronics, programming, development and test equipment w Home-automation components (X 10) n Electric outlet oriented, home automation focused, non-intuitive w Off-the-shelf solution n Costly (~$75), hard to find, not customizable (two garage doors? ) w Gave up, but noticed missing technology n Why can’t I just connect a contact switch, light sensor, logic, transmitter, receiver and LED? April 2005 Frank Vahid, UC Riverside 3
Noticed Similar Problems for a Few Years w Applications n n n 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) w Large domain, all buildable with right sensor-based blocks April 2005 Frank Vahid, UC Riverside 4
Revisited in 2001 w Electronic Building Blocks -- senior design project n n Two A students Did terrible l l Blocks not intuitive, not power efficient, limited applications Problem was harder than originally thought w Previous research didn’t help n Educational blocks l Logiblocs, Magic. Blocks, Logidules w l Electronic Blocks (Legos) w n Board based, non-intuitive, not low power Simple toy for young kids Programming for novices l Lego Mindstorm (MIT research), Phidgets, Robobrix w April 2005 Teaches programming using robot, several-day learning curve Frank Vahid, UC Riverside 5
Observation and Solution w Observation: Microprocessors cheap/smaller w Solution: Put microprocessor in “dumb” components (sensors, buttons, LEDs) to enable easy connection w e. Blocks Courtesy of Joe Kahn w Easy-to-use matchbox-sized embedded system building Blocks -- just connect w No voltage issues, programming, development tools. Garage-open-at-night buildable in minutes. Huge variety of applications. w Lasts for years or more w The “wood and nails” of embedded systems w Enables novices to build useful systems w Skilled users can do even more w 2003: NSF project began April 2005 Frank Vahid, UC Riverside 6
Research Issues 1. Human-computer interfacing w w Block set for novices Design individual blocks 2. Communication w Need new digital abstraction 3. Mass producible but tunable nodes 4. CAD tools for novices April 2005 Frank Vahid, UC Riverside 7
1. HCI -- Block Set Definition w Block set for novices n Tradeoff l l n Programmable e. Block vs Built ~100 physical prototypes l n Coarse-grain blocks: simple library, intimidating block Fine-grain blocks: simple blocks, intimidating library (and networks) Observed dozens of people (college, high-school, senior citizens, kids) Built simulator -- more people l http: //www. cs. ucr. edu/eblocks April 2005 Frank Vahid, UC Riverside 8
1. HCI: Block Set Definition w Yes/no blocks w Block set Button Sensors (motion, light, button, . . . ) Output (LED, buzzer, electric relay, logger) Compute n n n l l yes Button no Found yes/no better than 0/1, true/false, on/off Combine, Invert, Yes Prolonger, Toggle, Once-yes Stays-yes, Pulse Generator Result of several iterations and refinements red means NO yellow means ERROR green means YES Found users need to see yes/no values 123456789 When A is yes no AND B is yes no OR then the output is yes Combine Was “logic” in out Invert in yes time in out Yes Prolonger in in out prolong time out Was “delay” April 2005 in out rst Once yes, stays yes out Toggle yes time 123456789 in in no time out Pulse Generator rst out Was “tripper” Frank Vahid, UC Riverside 9
1. HCI -- Design of Individual Blocks (Logic) w Previous research -- Everyday people “don’t do logic, ” confuse AND/OR n n w w 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 no no A no yes B yes no yes Out no no yes yes Out Logic Block configurable DIP switch Original logic block -- Complete failure B Combine yes no: 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 The output should be yes when: A A no no yes yes yes Slightly better, still <20% success yes no A B yes AND B is yes When A is yes, B is yes A B no no OR When the A B The output When the A is yes, B is no the output input is A B should be input is A is no, B is yes should be then the output is yes A B out Combine A is no, B is no out Combine Logic Sentence Combine Colored truth table embedded in sentence Phrased truth table embedded in sentence Work ongoing for “integer” blocks April 2005 B Output no no yes no Logic Block Frank Vahid, UC Riverside #2 #1 50%-60% success (90% with some training), but not general 10
2. Communication w Continuous voltage between blocks -- too much power n n Need packets; microprocessor can sleep between Need new digital abstraction mapping packets to Boolean signals l Like mapping of voltage levels to Boolean signals w Shannon, C. A Symbolic Analysis of Relay and Switching Circuits. Trans. AIEE, Vol. 57, 1938, pp. 713 -723, Dissertation, Electrical Engineering Department, MIT, Cambridge, 69, 1940. Source channel (wire) Sink continuous voltage, two levels 0. 8 0 time 1 0 time Source channel (wires or wireless) packets containing “true” or “false” April 2005 Sink false true false time Frank Vahid, UC Riverside 11
2. Communication -- Digital Abstraction w Mapping packets to a continuous model desired signal time t f packets sent on signal changes only f Problem: What if source fails or is disconnected -- indistinguishable from continued false Solution: define maximum inter-packet time constraint < < error < f error maximum inter-packet time violation causes error values in the received signal f sending packets on signal changes and within maximum inter-packet time would result in the desired signal being received < f April 2005 t f Frank Vahid, UC Riverside 12
2. Communication -- Digital Abstraction w w Problem: sink node designer must know minimum packet separation, lest he/she overdesign Solution: define minimum inter-packet time n Creates tradeoffs for source node designers too input sensed by source node f t > f packets sent by source node obeying the minimum inter-packet time logic signal perceived by sink f > t > f alternative packets sent, creating a delayed signal logic signal perceived by sink • 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 Riverside 13
3. Mass Producable but Tunable Nodes w Node performance (lifetime, reliability, . . . ) heavily impacted by parameters n n Voltage 0 x. FF Clock Frequency 0 x. C 3 Baud Rate 0 x 1 A … Packet constraints, baud rate, voltage levels, frequency, error checking bits, . . . Observed by us and others l Endangered Species Videoing System 0 x. FF Adlakha et al 2003; Yuan/Qu 2002; Tilak et al 2002, Heinzelman et al 2000. 123456789 0 x. FF 0 x 1 n 0 x. C 0 x. FF 0 x. C 0 x 1 A+B Lifetime, reliability, responsiveness, . . . w Solution n 0 x. C 0 x 1 w Applications’ performance goals differ n Software Configurable Node Parameters Sleepwalker at Night Alarm Design highly-parameterized node Develop methodology for l l Node developer Application developer (node user) 0 x. FF 0 x. C 0 x 1 0 x. FF 0 x. C A’B 0 x 1 April 2005 Frank Vahid, UC Riverside 14
3. Mass Producable but Tunable Nodes -Methodology CAD Tool Application Developer Configure Node Parameters 0 x. FF 0 x 1 A 0 x. C 3 0 x. F 1 0 x 12 0 x. C 0 0 x 00 0 x 12 0 x. C 3 Computation and Communication Parameter Definition Design Metric Objective Functions Design Metric Evaluation Equations Overall Objective Function Parameter Interdependence Node Characterization Application Characterization Explore Design Space Network Deployment System Compute and Communicate Protocol Design Metric Achievement System Evaluation April 2005 Frank Vahid, UC Riverside 15
3. Node Characterization Determine parameters based on hardware options (u. C, sensors, etc) and software options (protocols, application requirements, etc) w Done by node developer w Consists of 3 stages n n n 5 V Computation and Communication Parameter Definition Design Metric Evaluation Equations Parameter Interdependence hamming 10 m 100 k Hz 0. 25 s 4 bits crc 32 k Hz 0. 5 s 4. 5 V 3 s 1 m parity 1 M Hz 1 byte 3 V Based on datasheets, determine interdependencies between parameters 3. 0 3. 5 4. 0 4. 5 5. 0 5. 5 April 2005 Frank Vahid, UC Riverside 32 k 100 k 200 k 300 k 455 k 800 k … 5. 3 M 7. 4 M 8 M 10. 4 M 16 M 20 M 1200 2400 4800 9600 14. 4 K 28. 8 K 16
3. Application Characterization Done by Application Developer 2 Types of objective functions Overall Objective Function n l l l Weighted sum Foverall = (A * Flifetime) + (B*Freliability) + (C * Flatency) + (D* Fresponsiveness) Designer specifies the relative weight (importance) of each metric Design Metric Objective Functions Block latency (seconds) Mean time between corrupted packets (days) Fresponsiveness 1 0 0 0. 10 0. 25 0. 50 1 2 3 4 5 10 30 60 300 600 0. 14 0. 05 0 3 3. 5 2 2. 5 1 1. 5 0 Lifetime (years) 0 1 Flatency Flifetime 0 0 1 1 Freliability 1 1 0. 25 0. 50 1 2 3 4 5 10 30 60 300 600 1800 l High-level metrics considered – lifetime, latency, reliability, responsiveness Designer must specify what values are good and bad for each metric (1 -good, 0 -bad) Fresponsiveness l 730 n 365 w w Disconnect response (seconds) Lifetime below 1. 5 years bad Block latency until 0. 05 seconds generally meets systems requirements Lifetime beyond 2. 5 years yields minimal improvement Block latency 0. 05 to 0. 14 seconds quickly degrades, beyond 0. 14 seconds system latency is unacceptable April 2005 Frank Vahid, UC Riverside Connect response (seconds) 17
3. Feedback to Application Developer n 3 3. 5 2 2. 5 1 1. 5 0 … Lifetime (years) 1 ecc = hamming 1 Downloaded onto nodes 0. 14 0 0. 05 w Feedback to application developer w Ultimately yields tuned parameter values 0 voltage = 5 V frequency = 32 k Hz 0 Simulated annealing search Flatency n Config. A 0. 5 w Automated exploration Flifetime 1 Block latency (seconds) voltage = 4 V frequency = 300 k Hz 730 365 0 1 Config. B Freliability 1 Mean time between corrupted packets (days) … 1 0 0. 10 0. 25 0. 50 1 2 3 4 5 10 30 60 300 600 Fresponsiveness ecc = crc Connect response (seconds) 0 0. 25 0. 50 1 2 3 4 5 10 30 60 300 600 1800 Prototype tool built, work submitted to upcoming conference Fresponsiveness 1 Disconnect response (seconds) April 2005 Frank Vahid, UC Riverside 18
4. CAD Tools for Novices w Problem 1 n n Application developer may not have full set of blocks Solution l Allow computer-capture using full set, use technology mapping techniques w Problem 2 n n Application developer may create inefficient solution Solution l Allow computer capture, optimize network w Combine both techniques into CAD tool Prototype tool built, work submitted to upcoming conference April 2005 Frank Vahid, UC Riverside 19
5. New Research Direction -- Spatial Programming of Basic Sensor Networks w Sensor networks evolving n n Programming is hard [e. g. , Horton, SECON’ 04 keynote] Sensor network programming languages are for expert programmers, e. g. : l l n SQTL - Shen, C. Srisathapornphat, C. Jaikaeo. Sensor Information Networking Architecture and Applications. IEEE Personal Communications, August 2001. Sensorware - Boulis, A. , M. Srivastava. A Framework for Efficient and Programmable Sensor Networks. Open Architectues and Network Programming Proc. , 2002. But many sensor network developers are not programmers l l Scientists, engineers, healthcare workers, homeowners, etc. Programming is difficult for ordinary people w n High-end sensor networks Expert programmers Pane, J. & Myers, B. (1996), Mc. Iver, 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” April 2005 Frank Vahid, UC Riverside Low-end sensor networks Non-programming developers 20
5. “Spatial” Programming using e. Blocks • Novices had great success build e. Block systems (physical and on computer) -- use as programming paradigm Temporally-Oriented Paradigm Spatially-Oriented Paradigm e. Blocks C Code bool input. A = P 0^1; bool input. B = P 0^2; bool output = P 0^3; void main() { if (input. A == YES || input. B == YES) { output = YES; } else { output = NO; } µC } LEGO Mindstorms µC Programmable e. Block RCX Brick April 2005 Frank Vahid, UC Riverside 21
5. Spatial Programming using e. Blocks w Tested 20 recent high school graduates w Asked them to build equivalent systems using temporal (LEGO Mindstorms) and spatial (e. Blocks) programming paradigms w 30 minutes to build 6 designs April 2005 Design Number Type Mindstorms Success Rate 1 2 -input logic (OR) 0% 87. 5 % 2 2 -input logic (AND) 0% 25 % 3 state (toggle) 0% 62. 5 % 4 state (tripper) 0% 50 % 5 state (on/off) 0% 37. 5 % 6 state (prolong) 0% 62. 5 % Frank Vahid, UC Riverside e. Blocks Success Rate 22
5. Spatial Programming -- Only Minutes to Program w User captures design using e. Blocks Simulator w Synthesis tools partition design based on types and number of programmable blocks available w Synthesis tools generates C code for each partition #include <pic. h> #include “sci. h” main(void) { #include “io. h” ORTA = 0 xff; #include “constants. h” CMCON = 0 x 07; Unsigned char data_val = ERROR; TRISA = 0 x 00; . . . TRISB = 0 x 02; main(void) { asm("CLRWDT"); unsigned I, j; TRISB = 0; . . . } April 2005 Frank Vahid, UC Riverside . . . } R. Mannion, H. Hsieh, S. Cotterell, F. Vahid System Synthesis for Networks of Programmable Blocks. Design, Automation and Test in Europe (DATE), March 2005. 23
5. Spatial Programming -- Only Minutes to Program w After synthesis, user can program a physical programmable e. Block via a PC cable Synthesis Program a Programmable e. Block April 2005 Frank Vahid, UC Riverside 24
5. Programming Directions w Increasingly abstract behavior capture Physical nodes Virtual blocks Graphical blocks Online assistance Light sensor Open-atnight Combine Are you trying to detect open at night? Yes LED Open-atnight Combine LED Light sensor Automatically generated Contact sensor Frank Vahid, UC Riverside Open-atnight Automatically generated Combine x 3 April 2005 I want to detect any of 3 doors opened at night LED Light sensor Contact sensor User statement Combine 25 LED
Future Work – Extending e. Blocks to Integers w Extend to integer e. Blocks n Sensors l n Display l n Temperature, speed, distance, sound, etc. LCDs (of varying sizes), data logger, etc. Communication l Integer Logic, wireless rx/tx, etc. w Number of potential embedded systems we can design increases tremendously w Configuration problem becomes harder n More options than just yes/no w Design space becomes larger April 2005 Frank Vahid, UC Riverside 26
Applications w Tremendously diverse applications buildable with just a dozen blocks w Present applications being considered n At-home monitoring of aging parent to detect trends or daily situation l n Customizable victim notification system l n With ADV, proposal in final stages with DOJ Localized organic pesticide meterer based on insect counts l n with Intel With ISCA Corp. Endangered species videoing system l April 2005 With UCR environment science colleagues Frank Vahid, UC Riverside 27
Conclusions w Everyday people can use e. Blocks to build basic but useful systems n Required careful block set definition and block design w Extensive ongoing and future research n n n Integer blocks Digital abstraction Mass producable tunable nodes CAD for node users e. Blocks as a spatial programming paradigm April 2005 Frank Vahid, UC Riverside 28
- Slides: 28
