1. eBlocks: Enabling Design of Basic Embedded Systems by Novice Users Susan Lysecky Dept. of Electrical and Computer Engineering University of Arizona slysecky@ece.arizona.edu Frank Vahid Dept. of Computer Science and Engineering University of California, Riverside vahid@cs.ucr.edu *Also with the Center for Embedded Computer Systems at UC Irvine This work is being supported by the National Science Foundation Grant CCR-0311026

2. 2 of 22 Introduction Large class of applications exists comprised of sensor-based systems Transform sensor data and feed the proceed data to output or actuator nodes Residential Wireless doorbell, mail alert, gate open, motion on property, package on porch, customized motion lights, carpool alert Office/Commercial Cafeteria food alert, front desk notifier, conference rooms in use, copy machine in use, visitor at front gate, reserved parking spot detector Countless applications Health Sleepwalker detection, hard-of-hearing sound alert, water leak alert... Environmental Temperature logging, animal tracking,... ? ? ?

3. 3 of 22 Why aren’t these systems more prevalent? http://www.smarthome.com Off-the-shelf Introduction Photo: Jason Hill http://www.dustnetworks.com/ http://www.xbow.com/ Programmable Button Motion Sensor 2-Input Logic LED Developed for specific application Hard to customize Expensive – low volume GOAL – enable novice users to build customized embedded systems Provide building blocks to enable customization Eliminate need for programming/electronics experience Hard to design Find components, read datasheets, program microcontrollers, many more issues... Expensive to hire an engineer eBlocks

4. 4 of 22 Balancing act Too many blocks – overwhelm end-user Too few blocks – require too much configuration Iterative process Example-driven eBlock Catalog Definition 2-Input Logic Beeper Tripper LED Button Light Sensor Contact Switch Motion Sensor Prolonger 1 2 3 4 5 6 7 8 9 Green/Red LED Wireless TX Wireless RX eBlock Catalog Can we implement this system with available eBlocks? NO – add required blocks YES – look at next system

5. 5 of 22 Boolean eBlock Library ~30 Blocks, classified into 3 categories Sensor Output Compute/Communicate Operates on yes/no values No programming required Some blocks require slight configuration eBlock Usability* Performed experiments with over 500 users Determined eBlock interfaces Determine if novices can construct various eBlock systems eBlock Catalog Button Light Sensor Contact Switch Motion Sensor Sensor 2-Input Logic Tripper Prolonger 1 2 3 4 5 6 7 8 9 Wireless TX Wireless RX Compute/Communicate Beeper Green/Red LED Output LED Electric Relay * S. Cotterell, Frank Vahid. Usability of State Based Boolean eBlocks. International Conference on Human-Computer Interaction (HCII), July 2005. * S. Cotterell, Frank Vahid. A Logic Block Enabling Logic Configuration by Non-Experts in Sensor Networks. Conference on Human Factors in Computing Systems (CHI), April 2005.

6. 6 of 22 A’B’ 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 Create an application to detect if the garage door is left open at night We want to detect night – use light sensor We want to know if garage door open – use contact switch Need something to indicate garage open at night – use led Plug pieces together and the system is done! Creating An Application with eBlocks Light Sensor Magnetic Contact Switch 2-Input Logic LED

7. 7 of 22 Same building blocks can be used to create a variety of applications Motion on Property Detector Motion Sensor 2-Input Logic A+B Prolonger 1 2 3 4 5 6 7 8 9 Beeper Sleepwalker at Night Alarm Tripper Motion Sensor 2-Input Logic A’B Light Sensor Button Beeper Front Desk Notifier Toggle Button Beeper Package Delivery Tripper Motion Sensor Button Beeper Tripper Button LED Visual Doorbell Front Door Inside House 8-Second Doorbell Prolonger 1 2 3 4 5 6 7 8 9 Beeper Button Creating An Application with eBlocks

8. 8 of 22 eBlock Implementation We’ve build >100 physical prototypes Java-based simulator User can choose a variety of blocks by selecting between pallets User is able to configure various blocks by clicking on switches Connections created by drawing lines between blocks User can create, experiment, test and configure design Welcome to the eBlocks Simulator! In this area, you’ll find helpful hints on creating your own designs. Click and drag an eBlock off of the “Available eBlocks” panel to add it to your design. To connect two blocks, click and drag from an output port (colored circle) to an input port (gray circle). A connection can be destroyed by clicking on a connected port. To move a block around the workspace, click and drag its orange area. Blocks can be moved into the trash can to delete them. Green circles indicate that the port is sending a yes, red circles indicate that the port is sending a no, yellow Circles indicate that the port is sending an error signal, and gray circles denote an input port. Available eBlocks Advanced ModeHide this panel Compute/Communications Prolonger 1 2 3 4 5 6 7 8 9 seconds Once Yes, Stays Yes rst in Toggle Combine AND OR yes no When A isyes no B is then the output is yes Green/Red Light Beeper Output Motion Sensor Yes/No Button Light Sensor Sensors Light Sensor Available eBlocks Advanced ModeHide this panel Green/Red Light Beeper Output Motion Sensor Yes/No Button Light Sensor Sensors Compute/Communications Prolonger 1 2 3 4 5 6 7 8 9 seconds Once Yes, Stays Yes rst in Toggle Combine AND OR yes no When A isyes no B is then the output is yes Available eBlocks Advanced ModeHide this panel Compute/Communications Prolonger 1 2 3 4 5 6 7 8 9 seconds Once Yes, Stays Yes rst in Toggle Combine AND OR yes no When A isyes no B is then the output is yes Motion Sensor Yes/No Button Light Sensor Sensors Green/Red Light Beeper Output Beeper Combine AND OR yes no When A isyes no B is then the output is yes Light Sensor Button Available at http://www.cs.ucr.edu/~eblock/simulator/index.html

9. 9 of 22 Challenges Can we provide additional tools to aid users in developing various systems? What if blocks used in simulator are not available as physical blocks? Application Developer (End-user ) 3-Input Logic yes no A B’ C A B’ C’ A B C’ A B C A’ B’ C A’ B’ C’ A’ B C’ A’ B C Invert 1 0 Motion Sensor Button Light Sensor Green/Red Light Available eBlocks Advanced ModeHide this panel Compute/Communications Prolonger 1 2 3 4 5 6 7 8 9 seconds Once Yes, Stays Yes rst in Toggle Combine AND OR yes no When A isyes no B is then the output is yes Green/Red Light Beeper Output Motion Sensor Yes/No Button Light Sensor Sensors Available eBlocks Advanced ModeHide this panel Compute/Communications Prolonger 1 2 3 4 5 6 7 8 9 seconds Once Yes, Stays Yes rst in Toggle Combine AND OR yes no When A isyes no B is then the output is yes Motion Sensor Yes/No Button Light Sensor Sensors Green/Red Light Beeper Output Available eBlocks Advanced ModeHide this panel Green/Red Light Beeper Output Compute/Communications Prolonger 1 2 3 4 5 6 7 8 9 seconds Once Yes, Stays Yes rst in Toggle Combine AND OR yes no When A isyes no B is then the output is yes Motion Sensor Yes/No Button Light Sensor Sensors Welcome to the eBlocks Simulator! In this area, you’ll find helpful hints on creating your own designs. Click and drag an eBlock off of the “Available eBlocks” panel to add it to your design. To connect two blocks, click and drag from an output port (colored circle) to an input port (gray circle). A connection can be destroyed by clicking on a connected port. To move a block around the workspace, click and drag its orange area. Blocks can be moved into the trash can to delete them. Green circles indicate that the port is sending a yes, red circles indicate that the port is sending a no, yellow Circles indicate that the port is sending an error signal, and gray circles denote an input port. eBlock Simulator No physical 3-input logic blocks available.

