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

Presentation Outline SATIRE: A Software � Introduction to SATIRE Architecture for Smart � Software Architecture � Implementation AtTIRE � Design Challenges � Critique & Comparison Authors: Raghu Ganti, Praveen Jayachandran, Tarek Abdelzaher, John Stankovic � Questions Presented by Rick Gerdes December 11, 2006 CSE 521S 2 What is SATIRE? SATIRE Design Goals � It is a layered software architecture for wearable � Modularity computing � Transparent to the user � To be used on all TinyOS-based wearables � Service longevity � It is designed for PC and mote interaction � Record a user’s discrete activities rather than doing � The motes take samples of sensor data and transfer continuous monitoring throughout the entire day them to the PC when in communication range � Store the sensor data on the wearable mote while the � The PC is used for post-processing the data user is away from the base station � It was implemented on a MICAz WSN � Upload it when a base station is within radio range � All sensor motes were sewn into a jacket � Recorded a user’s activity and tracked his location CSE 521S 3 CSE 521S 4 Software Architecture System Implementation � On the mote � MICAz:128KB Program, 512KB Flash, Mote Application Layer � PC � Sensor Protocol Layer has 802.15.4 Radio (256 Kbps) processing algorithms Application Layer Application Layer � TinyOS Layer for synchronization, User Interface 4 logging, and radio communication � 5 MICAz motes with 2 axis accelerometers � Communication device drivers Interpretation Layer Sensor Specific Protocols � 2 motes were placed in each arm sleeve � On the PC A1 A2 A3 … An 3 Energy Stillness Trunc. � Communication device drivers Filter Filter Filter � 1 mote near the waist band � Parsing Layer processes the raw data generated by the sensors � 1 MICAz mote with a GPS module � Interpretation Layer handles Synch Protocol different algorithms for interpreting Parsing Layer the sensor data 2 TinyOS Flash Log Protocol (raw sensor data) � 1 access mote � Application Layer allows different UI Upload Protocol and applications 1 USB Serial Port UART RF Radio CSE 521S 5 CSE 521S 6 1

Challenges Filter Evaluation � 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 Flash Storage Savings CSE 521S 7 CSE 521S 8 Challenges Upload Protocol � Data Upload � Transparent � Use beaconing messages � Reliable and Fast � Use ARQ/NACK protocol scheme Mote State Machine � Use a timer to send the packets instead of the TinyOS split phase mechanism CSE 521S 9 CSE 521S Access Mote State Machine 10 Upload Evaluation 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 Split Phase Send Throughput Clocked Send Throughput 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 CSE 521S 11 CSE 521S 12 2

Reconstruction Evaluation Evaluation of using the GPS User’s Walking Pace Stationary Activity Accuracy Non-stationary Activity Accuracy CSE 521S 13 CSE 521S 14 User’s Activity Critique Paper Comparison � The 2 designs don’t have all the same challenges to address mainly due to the sensor device location: car vs jacket � The wearable application they implemented needs to be worn year round, not a short season � CarTel’s embedded hardware in the car runs on a 266MHz 586 with 128MB RAM and 1GB Flash � There were no power management tests conducted, only � CarTel’s sensor data is uploaded to a Wi-Fi or Bluetooth calculations Wireless Access Point � Use an Imote2 � CarTel uses a TinyDB like methodology for sensor data � 32 MB Flash -> 64 times more capacity than MICAz acquisition e.g. continuous querying is possible � BlueTooth -> 720Kbps vs. 802.15.4 250Kbps � CarTel implements its own 3 layer network stack called CafNet � Gets rid of the UART bottleneck to efficiently send prioritized data over an intermittent network � Doing a FCFS upload causes high contention � CarTel has been tested with several applications and is more � Access mote should issue the beacon refined because of it � 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 15 CSE 521S 16 Questions CSE 521S 17 3