SATIRE: A Software Architecture for Smart AtTIRE R. 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 50 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 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?