Unlocking the Power of ChatGPT and AI in Testing - A Real-World Look, present...
Distributed Architecture for Heterogeneous Multi-Sensor Task Allocation
1. 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
5. 1. Intro & Model
Scenario
• An already deployed network of sensors
6. 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
• An already deployed network of sensors
- Support multiple tasks to be accomplished simultaneously
7. 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
• An already deployed network of sensors
- Support multiple tasks to be accomplished simultaneously
- Highly dynamic (sensor failures, change of plan)
8. 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
• An already deployed network of sensors
- Support multiple tasks to be accomplished simultaneously
- Highly dynamic (sensor failures, change of plan)
- Sensors are scarce and in high demand.
9. 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
• An already deployed network of sensors
- Support multiple tasks to be accomplished simultaneously
- Highly dynamic (sensor failures, change of plan)
- Sensors are scarce and in high demand.
10. 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 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.
11. 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
13. 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
14. 2. Architecture
Conceptual arch.
• Solve the MSTA problem step by step, by integrating a knowledge base module
with an allocation mechanism.
Mobile user
creates a
sensing task.
1
KB
Bundle
Generator
Allocation
mechanism
Sensor
Network
15. 2. Architecture
Conceptual arch.
• Solve the MSTA problem step by step, by integrating a knowledge base module
with an allocation mechanism.
Mobile user
creates a
sensing task.
1 2
KB Recommends
Bundle fit-for-purpose bundles
Generator and computes utility.
Allocation
mechanism
Sensor
Network
16. 2. Architecture
Conceptual arch.
• Solve the MSTA problem step by step, by integrating a knowledge base module
with an allocation mechanism.
Mobile user
creates a
sensing task.
1 2
KB Recommends
Bundle fit-for-purpose bundles
Generator and computes utility.
3
Allocation Finds a solution to
mechanism MSTA problem.
Sensor
Network
17. 2. Architecture
Conceptual arch.
• Solve the MSTA problem step by step, by integrating a knowledge base module
with an allocation mechanism.
Mobile user
creates a
sensing task.
1 2
KB Recommends
Bundle fit-for-purpose bundles
Generator and computes utility.
3
Allocation Finds a solution to
mechanism MSTA problem.
4
Sensor Configured accordingly
Network and delivers data to user.
18. 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
19. 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
20. 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
21. 2. Architecture
Reasoning procedure
KB
Bundle
Generator
Task Type
Using sensor & task ontologies Localize vehicle
& OWL reasoner.
Which functions can
Capabilities be used to estimate
Required the performances?
Sensor types
to choose.
compatible?
Joint Utility
Bundle Type
Function = Recommendations
22. 2. Architecture
Reasoning procedure
KB
Bundle
Generator
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.
compatible?
Joint Utility
Bundle Type
Function = Recommendations
23. 2. Architecture
Reasoning procedure
KB
Bundle
Generator
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.
compatible?
Joint Utility
Bundle Type
Function = Recommendations
BT1 = {AcousticArray}
BT2 = {UAV, Camera}
24. 2. Architecture
Reasoning procedure
KB
Bundle
Generator
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.
compatible?
Joint Utility
Bundle Type
Function = Recommendations
BT1 = {AcousticArray} JUF1 = 2D-Localization
BT2 = {UAV, Camera} JUF2 = Detection Probability
25. 2. Architecture
Reasoning procedure
KB
Bundle
Generator
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
26. 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 classifier.
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
27. 2. Architecture
Allocation protocol Allocation
protocol
• Our protocol consists of mainly 2 stages: Initial negotiation and Bundle formation.
28. 2. Architecture
Allocation protocol Allocation
protocol
• Our protocol consists of mainly 2 stages: Initial negotiation and Bundle formation.
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)
Request-Info-For(A) Request-Info-For(B)
A.Post-Info(S1) B.Post-Info(S1)
A.Post-Info(S2) B.Post-Info(S2)
bid 1 bid 2
A: {T1, (S1, S2), 0.9} B: {T2, (S1, S2), 0.8}
S2.Post-Bid(bid1) S2.Post-Bid(bid2)
S1.Post-Bid(bid1) S2.Post-Bid(bid2)
29. 2. Architecture
Allocation protocol Allocation
protocol
• Our protocol consists of mainly 2 stages: Initial negotiation and Bundle formation.
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)
Request-Info-For(A) Request-Info-For(B) (2) Mobile devs query sensors in the vicinity.
A.Post-Info(S1) B.Post-Info(S1)
A.Post-Info(S2) B.Post-Info(S2)
bid 1 bid 2
A: {T1, (S1, S2), 0.9} B: {T2, (S1, S2), 0.8}
S2.Post-Bid(bid1) S2.Post-Bid(bid2)
S1.Post-Bid(bid1) S2.Post-Bid(bid2)
30. 2. Architecture
Allocation protocol Allocation
protocol
• Our protocol consists of mainly 2 stages: Initial negotiation and Bundle formation.
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)
Request-Info-For(A) Request-Info-For(B) (2) Mobile devs query sensors in the vicinity.
A.Post-Info(S1) B.Post-Info(S1)
(3) Using the KB bundle generator,
the device creates a bid for a sensor bundle
A.Post-Info(S2) B.Post-Info(S2)
which optimally satisfies the sensing task.
bid 1 bid 2
A: {T1, (S1, S2), 0.9} B: {T2, (S1, S2), 0.8}
S2.Post-Bid(bid1) S2.Post-Bid(bid2)
S1.Post-Bid(bid1) S2.Post-Bid(bid2)
31. 2. Architecture
Allocation protocol Allocation
protocol
• Our protocol consists of mainly 2 stages: Initial negotiation and Bundle formation.
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)
Request-Info-For(A) Request-Info-For(B) (2) Mobile devs query sensors in the vicinity.
A.Post-Info(S1) B.Post-Info(S1)
(3) Using the KB bundle generator,
the device creates a bid for a sensor bundle
A.Post-Info(S2) B.Post-Info(S2)
which optimally satisfies 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}
S2.Post-Bid(bid1) S2.Post-Bid(bid2)
S1.Post-Bid(bid1) S2.Post-Bid(bid2)
32. 2. Architecture
Allocation protocol (2) Allocation
protocol
Bundle formation: The sensors decide the most profitable sensor bundle to join.
We allow preemption of already allocated sensors and a rebidding mechanism.
33. 2. Architecture
Allocation protocol (2) Allocation
protocol
Bundle formation: The sensors decide the most profitable sensor bundle to join.
We allow preemption of already allocated sensors and a rebidding mechanism.
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)
A.Task-Sat(S2, bid1) B.Task-Sat(S2, bid1)
Task satified Task unsatisfied
bid 3
B: {T2, (S3, S4), 0.7}
34. 2. Architecture
Allocation protocol (2) Allocation
protocol
Bundle formation: The sensors decide the most profitable sensor bundle to join.
We allow preemption of already allocated sensors and a rebidding mechanism.
Bundle formation:
User A Sensor 1 Sensor 2 User B
(1) Each sensor keeps a list of bids. S2.Accept(bid1, S1)
(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)
A.Task-Sat(S1, bid1) B.Task-Sat(S1, bid1)
A.Task-Sat(S2, bid1) B.Task-Sat(S2, bid1)
Task satified Task unsatisfied
bid 3
B: {T2, (S3, S4), 0.7}
35. 2. Architecture
Allocation protocol (2) Allocation
protocol
Bundle formation: The sensors decide the most profitable sensor bundle to join.
We allow preemption of already allocated sensors and a rebidding mechanism.
Bundle formation:
User A Sensor 1 Sensor 2 User B
(1) Each sensor keeps a list of bids. S2.Accept(bid1, S1)
(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)
(3) If sensor receives ACCEPTs from all sensors in bundle, S1.Cleared(S2)
it sends a CLEARED to all bid neighbours.
A.Task-Sat(S1, bid1) B.Task-Sat(S1, bid1)
The sensor starts serving the task notifying the user.
A.Task-Sat(S2, bid1) B.Task-Sat(S2, bid1)
Task satified Task unsatisfied
bid 3
B: {T2, (S3, S4), 0.7}
36. 2. Architecture
Allocation protocol (2) Allocation
protocol
Bundle formation: The sensors decide the most profitable sensor bundle to join.
We allow preemption of already allocated sensors and a rebidding mechanism.
Bundle formation:
User A Sensor 1 Sensor 2 User B
(1) Each sensor keeps a list of bids. S2.Accept(bid1, S1)
(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)
(3) If sensor receives ACCEPTs from all sensors in bundle, S1.Cleared(S2)
it sends a CLEARED to all bid neighbours.
A.Task-Sat(S1, bid1) B.Task-Sat(S1, bid1)
The sensor starts serving the task notifying the user.
A.Task-Sat(S2, bid1) B.Task-Sat(S2, bid1)
(4) A sensor receiving a CLEARED deletes the bids involving
Task satified Task unsatisfied
the sender sensor. It stops when clears a bid or list is empty. bid 3
B: {T2, (S3, S4), 0.7}
37. 2. Architecture
Allocation protocol (2) Allocation
protocol
Bundle formation: The sensors decide the most profitable sensor bundle to join.
We allow preemption of already allocated sensors and a rebidding mechanism.
Bundle formation:
User A Sensor 1 Sensor 2 User B
(1) Each sensor keeps a list of bids. S2.Accept(bid1, S1)
(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)
(3) If sensor receives ACCEPTs from all sensors in bundle, S1.Cleared(S2)
it sends a CLEARED to all bid neighbours.
A.Task-Sat(S1, bid1) B.Task-Sat(S1, bid1)
The sensor starts serving the task notifying the user.
A.Task-Sat(S2, bid1) B.Task-Sat(S2, bid1)
(4) A sensor receiving a CLEARED deletes the bids involving
Task satified Task unsatisfied
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.
39. 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.
40. 3. Performance
Allocation protocol
‣ We ran simulations implemented our extended protocol:
• 250 Static sensors of different types (already deployed).
• 50 Mobile users on the field.
• Task generated with uniform random distribution.
‣ Allocation quality improves using our extend protocol:
• Compared with the original and 2 other versions
41. 3. Performance
Allocation protocol
‣ We ran simulations implemented our extended protocol:
• 250 Static sensors of different types (already deployed).
• 50 Mobile users on the field.
• 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
42. 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 flexibility 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”.
43. 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