D.Pizzocaro@cs.cardiff.ac.uk                                                  DCOSS                                       ...
OutlineOutline   1. Intro & Model      2. Architecture      3. Performance   4. Conclusion
1. Intro & Model1. Intro & Model
1. Intro & ModelScenario
1. Intro & ModelScenario  •   An already deployed network of sensors
1. Intro & ModelScenario                                               TASK 3                  TASK 7                  Mon...
1. Intro & ModelScenario                                                 TASK 3                   TASK 7                  ...
1. Intro & ModelScenario                                                 TASK 3                   TASK 7                  ...
1. Intro & ModelScenario                                                    TASK 3                      TASK 7            ...
1. Intro & ModelMulti-sensor task allocation                    h & Rescue    Earthquake Searc                            ...
1. Intro & Model          Formal model                    (p1, d1)             (p2, d2)    ‣     Difference with HOMOGENEO...
2. Architecture2. Architecture
2. ArchitectureConceptual arch.•   Solve the MSTA problem step by step, by integrating a knowledge base module    with an ...
2. ArchitectureConceptual arch. •    Solve the MSTA problem step by step, by integrating a knowledge base module      with...
2. ArchitectureConceptual arch. •    Solve the MSTA problem step by step, by integrating a knowledge base module      with...
2. ArchitectureConceptual arch. •    Solve the MSTA problem step by step, by integrating a knowledge base module      with...
2. ArchitectureConceptual arch. •    Solve the MSTA problem step by step, by integrating a knowledge base module      with...
2. ArchitectureDistributed system•   The KB bundle generator on the user device (prototype mobile app)•   The allocation m...
2. ArchitectureKB bundle generator                                                                                        ...
2. ArchitectureReasoning procedure                                                                             KB         ...
2. ArchitectureReasoning procedure                                                                                      KB...
2. ArchitectureReasoning procedure                                                                                        ...
2. ArchitectureReasoning procedure                                                                                        ...
2. ArchitectureReasoning procedure                                                                                        ...
2. ArchitectureReasoning procedure                                                                                        ...
2. ArchitectureLightweight KB                                                                              KB             ...
2. ArchitectureAllocation protocol                                                                             Allocation ...
2. ArchitectureAllocation protocol                                                                                        ...
2. ArchitectureAllocation protocol                                                                                        ...
2. ArchitectureAllocation protocol                                                                                        ...
2. ArchitectureAllocation protocol                                                                                        ...
2. ArchitectureAllocation protocol (2)                                                                     Allocation     ...
2. ArchitectureAllocation protocol (2)                                                                                    ...
2. ArchitectureAllocation protocol (2)                                                                                    ...
2. ArchitectureAllocation protocol (2)                                                                                    ...
2. ArchitectureAllocation protocol (2)                                                                                    ...
2. ArchitectureAllocation protocol (2)                                                                                    ...
3. Performance3. Performance
3. PerformanceLightweight KB (mobile app)•   Deployed as an app on iPod Touch 2nd Gen, implemented as a relationship table...
3. PerformanceAllocation protocol               ‣    We ran simulations implemented our extended protocol:                ...
3. Performance    Allocation protocol                                                ‣   We ran simulations implemented ou...
4. ConclusionConclusion‣       We formalized MSTA in heterogeneous sensor networks.‣       We proposed a novel distributed...
End        Acknowledgements                                                                   Prof. Alun Preece,          ...
Upcoming SlideShare
Loading in …5
×

A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation

645 views

Published on

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
645
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

A Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation

  1. 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. 2. OutlineOutline 1. Intro & Model 2. Architecture 3. Performance 4. Conclusion
  3. 3. 1. Intro & Model1. Intro & Model
  4. 4. 1. Intro & ModelScenario
  5. 5. 1. Intro & ModelScenario • An already deployed network of sensors
  6. 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. 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. 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. 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. 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. 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. 12. 2. Architecture2. Architecture
  13. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 27. 2. ArchitectureAllocation protocol Allocation protocol • Our protocol consists of mainly 2 stages: Initial negotiation and Bundle formation.
  28. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 38. 3. Performance3. Performance
  39. 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. 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. 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. 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. 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

×