eBlocks: Enabling Design of Basic Embedded Systems by Novice Users

1
eBlocks Enabling Design of Basic Embedded
Systems by Novice Users

• Susan Lysecky
• Dept. of Electrical and Computer Engineering
• University of Arizona
• slysecky_at_ece.arizona.edu

Frank Vahid Dept. of Computer Science and
Engineering University of California,
Riverside vahid_at_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
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
Introduction

• Why arent these systems more prevalent?

eBlocks

• Hard to design
• Find components, read datasheets, program
  microcontrollers, many more issues...

• Developed for specific application
• Hard to customize
• Expensive low volume

4
eBlock Catalog Definition

• Balancing act
• Too many blocks overwhelm end-user
• Too few blocks require too much configuration
• Iterative process
• Example-driven

Can we implement this system with available
eBlocks?
5
eBlock Catalog

• 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

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
Creating An Application with eBlocks

• Create an application to detect if the garage
  door is left open at night

Need something to indicate garage open at night
use led
We want to detect night use light sensor
Need a function of light sensor output and
contact switch output use Logic Block
AB
We want to know if garage door open use contact
switch
7
Creating An Application with eBlocks

• Same building blocks can be used to create a
  variety of applications

8
eBlock Implementation

• Weve build gt100 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 at http//www.cs.ucr.edu/eblock/simulat
or/index.html
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?

10
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-users system?

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
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-users system?
• Can we maximize lifetime for the end-users
  specific application? Or Reliability? Or
  Responsiveness?...

12
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.
• blocks 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
• Blocks parameter space may consist of billions
  of possible configurations
• Heavily interdependent parameters

13
eBlock Tuning
Computation and Communication Parameter Definition
Design Metric Evaluation Equations
eBlock Developer
14
eBlock Tuning
Design Metric Objective Functions
Application Developer
15
eBlock Tuning
eBlock Characterization
Application Characterization
Computation and Communication Parameter Definition
Design Metric Objective Functions
Overall Objective Function
Application Developer
Design Metric Evaluation Equations
eBlock Developer
Config. A
Parameter Interdependence
voltage 5V frequency 32k Hz ecc hamming1
Explore Design Space
Explore Design Space

• 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

Foverall (75 0.11) (25 0.93)
(25 0.15) (50 0.92) (50 0.98)
16
eBlock Tuning
eBlock Characterization
Application Characterization
Computation and Communication Parameter Definition
Design Metric Objective Functions
Overall Objective Function
Application Developer
Design Metric Evaluation Equations
eBlock Developer
Parameter Interdependence
Explore Design Space
System Compute and Communicate Protocol
17
eBlock Tuning
eBlock Characterization
Application Characterization
Computation and Communication Parameter Definition
Design Metric Objective Functions
Overall Objective Function
Application Developer
Design Metric Evaluation Equations
eBlock Developer
Parameter Interdependence
Explore Design Space
Design Metric Achievement
System Compute and Communicate Protocol
18
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

1 2 3 4 5 6 7 8 9
Button
Button
Beeper
Motion Sensor
Prolonger
2-Input Logic
LED
Tripper
Front Door
Beeper
Tripper
Light Sensor
AB
Button
Motion Sensor
2-Input Logic
Inside House
Motion on Property Detector
AB
Motion Sensor
Visual Doorbell
Sleepwalker at Night Alarm
Button
Beeper
Toggle
Front Desk Notifier
General
Educational Science Kit
19
Experiments Varying Domains

• General
• Design metric weights
• lt1, 1, 1, 1, 1gt

General
1
Flifetime

• 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
• lt0.1, 0.5, 0.5, 1, 1gt

0
0
0.5
1
2
1.5
2.5
3
3.5
Lifetime (years)
1
Fresponsiveness
0
0.25
0.50
4
10
30
1800
60
1
2
3
5
300
600
Disconnect response (seconds)

• Vineyard Weather Tracker
• Lifetime metric
• Yearly maintenance acceptable
• Responsiveness metrics
• Deployed system, already test/configured
• Design metric weights
• lt1, 0.5, 0.5, 0.1, 0.1gt

1
Fresponsiveness
0
0.10
60
0.25
0.50
1
2
3
4
5
10
30
300
600
Connect response (seconds)
20
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

21
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

22
Conclusion

• 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

Thank you for your attention