A System Architecture for Exploiting Mission Information Requirement and

Resource AllocationFangfei Chena, Thomas La Portaa, Diego Pizzocarob,

Alun Preeceb and Mani B. Srivastavac

aDept. of Computer Science and Engineering, The Penn State University, USA

bSchool of Computer Science and Informatics, Cardiff University, UKcElectrical Engineering Department, University of California Los

Angeles, USA

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

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

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

System Architecture

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

Task Transition Graph• Identifies task relations of a mission

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

Resource Matching Graph• Identifies mission resource requirements

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

Resource Allocation Problem

• A set M of m missions, each with a profit pj

• A set R resources, each with capacity ci

• Mj requires Dij (random variable) of resource Ri

• xj =1 if Mj is admitted

Resource Allocation Problem

• An allowable over flow probability ρ• In the form of a chance-constrained

program• Proposed detailed solution in DCOSS’12

System Architecture

An Example Scenario

“Track any high value target on Vertical/Horizontal Rd”

Scenario —Task Transition Graph

• Two missions are of the same type.

Scenario—Mission Matching Graph

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

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