10. 10 of 22 Challenges Can we provide additional tools to aid users in developing various systems? What if blocks used in simulator are not available as physical blocks? Can we optimize the end-user’s system? Invert 1 0 2-Input Logic yes no A’ B A’ B’ A B’ A B 2-Input Logic yes no A’ B A’ B’ A B’ A B Motion Sensor Button Light Sensor Green/Red Light Inverter is redundant Application Developer (End-user ) Available eBlocks Advanced ModeHide this panel Compute/Communications Prolonger 1 2 3 4 5 6 7 8 9 seconds Once Yes, Stays Yes rst in Toggle Combine AND OR yes no When A isyes no B is then the output is yes Green/Red Light Beeper Output Motion Sensor Yes/No Button Light Sensor Sensors Available eBlocks Advanced ModeHide this panel Compute/Communications Prolonger 1 2 3 4 5 6 7 8 9 seconds Once Yes, Stays Yes rst in Toggle Combine AND OR yes no When A isyes no B is then the output is yes Motion Sensor Yes/No Button Light Sensor Sensors Green/Red Light Beeper Output Available eBlocks Advanced ModeHide this panel Green/Red Light Beeper Output Compute/Communications Prolonger 1 2 3 4 5 6 7 8 9 seconds Once Yes, Stays Yes rst in Toggle Combine AND OR yes no When A isyes no B is then the output is yes Motion Sensor Yes/No Button Light Sensor Sensors Welcome to the eBlocks Simulator! In this area, you’ll find helpful hints on creating your own designs. Click and drag an eBlock off of the “Available eBlocks” panel to add it to your design. To connect two blocks, click and drag from an output port (colored circle) to an input port (gray circle). A connection can be destroyed by clicking on a connected port. To move a block around the workspace, click and drag its orange area. Blocks can be moved into the trash can to delete them. Green circles indicate that the port is sending a yes, red circles indicate that the port is sending a no, yellow Circles indicate that the port is sending an error signal, and gray circles denote an input port. eBlock Simulator Developed eBlock mapping and optimization tools - discussed in earlier presentation* *"Automated Generation of Basic Custom Sensor-Based Embedded Computing Systems Guided by End-User Optimization Criteria” Susan Lysecky, Frank Vahid. UbiComp 2006.

11. 11 of 22 Challenges Can we provide additional tools to aid users in developing various systems? What if blocks used in simulator are not available as physical blocks? Can we optimize the end-user’s system? Can we maximize lifetime for the end-user’s specific application? Or Reliability? Or Responsiveness?... APP 1 APP 2 APP 3 Reliability Lifetime Latency Resp. 1.0 0.8 0.6 0.4 0.2 0 Reliability Lifetime Latency Resp. 1.0 0.8 0.6 0.4 0.2 0 Reliability Lifetime Latency Resp. 1.0 0.8 0.6 0.4 0.2 0

12. 12 of 22 Node Tuning Application-specific node tuning is not a new idea Adlakha, S., S. Ganeriwal, C. Schurger, M. Srivastava. Density, Accuracy, Latency and Lifetime Tradeoffs in Wireless Sensor Networks – A Multidimensional Design Perspective. Embedded Network Sensor Systems, 2003. block’s shutdown scheme, network routing algorithms, and data compression schemes Yuan, L., G. Qu. Design Space Exploration for Energy- Efficient Secure Sensor Network. Conf. on Application- Specific Systems, Architectures, and Processors, 2002. processor type, encryption/decryption algorithms, and dynamic voltage scaling Tilak, S., N. Abu-Ghazaleh, W. Heinzelman. Infrastructure Tradeoffs for Sensor Networks. Int. Workshop on Wireless Sensor Networks and Applications, 2002. sensor capability, number of sensors deployed, and deployment strategy Heinzelman, W., A. Chandrakasan, H. Balakrishnan. Energy-Efficient Communication Protocols for Wireless Microsensor Networks. Hawaii International Conference on System Sciences, 2000. communication protocols, transmit/receive circuitry, message size, distance between blocks, etc. Martin, T., M. Jones, J. Edmison, R. Shenoy. Towards a design framework for wearable electronic textiles. IEEE International Symposium on Wearable Computers, 2003. number of sensors and sampling rate Shih, E. S. Cho, N. Ickes, R. Min, A. Sinha, A. Wang, A. Chandrakasan. Physical Layer Driven Protocol and Algorithm Design for Energy-Efficient Wireless Sensor Networks. International Conference on Mobile Computing and Networking (MobiCom), 2001. Network protocols and algorithms, dynamic voltage scaling, sleep states Careful tuning of parameters can have a large impact on design objective Node tuning hard - beyond the expertise of most end-users Block’s parameter space may consist of billions of possible configurations Heavily interdependent parameters How do we develop application specific eBlock tuning tools for novice users? APP 1 APP 2 APP 3 Reliability Lifetime Latency Resp. 1.0 0.8 0.6 0.4 0.2 0 Reliability Lifetime Latency Resp. 1.0 0.8 0.6 0.4 0.2 0 Reliability Lifetime Latency Resp. 1.0 0.8 0.6 0.4 0.2 0

