1 WSN Summer Project Demo Scenario Skövde 2008

2 Shows features (legend) Real-time (RT) Fusion (Fus) Database, Replication (DB) Scalability, ViFuR (VF)

3 Fire fighting scenario or Battlefield game? The scenario described can be mapped to alternative real scenarios – ”imagine!”

4 Scenario features Items (people/vehicles etc) are moving over a field. They reveal signatures by (light) sensors that are spread out over the field. Their locations are reported into a database, from where their tracks can be extracted and also predicted by using fusion (e.g. Kalman filters). Items are reported, with signatures and timestmaps, to the connected database node. Disjoint sensor sub nets report their area to separate database nodes. Tracking and event localization is done at a (or several) fusion node(s), where database replication provides data for the entire area. Tracks and actions are visualized at multiple client nodes, which have replicas of the visualization data (segment) of the database.

5 Features of the Scenario Sensors: Tracking by using features, event detection and localization Events are localized and uses certainty management, combines multiple sensors (RT, Fus) Sensors classifies into signatures. This emulates processing for signatures at the sensor (RT, Fus) Tracks + localized events are visualized on multiple displays (DB, Rep) Tracking by using the logged visual trace, short term database time series, items may be distinguished by their physical move limitations (DB, Fus) In the multi-tier architecture, sensors are arranged into subnets, each connected to a (single) database node. Data from a database node, representing sensors in the subnet are replicated to other database nodes as client needs arise. (VF, DB)

6 Sensor setup Visual: Multiple TelosB, using the light sensors. Optional: (Acoustic: Room has 5 MICAz+MTS310, using the microphone sound level)

7 Sensor placement LLL L = Light sensor, on a projector screen LLLL LLLL L LLLL

8 Technical needs Move-events + classification from sensors Action-events + signature from sensors Feed of sensor data + (re-)configuration. Support request for 1) - single sensor input 2) - periodic sensor input 3) - sensor input (single or periodic) in response to event (including timer), all sensor input includes a vector of all sensor readings in the sensor node (should we prepare for the possibility of requesting a subset, or adding additional sensors?) (should we prepare for the need to buffer multiple readings and send as single message to save bandwidth clutter?) Database replication, single master, but extendable for PRiDe

9 Impl:Mote communication 1.Tmote Connect approach 2.[ TelosB gateway  Tablet USB ] 3.[ Tinymote gateway  Tablet SD slot ] 4.[ Bluetooth gateway  Tablet (port?) ]

10 Impl:Database 1.Store sensor data in local BDB database 2.Visualize sensor data 3.Replicate sensor data to other nodes 4.Visualization sensor data at other DB node

11 Visualization (1) Raw indications LLL LLLL LLLL L LLLL = Intensity of light, color for certainty of indication

12 Visualization (2) Trace (and prediction) = Fused localization (intensity of light/certainty of indication) 80% 100% 70% 50% 30% ”certainty%” = Prediction (by Kalman filter?)