system architectures for multi-sensor task allocation
Post on 05-Dec-2014
430 Views
Preview:
DESCRIPTION
TRANSCRIPT
ACITA 2010
Fangfei Chen, Tom La Porta
Matthew P. Johnson, Amotz Bar-Noy.
System Architectures forMulti-Sensor Task Allocation
Diego Pizzocaro, Alun Preece
http://users.cs.cf.ac.uk/D.Pizzocaro D.Pizzocaro@cs.cf.ac.uk
Why this paper?
http://users.cs.cf.ac.uk/D.Pizzocaro D.Pizzocaro@cs.cf.ac.uk
‣ 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.
Outline
http://users.cs.cf.ac.uk/D.Pizzocaro D.Pizzocaro@cs.cf.ac.uk
1. Multi-Sensor Task Allocation (MSTA)
2. Formalizing MSTA problems
3. Conceptual architecture
4. Cetralized, Distributed, Hybrid
5. Discussion & Conclusion
Main problem
is the problem of automatically allocating sensors to tasks satisfying the user’s information requirements.
http://users.cs.cf.ac.uk/D.Pizzocaro D.Pizzocaro@cs.cf.ac.uk
Multi-Sensor Task Allocation
Sensors (or Sensing assets) Tasks
Simple sensorsUsers create sensing tasks
Platforms
http://users.cs.cf.ac.uk/D.Pizzocaro D.Pizzocaro@cs.cf.ac.uk
TASK 3
Area Surveillance
TASK 4
Area Surveillance
TASK 1
Detectvehicle TASK 2
Identifypeople
Scenario
• A network of heterogeneous sensing assets:
- Support multiple tasks competing for bundles of sensors
TASK 7Localize
Jeep
http://users.cs.cf.ac.uk/D.Pizzocaro D.Pizzocaro@cs.cf.ac.uk
TASK 3
DetectPeople
TASK 5
DetectHelicopter
TASK 1
Identifypeople
TASK 6
IdentifyTank
TASK 4
DetectAircraft
- Sensors are scarce and in high demand.
- Highly dynamic (sensor failures, change of plan)
TASK 2
DetectGround Vehicle
http://users.cs.cf.ac.uk/D.Pizzocaro D.Pizzocaro@cs.cf.ac.uk
Multi-Sensor Task Allocation
• Coalition members 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.
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
Unmanned Sensor
Earthquake Search & Rescue
Detect
(injured) people
Monitor
collapsing building
Formalizing MSTAVarious MSTA instances imply the need for a classification scheme,
helping us to identify the relevant problems.
http://users.cs.cf.ac.uk/D.Pizzocaro D.Pizzocaro@cs.cf.ac.uk
Framework
Sensors
Task
sA
lloca
tion MSTA
http://users.cs.cf.ac.uk/D.Pizzocaro D.Pizzocaro@cs.cf.ac.uk
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)
http://users.cs.cf.ac.uk/D.Pizzocaro D.Pizzocaro@cs.cf.ac.uk
Single-Task sensors (No sharing)
• Referred to as Disjoint Coalition Formation problem in multi-agent community.
• 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.
T2
T1
xUnmanned Sensor
Earthquake Search & Rescue
Detect (injured) people
Monitor collapsing building
MSTA instance:
ST - MS - IA - HE
http://users.cs.cf.ac.uk/D.Pizzocaro D.Pizzocaro@cs.cf.ac.uk
Multi-Task sensors (Sharing)
• Referred to as Overlapping Coalition Formation problem in multi-agent community.
• 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.
T2
T1
Unmanned Sensor
Earthquake Search & Rescue
Detect (injured) people
Monitor collapsing building
MSTA instance:
MT - MS - IA - HE
Conceptual Architecturevalid for both problem instances (Single and Multi Task sensors)
which highlights the steps necessary to find a solution.
http://users.cs.cf.ac.uk/D.Pizzocaro D.Pizzocaro@cs.cf.ac.uk
Conceptual Architecture
http://users.cs.cf.ac.uk/D.Pizzocaro D.Pizzocaro@cs.cf.ac.uk
Conceptual architecture
KBBundle
Generator
Allocationmechanism
SensorNetwork
1Mobile user creates a sensing task.
2Recommends fit-for-purpose sensor bundles for that task type.
3Finds a solution to eitherST-MS-IA-HE (No sharing) or MT-MS-IA-HE (Sharing).
4Configured accordingly and delivers data to user.
http://users.cs.cf.ac.uk/D.Pizzocaro D.Pizzocaro@cs.cf.ac.uk
KB Bundle Generator
• MSTA in Heterogeneous sensor networks requires knowledge of
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.
• 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
KBBundle
Generator
http://users.cs.cf.ac.uk/D.Pizzocaro D.Pizzocaro@cs.cf.ac.uk
Reasoning procedure
Task Type
CapabilitiesRequired
Joint Utility FunctionBundle Type
Using sensor & task ontologies& OWL reasoner.
Sensor types to choose.
= Recommendations
Localize vehicle
1) Acoustic intelligence2) Imagery intelligence
BT1 = {AcousticArray}BT2 = {UAV, Camera}
JUF1 = 2D-LocalizationJUF2 = Detection Probability
compatible?
(BT1, JUF1), (BT1, JUF2), (BT2, JUF2)
Which functions can be used to estimate the performances?
Allocation flexibility
http://users.cs.cf.ac.uk/D.Pizzocaro D.Pizzocaro@cs.cf.ac.uk
Lightweight KB
• The original implementation of the reasoning process is computationally expensive
• The reasoner uses an exponential-time classification.
• On a mobile device is not recommended.
• Precompute the results of the reasoner and store themin a look-up table
• Task types and sensor types are “stable”
• Reasoning operations are O(1)
• Assumption: the device has sufficiently large store capacity.
• 4000 different task types, 5 different recommendation per task type (BT+JUF)
• ~ 12 MB of storage required, ~ 20 ms (increasing logarithmically)
Task Type Recommendation
1 (BT1 + JUF1)
1 (BT2 + JUF1)
1 (BT2 + JUF2)
2 (BT3 + JUF1)
2 (BT2 + JUF1)
2 (BT2 + JUF2)
... ...
N (BT5 + JUM1)
Allocation Mechanisms
http://users.cs.cf.ac.uk/D.Pizzocaro D.Pizzocaro@cs.cf.ac.uk
Architectures
Allocationmechanism
unlike the KB bundle generatorthe allocation mechanism varies greatly depending
on the architecture
http://users.cs.cf.ac.uk/D.Pizzocaro D.Pizzocaro@cs.cf.ac.uk
Centralized
Sensor Network
CentralAllocationalgorithm
Hub
CentralKB - Bundle Generator
Base Station(s)
Users
• Currently many mobile apps are cloud based with a powerful central server.
• Mobile devices are just the interface into the system (to create tasks)
‣ Task posted to the
central engine
(KB and Allocation alg).
‣ When connectivity to the
base station is down, can use
the sensor network to
support communication.
http://users.cs.cf.ac.uk/D.Pizzocaro D.Pizzocaro@cs.cf.ac.uk
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.
http://users.cs.cf.ac.uk/D.Pizzocaro D.Pizzocaro@cs.cf.ac.uk
Features
• Pros:
• Global overview of the situation
• Better overall allocation
• No “heavy” computation on the mobile device or on sensor nodes
Sensor Network
CentralAllocationalgorithm
Hub
CentralKB - Bundle Generator
Base Station(s)
Users
• 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)
http://users.cs.cf.ac.uk/D.Pizzocaro D.Pizzocaro@cs.cf.ac.uk
Distributed
Sensor Network
Allocationprotocol
Allocationprotocol
KB Bundle
Generator
Allocationprotocol
KB Bundle
Generator
Allocationprotocol
KB Bundle
Generator
• Moves the KB bundle gen. on the user device (Lightweight KB bundle generator)
• Moves the allocation mechanism on the sensors (distributed protocols)
‣ User communicates directly the task created to the sensors
‣ The sensors autonomously negotiate the best task to serve as part of a bundle
http://users.cs.cf.ac.uk/D.Pizzocaro D.Pizzocaro@cs.cf.ac.uk
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)
http://users.cs.cf.ac.uk/D.Pizzocaro D.Pizzocaro@cs.cf.ac.uk
Hybrid
Sensor Network
CentralAllocationalgorithm
Hub
CentralKB - Bundle Generator
Base Station(s)
Users
Allocationprotocol
Syncprotocol
Allocationprotocol
Syncprotocol
KB Bundle
Generator
• Combine aspects of both mechanisms into a hybrid architecture.
• Distributed architecture connected with a base station central allocation engine.
‣ Task posted to the
central engine when user
has connection.
‣ When connectivity to the
base station is down,
the system is able to
perform autonomously
‣ We need a sync protocol,
need to know if the local
protocol has started before
running the central algorithm.
http://users.cs.cf.ac.uk/D.Pizzocaro D.Pizzocaro@cs.cf.ac.uk
Hybrid with data logs
Sensor Network
Base Stations
DataCenter
Updateprotocol
Allocationprotocol
Allocationprotocol
Updateprotocol
KB Bundle
Generator
• 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
‣ Provide the big picture
to base station leaving the
allocation to the
distributed protocol.
‣ Update protocol is used
by sensors and users when an
something changes in the
network.
http://users.cs.cf.ac.uk/D.Pizzocaro D.Pizzocaro@cs.cf.ac.uk
Conclusion & Future
• 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
• We have presented and analyzed 4 different architectures to solve the MSTA problem
supporting coalition members on the field.
http://users.cs.cf.ac.uk/D.Pizzocaro D.Pizzocaro@cs.cf.ac.uk
Thanks for listening!
Questions?
top related