A Building Block Approach to Sensornet Systems

1
A Building Block Approach to Sensornet Systems
Prabal Dutta, Jay Taneja, Jaein Jeong, Xiaofan
Jiang, and David Culler
UC Berkeley Sensys 2008
Presenter SY (some slides borrowed from Dutta)
2
(Wireless) embedded systems are tightly coupled
to the application

• Common
• Computation
• Communication
• Storage
• Application-specific
• Power
• Sensing
• Mechanical

PEG Sharp05
HydroWatch Taneja07
Redwoods Tolle05
Shimmer Intel06
PicoCube Chee08
Radar Dutta06
3
Serious applications go through three stages
Production Reducing cost Optimizing
performance Improving manufacturability Obtain
ing high reliability Finalizing mechanicals
Prototype Goal Try it and see Rapid
prototyping
Pilot Goal Unprecedented data Realistic
study Modest scale Modest investment Well-en
ough executed

Accrue Learnings Artifacts Investments

4
Epic design philosophy

• Consolidate deep expertise into reusable modules
• Integrate modules with simple glue
• 3 Ps Prototype, Pilot, Production

5
Outline

• Introduction
• Related Work Building the design rules
• Design Rules
• Building Blocks and Development Stages
• Modules
• Results
• Revisiting the Design Rules
• Conclusion

6
Modular platforms and plug-and-play development
PC/104 Cerpa01
PASTA Bajura05
Mica Hill01
Mica2 Xbow03
MicaZ Xbow05
Rene Hill99
WeC Hill98
Stargate Intel
WINSng Pottie00
WINS Rockwell
mPlatformLymberopoulos07
7
Some (inconvenient) truths about these modular
approaches

• Prototyping is simpleplug-and-play
• Unspecified faux busses can result in signal
  conflicts
• Multiplexed busses can avoid conflicts
• They present barriers to simple interfacing
• Lego-like snap together modularity is great
• Backplanes and board stacks
• Too Bulky
• Waste space
• Expensive relative to other components
• Too fragile for experimentation and pilots (max
  insertions)
• Force 3D board packaging geometry
• 51-pin connector is ubiquitous!
• Instead of being just right
• Often too general for simple applications
• And too limited for demanding ones

8
Building the design rules

• Modularity
• Really hard stuff must be reused unchanged
• Snap/plug together
• Good for prototypingbad for production
• Generic bus/backplane
• Expensive, fragile, and often gets in the way

9
OPPOSITE VIEW THE HIGHLY-INTEGRATED APPROACH
Telos/Tmote Polastre05
PC/104 Cerpa01
PASTA Bajura05
Mica Hill01
Mica2 Xbow03
MicaZ Xbow05
Rene Hill99
WeC Hill98
Stargate Intel
WINSng Pottie00
WINS Rockwell
mPlatformLymberopoulos07
10
Some (inconvenient) truths about
thehighly-integrated approach

• Bundles core, sensors, antenna, power, host
  interface, and expansion port
• Onboard sensors make great demos
• Onboard sensors complicate the mechanicals
• Some sensors dont make sense TSR/PAR next to
  Temp/Hum
• Integrated USB host interface makes software
  development easy
• Integrated USB host interface adds cost and goes
  unused in production
• IDC expansion slot
• Forces 3D board stacking or cabling
• Realistic pilots strained because too few I/O are
  exposed
• Integrated power with battery/host cutover
• Hard to intercept power lines for measurement or
  debugging

11
Building the design rules

• Modularity is good
• Snap/plug together
• Eliminate bus/backplane
• Export everything
• Dont limit generality
• Partition functionality
• Eliminate waste
• Remove the sensors
• Theyre application-specific
• Separate the power supply
• Its application-specific
• Make current measurements easy

12
Emerging commercial platforms are designed for
manufacturability
Tmote Mini Sentilla07
Telos/Tmote Polastre05
PC/104 Cerpa01
PASTA Bajura05
Mica Hill01
Mica2 Xbow03
MicaZ Xbow05
Iris Xbow07
Rene Hill99
WeC Hill98
Iris OEM Xbow07
MicaZ Stamp Xbow06
Stargate Intel
WINSng Pottie00
WINS Rockwell
mPlatformLymberopoulos07
13
Some (inconvenient) truths about
theproduction-quality, assembly-optimized modules

• Excellent radio performance
• Might still require RF engineering
• Ideal for high-volume, pick-and-place assembly
• Hard to socket or hand-solder for prototype and
  pilot studies
• Hard to probe I/O lines for debugging
• Narrow interface makes integration easy
• Hides many internal signals useful for research

14
Design rules for application-specific platform
development

• Modularity is good
• Snap/plug together
• Eliminate bus/backplane
• Export everything
• Partition functionality
• Remove the sensors
• Separate the power supply
• Performance at worst ?-suboptimal
• RF out-of-the box
• Socketable
• Hand-solderable

15
Design Rules redux
Epic Building Block design rules

• Partition functionality
• Export wide electrical interface
• Eliminate the system bus
• Modules at worst ?-suboptimal
• Support many physical interconnects

• Modularity is good
• Snap/plug together
• Eliminate bus
• Export everything
• Partition functionality
• Remove the sensors
• Split power supply
• Only ?-suboptimal
• RF out-of-the box
• Socketable
• Hand-solderable

16
Epic building block approach to
supportprototype, pilot, and production

