System Architectures for Multi-Sensor Task Allocation

ACITA 2010

System Architectures for
Multi-Sensor Task Allocation
Diego Pizzocaro, Alun Preece

Fangfei Chen, Tom La Porta

Matthew P. Johnson, Amotz Bar-Noy.

http://users.cs.cf.ac.uk/D.Pizzocaro D.Pizzocaro@cs.cf.ac.uk

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.


Outline

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.


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


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)


h & Rescue
Earthquake Searc

• Coalition members on the ﬁeld 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


Framework

Formalizing MSTA
Various MSTA instances imply the need for a classiﬁcation scheme,
helping us to identify the relevant problems.

Allocation
MSTA

Sensors
ks
s
Ta


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)


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.


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.


Conceptual Architecture

Conceptual Architecture
valid for both problem instances (Single and Multi Task sensors)
which highlights the steps necessary to ﬁnd a solution.


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.


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


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


Lightweight KB
• The original implementation of the reasoning process is
computationally expensive

Task Type Recommendation • The reasoner uses an exponential-time classiﬁcation.
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 sufﬁciently 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)


Architectures

Allocation Mechanisms
unlike the KB bundle generator
the allocation mechanism varies greatly depending
on the architecture

Allocation
mechanism


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


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.


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)


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


Protocols & Features

• Well known efﬁcient 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 trafﬁc (hypothesized on past results - verifying)


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.


Hybrid with data logs
• In the previous architecture:
‣ A better solution is not guaranteed, the two mechanisms might work in potential conﬂict.
‣ The synchronisation protocol will increase the network trafﬁc

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.


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


Thanks for listening!

Questions?


System Architectures for Multi-Sensor Task Allocation

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (17)

Último

Último (20)

System Architectures for Multi-Sensor Task Allocation