e. Blocks: 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
Introduction • Large class of applications exists comprised of sensor-based systems • • • Wireless doorbell, mail alert, gate open, motion on property, package on porch, customized motion lights, carpool alert ? Office/Commercial • • Transform sensor data and feed the proceed data to output or actuator nodes Residential • ? 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, . . . 2
Introduction • Why aren’t these systems more prevalent? Off-the-shelf e. Blocks 2 -Input Logic Programmable Motion Sensor http: //www. xbow. com/ Button LED Photo: Jason Hill http: //www. dustnetworks. com/ • Hard to design • http: //www. smarthome. com • Developed for specific application Hard to customize Expensive – low volume • • • Find components, read datasheets, program microcontrollers, many more issues. . . • GOAL – enable novice users to build customized embedded systems • • Expensive to hire an engineer Provide building blocks to enable customization Eliminate need for programming/electronics experience 3
e. Block Catalog Definition • Balancing act • • • Too many blocks – overwhelm end-user Too few blocks – require too much configuration Iterative process • Example-driven e. Block Catalog Can we implement this system with available e. Blocks? NO – add required blocks Motion Sensor Tripper Beeper Wireless TX Button LED YES – look at next system 2 -Input Logic Light Sensor Contact Switch Wireless RX 12345678 9 Prolonger Green/Red LED 4
e. Block Catalog • Boolean e. Block Library • • • Sensor ~30 Blocks, classified into 3 categories • Sensor • Output • Compute/Communicate Motion Sensor Light Sensor Button Contact Switch Operates on yes/no values No programming required • Some blocks require slight configuration Output • e. Block Usability* • • • Performed experiments with over 500 users Determined e. Block interfaces Determine if novices can construct various e. Block systems Beeper LED Electric Relay Green/Red LED Compute/Communicate 12345678 9 Tripper Prolonger * S. Cotterell , Frank Vahid. Usability of State Based Boolean e. Blocks. 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. 2 -Input Logic Wireless TX Wireless RX 5
Creating An Application with e. Blocks Create an application to detect if the garage door is left open at night Light Sensor We want to detect night – use light sensor Magnetic Contact Switch LED 2 -Input Logic A’B’ We want to know if garage door open – use contact switch Need something to indicate garage open at night – use led Need a function of light sensor output and contact switch output – use Logic Block Configure Logic Block to turn led on when it’s night and when door is open Plug pieces together and the system is done! 6
Creating An Application with e. Blocks • Same building blocks can be used to create a variety of applications Button Tripper Light Sensor Motion Sensor Tripper Beeper Motion Sensor 2 -Input Logic Button Tripper Front Door Package Delivery A’B Sleepwalker at Night Alarm LED Button Inside House Visual Doorbell 12345678 9 Button Prolonger Beeper 8 -Second Doorbell 12345678 9 Motion Sensor 2 -Input Logic Prolonger A+B Beeper Button Toggle Beeper Front Desk Notifier Motion on Property Detector 7
e. Block 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 Available e. Blocks Sensors Output Compute/Communications Light Sensor When A is Button Beeper Button When A is yes no AND B is OR yes no then the output is yes Motion Sensor Green/Red Combine Green/Red Light yes no then the output is yes Combine yes no rs t in Beeper Light Once Yes, Stays Yes Sensor Toggle Yes/No 12345678 9 seconds Prolonger Hide this panel Advanced Mode Welcome to the e. Blocks Simulator! In this area, you’ll find helpful hints on creating your own designs. Click and drag an e. Block off of the “Available e. Blocks” 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 at http: //www. cs. ucr. edu/~eblock/simulator/index. html 8
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? e. Block Simulator Available e. Blocks Sensors Output When A is Button Beeper Button Motion Sensor 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 3 -Input Logic Compute/Communications yes no AND B is OR yes no then the output is yes Motion Sensor. Combine Green/Red Light rs t in 1 0 Invert Green/Red Light Sensor Once Yes, Stays Yes Toggle Light Sensor Yes/No 1234567 89 seconds Welcome to the e. Blocks Simulator! In this area, you’ll find helpful hints on creating your own designs. Click and drag an e. Block off of the “Available e. Blocks” 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. Prolonger Hide this panel Advanced Mode No physical 3 -input logic blocks available. Application Developer (End-user) 9
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? e. Block Simulator Button Motion Sensor Developed e. Block mapping and optimization tools - discussed in earlier presentation* Available e. Blocks Sensors Output yes no A’ B’ A’ B A B’ A B 2 -Input Logic When A is Button Beeper AND B is OR yes no then the output is yes no A’ B’ A’ B A B’ A B 2 -Input Logic rs t in 1 0 Invert Green/Red Light Sensor Once Yes, Stays Yes Toggle Yes/No 1234567 89 seconds Prolonger Welcome to the e. Blocks Simulator! In this area, you’ll find helpful hints on creating your own designs. Click and drag an e. Block off of the “Available e. Blocks” 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. Application Developer (End-user) yes no Motion Sensor. Combine Green/Red Light Sensor *"Automated Generation of Basic Custom Sensor-Based Embedded Computing Systems Guided by End-User Optimization Criteria” Susan Lysecky, Frank Vahid. Ubi. Comp 2006. Compute/Communications Hide this panel Advanced Mode Inverter is redundant 10
Re sp. Re cy cy ten sp. Re cy ten ity La ten bil ity La lia bil Re Re APP 3 La Life e tim Life 1. 0 0. 8 0. 6 0. 4 0. 2 0 lia bil APP 2 1. 0 0. 8 0. 6 0. 4 0. 2 0 tim APP 1 e • • 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? . . . tim • 1. 0 0. 8 0. 6 0. 4 0. 2 0 Re lia Can we provide additional tools to aid users in developing various systems? Life • e Challenges 11
Node Tuning Application-specific node tuning is not a new idea Adlakha, 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. Yuan, L. , G. Qu. Design Space Exploration for Energy. Efficient Secure Sensor Network. Conf. on Application. Specific Systems, Architectures, and Processors, 2002. • APP 3 . sp Re sp cy . Life tim e Re lia bil ity La ten cy ten Re. 1. 0 0. 8 0. 6 0. 4 0. 2 0 sp 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 (Mobi. Com), 2001. APP 2 1. 0 0. 8 0. 6 0. 4 0. 2 0 Re number of sensors and sampling rate APP 1 1. 0 0. 8 0. 6 0. 4 0. 2 0 La Martin, T. , M. Jones, J. Edmison, R. Shenoy. Towards a design framework for wearable electronic textiles. IEEE International Symposium on Wearable Computers, 2003. • • communication protocols, transmit/receive circuitry, message size, distance between blocks, etc. How do we develop application specific e. Block tuning tools for novice users? e Heinzelman, W. , A. Chandrakasan, H. Balakrishnan. Energy. Efficient Communication Protocols for Wireless Microsensor Networks. Hawaii International Conference on System Sciences, 2000. • • sensor capability, number of sensors deployed, and deployment strategy ity Tilak, S. , N. Abu-Ghazaleh, W. Heinzelman. Infrastructure Tradeoffs for Sensor Networks. Int. Workshop on Wireless Sensor Networks and Applications, 2002. • • processor type, encryption/decryption algorithms, and dynamic voltage scaling tim • • bil • • lia • block’s shutdown scheme, network routing algorithms, and data compression schemes Node tuning hard - beyond the expertise of most end-users Block’s parameter space may consist of billions of possible configurations Heavily interdependent parameters Life • • Re • Careful tuning of parameters can have a large impact on design objective Life tim e Re lia bil ity La ten cy • Network protocols and algorithms, dynamic voltage scaling, sleep states 12
e. Block Tuning Computation and Communication Parameter Definition Design Metric Evaluation Equations • • e. Block Developer Parameter Interdependence Expert in the e. Block platform Responsible for e. Block characterization Lifetime = battery capacity / u. P current … u. P current = u. P Active current + u. P Idle Current • 3. 0 3. 5 4. 0 4. 5 5. 0 5. 5 How do the parameters effect lifetime? Reliability? 32 k 100 k 200 k 300 k … 1200 2400 4800 9600 14. 4 K 28. 8 K 16 M 20 M • How are the parameters related? • Given a voltage level, what frequencies are valid? 5 V hamming crc 32 k Hz 100 k Hz 10 m 0. 5 s 4. 5 V 3 s 0. 25 s 1 m 4 bits parity 1 M Hz 1 byte 3 V • • What parameters can be adjusted? What values can be assigned to the various parameters? 13
e. Block Tuning e. Block Characterization Computation and Communication Parameter Definition Lifetime below 1. 5 is bad Design Metric Evaluation Equations Lifetime beyond 2 years yields minimal improvement e. Block Developer Parameter Interdependence Design Metric Objective Functions Overall Objective Function • • Flifetime 1 2 2. 5 3 3. 5 1 1. 5 0 0. 5 Reliability Lifetime (years) • Latency What is considered a good lifetime value and what is a bad lifetime value? (0 -good, 1 -bad) Mean time between corrupted packets (days) Block latency (seconds) Disconnect Responsiveness Fresponsiveness 1 Disconnect Responsiveness 0 Disconnect response (seconds) 50 100 0 50 100 Foverall = (75 * Flifetime) + (25 * Freliability) +(25 * Flatency) + (50 * Fconnect_resp) + (50 * Fdisconnect_resp) • 1 0 What is the relative importance of each design metric? 0 0. 10 0. 25 0. 50 1 2 3 4 5 10 30 60 300 600 0. 14 0. 05 0 0 730 1 365 Flatency Fresponsiveness 1 Freliability 1 Connect Responsiveness Latency 0. 25 0. 50 1 2 3 4 5 10 30 60 300 600 1800 Reliability 0 Expert in the application domain Responsible for application characterization Lifetime 0 Application Developer Connect response (seconds) 14
e. Block Tuning e. Block Characterization Computation and Communication Parameter Definition Design Metric Evaluation Equations Application Characterization Design Metric Objective Functions Overall Objective Function Application Developer e. Block Developer Parameter Interdependence Config. A voltage = 5 V frequency = 32 k Hz … ecc = hamming 1 Explore Design Space 1 Flatency Flifetime 1 0. 14 0. 05 3 Fresponsiveness 0 Connect response (seconds) • Simulated Annealing • • • 0 Choose e. Block configuration Determine how well configuration meets design metrics Aggregate into a single cost based on relative importance of each design metric 0. 25 0. 50 1 2 3 4 5 10 30 60 300 600 1800 730 365 Mean time between corrupted packets (days) 1 0. 10 0. 25 0. 50 1 2 3 4 5 10 30 60 300 600 Freliability 0 1 Block latency (seconds) 1 Fresponsiveness 1 3. 5 2 2. 5 1 1. 5 0 0. 5 Lifetime (years) 0 0 0 Disconnect response (seconds) Foverall = (75 * 0. 11) + (25 * 0. 93) + (25 * 0. 15) + (50 * 0. 92) + (50 * 0. 98) 15
e. Block Tuning e. Block Characterization Application Characterization Computation and Communication Parameter Definition Design Metric Evaluation Equations Design Metric Objective Functions Overall Objective Function Application Developer e. Block Developer Parameter Interdependence e. Block Config. voltage = 5 V frequency = 32 k Hz Explore Design Space … ecc = hamming 1 • Each e. Block parameter is assigned a value 1. 0 0. 8 0. 6 0. 4 0. 2 0 ne ss How well did the configuration perform for each design metric? siv e y Design Metric Achievement Re sp on La ten c ilit y Re lia b Life tim e • System Compute and Communicate Protocol 16
e. Block Tuning e. Block Characterization Computation and Communication Parameter Definition Mean time between corrupted packets (days) 0. 14 Fresponsiveness 0 Connect response (seconds) 0. 14 0 0. 25 0. 50 1 2 3 4 5 10 30 60 300 600 1800 730 365 0 Block latency (seconds) 1 0. 10 0. 25 0. 50 1 2 3 4 5 10 30 60 300 600 Freliability Fresponsiveness 1 0 0 0. 5 1 1. 5 2 2. 5 3 3. 5 1 1 Disconnect response (seconds) Flatency Flifetime Lifetime (years) ecc = crc Design Metric Achievement 1 0 0 … System Compute and Communicate Protocol 0 Connect response (seconds) 1 voltage = 4 V frequency = 1 M Hz System Evaluation 0. 25 0. 50 1 2 3 4 5 10 30 60 300 600 1800 Fresponsiveness 0. 10 0. 25 0. 50 1 2 3 4 5 10 30 60 300 600 365 0 730 Freliability 1 0 0. 05 Block latency (seconds) 1 1 Fresponsiveness 1 Config. C Explore Design Space Flatency 0 3. 5 3 2. 5 2 1 0. 5 1. 5 0 Lifetime (years) ecc = none Disconnect response (seconds) 0 0 … e. Block Developer Parameter Interdependence 1 Flifetime voltage = 4. 5 V frequency = 100 k Hz Application Developer 0 Connect response (seconds) 1 Config. B Overall Objective Function 0. 25 0. 50 1 2 3 4 5 10 30 60 300 600 1800 0. 10 0. 25 0. 50 1 2 3 4 5 10 30 60 300 600 0 730 365 1 0 Fresponsiveness 1 Freliability ecc = hamming 1 0. 14 0 3. 5 2 3 2. 5 1 0. 5 1. 5 0 1 Design Metric Objective Functions Block latency (seconds) 1 Lifetime (years) … 0. 05 0 0 0. 05 voltage = 5 V frequency = 32 k Hz Flatency Flifetime Config. A Design Metric Evaluation Equations 1 1 Application Characterization Disconnect response (seconds) 17
Experiments – Varying Domains • 123456789 Consider several applications • Button General Light Sensor Motion Sensor Tripper Motion Sensor Inside House Prolonger Beeper A+ B Motion on Property Detector Visual Doorbell A’B Sleepwalker at Night Alarm Educational Science Kit Button Toggle Beeper Front Desk Notifier General Vineyard Weather Tracker Educational Science Kit • Long-life application deployed in vineyard to track temperature, rainfall, avg. hours of sunlight • 2 -Input Logic Beeper Button 2 -Input Logic • Introduce middle school students to simple engineering concepts • Students combine and configure blocks to create customized sensorbased embedded systems • Motion Sensor LED Tripper Front Door • Encompasses a variety of possible e. Block systems • Button Other applications also considered in paper … Temp. Sensor Wireless Tx Logger Wireless Rx Temp. sensor Wireless Rx Logger … Vineyard Weather Tracker Record temperature readings 18
Experiments – Varying Domains Educational Science Kit General Flifetime 3. 5 3 2 2. 5 1 1. 5 0 3. 5 3 2 2. 5 1 1. 5 Fresponsiveness 0. 25 0. 50 1 2 3 4 5 10 30 60 300 600 1800 Disconnect response (seconds) Connect response (seconds) 0 Connect response (seconds) Responsiveness metrics • Lifetime metric • • Yearly maintenance acceptable Responsiveness metrics 0 Connect response (seconds) Extensive hot-swapping in an interactive learning environment Design metric weights • <0. 1, 0. 5, 1, 1> • 0. 10 0. 25 0. 50 1 2 3 4 5 10 30 60 300 600 Fresponsiveness 0 Lifetime requirement not as important – users can easily change batteries Vineyard Weather Tracker • 1 0. 10 0. 25 0. 50 1 2 3 4 5 10 30 60 300 600 Fresponsiveness • • 0 Disconnect response (seconds) 1 <1, 1, 1> Lifetime metric • 0. 25 0. 50 1 2 3 4 5 10 30 60 300 600 1800 0 • • 1 0. 25 0. 50 1 2 3 4 5 10 30 60 300 600 1800 0 Design metric weights • Lifetime (years) 1 Fresponsiveness 0. 5 Lifetime (years) • Educational Science Kit 0 0 3 3. 5 2 1. 5 1 0. 5 0 0 0 General 1 Flifetime 1 Vineyard Weather Tracker Deployed system, already test/configured Design metric weights • <1, 0. 5, 0. 1> 19
Experiments • 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% 20
Experiments • 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 21
Conclusion • Automated e. Block tuning • • • ~10 minutes to specify high-level design metric goals ~10 seconds to determine e. Block 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 Thank you for your attention 22
Скачать презентацию e Blocks Enabling Design of Basic Embedded Systems
0a4e7cced22d64bb7f8d5ced765b162c.ppt