1. A System Architecture for Exploiting Mission Information Requirement and Resource Allocation Fangfei Chen a, Thomas La Porta a, Diego Pizzocaro b, Alun Preece b and Mani B. Srivastava c a Dept. of Computer Science and Engineering, The Penn State University, USA b School of Computer Science and Informatics, Cardiff University, UK c Electrical Engineering Department, University of California Los Angeles, USA

2. Motivation Previous work: Sensor Assignment to Missions (SAM), tasking in terms of what rather than how, data dissemination Need a complete system to support (ISR) decision-making “Decision-to-data” coverage, from describing the commander’s intent to resource allocation and mission admission control

3. Concepts and Definitions A mission is a collection of tasks with temporal and causal relations Resources can be sensors, vehicles, bandwidth, with limited capacities Each task requires multiple resources A mission is admitted when all resource requirements of its tasks are satisfied

4. Basic Idea: Feedback Loop Commanders submit requests to the system Mission resource requirements are analyzed Admission decision is sent back to commanders If satisfactory, mission gets executed; otherwise, requests are revised and resubmitted

5. System Architecture

6. Information Flow in the System 1.Commanders send requests to a knowledge base describing the mission 2.Knowledge base matches mission with existing task-transition graph 3.The task transition graph is confirmed or adjusted by an analyst

7. Task Transition Graph Identifies task relations of a mission

8. Information Flow in the System 4.Tasks of a mission are analysed by SAM reasoner, and resource requirements per task are derived 5.This process results in a Resource Matching Graph

9. Resource Matching Graph Identifies mission resource requirements

10. Information Flow in the System 6.A resource inventory (with resource capacity), together with the task transition graph and mission resource matching graph are sent as input to a resource allocation problem solver 7.Decision on which mission is admitted is sent back to the commander 8.If decision is satisfactory, missions get executed; otherwise, adjusted requests are sent to the knowledge base again

11. Resource Allocation Problem A set M of m missions, each with a profit p j A set R resources, each with capacity c i M j requires D ij (random variable) of resource R i x j =1 if M j is admitted

12. Resource Allocation Problem An allowable over flow probability ρ In the form of a chance-constrained program Proposed detailed solution in DCOSS’12

13. System Architecture

14. An Example Scenario “Track any high value target on Vertical/Horizontal Rd”

15. Scenario —Task Transition Graph Two missions are of the same type.

16. Scenario—Mission Matching Graph

17. Scenario—Resource Allocation For this particular problem, the only resource that two missions compete for is Camera3 One mission does not necessarily occupy Camera3 all the time If each mission uses Camera3 for only a fraction of the time, these two missions may be both admitted with only a small chance of conflict

18. Conclusion We designed a system architecture for exploiting mission resource requirement and assisting mission admission control The system forms an information loop starting from requests by commanders, from which the system determines task relation & mission matching graphs, and then sends these as input to a resource allocation problem solver Decision from the solver is sent back to the commander Negative results leads to new requests to the system The loop converges when the resource utilization is maximized