• Two architectural elements
• Module
• Carrier
• Module
• General-purpose subsystem
• Reusable, self-contained
• Multi-chip module package
• Composed of one or more ICs and discrete
  components
• Carrier
• Application-specific glue
• Glues together
• General-purpose modules
• Application-specific sensors, power supplies,
  mechanicals

17
Epic building block approach a concrete example
Core
Storage
USB
Start with modules
Incorporate with carriers
Create platforms
Prototype
Production
Pilot

• Teaching/Experimentation
• Sensors via connectors
• Power USB, Li, Alkaline
• Mechanical All I/O exposed

• Research/Measurement
• Sensors temp/hum/light
• Power USB, Alkaline
• Mechanical Telos-like

• Scientific/Application
• Sensors V/I/temp
• Power AC, USB
• Mechanical Wall plug

18
Outline

• Introduction
• Related Work Building the design rules
• Design Rules
• Building Blocks and Development Stages
• Modules
• Results
• Prototype
• From Pilot to Production
• Organic Reuse
• Revisiting the Design Rules
• Conclusion

19
CORE MODULE

• a wireless sensornet node (mote) core that
  integrates a microcontroller, radio, and flash
  memory.
• Most critical, and difficult part
• A bunch of chips available
• How to choose

20
MICROCONTROLLER -- CRITERIA

• Low currents
• Low operating voltage
• Fast wakeup
• Sufficient RAM and Flash
• 16-bit timer
• DMA

21
RADIO -- CRITERIA

• Idle listen current
• Sleep current and wakeup time
• Link budget

22
SELECTION REVISIT

• MSP430F1611 CC2420, still hold?
• Yes
• They are still competitive
• If re-design now, still use same chips?
• No
• MSP430F26x or MSP430F54x CC2520
• Cost of re-design core module is very high

23
OTHER MODULES

• Storage Module
• 1 Gbit NAND flash
• two 16 Mbit NOR flash
• 512 Kbit FRAM

• USB Module
• Host interface
• Reprogramming
• JTAG over USB
• Battery management

24
Outline

• Introduction
• Related Work Building the design rules
• Design Rules
• Building Blocks and Development Stages
• Modules
• Results
• Prototype
• From Pilot to Production
• Organic Reuse
• Revisiting the Design Rules
• Conclusion

25
Prototyping experimentation and debugging
Development Board
Interface Board
Breakout Board
Phidgets
Interface Board
26
Result Five application-specific platforms in
six months with five grad students
HydroWatch
Benchmark
ACme
Jiang
Jeong, Taneja
Dutta
PowerNet (Stanford)
Quanto Testbed
Meraki Daughterboard
Dutta, Goto
Dutta
Gal, Heller, Kazandjieva
27
Carriers gluing together module with
app-specific sensors, power supplies, and
mechanicals
ACme AC Meter Ctrl
Benchmark Testbed measurement
Meraki Daughterboard b6lowpan border router
HydroWatch Environmental Mon.
1. Modules Core 2. Sensors T/H/L 3. Power
Solar, NiMH 4. Mech NEMA 4 encl 5. PCB
2-layer 6. Design 2 days 7. 10.83 ea _at_ 60
pcs 8. Fab Leadtime 5-day
1. Modules Core 2. Sensors V, I 3. Power AC 4.
Mech enclosure 5. PCB 2-layer 6. Design 1
week 7. 26.40 ea _at_ 5 pcs 8. Fab leadtime 5-day
1. Modules Core, USB 2. Sensors E/T/H/L 3.
Power USB 4. Mech Telos-like 5. PCB 4-layer 6.
Design 3 days 7. 141.30 ea _at_ 10 pcs 8. Fab
leadtime 5-day
1. Modules Core 2. Sensors T/H 3. Power
Meraki 4. Mech Meraki 5. PCB 2-layer 6. Design
5 hours 7. 33 ea _at_ 6 pcs 8. Fab leadtime 5-day
All first articles were hand-assembled in
hours. Shortens platform development
time-to-result. Makes custom platforms broadly
accessible.
28
Approach promotes reuse in modules, CAD parts,
inventory, subsystems
29
Outline

• Introduction
• Related Work
• Design Rules
• Building Blocks and Development Stages
• Modules
• Results
• Revisiting the Design Rules
• Conclusion

30
The design rules

• Partition functionality
• Export wide electrical interface
• Eliminate the system bus/backplane
• Modules at worst ?-suboptimal
• Support many physical interconnects

31
Where do modules come from?Heuristics for
partitioning functionality
If the answer to any of these questions is yes,
then make it a module. Otherwise, its a carrier
board.
32
EXPORT A WIDE ELECTRICAL INTERFACEACTUALLY,
JUST EXPORT EVERYTHING (ALMOST)
33
Modules can be only ?suboptimalif they are to
be enthusiastically adopted
34
Support many physical interconnect options
Prototype
Routed Vias 1. Free connector 2. Easy to
solder 3. Easy to probe 4. Connect all layers
Pilot
Socketing
Production
Hardware Inlining
Hand Soldering
LCC-68 footprint
35
Conclusion
TinyOS 2.1 support Make epic install miniprog

• Near-optimal platform decomposition
• From try it and see to high-volume production
• Enables rapid platform development through
  reusable carriers, modules, and CAD parts
• Epic is Open Source Hardware
• CAD source, gerbers, BOM available online
• Share you CAD parts and board designs!
• http//www.cs.berkeley.edu/prabal/projects/epic

Jan08
Oct08
PowerNet (Stanford)