13. 13 of 22 Expert in the eBlock platform Responsible for eBlock characterization eBlock Tuning eBlock Developer Computation and Communication Parameter Definition Design Metric Evaluation Equations 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 What parameters can be adjusted? What values can be assigned to the various parameters? Computation and Communication Parameter Definition How are the parameters related? Given a voltage level, what frequencies are valid? Parameter Interdependence 3.0 3.5 4.0 4.5 5.0 5.5 32k 100k 200k 300k … 16M 20M 1200 2400 4800 9600 14.4K 28.8K Lifetime = battery capacity / uP current uP current = uP Active current + uP Idle Current … How do the parameters effect lifetime? Reliability? Design Metric Evaluation Equations

14. 14 of 22 Computation and Communication Parameter Definition Design Metric Evaluation Equations Parameter Interdependence eBlock Developer eBlock Characterization Expert in the application domain Responsible for application characterization Application Developer eBlock Tuning Design Metric Objective Functions F lifetime 1 0 Lifetime (years) 0.5 1 22.5 3 01.5 3.5 What is considered a good lifetime value and what is a bad lifetime value? (0-good, 1-bad) Lifetime below 1.5 is bad Lifetime beyond 2 years yields minimal improvement Overall Objective Function What is the relative importance of each design metric? Lifetime 0100 50 Reliability 0100 50 Latency 0100 50 Connect Responsiveness 0100 50 F overall = (75 * F lifetime ) + (25 * F reliability ) +(25 * F latency ) + (50 * F connect_resp ) + (50 * F disconnect_resp ) Disconnect Responsiveness 0100 50 Mean time between corrupted packets (days) 1 0 F reliability 1 365 730 Block latency (seconds) 1 0 F latency 0 0.05 0.14 Disconnect response (seconds) 1 0 F responsiveness 1800 60 0.25 0.50 1 2 3 4 5 10 30 300 600 Connect response (seconds) 1 0 F responsiveness 0.10600.25 0.501 23 4510 30 300600 Latency Disconnect Responsiveness Reliability Connect Responsiveness

15. 15 of 22 eBlock Tuning Design Metric Objective Functions Overall Objective Function Computation and Communication Parameter Definition Design Metric Evaluation Equations Parameter Interdependence Application Developer eBlock Developer eBlock CharacterizationApplication Characterization Explore Design Space Config. A voltage = 5V frequency = 32k Hz … ecc = hamming1 F overall = (75 * 0.11) + (25 * 0.93) + (25 * 0.15) + (50 * 0.92) + (50 * 0.98) Simulated Annealing Choose eBlock configuration Determine how well configuration meets design metrics Aggregate into a single cost based on relative importance of each design metric Mean time between corrupted packets (days) 1 F reliability Connect response (seconds) 1 F responsiveness Disconnect response (seconds) 1 F responsiveness F lifetime Lifetime (years) 0.5 12 2.5 3 0 1.5 3.5 Block latency (seconds) 1 00.05 0.14 0 1 365 730 0 0.10 60 0.250.501234 51030300600 0 1800 60 0.25 0.50 1 23 4 5 1030 300 600 1 0 0 F latency

16. 16 of 22 eBlock Tuning Design Metric Objective Functions Overall Objective Function Computation and Communication Parameter Definition Design Metric Evaluation Equations Parameter Interdependence Application Developer eBlock Developer eBlock CharacterizationApplication Characterization Explore Design Space System Compute and Communicate Protocol How well did the configuration perform for each design metric? Reliability Lifetime Latency Responsiveness 1.0 0.8 0.6 0.4 0.2 0 Design Metric Achievement eBlock Config. voltage = 5V frequency = 32k Hz … ecc = hamming1 Each eBlock parameter is assigned a value System Compute and Communicate Protocol

