SATIRE: A Software Architecture for Smart AtTIRER. Ganti, P. Jayachandran, T. F. Abdelzaher,J. A. Stankovic

(Presented by Linda Deng)

Goals

• Personal wearable monitoring devices– Archive user activities for later lookup– Monitor at-home patients

• Transparent/non-obtrusive• Longevity of service• Flexible/modular system architecture

Hardware considerations

• Sensing: Acceleration + GPS sensors– Activity + location monitoring– Can reconstruct activities w/ hidden Markov models

• Memory/storage: Less than 1 MB?– 1 MB can log 6 hours of disconnected operation @

50 samples/s @ 1 byte/sample– Logging in flash memory• Persistence allows for operating at low power when no

activity is recorded

Hardware considerations (cont.)

• Communication: Wireless– Collaboration b/w pieces of attire– Information upload: < 1 minute near access mote?

• Processing: Microcontroller sufficient• Energy supply: Enough for a “season”?– AA batteries only good for a few days– But power-saving schemes + lithium batteries?

MicaZ chosen

• Off-the-shelf microcontroller-based device• 2-axis accelerometer + pluggable GPS module• 512 KB flash• 802.15.4 radio• AA batteries• But limited by off-the-shelf components…

Typical scenario

System architecture (mote)• Application layer: Receives data from sensor layer• Filter layer: Common data processing algorithms• OS layer: Data storage, upload, synchronization

System architecture (PC)• Parsing layer: Processing of raw sensor data• Interpretation layer: Offline algorithms for parsed data• Application layer: User interfaces for apps

Data collection and storage

• For walking, needed at least 12 Hz sampling• 25 Hz for each accelerometer axis• How to increase disconnected operation time?• Truncate filter– Effectively reduce accelerometer range

• Stillness filter– Just record number of samples of stillness

Data upload

• Need sufficient rate, transparency, reliability• Beaconing– Motes send periodic beacons– Base allows one mote to communicate– NACKs for reliability

Data synchronization

• Synchronize motes on different parts of body• To maintain temporal correlation: beaconing– During reconstruction, same beacon # = same time

• Beacon values recorded in flash– But beacons occur much less frequently than data– Acceptable overhead

Power management

• Typical mote lifetime = < 7 days?• But we want it to last for 3 months!• Duty cycle scheme– Sleep when still, wake periodically to check stillness

• Low-power operation possible 90% of time?• Assuming 5% duty cycle during low-power op…• Battery life of 7 weeks ≈ 3 months?• Same life for GPS if no fixes during stillness…

Reconstruction of activity logs

• How to determine type of activity performed?• Feature vector approach inaccurate in practice• Hidden Markov model– Machine learning technique requiring training data– Fairly accurate for predefined activities– But only for pre-trained “general” activities…

User interface

• Archive availability provided by Internet• Web server + DBMS to answer queries– Centralized

• Or data can be hosted on home computer…

Privacy and security

• Secure communication channels?• Authorization for accessing info archive?• Not really addressed…

Evaluation• Sending data rate = 30 Kbps– Due to serial port bottleneck b/w access mote + PC?– And lack of buffer space on jacket mote…• Read/writes to flash interleaved

• Truncate/stillness filters reduced flash needed• If disconnected op is long, sampling rate

becomes approximate– No effect from clock drift when near base

• Location tracking via GPS worked fine

Stationary activity identification

• 2 different users• 10 minutes of each activity, 1 minute training

Non-stationary activity

• Just 1 user

ID without specific training• “General” activities can be pre-trained• Or user can specially train own jacket…

Experiment example

Conclusions

• Flexible/modular architecture for smart attire• HMMs for activity identification• Prototype with accelerometer and GPS sensors• Bottlenecks of off-the-shelf hardware?• Privacy?