System Architectures for Multi-Sensor Task Allocation


Published on

Paper presentation at 4th Annual Conference of the International Technology Alliance (ACITA 2010), 
Imperial College London, UK 
September 2010.

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

System Architectures for Multi-Sensor Task Allocation

  1. 1. ACITA 2010 System Architectures for Multi-Sensor Task Allocation Diego Pizzocaro, Alun Preece Fangfei Chen, Tom La Porta Matthew P. Johnson, Amotz Bar-Noy.
  2. 2. Why this paper? ‣ In our previous work we developed a variety of allocation mechanisms inspired by real scenarios ‣ ...but we decided to imagine what a real interface would look like... ‣ The prototype* interface inspired many discussions about system architectures ‣ The novelty of our architectures consists in a modular approach to solve the allocation problem (integrating a KB module with an allocation mechanism) * Apple iPhone choice motivated mainly by its popularity and development tool provided.
  3. 3. Outline 1. Multi-Sensor Task Allocation (MSTA) 2. Formalizing MSTA problems 3. Conceptual architecture 4. Cetralized, Distributed, Hybrid 5. Discussion & Conclusion
  4. 4. Main problem Multi-Sensor Task Allocation is the problem of automatically allocating sensors to tasks satisfying the user’s information requirements.
  5. 5. Sensors Tasks (or Sensing assets) Simple sensors Users create sensing tasks TASK 3 Platforms TASK 4 Area Surveillance Area TASK 1 Surveillance Detect vehicle TASK 2 Identify people
  6. 6. Scenario TASK 3 TASK 7 Localize Detect Jeep People TASK 4 Detect TASK 6 Aircraft Identify Tank TASK 1 TASK 2 TASK 5 Detect Identify Detect Ground people Vehicle Helicopter • A network of heterogeneous sensing assets: - Support multiple tasks competing for bundles of sensors - Sensors are scarce and in high demand. - Highly dynamic (sensor failures, change of plan)
  7. 7. Multi-Sensor Task Allocation h & Rescue Earthquake Searc • Coalition members on the field have usually Unmanned Senso r no time and no expertise to manually decide the best sensors for each task. • We need to automatically allocate sensors to tasks Monitor to satisfy the information requirements of each user. Detect collapsing buildin g (injured) people Various problem settings but the fundamental question: “Which sensor should be allocated to which task?” We call it the Multi-Sensor Task Allocation (MSTA) problem
  8. 8. Framework Formalizing MSTA Various MSTA instances imply the need for a classification scheme, helping us to identify the relevant problems. Allocation MSTA Sensors ks s Ta
  9. 9. Taxonomy • We propose a MSTA taxonomy organized on four main axes: 1. Sensors: Single-task (ST) vs. multi-task (MT). 2. Tasks: Single-sensor (SS) vs. multi-sensor (MS). 3. Assignment: Instantaneous (IA) vs. time-extended (TA). 4. Sensor Network: Homogeneous (HO) vs. heterogeneous (HE). Given our military/emergency response scenario, our focus is: • Coalition: Heterogeneous sensor networks (HE) • Dynamic environment: Instantaneous Allocation (IA) • Complex sensing requirements: Multi-Sensor tasks (MS) • Sensor capabilities: both Single-Task (ST) and Multi-Task (MT)
  10. 10. Single-Task sensors (No sharing) Earthquake Search & Rescue Unmanned Sensor x MSTA instance: T2 ST - MS - IA - HE T1 • Referred to as Disjoint Coalition Formation problem in multi-agent community. Detect Monitor • (injured) people collapsing building It can be modelled as a Set Partitioning Problem (SPP) • Set of sensors S • Families F of acceptable subsets of S • Each family F is associated with a utility u • Goal: Find a maximum utility family X of elements in F such that X is a partition of S. • NB: here we allow sensors to remain unallocated and tasks to be dropped.
  11. 11. Multi-Task sensors (Sharing) Earthquake Search & Rescue Unmanned Sensor MSTA instance: T2 MT - MS - IA - HE T1 • Referred to as Overlapping Detect Coalition Formation problem in multi-agent community. Monitor (injured) people collapsing building • It can be modelled as a Set Covering Problem (SPP) • Set of sensors S • Families F of acceptable subsets of S - (representing overlapping coalitions) • Each family F is associated with a utility u • Goal: Find a maximum utility family X of elements in F such that X is a cover of S. • NB: also here we allow sensors to remain unallocated and tasks to be dropped.
  12. 12. Conceptual Architecture Conceptual Architecture valid for both problem instances (Single and Multi Task sensors) which highlights the steps necessary to find a solution.
  13. 13. Conceptual architecture Mobile user creates a sensing task. 1 2 KB Recommends Bundle fit-for-purpose sensor Generator bundles for that task type. 3 Allocation Finds a solution to either mechanism ST-MS-IA-HE (No sharing) or MT-MS-IA-HE (Sharing). 4 Sensor Configured accordingly Network and delivers data to user.
  14. 14. KB Bundle Generator • MSTA in Heterogeneous sensor networks requires knowledge of KB which sensor types are applicable to which kinds of task. Bundle Generator • 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. • 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
  15. 15. Reasoning procedure Task Type Using 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
  16. 16. Lightweight KB • The original implementation of the reasoning process is computationally expensive Task Type Recommendation • The reasoner uses an exponential-time classification. 1 (BT1 + JUF1) • On a mobile device is not recommended. 1 (BT2 + JUF1) 1 (BT2 + JUF2) • Precompute the results of the reasoner and store them in a look-up table 2 (BT3 + JUF1) 2 (BT2 + JUF1) • Task types and sensor types are “stable” 2 (BT2 + JUF2) • Reasoning operations are O(1) ... ... • Assumption: the device has sufficiently large store capacity. N (BT5 + JUM1) • 4000 different task types, 5 different recommendation per task type (BT+JUF) • ~ 12 MB of storage required, ~ 20 ms (increasing logarithmically)
  17. 17. Architectures Allocation Mechanisms unlike the KB bundle generator the allocation mechanism varies greatly depending on the architecture Allocation mechanism
  18. 18. Centralized • Currently many mobile apps are cloud based with a powerful central server. • Mobile devices are just the interface into the system (to create tasks) Users Base Station(s) Central KB - Bundle Generator ‣ Task posted to the Hub central engine (KB and Allocation alg). Central Allocation algorithm ‣ When connectivity to the base station is down, can use the sensor network to Sensor support communication. Network
  19. 19. Centralized allocation algorithms ST-MS-IA-HE: Single Task sensors (No sharing) • This can be seen as a combinatorial auction ‣ bidders: tasks ‣ items: sensors ‣ tasks bids for bundles of sensors • Many algorithms have been proposed: we use CASS (Combinatorial Auction Structured Search) MT-MS-IA-HE: Multi Task sensors (Sharing) • This can be solved with a Set Covering Problem (SCP) approximation algorithms: ‣ Poor performances if the number of allowed sensors in a bundle is large. ‣ The KB bundle generator limits the number of sensors that can be chosen.
  20. 20. Features Users Base Station(s) • Pros: Central KB - Bundle Generator • Global overview of the situation Central Hub • Better overall allocation • Allocation algorithm No “heavy” computation on the mobile device or on sensor nodes Sensor Network • Cons: • Periodic collection of data and allocation decisions every constant interval • If a certain area becomes “hot” (e.g. explosion or building collapses): ➡ Suddenly many mobile users occupies the same area, ➡ Overload of the mobile telecommunication network. • Sending the data over sensor network as a backup ➡ only shifts the overload on the sensor network (and decreases the lifetime of sensors)
  21. 21. Distributed • Moves the KB bundle gen. on the user device (Lightweight KB bundle generator) • Moves the allocation mechanism on the sensors (distributed protocols) KB Bundle KB KB Bundle Generator Bundle Generator Generator Allocation protocol Allocation Allocation protocol protocol ‣ User communicates directly the task created to the sensors Sensor Network ‣ The sensors autonomously negotiate the best task to serve as part of a bundle Allocation protocol
  22. 22. Protocols & Features • Well known efficient allocation protocols have been proposed for the disjoint and overlapping coalition formation problems. • We have adapted these to solve the ST-MS-IA-HE (No sharing) and MT-MS-IA-HE (Sharing) • Pros: • There is no need to periodically collect data or synchronize allocation • If new task type introduced, there is no need for wireless reprogramming sensors. We would just update all the KBs on the user devices. • Cons • No central base station offering an overview • Quality of the solution is worse than centralized (hypothesized on past results - verifying) • Less network traffic (hypothesized on past results - verifying)
  23. 23. Hybrid• Combine aspects of both mechanisms into a hybrid architecture.• Distributed architecture connected with a base station central allocation engine. Users ‣ Task posted to the KB central engine when user Base Station(s) Sync Bundle has connection. protocol Generator Central KB - Bundle Generator ‣ When connectivity to the Allocation base station is down, protocol Hub the system is able to perform autonomously Central Allocation algorithm ‣ We need a sync protocol, need to know if the local protocol has started before Sync Sensor Allocation protocol Network protocol running the central algorithm.
  24. 24. Hybrid with data logs• In the previous architecture: ‣ A better solution is not guaranteed, the two mechanisms might work in potential conflict. ‣ The synchronisation protocol will increase the network traffic Base Stations Update KB protocol Bundle Generator ‣ Provide the big picture to base station leaving the Data Allocation Center protocol allocation to the distributed protocol. ‣ Update protocol is used Update Allocation by sensors and users when an Sensor protocol protocol something changes in the Network network.
  25. 25. Conclusion & Future • We have presented and analyzed 4 different architectures to solve the MSTA problem supporting coalition members on the field. • These architectures may be considered in terms of their fit for coalition command and control structures. • Central - fits well with high echelon command centre (decisions needs overview) • Distributed - resembles the case of local commanders (no time and no expertise) • Hybrid with data logs - might fit both • We are currently conducting experiments to • compare solution quality, measure network traffic, sensor/user device performances
  26. 26. Thanks for listening! Questions?