17. 17 of 22 eBlock Tuning Design Metric Objective Functions Overall Objective Function Computation and Communication Parameter Definition Design Metric Evaluation Equations Parameter Interdependence Application Developer eBlock Developer eBlock CharacterizationApplication Characterization System Evaluation Explore Design Space Design Metric Achievement System Compute and Communicate Protocol Config. A voltage = 5V frequency = 32k Hz … ecc = hamming1 Mean time between corrupted packets (days) 1 0 F reliability 1 365 730 Connect response (seconds) 1 0 F responsiveness 0.10 60 0.250.50123451030300600 Disconnect response (seconds) 1 0 F responsiveness 180060 0.250.50 123 4 5 1030 300600 F lifetime 1 0 Lifetime (years) 0.5 122.5 3 01.5 3.5 Block latency (seconds) 1 0 F latency 00.05 0.14 Config. B voltage = 4.5V frequency = 100k Hz … ecc = none Mean time between corrupted packets (days) 1 0 F reliability 1 365 730 Connect response (seconds) 1 0 F responsiveness 0.10 60 0.250.50123451030300600 Disconnect response (seconds) 1 0 F responsiveness 180060 0.250.50 123 4 5 1030 300600 F lifetime 1 0 Lifetime (years) 0.5 122.5 3 01.5 3.5 Block latency (seconds) 1 0 F latency 00.05 0.14 Config. C voltage = 4V frequency = 1M Hz … ecc = crc Mean time between corrupted packets (days) 1 0 F reliability 1 365 730 Connect response (seconds) 1 0 F responsiveness 0.10 60 0.250.50123451030300600 Disconnect response (seconds) 1 0 F responsiveness 180060 0.250.50 123 4 5 1030 300600 F lifetime 1 0 Lifetime (years) 0.5 122.5 3 01.5 3.5 Block latency (seconds) 1 0 F latency 00.05 0.14

18. 18 of 22 Experiments – Varying Domains Consider several applications General Encompasses a variety of possible eBlock systems Educational Science Kit Introduce middle school students to simple engineering concepts Students combine and configure blocks to create customized sensor- based embedded systems Vineyard Weather Tracker Long-life application deployed in vineyard to track temperature, rainfall, avg. hours of sunlight Other applications also considered in paper … Motion on Property Detector Motion Sensor 2-Input Logic A+ B Prolonger 1 2 3 4 5 6 7 8 9 Beeper Sleepwalker at Night Alarm Tripper Motion Sensor 2-Input Logic A’B Light Sensor Button Beeper Front Desk Notifier Toggle Button Beeper Tripper Button LED Visual Doorbell Front Door Inside House Wireless Tx Temp. Sensor Wireless Rx Logger Wireless Rx Logger … Temp. sensor Record temperature readings Vineyard Weather Tracker General Educational Science Kit

19. 19 of 22 Experiments – Varying Domains F lifetime 1 0 Lifetime (years) 0.5 122.5 3 01.5 3.5 Disconnect response (seconds) 1 0 F responsiveness 180060 0.250.50 123 4 5 1030 300600 Connect response (seconds) 1 0 F responsiveness 0.10600.250.50123451030300600 General Educational Science Kit Lifetime metric Lifetime requirement not as important – users can easily change batteries Responsiveness metrics Extensive hot-swapping in an interactive learning environment Design metric weights F lifetime 1 0 Lifetime (years) 0.5 12 2.5 3 0 1.5 3.5 Disconnect response (seconds) 1 0 F responsiveness 180060 0.250.50 123 4 5 1030 300600 Connect response (seconds) 1 0 F responsiveness 0.10600.250.50123451030300600 Vineyard Weather Tracker F lifetime 1 0 Lifetime (years) 0.5 12 2.5 3 0 1.5 3.5 Disconnect response (seconds) 1 0 F responsiveness 180060 0.250.50 123 1030 300600 Connect response (seconds) 1 0 F responsiveness 0.10600.250.501251030300600 Educational Science Kit 4 5 34 Vineyard Weather Tracker Lifetime metric Yearly maintenance acceptable Responsiveness metrics Deployed system, already test/configured Design metric weights General Design metric weights

20. 20 of 22 General Optimized vs. Educational Science Kit Optimized Overall objective function increase of 68% Lifetime decreases from 931 days to 509 days Connect responsiveness changed from 1.25 s to 0.20 s Disconnect responsiveness changed from 0.3 s to 0.10 s General Optimized vs. Vineyard Weather Tracker Optimized Overall objective function increase of 85% Lifetime increases from 931 days to 1223 days Connect responsiveness changed from 1.25 s to 20 s Disconnect responsiveness changed from 0.3 s to 2.5 s Application-specific configuration verses general configuration yields an average improvement of 42% Experiments

21. 21 of 22 Compared simulated annealing heuristic to exhaustive search Exhaustive - average of 3.5 minutes per application Simulated Annealing – average of 10 seconds per application 3% difference in overall design metric achievement Experiments

22. 22 of 22 Automated eBlock tuning ~10 minutes to specify high-level design metric goals ~10 seconds to determine eBlock configuration Yield an average of 42% improvement in meeting user-defined goals, high of 85% Can easily be scaled to consider larger number of parameters Future Work Directly extendable to support general sensor network systems Conclusion Thank you for your attention