An Ontology-Centric Approach to Sensor-Mission Assignment

453 views

Published on

Paper presentation at EKAW 2008, Aci-Trezza, Sicily (Italy)
03/10/08

Published in: Education, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
453
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
29
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

An Ontology-Centric Approach to Sensor-Mission Assignment

  1. 1. EKAW 2008 An Ontology-Centric Approach to Sensor-Mission Assignment Mario Gomez † Alun Preece ‡ Matthew P. Johnson + Geeth de Mel † Wamberto Vasconcelos † Christopher Gibson Amotz Bar-Noy + Konrad Borowiecki ‡ Tom La Porta∗Diego Pizzocaro ‡ Hosam Rowaihy ∗ Gavin Pearson § and Tien Pham ¶ † University of Aberdeen, UK§ Defence Science and Technology Laboratory, UK ‡ Cardiff University, UK IBM, UK ¶ Army Research Laboratory, USA + City University of New York, USA ∗ Pennsylvania State University, USA
  2. 2. EKAW 2008 An Ontology-Centric Approach to Sensor-Mission Assignment Mario Gomez † Alun Preece ‡ Matthew P. Johnson + Geeth de Mel † Wamberto Vasconcelos † Christopher Gibson Amotz Bar-Noy + Konrad Borowiecki ‡ Tom La Porta∗Diego Pizzocaro ‡ Hosam Rowaihy ∗ Gavin Pearson § and Tien Pham ¶ † University of Aberdeen, UK§ Defence Science and Technology Laboratory, UK ‡ Cardiff University, UK IBM, UK ¶ Army Research Laboratory, USA + City University of New York, USA ∗ Pennsylvania State University, USA
  3. 3. Outline Sensor-Mission Assignment problem1. Sensor-Task Fitting 2. Sensor-Task Allocation 3. Sensor Deployment and Delivery Conclusion & Future
  4. 4. Why so many authors? Mario Gomez † Alun Preece ‡ Matthew P. Johnson + Geeth de Mel † Wamberto Vasconcelos † Christopher Gibson Amotz Bar-Noy + Konrad Borowiecki ‡ Tom La Porta∗ Diego Pizzocaro ‡ Hosam Rowaihy ∗ Gavin Pearson § and Tien Pham ¶• The heterogeneity of the problem requires a modular approach.• We present a conceptual system architecture: every author developed interlinked modules.• The architecture is centered around an ontology.
  5. 5. Why so many authors? Mario Gomez † Alun Preece ‡ Matthew P. Johnson + Geeth de Mel † Wamberto Vasconcelos † Christopher Gibson Amotz Bar-Noy + Konrad Borowiecki ‡ Tom La Porta∗ ____________________ Diego Pizzocaro ‡ Hosam Rowaihy ∗ Gavin Pearson § and Tien Pham ¶ = 13• The heterogeneity of the problem requires a modular approach.• We present a conceptual system architecture: every author developed interlinked modules.• The architecture is centered around an ontology.
  6. 6. Sensors(or Sensing asset) Simple sensors Platforms
  7. 7. Sensors(or Sensing asset) Simple sensors Platforms
  8. 8. Sensors Missions(or Sensing asset) composed by different tasks: Simple sensors e.g. Search-&-Rescue mission TASK 3 TASK 4 Area Surveillance (possible threats) Platforms Area Surveillance TASK 1 (possible threats) Injured people to TASK 2 identify Injured people to identify
  9. 9. Main problem: Sensor-Mission Assignmentis the problem of assigning sensing assets tomissions to cover the information needs of individual tasks in each mission.
  10. 10. Scenario
  11. 11. Scenario TASK 7 TASK 3 Aerial Surveillance Area TASK 4 Surveillance TASK 6 Area (possible threats) Surveillance Discover (possible threats) mines TASK 8 TASK 1 Detect TASK 5 suspicious Injured vehicles TASK 2 Audio Injured people Intelligence people to identify to identify• A network of heterogeneous sensing assets: - Support multiple missions to be accomplished simultaneously.
  12. 12. Scenario TASK 7 TASK 3 Aerial Surveillance Area TASK 4 Surveillance TASK 6 Area (possible threats) Surveillance Discover (possible threats) mines TASK 8 TASK 1 Detect TASK 5 suspicious Injured vehicles TASK 2 Audio Injured people Intelligence people to identify to identify• A network of heterogeneous sensing assets: - Support multiple missions to be accomplished simultaneously. - Sensing assets are scarce and in high demand.
  13. 13. Scenario TASK 7 TASK 3 Aerial Surveillance Area TASK 4 Surveillance TASK 6 Area (possible threats) Surveillance Discover (possible threats) mines TASK 8 TASK 1 Detect TASK 5 suspicious Injured vehicles TASK 2 Audio Injured people Intelligence people to identify to identify• A network of heterogeneous sensing assets: - Support multiple missions to be accomplished simultaneously. - Sensing assets are scarce and in high demand. - Highly dynamic (sensing asset failures, change of plan)
  14. 14. Subproblems• We identify 3 subproblems to solve the SENSOR-MISSION ASSIGNMENT:
  15. 15. Subproblems• We identify 3 subproblems to solve the SENSOR-MISSION ASSIGNMENT:1. SENSOR-TASK FITTING Tasks have different information requirements: we need to figure out which types of sensing assets are suitable.
  16. 16. Subproblems• We identify 3 subproblems to solve the SENSOR-MISSION ASSIGNMENT:1. SENSOR-TASK FITTING Tasks have different information requirements: we need to figure out which types of sensing assets are suitable.2. SENSOR-TASK ALLOCATION Tasks may compete for the exclusive usage of a sensing asset: we need a scheme to assign individual assets to tasks.
  17. 17. Subproblems• We identify 3 subproblems to solve the SENSOR-MISSION ASSIGNMENT:1. SENSOR-TASK FITTING Tasks have different information requirements: we need to figure out which types of sensing assets are suitable.2. SENSOR-TASK ALLOCATION Tasks may compete for the exclusive usage of a sensing asset: we need a scheme to assign individual assets to tasks.3. SENSOR DEPLOYMENT & DELIVERY Sensing assets must be dynamically configured and deployed, ensuring the right information is efficiently delivered to the user: we need a sensor infrastructure to mediate with physical-world sensors.
  18. 18. Conceptual architecture• A Semantic Web approach: The Core is a set of interlinked ontologies describing Missions/Tasks and Sensors/Platforms (building on pre-existing ontologies and schemas wherever possible). Day & night video surveillance Locate snipers ISR assets available in the wood Assets - Type Logistics - Location - Status Fitting Planning Requirements Reasoner Update status - Capabilities - QoI Ranking feasible - Environment solutions Allocation Monitoring algorithms Near-optimal Deployment allocation Dynamic events S1 Deployment D B & Tasking A S2 S4 E Sensor S3 Infrastructure C ("Fabric")
  19. 19. Conceptual architecture • A Semantic Web approach: The Core is a set of interlinked ontologies describing Missions/Tasks and Sensors/Platforms (building on pre-existing ontologies and schemas wherever possible). Day & night video surveillance Locate snipers ISR assets available in the wood Assets - Type Logistics - Location - StatusSENSOR-TASK FITTING Fitting Planning Requirements Reasoner Update status - Capabilities - QoI Ranking feasible - Environment solutions Allocation Monitoring algorithms Near-optimal Deployment allocation Dynamic events S1 Deployment D B & Tasking A S2 S4 E Sensor S3 Infrastructure C ("Fabric")
  20. 20. Conceptual architecture • A Semantic Web approach: The Core is a set of interlinked ontologies describing Missions/Tasks and Sensors/Platforms (building on pre-existing ontologies and schemas wherever possible). Day & night video surveillance Locate snipers ISR assets available in the wood Assets - Type Logistics - Location - StatusSENSOR-TASK FITTING Fitting Planning Requirements Reasoner Update status - Capabilities - QoI Ranking feasible - Environment solutions Allocation MonitoringSENSOR-TASK algorithmsALLOCATION Near-optimal Deployment allocation Dynamic events S1 Deployment D B & Tasking A S2 S4 E Sensor S3 Infrastructure C ("Fabric")
  21. 21. Conceptual architecture • A Semantic Web approach: The Core is a set of interlinked ontologies describing Missions/Tasks and Sensors/Platforms (building on pre-existing ontologies and schemas wherever possible). Day & night video surveillance Locate snipers ISR assets available in the wood Assets - Type Logistics - Location - StatusSENSOR-TASK FITTING Fitting Planning Requirements Reasoner Update status - Capabilities - QoI Ranking feasible - Environment solutions Allocation MonitoringSENSOR-TASK algorithmsALLOCATION Near-optimal Deployment allocation Dynamic events S1 Deployment D B & Tasking A S2 S4 SENSOR E Sensor S3DEPLOYMENT Infrastructure CAND DELIVERY ("Fabric")
  22. 22. Conceptual architecture • A Semantic Web approach: The Core is a set of interlinked ontologies describing Missions/Tasks and Sensors/Platforms (building on pre-existing ontologies and schemas wherever possible). Day & night video surveillance Locate snipers ISR assets available in the wood Assets - Type Logistics - Location - StatusSENSOR-TASK FITTING Fitting Planning Requirements Reasoner Update status - Capabilities - QoI Ranking feasible - Environment solutions Allocation MonitoringSENSOR-TASK algorithmsALLOCATION Near-optimal Deployment allocation Dynamic events S1 Deployment D B & Tasking A S2 S4 SENSOR E Sensor S3DEPLOYMENT Infrastructure CAND DELIVERY ("Fabric")
  23. 23. Sensor-Task Fittingdecides which collections of asset types fit the information requirements of each task.SENSING ASSET TYPES TASK Area video Surveillance (possible threats)
  24. 24. Sensor-Task Fittingdecides which collections of asset types fit the information requirements of each task.SENSING ASSET TYPES TASK Area video Surveillance (possible threats)
  25. 25. Methodology• Semantic matchmaking to evaluate the fitness-for-purpose of collections of asset types to the information requirements of a task. Sensor-task fitting
  26. 26. Methodology• Semantic matchmaking to evaluate the fitness-for-purpose of collections of asset types to the information requirements of a task.• We use ontologies for: Sensor-task fitting
  27. 27. Methodology• Semantic matchmaking to evaluate the fitness-for-purpose of collections of asset types to the information requirements of a task.• We use ontologies for: Sensor-task fitting Specify the information requirements of a task. ISR ontologies: tasks, sensors, etc Specify the sensing capabilities provided by assets.
  28. 28. Methodology• Semantic matchmaking to evaluate the fitness-for-purpose of collections of asset types to the information requirements of a task.• We use ontologies for: Compare the two of them. Sensor-task fitting Specify the information MMF ontology requirements of a task. ISR ontologies: tasks, sensors, etc Specify the sensing capabilities provided by assets.
  29. 29. Methodology• Semantic matchmaking to evaluate the fitness-for-purpose of collections of asset types to the information requirements of a task.• We use ontologies for: Compare the two of them. Sensor-task fitting Specify the information MMF ontology requirements of a task. ISR ontologies: tasks, sensors, etc Specify the sensing capabilities provided by assets.
  30. 30. MMF ontology• Based on the pre-existent Missions and Means Framework (MMF) ‣ MMF is an informal framework to help human planners determine the capabilities required to accomplish a military mission. (developed by US ARL)
  31. 31. MMF ontology• Based on the pre-existent Missions and Means Framework (MMF) ‣ MMF is an informal framework to help human planners determine the capabilities required to accomplish a military mission. (developed by US ARL) Expert’sknowledge
  32. 32. MMF ontology• Based on the pre-existent Missions and Means Framework (MMF) ‣ MMF is an informal framework to help human planners determine the capabilities required to accomplish a military mission. (developed by US ARL) Mission Expert’sknowledge
  33. 33. MMF ontology• Based on the pre-existent Missions and Means Framework (MMF) ‣ MMF is an informal framework to help human planners determine the capabilities required to accomplish a military mission. (developed by US ARL) Mission Expert’s Operationknowledge Operation
  34. 34. MMF ontology• Based on the pre-existent Missions and Means Framework (MMF) ‣ MMF is an informal framework to help human planners determine the capabilities required to accomplish a military mission. (developed by US ARL) Mission Expert’s Operationknowledge Operation Task Task
  35. 35. MMF ontology• Based on the pre-existent Missions and Means Framework (MMF) ‣ MMF is an informal framework to help human planners determine the capabilities required to accomplish a military mission. (developed by US ARL) Component Mission Component Expert’s Operationknowledge Operation Task Task
  36. 36. MMF ontology• Based on the pre-existent Missions and Means Framework (MMF) ‣ MMF is an informal framework to help human planners determine the capabilities required to accomplish a military mission. (developed by US ARL) Component Mission Component System Expert’s System Operationknowledge Operation Task Task
  37. 37. MMF ontology• Based on the pre-existent Missions and Means Framework (MMF) ‣ MMF is an informal framework to help human planners determine the capabilities required to accomplish a military mission. (developed by US ARL) Component Mission Component System Expert’s System Operationknowledge Operation Platform Task Task
  38. 38. MMF ontology• Based on the pre-existent Missions and Means Framework (MMF) ‣ MMF is an informal framework to help human planners determine the capabilities required to accomplish a military mission. (developed by US ARL) Component Mission Component System Expert’s System Operationknowledge Operation Platform Task Task Capability Capability
  39. 39. MMF ontology• Based on the pre-existent Missions and Means Framework (MMF) ‣ MMF is an informal framework to help human planners determine the capabilities required to accomplish a military mission. (developed by US ARL) Component Mission Component System Expert’s System Operationknowledge Operation Platform Task Task Capability Capability
  40. 40. MMF ontology• Based on the pre-existent Missions and Means Framework (MMF) ‣ MMF is an informal framework to help human planners determine the capabilities required to accomplish a military mission. (developed by US ARL) Component Mission Component System Expert’s System Operationknowledge Operation Platform Capabilities required Task Task Capability Capability
  41. 41. MMF ontology • Based on the pre-existent Missions and Means Framework (MMF) ‣ MMF is an informal framework to help human planners determine the capabilities required to accomplish a military mission. (developed by US ARL) Component Mission Component System Expert’s System Operation knowledge Operation Platform Capabilities required Task Task Capability Capability• In the military domain very precise definitions of capabilities required: • ISR requirements (Intelligence - Surveillance - Reconnaissance)
  42. 42. MMF ontology (contd)• Why develop an MMF ontology? ✓ Formally define relationship: Task’s ISR reqs Sensor/platform’s ISR capabilities. ✓ Directly use it inside the SENSOR-TASK FITTING reasoner.
  43. 43. MMF ontology (contd)• Why develop an MMF ontology? ✓ Formally define relationship: Task’s ISR reqs Sensor/platform’s ISR capabilities. ✓ Directly use it inside the SENSOR-TASK FITTING reasoner.• Main concepts and relations in MMF ontology (implemented in OWL DL): toPerform entails Task requires Capability allocatedTo provides comprises toAccomplish Asset Operation is-a is-a comprises toAccomplish Platform mounts System attachedTo is-a Mission interferesWith Sensor
  44. 44. ISR ontologies Sensor-task fitting MMF ontology ISR ontologies: tasks, sensors, etc• To describe instances of the MMF ontology concepts: we need domain specific ontologies.• Previous attempts to conceptualize ISR domain: mixed dimensions.
  45. 45. ISR ontologies Sensor-task fitting MMF ontology ISR ontologies: tasks, sensors, etc• To describe instances of the MMF ontology concepts: we need domain specific ontologies.• Previous attempts to conceptualize ISR domain: mixed dimensions.
  46. 46. ISR ontologies Sensor-task fitting MMF ontology ISR ontologies: tasks, sensors, etc• To describe instances of the MMF ontology concepts: we need domain specific ontologies.• Previous attempts to conceptualize ISR domain: mixed dimensions.
  47. 47. ISR ontologies Sensor-task fitting MMF ontology ISR ontologies: tasks, sensors, etc• To describe instances of the MMF ontology concepts: we need domain specific ontologies.• Previous attempts to conceptualize ISR domain: mixed dimensions. Example: UAV (Unmanned Aerial Vehicle) classification mixes - size (Micro vs Mini) - performance (Medium altitude vs High altitude) - task type (Maritime reconnaissance, Wide area surveillance, ...)
  48. 48. ISR ontologies (contd)• We use OWL DL to conceptualize the ISR domain based on pre-existent ontologies and schemas: ‣ Define new concepts by specifying property restrictions and relations on existing concepts: – Aircraft ≡ (Platform ∃ hasRealm.Atmosphere) – UnmannedVehicle ≡ (Platform ∃ hasQuality.Without-crew-mobility) – UAV ≡ (Aircraft UnmannedVehicle)
  49. 49. nnedVehicle ≡ (Platform ∃ hasQuality.Without-crew-mobility) – UAV ≡ (Aircraft UnmannedVehicle)≡ (Aircraft UnmannedVehicle) ISR ontologies (contd) atUAV ≡ (UAV ∃ providesCapability.Firepower) ≡ (UAV ∃ providesCapability.MediumAltitude ∃ providesCapabil- – CombatUAV ≡ (UAV ∃ providesCapabil – MALE ≡ (UAV ∃ providesCapability.Med ity.LongEndurance) • gEndurance) OWL DL to conceptualize the ISR domain based We use anceUAV ¬ (SmallUAV TacticalUAV). – EnduranceUAV ¬ (SmallUAV Tactica on pre-existent ontologies and schemas: By using OWL DL, we can apply off-the-self g OWL DL, we can apply off-the-self reasoners to infer new classifications based on concept definitions, which is very approp ‣oncept definitions, which new concepts bybecause different classifications Define is very appropriate specifying property restrictions are useful for different purposes. For example at s and relations on existing concepts: or different purposes. For example at some point one might be interested in selecting a platform in terms of the type of tasks platform in terms of the type of tasks that it can perform (reconnaissance, surveillance, battle damage assessment, etc), but – Aircraft ≡ (Platform ∃ hasRealm.Atmosphere) selecting a platform according to its te, battle damage assessment, etc), but in other circumstances one might be interested inn selecting a platform according to its takeoff and landing capabilities (cata- ∃ hasQuality.Without-crew-mobility) these dimens – UnmannedVehicle ≡ (Platform pult, runaway, VTOL, etc). Some of ay, VTOL, etc). Some of these dimensions are: – UAV ≡ (Aircraft UnmannedVehicle) – For platforms: mobility, realm, performanceatforms: mobility, realm, performance (range, endurance, altitude, speed, etc.), application or mission type (surveillanc pplication or mission type (surveillance, reconnaissance, target acquisition, etc.), firepower, landing and takeoff, commun • repower,A reasonertakeoff, communications, vulnerability and survivabil- with multi-dimensions): ilability. landing and can infer different classifications (to deal ity, availability. – For sensors: phenomena detected (type and Select platformnsors: phenomena detected (type and spectrum), performance (resolution, rate, etc), weather/terrain/contamination influence, vulnerability, interfer- sample rate, etc), weather/terrain/contaminatwith other sensors. using task type ences with other sensors. using platform features atforms (b) Sensors (c) ISR tasks (d) Intelligence (a) Platforms (b) Sensors
  50. 50. Sensor-Task Fitting Sensor-task fitting MMF ontology ISR ontologies: tasks, sensors, etc
  51. 51. Sensor-Task Fitting Sensor-task fitting MMF ontology ISR ontologies: tasks, sensors, etc• Given a task T, with a set of ISR requirements: RT = {R1, R2, ...}
  52. 52. Sensor-Task Fitting Sensor-task fitting MMF ontology ISR ontologies: tasks, sensors, etc• Given a task T, with a set of ISR requirements: RT = {R1, R2, ...}• A valid solution is - a (PC) Platform Configuration = (P , S) where P is a single platform type , S = {S1, ... , Sm} is a set of sensor types mountable on P (at the same time). - The aggregate capabilities of a PC have to semantically match RT
  53. 53. Sensor-Task Fitting Sensor-task fitting MMF ontology ISR ontologies: tasks, sensors, etc• Given a task T, with a set of ISR requirements: RT = {R1, R2, ...}• A valid solution is - a (PC) Platform Configuration = (P , S) where P is a single platform type , S = {S1, ... , Sm} is a set of sensor types mountable on P (at the same time). - The aggregate capabilities of a PC have to semantically match RT• There can be more than one valid solution: - Set of valid solutions = { PC1 , PC2 , ... }
  54. 54. Sensor-Task Fitting (contd)• Three interlinked semantic matching relations: Task Platform Sensor
  55. 55. Sensor-Task Fitting (contd)• Three interlinked semantic matching relations: Task Platform match(T,S) Sensor
  56. 56. Sensor-Task Fitting (contd)• Three interlinked semantic matching relations: Task match(T,P) Platform match(T,S) Sensor
  57. 57. Sensor-Task Fitting (contd)• Three interlinked semantic matching relations: Task match(T,P) Platform match(T,S) match(P,S) Sensor
  58. 58. Sensor-Task Fitting (contd)• Three interlinked semantic matching relations: Task match(T,P) Platform Ontologies match(T,S) match(P,S) Sensor
  59. 59. Sensor-Task Fitting (contd)• Three interlinked semantic matching relations: Task match(T,P) Platform Ontologies match(T,S) match(P,S) Sensor • All matching relations have to be satisfied for a valid solution.
  60. 60. Day & night video surveillance Locate snipers ISR assets available in the wood Assets - Type Logistics - Location - StatusSENSOR-TASK FITTING Fitting Planning Requirements Reasoner Update status - Capabilities - QoI Ranking feasible - Environment solutions Allocation MonitoringSENSOR-TASK algorithmsALLOCATION Near-optimal Deployment allocation Dynamic events S1 Deployment D B & Tasking A S2 S4 SENSOR E Sensor S3DEPLOYMENT Infrastructure CAND DELIVERY ("Fabric")
  61. 61. Day & night video surveillance Locate snipers ISR assets available in the wood Assets - Type Logistics - Location - StatusSENSOR-TASK FITTING Fitting Planning Requirements Reasoner Update status - Capabilities - QoI Ranking feasible - Environment solutions Allocation MonitoringSENSOR-TASK algorithmsALLOCATION Near-optimal Deployment allocation Dynamic events S1 Deployment D B & Tasking A S2 S4 SENSOR E Sensor S3DEPLOYMENT Infrastructure CAND DELIVERY ("Fabric")
  62. 62. Sensor-Task Allocation assign individual asset instances to competing tasks. X Task 2 X Task 1 X Task 3
  63. 63. Sensor-Task Allocation assign individual asset instances to competing tasks. X Task 2 X Task 1 X Task 3
  64. 64. Allocation model• This allocation problem can be represented as a bipartite graph: Assets ‣ Vertex sets: A1 Tasks Assets {Ai}, Task {Tj} e11 e1 T1 2 (d1, p1) ‣ For each task (Tj): A2 dj = utility demand pj = profit A3 T2 (d2, p2) ‣ For each asset-task pair: eij = utility that Ai could contribute to Tj A4• Goal: an allocation of asset that maximizes the total profit of the satisfied tasks. of the satisfied tasks, where• A task is satisfied when: (Ai ,Tj )∈F eij ≥ dj• This is an NP-Complete problem!• We developed centralized and distributed algorithms to find an approximate solution.
  65. 65. Quantitative Vs Qualitative• It needs a numerical utility for each (task, asset).• Usually utility value includes only QUANTITATIVE measures of sensing capabilities. • Example: Utility is a function of the distance Dij between assset and task   1 2 if Dij ≤ SR 1+Dij /c eij =  0 otherwise• In our approach we include also QUALITATIVE measures of capabilities: eij = 0 if there is no match between RT and CA• Two results: • Reduce the solution search space (and therefore the complexity). • Better solution quality.
  66. 66. More flexibility• Another advantage of using semantic matchmaking: The fitting output is a set of possible asset types which we can use for each task. • If a certain asset type becomes unavailable the task can still be accomplished by usign alternative asset types. X Task 2 X Task 1 X Task 3
  67. 67. More flexibility• Another advantage of using semantic matchmaking: The fitting output is a set of possible asset types which we can use for each task. • If a certain asset type becomes unavailable the task can still be accomplished by usign alternative asset types. X Task 2 X Task 1 X Task 3
  68. 68. More flexibility• Another advantage of using semantic matchmaking: The fitting output is a set of possible asset types which we can use for each task. • If a certain asset type becomes unavailable the task can still be accomplished by usign alternative asset types. X Task 2 X Task 1 X Task 3 ‣ Matches both ISR requirements of Task 3 and of Task 2 ‣ ... but Task 3 is critical
  69. 69. More flexibility• Another advantage of using semantic matchmaking: The fitting output is a set of possible asset types which we can use for each task. • If a certain asset type becomes unavailable the task can still be accomplished by usign alternative asset types. X Task 2 X Task 1 X Task 3 ‣ Matches both ISR requirements of Task 3 and of Task 2 ‣ ... but Task 3 is critical
  70. 70. Day & night video surveillance Locate snipers ISR assets available in the wood Assets - Type Logistics - Location - StatusSENSOR-TASK FITTING Fitting Planning Requirements Reasoner Update status - Capabilities - QoI Ranking feasible - Environment solutions Allocation MonitoringSENSOR-TASK algorithmsALLOCATION Near-optimal Deployment allocation Dynamic events S1 Deployment D B & Tasking A S2 S4 SENSOR E Sensor S3DEPLOYMENT Infrastructure CAND DELIVERY ("Fabric")
  71. 71. Day & night video surveillance Locate snipers ISR assets available in the wood Assets - Type Logistics - Location - StatusSENSOR-TASK FITTING Fitting Planning Requirements Reasoner Update status - Capabilities - QoI Ranking feasible - Environment solutions Allocation MonitoringSENSOR-TASK algorithmsALLOCATION Near-optimal Deployment allocation Dynamic events S1 Deployment D B & Tasking A S2 S4 SENSOR E Sensor S3DEPLOYMENT Infrastructure CAND DELIVERY ("Fabric")
  72. 72. are currently working on the problem of deploying selected sensor instances on thework, so that they operate as a coherent system that can deliver the required infor-ion to users. Our main focus at present is to interface the fitting and allocation com-ents with a particular sensor infrastructure — the Sensor Fabric — a prototype im-mentation of which has been built using commercial off-the-shelf components [14].ile the main aim of the fabric is to research and apply algorithms for the retrieval dissemination of task-specific information across sensor networks, it provides three Sensor deploymentn components that complement the fitting and allocation work previous described: Sensor Catalogue: provides a global inventory/registry of sensor instances, describ- ing all known assets and their availability. It manages the visibility of, and access & delivery to, sensor data feeds. The Sensor Catalogue is used to select the sensors required to fulfill the requirements of a specific task. Topology Manager: manages the network topology and inter-node communication, describing all known network nodes and their availability. The Topology Manager is used for node location and routing information. configuring and deploying sensing assets, Fabric Manager: responsible for the control (configuration and sensor-mission as- signment) and monitoring of individual sensors and intermediate nodes, and es- tablishing the communication channels between them. The Fabric is efficiently delivered ensuring the right information Manager also provides a container for running in-network information the user. to fusion and filtering algo- rithms, and registering them as assets with the Sensor Catalogue. Figure 9 sketches the Sensor Fabrichitecture and the three main services FM FM S1vided: the Sensor Catalogue (SC), the SC TM ology Manager (TM), and the Fab- B E S2Manager (FM). There is one instance S3h of the Sensor Catalogue and Topol- A D Manager per Sensor Fabric, and one S4ance of the Fabric Manager per node. FM C FM F sor nodes publish data locally to a S5 c in a global topic name space, and S6 FMilarly consumers subscribe locally to same global topic name. The Fab-
  73. 73. Sensor fabric• We need a sensor infrastructure: • Mediate between real world assets and fitting/allocation modules • Providing an high level interface to configure and deploy assets & ensure efficient information delivery.• “Sensor Fabric” a prototype implementation: FM FM S1 SC TM B E S2 S3 A D S4 FM C FM F S5 S6 FM
  74. 74. Sensor fabric• We need a sensor infrastructure: • Mediate between real world assets and fitting/allocation modules • Providing an high level interface to configure and deploy assets & ensure efficient information delivery.• “Sensor Fabric” a prototype implementation: • Sensor Catalogue: FM FM S1 - Asset instances and their ISR capabilities. SC TM B E S2 (supporting the SENSOR TASK FITTING) S3 A D S4 FM C FM F S5 S6 FM
  75. 75. Sensor fabric• We need a sensor infrastructure: • Mediate between real world assets and fitting/allocation modules • Providing an high level interface to configure and deploy assets & ensure efficient information delivery.• “Sensor Fabric” a prototype implementation: • Sensor Catalogue: FM FM S1 - Asset instances and their ISR capabilities. SC TM B E S2 (supporting the SENSOR TASK FITTING) S3 A D • S4 Topology Manager: FM C FM F S5 - Network topology. S6 FM
  76. 76. Sensor fabric• We need a sensor infrastructure: • Mediate between real world assets and fitting/allocation modules • Providing an high level interface to configure and deploy assets & ensure efficient information delivery.• “Sensor Fabric” a prototype implementation: • Sensor Catalogue: FM FM S1 - Asset instances and their ISR capabilities. SC TM B E S2 (supporting the SENSOR TASK FITTING) S3 A D • S4 Topology Manager: FM C FM F S5 - Network topology. S6 FM • Fabric Manager: - Allocate asset instances to tasks (SENSOR-TASK ALLOCATION) - Establish communication channel (DELIVERY)
  77. 77. Conclusion & Future part of the computation of a utility value). Then, an interface to the Topology Manager• allows us to specify how a set of selected instances needs to be configured to operate as Evaluation: we have implemented a first prototype of a Top-to-Bottom application a coherent system to deliver data to a user. for Sensor-Mission Assignment.• Positive feedback from US and UK users: ‣ liked the use of MMF and previous ISR ontologies/schemas. ‣ liked the multi-dimensional approach. Fig. 10: Tool for integrating the reasoner and the Sensor Fabric Figure 10 is a screenshot of a software prototype we are developing to enable the integration of the services provided by the reasoner and those provided by the Sensor Fabric. This screenshot shows the main user interface, which enables the specification of tasks, and supports users in the allocation of appropriate assets for their their tasks. Each task is characterised by qualitative requirements used by the reasoner to discover platforms that are fit-for-purpose. In addition, each task can define a geographic area of interest where some information has to be collected. The left part of the interface shows a map provided by Google Map Web services8 , where the user can specify the area of interest (overlapping rectangle) for a particular task. After selecting some requirements for the task, the user can retrieve the assets available that satisfy them, together with information on their availability and geographic location. In addition, the location of the assets is depicted on the map. In the example, we can see that user needs Imagery Intelligence (IMINT), which can be provided by three assets: one UAV of class Predator (P 1) and two UAVs of class PredatorB (P 1 and P 5). In addition, we can see that one of the PredatorB platforms is not available, because it has crashed previously (P 8). Therefore, in this case the user can select either P 1 or P 5 to accomplish the task. Multiple tasks can be defined, and then the assets committed to one task will not be available to other tasks. The next step is to integrate the allocation algorithms so as to maximize the global profit from multiple tasks. 6 Discussion and Conclusion
  78. 78. Conclusion & Future part of the computation of a utility value). Then, an interface to the Topology Manager• allows us to specify how a set of selected instances needs to be configured to operate as Evaluation: we have implemented a first prototype of a Top-to-Bottom application a coherent system to deliver data to a user. for Sensor-Mission Assignment.• Positive feedback from US and UK users: ‣ liked the use of MMF and previous ISR ontologies/schemas. ‣ liked the multi-dimensional approach. Fig. 10: Tool for integrating the reasoner and the Sensor Fabric Figure 10 is a screenshot of a software prototype we are developing to enable the• integration of the services provided by the reasoner and those provided by the Sensor MAIN MESSAGE: Fabric. This screenshot shows the main user interface, which enables the specification of tasks, and supports users in the allocation of appropriate assets for their their tasks. The Ontology centric approach is crucial Each task is characterised by qualitative requirements used by the reasoner to discover platforms that are fit-for-purpose. In addition, each task can define a geographic area of interest where some information has to be collected. The left part of the interface shows - to cope with the heterogeneity of the sensor network and of tasks, a map provided by Google Map Web services8 , where the user can specify the area of interest (overlapping rectangle) for a particular task. After selecting some requirements - to provide flexibility. for the task, the user can retrieve the assets available that satisfy them, together with information on their availability and geographic location. In addition, the location of the assets is depicted on the map. In the example, we can see that user needs Imagery Intelligence (IMINT), which can be provided by three assets: one UAV of class Predator (P 1) and two UAVs of class PredatorB (P 1 and P 5). In addition, we can see that one of the PredatorB platforms is not available, because it has crashed previously (P 8). Therefore, in this case the user can select either P 1 or P 5 to accomplish the task. Multiple tasks can be defined, and then the assets committed to one task will not be available to other tasks. The next step is to integrate the allocation algorithms so as to maximize the global profit from multiple tasks. 6 Discussion and Conclusion
  79. 79. Conclusion & Future part of the computation of a utility value). Then, an interface to the Topology Manager• allows us to specify how a set of selected instances needs to be configured to operate as Evaluation: we have implemented a first prototype of a Top-to-Bottom application a coherent system to deliver data to a user. for Sensor-Mission Assignment.• Positive feedback from US and UK users: ‣ liked the use of MMF and previous ISR ontologies/schemas. ‣ liked the multi-dimensional approach. Fig. 10: Tool for integrating the reasoner and the Sensor Fabric Figure 10 is a screenshot of a software prototype we are developing to enable the• integration of the services provided by the reasoner and those provided by the Sensor MAIN MESSAGE: Fabric. This screenshot shows the main user interface, which enables the specification of tasks, and supports users in the allocation of appropriate assets for their their tasks. The Ontology centric approach is crucial Each task is characterised by qualitative requirements used by the reasoner to discover platforms that are fit-for-purpose. In addition, each task can define a geographic area of interest where some information has to be collected. The left part of the interface shows - to cope with the heterogeneity of the sensor network and of tasks, a map provided by Google Map Web services8 , where the user can specify the area of interest (overlapping rectangle) for a particular task. After selecting some requirements - to provide flexibility. for the task, the user can retrieve the assets available that satisfy them, together with information on their availability and geographic location. In addition, the location of the assets is depicted on the map. In the example, we can see that user needs Imagery Intelligence (IMINT), which can be provided by three assets: one UAV of class Predator• Future: (P 1) and two UAVs of class PredatorB (P 1 and P 5). In addition, we can see that one of the PredatorB platforms is not available, because it has crashed previously (P 8). Therefore, in this case the user can select either P 1 or P 5 to accomplish the task. • Continue to develop each module and Multiple tasks can be defined, and then the assets committed to one task will not be available to other tasks. The next step is to integrate the allocation algorithms so as to • maximize the global profit from multiple tasks. to study interactions between them. 6 Discussion and Conclusion
  80. 80. Thanks for listening

×