1 / 28

Electronic Blocks -- The “Wood and Nails” of Sensor-Based Embedded Systems

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)

rspence
Download Presentation

Electronic Blocks -- The “Wood and Nails” of Sensor-Based Embedded Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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) 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)

  2. transmit LED receive AND light sensor contact switch Introduction • 1998: Simple Problem • Garage door open at night • Simple system • If garage open at night, blink LED in bedroom Frank Vahid, UC Riverside

  3. 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? Frank Vahid, UC Riverside

  4. 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 Frank Vahid, UC Riverside

  5. 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 Frank Vahid, UC Riverside

  6. Observation and Solution • 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 Courtesy of Joe Kahn Frank Vahid, UC Riverside

  7. Research Issues • Human-computer interfacing • Block set for novices • Design individual blocks • Communication • Need new digital abstraction • Mass producible but tunable nodes • CAD tools for novices Frank Vahid, UC Riverside

  8. Programmable eBlock 1. HCI -- Block Set Definition • 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 • http://www.cs.ucr.edu/eblocks vs Frank Vahid, UC Riverside

  9. out in out in Pulse Generator Yes Prolonger out out in in Toggle Invert 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 yes time yes no yes no When A is AND OR B is yes time in 1 2 3 4 5 6 7 8 9 out rst then the output is yes no time Once yes, stays yes Combine in rst out Button Button yes no red means NO yellow means ERROR green means YES 1. 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 Found yes/no better than 0/1, true/false, on/off Found users need to see yes/no values in in Was “logic” out out out prolong time Was “delay” Was “tripper” Frank Vahid, UC Riverside

  10. yes no A B B A The output should be yes when: Out A B yes no: A is yes, B is yes A is yes, B is yes When the input is the output should be A is yes, B is no configurable DIP switch A is yes, B is no Combine A A is no, B is yes A is no, B is yes A is no, B is no A is no, B is no out B Combine Phrased truth table Phrased truth table embedded in sentence Out Logic Block yes no yes no When A is AND OR B is then the output is yes Combine Logic Sentence A B Output yes no A B A B When the input is The output should be A B A B A B out Combine Colored truth table embedded in sentence Logic Block no no no no no no yes yes no no yes yes no no yes yes yes yes no no no no yes yes yes yes yes yes no no yes yes 1. 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 Original logic block -- Complete failure Slightly better, still <20% success #1 #2 50%-60% success (90% with some training), but not general Work ongoing for “integer” blocks Frank Vahid, UC Riverside

  11. Source channel (wire) Sink 0.8 0 continuous voltage, two levels time 1 0 Source channel (wires or wireless) Sink time packets containing “true” or “false” false true false time 2. 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. 713-723, Dissertation, Electrical Engineering Department, MIT, Cambridge, 69, 1940. Frank Vahid, UC Riverside

  12. 2. Communication -- Digital Abstraction • Mapping packets to a continuous model desired signal time packets sent on signal changes only t f f Problem: What if source fails or is disconnected -- indistinguishable from continued false Solution: define maximum inter-packet time constraint < < maximum inter-packet time violation causes error values in the received signal error error < < f t f f f sending packets on signal changes and within maximum inter-packet time would result in the desired signal being received Frank Vahid, UC Riverside

  13. input sensed by source node > f t f packets sent by source node obeying the minimum inter-packet time logic signal perceived by sink alternative packets sent, creating a delayed signal logic signal perceived by sink > > > f t f t f 2. 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 • 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 Frank Vahid, UC Riverside

  14. 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xC 0xC 0xC 0xC 0xC 0xC 0xC 0xC 0xC 0xC 0x1 0x1 0x1 0x1 0x1 0x1 0x1 0x1 0x1 0x1 3. Mass Producable but Tunable Nodes Software Configurable Node Parameters Voltage 0xFF • 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 2000. • Applications’ performance goals differ • Lifetime, reliability, responsiveness, ... • Solution • Design highly-parameterized node • Develop methodology for • Node developer • Application developer (node user) Clock Frequency 0xC3 Baud Rate 0x1A … Endangered Species Videoing System 1 2 3 4 5 6 7 8 9 A+B Sleepwalker at Night Alarm 0xFF 0xC 0x1 A’B Frank Vahid, UC Riverside

  15. CAD Tool Node Characterization Application Characterization Computation and Communication Parameter Definition Design Metric Objective Functions Application Developer Design Metric Evaluation Equations Overall Objective Function Parameter Interdependence Configure Node Parameters Explore Design Space System Evaluation Network Deployment System Compute and Communicate Protocol Design Metric Achievement 0xFF 0xF1 0x00 0x1A 0x12 0x12 0xC3 0xC0 0xC3 3.Mass Producable but Tunable Nodes -- Methodology Frank Vahid, UC Riverside

  16. 5V crc 32k Hz hamming 100k Hz 10 m 3s 4.5V 0.5s 0.25s 1M Hz 1m 4 bits parity 1 byte 3V 3.0 3.5 4.0 4.5 5.0 5.5 32k 100k 200k 300k 455k 800k … 5.3M 7.4M 8M 10M 10.4M 16M 20M 1200 2400 4800 9600 14.4K 28.8K 3. Node Characterization Determine parameters based on hardware options (uC, sensors, etc) and software options (protocols, application requirements, etc) • Done by node developer • Consists of 3 stages • Computation and Communication Parameter Definition • Design Metric Evaluation Equations • Parameter Interdependence Based on datasheets, determine interdependencies between parameters Frank Vahid, UC Riverside

  17. 1 1 Freliability Flifetime 0 0 365 1 730 0 0.5 1 1.5 2 3 3.5 2.5 Mean time between corrupted packets (days) Lifetime (years) 1 1 1 Flatency Fresponsiveness Fresponsiveness Lifetime below 1.5 years bad Block latency until 0.05 seconds generally meets systems requirements 0 0 0 0 0.14 0.05 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 0.25 0.50 4 10 30 1 2 3 5 60 300 600 1800 0.10 0.25 0.50 1 2 3 4 5 10 30 60 300 600 Block latency (seconds) Connect response (seconds) Disconnect response (seconds) 3. Application Characterization • Done by Application Developer • 2 Types of objective functions • Overall Objective Function • Weighted sum • Foverall = (A * Flifetime) + (B*Freliability) + (C * Flatency) + (D* Fresponsiveness) • 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) Frank Vahid, UC Riverside

  18. 1 1 Freliability Flifetime 0 0 365 1 730 0 0.5 1 1.5 2 3 3.5 2.5 Mean time between corrupted packets (days) Lifetime (years) 1 1 1 Flatency Fresponsiveness Fresponsiveness 0 0 0 0 0.14 0.05 0.25 0.50 4 10 30 1 2 3 5 60 300 600 1800 0.10 0.25 0.50 1 2 3 4 5 10 30 60 300 600 Block latency (seconds) Connect response (seconds) Disconnect response (seconds) 3. Feedback to Application Developer • Automated exploration • Simulated annealing search • Feedback to application developer • Ultimately yields tuned parameter values • Downloaded onto nodes Config. A voltage = 5V frequency = 32k Hz … ecc = hamming1 Config. B voltage = 4V frequency = 300k Hz … ecc = crc Prototype tool built, work submitted to upcoming conference Frank Vahid, UC Riverside

  19. 4. 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 Frank Vahid, UC Riverside

  20. 5. New Research Direction -- Spatial Programming of Basic Sensor Networks High-end sensor networks Expert programmers • 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 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 • 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” Low-end sensor networks Non-programming developers Frank Vahid, UC Riverside

  21. 5. “Spatial” Programming using eBlocks • Novices had great success build eBlock systems (physical and on computer) -- use as programming paradigm Temporally-Oriented Paradigm Spatially-Oriented Paradigm eBlocks C Code bool inputA = P0^1; bool inputB = P0^2; bool output = P0^3; void main() { if (inputA == YES || inputB == YES) { output = YES; } else { output = NO; } } µC LEGO Mindstorms µC Programmable eBlock RCX Brick Frank Vahid, UC Riverside

  22. 5. 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 Frank Vahid, UC Riverside

  23. 5. Spatial Programming -- Only Minutes to Program • 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 #include <pic.h>#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. Frank Vahid, UC Riverside

  24. 5. Spatial Programming -- Only Minutes to Program • After synthesis, user can program a physical programmable eBlock via a PC cable Synthesis Program a Programmable eBlock Frank Vahid, UC Riverside

  25. LED LED LED LED Physical nodes Graphical blocks Virtual blocks Online assistance User statement Combine Combine Combine Combine I want to detect any of 3 doors opened at night Light sensor Contact sensor Light sensor Open-at-night Contact sensor Are you trying to detect open at night? Yes Automatically generated Open-at-night Open-at-night Open-at-night Open-at-night Open-at-night Open-at-night Automatically generated Light sensor x3 x3 Contact sensor 5. Programming Directions • Increasingly abstract behavior capture Frank Vahid, UC Riverside

  26. 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 Frank Vahid, UC Riverside

  27. 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 Frank Vahid, UC Riverside

  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 Frank Vahid, UC Riverside

More Related