SATIRE: A Software Introduction to SATIRE Architecture for Smart - - PDF document

1

SATIRE: A Software Architecture for Smart AtTIRE

Authors: Raghu Ganti, Praveen Jayachandran, Tarek Abdelzaher, John Stankovic

Presented by Rick Gerdes December 11, 2006

CSE 521S 2

Presentation Outline

Introduction to SATIRE Software Architecture Implementation

Design Challenges

Critique & Comparison Questions

CSE 521S 3

What is SATIRE?

It is a layered software architecture for wearable

computing

To be used on all TinyOS-based wearables

It is designed for PC and mote interaction

The motes take samples of sensor data and transfer

them to the PC when in communication range

The PC is used for post-processing the data

It was implemented on a MICAz WSN

All sensor motes were sewn into a jacket Recorded a user’s activity and tracked his location

CSE 521S 4

SATIRE Design Goals

Modularity Transparent to the user Service longevity

Record a user’s discrete activities rather than doing

continuous monitoring throughout the entire day Store the sensor data on the wearable mote while the

user is away from the base station

Upload it when a base station is within radio range

CSE 521S 5

Software Architecture

• On the mote
• Application Layer
• Sensor Protocol Layer has

processing algorithms

• TinyOS Layer for synchronization,

logging, and radio communication

• Communication device drivers
• On the PC
• Communication device drivers
• Parsing Layer processes the raw

data generated by the sensors

• Interpretation Layer handles

different algorithms for interpreting the sensor data

• Application Layer allows different UI

and applications

Sensor Specific Protocols Energy Filter Stillness Filter Trunc. Filter

Synch Protocol Upload Protocol Flash Log Protocol TinyOS

UART RF Radio Application Layer Interpretation Layer A1 A2 A3 … An USB Serial Port Parsing Layer

PC Mote

(raw sensor data) 4 3 2 1 Application Layer User Interface

CSE 521S 6

System Implementation

MICAz:128KB Program, 512KB Flash,

802.15.4 Radio (256 Kbps)

5 MICAz motes with 2 axis accelerometers

2 motes were placed in each arm sleeve 1 mote near the waist band

1 MICAz mote with a GPS module 1 access mote

2

CSE 521S 7

Challenges

Data Collection and Storage on the Mote

Truncate filter: normal human activity only

requires 8 bits of accelerometer data

Stillness filter: calculate the energy of a

discrete difference signal periodically

CSE 521S 8

Filter Evaluation

Flash Storage Savings

CSE 521S 9

Challenges

Data Upload

Transparent

Use beaconing messages

Reliable and Fast

Use ARQ/NACK protocol scheme Use a timer to send the packets instead of the

TinyOS split phase mechanism

CSE 521S 10

Upload Protocol

Mote State Machine Access Mote State Machine

CSE 521S 11

Upload Evaluation

Split Phase Send Throughput Clocked Send Throughput

CSE 521S 12

Challenges

Reconstruction of Activity Logs

Identifying the activities e.g. sitting, walking,

eating, etc.

Feature Vector Solution

Find the closest match between the features of a signal (e.g. average, std. deviation, RMS, integral, temporal variation, and rotational direction) representing an activity to the same features of the raw data

Hidden Markov Model Solution

Phase 1: Use the Baum-Welch procedure to train the HMM for each activity Phase 2: Use the Forward-Backward procedure to find in the HMM the activity that has the highest probablility of having an observation sequence that matches the raw sensor

3

CSE 521S 13

Reconstruction Evaluation

Stationary Activity Accuracy Non-stationary Activity Accuracy

CSE 521S 14

Evaluation of using the GPS

User’s Walking Pace User’s Activity

CSE 521S 15

Critique

The wearable application they implemented needs to be worn

year round, not a short season

There were no power management tests conducted, only

calculations

Use an Imote2

32 MB Flash -> 64 times more capacity than MICAz BlueTooth -> 720Kbps vs. 802.15.4 250Kbps

Gets rid of the UART bottleneck

Doing a FCFS upload causes high contention

Access mote should issue the beacon

A max upload time of 12 mins. to transfer all the motes’ data is

not fast by today’s internet standards that a user will be accustomed to

CSE 521S 16

Paper Comparison

The 2 designs don’t have all the same challenges to address

mainly due to the sensor device location: car vs jacket

CarTel’s embedded hardware in the car runs on a 266MHz

586 with 128MB RAM and 1GB Flash

CarTel’s sensor data is uploaded to a Wi-Fi or Bluetooth

Wireless Access Point

CarTel uses a TinyDB like methodology for sensor data

acquisition e.g. continuous querying is possible

CarTel implements its own 3 layer network stack called CafNet

to efficiently send prioritized data over an intermittent network

CarTel has been tested with several applications and is more

refined because of it

CSE 521S 17

Questions