Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation

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

Outline

Outline
1. Intro & Model

2. Architecture

3. Performance

4. Conclusion

1. Intro & Model

1. Intro & Model

1. Intro & Model

Scenario

• An already deployed network of sensors

1. Intro & Model

Scenario
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

- Support multiple tasks to be accomplished simultaneously

1. Intro & Model

Scenario
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
people to
identify

- Highly dynamic (sensor failures, change of plan)

1. Intro & Model

Scenario
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
people to
identify

- Highly dynamic (sensor failures, change of plan)

- Sensors are scarce and in high demand.

1. Intro & Model

Multi-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 ﬁeld 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.

1. Intro & Model

Formal model

(p1, d1) (p2, d2) ‣ Difference with HOMOGENEOUS sensors:
Utilities of groups of sensors (BUNDLES) are more
s T1 T2
e 12 complex to compute.
e11

s 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

2. Architecture

2. Architecture

2. Architecture

Conceptual 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

2. Architecture

Conceptual arch.

Mobile user
creates a
sensing task.
1
KB
Bundle
Generator

Allocation
mechanism

Sensor
Network

2. Architecture

Conceptual arch.

Mobile user
creates a
sensing task.
1 2
KB Recommends
Bundle fit-for-purpose bundles
Generator and computes utility.

Allocation
mechanism

Sensor
Network

2. Architecture

Conceptual arch.

Mobile user
creates a
sensing task.
1 2
KB Recommends

3
Allocation Finds a solution to
mechanism MSTA problem.

Sensor
Network

2. Architecture

Conceptual arch.

Mobile user
creates a
sensing task.
1 2
KB Recommends

3
Allocation Finds a solution to
mechanism MSTA problem.

4
Sensor Configured accordingly
Network and delivers data to user.

2. Architecture

Distributed 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

2. Architecture

KB 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

2. Architecture

Reasoning procedure
KB
Bundle
Generator
Task Type
Using 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

2. Architecture

Reasoning procedure
KB
Bundle
Generator
Task Type
Using sensor & task ontologies Localize vehicle
& OWL reasoner.

Which functions can

Sensor types
to choose.

compatible?
Joint Utility
Bundle Type

2. Architecture

Reasoning procedure
KB
Bundle
Generator
Task Type
& OWL reasoner.

Which functions can
1) Acoustic intelligence
2) Imagery intelligence

Sensor types
to choose.

compatible?
Joint Utility
Bundle Type

2. Architecture

Reasoning procedure
KB
Bundle
Generator
Task Type
& OWL reasoner.

Which functions can

Sensor types
to choose.

compatible?
Joint Utility
Bundle Type

BT1 = {AcousticArray}
BT2 = {UAV, Camera}

2. Architecture

Reasoning procedure
KB
Bundle
Generator
Task Type
& OWL reasoner.

Which functions can

Sensor types
to choose.

compatible?
Joint Utility
Bundle Type

BT1 = {AcousticArray} JUF1 = 2D-Localization
BT2 = {UAV, Camera} JUF2 = Detection Probability

2. Architecture

Reasoning procedure
KB
Bundle
Generator
Task Type
& OWL reasoner.

Which functions can

Sensor types
to choose.
Allocation flexibility

compatible?
Joint Utility
Bundle Type

BT1 = {AcousticArray} JUF1 = 2D-Localization
(BT1, JUF1), (BT1, JUF2), (BT2, JUF2)
BT2 = {UAV, Camera} JUF2 = Detection Probability

2. Architecture

Lightweight KB
KB
Bundle
Generator

Task Type Recommendation • The original implementation of the reasoning process is
1 (BT1 + JUF1) computationally expensive
1 (BT2 + JUF1) ‣ The reasoner uses an exponential-time classiﬁer.
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

2. Architecture

Allocation protocol Allocation
protocol

• Our protocol consists of mainly 2 stages: Initial negotiation and Bundle formation.

2. Architecture

protocol


Sensor 1 Sensor 2
User 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)


A.Post-Info(S1) B.Post-Info(S1)


bid 1 bid 2
A: {T1, (S1, S2), 0.9} B: {T2, (S1, S2), 0.8}

S2.Post-Bid(bid1) S2.Post-Bid(bid2)


2. Architecture

protocol


Sensor 1 Sensor 2
User A User B


Request-Info-For(A) Request-Info-For(B) (2) Mobile devs query sensors in the vicinity.



bid 1 bid 2
A: {T1, (S1, S2), 0.9} B: {T2, (S1, S2), 0.8}



2. Architecture

protocol


Sensor 1 Sensor 2
User A User B



(3) Using the KB bundle generator,
the device creates a bid for a sensor bundle
which optimally satisﬁes the sensing task.

bid 1 bid 2
A: {T1, (S1, S2), 0.9} B: {T2, (S1, S2), 0.8}



2. Architecture

protocol


Sensor 1 Sensor 2
User A User B



(3) Using the KB bundle generator,
the device creates a bid for a sensor bundle
which optimally satisﬁes 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}



2. Architecture

Allocation protocol (2) Allocation
protocol
Bundle formation: The sensors decide the most proﬁtable sensor bundle to join.

We allow preemption of already allocated sensors and a rebidding mechanism.

2. Architecture

protocol


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)


Task satiﬁed Task unsatisﬁed

bid 3
B: {T2, (S3, S4), 0.7}

2. Architecture

protocol


Bundle formation:

(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)




bid 3
B: {T2, (S3, S4), 0.7}

2. Architecture

protocol


Bundle formation:


S2.Cleared(S1)

(3) If sensor receives ACCEPTs from all sensors in bundle, S1.Cleared(S2)

it sends a CLEARED to all bid neighbours.
The sensor starts serving the task notifying the user.


bid 3
B: {T2, (S3, S4), 0.7}

2. Architecture

protocol


Bundle formation:


S2.Cleared(S1)



(4) A sensor receiving a CLEARED deletes the bids involving
the sender sensor. It stops when clears a bid or list is empty. bid 3
B: {T2, (S3, S4), 0.7}

2. Architecture

protocol


Bundle formation:


S2.Cleared(S1)



(4) A sensor receiving a CLEARED deletes the bids involving
the 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 timeout
to satisfy the task expires.

3. Performance

3. Performance

3. Performance

Lightweight 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.

3. Performance

Allocation protocol
‣ We ran simulations implemented our extended protocol:

• 250 Static sensors of different types (already deployed).

• 50 Mobile users on the ﬁeld.

• Task generated with uniform random distribution.

‣ Allocation quality improves using our extend protocol:

• Compared with the original and 2 other versions

3. Performance

Allocation protocol
‣ We ran simulations implemented our extended protocol:

• 250 Static sensors of different types (already deployed).

• 50 Mobile users on the ﬁeld.

• 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

4. Conclusion

Conclusion
‣ We formalized MSTA in heterogeneous sensor networks.

‣ We proposed a novel distributed architecture which integrates a knowledge
base with an allocation protocol, providing ﬂexibility 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”.

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

Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation

Recomendados

Recomendados

Mais conteúdo relacionado

Último

Último (20)

Destaque

Destaque (20)

Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation