1 / 18

A System Architecture for Exploiting Mission Information Requirement and Resource Allocation

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

hue
Download Presentation

A System Architecture for Exploiting Mission Information Requirement and Resource Allocation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. A System Architecture for Exploiting Mission Information Requirement and Resource Allocation Fangfei Chena, Thomas La Portaa, Diego Pizzocarob, AlunPreeceband Mani B. Srivastavac aDept. of Computer Science and Engineering, The Penn State University, USA bSchool of Computer Science and Informatics, Cardiff University, UK cElectrical Engineering Department, University of California Los Angeles, USA

  2. Motivation • Previous work: SensorAssignment to Missions (SAM), tasking in terms of whatrather 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 • Commanders send requests to a knowledge base describing the mission • Knowledge base matches mission with existing task-transition graph • 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 • Tasks of a mission are analysed by SAMreasoner, and resource requirements per task are derived • This process results in a Resource Matching Graph

  9. Resource Matching Graph • Identifies mission resource requirements

  10. Information Flow in the System • 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 • Decision on which mission is admitted is sent back to the commander • 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 pj • A set R resources, each with capacity ci • Mj requires Dij(random variable) of resource Ri • xj=1 if Mj 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 Camera3all the time • If each mission uses Camera3for 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

More Related