system architectures for multi-sensor task allocation

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 [email protected]

mailto:[email protected]


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.


Multi-Sensor Task Allocation



Sensors (or Sensing assets) Tasks

Simple sensorsUsers create sensing tasks

Platforms


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


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




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.


Framework

Sensors

Task

sA

lloca

tion MSTA




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)

• 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


Detect (injured) people

Monitor collapsing building

MSTA instance:

ST - MS - IA - HE




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


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.


Conceptual Architecture




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.




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




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




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


Architectures

Allocationmechanism

unlike the KB bundle generatorthe allocation mechanism varies greatly depending

on the architecture




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.




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

• Pros:

• Global overview of the situation

• Better overall allocation

• No “heavy” computation on the mobile device or on sensor nodes

Sensor Network


Hub


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)




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




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)




Hybrid

Sensor Network


Hub


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.




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.




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.




Thanks for listening!

Questions?



system architectures for multi-sensor task allocation

Technology