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
 1998: Simple Problem

Garage door open at night
 Simple system

If garage open at night,
blink LED in bedroom
transmit
AND
receive
light
sensor
April 2005
LED
contact
switch
Frank Vahid, UC Riverside
2 of 28
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?
April 2005
Frank Vahid, UC Riverside
3 of 28
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
April 2005
Frank Vahid, UC Riverside
4 of 28
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


Electronic Blocks (Legos)


Board based, non-intuitive, not low power
Simple toy for young kids
Programming for novices

Lego Mindstorm (MIT research), Phidgets, Robobrix

April 2005
Teaches programming using robot, several-day learning curve
Frank Vahid, UC Riverside
5 of 28
Observation and Solution
 Observation: Microprocessors cheap/smaller
 Solution: Put microprocessor in “dumb”
components (sensors, buttons, LEDs) to
enable easy connection
 eBlocks
Courtesy of Joe Kahn
 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
April 2005
Frank Vahid, UC Riverside
6 of 28
Research Issues
1. Human-computer interfacing


Block set for novices
Design individual blocks
2. Communication

Need new digital abstraction
3. Mass producible but tunable nodes
4. CAD tools for novices
April 2005
Frank Vahid, UC Riverside
7 of 28
1. HCI -- Block Set Definition
 Block set for novices

Tradeoff



Programmable
eBlock
vs
Built ~100 physical prototypes


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

http://www.cs.ucr.edu/eblocks
April 2005
Frank Vahid, UC Riverside
8 of 28
1. HCI: Block Set Definition
 Yes/no blocks
 Block set
Button
Sensors (motion, light, button, ...)
Output (LED, buzzer, electric relay, logger)
Compute





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
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
yes time
123456789
in
in
in
out
out
prolong
time
Was “delay”
April 2005
in
out
rst
Once yes, stays yes
out
Toggle
no time
out
in
Pulse Generator
rst
out
out
Was “tripper”
Frank Vahid, UC Riverside
9 of 28
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
A B
no no
A no yes
B yes no
yes yes
Out
no
no
no
no
yes
yes
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
yes no
A
B
A is yes, B is yes
When the A is yes, B is no the output
input is A is no, B is yes should be
A is no, B is no
out
Combine
A
no
no
yes
yes
yes
yes
yes
yes
Slightly better, still <20% success
A
When the A
A
input is A
A
yes no
B
B The output
B
B should be
B
out
When A is
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
no no
yes no
Logic Block
Frank Vahid, UC Riverside
#2
yes
no
AND B is yes
no
OR
then the output is yes
Combine
Logic Sentence
#1
50%-60% success (90% with
some training), but not general
10 of 28
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.
Source
channel (wire)
Sink
0.8
0
time
continuous voltage, two
levels
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 of 28
2. Communication -- Digital Abstraction
 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
error
<
f
maximum inter-packet time violation causes error values
in the received signal
<
f
April 2005
t
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
12 of 28
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
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
>
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 of 28
3. Mass Producable but Tunable Nodes
 Node performance (lifetime,
reliability, ...) heavily impacted by
parameters


Voltage
0xFF
Clock Frequency
0xC3
Baud Rate
0x1A
…
Packet constraints, baud rate,
voltage levels, frequency, error
checking bits, ...
Observed by us and others

Endangered Species Videoing System
0xFF
Adlakha et al 2003; Yuan/Qu 2002; Tilak et
al 2002, Heinzelman et al 2000.
123456789
0xFF
0xFF

0x1

0x1
0xFF
0xC
0xC
0x1
0x1
Sleepwalker at Night Alarm
0x1
Node developer
Application developer (node user)
April 2005
0xC
0xFF 0xC
Design highly-parameterized node
Develop methodology for

0xC
0xFF
A+B
Lifetime, reliability, responsiveness,
...
 Solution

0xC
0x1
 Applications’ performance goals
differ

Software Configurable
Node Parameters
0xFF
0xFF
0xC
0xC
0x1
0x1
0xFF
0xFF
0xC
0xC
0x1
0x1
0xFF
0xC
A’B
0x1
Frank Vahid, UC Riverside
14 of 28
3.Mass Producable but Tunable Nodes -Methodology
CAD Tool
Application
Developer
Configure
Node
Parameters
0xFF 0x1A 0xC3
0xF1 0x12 0xC0
0x00 0x12 0xC3
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 of 28
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



5V
Computation and Communication
Parameter Definition
Design Metric Evaluation
Equations
Parameter Interdependence
hamming
10 m
crc
32k Hz
0.5s
4.5V
100k Hz
0.25s
4 bits
3s
1m
parity 1M Hz
1 byte
3V
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
32k
100k
200k
300k
455k
800k
…
5.3M
7.4M
8M
10M
10.4M
16M
20M
1200
2400
4800
9600
14.4K
28.8K
16 of 28
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
Block latency
(seconds)
0
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
3
3.5
2
2.5
1
1.5
0.5
0
Lifetime (years)
0
0
0
1
1
Flatency
Flifetime
1
Freliability
1
1
0.25
0.50
1
2
3
4
5
10
30
60
300
600
1800

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

730

365


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 of 28
3. Feedback to Application Developer
 Automated exploration
Simulated annealing search

3
3.5
2
2.5
1
1.5
0
…
Lifetime (years)
1
ecc = hamming1
0.05
Downloaded onto nodes
0.14
0
0
 Feedback to application developer
 Ultimately yields tuned parameter
values
0.5
0
voltage = 5V
frequency = 32k Hz
Flatency

Config. A
Flifetime
1
Block latency (seconds)
Freliability
1
Config. B
voltage = 4V
frequency = 300k Hz
730
365
1
0
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 of 28
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
April 2005
Frank Vahid, UC Riverside
19 of 28
5. New Research Direction -- Spatial
Programming of Basic Sensor Networks
 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


High-end sensor networks
Expert programmers
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”
April 2005
Frank Vahid, UC Riverside
Low-end sensor networks
Non-programming developers
20 of 28
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
April 2005
Frank Vahid, UC Riverside
21 of 28
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
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
eBlocks
Success Rate
22 of 28
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”
main(void) {
#include “io.h”
ORTA = 0xff;
#include “constants.h”
CMCON = 0x07;
Unsigned char data_val = ERROR;
TRISA = 0x00;
...
TRISB = 0x02;
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 of 28
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
April 2005
Frank Vahid, UC Riverside
24 of 28
5. Programming Directions
 Increasingly abstract behavior capture
Physical nodes
Graphical blocks
Virtual blocks
Online assistance
Light
sensor
Open-atnight
Combine
I want to detect any
of 3 doors opened at
night
LED
Light
sensor
Contact
sensor
Contact
sensor
User statement
Are you trying to
detect open at
night? Yes
LED
Open-atOpen-atnight
Open-atnight
night
Combine
LED
Light
sensor
Automatically
generated
Automatically
generated
Open-atOpen-atnight
Open-atnight
night
Combine
x3
x3
Contact
sensor
April 2005
Frank Vahid, UC Riverside
Combine
25 of 28
LED
Future Work – Extending eBlocks to
Integers
 Extend to integer eBlocks

Sensors


Display


Temperature, speed, distance, sound, etc.
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
April 2005
Frank Vahid, UC Riverside
26 of 28
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


Customizable victim notification system


With ADV, proposal in final stages with DOJ
Localized organic pesticide meterer based on insect counts


with Intel
With ISCA Corp.
Endangered species videoing system

April 2005
With UCR environment science colleagues
Frank Vahid, UC Riverside
27 of 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
April 2005
Frank Vahid, UC Riverside
28 of 28