Your SlideShare is downloading. ×
0
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation

331

Published on

Paper presentation at IEEE DCOSS 2011, 
Barcelona, Spain, June 2011. …

Paper presentation at IEEE DCOSS 2011, 
Barcelona, Spain, June 2011.

Video of the demo: http://www.youtube.com/watch?v=QzrpKRhGFRU


Published in: Technology, Health & Medicine
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
331
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. D.Pizzocaro@cs.cardiff.ac.uk DCOSS 2011 A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation D. Pizzocaro, A. Preece [Cardiff Univ., UK] F. Chen, T. La Porta [Penn State Univ., US] A. Bar-Noy [Graduate Center, City Univ. of NY, US] Twitter: @diegostream users.cs.cf.ac.uk/D.Pizzocaro
  • 2. OutlineOutline 1. Intro & Model 2. Architecture 3. Performance 4. Conclusion
  • 3. 1. Intro & Model1. Intro & Model
  • 4. 1. Intro & ModelScenario
  • 5. 1. Intro & ModelScenario • An already deployed network of sensors
  • 6. 1. Intro & ModelScenario TASK 3 TASK 7 Monitor Area weather Surveillance TASK 4 TASK 6 Identify Identify evacuation route evacuation route TASK 2 TASK 5 TASK 8 TASK 1 Area Monitor Surveillance Detect weather Injured vehicles people to identify • An already deployed network of sensors - Support multiple tasks to be accomplished simultaneously
  • 7. 1. Intro & ModelScenario TASK 3 TASK 7 Monitor Area weather Surveillance TASK 4 TASK 6 Identify Identify evacuation route evacuation route TASK 2 TASK 5 TASK 8 TASK 1 Area Monitor Surveillance Detect weather Injured vehicles people to identify • An already deployed network of sensors - Support multiple tasks to be accomplished simultaneously - Highly dynamic (sensor failures, change of plan)
  • 8. 1. Intro & ModelScenario TASK 3 TASK 7 Monitor Area weather Surveillance TASK 4 TASK 6 Identify Identify evacuation route evacuation route TASK 2 TASK 5 TASK 8 TASK 1 Area Monitor Surveillance Detect weather Injured vehicles people to identify • An already deployed network of sensors - Support multiple tasks to be accomplished simultaneously - Highly dynamic (sensor failures, change of plan) - Sensors are scarce and in high demand.
  • 9. 1. Intro & ModelScenario TASK 3 TASK 7 Monitor Area weather Surveillance TASK 4 TASK 6 Identify Identify evacuation route evacuation route TASK 2 TASK 5 TASK 8 TASK 1 Area Monitor Surveillance Detect weather Injured vehicles people to identify • An already deployed network of sensors - Support multiple tasks to be accomplished simultaneously - Highly dynamic (sensor failures, change of plan) - Sensors are scarce and in high demand.
  • 10. 1. Intro & ModelMulti-sensor task allocation h & Rescue Earthquake Searc Various problem settings but the fundamental question: or Unmanned Sens “Which sensor should be allocated to which task?” We call it the Multi-Sensor Task Allocation problem (MSTA) Monitor Detect collapsing buildin g (injured) people • Users on the field have usually no time and no expertise to manually decide the best sensors for each task. • We need to automatically allocate sensors to tasks to satisfy the information requirements of each user.
  • 11. 1. Intro & Model Formal model (p1, d1) (p2, d2) ‣ Difference with HOMOGENEOUS sensors: Utilities of groups of sensors (BUNDLES) are mores T1 T2 e 12 complex to compute. e11s B1 B2 ‣ p = task priority first need We d = utility demand to group sensors into bundles, and e = joint utility then find the best assignment of bundles to tasks. (p2, d2)s T2 S1 S2 S3 S4 ‣ We consider the possibility of preempting sensors: reallocating them to more important tasks. B2 p = task priority d = utility demand ‣ Goal: Maximize profit (i.e. weighted utility) e = joint utility and Minimize the reallocation cost.S3 S4
  • 12. 2. Architecture2. Architecture
  • 13. 2. ArchitectureConceptual arch.• Solve the MSTA problem step by step, by integrating a knowledge base module with an allocation mechanism. KB Bundle Generator Allocation mechanism Sensor Network
  • 14. 2. ArchitectureConceptual arch. • Solve the MSTA problem step by step, by integrating a knowledge base module with an allocation mechanism.Mobile usercreates asensing task. 1 KB Bundle Generator Allocation mechanism Sensor Network
  • 15. 2. ArchitectureConceptual arch. • Solve the MSTA problem step by step, by integrating a knowledge base module with an allocation mechanism.Mobile usercreates asensing task. 1 2 KB Recommends Bundle fit-for-purpose bundles Generator and computes utility. Allocation mechanism Sensor Network
  • 16. 2. ArchitectureConceptual arch. • Solve the MSTA problem step by step, by integrating a knowledge base module with an allocation mechanism.Mobile usercreates asensing task. 1 2 KB Recommends Bundle fit-for-purpose bundles Generator and computes utility. 3 Allocation Finds a solution to mechanism MSTA problem. Sensor Network
  • 17. 2. ArchitectureConceptual arch. • Solve the MSTA problem step by step, by integrating a knowledge base module with an allocation mechanism.Mobile usercreates asensing task. 1 2 KB Recommends Bundle fit-for-purpose bundles Generator and computes utility. 3 Allocation Finds a solution to mechanism MSTA problem. 4 Sensor Configured accordingly Network and delivers data to user.
  • 18. 2. ArchitectureDistributed system• The KB bundle generator on the user device (prototype mobile app)• The allocation mechanism on the sensors & user device as a distributed protocol ‣ Extended a pre-existent coalition formation protocol to deal with dynamic environment. KB KB KB Bundle Bundle Bundle Generator Generator Generator Allocation protocol Allocation protocol Sensor Network Allocation Allocation protocol protocol
  • 19. 2. ArchitectureKB bundle generator KB• MSTA in Heterogeneous sensor networks requires knowledge of Bundle Generator which sensor types are applicable to which kinds of task.• Two issues: (1) Can a type of sensor (or combination) satisfy a task type? (2) How well a particular sensor instance might perform?• Addressing these issues requires knowledge from literature, which we encode in a Knowledge Base (KB).• The KB stores: (1) each type of sensor (or combination) that can theoretically satisfy the task (2) a joint utility function to estimate the utility of sensor instances for that task
  • 20. 2. ArchitectureReasoning procedure KB Bundle Generator Task TypeUsing sensor & task ontologies& OWL reasoner. Which functions can Capabilities be used to estimate Required the performances? Sensor types to choose. compatible? Joint Utility Bundle Type Function = Recommendations
  • 21. 2. ArchitectureReasoning procedure KB Bundle Generator Task TypeUsing sensor & task ontologies Localize vehicle& OWL reasoner. Which functions can Capabilities be used to estimate Required the performances? Sensor types to choose. compatible? Joint Utility Bundle Type Function = Recommendations
  • 22. 2. ArchitectureReasoning procedure KB Bundle Generator Task TypeUsing sensor & task ontologies Localize vehicle& OWL reasoner. Which functions can Capabilities be used to estimate Required the performances? 1) Acoustic intelligence 2) Imagery intelligence Sensor types to choose. compatible? Joint Utility Bundle Type Function = Recommendations
  • 23. 2. ArchitectureReasoning procedure KB Bundle Generator Task TypeUsing sensor & task ontologies Localize vehicle& OWL reasoner. Which functions can Capabilities be used to estimate Required the performances? 1) Acoustic intelligence 2) Imagery intelligence Sensor types to choose. compatible? Joint Utility Bundle Type Function = Recommendations BT1 = {AcousticArray} BT2 = {UAV, Camera}
  • 24. 2. ArchitectureReasoning procedure KB Bundle Generator Task TypeUsing sensor & task ontologies Localize vehicle& OWL reasoner. Which functions can Capabilities be used to estimate Required the performances? 1) Acoustic intelligence 2) Imagery intelligence Sensor types to choose. compatible? Joint Utility Bundle Type Function = Recommendations BT1 = {AcousticArray} JUF1 = 2D-Localization BT2 = {UAV, Camera} JUF2 = Detection Probability
  • 25. 2. ArchitectureReasoning procedure KB Bundle Generator Task TypeUsing sensor & task ontologies Localize vehicle& OWL reasoner. Which functions can Capabilities be used to estimate Required the performances? 1) Acoustic intelligence 2) Imagery intelligence Sensor types to choose. Allocation flexibility compatible? Joint Utility Bundle Type Function = Recommendations BT1 = {AcousticArray} JUF1 = 2D-Localization (BT1, JUF1), (BT1, JUF2), (BT2, JUF2) BT2 = {UAV, Camera} JUF2 = Detection Probability
  • 26. 2. ArchitectureLightweight KB KB Bundle GeneratorTask Type Recommendation • The original implementation of the reasoning process is 1 (BT1 + JUF1) computationally expensive 1 (BT2 + JUF1) ‣ The reasoner uses an exponential-time classifier. 1 (BT2 + JUF2) ‣ On a mobile device is not recommended. 2 (BT3 + JUF1) 2 (BT2 + JUF1) 2 (BT2 + JUF2) • Precompute the results of the reasoner and store them ... ... in a look-up table N (BT5 + JUM1) • Task types and sensor types are “stable” • Reasoning operations are much less expensive
  • 27. 2. ArchitectureAllocation protocol Allocation protocol • Our protocol consists of mainly 2 stages: Initial negotiation and Bundle formation.
  • 28. 2. ArchitectureAllocation protocol Allocation protocol • Our protocol consists of mainly 2 stages: Initial negotiation and Bundle formation. Sensor 1 Sensor 2User A User B Initial negotiation:Task T1 created Task T2 created Request-Info-For(A) Request-Info-For(B) (1) The user creates a task in a location (x, y) Request-Info-For(A) Request-Info-For(B) A.Post-Info(S1) B.Post-Info(S1) A.Post-Info(S2) B.Post-Info(S2) bid 1 bid 2A: {T1, (S1, S2), 0.9} B: {T2, (S1, S2), 0.8} S2.Post-Bid(bid1) S2.Post-Bid(bid2) S1.Post-Bid(bid1) S2.Post-Bid(bid2)
  • 29. 2. ArchitectureAllocation protocol Allocation protocol • Our protocol consists of mainly 2 stages: Initial negotiation and Bundle formation. Sensor 1 Sensor 2User A User B Initial negotiation:Task T1 created Task T2 created Request-Info-For(A) Request-Info-For(B) (1) The user creates a task in a location (x, y) Request-Info-For(A) Request-Info-For(B) (2) Mobile devs query sensors in the vicinity. A.Post-Info(S1) B.Post-Info(S1) A.Post-Info(S2) B.Post-Info(S2) bid 1 bid 2A: {T1, (S1, S2), 0.9} B: {T2, (S1, S2), 0.8} S2.Post-Bid(bid1) S2.Post-Bid(bid2) S1.Post-Bid(bid1) S2.Post-Bid(bid2)
  • 30. 2. ArchitectureAllocation protocol Allocation protocol • Our protocol consists of mainly 2 stages: Initial negotiation and Bundle formation. Sensor 1 Sensor 2User A User B Initial negotiation:Task T1 created Task T2 created Request-Info-For(A) Request-Info-For(B) (1) The user creates a task in a location (x, y) Request-Info-For(A) Request-Info-For(B) (2) Mobile devs query sensors in the vicinity. A.Post-Info(S1) B.Post-Info(S1) (3) Using the KB bundle generator, the device creates a bid for a sensor bundle A.Post-Info(S2) B.Post-Info(S2) which optimally satisfies the sensing task. bid 1 bid 2A: {T1, (S1, S2), 0.9} B: {T2, (S1, S2), 0.8} S2.Post-Bid(bid1) S2.Post-Bid(bid2) S1.Post-Bid(bid1) S2.Post-Bid(bid2)
  • 31. 2. ArchitectureAllocation protocol Allocation protocol • Our protocol consists of mainly 2 stages: Initial negotiation and Bundle formation. Sensor 1 Sensor 2User A User B Initial negotiation:Task T1 created Task T2 created Request-Info-For(A) Request-Info-For(B) (1) The user creates a task in a location (x, y) Request-Info-For(A) Request-Info-For(B) (2) Mobile devs query sensors in the vicinity. A.Post-Info(S1) B.Post-Info(S1) (3) Using the KB bundle generator, the device creates a bid for a sensor bundle A.Post-Info(S2) B.Post-Info(S2) which optimally satisfies the sensing task. bid 1 bid 2 (5) Bid propagated to all sensors in the bundle.A: {T1, (S1, S2), 0.9} B: {T2, (S1, S2), 0.8} S2.Post-Bid(bid1) S2.Post-Bid(bid2) S1.Post-Bid(bid1) S2.Post-Bid(bid2)
  • 32. 2. ArchitectureAllocation protocol (2) Allocation protocol Bundle formation: The sensors decide the most profitable sensor bundle to join. We allow preemption of already allocated sensors and a rebidding mechanism.
  • 33. 2. ArchitectureAllocation protocol (2) Allocation protocol Bundle formation: The sensors decide the most profitable sensor bundle to join. We allow preemption of already allocated sensors and a rebidding mechanism.Bundle formation: User A Sensor 1 Sensor 2 User B(1) Each sensor keeps a list of bids. S2.Accept(bid1, S1) S1.Accept(bid1, S2) S2.Cleared(S1) S1.Cleared(S2) A.Task-Sat(S1, bid1) B.Task-Sat(S1, bid1) A.Task-Sat(S2, bid1) B.Task-Sat(S2, bid1) Task satified Task unsatisfied bid 3 B: {T2, (S3, S4), 0.7}
  • 34. 2. ArchitectureAllocation protocol (2) Allocation protocol Bundle formation: The sensors decide the most profitable sensor bundle to join. We allow preemption of already allocated sensors and a rebidding mechanism.Bundle formation: User A Sensor 1 Sensor 2 User B(1) Each sensor keeps a list of bids. S2.Accept(bid1, S1)(2) A sensor sends an ACCEPT to other sensors S1.Accept(bid1, S2)in the bid it can contribute the most (i.e. larger eij/|Bk|). S2.Cleared(S1) S1.Cleared(S2) A.Task-Sat(S1, bid1) B.Task-Sat(S1, bid1) A.Task-Sat(S2, bid1) B.Task-Sat(S2, bid1) Task satified Task unsatisfied bid 3 B: {T2, (S3, S4), 0.7}
  • 35. 2. ArchitectureAllocation protocol (2) Allocation protocol Bundle formation: The sensors decide the most profitable sensor bundle to join. We allow preemption of already allocated sensors and a rebidding mechanism.Bundle formation: User A Sensor 1 Sensor 2 User B(1) Each sensor keeps a list of bids. S2.Accept(bid1, S1)(2) A sensor sends an ACCEPT to other sensors S1.Accept(bid1, S2)in the bid it can contribute the most (i.e. larger eij/|Bk|). S2.Cleared(S1)(3) If sensor receives ACCEPTs from all sensors in bundle, S1.Cleared(S2)it sends a CLEARED to all bid neighbours. A.Task-Sat(S1, bid1) B.Task-Sat(S1, bid1)The sensor starts serving the task notifying the user. A.Task-Sat(S2, bid1) B.Task-Sat(S2, bid1) Task satified Task unsatisfied bid 3 B: {T2, (S3, S4), 0.7}
  • 36. 2. ArchitectureAllocation protocol (2) Allocation protocol Bundle formation: The sensors decide the most profitable sensor bundle to join. We allow preemption of already allocated sensors and a rebidding mechanism.Bundle formation: User A Sensor 1 Sensor 2 User B(1) Each sensor keeps a list of bids. S2.Accept(bid1, S1)(2) A sensor sends an ACCEPT to other sensors S1.Accept(bid1, S2)in the bid it can contribute the most (i.e. larger eij/|Bk|). S2.Cleared(S1)(3) If sensor receives ACCEPTs from all sensors in bundle, S1.Cleared(S2)it sends a CLEARED to all bid neighbours. A.Task-Sat(S1, bid1) B.Task-Sat(S1, bid1)The sensor starts serving the task notifying the user. A.Task-Sat(S2, bid1) B.Task-Sat(S2, bid1)(4) A sensor receiving a CLEARED deletes the bids involving Task satified Task unsatisfiedthe sender sensor. It stops when clears a bid or list is empty. bid 3 B: {T2, (S3, S4), 0.7}
  • 37. 2. ArchitectureAllocation protocol (2) Allocation protocol Bundle formation: The sensors decide the most profitable sensor bundle to join. We allow preemption of already allocated sensors and a rebidding mechanism.Bundle formation: User A Sensor 1 Sensor 2 User B(1) Each sensor keeps a list of bids. S2.Accept(bid1, S1)(2) A sensor sends an ACCEPT to other sensors S1.Accept(bid1, S2)in the bid it can contribute the most (i.e. larger eij/|Bk|). S2.Cleared(S1)(3) If sensor receives ACCEPTs from all sensors in bundle, S1.Cleared(S2)it sends a CLEARED to all bid neighbours. A.Task-Sat(S1, bid1) B.Task-Sat(S1, bid1)The sensor starts serving the task notifying the user. A.Task-Sat(S2, bid1) B.Task-Sat(S2, bid1)(4) A sensor receiving a CLEARED deletes the bids involving Task satified Task unsatisfiedthe sender sensor. It stops when clears a bid or list is empty. bid 3 B: {T2, (S3, S4), 0.7}(5) User device can rebid until a convergence timeoutto satisfy the task expires.
  • 38. 3. Performance3. Performance
  • 39. 3. PerformanceLightweight KB (mobile app)• Deployed as an app on iPod Touch 2nd Gen, implemented as a relationship table in the db.• We consider a Synthetic KB (synthetically generated data) and a Prototype KB (real knowledge from literature) • Query time increases logarithmically: ‣ Due to DB used in iOS (SQLite) ‣ Performs a binary search O(log(n)) • Storage space grows linearly. • Prototype KB: ~ 12 MB of storage required, ~ 20 ms of query time.
  • 40. 3. PerformanceAllocation protocol ‣ We ran simulations implemented our extended protocol: • 250 Static sensors of different types (already deployed). • 50 Mobile users on the field. • Task generated with uniform random distribution. ‣ Allocation quality improves using our extend protocol: • Compared with the original and 2 other versions
  • 41. 3. Performance Allocation protocol ‣ We ran simulations implemented our extended protocol: • 250 Static sensors of different types (already deployed). • 50 Mobile users on the field. • Task generated with uniform random distribution. ‣ Allocation quality improves using our extend protocol: • Compared with the original and 2 other versions• The distributed protocol is scalable. To prove it we increase linearly task arrival rate: ‣ Allocation quality decreases sub-linearly ‣ # Messages exchanged grows linearly
  • 42. 4. ConclusionConclusion‣ We formalized MSTA in heterogeneous sensor networks.‣ We proposed a novel distributed architecture which integrates a knowledge base with an allocation protocol, providing flexibility in the choice of sensors.‣ We implemented a prototype app to show feasibility of Knowledge based sensor-task matching on the mobile device.‣ We also ran simulations to show our architecture is scalable and the allocation quality improves using our extended protocol.Future: ‣ Currently working on how to integrate data delivery/dissemination mechanisms in our architecture, to “close the loop”.
  • 43. End Acknowledgements Prof. Alun Preece, Prof. Amotz Bar-Noy Prof. Tom La Porta & Fangfei Chen Sponsored by the International Technology Alliance (ITA) ITA in Network and Information Science Thanks! D.Pizzocaro@cs.cardiff.ac.uk Images copyrights disclaimer: Twitter: @diegostream Some of the images are copyrighted by Apple..Contact me if you would like the direct links to each of the images. users.cs.cf.ac.uk/D.Pizzocaro

×