Theater Tactical Air Warfare Methodologies:

Automated Scenario Generation

 

 

 

Final Report

Contract No. F33657-88-C-2156

 

 

 

July 21, 1989

 

 

 

 

 

 

 

 

 

Prepared by:

Dr. J. George Caldwell

Vista Research Corporation

3826 Snead Drive

Sierra Vista, AZ 85635

Tel: (602)378-2130

 

 

Submitted to:

USAF Air Force Systems Command (AFSC)

Aeronautical System Division (ASD)

SD/XRX

Attn: Lt. Tom Wong

Wright-Patterson Air Force Base, OH 45433-6503

Tel: (513)255-5035

 

Copyright (C) 1989 Vista Research Corporation

 


 

Contents

Foreword. 3

Executive Summary. 4

List of Acronyms and Abbreviations. 6

List of Symbols. 8

I. Introduction and Summary. 10

II. Background of the Problem.. 21

III. Phase I Activities and Results. 25

IV. Recommendations for Phase II 39

Appendix A. References. 40

Appendix B. List of Contacts Made During Course of Project 41

Appendix C. Analytical and Conceptual Frameworks for Automated Scenario Generation. 44

Appendix D. Definitions and Concepts in Tactical Air Warfare. 52

Appendix E. Scenario Generation System Preliminary Top-Level Design. 60

Appendix F. Optimal Attack and Defense for a Number of Targets in the Case of Imperfect Interceptors. 73

Appendix G. Mission Planning Model 37

Appendix H. Phase II Work Plan. 59

Appendix I. Statement of Work for Short Takeoff / Vertical Landing (STOVL) Aircraft Evaluation. 73

 


Foreword

 

This report was prepared by the staff of Vista Research Corporation, under Contract No. F33657-88-C-2156 to the United States Air Force (USAF) Air Force Systems Command (AFSC), Aeronautical Systems Division (ASD).  Project staff included Dr. J. George Caldwell (Principal Investigator), Dr. William O. Rasmussen, Dr. Martin A. Diamond, Mr. R. Craig Vulkoff, and Mr. Christopher Caldwell.  Government monitoring of the project was provided by Lt. Tom Wong.

 


Executive Summary

 

This report documents a study of the feasibility of developing an automated scenario generation system.  Scenarios are used in military systems analysis as contexts in which to conduct system test and evaluation.  The scenario specifies the magnitudes and nature of the opposing forces and targets prior to battle, and a battle plan.

 

There are several problems associated with current manual methods for scenario generation, which are slow and costly.  First, there is in general no well-defined conceptual framework associated with the manual methods.  It is generally not possible to describe the procedure in terms of a well-defined scenario population and a probability of selection of scenarios from that population.  In this situation, it is not possible to legitimately use the methods of statistical analysis to make inferences about the system performance in a larger population of scenarios, other than the particular one or ones used in the analysis.  Hence, the scope of inference of the evaluations is very restricted.

 

A second problem associated with manual methods is that, because of the large amount of effort required to produce the scenario, the number of scenarios used in the analysis is very small -- often just one!  If a small number of scenarios is used, the precision of the performance estimates based on this small sample of scenarios is low.  If a single scenario is used, the precision estimates (e.g., standard errors, confidence intervals) derived from the scenario are conditional on the single scenario used, and they should not be represented as precision estimates over a larger population of scenarios.  These precision estimates reflect the "within-scenario" component of variation, but they do not reflect the "among-scenario" component of variation. 

 

A third problem associated with manual scenario generation methods is cost.  The manual approach involves input from many military analysts, and the total cost of producing even a single scenario is very great.  The availability of an automated scenario generation methodology would reduce the cost of test and evaluation.

 

The study documented by this report is a Phase I study conducted under the Small Business Innovation Research (SBIR) Program.  The primary purpose of a Phase I SBIR study is to assess the feasibility of a proposed concept.  The feasibility of developing an automated scenario generation system has been established in this study by the demonstration of a prototype automated scenario generation system.

 

In the present study, the problem of generating a scenario has been divided into two phases: (1) specification of the scenario initial conditions (magnitude and nature of the opposing forces, targets, and combat goals); and (2) specification of a battle plan, given the scenario initial conditions.  The prototype system developed in this study generates battle plans, in the context of tactical air warfare.  That is, it generates samples of aircraft missions, given the number of aircraft to be allocated by the attacker, the number of interceptors to be allocated by the defender, and a list of targets identified by their values and vulnerabilities.

 

The design of the prototype scenario generation system is based on a mathematical representation of combat as a two-sided resource-constrained optimization problem, or sequential-move game.  This mathematical model is used to determine a set of optimal strategies for combat.  A probability sample of battle plans (i.e., aircraft missions) is generated simply by selecting probability samples from the set of optimal strategies.

 

The feasibility of developing an automated scenario generation system has been demonstrated by developing a prototype model that can produce probability samples of battle plans.  The report outlines a Phase II work plan for extending the research to include automatic generation of scenario initial conditions, and extension of the battle-plan (mission) generator to include multiple weapon and interceptor types and additional defense firing doctrines (e.g., subtractive overlapping-island defense).

 

The Air Force Systems Command has an upcoming system evaluation that could benefit from the availability of an automated scenario generation system, namely, the evaluation of the short takeoff/vertical landing (STOVL) aircraft.  The Statement of Work for this evaluation calls for the evaluation of the STOVL and other aircraft in a variety of scenarios and missions.  The automated scenario generation system proposed to be developed in Phase II could support this upcoming system evaluation.

 

In addition to Air Force applications, the problem of generating scenarios occurs in all branches of the armed forces, in a wide variety of applications.  In addition to applications concerned with weapon system evaluation, other examples of applications requiring scenario samples include evaluation of reconnaissance systems, training of intelligence officers, and test and evaluation of command, control, communications and intelligence systems.


List of Acronyms and Abbreviations

 

ACDA             Arms Control and Disarmament Agency

Ada                 high-order programming language

AFM                Air Force Manual

AFSC              Air Force Systems Command

AI                    artificial intelligence, air interdiction

ALO                Air Liaison Officer

AMTAF          All Mobile Tactical Air Forces, model developed

                        by VERAC, Inc. (now Ball Systems Engineering

                        Division)

ASD                Aeronautical System Division

ASE                 Advanced Sensor Exploitation

BAI                 battlefield air interdiction

C                     C high-order programming language

C3                   command, control, and communications

CAS                close air support

CE                   communications-electronics

CCD                camouflage, concealment and deception

CDR                Critical Design Review

CTOL              conventional takeoff and landing

CTS                 Communications Threat Simulator

DASC              Direct Air Support Center

DARPA           Defense Advanced Research Projects Agency

DCA                defensive counter air

DGTS              Dynamic Ground Target Simulator

DOD                Department of Defense

EMETF           Electromagnetic Environmental Test Facility

EPG                 USAEPG, US Army Electronic Proving Ground

FAC                Forward Air Controller

FORTRAN      high-order programming language

GLM               Generalized Lagrange Multiplier

HPTE              high performance turbine engine

IR                    infrared

ITES/TEC       Intelligence Training Evaluation System /

                        Training Evaluation Complex

JESS                Joint Exercise Support System

JOC                 Joint Operations Center

JPL                  Jet Propulsion Laboratory

JTLS               Joint Theater-Level Simulation

KEE                simulation software system

LCC                life cycle cost

LLNL              Lawrence Livermore National Laboratory

MPM               Mission Planning Model

NCTS              Noncommunications Threat Simulator

OCA                offensive counter air

OPTIMA         name of a computer program used to compute optimal

                        attack and defense of targets with imperfect

                        interceptors

PDR                Preliminary Design Review

RADC             Rome Air Development Center

RAMP             RAND Analytic Modeling Platform

RCC                radar cross section

RSAC              RAND Strategy Assessment Center

RSAS              RAND Strategy Assessment System

SAM                surface-to-air missile

SBIR               Small Business Innovation Research

SCORES         Scenario-Oriented Recurrent Evaluation System

                        (former name for TRAC Standard Scenarios)

SD                   satellite dispersal

SDD                Software Design Document

SLF                 Stress Loading Facility

SPM                Software Programmer's Manual

SRR                 System Requirements Review

SRS                 Software Requirements Specification

STP                 Software Test Plan

SUM                Software User's Manual

STOL              short takeoff and landing

STOVL           short takeoff/vertical landing

TACC             Tactical Air Control Center

TACP              Tactical Air Control Party

TRAC             TRADOC Analysis Command

TRADOC        US Army Training and Doctrine Command

UNIX              proprietary computer operating system

USAEPG         US Army Electronic Proving Ground

USAF              United States Air Force

USAICS          US Army Intelligence Center and School

V/STOL          vertical/short takeoff and landing

 


List of Symbols

 

ai                      parameter defined by the equation

                                    exp(-ai) = (1 - K)exp(-bi) + K

bi                     exponential damage function parameter for the

                        i-th target

H(X<Y)           payoff (total target damage) corresponding to

                        the optimal allocation of X weapons and Y

                        interceptors to a set of targets

H(x,y)  payoff corresponding to the weapon allocation x by

                        the attacker and interceptor allocation y by

                        the defender

Hi(xi,yi) payoff (damage) at the i-th target, corresponding

                        to the allocation of xi weapons and yi interceptors

                        to the target

K                     single-weapon kill probability

L                      attacker's Lagrange multiplier

M                     defender's Lagrange multiplier

min                  minimum

max                 maximum

S(i:1,t) summation using the index i, over the range

                        from 1 to t

x                      number of weapons

x*                    optimal weapon level

xi                     number of weapons allocated to the i-th target

X                     weapon stockpile size (total number of weapons

                        to be allocated by attacker)

Xmax(Y)           highest weapon stockpile on linear region of

                        optimal payoff function curve, when total

                        interceptor stockpile is Y

Xmin(Y)            lowest weapon stockpile on linear region of

                        optimal payoff function curve, when total

                        interceptor stockpile is Y

x                      x = (x1,x2,...,xt) = vector whose i-th component

                        is xi, the number of weapons allocated to the

                        i-th target

y                      number of interceptors

y*                    optimal interceptor level

yi                     number of interceptors allocated to the i-th target

Y                     interceptor stockpile size (total number of

                        interceptors to be allocated by defender)

y                      y = (y1,y2,...,yt) = vector whose i-th component

                        is yi, the number of interceptors allocated to the

                        i-th target


I. Introduction and Summary

 

A. Project Objectives

 

This report documents the results of the project, "Tactical Theater Air Warfare Methodologies: Automated Scenario Generation."  This work was funded under contract number F33657-88-C-2156, awarded by the USAF Air Force Systems Command to Vista Research Corporation.  The goal of the project was to develop methodology for generating scenarios for theater tactical air warfare.

 

The purpose of the methodology is to have available automated procedures for generating samples of scenarios that may be utilized as a basis for conducting planning and evaluation studies.  The advantage of having such automated procedures available is twofold: (1) it reduces the cost of test and evaluation, by providing a rapid means of generating test cases; and (2) it broadens the scope of inference of test and evaluation, by enabling test and evaluation of systems and concepts to be conducted in a wider range of situations than is possible using manual methods for situation specification.

 

Although the methodology being developed under this project is oriented specifically to theater tactical air warfare, it will have wide applicability to a wide range of military applications, including Air Force, Army, Navy applications at the strategic, operational, and tactical levels of combat.  In addition to supporting evaluation of attack systems, the methodology can support evaluation of reconnaissance systems as well.

 

This work was funded as a Phase I project under the Small Business Innovation Research (SBIR) program.  The goals of a Phase I SBIR project are to establish the scientific and technical feasibility and merit of the proposed research and development effort.  Under a Phase I effort, the contractor can conduct literature surveys to identify related work and establish the need for the proposed concept, develop the proposed concept in further detail, and conduct analyses to establish its feasibility.  The purpose of the Phase I effort is to provide the Government with a sound basis for deciding whether to fund the further development of the proposed concept under a Phase II SBIR contract.

 

Based on the requirements analysis conducted during this project, an immediate ASD requirement that could benefit from the proposed research is the generation of "cases" for analysis of the performance of the Short Take-Off / Vertical Landing (STOVL) aircraft.  A "case" consists of an aircraft option (single aircraft type or force mix of different aircraft types) applied to an operational environment option (scenario, mission concept, basing concept, and logistic support concept).

 

A specific area in which the proposed research could assist evaluation of the STOVL is in the generation of cases, in which the performance of STOVL could be compared to that of both conventional takeoff and landing (CTOL) and short takeoff and landing (STOL) aircraft.  With an eye to this possible application, the prototype demonstration model developed in this Phase I study was oriented to the development of methodology for selection of alternative samples of targets in tactical air warfare operations, i.e., the prototype model is a theater tactical air warfare mission planning model.

 

Terminology.  In this report, the term "scenario" is used to refer to a specification of the initial conditions of forces and targets prior to a battle, and a battle plan.  The term "initial conditions" refers to the number and characteristics (values, vulnerabilities) of the targets, the number of force elements (weapons and nonweapons) of each type possessed by the two sides, and the combat goals.  The term "battle plan" refers to the intended allocation of offensive and defensive weapons against targets.  The exact definition of the term "weapon" depends on the application and the degree of resolution of the analysis; for example, in tactical theater air warfare applications the term "weapon" could refer to an aircraft.

 

The proposed concept being addressed in this study is to develop methodology for automated generation of "scenarios, strategies, tactics, and plans."  These terms are defined as follows.  To reiterate, a "scenario" is defined by a set of initial conditions that specify the force levels, targets, and combat goals prior to a battle, and a battle plan.  The terms "strategy" and "tactic" refer to probability distributions defined over sets of military decisions or actions.  A particular battle plan is determined by sampling from the strategy or tactic distribution.  The term "scenario" may be used to refer simply to the battle initial conditions and the battle plan, or it may be used more comprehensively to refer to the battle initial conditions, the battle plan, and the strategy and tactics used to generate the plan.

 

Note that in order to generate a scenario, it is necessary to generate strategy and tactics, and to sample a battle plan from the strategy and tactic probability distributions.  Hence, the term "automated scenario generation" implies generation of strategy, tactics, and battle plans (as well as specification of the initial battle conditions).

 

To avoid confusion, it is noted that the military terms "strategy" and "tactic" as used in this report are both "strategies," as that term is used in statistical decision theory (to refer to a probability distribution defined over a set of actions or decisions).  The military term "strategy" refers to a (mathematical) strategy at the "strategic" level, i.e., at the theater echelon level.  The military term "tactic" refers to a (mathematical) strategy at the "tactical" level, i.e., at the division or lower-echelon levels.  Finally, it is noted that the military term, "operational art," refers to the art or science of employing military units at the army or front echelon levels.  In air warfare applications, the term "tactical" refers to air attack operations in close support of friendly ground forces.

   

In this report, the term "scenario" is used in a restricted sense, to refer to a description of the opposing forces and the planned course of action of the two sides (i.e., specification of battle initial conditions and plans).  It is not used in the broad sense, which includes description of the social, political, and economic developments and events leading up to the conflict situation.

 

B. Project Approach

 

The approach to this study consisted of accomplishing the following tasks:

 

            1.         Task 1.  To conduct a review of technology related to the project, for the purpose of avoiding duplication of effort and taking advantage of existing technology.

 

            2.         Task 2.  To conduct a requirements analysis, that is oriented not only to the need for automated scenario generation in general, but oriented to the specific requirements of ASD.

 

            3.         Task 3.  To complete the development of a conceptual and analytical framework for scenario generation, along the lines outlined in the proposal.

 

            4.         Task 4.  To complete the development of a top-level system design.  To make recommendations concerning the tailoring of DOD-STD-2167A (Defense System Software Development Standard, Reference 13) to the Phase II effort.  To make recommendations concerning software development tools to be used in Phase II.  To analyze alternative simulation languages, and recommend one for the Phase II effort.  To analyze process-oriented languages, and to recommend one to supplement the simulation language.  To analyze alternative computer hardware systems, and recommend a system for the Phase II work.  To analyze alternative game-theoretic approaches for generating strategies, and to recommend one for Phase II.

 

            5.         Task 5.  To develop a simplified prototype model that incorporates the concepts identified in the proposal.

 

            6.         Task 6.  To determine the availability of local Department of Defense resources that may be available to support the Phase II effort.

 

            7.         Task 7.  To develop a Phase II work plan.

 

            7.         Task 8.  To prepare a final report.

 

C. Project Activities

 

The methods used to accomplish each of the tasks listed above are described in the paragraphs that follow.

 

Task 1. Review of Technology

The review of technology consisted of a review of literature related to this project, and contact of organizations that were known to be engaged in research or development related to the proposed work (a list of the individuals and organizations contacted during this project is included in Appendix B).  The purpose of these contacts was to identify previous related research (in order to take advantage of previous research findings and to avoid duplication of effort); to identify methodologies (e.g., simulation systems, artificial intelligence methodology, game-theoretic methodology) that could be applied in the current research; and to identify potential applications for automated scenario generation methodology.

 

Under a previous project conducted last year, Vista Research Corporation staff reviewed over 50 documents related to automated scenario generation.  These documents are identified in the bibliography of the final report to that effort (Reference 1; a list of references is presented in Appendix A of that report).  The effort in the present project centered on updating that previous literature search effort.  The major additional documents obtained since the completion of the previous effort were a series of RAND Corporation reports that describe the RAND Strategy Assessment System.

 

Task 2. Requirements Analysis

 

Our proposal presented a rather thorough description of the need for automated scenario generation methodology.  Essentially, an automated scenario generation system is needed to produce scenario samples required to support broad-scope system evaluations. The use of manual scenario generation methods is too costly and slow to produce the large number of scenarios needed, and the lack of a well-defined probabilistic basis of manually generated scenarios precludes the legitimate use of statistical theory to make broad-scope inferences from evaluations based on these scenarios.  A consideration of the general need for an automated scenario generation system leads to basic requirements for a general-purpose scenario generation system.  The basic requirement is that the system be able to generate probability samples of scenarios.

 

In addition to general requirements, it may be desirable to consider requirements associated with specific scenario generation applications anticipated by AFSC.  To this end, Vista staff (Dr. Caldwell and Dr. Rasmussen) visited the Aeronautical Systems Division and met with Lt. Tom Wong and other members of ASD, for the purpose of identifying specific ASD requirements for scenario generation methodology.

 

As a result of this meeting, ASD staff determined that a major potential application for automated scenario generation methodology was the upcoming evaluation of the short takeoff / vertical landing (STOVL) aircraft.  A copy of the Statement of Work for the STOVL evaluation is presented in Appendix I.

 

Task 3. Completion of Development of Conceptual and Analytical Frameworks

 

During this task, the conceptual and analytical frameworks that were described in our proposal were reviewed.  The adequacy of these frameworks, relative to the goal of evaluation of the STOVL was assessed.  Based on a review of the STOVL Statement of Work, no substantive changes are recommended to those proposed frameworks.

 

Task 4. Development of Top-Level System Design

 

A top-level design was developed for an automated scenario generation system.  The top-level design was developed by synthesizing several alternative automated approaches for scenario generation and selecting a preferred alternative.  The selection of the preferred alternative was accomplished by conducting an analysis of the adequacy of each candidate in meeting the proposed system requirements, and assessing the relative cost-effectiveness of the alternatives.

 

The top-level design for the automated scenario generation system involves the use of game-theoretic representation of combat to identify a set of optimal combat strategies.  Probability samples of scenarios are then selected from this set of optimal strategies.

 

The top-level system design was developed by taking into account the general requirements for a scenario generation system.  The top-level design was not specifically tailored to the STOVL evaluation, except for the requirement that the developed general-purpose scenario generation system could readily be extended to support the STOVL application.

 

In addition to the development of a top-level design, our proposal identified several other design issues to be addressed in the Phase I effort (e.g., identification of a simulation language, computer hardware, and game-theoretic approaches).  These design issues were analyzed in the Phase I effort, and recommendations concerning these issues are presented later.  The requirements analysis and design work accomplished in this Phase I effort are preliminary, and subject to revision in Phase II.  The recommendations are relatively well-founded, however, and will be used as a basis for our cost proposal.

 

Task 5. Develop Prototype Model

 

To demonstrate the proposed concepts, a prototype model was developed.  The prototype model is an automated mission planner, that selects samples of targets.  This mission planning model is a mathematical representation of tactical air warfare as a resource-constrained allocation problem in which the defender moves first (i.e., allocates his interceptors first) and the attacker moves last (i.e, allocates his weapons to targets after observing the defender's interceptor allocation).  This model can be used to generate samples of targets (i.e., missions) that reflect a wide range of diversity, within the general framework of tactical air warfare viewed as a resource-constrained allocation problem.

 

Although the prototype model is a single-aircraft-type, single-interceptor-type model, it can be extended to the multiple-aircraft-type, multiple-interceptor-type case, to address force-mix problems.  The prototype model considers the case of point defense of "hard" targets.  The methodology can be extended to consider other types of attack (e.g., cross-targeting) and defense (firing doctrines), such as subtractive overlapping-island defense.  If desired, it could also be extended to consider the case of simultaneous moves by the two sides (i.e., the case in which the attacker does not know the defense allocation prior to making his allocation).

 

The purpose of developing the prototype model is to demonstrate the feasibility of the proposed concepts, by means of a specific, concrete example.  The developed prototype accomplishes this objective.  It demonstrates a procedure for generating missions based on probability sampling within the context of a mathematical representation of tactical air combat.  Each of the missions that the model generates is consistent with the objectives of the two sides, and yet the model is capable of generating a large number (i.e., probability sample) of such missions.

 

Such a model has a high degree of face validity (since it is a reasonable and accepted abstraction of combat), and affords a basis for a broad and well-defined inferential scope (because, using the model, it is possible to quickly and easily generate a large probability sample of missions from a well-defined mission population).

 

The prototype model is a means of automatically generating tactics, given a specification of the targets and the aircraft and interceptor levels.  The Phase II effort will extent the methodology to consider variations in force levels and target sets (in addition to multiple aircraft and interceptor types).

 

In our proposal, we proposed to make recommendations, at the end of Phase I, concerning the following items:

 

            o Recommendation for tailoring of the DOD-STD-2167A to

               the Phase II effort

 

            o Recommendation for software development tools

                        (e.g., program development language, C-UNIX,

                        computer-assisted software engineering, or

                        CASE, tools)

 

            o Recommendation for a simulation language

 

            o Recommendation for a process-oriented language

 

            o Recommendation for computer hardware

              (workstations, by vendors such as Sun, SGI

              Apollo, HP and IBM)

 

            o Recommendation for a game-theoretic approach

 

In the Phase I effort, we have conducted analysis that has enabled us to make relatively well-founded recommendations on most of the issues listed above.  Since the Phase II effort will include additional requirements analysis and design work, however, recommendations are subject to change during the Phase II project.

 

Recommendation Concerning DOD-STD-2167A.  The Defense System Software Development standard, DOD-STD-2167A, is a very flexible standard, which can be tailored for application to a wide size range of software development projects.  It specifies a large number of documents that can be produced as part of the software development.  A software development contract generally specifies which documents are required to be produced by the contractor, in consideration of the magnitude and duration of the development effort.  Upon consideration of the anticipated size of the Phase II effort and the anticipated type of contract (a fixed-price contract allowing for payment upon delivery every three months, using invoicing by DD Form 250), we make the following recommendations concerning the 2167A development documents to be required by the contract.

 

It is recommended that the following documents be produced as part of the Phase II software system development effort:

 

            o Software Requirements Specification (SRS)

 

            o Software Design Document (SDD)

 

            o Software Test Plan (STP)

 

            o Software User's Manual (SUM)

 

            o Software Programmer's Manual (SPM)

 

The preceding documents represent a subset of the software development documents associated with DOD-STD-2167A.  This subset is appropriate for a project of the size anticipated for Phase II.  Production of these documents (and drafts as appropriate) will provide tangible research products throughout the Phase II period, and provide the Government with a sound basis for measuring project progress and approving either progress payments or payments linked to deliverable products.

 

In addition to the production of the preceding list of deliverables, we propose that technical reviews accompany the production of the major software design documents.  Specifically, we recommend that a Software Specification Review (SRR), a Preliminary Design Review (PDR) and a Critical Design Review (CDR) be conducted by the Government.  The SRR enables the Government to review and approve the software specifications prior to the contractor's proceeding to the design effort.  The PDR provides the Government an opportunity to review and approve the design approach.  The CDR affords the Government an opportunity to review and approve the detailed design.  A detailed description of the usual content of the SRR, PRD and CDR is presented in MIL-STD-1521B (USAF), Military Standard: Technical Reviews and Audits for Systems, Equipments, and Computer Software (Reference 17).

 

Task 6. Availability of Local Resources

 

As part of our Phase I feasibility assessment, we proposed to explore the possibility of gaining access to advanced computer hardware and software that may be available locally at military commands in the Sierra Vista area.  It was known that local commands possessed advanced knowledge-based simulation software and symbolic (list processing) computers, and that their missions involved problems that could require or benefit from an automated scenario generation capability.  If access to such equipment were possible, and if local commands expressed an interest in supporting the development of an automated software development system, the resource base for the Phase II effort might be expanded beyond that available from AFSC.

 

For these reasons, we examined the possibility of obtaining access to hardware and software that is available locally, at various commands located at Ft. Huachuca, Arizona (located in Sierra Vista).  To this end, we contacted the following individuals and organizations:

 

            o          Dr. Byron Dean, Scientific Advisor

                        US Army Intelligence Center and School

                        ATTN: ATSI-SA

                        Fort Huachuca, AZ 85636

                        Tel: (602)533-1143

 

            o          Mr. Robert Reiner, Chief

                        Modernization and Test Technology Office

                        ATTN: STEEP-MO

                        US Army Electronic Proving Ground

                        Fort Huachuca, AZ 85613

                        Tel: (602)538-7618

 

            o          Mr. Robert J. Harder, Head

                        Artificial Intelligence Office

                        Software and Automation Division

                        ATTN:STEEP-ET-S

                        US Army Electronic Proving Ground

                        Fort Huachuca, AZ 85613-7110

                        Tel: (602)533-1879

 

All three sources contacted expressed interest in the project, and agreed that the proposed work could be of potential benefit to the USAEPG and USAICS missions.  Mr. Harder suggested that some EPG resources might be available, if further discussions substantiated the benefit of the proposed work to the EPG mission.  Dr. Dean expressed the opinion that the proposed work fit both technically and functionally with the USAICS mission, and that the potential for mutual collaboration was strong.  Mr. Reiner acknowledged that the proposed work could be of definite value to EPG work relating to the Stress Loading Facility.

 

In summary, all local sources contacted expressed an interest in the project, and a desire to explore opportunities for mutual benefit, including possible support with hardware and software resources.  It was generally agreed, however, that the best time to become more definite about arrangements and commitments was after the Government had made a decision to fund the Phase II effort.  At that time, further discussions and analysis would be conducted, leading to a firm determination of the applicability of the proposed methodology to specific applications, and the desirability and availability of resource support under an agreement with AFSC.

 

Task 7. Develop Phase II Work Plan

 

A task specification, schedule and staffing plan has been developed for the Phase II effort.  The proposed work plan allows for the fact that a specific scenario generation application (such as STOVL) has not and may not be specified by ASD.  The work plan allows for either a specific or general development effort, by including a requirements analysis task during which the decision to orient the proposed research to a specific or general application will be made.

 

Task 8. Prepare Final Report

 

One of the features of the SBIR program is that the Phase II proposal may include large sections of the Phase I final report, verbatim.  To this end, this final report is oriented not only to the goal of establishing the feasibility of the proposed concept, but it is also heavily oriented toward the goal of assisting the preparation of the Phase II proposal.  The report includes a Phase II work plan (in Appendix H), which will be the basis for the Phase II proposed schedule, staffing plan, and budget.

 

D. Project Findings and Conclusions

 

The principal findings of the project are the following.

 

            1. Further consideration of the conceptual and analytical frameworks presented in our proposal has confirmed them to be sound.  The essence of these frameworks is the specification of a mathematical representation of aspects of combat, which includes definitions of strategies and tactics as probability distributions, and scenarios and plans as random variables defined on specified sample spaces in accordance with those probability distributions.  These frameworks provides a sound mathematical basis for generating samples of scenarios that can provide a sound inferential basis for evaluation studies.  No substantive changes are recommended to the conceptual and analytical frameworks presented in our original proposal. 

 

            2. A simple mission planning model has been developed, to demonstrate the proposed concept.  This model represents tactical air warfare as a resource-constrained two-sided optimization problem ("sequential-move game").  The model provides a framework for generating a population of missions, and for selecting a probability sample of missions from that population.  The population-generation and sampling are automated, rapid, and easy to implement.  This model demonstrates the feasibility of implementing the proposed concept.

 

            3. No other system was identified that accomplishes the objectives specified in our proposal.

 

            4. The RAND Corporation has available a modeling system, the RAND Strategy Assessment System (RSAS) that could assist some of the modeling proposed for Phase II.  Specifically, the RSAS contains a simulation system called the RAND Analytic Modeling Platform (RAMP), that could be used to accomplish efficient modeling of tactical air warfare.  This system is easy to learn to use, and would not consume an inordinate amount of Phase II project resources to apply.  The system is being converted to a Sun Microsystems SPARCstation 1 microcomputer, the cost of which (approx. $10,000) is reasonable for purchase by the firm.  Furthermore, the RAMP is written in the C programming language, so that it would not be necessary to make substantial expenditures for expensive compilers or commercial simulation languages.  In view of the availability of the RAMP, a reasonable approach to Phase II would be to use the RAMP to conduct tactical modeling, to develop the automated scenario generation software in C, and to conduct the development on a Sun SPARCstation 1 microcomputer.

 

It is noted, however, that the Sun SPARCstation is not the only computer that could be a strong candidate for the system.  SGI, HP, and other vendors produce competing equipment that will be considered before a final selection is made.

 

            5. The AFSC has an upcoming evaluation -- the evaluation of the short takeoff/vertical landing (STOVL) aircraft -- that could benefit from the application of the methodology that is proposed to be developed under the Phase II effort.  Specifically, the automated scenario generation methodology could be applied to generate "cases" (aircraft options and operational environment options) for analysis of the STOVL and alternative aircraft.

 

            6. An investigation of local Department of Defense commands at Ft. Huachuca revealed that the proposed methodology could assist the execution of the missions of those commands, and that resource support, in the form of computer hardware or software, may be available to support the project.  Although local commands expressed an interest in our project, no commitments for support were obtained, and the realization of local support would depend upon the outcome of further discussions, in Phase II.  Because the availability of access to advanced software and hardware from local levels is not established, our preliminary top-level design is not premised on the use of such resources, and our Phase II cost proposal will assume that all software and hardware resources must be provided either by the firm or by the Phase II contract funds.

 

E. Recommendations for Phase II

 

Based on the findings of the Phase I effort, and the expectations about the level of Phase II funding, the following recommendations are made for the Phase II activity.

 

            1. In order to make good use of available simulation software, it is recommended that the Phase II effort make use of the RAND Corporation RAMP modeling system.  Development of this system was funded by the Director of Net Assessment, Office of the Secretary of Defense.  If AFSC requests and receives approval for the use of the RAMP system by Vista, it would be available at no cost to the project.  RAND officials expressed the opinion that no problems would be faced in obtaining access to RAMP by Vista, if AFSC made a request.  (Note that the full RAND Strategy Assessment System (RSAS) is not available to contractors -- only the RAMP is available for use outside the Government.)

 

            2. It is recommended that the C programming language be used to implement the automated scenario generation software.  Not only is C considered to be a good choice for microcomputer program development (including graphics), but the RAMP is coded in C, allowing for easy interface.

 

            3. It is recommended that the development effort take place on a Sun Microsystems SPARCstation 1.  The RAMP is currently being converted to the SPARCstation 1.  This system is affordable to the firm.  The RAMP is implemented in the UNIX operating system, which is supported by the SPARCstation.

 

            4. If the implementation schedule of the STOVL evaluation permits, it is recommended that the STOVL evaluation be used as a "test-bed" for the proposed system development.  It is anticipated that the proposed methodology would be available sometime during the second year of the Phase II effort, to assist the generation of cases for the STOVL evaluation.  If the STOVL cases are not needed for about a year, the proposed Phase II effort could be of immediate benefit to the AFSC.  Otherwise, the proposed system would be available to provide scenario generation support to future AFSC and other DOD system evaluations.


 

II. Background of the Problem

 

A. The Need for Scenarios in Military System Evaluation

 

The goal of the proposed research is to develop methodology that will enable the rapid generation of broad-scope samples of scenarios.  Broad-scope samples of scenarios are needed so that the scope of inference of evaluation studies may be well founded and broad.  If a system evaluation is based on a single scenario, it is not possible to infer with a high or measured level of confidence that the performance of the system will be the same in other situations or circumstances.  This situation seriously undermines the reliability and validity of conclusions based on the evaluation.

 

Although this proposal is oriented to the use of scenarios in system evaluation, there are many other military analysis applications that could benefit from automated scenario generation methodology.  These applications include: force planning (force structure analysis, force level analysis, force mix analysis); research, development, test and evaluation (concept development, system design and development, system test and evaluation); operational planning and evaluation (analysis of operational concepts, tactics, doctrine); and training and education.

 

Although these many application areas could benefit from the availability of automated scenario generation methodology, it is not the case that all of these applications need a system that can produce probability samples of scenarios.  For example, scenarios are needed to support advanced training systems.  In that application area, however, the use of "judgment" scenarios would work satisfactorily.  There is no requirement in this application to develop valid, reliable statistical estimates of system performance.  What is needed is a capability of generating a wide range of scenarios, that will afford military personnel the opportunity to improve their skills in certain applications.  While that application and some others may not need probability samples of scenarios, they would still benefit from a methodology that could produce alternative scenarios fast and inexpensively.  For this reason, the results of the proposed research would be of interest and benefit to a wide range of application areas, not just those (such as system test and evaluation) in which probability samples of scenarios are needed to enable the construction of rigorous statistical estimates.

 

B. Problems Associated with Manually Generated Scenarios

 

There are two major problem that face the military systems evaluation community, with respect to scenario generation: (1) the current methodology for generation of scenarios does not have a well-defined conceptual framework; and (2) it requires a large amount of effort.  In general, the scenarios under which new systems or concepts are tested are manually developed.  These scenarios are developed by experienced military analysts, drawing heavily on their practical experience.  The scenarios are developed by a subjective process; the process is not reproducible, and it is not defined in terms of standard statistical concepts (i.e., in terms of populations, sample spaces, random variables, and probability distribution functions).  Because of the large amount of effort required to generate scenarios by manual means, it is usually the case that systems under test are evaluated in a limited number of situations.  Or, if a large number of situations is examined, the cost of generating these situations is high.

 

The large amount of effort required to generate scenarios manually usually implies that the number of cases examined in a system evaluation is not large or extensive.  Hence, the reliability (precision) and the validity (scope of inference) of the evaluation is restricted.

 

The first problem associated with current scenario generation methods, viz., the lack of a quantitatively defined conceptual framework, severely impairs the inferential basis for evaluations based on those scenarios.  The scenario(s) are generally specified by judgment, without benefit of a formal mathematical theory.  In general, it is not possible to identify the population of scenarios from which the proposed situation has been selected, or to define the probability of selection of the scenario used for the analysis.  The situation is analogous to the use of a so-called "judgment" sample in public opinion polling, instead of a sample based on probability sampling from a well-defined sample frame.  The problem that arises is that, since the sample is not a probability sample, it is not possible to apply statistical theory to make valid inferences about a larger population from which the sample was selected.  Instead, with a judgment sample, judgment must be used to make the inferences.

 

Essentially, all that can be inferred from an system evaluation based on a manually produced "judgment"-type scenario is the system performance in the particular scenario examined.  How the system will perform in other scenarios must be inferred using judgment, not statistical inference.  Since no statistical framework is identified, statistical inference is of no assistance in inferring the system performance for a well-defined population of scenarios, other than the one(s) actually used.  This serious shortcoming of the use of manually developed judgment scenarios is often not apparent, because statistical procedures are generally used to produce performance estimates from the scenario data (e.g., estimated means, standard deviations, variances, confidence intervals, proportions, etc.).  What is overlooked is that these estimates apply only to the scenario actually used, not to a larger population of scenarios.  In general, the estimated precision of estimates based on single scenarios is grossly misleading -- it includes the "within-scenario" component of variance, but excludes the "among-scenarios" component of variance.

 

A major reason why limited progress has been made in developing a systematic methodology for situation generation is that the problem is difficult.  In many research fields, such as social or economic research, the population of interest is a well-defined physical population, and it is a relatively easy matter to specify a sampling procedure for selecting probability samples from the population.  In military systems evaluation, on the other hand, it is not at all clear what the population of scenarios is.  The population of interest is all possible (or likely) situations under which a system under test may have to be deployed in the real world.  It is not a simple matter to identify all of the elements of this population.

 

In summary, the first major problem associated with the use of manually generated scenarios is the fact that the sampling population is ill-defined, so that the inferential scope of evaluations based on these situations is also ill-defined.  The second major problem is that, using manual methods, the number of situations that may be examined must generally be small (because of the extensive manual labor required to generate each situation).  Hence, the scope of inference of evaluations based on the situations is restricted.  A third problem associated with manual generation of scenarios is cost -- if it is desired to consider a large variety of situations, the cost of test and evaluation is high.

 

C. Motivation for an Automated Scenario Generation System

 

The motivation in proposing the development of methodology for automated scenario development is, hence, threefold: (1) to make the basis of inference of evaluations based on the situations well-defined; (2) to increase the reliability and broaden the scope of inference of evaluation estimates (by enabling a much larger variety of situations to be examined); and (3) to lower the cost of test and evaluation and of other applications that require scenarios, through the use of automated procedures.

 

The proposed methodology will benefit a wide range of military test and evaluation applications; it is not limited to application in tactical air warfare.  The problem of specifying scenarios / strategies / tactics / plans occurs in Air Force, Army, and Navy applications.  It arises wherever the problem of evaluation of a new system or concept arises.  The methodology developed in Phase II will benefit the entire test and evaluation community, not just the Air Force.

 

With the advent of the AirLand Battle 2000 concept of battlefield operations, the need for automated scenario development methodology has been made even stronger.  (See References 14-16 for discussion of AirLand Battle doctrine.)  The major functional concepts in AirLand Battle are close combat; fire support; air defense; communications; command and control; intelligence and electronic warfare; combat support, engineering, and mine warfare; combat service support; and aviation.  The basic operational concepts of AirLand Battle are initiative (with emphasis on maneuver), depth (deep attacks into rear echelons), agility (fast reaction), time (faster information processing and exchange) and synchronization.

 

The AirLand Battle concept involves the use of a concept-based requirements system, in which requirements (in doctrine, organization, training, and materiel) are related to mission area analyses and a battlefield development plan, which are in turn related to an explicit specification of the threat, technological forecasts, and force mission statements.  In order to evaluate and develop systems and concepts on a rational basis, it is important that these systems and concepts be evaluated in broad-scope scenarios that reflect the wide range of circumstances under which the AirLand Battle concept must work.

 

From the point of view of the Air Force, it is desirable that the performance requirements for new systems be related to the requirements of AirLand Battle, and to the role of the Air Force in supporting ground forces.  In other words, the specification and validation of requirements for Air Force systems and concepts should relate to AirLand Battle doctrine.  Because of the emphasis of AirLand Battle on maneuver and agility in a dynamic environment, it is important to have access to a range of scenarios that reflects the wide range of potential battlefield situations.  This holds true for aircraft missions relating to aircraft attack (close air support, battlefield air interdiction) as well as tactical reconnaissance.

 

An example of an AFSC application requiring the generation of scenarios, is the upcoming evaluation of the short takeoff / vertical landing (STOVL) aircraft.  The Statement of Work for the STOVL evaluation (in Appendix I) describes this requirement.

 

In summary, the availability of automated methodology for generation of scenarios will assist the Air Force in the evaluation of systems and concepts, and facilitate relating the performance of those systems and concepts to a wide range of battlefield situations.  In particular, the availability of this methodology will assist evaluation of systems and concepts in the context of AirLand Battle 2000 doctrine, and could assist the AFSC's evaluation of the STOVL aircraft and other similar system evaluations.

 


 

III. Phase I Activities and Results

 

This section describes project activities and results, in each of the tasks that were identified above:

 

            1.         Review Technology

 

            2.         Conduct Requirements Analysis

 

            3.         Complete Development of Conceptual and

                        Analytical Frameworks

 

            4.         Develop Top-Level System Design

 

            5.         Develop Prototype Model

 

            6.         Assess Availability of Local Resources

 

            7.         Develop Phase II Work Plan

 

            8.         Prepare Final Report

 

A. Review of Technology

 

During the course of Phase I, a number of organizations and individuals were contacted, to determine the current status of research in areas related to the proposed effort.  Since Vista Research Corporation has conducted previous work in the field of automated scenario generation, we were already well aware of much of the work that had been done in this field, and the effort in this project was limited to updating our previous knowledge of this field.

 

As noted, we had previously reviewed over fifty documents related to scenario generation.  In the course of our earlier research, we had contacted over twenty individuals in organizations engaged in scenario development or use (military organization, government laboratories, and defense contractors).  In the present study, we recontacted those organizations and individuals considered to be actively engaged in work most closely related to the proposed work.

 

We contacted the following individuals:

 

            1. Lt. Tom Wong

            Contracting Officer's Technical Representative

            Area B, Bldg 11a, Room 205

            USAF Air Force Systems Command

            Aeronautical Systems Division, ASD/XRX

            Wright-Patterson AFB, OH 45433-6503

            Tel: (513)255-5035

 

            2. Lt. Glenn Fye, Program Manager

            Distributed Situation Development

            Rome Air Development Center

            Griffiss AFB, NY 13441-5700

            (315)330-3175

 

            3. Dr. Ralph M. Toms

            Janus Program Manager

            Conflict Simulation Center

            Lawrence Livermore National Laboratory

            Box 808, L-315

            Livermore, CA 94550

            (415)423-7164

 

            4. Maj. Shuey E. Wolfe

            Joint Warfare Center

            Hurlburt Field, FL 32544

            (904)884-5870

 

            5. Dr. R. T. Hayes, Program Manager

            Joint Theater-Level Simulation (JTLS)

            Jet Propulsion Laboratory

            California Institute of Technology

            Pasadena, CA 91109

            (818)354-4321

 

            6. Mr. Alfred Silliman, Task Manager

            Joint Exercise Support System (JESS)

            Jet Propulsion Laboratory

            California Institute of Technology

            Pasadena, CA 91109

            (818)397-9328

 

            7. Dr. Joe Fearey

            War Gaming Technologist and Scenario Planner

            Jet Propulsion Laboratory

            California Institute of Technology

            Pasadena, CA 91109

            (818)397-9322

            8. Dr. Paul K. Davis, Director

            Strategy Assessment Center

            The RAND Corporation

            1700 Main Street

            Santa Monica, CA 90406

            (213)393-6912

 

A summary of the results of each of these contacts follows.

 

Lt. Tom Wong, AFSC/ASD. Lt. Tom Wong was the AFSC contracting officer's technical representative for the project.  Early in the project, Vista staff (Dr. Caldwell and Dr. Rasmussen) met with Lt. Wong to discuss the project goals, and assure that they were responsive to AFSC requirements.  The results of those discussions are described later, under the heading "Requirements Analysis" (Task 2).

 

Lt. Glenn Fye, RADC. Lt. Fye of RADC was contacted as a possible user of an automated system for generating scenarios.  He expressed an interest in our project, and, after completion of our February visit to AFSC in Dayton, Ohio, Vista staff visited Lt. Fye at Rome, New York.  We explained the purpose of our project, and inquired about the nature of RADC's work and how it might utilize automated scenario generation methodology.  Lt. Fye provided us access to a report (Reference 3) which described previous work funded by RADC in the area of situation assessment.  The concept described in the report was a "rapid profiling" technique, which was oriented to identification, from sensor data, of which member of a set of enemy operations was under way.

 

Lt. Fye introduced us to Mr. Jim Papagni of RADC, who briefed us on the Dynamic Ground Target Simulator (DGTS) of the Advanced Sensor Exploitation (ASE) Testbed.  Mr. Papagni was responsible for an effort to design a state-of-the-art battlefield simulation system that supports real-time scenario generation and sensor simulation to support analyst training, wargaming and provide real-time intelligence data for the ASE Testbed.  He indicated that the current software system for the DGTS was too slow, and would be interested in any developments that might support fast scenario generation capability.  Mr. Papagni provided us with two documents (References 4, 5) related to his work.

 

Dr. Ralph Toms, LLNL. We contacted Dr. Ralph Toms and Maj. Shuey Wolfe of the Lawrence Livermore National Laboratory to learn the current status of the Janus brigade-level combat model and the ConMod corps-level combat model.  The Janus model has been operational for several years, but continues to undergo enhancements.  The Janus is used to support brigade-level training.  The ConMod is a recent effort to develop a new corps-level automated war-game model.

 

Dr. Toms briefed us by telephone on the status of the Janus and ConMod development efforts.  Evidently the Janus model is well accepted, and the number of installations that support the model continues to grow.  A version is available at the US Army Intelligence Center and School at Fort Huachuca.  Janus is considered to be a replacement for the Joint Exercise Support System (JESS).  LLNL has encountered difficulties in obtaining continued support for ConMod from the Army, and is searching for alternative sources of funding.  Vista asked to be provided with ConMod documentation, as it becomes available.  Without additional documentation on the ConMod design, it is not possible to determine the extent to which an interface may be possible between ConMod and an automated scenario generation system.

 

Maj. Shuey Wolfe, JWC. Maj. Wolfe, who had previously worked on the Janus system, had transferred last year to the Joint Warfare Center at Hurlburt Field, Florida, where he is currently involved with application and support of the JESS, JTLS, and other combat models.  The Joint Warfare Center engages in theater-level modeling analysis for the Office of the Joint Chiefs of Staff.  In view of the relevance of the Phase II work to the mission of this activity, we offered to keep Maj. Wolfe apprised of progress on the automated scenario generation project.

 

Mr. Al Silliman, JPL. Staff of the Jet Propulsion Laboratory (JPL) were contacted to determine the need for automated scenario generation by the Joint Theater Level Simulation (JTLS) and Joint Exercise Support System (JESS).  Mr. Alfred Silliman was the initial point of contact.  He indicated that Dr. Tom Hayes at JPL had directed the development of the JTLS over two years ago, and that it had been handed over to the Concepts Analysis Agency and Syscon.  He directed us to Dr. Joe Fearey of JPL, for discussion of the potential role of automated scenario generation relative to JESS or other applications. 

 

Dr. Joe Fearey, JPL. Dr. Fearey stated that a lot of manual effort is expended in scenario development, and that an automated planner would be helpful.  JESS could use a scenario generator; Scenario-Oriented Recurring Evaluation System (SCORES) scenarios (recently renamed as TRAC Standard Scenarios, the scenarios produced by the Training and Doctrine Command (TRADOC) Analysis Command (TRAC)) are too static.  In the JESS application, the scenario is written down in words; it describes the motivation for the exercise.  The situation is reflected in the starting data base.  Putting the data base together is a monumental job, if starting from scratch.  Once the data base is available, most scenarios are excursions from a baseline.

 

Dr. Fearey expressed the opinion that it would be helpful if one could take a written description of the scenario and input it into a scenario generator whose output is changes to the data base.  He expressed the opinion that a two-year effort was probably not sufficient to build an automated scenario generator.   A scenario is highly specific to a specific corps and a corps commander's views.  Dr. Fearey expressed the opinion that for Air Force applications, it was necessary to generate the entire battlefield situation, in order to obtain the air situation.

 

Dr. Paul Davis and Mr. Ed Hall, JPL. A visit was made by Vista project staff (Drs. Caldwell and Rasmussen) to the RAND Corporation in Santa Monica, California, for the purpose of learning about the RAND Strategy Assessment System (RSAS) and briefing RAND staff on this project.  We met with Dr. Paul K. Davis, Director of the RAND Strategy Assessment Center, and Mr. H. Edward Hall, a member of the Center staff.  Dr. Davis demonstrated the RAND Analytic Modeling Platform, or RAMP.  The RAMP is a powerful system for rapidly developing war game models.  The RAMP allows the user to generate logic tables that describe the behavior of the opposing sides.  The RAMP supports knowledge-based modeling through an interpretive language called RAND-ABEL (trade mark registered).  Numerical computations (for bookkeeping and process simulation) are implemented in the C programming language.  The RAMP is implemented on Sun Microsystems microcomputing equipment, using the UNIX operating system.

 

From the point of view of the proposed Phase II effort, the RAMP is particularly attractive.  Not only does it represent a productivity-enhancing system for rapid generation of tactical combat models, but it is easy to learn and runs on low-cost computing equipment.  Dr. Davis and Mr. Hall estimated that less than a month of effort was required to become fully proficient in RAMP.  Finally, since the RAMP was developed with DOD funds, it would evidently be available at no cost to the project, if the Air Force requested permission for Vista to use it in the Phase II effort.  In summary, the RAMP system can assist the accomplishment of the Phase II goals, by providing a powerful yet low-cost war-game modeling capability to the project.

 

Dr. Davis provided us with a number of references describing the RSAS, the RAMP, and applications.  These references are included in the list of references at the end of this report (Reference 6-11).

 

B. Requirements Analysis

 

Shortly after award of the Phase I contract, in February, Vista staff (Drs. Caldwell and Rasmussen) visited the contracting officer's technical representative, Lt. Tom Wong, at the Aeronautical Systems Division of the Air Force Systems Command at Wright-Patterson Air Force Base.  A primary purpose of this meeting was to determine what requirements the Air Force may wish to apply to the automated scenario generation system.  The primary means for conducting this requirements analysis was to identify potential applications for automated scenario generation within the Air Force Systems Command, and to determine the requirements that these specific applications would levy.

 

After briefing AFSC personnel on the goals of the project, a roundtable discussion was held between Vista and AFSC staff, for the purpose of identifying specific potential applications, and thereby deriving additional specific system requirements.  After some discussion, it was concluded that the most likely near-term application for such a system would be the evaluation of the short takeoff/vertical landing (STOVL) aircraft.  Lt. Wong agreed to send Vista a copy of the Statement of Work for this evaluation effort, when it became available.  We received this Statement of Work, which is included in Appendix I.

 

The STOVL evaluation is an excellent example of the type of study in which an automated scenario generation capability would be useful.  The Statement of Work calls for evaluation of the STOVL aircraft in a variety of "cases."  A case is defined in this context as a combination of an aircraft force mix (i.e., a force consisting of aircraft of different types) and an operational environment option.  An operational environment option consist of four elements: a scenario, mission concept, basing concept and logistic support concept.

 

Appendix I contains a detailed description of the elements of an operational environment option.  A major thrust of the Statement of Work is the desirability of considering a wide range of cases, so that the inferential scope of the evaluation will be broad.  The assessment methodology is to "permit the evaluation of existing and conceptual aircraft in a variety of basing concepts and threat environments."  The methodology "shall have the capability to conduct sensitivity analyses based upon parametric variations (emphasis added) in aircraft characteristics, mission requirements, threat levels, and cost constraints."

 

A major problem with existing scenario generation procedures is that they are not parametric.  Instead, they are nonparametric in nature -- they are constructed in detail, piece by piece, rather than by means of varying the parameters of a scenario generation model.  This feature presents serious problems both in terms of the amount of effort required to construct the scenarios, and in terms of the procedures used to make inferences from the scenario sample.  Since there is no underlying probabilistic model for the scenario generation process, statistical theory cannot legitimately be used to extend the performance estimates which are based on the examined scenarios to a larger well-defined scenario population.  The proposed research is aimed at rectifying both of these serious problems.

 

In this Phase I effort, the requirements for the STOVL evaluation have been taken into account, in evaluating adequacy and appropriateness of the conceptual and analytical frameworks for eventually supporting AFSC applications.  The conclusion is that the proposed frameworks are adequate to support an application of the nature of the STOVL evaluation. 

C. Conceptual and Analytical Frameworks

 

Conceptual and analytical frameworks for the automated scenario generation system were presented in our Phase I proposal.  Those frameworks are presented in Appendix C to this final report.  Except for some minor notational modifications, amplification, and orientation to the specific application of theater tactical air warfare, those frameworks are still proposed as a basis for initiation of the Phase II effort.

 

The essence of the conceptual framework of the scenario generation system is the formulation of a method for specifying a population of scenarios from which probability samples may be selected for use in a particular evaluation.  Furthermore, it is proposed that the population of scenarios be parametrically defined, so that experimental designs or designed probability samples may be selected from those populations.  (By the term "designed probability sample" we mean a probability sample selected in accordance with a formal sample survey design, such as a simple random sample, stratified sample, or multistage sample design.)

 

Because battlefield strategies and tactics result from a conscious resource allocation process, we propose that the population of scenarios be formulated as the result of a resource-constrained optimization process.  The prototype mission generation model presented later in this report illustrates this conceptual approach.

 

D. Top-Level System Design

 

In our Phase I proposal, we recommended that effort be allocated toward the development of a preliminary top-level system design for an automated scenario generation system.  In addition, we proposed that recommendations be made relative to the following design issues:

 

            o Recommendation concerning what documents of

                        DOD-STD-2167A (Defense System Software

                        Development Standard) should be produced

                        in the Phase II project

 

            o Recommendation of a simulation language for

                        implementation          of combat scenarios (i.e.,

                        wargaming)

 

            o Recommendation of a process-oriented language (e.g.,

                        FORTRAN, Ada, C) for use in computationally

                        intensive operations additional to the war

                        game simulation (i.e., processes required to

                        generate scenarios, strategies, tactics, and

                        plans)

 

            o Recommendation of computer hardware for implementing

                        the system

 

            o Recommendation of an approach to implementing the

                        game-theoretic conceptual framework

 

Preliminary Top-Level System Design.  Appendix E presents a preliminary top-level design for the automated scenario generation system.  As was mentioned earlier, this system design was developed by establishing a list of system requirements, synthesizing a number of candidate systems that generally met these requirements, and selecting a preferred alternative on the basis of a cost-effectiveness analysis of the candidates.

 

The top-level system design views the generation of a scenario in two phases: (1) the specification of the scenario initial conditions (target set, force sizes, combat goals); and (2) the specification of a battle plan.  In this Phase I project, most of the analysis was directed toward assessment of the feasibility of generating battle plans, since this was considered to be the more difficult aspect of the scenario generation problem.  It was viewed that a statistical experimental design approach could be used to specify initial conditions.  The design approach for the battle plan generation is summarized in the following paragraph.

 

The top-level system design for the battle-plan phase of scenario generation is based on a mathematical model of combat, which represents combat as a two-sided resource-constrained optimal allocation problem, viz., a sequential-move game.  Under this design, the model is used to identify optimal strategies and tactics for combat.  A probability sample is selected from the set of optimal allocations defined by the optimal strategy/tactic.  This sample is a battle plan.  A sample of battle plans is obtained simply by repeating this sampling process.

 

The top-level design that was developed in this Phase I effort is preliminary.  In Phase II, additional analysis will be conducted in system requirements analysis and design.  Based on that analysis, changes could be made to the top-level design.

 

The paragraphs that follow describe the recommendations that have been formulated relative to the other design issues identified in our proposal.

 

DOD-STD-2167A Documentation.  It is recommended that the following documents be produced during the course of the Phase II effort:

 

            o Software Requirements Specification (SRS)

 

            o Software Design Document (SDS)

 

            o Software Test Plan (STP)

 

            o Software User's Manual (SUM)

 

            o Software Programmer's Manual (SPM)

 

The preceding documents represent a subset of the software development documents associated with DOD-STD-2167A.  This subset is appropriate for a project of the size anticipated for Phase II.  Production of these documents (and drafts as appropriate) will provide tangible research products throughout the Phase II period, and provide the Government with a sound basis for measuring project progress and approving either progress payments or payments linked to deliverable products.

 

Software Development Tools.  It is recommended to defer selection of software development tools (e.g., program design language, computer-assisted software engineering, or CASE, tools) until initiation of the Phase II effort.  It is considered best to make the decision concerning these tools when it is decided for certain what computer hardware will be used for the Phase II effort (e.g., a Sun Microsystems SPARCstation 1).

 

Simulation Language.  It is recommended that the RAND Analytic Modeling Platform (RAMP) be acquired for use in the combat simulation of the Phase II work.  The RAMP is a war gaming simulation system developed by the RAND Strategy Assessment Center expressly for the purpose of implementing alternative scenarios.  The RAMP would evidently be available at no cost to the project, if AFSC makes a formal request to RAND for use of the system by Vista.  The system is easy to learn to use, and is well-suited to programming the war-game process needed to implement scenarios.

 

High-Order Process-Oriented Programming Language.  It is recommended that the additional programming required in Phase II (i.e., additional to that which can be implemented in the RAND-ABEL simulation language of the RAMP) be conducted in the C programming language.  Not only is C a widely used language for development of microcomputer systems, but the RAMP is written in C.  This would enable an easy interface between the new code generated in the Phase II effort and the RAMP.

 

Computer Hardware.  The RAMP is currently implemented on a Sun 360 workstation, using the UNIX operating system, and will soon be converted to a Sun SPARCstation 1 microcomputer.  It is tentatively recommended to implement the proposed scenario generation system on a SPARCstation 1, using UNIX.  This system is very fast, yet affordable (approximately $10,000).  With this system, it would be possible to implement sophisticated graphics output at a later date, if the Phase II effort is successful.  A final recommendation concerning computer hardware will not be made until completion of the system design work (since the system design includes specification of the system hardware, as well as software).

 

Any recommendation concerning computer hardware is tentative and subject to change, because of the rapid changes in technology and price.  Recently, there have been substantial price drops in workstations, and more may follow.  In order to take full advantage of the competitive price situation for computer hardware, the final selection of computer hardware will not be made until we are ready to use the equipment.

 

Analytical Approach.  Our conceptual approach is to consider battlefield combat as a two-sided resource-constrained optimization problem, and to use this conceptual framework as a basis for describing populations of scenarios (strategies, etc.).  Although we identified a number of analytical methods for implementing this conceptual approach in our Phase I proposal, we did not recommend selection of a particular method for implementing a game-theoretic representation of combat.

 

In the prototype model presented later in this report, we use Everett's Generalized Lagrange Multiplier (GLM) method as the method for solving a two-sided resource-constrained sequential-move game.  While this method is likely to be the preferred choice in Phase II, we will defer making a final decision on this matter until the detailed design process is under way.  If the conceptual framework changes (e.g., battlefield combat is represented as a simultaneous-move game instead of a sequential-move game), other methods (e.g., the Brown-Robinson method of fictitious play) may be incorporated into the methodology.

 

 

E. Prototype Demonstration Model

 

In our Phase I proposal, we proposed to develop a simplified prototype model, to illustrate the concepts identified in the proposal.  Appendix G of this report presents a simplified prototype model.

 

The model presented in Appendix G represents battlefield combat as a two-sided resource-constrained optimization problem -- a "sequential-move" game.  In this representation, the defender places his interceptors, and the attacker then allocates his weapons and attacks, in full knowledge of the placement of the defender's interceptors.  This representation is different from a "game" in the strict sense, because in a two-person game each side selects his strategy simultaneously (i.e., strictly speaking, the term "game" implies simultaneous moves by the two players).

 

Appendix D presents a discussion of the basic concepts and definitions associated with tactical air warfare.  The key aspect of tactical air warfare that motivates the use of a resource-constrained game model is the fact that, in general, there are many more targets of opportunity than can be destroyed by the attacker's weapon resources, or that can be defended by the defender's interceptor resources.

 

The model presented in Appendix G uses a method for weapon and interceptor allocation that was originally developed by Dr. Caldwell, proposed principal investigator for the Phase II effort.  The method determines optimal weapon and interceptor allocations using the Generalized Lagrange Multiplier (GLM) method.  A complete description of the method was originally presented in a report (Reference 12) submitted to the US Arms Control and Disarmament Agency.  Since the original derivation was never published in the open literature, it is presented in Appendix E.  A computer program, called OPTIMA, has been written to implement the model.  The OPTIMA program is presented at the end of Appendix G.

 

The OPTIMA program of Appendix G is a mission generation model -- it selects a set of targets to be attacked.  Each selected set of targets is a probability sample from a well-defined population of target sets.  The population of target sets is the set of all possible solutions to the two-sided resource-constrained resource allocation problem (sequential-move game) that is used to represent tactical air warfare.  A number of these probability samples would be used in an evaluation.  Since each sample is selected with the same probability, an evaluation based on these samples would form performance estimates simply by forming the simple arithmetic mean of the various sample results.

 

In summary, the OPTIMA mission generation model of Appendix G demonstrates the feasibility of the proposed approach to generation of scenarios.  Using the model, it is possible to generate a probability sample of missions, from a well-defined population of missions (i.e., the set of all missions that are optimal solutions to the sequential-move game).

 

F. Identification of Local Resources

 

Because of the relatively small size of Vista Research Corporation and of the Phase II project, it is not possible to purchase a large amount of sophisticated simulation software and computer hardware for the project.  We have sought to overcome these resource limitations, however, by identifying simulation software, such as the RAMP, that can be used without additional cost on modest-cost microcomputer hardware.  In addition, we investigated the possibility of making arrangements to use simulation software and hardware resident at various commands at Fort Huachuca, for the Phase II effort.  (Fort Huchacua is located adjacent to Sierra Vista, Arizona, the headquarters location of Vista Research Corporation.) 

 

In order to motivate local commands to favorably consider a request by AFSC to provide resource support to Vista, we approached those activities that might benefit from the availability of automated scenario generation methodology.  Specifically, we approached activities in the US Army Electronic Proving Ground (USAEPG) and the US Army Intelligence Center and School (USAICS).

 

The following individuals were contacted:

 

            1. Dr. Byron Dean, Scientific Advisor

            US Army Intelligence Center and School

            ATTN: ATSI-SA

            Fort Huachuca, AZ 85636

            Tel: (602)533-1143

 

            2. Mr. Robert Reiner, Chief

            Modernization and Test Technology Office

            ATTN: STEEP-MO

            US Army Electronic Proving Ground

            Fort Huachuca, AZ 85613

            Tel: (602)538-7618

 

            3. Mr. Robert J. Harder, Head

            Artificial Intelligence Office

            Software and Automation Division

            ATTN:STEEP-ET-S

            US Army Electronic Proving Ground

            Fort Huachuca, AZ 85613-7110

            Tel: (602)533-1879

 

The paragraphs that follow describe the results of the contacts with the preceding individuals.

 

Dr. Byron Dean, USAICS. The US Army Intelligence Center and School is involved in the training of intelligence officers, and in the development of automated systems with which to conduct that training.  For example, the USAICS has a full eight-terminal Janus system.  They have used the JESS, and are currently involved in the development of the Intelligence Training Evaluation System / Training Evaluation Complex (ITES/TEC).  When this system is completed, it will require the specification of scenarios to drive it.

 

In view of the relevance of scenario generation to the USAICS mission, Dr. Byron Dean, Scientific Advisor to USAICS, was contacted, and briefed on the goals of the proposed work.  Dr. Dean stated that our project was technically and functionally related to their mission, and asked us to keep him informed of progress.  He thought that there might be a mutually beneficial relationship between the Phase II project and USAICS mission requirements.

 

Mr. Bob Reiner, USAEPG. Mr. Bob Reiner is head of the USAEPG office responsible for development of the Stress Loading Facility (SLF).  The SLF is a physical simulation system that generates electromagnetic signals for input to electronic systems under test.  The SLF can generate a wide spectrum of electromagnetic signals, through the use of computer-controlled signal generators.  The two major components of the SLF are the Noncommunications Threat Simulator (NCTS), which generates radar and navigation system signals, and the Communications Threat Simulator (CTS), which generates communication (radio) signals.  Scenario generation is of interest to the SLF, because a scenario must be specified to the NCTS and CTS for them to function.

 

Scenario generation is not a major problem for the NCTS, since the number of radars in the electromagnetic environment is small.  For the CTS, however, scenario generation is a major problem.  The battlefield electromagnetic environment may consist of several hundred thousand emitters.  It is a major undertaking to specify the emitter environment corresponding to even a single scenario.  When the CTS is eventually in operation, a strong requirement will exist for automated scenario generation methods.

 

We contacted Mr. Reiner, and informed him of the goals of our study and our interest in obtaining local resource support if it was established that our proposed research could be of benefit in SLF applications.  After review of our Phase I proposal, Mr. Reiner agreed that there could be a mutual interest.  He suggested, however, that we wait until Phase II was awarded before spending additional effort in exploring the issue in greater detail.

Mr. Bob Harder, USAEPG. Mr. Bob Harder is head of the Artificial Intelligence Office of the US Army Electronic Proving Ground (USAEPG) at Fort Huachuca.  This office has available a good deal of sophisticated simulation software and equipment, such as the KEE knowledge-based system and a Symbolics computer.  Mr. Harder indicated that the availability of the software and hardware was such that it was likely that resource support might be provided, if it were determined that the resulting product would be beneficial to EPG.

 

Another potential user of an automated scenario generation capability is the USAEPG Electromagnetic Environmental Test Facility (EMETF).  The EMETF is the Army facility responsible for test and evaluation of communications-electronics (CE) systems in corps-sized deployments.  Currently, the EMETF uses TRAC Standard Scenarios (SCORES scenarios) as the basis for its evaluations.  For several years, however, there has been a desire on the part of the EMETF to interface their electromagnetic system performance evaluation models with tactical combat models, to broaden the scope of inference of its evaluations.  To date, this has not been possible, because of the massive size of corps-level tactical combat models and the EMETF corps-level CE system evaluation models.  If the right automated scenario generation system were available, the EMETF could make use of it, to broaden the inferential scope of its CE performance evaluations.

 

In summary, the individuals contacted at Fort Huachuca were interested in the proposed work, and expressed a desire to consider further the possibility of some sort of mutually beneficial relationship.  It was generally agreed, however, that more detailed discussions should be held after the Phase II award, when discussions could move from a hypothetical basis to a firm one.

 

G. Phase II Work Plan

 

Appendix H contains a work plan for Phase II.  It is proposed to employ a modern systems engineering approach to the Phase II system design and development.  This approach includes a requirements specification, requirements analysis, functional analysis, synthesis of alternative top-level designs that meet the requirements, application of cost-effectiveness trade-off analysis to select a preferred alternative, development of a detailed design, optimization of the detailed design, implementation, and testing.

 

For the software development, the design will be based on a top-down, structured analysis / structured design approach, as advocated by DeMarco, Constantine, and Yourdon.  The DOD-STD-2167A Defense System Software Development Standard is consistent with this methodology.  The project work plan will be structured around the documentation to be produced in compliance with the 2167A standard.  This approach not only enhances the likelihood of producing a high-quality, maintainable software product, but also makes the research progress highly visible to the Government.  To enhance the visibility of the project progress to the Government, and to afford the Government an ample opportunity to review, approve, and provide input to the system design, we propose to hold three formal technical reviews: a Software Requirements Review, a Preliminary Design Review, and a Critical Design Review.  We propose to use the 2167A documents (and drafts, as appropriate) as the deliverables on which periodic payments can be made.

 

Unless we receive further direction from the Government, the work plan of Appendix H will be used as a basis for our Phase II proposal, if we are invited to submit one as a result of this Phase I effort.

 


 

IV. Recommendations for Phase II

 

Based on the Phase I results described above and presented in additional detail in the Appendices, the following recommendations are made for Phase II.

 

            1. The Phase I effort has demonstrated the feasibility of the proposed concept for automatically generating scenarios.  In view of the many organizations, in addition to AFSC, that could benefit from this methodology, it is recommended that Phase II be funded.

 

            2. It is recommended that AFSC approach the RAND Corporation Strategy Assessment Center (Dr. Paul K. Davis, Director) with a formal request to allow Vista to use the RAND Analytic Modeling Platform (RAMP) for the war gaming (scenario implementation) part of the Phase II effort.

 

            3. We propose to implement the proposed system on a Sun Microsystems SPARCstation 1 microcomputer workstation, using the C programming language and the UNIX operating system.  The rationale for this recommendation is that the RAMP is written in C and is currently being converted to a SPARCstation 1 with a UNIX operating system.

 

            4. We propose that the AFSC give consideration to applying the scenario generation methodology to assist the STOVL evaluation project.  This would be feasible if this application would not consume a large portion of the Phase II budget, and if the STOVL application would not need major input until the second year of the Phase II project.

            If AFSC deems that it is not feasible to support the STOVL effort with the proposed Phase II project, the requirements of the STOVL evaluation may still be used as an example of an AFSC evaluation application that requires scenario generation, and could benefit from the availability of automated scenario generation methodology.

 

            5.  We propose that the project be funded as a fixed- price contract, with eight deliverables (one every three months).  Payment, in the amount of approximately one-eighth of the total project amount, would be made upon delivery and acceptance of each deliverable (DD Form 250 invoicing).


 

 

 

Appendix A. References

 

1. Caldwell, J. G., Tactical Theater Air Warfare Methodologies: Automated Scenario Generation, Phase I SBIR proposal submitted to USAF Air Force Systems Command by Vista Research Corporation, Sierra Vista, Arizona, January 4, 1988

 

2. Caldwell, J. G., Research in Artificial Intelligence for Noncommunications Electronic Warfare Systems, final report produced under contract no. DAAB07-87-C-P057, Vista Research Corporation, Sierra Vista, Arizona, March 28, 1988

 

3. Rapid Application of Air Power Study (U), Task K, CDRL Item 002, Contract No. F41621-84-D5003, Volume I: The Rapid Application of Air Power (RAAAP), Dynamic Profiling Concept, report prepared for Joint Electronic Warfare Center Systems Engineering by E-Systems Garland Division, March 1987

 

4. Gilmer, John B., Jr., Real Time Simulation Functional Analysis, The BDM Corporation, Arlington, Virginia, March 1, 1988

 

5. O'Brien, David W. and Phil A. Merkel, Real-Time Simulation Final Technical Report, BDM Technical Report: DBM/ROS-88-11442-TR, The BDM Corporation, Arlington, Virginia, October 24, 1988

 

6. Davis, Paul K. and H. Edward Hall, Overview of System Software in the RAND Strategy Assessment System, RAND Corporation, Santa Monica, California, December, 1988

 

7. Bennett, Bruce W., Carl M. Jones, Arthur M. Bullock, and Paul K. Davis, Main Theater Warfare Modelling in the RAND Strategy Assessment System (3.0), RAND Corporation, Santa Monica, California, September, 1988

 

8.  Shapiro, Norman Z., H. Edward Hall, Robert H. Anderson, Mark LaCasse, Marrietta S. Gillogly, and Robert Weisser, The RAND-ABEL Programming Language: Reference Manual, RAND Corporation, Santa Monica, California, December, 1988

 

9. Allen, Patrick D., and Barry A. Wilson, Secondary Land Theater Model, RAND Corporation, Santa Monica, California, July, 1987

 

10. Davis, Paul K., A New Analytic Technique for the Study of Deterrence, Escalation Control, and War Termination, RAND Corporation, Santa Monica, California, May, 1986

 

11. Davis, Paul K., Applying Artificial Intelligence Techniques to Strategic-Level Gaming and Simulation, RAND Corporation, Santa Monica, California, November, 1985

 

12. Caldwell, J. G., et al., Some Problems in Ballistic Missile Defense Involving Radar Attacks and Imperfect Interceptors, ACDA/ST-145 SR-4, Special Report No. 4, report prepared for the US Arms Control and Disarmament Agency by Lambda Corporation (subsidiary of General Research Corporation), McLean, Virginia, May 1969

 

13. Defense System Software Development, Military Standard DOD-STD-2167A, US Naval Publication and Forms Center, 5801 Tabor Avenue, Philadelphia, Pennsylvania, 29 February 1988

 

14. AirLand Battle 2000, US Army Training and Doctrine Command, Fort Monroe, Virginia 23651, 10 August 1982; also, FM90-14, Rear Battle, 10 June 1985

 

15. Field Manual FM 100-5, Operations, US Army Training and Doctrine Command, Fort Monroe, Virginia 23651, 5 May 1986; available from US Government Printing Office, Washington, DC

 

16. Air Force Manual 1-1, Basic Aerospace Doctrine of the United States Air Force, 16 March 1984; available from US Government Printing Office, Washington, DC

 

17. Military Standard: Technical Reviews and Audits for Systems, Equipments, and Computer Software, MIL-STD-1521B (USAF), US Naval Publication and Forms Center, 5801 Tabor Avenue, Philadelphia, Pennsylvania, 4 June 1985

 

 

Appendix B. List of Contacts Made During Course of Project

 

            1. Lt. Tom Wong

            Contracting Officer's Technical Representative

            Area B, Bldg 11a, Room 205

            USAF Air Force Systems Command

            Aeronautical Systems Division, ASD/XRX

            Wright-Patterson AFB, OH 45433-6503

            Tel: (513)255-5035

 

            2. Lt. Glenn Fye, Program Manager

            Distributed Situation Development

            Rome Air Development Center

            Griffiss AFB, NY 13441-5700

            (315)330-3175

 

            3. Dr. Ralph M. Toms

            Janus Program Manager

            Conflict Simulation Center

            Lawrence Livermore National Laboratory

            Box 808, L-315

            Livermore, CA 94550

            (415)423-7164

 

            4. Maj. Shuey E. Wolfe

            Joint Warfare Center

            Hurlburt Field, FL 32544

            (904)884-5870

 

            5. Dr. R. T. Hayes, Program Manager

            Joint Theater-Level Simulation (JTLS)

            Jet Propulsion Laboratory

            California Institute of Technology

            Pasadena, CA 91109

            (818)354-4321

 

            6. Mr. Alfred Silliman, Task Manager

            Joint Exercise Support System (JESS)

            Jet Propulsion Laboratory

            California Institute of Technology

            Pasadena, CA 91109

            (818)397-9328

 

            7. Dr. Joe Fearey

            War Gaming Technologist and Scenario Planner

            Jet Propulsion Laboratory

            California Institute of Technology

            Pasadena, CA 91109

            (818)397-9322

 

            8. Dr. Paul K. Davis, Director

            Strategy Assessment Center

            The RAND Corporation

            1700 Main Street

            Santa Monica, CA 90406

            (213)393-6912

 

            9. Dr. Byron Dean, Scientific Advisor

            US Army Intelligence Center and School

            ATTN: ATSI-SA

            Fort Huachuca, AZ 85636

            Tel: (602)533-1143

 

            10. Mr. Robert Reiner, Chief

            Modernization and Test Technology Office

            ATTN: STEEP-MO

            US Army Electronic Proving Ground

            Fort Huachuca, AZ 85613

            Tel: (602)538-7618

 

            11. Mr. Robert J. Harder, Head

            Artificial Intelligence Office

            Software and Automation Division

            ATTN:STEEP-ET-S

            US Army Electronic Proving Ground

            Fort Huachuca, AZ 85613-7110

            Tel: (602)533-1879

 


Appendix C. Analytical and Conceptual Frameworks for Automated Scenario Generation

 

I. Conceptual Framework

 

A. Definitions

 

This appendix describes the conceptual and analytical frameworks for developing an automated methodology for generation of scenarios.  The term "conceptual framework" refers to a description of the general concepts underlying our approach.  The term "analytical framework" refers to a quantification of the conceptual framework, in terms of specific variables, functions, and procedures.

 

In this report, the term "scenario" is used to refer to a description of the initial compositions of the opposing forces, the targets, and the battle plan.  In order to develop a battle plan, the opposing forces develop strategies and tactics.  The term "strategy" refers to a probability distribution defined over a set of high-echelon (theater-level) actions or decisions (employment of task forces or force units at division or higher level).  The term "tactic" refers to a probability distribution defined over a set of low-echelon actions or decisions (employment of units or weapons at the division level or below).  (In air warfare, the term "tactical" refers to air attack in close support of friendly ground forces.)  A "plan" is a particular sample from a strategy or tactic, i.e., a specified military action or decision, selected according to the probabilities that define the strategy or tactic. 

 

The preceding definitions of "strategy" and "tactic" are military usages of these terms.  In the terminology of statistical decision theory, there is no consideration of echelon, and both concepts would be referred to using the term "strategy" (i.e., a probability distribution defined over a set of actions or decisions).

 

In order to generate a scenario, it is necessary to specify the force levels and targets prior to battle, to determine a strategy (or tactic) for the employment of the forces, and to select a specific plan from that strategy (or tactic).  At the strategic (theater) level, a scenario could involve simply the specification of a initial state of the forces and a strategic plan.  At a tactical level, a scenario would include specification of the initial state of the forces, a strategic plan for the high-echelon forces, and tactical plans for the lower-echelon forces.  

 

In addition to the military concepts of strategy and tactic, there is a third level of military planning, viz., "operational art."  "Strategy" refers to the theater echelon level; "tactic" refers to division or lower-echelon; "operational art" refers to the army/front echelon levels.  The concept of operational art is relevant to AirLand Battle doctrine, which is concerned with the rapid, synchronized movement, concentration and application of large military units.

 

The generation of a scenario involves the specification of the initial compositions of the forces, the targets, the combat goals of the two sides, the generation of strategies and tactics to achieve those goals, and the sampling of battle plans from those strategies and tactics.  Hence, although the term "scenario" refers simply to a specification of the initial state of the forces and the battle plan, the task of developing an automated scenario generation system includes the tasks of developing automated strategy, tactic, and plan generation systems.  The term "scenario generation," as used in this report, could reasonably be described by the terms "war plan generator" or "battle plan generator."

 

B. Motivation for an Automated Scenario Generation System

 

The conceptual framework for the proposed approach is derived from a consideration of why an automated scenario generation capability is needed.  Such a capability is needed to generate probability samples of scenarios for use in test and evaluation of military concepts and systems.  Because of the high cost of developing scenarios by manual means, many military systems evaluations are based on just one or a very limited number of scenarios.  Moreover, the scenario generation process often takes place without reference to a well-defined probability space (i.e, a well-defined population of scenarios and a probability distribution for selecting members from that population). 

 

Typically, the scenario generation process is "nonparametric."  By the term "nonparametric" is meant that a scenario is specified in detail without reference to parametrically specified probability distributions.  While the use of nonparametric procedures for specifying scenarios may be cumbersome, it is not the most serious problem, from a methodological point of view.  A more serious problem associated with many scenario generation procedures is that they make no reference to a sample space or probability sampling.  In statistical terminology, the developed scenarios constitute a "judgment" sample.  The problem with judgment sampling is that, while everyone may agree that it is reasonable, the methods of statistical inference cannot be used to make inferences from the sample about a larger population of scenarios, based on the sample results.

 

In summary, there are two major problems associated with the use of manual methods for scenario generation.  The first problem is the fact that the high cost of manually generating scenarios means that few of them can be used in an evaluation, thereby restricting both the reliability (precision) and the scope of inference of performance evaluations based on those scenarios.  The second problem -- a methodological one -- is that the procedures used to manually generate scenarios typically preclude the legitimate application of statistical analysis procedures to make broad-scope inferences from analyses based on the scenarios, since the probability space underlying the scenario selection is not well-defined.  To reiterate, the difficulty with "judgment" or "consensus" scenarios, then, is that, because no well-defined population of scenarios is identified, and because no well-defined probability sampling method is used to select the scenario from an identified population, the methods of statistics cannot legitimately be used to infer the performance estimates associated with the scenario to a well-defined large population extending beyond the scenarios actually used in the evaluation.

 

C. Goal of the Project

 

The goal in the proposed study is to develop a means for parametrically defining a population of scenarios, and a rapid means for selecting probability samples from that population.  Such a capability could be used to provide samples of scenarios for evaluation studies, and those studies could then infer the results from the sampled scenarios to the larger scenario population.  The basis of inference would be firm, and the scope of inference would be broad.  The availability of a rapid means of scenario generation would enable statistical experimental design and sample survey procedures to be applied to the scenario selection process.  The inference methods of statistics could then legitimately be applied to the analysis of the data obtained from the sampled scenarios.

 

The conceptual basis proposed for a scenario generation system is to specify a mathematical representation, or model, of combat; to use that model as a basis for specifying a population of scenarios; and to specify a method for selecting probability samples from that population. 

 

D. Concept of Battle

 

The preceding paragraphs have described the general concept of a scenario.  Prior to defining an analytical framework for scenario generation, we shall define some additional warfare concepts.  The analytical framework that follows quantifies these concepts (i.e., both the scenario generation concepts and the additional warfare concepts).

 

First, we describe the major elements of tactical air combat (either actual or modelled).  The major steps of the process are the following:

 

1. Define Force Elements and Targets

            o Define offensive weapon types (in tactical

              theater air warfare, aircraft or aircraft force mixes)

            o Define defensive weapon types (interceptors,

              either aircraft, artillery or missiles)

            o Define targets (specification of value and

              vulnerability; vulnerability is specified by a damage

              function that specifies expected damage (probability

              that target is destroyed, or expected proportion of

              value destroyed, as a function of the weapons and

              interceptors allocated to the target))

            o Define force units, task forces

 

In tactical theater air warfare, the term "weapon" would typically refer to an aircraft type, rather than a specific store (bomb, missile) carried by an aircraft.  The term "target" may refer to a force element (weapon, interceptor) or item of intrinsic value (targets of intrinsic value include civilian population, agricultural territory, infrastructure elements, and industry).

 

2. Specify Constraints

   Resource Constraints

            o Numbers of weapons of each type

            o Numbers of interceptors of each type

            o Numbers of targets and characteristics (value

              and damage function parameters)

   Other Constraints

            o Physical constraints (rates, ranges, flyout

              radii, mission durations)

            o Organizational constraints

            o Environmental constraints (e.g., corridors, terrain,

              weather, day/night)

            o Logistic constraints (e.g., POL, ammunition)

            o Political constraints

                        o Conditions under which certain targets will

                          or will not be attacked

            o Military doctrine

 

3. Specify Combat Goals

            o Specify combat goals in terms of observable, quantifiable measures of the degree of success in achieving combat objectives, such as the following:

                        o Enemy targets destroyed

                        o Friendly targets saved

            o The combat goals may be specified in terms of the maximization or minimization of an objective function, or the occurrence of a specified set of conditions

 

4. Determine Strategies/Tactics

            o Determine strategies (probabilistic specification of the use of task forces or major units), in accordance with stated combat goals and doctrine

            o Determine tactics (probabilistic specification of the use of units or weapons), in accordance with stated goals and doctrine

 

5. Generate Battle Plan

            o Select a sample from the strategy and tactic distributions.  (The strategy or tactic is a probability distribution over a set of military actions or decisions, such as the allocation of a number of weapons and interceptors to a set of targets.  The battle plan is a specific set of decisions or actions sampled in accordance with this probability distribution.)

 

6. Execute Plan and Assess Results

            o Conduct (or simulate) the battle, using the plan

            o Evaluate objective function or note occurrence

              of conditions corresponding to goal achievement

 

7. Describe Scenario

            o The scenario is defined by the initial state of the forces and targets, and the battle plan, i.e., by items 1, 2, and 5 of this list.  It is described by:

                        o Positioning of units (offensive, defensive)

                        o Engagements of units

                        o Assignment of aircraft to missions

                        o Assignment of aircraft to targets

                        o Allocation of interceptors to targets

 

Note that the scenario description corresponds to the end result of steps 1-5.  It is the description of the initial state of the forces and the battle plan, but does not include the battle outcome.  The scenario description need not (but may) include explicit description of the battle goals, strategy, and tactics, which are reflected in the battle plan.  That is, although the generation of a scenario involves the generation of strategies, tactics, and plans, a description of a generated scenario need not include a description of the strategies and tactics developed and used to generate it.

 

Strategy Specification.  A critical aspect of the conceptual framework is the means for determining the strategies and tactics (step 4, above).  We propose that the conceptual framework include the use of optimal strategies and tactics, i.e., the strategies/tactics that achieve a stated combat goal.  It is noted that not all military analysts agree that the use of optimal strategies is important, or even desirable.  For example, some major wargame models (e.g., VECTOR-II, VIC) utilize tactical decision rules derived from the judgment and experience of military experts, rather than optimal strategies.

 

We do not dismiss the importance of judgment strategies in certain applications, such as training and scenario evaluation.  In fact, actual wars are fought using judgment strategies.  We believe, however, that it is preferable to employ optimal strategies rather than judgment strategies as the basis for automated scenario generation, for several reasons.  First, this approach acknowledges, accepts, and uses the science and methodology of statistical decision theory as the basis for evaluation.  This approach is easy to defend.  In evaluating a system, it seems reasonable to examine the system performance in a context in which both the offense and defense are operating in the best possible (optimal) fashion consistent with stated combat goals (even though it may be also of interest to examine system performance under suboptimal conditions).  Second, corresponding to the class of optimal strategies is a well-defined population of scenarios; viz., the population of scenarios corresponding to optimal strategies.  The population of scenarios corresponding to judgment strategies is not well defined.  Third, the use of optimal strategies lends itself to speed, which is essential for an automated scenario generation system.  While the use of judgment strategies may have a role in training and detailed wargaming, and in scenario assessment, it is not considered a good candidate for fast, automatic generation of many scenarios, or of scenarios having specified properties.

 

II. Analytical Framework

 

The following paragraphs present an analytical framework for combat, including air, land, and sea forces.  The analytical framework that follows quantifies the concepts presented in the preceding paragraphs.  The presentation that follows is in general terms, i.e., it applies to any type of warfare (land, air, or sea).  In a particular application, not all of the structure that is defined below may apply, or be utilized (e.g., an aircraft mission analyst may choose not to become involved with the definition of task forces, but prefer to conduct an analysis simply in terms of total numbers of weapons and interceptors).

 

In quantitative terms, the analytical framework for the model is as follows.  First, we define a number of task forces (comprised of military units).  A task force (Xi) =  (xi1,xi2,...,xin), is comprised of various units (e.g., in tactical theater air warfare, force mixes of aircraft), xij = (xij1,xij2,...,xijm), which are in turn comprised of various force elements (e.g., in tactical theater air warfare, aircraft), xijk, which may be separately targeted, and the failure, neutralization, or destruction of which can affect the performance of the unit.  These force elements include weapons (both destructive, such as artillery, and disruptive, such as EW or misinformation), command and control centers, communications equipment, intelligence sensors, supplies, and personnel.

 

One or more task forces may be assigned to a task-force mission, which is defined in terms of the assignment of the task forces against another task force.  A unit mission is the assignment of units against other units, or against targets.  One or more weapons of a task force may be assigned a weapon mission, which is defined in terms of the assignment of the weapons against a target (force element, either weapon or nonweapon, or target of intrinsic value).

 

A battle strategy is a set of probabilities, pi, that specify the likelihood that a task force will be assigned to a particular mission.  A tactic is a set of probabilities, pijk, that specify the likelihood that a weapon will be assigned against a force element.

 

A plan (or battle plan) is a particular sample assignment, selected according to the probabilities specified by a strategy or tactic.  In particular, a strategic plan is a sample from a strategy, and a tactical plan is a sample from a tactic.

 

A scenario is a description of the force initial state (prior to battle) and a battle plan.  This description does not include a description of the results (outcome) of executing that plan. The battle outcome is a random variable; because of stochastic variability, the same battle plan could realize many different outcomes.  The battle outcome is determined by executing the plan in a real battle, or by inputting the scenario to a war-game (combat) simulation model.

 

A battle, then, is the implementation of a battle plan --the execution by task forces and units of their assigned missions, and the execution by weapons of their assigned missions.  The term "battle" refers to all of the events that occur during the course of executing the battle plan.

 

The battle outcome is a quantitative description of the result of the battle.  The term "battle outcome" may be used to refer to a description of the battle at a series of points in time, or at a single point in time (the "end" of the battle), at which hostilities cease.  It may be expressed in terms of the expected damage, or in terms of functions related to expected damage.

 

The expected damage is determined using damage functions, which specify the probability of destruction or  neutralization of each target, or the expected proportion of the target value destroyed, given the interaction of the forces of the two sides:

 

            dPxPy = D(X,Y,Px,Py)

 

where X symbolically denotes all of the task forces, units, and force elements of the friendly side (side 1, side A, the Blue side), Y symbolically denotes all of the task forces, units, and force elements of the enemy side (side 2, side B, the Red side), Px denotes a side 1 strategy (i.e., the probabilities of assignment of the friendly side task forces, units, and force elements to missions), and Py denotes a side 2 strategy (i.e., the probabilities of assignment of the enemy side task forces, units, and force elements to missions). 

 

During the course of determining a specific strategy or tactic (i.e., Px and Py), the force levels X and Y are considered fixed.

 

As mentioned, the battle outcome may be expressed in terms of the losses of each type of force element, unit, or target of intrinsic value.  Alternatively, discrete loss or victory indicator variables may be defined in terms of a set of logical statements about the magnitudes of losses of each force element, unit, or other target (just as goals are defined).  For each side, a set of payoff functions, Hx and Hy, are defined -- one for each goal statement.  The payoff is a function of the damage.

 

A war is a sequence of battles.  After each battle, the remaining forces are reconstituted to the extent that remaining force elements permit (recall that supplies, ammunition, payloads are force elements).  A war strategy is a scheme for determining a sequence of battle strategies.

 

Goal Specification. The goals are specified by the user, in terms of quantitative criteria associated with battle outcome.  A goal may be specified in terms of expected damage to various types of force elements, territorial losses, personnel losses, target damage, or other measurable quantities functionally related to expected damage.

 

Constraint Specification. Constraints include:

            o Resource constraints (weapon, interceptor stockpiles)

            o Physical constraints

            o Organizational constraints

            o Environmental constraints

            o Logistic constraints

            o Movement constraints

            o Strategic and tactical constraints

            o Political constraints

            o Military doctrine constraints


Appendix D. Definitions and Concepts in Tactical Air Warfare

 

I. Introduction

 

This appendix defines and explains in practical terms the phrases "Close Air Support,"  "Battlefield Air Interdiction," and "Deep Strike" in order to better understand their meaning as applied to an area of joint combat operations in wartime.  The purpose of the appendix is to assist the specification of a conceptual framework for tactical air warfare.  In particular, this appendix provides support for the proposal to represent tactical air warfare as a two-sided resource- constrained optimization problem (i.e., a resource-constrained sequential-move game).

 

A straightforward explanation of these terms is found in Air Force Manual AFM 1-1, Basic Aerospace Doctrine of the United States Air Force.  We shall extract statements of doctrine from AFM 1-1 and comment on them to bring practical meaning to abstract doctrine.  We begin with "close air support."

 

II. Close Air Support

 

AFM 1-1 states:

Close air support objectives are to support surface operations by attacking hostile targets in close proximity to friendly surface forces.  Close air support can support offensive, counter-offensive, and defensive surface force operations with preplanned or immediate attacks.

 

As can be seen, CAS is useful in all types of ground warfare.  But, how close is close air support?  The extreme case has been ground commanders calling the fire on their own position because they had been overrun by the enemy.  Normally the firepower is directed at the opposing enemy force that may be from 100 to 1500 or more yards away.  Generally speaking the ground commander will see an immediate effect from the employment of this firepower.

 

AFM 1-1 continues:

All preplanned and immediate close air support missions require detailed coordination and integration with the fire and maneuver plans of friendly surface forces.

 

Coordination, integration and planning are paramount.  In past battles grave mistakes have been made by ignoring these details.  Friendly patrols have been bombed after the Air Force had been told an area was clear of friendly forces.  Attacking airplanes have found themselves flying through a hail of friendly artillery shells when both the Air Force and the Army's long-range artillery attack the same enemy position at the same time.

The terms "preplanned" and "immediate" need some explanation.  The Air Force prefers "Preplanned."  It knows the target and can optimize the weapons carried (anti personnel, anti tank, etc.).  The logistic base can schedule its work load.  The pilots can plan their tactics for safest delivery.

 

"Immediate" implies aircraft waiting on alert for a call, or diversion of a flight en route to another target.  Immediate also implies emergency.  If a ground commander calls for an immediate air strike, it means he is in a situation he may not have planned.  Sometimes, for reasons of economy, the immediate strike is actually planned.  The ground forces send out patrols to find the enemy (as in Vietnam).  When discovered he can be pinned down until air power arrives.  The problem with most immediate strikes is the lack of schedule and tactical planning.  It is frustrating to have airplanes loaded with antitank weapons sent to a target consisting of enemy troops in the open.  The loss of effectiveness does not reduce the risk.

 

AFM 1-1 continues:

Close air support missions require access to the battlefield, timely intelligence information, and accurate weapons delivery.

 

Here, all seems self explanatory except possibly "access to the battlefield."  Access has many forms.  The weather must be sufficiently good to enable definition of the target.  The airplanes must have sufficient range and endurance to reach the battle area and stay long enough to have an effect.  The enemy air defenses must be weak enough to allow air attacks to succeed without undue losses.

 

Finally, the battlefield must be locatable to be accessible.  In Vietnam for instance, search and destroy ground force missions established a battlefield wherever the enemy chose to stop and fight.  An air strike must be able to find that friendly force on the ground, and be given the enemy position from that reference.

 

AFM 1-1 continues:

Close air support enhances surface force operations by providing the capability to deliver a wide range of weapons and massed firepower at decisive points. Close air support can surprise the enemy, create opportunities for the maneuver or advance of friendly forces through shock action and concentrated attacks, protect the flanks of friendly forces, blunt enemy offensives, and protect the rear of surface forces during retrograde maneuvers.

 

These last sentences complete the definition of CAS with a catalog of capabilities.  In CAS, the airplanes are used as purveyors of a type of artillery support that is more flexible, can be massed easily and can deliver larger weapons for greater effect.  The emphasis is on direct support of ground operations where results are seen immediately.  Quick results are not the usual effect of the next form of air support for ground forces to be discussed, interdiction.

 

III. Interdiction

 

A. Air Interdiction

 

AFM 1-1 states:

Air interdiction (AI) objectives are to delay, disrupt, divert, or destroy an enemy's military potential before it can be brought to bear effectively against friendly forces.  These combat operations are performed at such distances from friendly surface forces that detailed integration of specific actions with the fire and movement of friendly forces is normally not required.  Air interdiction attacks are usually executed against enemy surface forces, movement networks (including lines of communication), command, control, and communications networks, and combat supplies.  Interdiction of the enemy can delay the arrival of buildup of forces and supplies, disrupt the enemy's scheme of operation and control of forces, divert forces and supplies.  Air interdiction attacks are normally executed by an air commander as part of a systematic and persistent campaign.

 

This is a fairly simple concept; find the enemy war-making potential and blow it up.  These targets are safe distances from friendly forces.  Note, however, that the campaign must be systematic and persistent.

 

AFM 1-1 continues:

Although an air interdiction campaign can be an independent air effort, an air campaign normally coordinates an interdiction campaign with a surface force commander.  An air interdiction campaign is developed to limit the enemy's mobility to maneuver forces, while forcing the enemy into high rates of consumption, and to create opportunities for friendly forces to exploit the disabilities produces by interdiction attacks.

 

Interdiction is planned into the grand scheme of the battle, but its effects are not generally noted by the troops in the trenches.  It is hard to convince a soldier that without the interdiction campaign there would be more people shooting at him.  The ground troops would rather see close air support.  The Air Force prefers interdiction because it has all the advantages of a preplanned strike.  The ground commander must support the air interdiction campaign by attacking and forcing the enemy to consume supplies so that resupply trains may be found and attacked.

 

Interdiction in a low intensity or guerrilla war is almost impossible to obtain or assess success.  If a guerrilla supply point is destroyed, the enemy just waits until he has rebuilt enough to reengage friendly forces.

 

Although high-intensity conflict would tend to enhance the effect of interdiction, this type of conflict usually involves sophisticated defenses.  Defense has a serious impact on the effort required to mount a successful interdiction campaign.  By 1972, a sixteen-bomber attack on supply lines in North Vietnam took in excess of 200 support planes including tankers, electronic countermeasures, SAM suppression, fighter escort, rescue, and reconnaissance.

 

AFM 1-1 continues:

The weight, phasing, and most importantly, the timing of interdiction attacks can provide friendly forces the time or opportunity to seize the initiative and deny that same opportunity to an enemy.

 

 

Of these elements, timing is most important and is dependent upon being integrated with the ground commander's plans.

 

B. Battlefield Air Interdiction

 

AFM 1-1 continues:

Air interdiction attacks against targets which are in a position to have a near term effect on friendly land forces are referred to as battlefield air interdiction. The primary difference between battlefield air interdiction and the remainder of the air interdiction effort is the level of interest and emphasis the land commander places on the process of identifying, selecting, and attacking certain targets.  Therefore, battlefield air interdiction requires joint coordination at the component level during planning, but once planned, battlefield air interdiction is controlled and executed by the air commander as an integral part of a total air interdiction campaign.

 

Battlefield air interdiction (BAI) is an integral part of the short term ground tactical plan.  Airplanes are used as artillery that fires big shells a long way (20-100 miles).  Today's mechanized armies can move divisions 40-50 miles in a day.  BAI can keep mechanized troops held in reserve from ever reaching the battlefield.  BAI was decisive in stopping the North Vietnamese Army advance on the town of Hue during their March 1972 (Easter) offensive.  In WWII, the successful invasion of Normandy was enhanced by the inability of German forces to move to the area due to battlefield air interdiction.

 

In summary, the purpose of air interdiction is to isolate the battlefield by attacking the enemy's lines of communication and the troops and supplies on those lines.  If the isolation is required by the ground forces' plan of attack, is short term, and is close to the friendly forces, the air interdiction is called "battlefield air interdiction."  Any air interdiction beyond the immediate concern of the ground commander may be considered deep strikes.

 

IV. Deep Strikes

 

Any definition of "deep strike" becomes vague in that it approaches a definition of strategic attack yet eventually effects the tactical battles.

AFM 1-1 states:

Attack an Enemy in Depth. Integrated strategic and tactical actions produce a cumulative effect on the enemy's ability to wage war.  Successful strategic attacks directed against a the heartland will normally produce direct effects on an enemy nation or alliance.  Its impact on the military forces engaged in tactical action, however, may be delayed because of the inherent momentum of forces actively engaged in combat and those reserve forces ready to enter the action.  Consequently, an air commander must exploit the devastating firepower of air power to disrupt that momentum and place an enemy's surface forces at risk.  To do that, an air commander must attack not only those enemy forces in contact, but enemy forces in reserve or rear echelons as well.  An air commander's in-depth attacks against these forces must include targeting an enemy's movement network (including his lines of communication) and his command and control structures used to guide the actions of enemy forces.

 

Deep strikes are distinguished from battlefield air interdiction by their distances from the front and the length of time it takes to see results at the front.

 

This concludes the discussion of definitions.  We will now consider a general war scenario in a European-like environment and describe how the doctrine looks and operates on such a battlefield.  The paragraphs that follow describe the nature of the target-selection process, and motivate the mathematical representation of tactical theater air warfare as a resource-constrained optimal allocation problem.

 

V. Operational Considerations

 

As time passes, weapons, equipment and names for the tactical air system may change, but the system always leaves its basic principles intact.  In any battle where the Air Force is in support of the Army, face to face negotiations will take place to insure the most efficient use of the combat power available to each service.  A system of communication between the services and between each level of authority within the services will exist.  A short history of the development of today's system principles may help in understanding the nature of tactical air support.

 

In WWII, North Africa, tactical air was organic to the Army division.  It was small.  It was unable to mass enough fire power to affect the land battle facing its parent division.  Higher headquarters decided to consolidate all the air power and control it from a Joint Operations Center (JOC).  Air power now could be massed in enough force to affect the overall battle plan and still have enough resources left to keep a presence felt across the entire front.  CAS was performed more like what we have defined here as BAI.  In Korea, CAS evolved very close to its present form.  A Forward Air Controller (FAC) was required to direct all air strikes in close proximity to friendly forces.  FACs are experienced fighter pilots who know how to direct an air strike precisely.  Precision is definitely necessary for the delivery of ordnance so close to friendly forces.  FACs and the supporting Tactical Air Control Party (TACP) were assigned down to regiment level.  In the Vietnam era, TACPs were assigned down to each battalion.  The system remains essentially the same, with refinements in equipment and adjustments for the type of war being fought.

 

In describing this system we begin with the FAC.  His job is representing the Air Commander on the scene, both to the ground force commander and to the strike force aircraft assigned to his control.  His TACP is located within the battalion operations center and probably consists of a jeep with lots of communication equipment, one or two enlisted communication specialists, and possibly a small spotter airplane and mechanic. 

 

The FAC is the key to the employment of air power in the Close Air Support role.  FACs gather intelligence through daily flights over the combat zone, and FACs know the ground operations plan.  A FAC is responsible for identifying the enemy targets, and for the tactics to be employed by the strike aircraft.  His authority in the direction of an air strike is absolute, a fact recognized by both the ground commander and the fighter pilots.

 

A FAC, as representative of air power to the ground commander, advises on its effective use.  When the battalion is making its plans for tomorrow's operations the FAC is intimately involved.  Targets are selected and prioritized.  Targets suitable for air strike are identified.  Generally, no decisions concerning artillery versus air strike are made at this level, only recommendations. 

 

The selection and prioritization of targets takes into account that, typically, there are not sufficient resources available to destroy all of the available targets, and that the characteristics of targets vary, in terms of value, vulnerability, and risk.  Because there are more targets of opportunity than can be destroyed, tactical air combat may be viewed as a resource-constrained optimal allocation problem.  Because targets vary in terms of value, and because target damage is a nonlinear function of the weapons and interceptors allocated to a target, the task of prioritizing targets is a nontrivial nonlinear optimization problem. 

 

The recommendations flow up both Army and Air Force channels.  At brigade level, target lists are collated and reprioritized.  At division level the list is consolidated and force allocation begins.  Artillery is allocated according to the division plan, air strikes are requested, again in priority order.

 

At each level, there is an Air Liaison Officer (ALO) advising on the appropriate use of air power.  An ALO at division or higher would probably operate out of an office called the Direct Air Support Center (DASC).  The DASC is an expanded FACP with a semi-permanent location and possibly a mobile radar for control of the air assets assigned to it each day.  The DASC processes all requests for air support through Air Force channels.  Finally, at the highest operational headquarters in the field, there will be a Joint Operations Center (JOC) where the Army and the Air Force staffs jointly run the war.

Within the JOC is a Tactical Air Control Center (TACC) where air assets are finally allocated and integrated into the overall scheme of the war.  The TACC is a greatly expanded DASC, with a capability to direct and control the entire air effort through radar and direct communication.  The TACC knows everything about the air war:  aircraft numbers, maintenance condition, how soon to launch the next flight, targets for specific airplanes, the ordnance carried by every airplane, location of FACs - everything!  It is in the TACC that requests for immediate air strikes are received.  Such a request passes directly from the battalion commander to the FAC to the TACC, by-passing all intermediate levels of command, although they are monitoring the request.  In a very short time, if the intermediate levels of command have not intervened with an alternative means of supporting the request, the immediate air strike will be approved.  Decisions on how to support the approval will be based on the priorities for the day and the forces allocated for each of the days events.  Alert forces may be launched, if available and suitably armed for the strike.  Or, an airborne flight can be diverted from their preplanned target and directed to the FAC.  Radar is very important to this kind of control of air assets.  Rapid, secure, and reliable communications, including radar, are required for the optimum use of the capability and flexibility of air power.

 

The concept of centralized control and decentralized execution is a cornerstone of air doctrine and is accepted as the most effective means of employing air power.  In wars of stabilized fronts and limited advances, BAI requires an extensive intelligence effort, but the resource allocation problem is minimized due to the preplanned nature of the operation.  In wars of rapid movement and small unit engagements, CAS can be most useful.  Intelligence is fragile and fleeting but accurate and timely.  Resource allocation becomes a prime consideration in rapidly moving battles.  To commit forces now may deny their availability to a more lucrative target later.

 

Since the war in Southeast Asia involved organizing air assets for both types of warfare, the experience should serve us well.

 

VI. Summary

 

We close this appendix with a brief list of considerations in the use of tactical air power.

 

Close air support is used to:

            1.  Create an immediate effect on the current battle.

            2.  Strike only military targets.

CAS can be preplanned, but is always in response to enemy action.

 

Battlefield air interdiction is used to:

            1.  Create a short term military effect in support of     our current ground operational plan.

            2.  Strike chiefly military targets or lines of     communication.

BAI is preplanned, but often dictated by enemy action.

Deep strikes are used to:

            1.  Support our political position.

            2.  Reduce or eliminate the enemy's will to continue the

                war.

            3.  Strike targets that may not be strictly military.

            4.  Support defensive, stalemate, and offensive             operations.

Deep strikes are preplanned, and totally under our control.

 

Tactical air power is a chain with many complicated links, command, control, communications, intelligence, logistics, etc.  There are no specific weak links until measured against a specific scenario, or the action of a real enemy.

 

In general, since insufficient resources are available to totally destroy, or completely defend, all targets, and since the damage caused to a target is a nonlinear function of the weapons and interceptors allocated to it, the problem of selecting targets may be viewed as a resource-constrained nonlinear optimization problem.

 

References

 

1. Air Force Manual 1-1, Basic Aerospace Doctrine of the

United States Air Force, US Government Printing Office, Washington, DC, 16 March 1984

 

2. Partridge, Earl E., Air Interdiction in World War II, Korea, and Vietnam, US Government Printing Office, Washington, DC, 1986

 

3. Momyer, Gen. William W. USAF, Ret., Air Power in Three Wars (WWII, Korea, Vietnam), US Government Printing Office, Washington, DC, 1978

 


Appendix E. Scenario Generation System Preliminary Top-Level Design

 

I. Approach to Top-Level Design

 

This appendix describes a top-level design for an automatic scenario generation system.  The top-level design incorporates the conceptual and analytical frameworks presented in Appendix C.  The approach to specifying the top-level design is to specify a number of requirements that the system must specify, to synthesize a number of alternative candidate system designs that satisfy these requirements, and to conduct a cost-effectiveness analysis to select a preferred alternative.  The system requirements are derived from consideration of the needs of potential users of the system, the conceptual and analytical frameworks, and the resources available for system development.

 

The top-level design presented in this appendix is a preliminary design, developed with limited resources.  Although it is preliminary, it has nevertheless been used as the basis for the detailed design and implementation of the prototype model presented in Appendix G.  The top level design is subject to revision in Phase II of the project, as a result of refinement of the requirements specification and further analysis.  If revisions do occur, then the prototype model would be revised and extended accordingly.  This approach is the "rapid prototyping" or iterative approach to model design.

 

II. Requirements Specification

 

Based on consideration of the many different military system evaluation applications that generate a requirement for an automated scenario generation system, and in consideration of the particular requirements of the STOVL system evaluation, we propose the following requirements to be levied on the automated scenario generation system.

 

            1. The system must comply with the conceptual and analytical frameworks set forth in Appendix C.  In brief, the system must be automated, and enable the generation of probability samples of scenarios.

 

            2. The system must be developable within the funding levels expected for Phase II (i.e., $250,000 per year for two years).

 

            3. The system must be capable of being adapted to support the STOVL evaluation, without major modification.  That is, the Phase II resources may be allocated to the design and development of a general-purpose scenario generation system, but the design must be such that the resulting system could be modified to support the STOVL application, at modest cost.

 

            4. To permit ease of use and wide applicability, it is required that the automated scenario generation system allow the user the option of specifying scenarios parametrically.  This feature will enable the user to specify complex scenario sample designs, i.e., to generate a sample of scenarios having specified characteristics.  This capability will enable the system to support evaluation of systems under test/evaluation from several perspectives:

 

            o Assessment of the system under test (SUT) to comply with requirements

 

            o Assessment of the system under test to operate adequately in a realistic environment

 

            o Assessment of the system under test to operate under "stress-level" conditions (i.e., environmental loads that exceed normal expectations, and may degrade the performance of the system to an unacceptable level)

 

            o Assessment of failure characteristics of the system (graceful or catastrophic) as the load on the system is increased

 

            o Characterization of the performance of the system under alternative conditions (e.g., night/day, weather, geographic locations, types of war)

 

            o Determination of the system "break points," i.e., conditions under which the system performance begins to fall below that required

 

            o Determination of the performance of the system under specified conditions (realistic, stress-level, specialized), even though that performance may fail to meet original performance specifications

 

The preceding requirements are general.  It is anticipated that, as part of the Phase II effort, additional system requirements may be imposed.  As the system requirements are changed, the system design may also change.  For this reason, the top-level design presented here is a preliminary one, that is subject to change in Phase II.

 

 

 

III. Synthesis of Alternatives

 

As mentioned, we propose to adopt a "rapid prototyping" approach to the development of an automated scenario generation system.  This approach is described in Appendix H (Phase II Work Plan).  Previously, this approach to model building was referred to simply as an "iterative approach to model building."  This evolutionary approach to model development is appropriate for the development of a complex system in situations where several alternative approaches are available and it is difficult to know in advance whether a particular approach will be satisfactory or most cost-effective.  The approach allows for iterative reconsideration and respecification of the system requirements, in the light of additional knowledge obtained by operation of the prototypes.

 

Two Phases of Scenario Generation. In the discussion that follows, it is helpful to consider two phases to scenario generation.  The first phase is concerned with specification of the general setting for the combat, i.e., the geographic location, force compositions and sizes, and general military goals.  This phase is concerned with the specification of the initial conditions and goals of combat.  The second phase is concerned with specification of a battle plan, i.e., the intended movements of units against targets during the battle.

 

This Phase I Effort Emphasizes the Battle-Plan Phase of Scenario Generation. In this Phase I effort, we have placed heavier emphasis on the second phase of scenario generation, i.e., on the generation of battle plans given the scenario initial conditions.  While it is not intended to depreciate the importance of the first phase, that phase is considered easier to address from a technical viewpoint, for several reasons.  First, some evaluations (e.g., a preliminary evaluation of the degree to which a system satisfies a particular requirement in a developmental context) are deliberately restricted in scope, and it is desired only to evaluate system performance under certain prescribed conditions.  In this case, it may not be not necessary to sample sets of initial conditions (i.e., the first phase of the scenario generation process); instead, it is necessary only to specify samples of plans that could be used under those conditions (i.e., the second phase of the scenario generation process).  Second, in broad-scope evaluations in which it is required to consider alternative evaluation contexts, it is considered that a reasonable approach to the first phase is to parametrically specify general scenario settings (i.e., geographic locations, scale of combat) using the methodology of statistical experimental design. 

 

The reason for the applicability of an experimental-design approach (or, alternatively, a stratified sample-design approach) is that most evaluations are concerned with the characterization/estimation of system performance, conditional on specified types of environment or application.  If it is suspected that system performance may differ substantially under different conditions, the evaluation analyst should present results for these different conditions.  It is not helpful to simply "average over" all of these different conditions.  It is desirable to present results conditional on types of environments or conditions, and it is desirable that the scenario generation process be able to generate scenarios representative of those different conditions.

 

For this reason, it is desirable to have a scenario generation system that can generate a wide variety of scenarios.  Furthermore, to make it feasible to efficiently describe these different scenarios, it is desirable to be able to describe scenario initial conditions parametrically.  Finally, even if an analysis is restricted to a particular type of scenario, it may be desired to generate samples of that type of scenario (in order to conduct statistical inference over that scenario class).  To do this, it is necessary to have an explicit definition of what is meant by "that kind of" scenario.  This problem is solved if we are able to develop a parametric specification of scenarios (since a scenario type may be specified in terms of values or ranges of values of the parameters).

 

While the methodology of statistical experimental design requires specialized expertise and resources to apply, it is a well-developed methodology, and, based on experience, it is considered feasible to apply this methodology to the problem of specifying scenario initial conditions.  For this reason, most of the feasibility-assessment effort of this Phase I project was allocated to the problem of assessing the feasibility of battle plan generation, rather than of assessing the feasibility of generating scenario initial conditions.

 

(The problem of determining a parametric specification of scenarios is not trivial, for it is necessary to identify measurable parameters that characterize scenarios and are believed a priori to be related to system performance.  Nevertheless, the feasibility of accomplishing this is judged to be considerably less in question and an issue for analysis than the problem of generating probability samples of battle plans.)

 

The second phase of scenario generation is considered more difficult, since it is concerned with the dynamics of combat and the allocation of forces to achieve combat goals.  From the point of view of feasibility assessment, it is considered that this phase of scenario generation warrants more consideration than the first phase.  Since the basic purpose of an SBIR Phase I study is feasibility assessment, we emphasize the second phase of scenario generation in this study.  Although this Phase I study concentrates on assessment of the second phase of scenario generation, the Phase II development effort will include full consideration of both phases of scenario generation.  For the discussion that follows, we shall consider the scenario generation problem from the point at which the basic parameters of the scenario (initial force locations and sizes, targets, goals) have been specified, and it is required to specify plans that specify how those forces will be allocated against targets during the course of the battle.

 

In summary, we are conceptually splitting the problem of scenario generation into two phases: (1) specification of initial conditions, and (2) specification of battle plans, given the initial conditions.  (Note that the second phase, specification of battle plans, includes the consideration of both strategy and tactics.)

 

Advantages of a Parametric Specification of Scenarios. Once a scenario is specified, a system evaluation may use a scenario as a basis for specifying input to a detailed system evaluation model.  This input specification requires detailed specification of the placement and movement of units and the operation of equipment.  While this aspect of system evaluation is beyond the scenario specification phase, it nevertheless affects scenario specification, since the scenario specification must be sufficiently detailed to permit an interface from the scenario specification to the system evaluation model.  In the Phase II effort, it will be attempted to develop a scenario generation system that will be amenable to interface with a wide range of system evaluation models.  Solution of this interface problem would be facilitated if a means of parametrically describing scenarios were available, for then a parametric interface between the scenario and the evaluation model would be possible.  By a "parametric interface" is meant that a scenario would be described in terms of a relatively small number of parameters (e.g., unit sizes, locations), and that these parameters would be input to the evaluation model, instead of a detailed nonparametric specification of the scenario.

 

We shall now consider several alternative approaches to the design of an automated scenario generation system.  For the reasons noted above, we restrict consideration to the phase of scenario generation concerned with the formulation of battle plans, given the initial compositions of the forces and targets.  Several alternative approaches to the design are the following:

 

            1. Generate a population of scenarios using probabilistic simulation of combat (stochastic war gaming), and select scenario samples from this generated population.  (Recall that we are assuming in this Phase I prototype effort that the battle initial conditions have been specified, so that it is feasible to initiate the war-game model.)

 

            2. Formulate tactical combat as a time-sequential game, attempt to solve the game, and generate scenario samples by sampling from the optimal (solution) game strategies.  (By the term "strategy," we are referring to a "mixed" strategy, which is a probability distribution over a set of pure strategies, or decisions.)

 

            3. Formulate tactical combat as a resource-constrained two-sided allocation problem, using expected-damage functions that ignore (i.e., average over) battlefield dynamics.  Solve this optimization problem, and sample from the optimal strategies.  In other words, formulate battle plans based on the expected value of an objective function, averaging over dynamics.

 

            4. Develop an expert system for specifying scenarios (i.e., an automated computer system for generating scenarios by emulating experts).

 

III. Analysis of Alternatives; Selection of Preferred Alternative

 

All of the preceding system design candidates may be automated.  Most of the preceding alternative candidates can be implemented in ways that satisfy the requirement that it must be possible to define a parametrically described population of scenarios, and select samples of scenarios from that population.  Under Approach 4 (the expert system approach), however, a system would be developed that would produce scenarios according to sets of rules gleaned from scenario generation experts.  It is not clear, using this approach, how a well-defined sample space of scenarios would be specified.  For this reason, this approach to automated scenario generation was eliminated from further consideration.

 

Approach 1 (select samples of scenarios from a population of simulated war games) may appear to be appealing on the surface, but it is not considered feasible to implement, for several reasons.  First, many war game models require massive data preparation (set-up) efforts, and have very long running times, so that it is not feasible to generate large populations of war-game runs.  Furthermore, many are deterministic or require man-in-the-loop input, so that they are not amenable to generation of Monte-Carlo realizations of combat.  Next, although a wargame model could be used to develop battle plans, the running of a war game requires specification of the scenario initial conditions.  That is, this approach would solve only part of the problem of scenario generation (i.e., development of battle plans, but not specification of scenario initial conditions).  Finally, it is in general difficult to establish the validity of war game simulations, because of their substantial complexity.  The use of a war-game model as a basis for a scenario generation system would open the system to substantial criticism on the basis of difficulty of establishing system validity.  For these several reasons, it was not considered feasible to implement Approach 1 as a method for automatically generating scenarios.

 

Approach 2 is appealing on conceptual grounds, because the representation of combat as a time-sequential (dynamic, multistage) game has a high degree of face validity and has been accepted for a long time as a reasonable abstraction (mathematical representation) of combat.  The problem with this approach is that no practical means have been found for solving large-scale multistage games.  The method of dynamic programming breaks down because of the so-called "curse of dimensionality" (i.e., the solution running time becomes incredibly large for games involving more than just a few stages and state-vector components).

 

Having rejected Approaches 1, 2, and 4, we are left with Approach 3: consider combat as a two-sided resource-constrained allocation problem, solve the problem, and select samples from the space of optimal solutions.  Each sample is a scenario.  This approach is appealing, because it is based on a reasonable abstraction of combat.  The basic input to the method would be damage functions, that specify the expected damage to a target as a function of the (offensive and defensive) weapons allocated to the target.  This approach avoids the problem of solving a multistage game, and it avoids the massive computations associated with the use of war-game simulations of combat.

 

This approach can be implemented in a Bayesian-like context, by allowing the user to make judgment assessments of the expected damage.  It develops plans that are based on the best available knowledge about the expected damage, determined either from empirical evidence or from subjective judgment.  Its implementation does not require the use of a war-game simulation, but a war-game model (e.g., the RAND Analytic Modeling Platform of the RAND Strategy Assessment System) could be used to simulate the generated scenarios (i.e., war plans).  Such war-game simulations of generated scenarios could be examined for realism, prior to input of the scenarios into system evaluation models.

 

V. Specification of Top-Level Design

 

The recommended approach for implementation of an automated scenario generation system, then, is to formulate combat as a two-sided resource-constrained optimal allocation problem ("sequential move game"), to solve this optimization problem, and to select samples from the optimal strategy.  Each sample is a scenario.  The approach is conceptually feasible because, as is shown in Appendix F, the solution set (optimal strategy) for this problem is a probability distribution, i.e., there are an infinite number of optimal solutions, any one of which may be selected.

 

Figure E-1 presents a simplified system functional flow diagram that describes the top-level design for the automated scenario generation system.  In Phase II, additional, more detailed, representations of the system design will be developed (system architectures, functional representations, data flow diagrams, structure charts).

 

VI. Specification of Detailed Design for Prototype Model

 

In our proposal, we proposed to establish the feasibility of the concept of developing an automated scenario generation system by developing a simplified prototype model.  As discussed above, in this Phase I study we center our attention on the specification of a battle plan, after the scenario initial conditions (force sizes, targets, objectives) have been specified.  That is, the emphasis is on the development of optimal strategy and tactics.

 

Our proposed approach to the detailed design is to formulate combat as a two-sided resource-constrained optimization problem, or sequential-move game, and to determine the optimal strategies for each side for this game.  In a game, the optimal strategy specifies the probabilities of selecting specific actions (or decisions); in the current application, an "action" corresponds to the allocation of a specified number of weapons and interceptors to each target.  A battle plan is determined by selecting a specific probability sample of weapon/interceptor allocations, according to the probabilities of the optimal strategy.  

 

In order to solve this problem, it is necessary to specify the value of each target, and a damage function for each target, viz., a function that specifies what the probability of destruction (or fraction of value destroyed) is for each target, as a function of the number of weapons and interceptors allocated to the target.  For "hard" targets, an appropriate damage function is the "exponential damage function," which is described in Appendix F.

 

Appendix F presents a detailed mathematical specification of the two-sided resource-constrained optimization problem, and a solution.  The interesting feature of the optimal solution is that the attacker may attack each target at either of two levels -- a "low" optimal level or a "high" optimal level.  The optimal solution for a specified weapon stockpile is obtained by selecting any combination of low and high optimal attack levels that meets the weapon stockpile constraint.  This feature of the optimal attack strategy suggests a means for generating probability samples of scenario battle plans -- simply specify a probability of attacking each target at the high level, and select a sample of targets to attack at the high level, according to these selection probabilities.  This method for generating scenarios is implemented in a computer program, called OPTIMA, which is described and demonstrated in Appendix G. 

 

A functional flow diagram for the detailed system design is presented in Figure E-2, following the format of the top-level design presented in Figure E-1.

 

 


 

Figure E-1. Top-Level Design for Scenario Generation System (Functional Flow Diagram)

                                                      

                                                       

                                                          

                        Specify Scenario Type                         

                                    o Geographic Area                       

                                    o Scope, Scale, Duration,               

                                      Intensity of Conflict                 

                                    o Combat Objectives                     

                                                        

                                                       

                                                      

                        Specify Scenario Population Parameters      

                                    o No of Targets, Characteristics       

                                      (Value, Damage Function Parameters)                                            o No of Offensive Weapons of Each      

                                      Type

                                    o No of Defensive Weapons of Each

                                      Type

    

    

    

                        Specify Scenario Sample Design Parameters

                                    o Specify Sample Design or Experimental

                                      Design

                                    o If Sample Design, Specify

                                      Type of Sample Design (Simple Random

                                      Sample, Stratified, Multistage,

                                      Controlled Selection)

                                    o If Experimental Design, Specify

                                      Type of Experimental Design (Randomized

                                      Blocks, Fractional Factorial, etc.)

                                    o Specify Sample Sizes, Probabilities of

                                      Selection, Selection Methods

 

 

 

                        Determine Optimal Strategy/Tactic

           

 

 

                        Select Probability Sample of Plans

                          (Each Plan = Probability Sample from

                          Optimal Strategy/Tactic)

 

 


 

Figure E-2. Detailed Design for Plan Generation Subsystem of Prototype Scenario Generation System (Functional Flow Diagram)

                                                      

                                                       

                                                      

                        Specify Scenario Population Parameters      

                                    o No of Targets, Characteristics       

                                      (Value, Damage Function Parameters)                                            o No of Aircraft

                                    o No of Interceptors

    

    

    

                        Specify Scenario Sample Design Parameters

                                    o Specify Sample Sizes, Probabilities of

                                      Selection, Selection Methods as:

                                      Sample Size = 10; Probability of

                                      Selection = .5; Selection Method

                                      Binomial Sampling

 

 

 

                        Determine Optimal Strategy/Tactic

                                    o Determine Low and High Optimal Attack

                                      Levels for Each Target

                                    o Determine Probability of Attacking

                                      Each Target at High Optimal Level,

                                      in Accordance with Sample Design

                                      ( = .5)

           

 

 

                        Select Probability Sample of Plans

                          (Each Plan = Probability Sample from

                          Optimal Strategy/Tactic)

                                    o For Each Plan, Select Targets to

                                      Attack at High Optimal Level with

                                      Probability = .5

 


 

 

 

 

 

 

 

                                                                Appendix F

 

                              Optimal Attack and Defense for a Number of Targets

                                            in the Case of Imperfect Interceptors

 

 

Note: This appendix is an extraction, with some amplification and minor notational changes, of portions of the report: Caldwell, J. G., T. S. Schreiber, and S. S. Dick, Some Problems in Ballistic Missile Defense Involving Radar Attacks and Imperfect Interceptors, Report ACDA/ST-145 SR-4, Special Report 4, prepared for the US Arms Control and Disarmament Agency by the Lambda Corporation (subsidiary of General Research Corporation), McLean, Virginia, May 1969.  The results presented here were derived by Dr. J. G. Caldwell.  These results are presented here because they were never published in the open literature (refereed journals).  They form the basis for the Mission Planning Model presented in Appendix G.

            It is noted that, in the examples illustrated in Figures F-1 and F-2 of this appendix, the parameter values (i.e., the damage function parameters and interceptor kill probabilities) were specified to illustrate ballistic missile defense in strategic nuclear warfare.  The "weapons" of these examples were ballistic missiles, the "interceptors" were terminal defensive missiles, and the targets were cities (i.e., the target value was population and the damage function parameter values ("beta values") are representative of "soft" targets of varying value and extent).  Although the original application the model described in this appendix was strategic nuclear warfare, the mathematical representation (a two-sided resource-constrained optimization problem) is considered, for the reasons discussed elsewhere in this report, to be an adequate representation of aspects of tactical theater air warfare.  In applying the theory of this appendix to the prototype model of Appendix G, appropriate changes have been made to the model parameter values.  Specifically, the interceptor kill probabilities have been reduced to small values.  

 

 


 

                                                                Appendix F

 

                              Optimal Attack and Defense for a Number of Targets

                                            in the Case of Imperfect Interceptors

 

                                                           Table of Contents

 

 

            Summary . . . . . . . . . . . . . . . . . . . . . . F-1

 

I.          Introduction. . . . . . . . . . . . . . . . . . . . F-11

 

II.  An Expression for the Expected Damage . . . . . . . F-12

 

III. Procedure for Finding the Solution. . . . . . . . . F-13

 

IV.       Derivation of the Solution. . . . . . . . . . . . . F-14

 

V.        Characteristics of the Attacker's Optimal Solutions F-23

 

VI.       Characteristics of the Defender's Optimal Solutions F-25

 

VII.      Determination of Solutions Which Are Simultaneously

            Optimal for Both Attacker and Defender. . . . . . . F-27

 

VIII.Nature of the Solution as a Function of the

            Attacker's Lagrange Multiplier. . . . . . . . . . . F-32

 

IX.       Computer Program for Computing the Optimal Solution F-35

 

X.        Explicit Solution . . . . . . . . . . . . . . . . . F-36

 

            References. . . . . . . . . . . . . . . . . . . . . F-39

 


 

          Appendix F. Optimal Attack and Defense for a Number of Targets in the Case of Imperfect Interceptors

 

                                                                 Summary

 

This appendix describes the optimal defense of a set of targets against an optimal attack, in the case of imperfect interceptors.  The attacker and defender are assumed to know each other's total force sizes, and it is assumed that the attacker "moves last", i.e., the attacker allocates his weapons to targets after observing the defender's allocation of interceptors to targets.  A one-on-one (or fixed salvo-to-one) firing doctrine is assumed.  The attacker's goal is to maximize the total damage to the targets, and the defender's goal is to minimize this damage.  It is assumed that damage on any single target can be adequately described by the "exponential" damage function defined below.

 

A. Mathematical Description of the Problem

 

1. Notation

           

Let us denote the total number of weapons by X and the total number of interceptors by Y.  Further, let us denote the number of targets by t, and the number of weapons and interceptors allocated to the i-th target by xi and yi, respectively.  The attacker's and defender's strategies are hence specified by vectors

 

            x' = (x1, x2,..., xt)

 

and

 

            y' = (y1, y2,..., yt)

 

where each xi > 0, yi > 0, and

 

            S(i:1,t) xi = X

 

and

 

            S(i:1,t) yi = Y

 

where the notation S(i:1,t) denotes the summation operator over the index i, ranging from 1 to t.

Using the exponential damage function, the expected damage at the i-th target is

 

            Di(zi) = Pi(1 - exp(-bizi))

 

where zi is the number of weapons reaching the i-th target, Pi is the value of the i-th target, and bi is the damage function parameter for the i-th target.

 

The interceptor kill probability, K, is assumed to be the same for all targets.

 

The attacker is assumed to choose his strategy x after observing the strategy y selected by the defender.  He will choose a strategy x*(y) such that

 

            H(x*(y*),y) = max H(x,y),

                                                 x

 

where H(x,y) represents the total expected damage corresponding to the strategies x and y.  The defender hence must choose his strategy y* such that

 

            H(x*(y*),y*) = min max H(x,y) .

                                                 y   x

 

2. An Expression for the Expected Damage

 

Using the exponential damage function, the expected damage on the i-th target is shown in later in this appendix to be PiQi where 

 

                        1 - exp(-aixi)                                          , xi < yi

            Qi =

                        1 - exp(-bi(xi-yi)) exp(-aiyi)  , xi > yi ,

 

and ai < bi is defined by the equation

 

            exp(-ai) = (1 - K)exp(-bi) + K .

 

The total expected damage is

 

            H(x,y) = S(i:1,t) Hi(xi,yi)

 

                          = S(i:1,t) PiQi .

 

We shall denote the expected damage corresponding to the optimal solutions x*, y* as H(X,Y).

 

3. Procedure for Finding the Solution

 

Our problem, thus, is to determine x*,y* such that

 

 

            H(x*,y*) = min max H(x,y)

                                      y   x

where

 

            H(x,y) = S(i:1,t) PiQi

 

subject to the constraints

 

            S(i:1,t) xi = X

 

            S(i:1,t) yi = Y

 

and xi > 0, yi > 0.  The function H(x,y) is additively separable over the targets so the Everett-Pugh double Lagrange multiplier technique (References F-2 and F-3) can be used to find a solution.  The problem becomes one of finding xi, yi corresponding to

 

            min max (PiQi - Lxi + Myi)

             yi  xi

 

where L, M are adjusted so that the constraints

 

            S(i:1,t) xi = X

 

and

 

            S(i:1,t) yi = Y

 

are satisfied.  If there are several choices of (M,L) for which the constraints can be met (i.e., there are several solutions to the double Lagrange multiplier problem), the correct optimal solution to the problem is the solution corresponding the least damage.

 

For convenience we drop the subscript i, so that the problem is to find x, y corresponding to

 

            min max (PQ - Lx + My) .

             y   x

 

The solution is later in this appendix.  The next section will describe the results.

 

B. Description of the Solution

 

The solution to the above two-sided optimization problem is complicated to describe analytically, and can be described best in geometrical terms.  Such a description is presented later in this appendix.  In this section we shall present only a qualitative description of the optimal attack and defence allocations.

 

Note that the mathematical approach used to solve the present problem assumes that the xi's and yi's are continuous variables, rather than integers.  This approximation introduces a negligible error whenever the number of interceptors and weapons allocated to targets are zero or large enough that the fractional parts are insignificant.

 

The optimal solution can conveniently be described by observing how the weapon and interceptor allocations to targets change for a fixed total defense level, Y, as we very the total offense level, X, from zero to a very large number.  In all situations, weapons are allocated to targets so that the marginal payoff per weapon is the some on all targets.  Note that for a specified X, there may be some targets which, even if undefended, yield so little payoff to the attacker that they are not attacked.  Such targets are not defended, either.  For a specified total defense level, Y, there are two total attack levels, Xmin(Y) and Xmax(Y), that are of special significance.  We shall describe the nature of the solution in terms of these levels.

 

1. Low Attack Level (X < Xmin(Y))

 

When the attack level is less than the value Xmin(Y), every attacked target is defended by a number of interceptors which exceeds the number of weapons assigned to it.  Thus damage to targets can occur only through "leakage", i.e., failure of the interceptors to kill all incoming weapons.  The defense allocation is arbitrary, so long as there are more interceptors than weapons on each attacked target.  The attack allocation for specified X is unique.  The total payoff to the attacker is an increasing concave ("diminishing returns") function of the total attack level, X.

 

2. Intermediate Attack Level (Xmin(Y) < X < Xmax(Y))

 

For all attack levels lying between the values Xmin(Y) and Xmax(Y), the defense is unique.  Such a defense is called "stable".  In this region of attack levels, the attacker can choose between two different attack levels on each target.  The lower level may be zero on some targets.  The attacker must attack each target at either the lower level or the higher level, and can choose to attack at any combination of these permissible levels which meets his total attack level, X.  The payoff is a linear function of the total attack level in this region.

 

The situation in the case of the low and intermediate attack levels is referred to as "defense dominant".

 

3. High Attack Level (X > Xmax(Y))

 

As the total number of weapons is increased above the level Xmax(Y), the defender must change his allocation.  He does so by defending fewer targets, but defending the defended targets at a higher level.  As the attack size increases, eventually only one target would be attacked.  Since the defense allocation changes as the attack size changes in this region, the defense is called "unstable".  Both the attack and defense allocation corresponding to specified X are unique.

 

The situation in the case of a high attack level is called "attack dominant".

 

4. Qualification Concerning the Lagrangian Solution

 

The solutions to the present problem are derived by the method of generalized Lagrange multipliers.  Using this technique, we can find a solution for every total attack level X < Xmin(Y).  Over the range Xmin(Y) < X < Xmax(Y), however, there are only a finite number of Lagrangian solutions, corresponding to all possible combinations of low level or high level attacks on each attacked target.  For a large number of weapons, interceptors, and targets, there is a very large number of such solutions, and there would be a Lagrangian solution corresponding to a total attack size quite close to any specified total attack level.  Hence in practice we need only concern ourselves with the Lagrangian solutions.  (Solutions corresponding to other total attack levels differ very little from Lagrangian solutions corresponding to nearby total attack levels.  These other solutions are less "efficient" than the Lagrangian solutions, since the payoff function for them lies below the marginal payoff for the additional weapons used (beyond those required by the closest Lagrangian solution using fewer weapons) is less than the total marginal payoff achieved by going to the next higher Lagrangian solution.  This latter marginal payoff is defined by the slope of linear payoff function defined by the Lagrangian solutions.)

 

Over the range X > Xmax(Y), there can be found a Lagrangian solution for any specified total attack level, X, but not for every specified total defense level, Y.  The reason for this difficulty lies with the fact that, in the Lagrangian solution, a target can be defended at only two levels, one of which is zero (no defense).  (The situation is analogous to the intermediate attack situation in which targets could be attacked at only two levels.)  As before, this problem is not of practical significance, since we can always find a Lagrangian solution corresponding to a total defense level close to the specified total defence level.

 

C. Comparison of Solution in the Case of Imperfect Interceptors to that for Perfect Interceptors

 

It is of interest to compare how the nature of the solution to the allocation problem in the case of imperfect interceptors differs from the solution in the case of perfect interceptors.  Two questions of interest are:

 

            (1)  For what range of the kill probability, K, are the allocations and total damage essentially the same as for the perfect interceptor case, K = 1.

 

            (2)  For specified interceptor kill probability, K, and total defense level, Y, in the solution to the problem "similar" (in allocations and total damage) to the perfect interceptor problem with total defense level, KY.  (Note that KY is the expected number of interceptors which do not fail, and represents a possible "effective" number of perfect interceptors.)

 

The questions were answered by examining the nature of the solution for a "reasonable" set of hypothetical targets, described in Table F-1.

 

 

                                             Table F-1. Hypothetical Target Set

 

                                                               Target              Exponential Damage

            Target Number                         Value    Function Parameter (b)

                        1                                              10                                            .03

                        2                                              6                                              .04

                        3                                              4                                              .05

                        4                                              3                                              .06

                        5                                              2                                              .08

                        6                                              1.5                                           .10

                        7                                              1.0                                           .20

                        8                                              1.0                                           .30

                        9                                              1.0                                           .40

                10                                        .5                                            .50

 

 

The total expected damage, H(X,Y), corresponding to the optimal attack and defense allocations is plotted in Figures F-1 and F-2 as a function of total attack level, X, for fixed total defense level, Y.  Figure F-1 corresponds to Y1 = 400, and Figure F-2 corresponds to Y2 = 800.  On each figure are three curves:

 

            (1)  H(X,Yi) for K = 1

            (2)  H(X,Yi) for K = .75

            (3)  H(X,.75Yi) for K = 1.

 

The figures indicate first that there are substantial differences in total damage between K = 1 and K = .75 cases, and that the imperfect interceptor case is not always closely approximated by the perfect interceptor case for total defense level, KY.  However, the difference between these latter two cases is not so great as to preclude using the "equivalent perfect interceptor" approximation for some purpose.


 

I.  Introduction

 

This appendix derives the optimal defense of a set of targets against an optimal attack in the case of imperfect interceptors.  It is assumed that the defender has a total number, Y, of interceptors, and that the attacker has a total number, X, or weapons.  Let us denote the number of targets by t, and the number of weapons and interceptors allocated to the i-th target by xi and yi, respectively.  The attacker's and defender's strategies are hence specified by vectors

 

            x' = (x1, x2,..., xt)

 

and

 

            y' = (y1, y2,..., yt)

 

where each xi > 0, yi > 0, and

 

            S(i:1,t) xi = X

 

and

 

            S(i:1,t) yi = Y .

 

We assume that the exponential damage function adequately describes the expected damage at each target; that is, the expected damage is

 

            Di(zi) = Pi(1 - exp(-bizi)

 

where zi is the number of weapons reaching the i-th target, Pi denotes the value of the i-th target, and bi is the damage function parameter for the i-th target.

            We assume that the attacker "moves last"; i.e., he chooses his strategy, x, after observing the strategy y selected by the defender.  He will choose a strategy x*(y) such that

 

            H(x*(y),y) = max H(x,y)

                                        x

where H(x,y) represents the expected damage corresponding to the strategies x and y.  The defender, then, should choose his strategy y* such that

 

            H(x*(y*),y*) = min max H(x,y) = U .

                                                 y         x

 

The value U is the upper pure value of the game in which the attacker and defender move simultaneously.  Since x* and y* are pure strategies, there is no reason why U should equal the lower pure value of such a game, defined by

 

            L = max min H(x,y) .

                        x   y

 

Both the attacker and defender are assumed to know each other's force size and K.

 

We assume that the interceptor kill probability, K, is the same for all targets.

 

II.  An Expression for the Expected Damage

 

The expected damage on the i-th target if u weapons get through is given by

 

            Di(u) = Pi(1 - exp(-biu)) .

 

The probability that u weapons get through, given that there are xi weapons and yi interceptors, both integers, is

 

                                                A if 0 < u < xi and if xi < yi

 

            Pxiyi(u) =          0 if 0 < u < xi-yi and xi > yi

 

                                                B if xi-yi < u < xi and xi > yi

                                   

where

 

            A = C(xi,u)(1-K)u K(xi-u)

 

and

 

            B = C(yi,(u-(xi-yi))) (1-K)(u-(xi-yi)) K(xi-u) ,

 

and C(n,e) denotes the combination function (i.e., the number of combinations of n things taken e at a time).

 

The expected damage on the i-th target is hence

 

            Hi(xi,yi) = S(u:0,xi) (Expected damage given that u weapons

                                     get through) (Probability that u weapons get

                                     through)

 

                                    = S(u:0,xi) Pi(1 - exp(-biu))Pxiyi(u)

                                                                                                                       

                                    = PiS(u:0,xi) (1 - exp(-biu))Pxiyi(u)

                                                                                                                       

                                    = PiQi ,

 

where

 

                        A, xi < yi

            Qi =

                        B, xi > yi

 

where

           

            A = 1 - ((1-K)exp(-bi)+K)xi

 

and

            B = 1 - exp(-bi(xi-yi)) ((1-K)exp(-bi) + K)yi .

 

We shall use this expression for all xi, yi, not just for integral values.  We shall simplify the expression for Qi by defining

 

            exp(-ai) = (1 - K)exp(-bi) + K

 

where ai < bi since K < 1.  Hence we have

 

                        1 - exp(-aixi)                 , xi < yi

            Qi =

                        1 - exp(-bi(xi-yi)) exp(-aiyi)  , xi > yi .

 

The total expected damage is

 

            H(x,y) = S(i:1,t) Hi(xi,yi)

 

                          = S(i:1,t) PiQi .

 

We shall denote the expected damage corresponding to the optimal solutions x*, y* as H(X,Y).

 

III.  Procedure for Finding the Solution

 

Our problem, thus, is to determine x*, y* such that

 

            H(x*,y*) = min max H(x,y)

                                      y   x

 

where

 

            H(x,y) = S(i:1,t) PiQi

 

subject to the constraints

 

            S(i:1,t) xi = X

 

            S(i:1,t) yi = Y

 

and xi > 0, yi > 0.  Since the function H(x,y) is not concave, the Kuhn-Tucker theorem is of no assistance in computing the solution.  The function H(x,y) is additively separable over the targets, however, and so the Everett-Pugh double Lagrange multiplier technique (References F-2 and F-3) can be used to find a solution.  The problem becomes one of finding xi, yi corresponding to

 

            min max (PiQi - Lxi + Myi)

             yi  xi

 

where L, M are adjusted so that the constraints

 

            S(i:1,t) xi = X

 

and

 

            S(i:1,t) yi = Y

 

are satisfied.  If there are several choices of (L,M) for which the constraints can be met, (i.e., there are several solutions to the double Lagrange multiplier problem), the correct optimal solution to the problem is the solution corresponding to the least damage.  We shall for convenience drop the subscript i; that is, the problem is to find x, y corresponding to

 

            min max (PQ - Lx + My) .

             y   x

 

IV.  Derivation of the Solution

 

The damage function H(x,y) = PQ may be illustrated as in Figure F-3.

 

Let us denote

 

            g(x) = P(1 - exp(-ax))

 

and

 

            f(d,y) = P(1 - exp(-bd)exp(-ad))

 

where d = x - y > 0.  The we may write

 

                   g(x)    , x < y

            PQ = H(x,y) =

                                        f(d,y)  , x > y .

 

We distinguish three cases:

 

            Case 1:  g'(0) < L, f'(0,0) > L

class=Section3>

 

            Case 2:  g'(0) > L (which implies f'(0,0) > L

                                                            since a < b)

 

and

            Case 3:  f'(0,0) < L (which implies g'(0) < L

                                                            since a < b) ,

 

where the derivative of f(d,y) is with respect to d, as depicted in Figures F-4, F-5, and F-6.

 

A. Solutions for Case 1 and Case 3

 

Now Case 1 is a straightforward generalization of the problem solved by Goodrich (pp. 12 - 19 of Reference F-4).  Goodrich solved this problem in the case of perfect interceptors (K = 1), as depicted in Figure F-7.

 

The solution in Case 1 is as follows.  For specified y, consider the line passing through the origin and tangent to the damage curve (see Figure F-8).

 

Let us denote the slope of this line by L'(y), the value of x at the point of tangency by x', and denote d' = d' = x'-y.  Let us denote the value of x corresponding to slope L by xL, and denote dL(y) = dy = xL-y.  It is easy to show (see Goodrich) that the value of x which maximizes the Lagrangian function

 

            L(x,y) = H(x,y) - Lx + My

 

is

 

                 0   if L > L'(y) = L'

            x* =

                        xL  if L < L'(y) = L'

 

(either value, 0 or xL, may be chosen if L = L').  Denoting d'(y) = d' = x' - y, we have that

 

            f'(d',y) == L' = f(d',y)/(d' + y) ,

 

(where the differentiation is with respect to d and the double equal sign, ==, denotes "is identically equal to") and we may rewrite the optimal x-solution as

 

                  0            if L > f(d',y)/(d' + y)

            x* =

                         xL = dL + y  if L < f(d',y)/(d' + y) .

 

Note that if f'(0,0) < L (Case 3), then x* = 0, for then

class=Section4>

(since f'(d,y) < f'(0,0) < L) there is no point x such that f'(d,y) = L, regardless of the value of y).

 

Substituting the above solution x* into L(x,y), we obtain

 

                      My                             if L > f(d',y)/(d'+y)

            L(x*,y) =

                                    f(dL,y) - L(dL+y) + My if L < f(d',y)/(d'+y) .

 

Note that we have substituted dL + y for xL in the above, because we wish to represent y explicitly.  We wish to choose y to minimize L(x*,y).

 

It is interesting, but not necessary for the solution, to note that f(dL,y) depends only on L, in the case of the exponential damage function.  Now dL is defined by the equation

 

            f'(dL,y) = L

 

where the differentiation of f(d,y) is with respect to d.  Note that dL depends on y.  Since

 

            f(d,y) = P(1 - exp(-bd)exp(-ay)) ,

 

we have

 

            f'(d,y) = Pbexp(-bd)exp(-ay) ,

 

so that

 

            Pbexp(-bdL)exp(-ay) = L ,

so that

 

            f(dL,y) = P(1 - L/Pb) ,

 

which depends only on L.  Hence we could write

 

            f(dL,y) = f(L)

 

in the case of the exponential damage function.

 

This result if rather interesting, since if implies that the damage is the attacker's (heavier) optimal attack corresponding to the value L is the same, whether the defender chooses to defend the target or not (since the height of the damage function is the same (f(dL,0) = f(dL,y)) in either case).  (If, in the optimal attack against a defended target, the attacker has two attack options (e.g., 0 and xL), the no-defense damage (optimal attack) is the same as the damage at the heavier optimal attack level against the defended target.  We observe from the expression for f(L) that the fraction surviving the optimal attack is L/Pb.)

 

Continuing with the solution, we observe that we can write the Lagrangian function as

 

                      My                     if L > f(d',y)/(d' + y)

            L(x*,y) =

                                    f(L) - L(dL + y) + My  if L < f(d',y)/(d' + y)

 

 

                                    My                                              if y > f(d',y)/L - d'

                         =

                                    f(L) - L(dL + y) + My  if y < f(d',y)/L - d' .

 

Now the set

 

            S = {y │ y > f(d'(y),y)/L - d'(y)}

 

              = {y │ L > f(x'+y,y)/x'}

 

              = {y │ L > L'(y)} .

 

Now L'(y) = f(x'+y,y)/x' is a monotonic increasing function of y, and so

 

            S = {y │ y > y'}

 

where y' is the unique solution to the equation

 

            y = f(d'(y),y)/L - d'(y) .

 

Hence the Lagrangian becomes

 

                                    My                                               if y > y'

            L(x*,y) =

                                    f(dL,y) - L(dL+Y) + My  if y < y'

 

Since L(x*,y) is hence a piecewise linear function of y, the value of y that minimizes L(x*,y) occurs either as y = 0 or at the solution y = y' to the equation

 

            y = f(d'(y),y)/L - d'(y) .

 

Substituting these values into L(x*,y), we obtain

 

            L(x*,0) = f(dL(0),0) - LdL(0)

 

and

 

            L(x*,y') = My'

                       

                            = (M/L)(f(d'(y'),y') - Ld'(y')) .

 

To minimize L(x*,y), we hence choose

 

          0   if M > Lc

            Y =

                        y'  if M < Lc

 

where

 

            c = (f(L) - LdL(0))/(f(L) - LdL(y')) ,

 

and either value if M = Lc.  This corresponds to the solution obtained by Goodrich (where c = 1 in the case of perfect interceptors).  (The solution represents a "balanced defense", since the per-weapon payoff to the attacker is the same for all targets.)

 

B. Solution for Case 2

 

We now consider Case 2, in which g'(0) > L.  (This implies f'(0,0) > L. Observe also that f'(0,x) > g'(x).)  For specified y, consider the line tangent to the damage function in two places, as shown in Figure F-9.

 

We denote the slope of this line by L', and the values of x at the two points of tangency by x1' and x2'.  We define x1, x2, d1, d2, d1', d2' similarly, as shown in Figure F-9.  Since f'(0,x) > g'(x), we have x1' < y < x2'.  Since we are assuming that g'(0) > L, the value of x that maximizes  the Lagrangian function

 

            L(x,y) = H(x,y) - Lx + My

 

cannot occurs at x = 0.  Rather, the optimal solution is

 

                 x1  if L > L'

            x* =

                 x2  if L < L'

 

(either value if L = L').  That this is the optimal solution follows from the generalizated theory of Lagrange multipliers (Reference F-1).  Defining d1' = x1' and d2' - x2' - y, we have

 

                           

            L' == f'(d2',y) = (f(d2',y) - g(d1'))/(d2' + y - d1')

 

(where the differentiation is with respect to d2') so that we may write

 

 

class=Section5>

                  x1 = d1     if L > (f(d2',y)-g(d1'))/(d2'+y-d1')

            x* =

                         x2 = d2 + y if L < (f(d2',y)-g(d1'))/(d2'+y-d1') .

 

As in Case 1, we observe that f(d2,y) depends only on L in the case of the exponential damage function.  The Lagrangian function hence becomes

 

                  g(d1)-Ld1+My  if L > (f(L')-g(d1'))/(d2'+y-d1')

 L(x*,y) =

                         f(L)-L(d2+y)+My if L < (f(L')-g(d1'))/(d2'+y-d1')

 

                         g(d1) - Ld1 + My       if y > y'

                =

                         f(L) - L(d2 + y) + My  if y < y'

 

where, as in Case 1, we substituted d2 + y for x2 and where y' is the solution to the equation

 

            y = (f(L) - g(d1L))/L - (d2L(y) - d1L) .

 

Note that L(x*,y) is continuous at y = y'.  Since L(x*,y) is piecewise linear in y, the minimum occurs either at y = 0 or at the solution y = y' to

              

            y = (f(L) - g(d1L))/L - (d2L(y) - d1L) .

 

(It is easy to show that the function L(x*,y) is always positive for y positive.)

 

Calculating the value of L(x*,y) for these two values, we have

 

            L(x*,0) = f(L) - Ld2(0)

 

and

 

            L(x*,y) = g(d1) - Ld1 + My'

 

             = g(d1) - Ld1 + M((f(L)-g(d1))/L - (d2(y')-d1)).

 

To minimize L(x*,y) we hence choose y to be

 

                 0   if M > Lc

            y* =

                 y'  if M < Lc

 

where

 

            c = [(f(L)-g(d1))/L - (d2(0)-d1)]

                                                             / [(f(L)-g(d1))/L-(d2(y')-d1)],

 

and either value if M = Lc.

 

C. Summary of Lagrangian Solutions

 

Let us denote the attacker's optimal solution corresponding to y* by

 

            x* = x*(y*)

 

                     0 or x'     if y* = y'

                        =

                            x"                if y* = 0

 

for Case 1 targets, and

 

                           x1' or x2'  if y* = y'

                        =

                    x"            if y* = 0

 

for Case 2 targets.

 

Both x* and y* are zero for Case 3 targets; that is, the only targets worth attacking are those worth defending.  Note that, since f'(x,0) > g'(x) for small x, x" > x1' for small x1'.  Further, since f'(x - y,y) < f'(x - y,0), we have x" > x2' - y'.

 

An unfortunate aspect of the solutions obtained by the double Lagrange multiplier method is that, for specified resource levels (X and Y), there may be several solutions, corresponding to different values of the Lagrange multipliers (M and L).  While all such solutions are optimal for the attacker, only one of them is also optimal for the defender.  We shall refer to this latter solution as the "correct" optimal solution.  (The others are referred to as "spurious".)  The next three sections well describe the Lagrangian solutions in further detail, and which of them are optimal for both the attacker and the defender simultaneously (i.e., which combinations correspond to "correct" optimal solutions.)

 

V. Characteristics of the Attacker's Optimal Solutions

 

We shall now observe some properties of the attacker's optimal solutions.  The salient characteristic of the solution is that the attacker attacks each target at a level for which the slope of damage curve is the same (L).  It is noted that the defender either allocates no interceptors to a target, or y' interceptors to a target, where y' is the level such that the line of slope L tangent to the damage curve at the attack level x > y' either passes through the origin (in

class=Section6>

Case (1) in which g'(0) < L), or is also tangent to the damage curve at the attack level x < y' (in Case (2) in which g'(0) > L).  This situation is illustrated in Figures F-10, F-11, and F-12.

 

(Concerning Figure F-11: Since f'(0,x) > g'(x), there must exist d > 0 and y > 0 such that f'(d,y) = L in this case.  Note that x" > x1' holds only if x1' is small.)

 

(Concerning Figure F-12: Since f'(0,0) > g'(x), there is no x such that g'(x) = L.)

 

Note that the attacker chooses his solution after observing at each target whether the defender defends at level 0 or y'.  For reasons that will be explained later, the attacker can attack some targets at the low level (0 for Case 1 targets and x1' for Case 2 targets) only if the defender is defending all Case 1 and Case 2 targets at the higher level (y').

 

In summary, the optimal solution for the attacker has the following properties:

            1)  The marginal payoff to the attacker on all targets                       attacked is L.

            2)  On all defended "Case 1" targets, the ratio of damage to number of weapons is L; on all defended "Case 2" targets, the ratio of damage to number of weapons is greater than L, and this ratio is greater for the solution x1' than the solution x2'; on all undefended Case 1 or Case 2 targets, the ratio is greater than L.

 

VI.  Characteristics of the Defender's Optimal Solutions

If all Case 1 or Case 2 targets are defended, the total number,

 

            Ymax(L) == S yi'

 

where the symbol S denotes summation; if all Case 1 and Case 2 targets are defended, and attacked at the highest optimal level, the total number of weapons used is

 

            Xmax(Ymax(L)) == Xmax(L) = S x2i' ;

 

if all Case 1 and Case 2 targets are defended, and attacked at the lowest optimal level, the total number of weapons used is

 

            Xmin(Ymax(L)) == Xmin(L) = S x1i' ;

 

if all Case 1 and Case 2 targets are not defended, but are attacked at the optimal level, the total number of weapons used is

 

            X(Y,L)│Y=0 = X(0,L) == S x3i' ;

 

where we define

 

                   0 on Case 1 targets

 

            x1i' = x1' on Case 2 targets

 

                          0 on Case 3 targets

 

(corresponding to minimal attack, maximal defense);

 

                          x' on Case 1 targets

 

            x2i' = x2' on Case 2 targets

 

                          0 on Case 3 targets

 

(corresponding to maximal attack, maximal defense); and

                  

                                    x" on Case 1 or Case 2 targets

            x3i' =

                                    0 on Case 3 targets.

 

(corresponding to an attack against no defense).

 

The following characteristics of the defender's solution are noted:

            1.  For the complete defense, Y = Ymax(L), the attacker can choose not to attack any (or all) of the Case 1 targets or to attack any of the Case 2 targets at the lower level, x1', and the resulting deployments (attack and defense) are optimal at the new level x,

 

            Xmin(L) < X < Xmax(L) .

 

This characteristic results from the defender's having chosen the defense so that the tangent at slope L  passes through the origin (Case 1) or through both points of tangency (Case 2).  The attacker is thus indifferent to attacking at the level 0 or the level x' (Case 1), or to attacking at the level x1' or x2' (Case 2).  The damage increases linearly (with slope L) for all X, Xmin(L) < X < Xmax(L) (this will be proved later).

            2.  If the defender chooses not to defend some Case 1 or Case 2 targets, and the attacker also chooses not to attack some defended Case 1 targets or to attack some defended Case 2 targets at the lower level, then the resulting deployment is not optimal for the given resource levels, X and Y, even though the deployment would be the optimal one for the given values of L and M, if L and M represented true marginal costs of weapons and interceptors.  This paradoxical situation arises since, using the double Lagrange multiplier method, there may be many different values of L and M that correspond to the same resource levels.  (See Reference F-3 for a discussion of this point).  In the preceding situation, there would be a larger value of L which would correspond to the same total numbers of weapons and interceptors deployed.

 

The defense would prefer this latter deployment since it results in lower payoff to the attacker.  This follows since, for Xmin(L) < X < Xmax(L), the payoff to the attacker is the same per weapon (beyond the payoff of the "Xmin(L) weapons"):

 

            Payoff = L(X - X0).

 

For L1 < L2, the payoff L1X01 of the "Xmin(L1) weapons" is greater than the payoff L2X02 of the "Xmin(L2) weapons."  Also, L1X < L2X.  Hence

 

   Payoff for L1 = L1(X - X01) < L2(X - X02) = Payoff for L2.

 

Hence the defender would choose the deployment corresponding to L2.  Thus we see that the attacker can attack on the range Xmin(L) < X < Xmax(L) only if the defense is "complete" (i.e., the defender defends at level y' in all Case 1 and Case 2 targets).

 

VII. Determination of Solutions Which Are Simultaneously Optimal for Both Attacker and Defender

 

We shall now determine which solutions are simultaneously optimal for both the attacker and the defender.

A.  Correct Solution When Xmin(L) < X < Xmax(L)

 

In the preceding section, we showed that the pair (M,L) corresponding to the correct solution cannot correspond to a partial defense and a partial attack.  Rather, the correct (M,L) must correspond either to a complete attack, partial defense, or to a complete defense, partial attack.  We also provide that in the complete defense case, in which Xmin(L) < X < Xmax(L), if two different choices for (M,L) correspond to the same resource levels, the "better" solution corresponds to the larger value of L.  In view of the possibility of there being many different choices (M,L) which correspond to the same resource levels, it is necessary to answer the following question:  How is it possible to find (M,L) corresponding to the solution optimal for the specified resource levels?  Our objective is twofold:  (1) to make certain that the correct (M,L) pair is included among all (M,L) pairs identified as corresponding to the specified resource levels; (2) to test each such (M,L) solution to determine if it is optimal.

 

In view of the results of the preceding section, if the correct solution is included in the set of (M,L) pairs identified as meeting the constraint levels, then we will be able to select it in the complete defense case.  Thus our problem is solved for the complete defense case if we can prove that the correct solution is among those identified.

 

We can prove the correct solution is in fact included, by the following argument.  We will show that there is only one permissible choice of L corresponding to the complete defense case.  Since the correct solution must correspond to the complete defense case.  Since the correct solution must correspond to some choice of (M,L) which meets the resource constraints, and this choice is the only permissible one, it must then be the correct solution.  (There may indeed be other values of L which satisfy the resource constraints, but they will correspond to partial defenses and attacks, and hence to spurious solutions.)

 

Note that for values of L greater than max (Pi,bi), no weapons and no interceptors are allocated to any target.  Furthermore, as L is decreased to zero, the maximal number of weapons that are allocated increased monotonically (but discontinuously) from zero.  For M > L, no interceptors are allocated, and for all M < L, the allocation is the same (all Ymax(L) interceptors).  The upper interceptor limit increases monotonically (and continously) as L decreases.  Hence, if we are allocating for a complete defense, partial attack, there is only one value of L which will meet the defense level constraint.  Hence we have the correct solution (i.e., the solution which is simultaneously optimal for both attacker and defender) in the complete defense case (Xmin(l) < X < Xmax(L)).

 

B. Correct Solution When X < Xmin(L).

 

Note that there may be no choice of (M,L) corresponding to the specified defense and attack levels.  For example, in the complete defense, minimal attack situation, the minimal attack resource level may exceed the specified attack resource level.  In this case, we have no solution to the problem for the specified resource levels, by the Everett-Pugh double Lagrange multiplier technique.  It is nevertheless possible to determine an optimal solution in this case using the single Lagrange multiplier technique, by the following reasoning.  Consider the complete defense, minimal attack situation, in which the defender defends all Case 1 and Case 2 targets, and the attacker attacks all such targets at the minimal level (x1').  The attacker deploys Xmin(L) weapons in this case.  If the attacker wishes to use fewer than Xmin(L) weapons, he must allocate his weapons so that the marginal payoff per weapon is the same for all targets.  That is, he chooses a new value of L, greater than L', and chooses x' so that g'(x') = L'.  Clearly, he will attack all targets with a number of weapons that is less than x1', and hence less than the number of interceptors.  Since this is the case, the defender has no need to adjust his defense.  He can maintain the same defense no matter how many weapons (less than Xmin(L)) the attacker allocates, since in every case there are fewer weapons than defenders.  Additional interceptors have absolutely no effect on the payoff.  The problem hence reduces to one of simply allocating the attacker's weapons, using g(x) for the payoff function.  Since the total number X(L) of attackers allocated, given L, is a monotone decreasing function of L. this is easily accomplished.  Note that the defense can rearrange his allocation any way he pleases, so long as y > x on every target, and the resulting allocation is still optimal.  Only X(L) of the interceptors are actually needed.

 

Thus we have the correct solution in the case in which X < Xmin(L).

 

C. Correct Solution When X > Xmax(L)

 

The final case to consider is the complete attack case in which X > Xmax(L).  For a specified number of defended targets, both Y(L) and X(Y(L),L) increase as L decreases.  However, there may be several different numbers of defended targets for which L = L' can be chosen so that X(Y(L'),L') = X and Y(L') is close to Y.  (Owing to the discrete nature of targets, it in general will not be possible to meet the interceptor constraint exactly.)  In the unlikely event that Y(L') is the same for two different values of L', the better solution corresponds to the allocation resulting in least damage.  In general, however, we will have several possible solutions, each using a different number of interceptors and resulting in a different level of damage.  The correct optimal solution is the solution with Y(L') < Y which has least damage.  The situation is illustrated in Figure F-13.

 

For both Case 1 and Case 2 targets, the damage in the optimal attack (complete attack case) is a function of L only, i.e.,

 

            Damage = f(x-y,y) = f(L) = P(1-L/Pb).

 

We observe that the damage is a decreasing function of L.  Therefore, if there are several different L's for which the weapon constraint is met and for which the interceptor constraint is not exceeded, then the defender will choose the defense corresponding to the largest L.  Referring to Figure

class=Section7>

B-11, the optimal solution is hence the rightmost one (corresponding to total resource levels X, Y2), in which the maximum number of targets is defended.

D. Summary of Correct Solutions

 

A useful way to summarize the several preceding observations is to plot the payoff for optimal solutions corresponding to varying attack levels for a fixed defense level.  Such a plot is shown in Figure F-14.

 

Before summarizing the nature of the solutions corresponding to the different sections of this curve, we recall the nature of the Lagrangian solutions on the three types of targets.

 

For Case 1 targets, the defender chooses a number, y, of interceptors and the attacker chooses a number, x, of weapons, such that the tangent line to the damage curve at x is of slope L, and the tangent line passes through the origin.  (See Figure F-10.)  For Case 2 targets, the defender chooses y, and the attacker chooses x2 > y, so that the tangent line to the curve at x2 is also tangent at a point x1 < y; furthermore, this tangent line is of slope L.  (See Figure F-11.)  Case 3 targets are neither defended nor attacked.  (See Figure F-12.)

 

Not all of the points described above correspond to optimal solutions.  Depending on the circumstances (to be described) the attacker may be required to attack only at the higher level, or the defender may be required to defend only at the higher level.  We shall now describe the situation using Figure F-14, which depicts total damage, H(X,Y) as a function of X, for fixed Y.

 

In the first section of the curve, all Case 1 and Case 2 targets are defended, and all are attacked.  The defense is greater than necessary in this region, for there are more interceptors than weapons on each target.  The defense is some what arbitrary here; it can be rearranged in any fashion so long as there are always more interceptors than weapons on each target.  The attack corresponding to a specified X is unique.  Both the interceptor and weapon constraints are met exactly.

 

In the second section of the curve, all Case 1 and Case 2 targets are defended, and the defense is unique.  The attacker may attack each target at either the low level or the high level, and he does so in any fashion which enables him to meet his weapon constraint, X.  The interceptor constraint, Y, is met exactly, but the weapon constraint may only be approximated, owing to the discrete nature of targets.  (We refer to this error as the "small change" effect.)  Thus there are actually only a finite number of Lagrangian solutions along the linear portion of the curve corresponding to all possible combinations of attacks at the high or low attack levels on each target.  Payoffs corresponding to total attack levels lying between these points lie slightly below the line defined by the payoffs of the Lagrangian solutions.

 

The first two sections of the curve represent what is called a "defense dominant" situation.

 

In the third section of the curve, all Case 1 and Case 2 targets are attacked at the higher level, but only a subset of the Case 2 targets are defended.  The defended targets have the following property.  Let L denote the value of the (attacker's) Lagrange multiplier in the optimal attack.  Suppose, now, that no targets were defended, and that this same value of L were used to determine the number of weapons to be allocated to each target.  Let us denote the damage to the i-th target in such an attack by Di, and the number of weapons by Ni.  Consider the ratio Ri = Di/Ni.  If all Case 1 and Case 2 targets are arranged in decreasing order of Ri, then the defended targets of the optimal attack are at the beginning of this list.  In other words, the defender defends targets in decreasing order of their undefended damage per weapon.

 

Both the defense and the attack are unique in this section of the curve.  The weapon constraint is met exactly, but the interceptor constraint may only be approximated.  This section of the curve represents the "attack dominant" situation.

 

In the third section of the curve, there may be several different values of L, corresponding to different numbers of defended targets, which enable us to meet the weapon and interceptor constraints.  The defender naturally chooses the defense allocation which corresponds to the least damage.  In the present problem, this happens to the solution corresponding to the largest value of L, since in the attack dominant case the damage on the i-th target is given by

 

            Pi(1 - L/Pibi) .

 

VIII. Nature of the Solution as a Function of the Attacker's Lagrange Multiplier                                                                     

 

It is of some interest to describe the nature of the solution as a function of the Lagrange multiplier L.  We summarize the situation in Figure F-15 through F-19 (ignoring the "small-change" effect caused by discrete targets).

 

class=Section8>

Figures F-16 and F-17 illustrate the ranges of total defense and attack levels corresponding to optimal attacks for different values of L.

 

Note that it is not possible to obtain an optimal solution for every choice of X and Y, by the method of double Lagrange multipliers.  If Y is very large and X is very small, there may be no value of L for which Xmin(L) < X and Y < Ymax(L).  (This region is called a "gap".  Regions such as this, which are inaccessible by the Everett-Pugh Procedure of min-maxing the Lagrangian function (as opposed to zeroing its derivative, in the case of continuously differentiable functions), represent "inefficient" solutions.  (See Reference F-2 for a discussion of gaps.)  As discussed previously, however, we were able in the present problem to find an optimal solution over this gap.  (Another type of gap occurs since the discrete nature of targets prohibits meeting both resource levels exactly.  This "small change" effect is generally small, however, for problems involving several targets and large numbers of weapons and interceptors.)

 

Figure F-18 is a plot of the payoff (denoted by H(X,Ymax(L))) corresponding to all possible optimal attack levels, for constant L and Y = Ymax(L).  (This plot is simply the middle section of Figure F-14.)

 

Figure F-19 is a plot of the payoff (denoted by H(X(Y,L),Y)) corresponding to all possible optimal defense levels, for fixed L.

 

The plot of Figure F-19 is a level line since f(dL,y) = (dL,0), as discussed previously.

 

IX. Computer Program for Computing the Optimal Solution

 

In view of the preceding characteristics of the optimal solution, a reasonable procedure for finding the optimal solution (corresponding to S xi = X, S yi = Y) is the following:

            1.  Determine the largest value of L such that Ymax(L) = Y.  Compute Xmin(L) and Xmax(L).

            2.  Complete defense, partial attack case.  If Xmin(L) < X < Xmax(L), then the optimal solution is obtained by attacking a sufficient number of the (Case 1 or Case 2) targets at the higher level (x2i') to satisfy the weapon constraint, X.  (Any such collection of targets is satisfactory.  This is the case since the additional damage caused in going from x1i' to x2i' weapons on the i-th target is L(x2i' - x1i').  Thus the additional damage caused by the x2i' - x1i' weapons, above the damage caused by the x1i' weapons, is the same linear function of the additional weapons allocated, for all targets.)  Since weapons are allocated to targets in groups, it will in general not be possible to meet the weapon constraint exactly.

            3.  Complete attack, partial defense case.  If X > Xmax(L), then decrease L to the largest value of L such that Xmax(L) = X.  An optimal solution is obtained by defending a sufficient number of the (Case 1 or Case 2) targets to satisfy the interceptor constraint, Y.  The targets to be defended must be selected in order of decreasing ratio in the no-defence case, of damage to weapons, until Y interceptors are used.  Unfortunately, however, if some defendable targets are not defended, then fewer weapons are allocated (see Figure F-11).  Hence our weapon constraint is not met.  We must hence decrease the value of L (giving us new values of Ymax(L) > Y and Xmax(L) > X), and choose a new set of targets to be defended.  As before, we select targets to be defended in the (new) order of decreasing ratio, in the no-defense case, of damage to weapons, until Y interceptors are used.  We compute, for this defense allocation, the corresponding number, X(Y), of weapons.  We decrease L until X(Y) = X.  Since interceptors are allocated to targets in groups, it will in general not be possible to meet the interceptor constraint exactly.  There may, however, be a number of different solutions (corresponding to different numbers of defended targets) using fewer than Y interceptors, and we should choose the one resulting in least damage (largest L).

            4.  Complete attack, unnecessarily large defense.  If X < Xmin(L), no solution can be found by the method of double Lagrange multipliers.  Either fewer than Y interceptors must be used, or more than X weapons must be used, to obtain an optimal solution by this method.  To find the optimal solution for the specified Y, we instead use the single Lagrange multiplier method, and proceed as follows.  Accept the defense allocation corresponding to Xmin(L), Ymax(L) = Y.  Then, increase the value of L, and compute the corresponding attack allocation.  Denoting the number of weapons deployed by X(L), adjust L so that X = X(L).  This allocation is the optimal attack allocation.  Denoting the number of weapons deployed by X(L), adjust L so that X = X(L).  This allocation is the optimal attack allocation.  Any defense allocation for which the number of interceptors on each target exceeds the number of weapons is optimal.  Hence, in particular, the defense allocation corresponding to X = Xmin(L), Y = Ymax(L), is optimal.

 

A computer program has been written to perform the above computations.

 

X. Explicit Solution

 

The derivation presented above of the optimal solution includes a number of implicit relationships.  The solution will now be explicitly derived.

 

Case 3.

 

If f'(0,0) < L, no weapons or interceptors are allocated to the target.

 

We have

 

            f(d,y) = P(1 - exp(-bd)exp(-ay))

 

so that

 

            f'(d,y) = Pbexp(-bd)exp(-ay)

 

and

 

            f'(0,0) = Pb .

 

Thus if Pb < L, no weapons or interceptors are allocated to the target.

 

Case 1.

 

In this case, Pb > L and g'(0) < L.  We have

 

            g(x) = P(1 - exp(-ax))

 

so that

 

            g'(x) = Paexp(-ax)

 

and

 

            g'(0) = Pa .

 

Thus if Pa < L, the situation is that of Case 1.  In this case, we wish first to determine x,y > 0 such that the tangent line at the point x is of slope L and passes through the origin.  That is, find x,y such that

 

            f'(x - y, y) = L

 

and

 

            f(x - y,y)/x = L.

 

The first relation implies

 

            Pbexp(-b(x - y)exp(-ay) = L

 

or

 

            exp(-b(x - y))exp(-ay) = L/Pb .

 

Substituting this into the second relation, we have

 

            P(1 - L/Pb)/x = L

 

or

 

            x = P(1 - L/Pb)/L .

 

The first relation then yields

 

            y = (ln(L/Pb) + Bx)/(b - a).

 

If y = 0, then x must satisfy

 

            f'(x,0) = L

 

i.e.,

 

            Pbexp(-bx) = L

 

or

            x = (-1/b) ln(L/Pb) .

 

Case 2

 

Case 2 corresponds to Pa > L (Pb > holds since a < b).  In this case, we wish first to determine x1, x2, and y, where x1 < y < x2, such that the tangent line at the point x2 is of slope L, the tangent line at the point x1 is of slope L, and these tangent lines are in fact the same line.  That is, we want x1, x2, y such that

 

            g'(x1) = L

 

            f'(x2 - y,y) = L

 

            (f(x2 - y,y) - g(x1))/(x2 - x1) = L.

 

The first relation yields

 

            exp(-ax1) = L/Pa

 

or

 

            x1 = -(1/a)(ln(L/Pa)) .

 

The second relation yields

 

            exp(-b(x2 - y))exp(-ay) = L/Pb .

 

Substituting the first two relations into the third hence yields

 

            (P(1 - L/Pb) - P(1 - L/Pa))/(x2 - x1) = L

 

or

 

            x2 = x1 + 1/a - 1/b .

 

The second relation yields

 

            y = (ln(L/Pb) + bx2)/(b - a) .

 

In the case in which y = 0, we wish to find x such that

 

            f'(x,0) = L.

 

As is Case 1, we obtain

 

            x = -(1/b)(ln(L/Pb)) .

 

 

References

 

F-1.  Hugh Everett, III, Defense Models XI:  Exhaustion of Interceptor Supplies, Lambda Paper 17, Lamdba Corporation, Arlington, Virginia, 1968. (Lambda Corporation later became a subsidiary of General Research Corporation, McLean, Virginia.)

 

F-2.  Hugh Everett, III, "Generalized Lagrange Multiplier Method for Solving Problems of Optimum Allocation of Resources," Operations Research, 11:399-411, 1963.

 

F-3.  George E. Pugh, "Lagrange Multipliers and the Optimal Allocation of Defense Resources," Operations Research, 12:543-567, 1964.

 

F-4.  Robert L. Goodrich, Defense Models V:  Ivan II, A Detailed Model for Preferential Defense, Lambda Paper 7, Lambda Corporation, Arlington, Virginia, 1968.

 


Appendix G. Mission Planning Model

 

I. Introduction

 

The model presented in this appendix generates missions by selecting probability samples of targets from a list of candidate targets, and allocating weapons to those targets in a fashion that maximizes the total target damage.  The purpose of developing the prototype mission planning model of this appendix is to demonstrate that it is possible to generate sets of mission plans that are probability samples from a well-defined population of mission plans.  By accomplishing this objective, we demonstrate the feasibility of the concept of developing probability samples of full-blown scenarios.

 

The model presented here is developed solely to illustrate the feasibility of the concept of identifying a population of missions and a probability scheme for sampling from that population.  The model assumes that a list of candidate targets is available, i.e., that the scenario initial conditions are given.  In the Phase II effort, a means would be developed to generate such target lists.  In accordance with operational experience, it is assumed that the candidate target list contains more targets than resources are available to completely protect or destroy, so that it is reasonable to represent the situation as a two-sided resource-constrained optimal allocation problem.  Further, since targets vary in value and vulnerability, and since the damage is a nonlinear function of the number of weapons and interceptors allocated to a target, this optimization problem is a nonlinear one.

 

The example presented here is a simple one, in which the only constraints considered are constraints on the total stockpiles of weapons and interceptors (denoted as X and Y, respectively, in the notation of Appendix F).  The defender's objective is to allocate his interceptors in a fashion to minimize the total damage on all targets; the attacker's objective is to maximize the total damage.  Phase II extensions of the model will introduce additional complexity into the model, in accordance with the detailed requirements specification to be developed at the beginning of Phase II.

 

This prototype example is based on a conceptual model of battle as a two-sided sequential-move resource-constrained game.  This formulation is advantageous from the point of view of implementation of a prototype model, since the solution is readily obtained using the method of Generalized Lagrange Multipliers (as shown in Appendix F).

 

Although the sequential-move formulation is readily implemented, it does have some drawbacks.  First, in some applications it may be argued that the attacker does not have prior knowledge of the defense allocation.  This assumption may be more reasonable for ballistic missile defense than for tactical air warfare.  Second, in some cases the sequential-move solution yields a single, nonstochastic solution, i.e., the optimal solution is a fixed weapon/interceptor allocation, rather than a probability distribution.  This occurs, for example, in the case in which there is no defense (i.e., no interceptors).  Of course, this case is not very interesting from a game-theoretic (or a military) viewpoint, since player 2 (the defender) has no options.

 

Apart from this trivial case, however, it is nevertheless the case that, using a sequential-move battle concept, the different members of the set of optimal attack strategies (i.e., attack options) do not vary very much, if the interceptor kill probability is small.  In this case, an additional step is necessary to obtain a probabilistic (randomized) strategy for which the attacker's options possess a reasonable degree of variation.  One approach (which is described below) is to select the targets for a mission using probability sampling from a large list of targets (i.e., a list that contains more targets than can be struck in a single mission).  Another is to reformulate the conceptual framework to consider battlefield combat as a simultaneous-move game, i.e., one in which the attacker does not know the defense allocation prior to determining his weapon allocation.  Which conceptual framework is most appropriate will depend on the specific application for which scenarios are needed.

 

For the purpose of establishing the feasibility of the concept of generating probability samples of scenarios, it does not really matter whether we view combat as a sequential-move game or a simultaneous-move game.  The point is to demonstrate that the concept of generating probability samples is feasible, in the context of some reasonable conceptual representation of the battlefield.  That goal has been achieved in this Appendix, by means of a prototype model based on a sequential-move concept of battle.  Phase II will consider the conceptual basis further, and may adopt a different conceptual framework.  It a different conceptual framework is adopted, the method for determining optimal strategies under that concept may change (e.g., use of the Brown-Robinson method of fictitious play to determine randomized strategies for a simultaneous-move game, rather than the method of Appendix F).

 

II. Mission Planning Model

 

The Mission Planning Model (MPM) begins by determining the optimal allocation of weapons and interceptors to targets.  This optimal allocation is determined using the Generalized Lagrange Multiplier (GLM) optimization procedure described in Appendix F.  The interesting feature of the optimal allocation is that, as a result of the fact that interceptor reliability (kill probability) is less than unity, on some targets there may be two different attack levels which are both optimal.  This situation occurs in cases in which the attack and defense stockpiles are of comparable size.  These two optimal attack levels both provide the attacker with the same marginal "return" of damage per weapon expended; he is therefore indifferent concerning which level he chooses (as long as the total weapon allocation over all targets is within his weapon stockpile).  

 

Two Schemes for Selecting Probability Samples of Missions. In general, if the interceptor kill probability is low, the two optimal attack levels do not differ very much -- the low optimal level is just a little less than the high optimal level.  If the interceptor kill probability is high, however, the low and high optimal levels may be very different.  The fact that the nature of the optimal allocation differs substantially depending on the value of the interceptor kill probability suggests two different schemes for selecting probability samples of optimal attack allocations. 

 

In the case in which the interceptor kill probability is large, it is proposed to use a sampling scheme in which the attacker decides by probability sampling whether to attack a target at the high or the low level.  In this approach, we specify the probability that the high optimal level is selected.  Let us denote this sampling scheme as Scheme A.

 

In the case in which the interceptor kill probability is small, it is proposed to use a sampling scheme in which the attacker decides by probability sampling whether to attack a target at the high level, or not to attack it at all.  In this approach, we specify the probability that the target is selected.  Let us denote this sampling scheme as Scheme B.

 

Note that for both Schemes A and B, the size of the weapon stockpile used in the attack depends on which targets or target attack levels (high-optimal or low-optimal) are selected for the sample.  That is, the sample allocation does not necessarily involve the same total number of weapons and interceptors as were specified as constraints in the original allocation problem prior to sampling.  Let us refer to the weapon and interceptor stockpiles associated with a sample target sets as "reduced" stockpiles.

 

Both Scheme A and Scheme B result in an optimal allocation of the reduced stockpiles over the sample target set.  This was proved explicitly for Scheme A, in Appendix F, since the sample target set is the full target set.  For Scheme B, the result also holds for the sample target set, using the same allocation to each sample target as was determined in solving the allocation problem for the full target set, since the marginal payoff on each target of the sample set is identical.  The optimal allocation process of Appendix F produces a set of targeting opportunities to which the attacker is indifferent, from the point of view of damage produced per weapon allocated.  (Note that although the allocation is an optimal allocation of the reduced stockpile over the sample set, it is not an optimal allocation of the reduced stockpile over the full target set.  Although this is true, it is immaterial.  The allocation over the sample set is optimal, conditional on the particular selection of targets that constitute the sample, and for total resource expenditures (of weapons and interceptors) equal to those allocated in the sample target set.)

 

Sampling Scheme B may be more practical than Scheme A for tactical theater aircraft applications, since it involves fewer targets, and may be tailored to situations in which the mission size (in terms of number of targets attacked) is constrained.

 

For tactical air warfare applications involving manned attack aircraft against surface-to-air missiles, the interceptor kill probability is low, and so Scheme B applies.  Scheme A applies to situations for which the interceptor kill probability may be substantial.  (In particular, Scheme A applies to problems in ballistic missile defense.  This case is included in this appendix because of the goals and guidelines of the SBIR program, under which this Phase I effort was funded.  Specifically, the likelihood of obtaining Phase II funding for an SBIR proposal is enhanced if widespread applicability or general utility of the concept can be established, i.e., if it can be shown that there exist applications additional to those solely of interest to the organization that funded Phase I.)  Scheme A could apply to the case of attack aircraft against aircraft interceptors.

 

A variety of probability sampling methods could be used to select targets from the candidate target list.  In the model formulation used here, binomial sampling is used as a basis for the selection  In binomial sampling, the selection of a high level at one target is stochastically independent of the selection at any other target; in this case the number of targets struck at the high optimal level is a random variable.  Under another sampling approach, the analyst may wish to specify the total number of targets to be included in the sample; in that case the targets could be randomly permuted (arranged), and the targets selected for the sample in order from the permutation, up to the number desired for the sample.

 

In the formulation presented here, the binomial sampling approach is used.  From an operational viewpoint, a selection method in which the total number of sample targets may be controlled may be more helpful in assisting mission planning than a method in which the sample size is a random variable.  Since the purpose of developing the mission generation model presented in this appendix is simply to demonstrate feasibility of developing a method for generating probability samples of missions, however, no effort was expended in attempting to introduce additional operational realism in the model.

 

Note that it is not sufficient merely to select probability samples of targets to establish feasibility for the automated scenario generation application.  The essential feature of the prototype model presented here (with respect to the issue of establishing feasibility of an automated scenario generation system) is that those probability samples represent optimal allocations.  In this prototype, the population of optimal allocations represents the population of scenarios.  By demonstrating that it is feasible to generate probability samples of missions, we establish the feasibility of generating probability samples of scenarios.

 

II. The OPTIMA Computer Program

 

A computer program, called OPTIMA, was written to implement the Mission Planning Model.  The OPTIMA model conducts all of the computations necessary to determine the optimal solution to the two-side resource-constrained optimal allocation problem described and solved in Appendix F.  In addition, the OPTIMA model implements the sampling schemes (A and B) described above, for selecting probability samples of optimal allocations.

In the current version of the prototype model, the sampling schemes are implemented only for the "stable defense" case, in which the weapon and interceptor stockpiles are of comparable magnitudes.  (Note: For strong-defense attacks and saturation attacks, there is only one optimal attack level.  For this reason, only sampling scheme B would be applicable.)

 

This appendix includes two sample runs of the OPTIMA program, using a hypothetical candidate target list consisting of t=10 targets.  The damage function used in this model is the so-called exponential damage function, which is appropriate for "hard" targets.

 

Two sample runs are presented -- one for the case of low interceptor kill probabilities (e.g., attack aircraft and surface-to-air missiles), and one for the case of high interceptor kill probabilities (e.g., attack aircraft against aircraft interceptors, or ballistic missile attack and defense).

 

In the sample runs, a total of 10 different samples of targets is selected.  The samples are selected in the case of a stable defense, in which the attack and defense levels are comparable.  Since binomial sampling is used, the number of targets selected to strike at the high optimal level varies.  In an evaluation, the analyst could conduct a performance evaluation for each of these 10 different samples, and determine point estimates and confidence intervals for system performance from the sample results.  These estimates would apply to the population of optimal attacks against the candidate target set, corresponding to the (sample of) expended weapon and interceptor levels.

 

The sample runs of OPTIMA are presented at the end of the text of this appendix, followed by a listing of the FORTRAN code of the OPTIMA program.  The output of the sample runs is presented in Figures G-1 and G-2; the OPTIMA computer program listing is presented in Figure G-3.

 

III. Description of OPTIMA Output

 

The following pages present sample output of the OPTIMA program, which implements the Mission Planning Model.  Two different examples are presented, corresponding to high and low values for the interceptor kill probability.  Example 1 considers the case of interceptor kill probability equal to .75; this parameter value could apply, for example, to the case of attack aircraft against aircraft interceptors, or to ballistic missile defense.  Example 2 considers the case of interceptor kill probability equal to .01; this parameter value is relevant to the analysis of theater tactical air warfare against surface-to-air missiles, in which the "weapons" of the model would correspond to attack aircraft, and the "interceptors" of the model would correspond to surface-to-air missiles.

 

In order to assist review and evaluation of the methodology presented in this report, in particular that of Appendix F, we have matched the Example 1 run of the OPTIMA program to one of the examples discussed in Appendix F.  Specifically, the case considered in Example 1 corresponds to an example illustrated in Figure F-1 of Appendix F.

 

In both examples, the target set presented in Table F-1 of Appendix F is used.  This target set is small, but it serves to illustrate the concepts involved.

 

Example 1: Interceptor Kill Probability = .75

 

The first item on the output listing (Figure G-1) is a list of the 10 targets of the example.  Each target is identified by an identification number (1-10), a value (ranging from .5 to 10 in the example), and a damage function parameter, beta (ranging from .03 to .5 in the example).

 

The next item in the output listing is the interceptor kill probability (K=.75) and interceptor salvo size (1).

 

The output presented in Figure G-1 includes three different weapon stockpile levels (X=50, 400, and 600) and a single interceptor stockpile level (Y=400).  These three cases correspond to three different regions of the total damage curve.  The case X=50, Y=400 corresponds to a "strong defense"; in the optimal attack, there are more interceptors than weapons on every target.  The only damage occurs from "leakage," which occurs when a weapon reaches a target because of interceptor failure.  The case X=600, Y=400 corresponds to the "unstable defense" described in Appendix F.  In this case, called a "saturation attack" on the printout, there are more weapons than interceptors on every target.  The third case, X=400, Y=400, corresponds to a "stable defense."   This case occurs in a region of the total damage curve that is linear in the attack size (X).

 

We continue with a description of the printout corresponding to the strong defense case (X=50, Y=400).

 

The next line of the printout specifies parameters that control the termination of the Lagrange multiplier optimization procedure.  The optimization procedure works by iteratively adjusting the value of the Lagrange multiplier.  For each value of the Lagrange multiplier, the program computes the corresponding total number of weapons allocated.  If that total is too large, the value of the multiplier is increased; it the total is too small, the value of the multiplier is decreased.  This process continues; with each iteration, the weapons allocated approaches the desired weapon stockpile.  This process terminates when the difference between the total weapons allocated and the total weapon stockpile constraint is less than "epsilon-x."  The value of epsilon-x is specified in the printout (.001 in the example).  The parameter epsilon-y controls the termination of the interceptor convergence in a similar fashion.

 

The next line of the printout is the total value of all targets.

 

The next line is the interceptor salvo kill probability.

The next line indicates the nature of the solution -- a strong defense, saturation attack, or a "stable defense."  (We are now in the process of describing the strong defense case.)

 

The next line is the value of the attacker's Lagrange multiplier, corresponding to the optimal solution.  The attacker's Lagrange multiplier specifies the marginal payoff (damage) per weapon expended at the optimal solution (i.e., the amount of increase in damage per unit increase in weapon stockpile).

 

Next follows a table that summarizes the optimal allocation.  Columns one, two, and three simply repeat a listing of the target-set parameters (target number, target value, and target damage function parameter, or "beta").  The next two columns specify the number of weapons and interceptors allocated to the target.  The next column ("Value Dest") indicates the expected portion of the target that is destroyed, according to the damage function, given the number of weapons and interceptors allocated to the target.  The final column ("Frac Dest") specifies this damage as a fraction of the target value.

 

Following the table is the total damage ("Total Value Destroyed") to all targets associated with the optimal allocation of weapons and interceptors, and the total damage expressed as a fraction of the total target value ("Fraction Value Destroyed").

 

This completes the description of the output for case 1 (X=50, Y=400).

 

The next section of the printout specifies the same information as described above, but for case 2 (X=600, Y=400).  This attack is a saturation attack.

 

The next section of the printout specifies the same information as described above, for case 3 (X=400, Y=400).  There are two tables presented in this section, one table corresponding to the attack levels at each of the two ends of the linear region of the total damage curve (plotted as a function of the total number of weapons allocated).  In this example, these two attack levels are Xmin(L) = XMINL = 122 and Xmax(L) = XMAXL = 513.  (The desired weapon stockpile, x=400, lies within the linear region, i.e., between 122 and 513.)  The "fraction value destroyed" corresponding to these two attack levels are .23 and .81, respectively.  Note that the two points (122,.23) and (513,.81) define the endpoints of the linear portion of the topmost damage curve in Figure F-1.  The equation for this linear segment is next printed out, and the fraction value destroyed corresponding to the specified attack level (in this case, X=400) is also printed (in this case, .64).

 

The next section of the printout specifies ten samples of targets.  Each sample is itself an optimal allocation, for the number of weapons and interceptors used in the sample.  In the program, the user has the option of specifying the type of sampling used to select the target samples.  In this example, since the value of the interceptor kill probability is large (i.e., K=.75), we have specified the sampling method in which the attacker chooses to attack at the high optimal level on each target with probability .5, and to attack at the low optimal level also with probability .5.

 

For "Sample No 1," eight of the ten targets were randomly selected to be struck at the high optimal level.  The targets to be struck at the high level are indicated in the last column of the table, titled "IHIGH."  If IHIGH has the value "1," the target is struck at the high optimal level; if IHIGH has the value "0," then the target is struck at the low optimal level.

 

The number of targets struck at the high optimal level is a random variable, that varies from sample to sample.  The numbers of weapons and interceptors expended are also random variables, which will vary between XMINL and XMAXL.  For Sample No 1, the number of weapons expended is 496 and the number of interceptors expended is 388.

 

The form of the printout for the next nine samples is identical to that for Sample No 1.

 

Example 2: Interceptor Kill Probability = .01

 

Figure G-2 presents the sample run for an example in which the interceptor kill probability is small (.01).  The form of the printout is the same as in Example 1.  The only difference between the two examples is in the specification of the method of sampling.  In Example 2, the sampling method selects targets to strike at the high optimal level according to a specified probability; those targets that are not selected are not struck at all (i.e., no weapons are allocated to them).

 

IV. Summary

 

The Mission Planning Model described in this appendix generates samples of missions, given the forces and targets available prior to the battle, i.e., given the scenario initial conditions.  In Phase II, a means would be developed (in the design task) to generate candidate target lists corresponding to different scenarios.  The procedures for developing different scenario initial conditions will be developed in Phase II.

 

The model presented in this appendix, although simple, demonstrates the feasibility of using probability sampling to generate scenario battle plans in the context of tactical theater air warfare.  Specifically, the MPM generates tactical air missions, defined in terms of designated target sets.  The model represents tactical air combat as a resource-constrained two-sided optimization problem (sequential-move game).  The significance of this formulation is that it produces probability samples of missions that can be used to make statistical inferences about a well-defined mission population (i.e., the population of missions that are optimal for both the attacker and the defender).  The inferential basis of the mission samples is well-defined.  The Phase II effort will extend the research to the specification of scenario initial conditions and the introduction of additional realism into the model.

 

Here follows a listing of the OPTIMA computer program (in FORTRAN IV code).

 

      PROGRAM OPTIMA

C  AUTHOR: DR. J. GEORGE CALDWELL, DIRECTOR

C  VISTA RESEARCH CORPORATION

C  3826 SNEAD DRIVE

C  SIERRA VISTA, AZ 85635

C  (602)378-2130

C  DATE: JULY 21, 1989

      DIMENSION X1(100),X2(100),X3(100),Y2(100),P(100),B(100),

     1PB(100),A(100),PA(100),POPK(100),FK(100),IR(100),X2T(100),

     2POPKT(100),Y2T(100),X4(100),IHIT(100),SLOPE1(100),SLOPE2(100)

      EQUIVALENCE (X2T,Y2T)

      REAL KPOP

      CHARACTER*16 FNAM1,FNAM2

      LUN0=0

      LUN1=1

      LUN2=2

      ITMAX=50

      FNAM2='PRN'

      OPEN(LUN2,FILE=FNAM2)

      WRITE(LUN0,9002)

      WRITE(LUN2,9002)

 9002 FORMAT(1H1,'PROGRAM OPTIMA'//

     1' VISTA RESEARCH CORPORATION'/

     1' 3826 SNEAD DRIVE'/

     1' SIERRA VISTA, AZ 85635'/

     1' TEL: (602)378-2130'/)

      WRITE(LUN0,9003)

 9003 FORMAT(' INPUT NAME OF TARGET DATA FILE: '\)

      READ(LUN0,9004)FNAM1

 9004 FORMAT(A16)

      OPEN(LUN1,FILE=FNAM1)

      WRITE(LUN2,9005)FNAM1

 9005 FORMAT(' NAME OF TARGET FILE = 'A16)

      WRITE(LUN0,9006)

 9006 FORMAT(' INPUT NO OF TARGETS: '\)

      READ(LUN0,9010)NT

 9010 FORMAT(I3)

      WRITE(LUN2,9012)NT

 9012 FORMAT(' NO OF TARGETS = ',I3)

      WRITE(LUN0,9015)

 9015 FORMAT(' INPUT VALUE, BETA, FOR EACH TARGET'/

     1' (TWO ENTRIES PER LINE): ')

      READ(LUN1,9020)(P(I),B(I),I=1,NT)

 9020 FORMAT(2F10.4)

      WRITE(LUN0,9021)

      WRITE(LUN2,9021)

 9021 FORMAT(' TGT NO   VALUE      BETA')

      WRITE(LUN0,9022)(I,P(I),B(I),I=1,NT)

      WRITE(LUN2,9022)(I,P(I),B(I),I=1,NT)

 9022 FORMAT(1X,I5,2F10.4)

  385 CONTINUE

      WRITE(LUN0,9025)

      WRITE(LUN2,9025)

 9025 FORMAT(1H0,'NEW PROBLEM (SAME TARGET SET)'/)

      WRITE(LUN0,9030)

 9030 FORMAT(' INPUT INTERCEPTOR KILL PROB, SALVO SIZE: '\)

      READ(LUN0,9035)PPK,SS

 9035 FORMAT(2F10.4)

      WRITE(LUN2,9032)PPK,SS

 9032 FORMAT(' INTERCEPTOR KILL PROB = 'F10.4,' SALVO SIZE = ',F10.4)

      PK=1.-(1.-PPK)**SS

      WRITE(LUN0,9040)

 9040 FORMAT(' INPUT NO OF WEAPONS(X), NO OF INTERCEPTORS(Y): '\)

      READ(LUN0,9045)X,Y

 9045 FORMAT(2F10.4)

      WRITE(LUN2,9047)X,Y

 9047 FORMAT(' NO OF WEAPONS(X) = ',F10.4,' NO OF INTERCEPTORS(Y) = '

     1F10.4)

      WRITE(LUN0,9050)

 9050 FORMAT(' INPUT EPSILON-Y, EPSILON-X: '\)

      READ(LUN0,9055)EY,EX

 9055 FORMAT(2F10.4)

      WRITE(LUN2,9057)EY,EX

 9057 FORMAT(' EPSILON-Y = 'F10.4,' EPSILON-X = 'F10.4)

C  COMPUTE DAMAGE FUNCTION PARAMETERS

      TPOP=0.0

      DO 100 IT=1,NT

      A(IT)=-LOG((1.-PK)*EXP(-B(IT))+PK)

C  PA IS SLOPE AT ORIGIN OF LEAKAGE CURVE

      PA(IT)=P(IT)*A(IT)

C  PB IS SLOPE AT ORIGIN OF EXHAUSTION DAMAGE CURVE

C  (I.E., OF THE NO-DEFENSE DAMAGE CURVE)

      PB(IT)=P(IT)*B(IT)

      SLOPE2(IT)=PB(IT)

      Y2T(IT)=0.0

      TPOP=TPOP+P(IT)

  100 CONTINUE

      WRITE(LUN0,9060)TPOP

      WRITE(LUN2,9060)TPOP

 9060 FORMAT(' TOTAL TARGET VALUE = ',F14.4)

      WRITE(LUN0,9065)PK

      WRITE(LUN2,9065)PK

 9065 FORMAT(' SALVO KILL PROBABILITY = ',F10.4)

C  RANK TARGETS BY PB = SLOPE OF NO-DEFENSE DAMAGE CURVE AT ORIGIN

C  X2 NOT USED

      CALL RANK(NT,X2,SLOPE2,IR)

C  MAX VALUE OF LAG MULT = MAX SLOPE OF ALL NO-DEFENSE

C  DAMAGE CURVES

      RL2=SLOPE2(NT)

      RL1=0.0

      RL=.5*RL2

      ITS=0

  320 CONTINUE

      ITS=ITS+1

      IF(ITS.LE.ITMAX)GO TO 321

      WRITE(LUN0,9066)

      WRITE(LUN2,9066)

 9066 FORMAT(' CONVERGENCE FAILURE, LINEAR DAMAGE REGION')

      GO TO 385

  321 CONTINUE

C  COMPUTE WEAPON AND INT LEVELS CORRESP TO SPEC VALUE OF LAG MULT

      DO 200 IT=1,NT

      IF(PB(IT)-RL)210,210,220

C  X1 IS LOWER OPTIMAL SOLN, X2 IS UPPER OPTIMAL SOLUTION,

C  OVER LINEAR PORTION OF DAMAGE CURVE

C  X3 IS SOLN IF Y=0

C  CASE 3: NO WEAPONS OR INTERCEPTORS ALLOCATED TO TARGETS

  210 CONTINUE

      X1(IT)=0.0

      X2(IT)=0.0

      X3(IT)=0.0

      Y2(IT)=0.0

      GO TO 200

  220 IF(PA(IT)-RL)230,230,240

C  CASE 1: LINEAR DAMAGE CURVE FROM ORIGIN TO X2

  230 CONTINUE

      X1(IT)=0.0

      X2(IT)=P(IT)*(1.-RL/PB(IT))/RL

      X3(IT)=-LOG(RL/PB(IT))/B(IT)

      Y2(IT)=(LOG(RL/PB(IT))+B(IT)*X2(IT))/(B(IT)-A(IT))

      GO TO 200

C  CASE 2: LINEAR DAMAGE CURVE FROM X1 TO X2

  240 CONTINUE

      X1(IT)=-LOG(RL/PA(IT))/A(IT)

      X2(IT)=X1(IT)+1./A(IT)-1./B(IT)

      X3(IT)=-LOG(RL/PB(IT))/B(IT)

      Y2(IT)=(LOG(RL/PB(IT))+B(IT)*X2(IT))/(B(IT)-A(IT))

  200 CONTINUE

C  ADD UP ALLOCATED INTERCEPTORS CORRESPONDING TO CURRENT

C  VALUE OF LAGRANGE MULTIPLIER

      YMAXL=0.0

      DO 250 IT=1,NT

  250 YMAXL=YMAXL+Y2(IT)

C  START LINEAR-PAYOFF CONVERGENCE SECTION

  260 IF(ABS(YMAXL-Y)-EY)280,290,290

  290 IF(YMAXL-Y)300,310,310

  300 CONTINUE

C  TOO FEW INTERCEPTORS ALLOCATED, DECREASE MULTIPLIER

      RL2=RL

      RL=(RL1+RL2)/2.

      GO TO 320

  310 CONTINUE

C  TOO MANY INTERCEPTORS ALLOCATED, INCREASE MULTIPLIER

      RL1=RL

      RL=(RL1+RL2)/2.

      GO TO 320

C  INTERCEPTOR CONVERGENCE -- ADD UP ALLOCATED WEAPONS

  280 CONTINUE

      XMAXL=0.0

      XMINL=0.0

      X0L=0.0

      DO 330 IT=1,NT

      XMAXL=XMAXL+X2(IT)

      XMINL=XMINL+X1(IT)

      X0L=X0L+X3(IT)

  330 CONTINUE

C  IF X.LT.XMINL, GO TO STRONG DEFENSE SECTION

      IF(X-XMINL)380,390,390

C  IF X.GT.XMAXL, GO TO SATURATION ATTACK SECTION

  390 IF(X-XMAXL)400,400,410

C  PRINT RESULTS FOR LINEAR PAYOFF SECTION OF DAMAGE CURVE

C  (STABLE DEFENSE)

  400 CONTINUE

      WRITE(LUN0,9075)

      WRITE(LUN2,9075)

 9075 FORMAT(1H0,'LINEAR DAMAGE FUNCTION REGION'

     1' (STABLE DEFENSE REGION)')

      WRITE(LUN0,9086)RL

      WRITE(LUN2,9086)RL

 9086 FORMAT(' ATTACKER"S LAGRANGE MULTIPLIER = 'F14.4)

      WRITE(LUN0,9080)

      WRITE(LUN2,9080)

 9080 FORMAT(1H0,'STABLE DEFENSE(YMAXL), MAXIMAL ATTACK(XMAXL)')

      WRITE(LUN0,9085)YMAXL,XMAXL

      WRITE(LUN2,9085)YMAXL,XMAXL

 9085 FORMAT(' YMAXL = 'F14.4,' XMAXL = 'F14.4)

      CALL DAMAG(NT,X2,Y2,P,B,PK,KPOP,POPK,FK)

      FK2=KPOP/TPOP

      WRITE(LUN0,9090)

      WRITE(LUN2,9090)

 9090 FORMAT(' TGT NO   VALUE      BETA    #WEAPS    #INTS',

     1'   VALUE DEST  FRAC DEST')

      DO 450 IT=1,NT

      WRITE(LUN0,9091)IT,P(IT),B(IT),X2(IT),Y2(IT),POPK(IT),FK(IT)

      WRITE(LUN2,9091)IT,P(IT),B(IT),X2(IT),Y2(IT),POPK(IT),FK(IT)

 9091 FORMAT(1X,I5,6F10.4)

  450 CONTINUE

      WRITE(LUN0,9095)KPOP

      WRITE(LUN2,9095)KPOP

 9095 FORMAT(' TOTAL VALUE DESTROYED = 'F14.4)

      WRITE(LUN0,9105)FK2

      WRITE(LUN2,9105)FK2

 9105 FORMAT(' FRACTION VALUE DESTROYED = ',F14.4)

      WRITE(LUN0,9110)

      WRITE(LUN2,9110)

 9110 FORMAT(1H0,'STABLE DEFENSE(YMAXL), MINIMAL ATTACK(XMINL)')

      WRITE(LUN0,9115)YMAXL,XMINL

      WRITE(LUN2,9115)YMAXL,XMINL

 9115 FORMAT(' YMAXL = 'F14.4,' XMINL = 'F14.4)

      CALL DAMAG(NT,X1,Y2,P,B,PK,KPOP,POPK,FK)

      FK1=KPOP/TPOP

      WRITE(LUN0,9090)

      WRITE(LUN2,9090)

      DO 460 IT=1,NT

      WRITE(LUN0,9091)IT,P(IT),B(IT),X1(IT),Y2(IT),POPK(IT),FK(IT)

      WRITE(LUN2,9091)IT,P(IT),B(IT),X1(IT),Y2(IT),POPK(IT),FK(IT)

  460 CONTINUE

      WRITE(LUN0,9095)KPOP

      WRITE(LUN2,9095)KPOP

      WRITE(LUN2,9105)FK1

      WRITE(LUN0,9105)FK1

      SLOPE=(FK2-FK1)/(XMAXL-XMINL)

      WRITE(LUN0,9135)

      WRITE(LUN2,9135)

 9135 FORMAT(' EQUATION FOR DAMAGE IN OPTIMAL ATTACK OF SIZE X,'/

     1'  YMAXL, WHERE XMINL LE X LE XMAXL.')

      WRITE(LUN0,9136)

      WRITE(LUN2,9136)

 9136 FORMAT(' FRAC DEST = INT + SLOPE*(X-XMINL)')

      WRITE(LUN0,9140)FK1,SLOPE,XMINL

      WRITE(LUN2,9140)FK1,SLOPE,XMINL

 9140 FORMAT(' INT,SLOPE,XMINL = '3F14.4)

      DAM=FK1+SLOPE*(X-XMINL)

      WRITE(LUN0,9145)X,Y,DAM

      WRITE(LUN2,9145)X,Y,DAM

 9145 FORMAT(' FRAC DEST IN SPECIFIED ATTACK (X = 'F14.4,

     1' Y = 'F14.4,'),'/'  IGNORING DISCRETE TARGET EFFECT = 'F14.4)

C  SELECTION OF A PROBABILITY SAMPLE OF TARGETS

      WRITE(LUN0,9305)

 9305 FORMAT(' INPUT 1 TO SELECT A PROBABILITY SAMPLE'/

     1'  OF TARGETS, 0 OTHERWISE:'\)

      READ(LUN0,9306)ISEL

 9306 FORMAT(I3)

      IF(ISEL)700,700,701

  701 CONTINUE

      WRITE(LUN2,9308)

 9308 FORMAT(1H0,'SELECTION OF PROBABILITY SAMPLES OF TARGETS')

      WRITE(LUN0,9311)

 9311 FORMAT(' SPECIFY TARGET SAMPLING METHOD.'/

     1'  INPUT 0 TO SELECT TARGETS TO STRIKE AT HIGH OPTIMAL'/

     1'  LEVELS, WITH OTHERS STRUCK AT LOW OPTIMAL LEVELS.'/

     1'  (USE THIS OPTION FOR HIGH VALUES OF INTERCEPTOR'/

     1'  KILL PROBABILITY.)'/

     1'  INPUT 1 TO SELECT TARGETS TO STRIKE AT HIGH OPTIMAL'/

     1'  LEVELS, WITH OTHERS NOT STRUCK.  (USE THIS OPTION'/

     1'  FOR LOW VALUES OF INTERCEPTOR KILL PROBABILITY.)'

     1'  INPUT 0 OR 1: '\)

      READ(LUN0,9312)ISAM

 9312 FORMAT(I1)

      IF(ISAM.GT.0)GO TO 702

C  SELECTION OF A PROB SAMPLE OF TARGETS TO HIT AT THE HIGH

C  OPTIMAL LEVEL, OTHERS HIT AT THE LOW OPTIMAL LEVEL.

      WRITE(LUN2,9313)

 9313 FORMAT(' SAMPLING METHOD: SELECT TARGETS TO STRIKE AT'/

     1'  HIGH OPTIMAL LEVEL WITH SPECIFIED PROBABILITY.  OTHER'/

     1'  TARGETS ARE STRUCK AT LOW OPTIMAL LEVELS.')

      WRITE(LUN0,9307)

 9307 FORMAT(' INPUT PROB OF HITTING A TARGET AT THE HIGH LEVEL:'\)

      READ(LUN0,9310)PHI

 9310 FORMAT(F10.4)

      WRITE(LUN2,9320)PHI

 9320 FORMAT(' PROB OF HITTING EACH TARGET AT THE HIGH LEVEL = ',

     1F10.4)

      ISAMP=0

  709 CONTINUE

      ISAMP=ISAMP+1

      WRITE(LUN0,9323)ISAMP

      WRITE(LUN2,9323)ISAMP

 9323 FORMAT(1H0,'SAMPLE NO ',I3)

      YSUM=0.0

      XSUM=0.0

      YALOC=0.0

      ISUM=0

      DO 705 IT=1,NT

      IHIT(IT)=0

      X4(IT)=X1(IT)

      YUSED=X1(IT)

      CALL RANDU(XX)

      IF(XX.GT.PHI)GO TO 710

      IHIT(IT)=1

      ISUM=ISUM+1

      X4(IT)=X2(IT)

      YUSED=Y2(IT)

  710 CONTINUE

      XSUM=XSUM+X4(IT)

      YALOC=YALOC+Y2(IT)

      YSUM=YSUM+YUSED

  705 CONTINUE

      CALL DAMAG(NT,X4,Y2,P,B,PK,KPOP,POPK,FK)

      WRITE(LUN0,9330)ISUM

      WRITE(LUN2,9330)ISUM

 9330 FORMAT(' NO OF TARGETS HIT AT HIGH LEVEL = ',I3)

      WRITE(LUN0,9340)XSUM

      WRITE(LUN2,9340)XSUM

 9340 FORMAT(' NO OF WEAPONS EXPENDED = ',F14.4)

      WRITE(LUN0,9345)YALOC

      WRITE(LUN2,9345)YALOC

 9345 FORMAT(' NO OF INTERCEPTORS ALLOCATED = ',F14.4)

      WRITE(LUN0,9350)YSUM

      WRITE(LUN2,9350)YSUM

 9350 FORMAT(' NO OF INTERCEPTORS EXPENDED = ',F14.4)

      FK2=KPOP/TPOP

      WRITE(LUN0,9390)

      WRITE(LUN2,9390)

 9390 FORMAT(' TGT NO   VALUE      BETA    #WEAPS    #INTS',

     1'   VALUE DEST  FRAC DEST   IHIGH')

      DO 750 IT=1,NT

      WRITE(LUN0,9391)IT,P(IT),B(IT),X4(IT),Y2(IT),POPK(IT),FK(IT)

     1,IHIT(IT)

      WRITE(LUN2,9391)IT,P(IT),B(IT),X4(IT),Y2(IT),POPK(IT),FK(IT)

     1,IHIT(IT)

 9391 FORMAT(1X,I5,6F10.4,3X,I5)

  750 CONTINUE

      WRITE(LUN0,9095)KPOP

      WRITE(LUN2,9095)KPOP

      WRITE(LUN0,9105)FK2

      WRITE(LUN2,9105)FK2

      WRITE(LUN0,9380)

 9380 FORMAT(' INPUT 1 TO GENERATE ANOTHER SAMPLE, 0 OTHERWISE:'\)

      READ(LUN0,9381)ICONT

 9381 FORMAT(I3)

      IF(ICONT)708,708,709

  708 CONTINUE

      GO TO 700

C  SELECTION OF A PROB SAMPLE OF TARGETS TO HIT AT HIGH OPTIMAL

C  LEVEL, OTHER TARGETS NOT HIT.

  702 CONTINUE

      WRITE(LUN2,9409)

 9409 FORMAT(' SAMPLING METHOD: SELECT TARGETS TO STRIKE AT'/

     1'  HIGH OPTIMAL LEVEL WITH SPECIFIED PROBABILITY.  OTHER'/

     1'  TARGETS ARE NOT STRUCK.')

      WRITE(LUN0,9407)

 9407 FORMAT(' INPUT PROB OF SELECTING A TARGET:'\)

      READ(LUN0,9410)PHI

 9410 FORMAT(F10.4)

      WRITE(LUN2,9420)PHI

 9420 FORMAT(' PROB OF SELECTING A TARGET = ',

     1F10.4)

      ISAMP=0

  809 CONTINUE

      ISAMP=ISAMP+1

      WRITE(LUN0,9423)ISAMP

      WRITE(LUN2,9423)ISAMP

 9423 FORMAT(1H0,'SAMPLE NO ',I3)

      YSUM=0.0

      XSUM=0.0

      YALOC=0.0

      ISUM=0

      DO 805 IT=1,NT

      IHIT(IT)=0

      X4(IT)=0.0

      YUSED=0.0

      CALL RANDU(XX)

      IF(XX.GT.PHI)GO TO 810

      IHIT(IT)=1

      ISUM=ISUM+1

      X4(IT)=X2(IT)

      YUSED=Y2(IT)

  810 CONTINUE

      XSUM=XSUM+X4(IT)

      YALOC=YALOC+Y2(IT)

      YSUM=YSUM+YUSED

  805 CONTINUE

      CALL DAMAG(NT,X4,Y2,P,B,PK,KPOP,POPK,FK)

      WRITE(LUN0,9430)ISUM

      WRITE(LUN2,9430)ISUM

 9430 FORMAT(' NO OF TARGETS HIT  = ',I3)

      WRITE(LUN0,9440)XSUM

      WRITE(LUN2,9440)XSUM

 9440 FORMAT(' NO OF WEAPONS EXPENDED = ',F14.4)

      WRITE(LUN0,9445)YALOC

      WRITE(LUN2,9445)YALOC

 9445 FORMAT(' NO OF INTERCEPTORS ALLOCATED = ',F14.4)

      WRITE(LUN0,9450)YSUM

      WRITE(LUN2,9450)YSUM

 9450 FORMAT(' NO OF INTERCEPTORS EXPENDED = ',F14.4)

      FK2=KPOP/TPOP

      WRITE(LUN0,9490)

      WRITE(LUN2,9490)

 9490 FORMAT(' TGT NO   VALUE      BETA    #WEAPS    #INTS',

     1'   VALUE DEST  FRAC DEST   IHIGH')

      DO 850 IT=1,NT

      WRITE(LUN0,9491)IT,P(IT),B(IT),X4(IT),Y2(IT),POPK(IT),FK(IT)

     1,IHIT(IT)

      WRITE(LUN2,9491)IT,P(IT),B(IT),X4(IT),Y2(IT),POPK(IT),FK(IT)

     1,IHIT(IT)

 9491 FORMAT(1X,I5,6F10.4,3X,I5)

  850 CONTINUE

      WRITE(LUN0,9095)KPOP

      WRITE(LUN2,9095)KPOP

      WRITE(LUN0,9105)FK2

      WRITE(LUN2,9105)FK2

      WRITE(LUN0,9480)

 9480 FORMAT(' INPUT 1 TO GENERATE ANOTHER SAMPLE, 0 OTHERWISE:'\)

      READ(LUN0,9481)ICONT

 9481 FORMAT(I3)

      IF(ICONT)808,808,809

  808 CONTINUE

  700 CONTINUE

      GO TO 385

C  STRONG DEFENSE REGION OF DAMAGE CURVE

C  DAMAGE DUE TO DEFENSE INTERCEPTOR LEAKAGE

  380 CONTINUE

      DO 500 IT=1,NT

      SLOPE1(IT)=PA(IT)

      SLOPE2(IT)=PA(IT)

  500 CONTINUE

C  RANK TARGETS BY PA = SLOPE OF LEAKAGE CURVE AT ORIGIN

      CALL RANK(NT,X2,SLOPE2,IR)

C  MAX VALUE OF LAG MULT = MAX SLOPE OF LEAKAGE CURVES

C  AT ORIGIN

      RL2=SLOPE2(NT)

      RL1=0.0

      RL=.5*RL2

      ITS=0

  580 CONTINUE

      ITS=ITS+1

      IF(ITS.LE.ITMAX)GO TO 581

      WRITE(LUN0,9382)

      WRITE(LUN2,9382)

 9382 FORMAT(' CONVERGENCE FAILURE, STRONG DEFENSE REGION')

      GO TO 385

  581 CONTINUE

      DO 505 IT=1,NT

C  IF LAG MULT EXCEEDS ORIGIN SLOPE FOR A TARGET, ALLOCATE ZERO

C  WEAPONS (OR ELSE WOULD GET NEGATIVE WEAPON LEVELS)

      X2(IT)=0.0

      IF(RL-SLOPE1(IT))506,507,507

  506 CONTINUE

      X2(IT)=-LOG(RL/PA(IT))/A(IT)

  507 CONTINUE

  505 CONTINUE

C  ADD UP ALLOCATED WEAPONS CORRESPONDING TO CURRENT

C  VALUE OF LAGRANGE MULTIPLIER

      XALOC=0.0

      DO 510 IT=1,NT

      XALOC=XALOC+X2(IT)

  510 CONTINUE

      IF(ABS(XALOC-X)-EX)515,520,520

  520 CONTINUE

      IF(XALOC-X)560,570,570

  560 CONTINUE

C  TOO FEW WEAPONS ALLOCATED, DECREASE MULTIPLIER

      RL2=RL

      RL=(RL1+RL2)/2.

      GO TO 580

  570 CONTINUE

C  TOO MANY WEAPONS ALLOCATED, INCREASE MULTIPLIER

      RL1=RL

      RL=(RL1+RL2)/2.

      GO TO 580

  515 CONTINUE

      WRITE(LUN0,9220)

      WRITE(LUN2,9220)

 9220 FORMAT(' STRONG DEFENSE')

      WRITE(LUN0,9086)RL

      WRITE(LUN2,9086)RL

      CALL DAMAG(NT,X2,Y2,P,B,PK,KPOP,POPK,FK)

      FK1=KPOP/TPOP

      WRITE(LUN0,9090)

      WRITE(LUN2,9090)

      DO 540 IT=1,NT

      WRITE(LUN0,9091)IT,P(IT),B(IT),X2(IT),Y2(IT),POPK(IT),FK(IT)

      WRITE(LUN2,9091)IT,P(IT),B(IT),X2(IT),Y2(IT),POPK(IT),FK(IT)

  540 CONTINUE

      WRITE(LUN0,9095)KPOP

      WRITE(LUN2,9095)KPOP

      WRITE(LUN0,9105)FK1

      WRITE(LUN2,9105)FK1

      GO TO 385

C  SATURATION ATTACK REGION OF DAMAGE CURVE (UNSTABLE DEFENSE)

C  NOTE: THIS SECTION IMPLEMENTS AN APPROXIMATE (BUT FAST)

C  SOLUTION.  IT ASSUMES THE STABLE-DEFENSE ALLOCATION OF

C  INTERCEPTORS (FROM THE LINEAR REGION OF THE TOTAL

C  PAYOFF CURVE).

  410 CONTINUE

C  COMPUTE SLOPE OF DAMAGE CURVE AT POINT OF EXHAUSTION

C  OF INTERCEPTORS

      DO 600 IT=1,NT

      SLOPE2(IT)=PB(IT)*EXP(-A(IT)*Y2(IT))

      SLOPE1(IT)=SLOPE2(IT)

  600 CONTINUE

C  X2 NOT USED

C  RANK TARGETS BY SLOPE OF DAMAGE CURVE AT EXHAUSTION POINT

      CALL RANK(NT,X2,SLOPE2,IR)

C  MAX LAG MULT IS SLOPE AT EXHAUSTION POINT

      RL2=SLOPE2(NT)

      RL1=0.0

      RL=.5*RL2

      ITS=0

  680 CONTINUE

      ITS=ITS+1

      IF(ITS.LE.ITMAX)GO TO 681

      WRITE(LUN0,9383)

      WRITE(LUN2,9383)

 9383 FORMAT(' CONVERGENCE FAILURE, SATURATION ATTACK REGION')

      GO TO 385

  681 CONTINUE

      DO 605 IT=1,NT

C  IF LAG MULT EXCEEDS EXHAUSTION-POINT SLOPE FOR A TARGET,

C  ALLOCATE ZERO WEAPONS (OR ELSE WOULD GET NEGATIVE WEAPON LEVELS)

      X2(IT)=0.0

      IF(RL-SLOPE1(IT))606,607,607

  606 CONTINUE

      X2(IT)=-(LOG(RL/PB(IT))-(B(IT)-A(IT))*Y2(IT))/B(IT)

  607 CONTINUE

  605 CONTINUE

      XALOC=0.0

C  ADD UP ALLOCATED WEAPONS CORRESPONDING TO CURRENT

C  VALUE OF LAGRANGE MULTIPLIER.

      DO 610 IT=1,NT

      XALOC=XALOC+X2(IT)

  610 CONTINUE

      IF(ABS(XALOC-X)-EX)615,620,620

  620 CONTINUE

      IF(XALOC-X)660,670,670

  660 CONTINUE

C  TOO FEW WEAPONS ALLOCATED, DECREASE MULTIPLIER

      RL2=RL

      RL=(RL1+RL2)/2.

      GO TO 680

  670 CONTINUE

C  TOO MANY WEAPONS ALLOCATED, INCREASE MULTIPLIER

      RL1=RL

      RL=(RL1+RL2)/2.

      GO TO 680

  615 CONTINUE

      WRITE(LUN0,9230)

      WRITE(LUN2,9230)

 9230 FORMAT(' SATURATION ATTACK')

      WRITE(LUN0,9086)RL

      WRITE(LUN2,9086)RL

      CALL DAMAG(NT,X2,Y2,P,B,PK,KPOP,POPK,FK)

      FK1=KPOP/TPOP

      WRITE(LUN0,9090)

      WRITE(LUN2,9090)

      DO 480 IT=1,NT

      WRITE(LUN0,9091)IT,P(IT),B(IT),X2(IT),Y2(IT),POPK(IT),FK(IT)

      WRITE(LUN2,9091)IT,P(IT),B(IT),X2(IT),Y2(IT),POPK(IT),FK(IT)

  480 CONTINUE

      WRITE(LUN0,9095)KPOP

      WRITE(LUN2,9095)KPOP

      WRITE(LUN0,9105)FK1

      WRITE(LUN2,9105)FK1

      GO TO 385

      END

      SUBROUTINE DAMAG(NT,X,Y,P,B,PK,KPOP,POPK,FK)

      DIMENSION X(1),Y(1),B(1),P(1),POPK(1),FK(1)

      REAL KPOP

      KPOP=0.0

      DO 200 IT=1,NT

      XX=X(IT)

      YY=Y(IT)

      BB=B(IT)

      IF(XX-YY)100,100,110

  100 Q=1.-((1.-PK)*EXP(-BB)+PK)**XX

      GO TO 120

  110 Q=1.-EXP(-BB*(XX-YY))*((1.-PK)*EXP(-BB)+PK)**YY

  120 CONTINUE

      FK(IT)=Q

      POPK(IT)=P(IT)*Q

      KPOP=KPOP+POPK(IT)

  200 CONTINUE

      RETURN

      END

      SUBROUTINE RANK(N,X,Y,IR)

      DIMENSION X(1),Y(1),IR(1)

C  REARR X + Y IN INC ORD OF COMPS OF Y. REC ORIG POS'S IN IR.

      DO 50 I=1,N

   50 IR(I)=I

      NM1=N-1

      DO 100 I=1,NM1

      IP1=I+1

      DO 100 J=IP1,N

      IF(Y(J)-Y(I))110,100,100

  110 TEMP=Y(J)

      Y(J)=Y(I)

      Y(I)=TEMP

      TEMP=X(J)

      X(J)=X(I)

      X(I)=TEMP

      ITEMP=IR(J)

      IR(J)=IR(I)

      IR(I)=ITEMP

  100 CONTINUE

      RETURN

      END

      SUBROUTINE RANDU(YFL)

C  THIS SUBROUTINE GENERATES UNIFORMLY DISTRIBUTED RANDOM NUMBERS

C  BY THE MULTIPLICATIVE CONGRUENTIAL ("RESIDUE") METHOD

C  OUTPUT YFL IS THE RANDOM NUMBER

      INTEGER*2 IX,IY

      DATA IX/257/

      IY=IX*259

      IF(IY)5,6,6

    5 IY=IY+32767+1

    6 YFL=IY

      YFL=YFL*0.30517578E-4

      IX=IY

      RETURN

      END

 


Appendix H. Phase II Work Plan

 

I. Proposed Project Tasks

 

To accomplish the goal of developing an automated system for generation of scenarios, strategies, plans or tactics, it is proposed to accomplish the following tasks:

 

            Task 1. Conduct Project Planning

            Task 2. Conduct Requirements Analysis

            Task 3. Develop Top-Level (Preliminary) Design

            Task 4. Develop Detailed Design

            Task 5. Implement and Test Model

            Task 6. Prepare Model Documentation

            Task 7. Prepare Monthly Progress Reports,

                                    Presentations, and Final Report

 

The following paragraphs describe the content of each of the preceding tasks.  Following the task descriptions, a schedule and staffing plan is presented.

 

Task 1: Conduct Project Planning.  Task 1 is concerned with the development and revision of a detailed project work plan and the assignment of staff to project tasks.

 

It is proposed that the software development of Tasks 2-5 of the project be conducted in accordance with DOD-STD-2167A, Defense System Software Development.  The proposed task structure (requirements analysis, top-level design, detailed design, implementation and test) is consistent with 2167A methodology.  The deliverables proposed to be produced in the course of the project (e.g., Software Requirements Specification, Software Design Document, Software User's Manual) are consistent with DOD-STD-2167A.

 

Task 2: Conduct Requirements Analysis.  Vista proposes to use a modern systems engineering approach to the system design.  This approach employs a top-down structured analysis and structured design methodology to develop a manageable system that satisfies all of the requirements.  This approach includes a requirements specification, requirements analysis, functional analysis, synthesis of alternative top-level designs that meet the requirements, application of cost-effectiveness trade-off analysis to select a preferred alternative, development of a detailed design, optimization of the detailed design, implementation, and testing.

 

The systems engineering process will be applied to the total system design, including hardware and software.  Systems engineering applied to software development is called software engineering.  As mentioned, we propose that the software development be conducted in accordance with DOD-STD-2167A, Defense System Software Development.

 

The first step in this process is the requirements specification.  The general need for the proposed system will be described, and the general requirements identified and described.  The government project officer (contracting officer's technical representative) will be asked for information about AFSC problems that are to be addressed with a system such as the proposed one.  The characteristics and capabilities that the system must possess in order to be most useful to AFSC will be identified.  From this information, a system specification will be developed.  From the system specification, a detailed list of all of the requirements that the system must satisfy will be developed.

 

A Software Requirements Specification document will be produced, in accordance with DOD-STD-2167A specifications.

 

A requirements analysis will then be conducted.  Each explicitly stated requirement will be broken down, or "decomposed," into elemental requirements.  (A requirement that is not broken down into any further requirements is referred to as an "elemental" requirement.)

 

Task 3. Develop Top-Level System Design.  Preliminary design, or top-level design, is concerned with a definition of the subsystems to be developed, specification of the functions that each performs, and definition of the interfaces among the subsystems.  In Task 3, a functional description of the model will be developed.  Similar functions will be grouped into functional classes.  The elemental requirements identified in Task 2 will be assigned to functional classes.

 

At the completion of the requirements analysis (Task 2), there is no form, or structure to the system -- nothing more than a list of requirements.  In order to assist the synthesis of alternative systems, it is necessary to structure the requirements.  This is done by defining a number of categories, or classes, of functions, into which the requirements will be separated, or "allocated." 

 

The functions will thus be grouped into manageable groups, or modules, and a system "architecture" will be developed.  The architecture is a description of all of the major system modules and their interrelationships.  The architecture represents a top-level system design.

 

The functional classification for the proposed system (i.e., battlefield simulation model) will likely consist of the following variables of classification:

            o Hardware/software/personnel

            o Subsystem

The "subsystem" variable of classification refers to classification breakdown within each of the Hardware, Software, and Personnel categories.  The Hardware system will likely consist simply of a computer system (e.g., a Sun SPARCstation 1, Symbolics machine, an AT-compatible machine, a VAX system).  The software system will likely be broken down into two subsystems: commercially available software (e.g., a "C" compiler, a simulation package such as the RAMP), and application software (to be developed by staff during the course of the project).

 

A top-level design will be developed.  The design will be based on a top-down, structured analysis / structured design approach, as advocated by De Marco, Constantine, and Yourdon.  Recommendations will be made concerning the tailoring of DOD-STD-2167A (Defense System Software Development Standard) to the project.  Recommendations concerning the use of software development tools (e.g., EXCELLERATOR, PROMOD) will be made.  The top-level design effort will relate to the requirements analysis.  It will include analysis of alternative software development, programming and simulation systems, alternative process-oriented languages (e.g., C, FORTRAN, Ada, Pascal, LISP), alternative development hardware (e.g., Sun, Apollo, VAX, Symbolics, TI, Silicon Graphics, AT), operating systems, and alternative modeling approaches.

 

The top-level design task includes specification of the conceptual and analytical frameworks for the system.  The conceptual and analytical framework described in this proposal will be developed in detail.  The major functions of the system will be identified and described.  A functional flow diagram will be developed.  The specific analytical procedures by which the conceptual framework will be implemented will be identified and described.

 

We now turn our attention to the software system.  The top-level design is accomplished by the synthesis of a software architecture.  The software architecture is the structure and relationship among the components of the software system.  The components or "modules" of the software system are groups of related functions.  These modules are formed by applying the principles of structured software design.  Functions are grouped into modules so that the resultant modules are small, highly cohesive and loosely coupled.  Such modules are easy to develop, test, integrate, and maintain.

 

The software architecture identifies the major software system components, but it does not specify whether they involve the development of new software or the utilization of existing software.  There may be areas in which commercially available software exists that will satisfy the system requirements (e.g., a relational data base management system, an object-oriented simulation package).  During the program design phase, a cost-effectiveness analysis study will be conducted, to determine the relative merits of using package software versus developing new software, and to make a design recommendation to the Government concerning what packages to use.

 

In addition to application-oriented software, existing software also includes system support software and programming support software (such as a program design language).

 

While the final recommendations for the use of existing software will be made as part of the detailed design process, our cost proposal is based on recommendations made on the basis of our initial design.  Similarly, our cost proposal is based on an initial design for the development hardware.  Specifically, we propose, as an initial design, the following:

            o All development on a Sun SPARCstation 1 microcomputer

            o Use of the RAMP at no cost to the project

            o Use of a C compiler and UNIX operating system

 

During the system development, a software development folder (SDF) will be maintained for the purpose of status monitoring and controlling the design, coding, debugging, testing, and integration of software items.  The SDF is to be used as a day-to-day engineering notebook for all phases of program development.  Software development folders will be maintained at several separate levels to insure top-down development, monitoring and control.  These levels consist of Computer Software Configuration Items (CSCIs), Computer Software Components (CSCs), and units.

 

A unit is the lowest-level logical entity specified in the detailed design which completely describes a non-divisible function in sufficient detail to allow implementing code to be produced, assembled/compiled and tested independently of other units.

 

At the end of the preliminary design phase, a Software Design Document will be prepared, and submitted to the Government.

 

Task 4. Develop Detailed System Design.  Detailed design is concerned with a complete identification of all of the hardware units and software modules, and the development of specification documents for these items.  The detailed design phase includes consideration of alternatives and the conduct of cost-effectiveness analysis, just as in the preliminary (top-level) design phase, but within the framework of the preliminary design. 

At the end of the detailed design phase, the Software Design Document will be revised to reflect the detailed design, and submitted to the government.

 

Task 5. Implement and Test Model.  A "rapid prototyping" approach will be adopted.  This approach to model development consists of the following steps:

            1.         Determine Requirements

            2.         Build Prototype Model

            3.         Execute Prototype, Analyze Results

            4.         Revise Requirements

            5.         Modify Prototype

            6.         Execute Prototype, Analyze Results

            7.         Repeat Steps (4)-(6) until Prototype Is

                        Satisfactory

            8.         Implement Accepted System

This approach to system development is an iterative approach, which recognizes that it may not always be possible to satisfy all of the initially specified system requirements because of cost and technology constraints.  It is a procedure for taking advantage of new knowledge that is obtained during the course of the development effort.  This approach explicitly recognizes the dynamic nature of research and development, and allows for an iterative adjustment (evolution) of the requirements in order to obtain a system that is as fully responsive to the client's desires as possible.

 

Note that a rapid prototyping approach to software development is consistent with DOD-STD-2167A, which specifically allows for the major steps of software development to be overlapping and recursive.

 

As units are developed, they will be subjected to unit tests.  Prior to the availability of all units, the system may be subjected to system tests, using appropriate test tools, stubs, or test drivers.  A Software Test Description will be delivered to the Government 30 days prior to formal acceptance testing of the model.

 

As changes are made to the model, the Software Design Document will be periodically revised to reflect those changes.

 

The implementation and test task will include the development of demonstration test cases.  This task may also include detailed development of a sample application, such as application of the developed methodology to support of the STOVL application.  This task will include revisions to the model, after review of the demonstration cases.  This task will represent a continuation of the "rapid prototyping" iterative approach to model development.

 

Task 6. Prepare Model Documentation. Task 6 is concerned with the development of a programmer's manual and a user's manual.  These manuals will be prepared in accordance with DOD-STD-2167A.  The programmer's manual will contain all information necessary to enable a programmer to understand the model code and make changes to it.  It will include a data dictionary, data flow diagrams, and structure charts, as well as a complete listing of the program code.  The user's manual will contain a detailed explanation of how to run the program.  It will include a sample problem, including all of the required data, program control instructions, and system resource requirements (e.g., memory, disk space).

 

Task 7. Prepare Monthly Progress Reports, Presentations, and Final Report. Monthly technical progress reports and oral presentations will be prepared and submitted to the Government.  Near the end of the project, a final report will be prepared that describes the project objectives, activities, findings, and results.  The final report will contain a complete description of the mathematical specification of the model (probably as a separate volume).  The model description will be keyed to the programmer's and user's manuals.

 

As discussed in the main text of this report, we propose to conduct formal reviews of the system requirements specification, the top-level design, and the detailed design, in accordance with MIL-STD-1521B, Military Standard: Technical Reviews and Audits for Systems, Equipments, and Computer Software.  These meetings are the System Requirements Review (SRR), the Preliminary Design Review (PDR) and the Critical Design Review (CDR).

 

In order to develop a product that is fully responsive to Government requirements, we propose that a total of seven meetings be conducted between Vista staff and Government staff.  Three of these are the SRR, PDR, and CDR.  In addition, we propose a project "kickoff" meeting and project reviews at the end of 12 months, 18 months, and 24 months.  To keep the project travel budget down, we propose that four of these meetings (the SRR, CDR, and the 18-month project review) be conducted in Tucson (i.e., the ASD project officer would travel to Tucson for these meetings).  For the other meetings, Vista staff would travel to ASD/Dayton.

 

 

 

 

II. Proposed Project Schedule

 

The proposed project schedule is shown in Figure H-1 ("Proposed Project Schedule"), which follows.  Figure H-1 also shows when project deliverables, meetings, and trips occur.


 

                                          Figure H-1. Proposed Project Schedule

 

                                                                                    Month After Contract Award

            Task/Subtask                                      123456789012345678901234

 

1. Proj. Planning                                             -

2. Reqts. Analysis                                           ------------

3. Top-Level Design                                          ----

4. Detailed Design                                                        ------

5. Implem. & Test                                                             ----------

6. Documentation                                           ----------------------

7. Reports                                                        ------------------------

 

Deliverables:                                                  123456789012345678901234

1. Quarterly Status Report                     x  x  x  x  x  x  x  x

2. Prelim. Soft. Req. Spec.                    x

3. Software Req. Spec.                                               x         

4. Prelim. Soft. Des. Doc. (Top Level)   x

5. Prelim. Soft. Des. Doc. (Detailed)       x

6. Software Des. Doc.                                            x

7. Software Test Desc.                                                             x

8. Outline of Soft. User's & Prog. Manuals        x

9. Software User's Manual                                                                 x

10. Software Programmer's Manual                                            x

11. Presentation Material                   x                       x                        x

12. Final Report                                                                                                  x

 

Meetings and Trips:                                        123456789012345678901234

1. Kickoff Meeting (at Dayton)          x

2. System Requirements Review

     (at Tucson)                                        x

3. Preliminary Design Review (at Dayton) x

4. Critical Design Review (at Tucson)       x

5. Project Review (12-month, at Dayton)        x

6. Project Review (18-month, at Tucson)                                 x

7. Project Review (24-month, at Dayton)                                              x

 


 

A comment is in order regarding the scheduling and documentation of the requirements analysis.  As mentioned, we propose to adopt a "rapid prototyping" approach to the software/model development.  Under this concept, the system requirements may be modified as part of the design process.  For this reason, the requirements analysis task (Task 2) lasts as long as the design tasks (Tasks 3 and 4).  Although the possibility exists that the requirements may change during the design process, much of the requirements analysis is accomplished before work begins on the design tasks.  We propose to prepare a preliminary Software Requirements Specification at the end of the first quarter.  This document will present a preliminary requirements specification, prior to possible modifications during the design process.

 

In order to facilitate quarterly payments linked to specific deliverables (DD Form 250), we propose the following list of deliverable documents:

            1. Quarterly Status Report (every quarter)

            2. Preliminary Software Requirements Specification

                        (qtr 1)

            3. Software Requirements Specification (qtr 4)

            4. Preliminary Software Design Document 1 (Top Level)

                        (qtr 2)

            5. Preliminary Software Design Document 2 (Detailed)

                        (qtr 3)

            6. Software Design Document (qtr 4)

            7. Outlines of Software User's Manual and Software

                        Programmer's Manuals (qtr 5)

            8. Software Test Description (qtr 6)

            9. Software User's Manual (qtr 7)

            10. Software Programmer's Manual (qtr 7)

            11. Presentation Material (qtrs 1, 4, and 8)

            12. Final Report (qtr 8)

 

This substantial list of deliverables is proposed in order to give the Government a specific deliverable in each quarter.  In this way, the Government's decision to approve the DD 250 payment can be based not only on a quarterly status report, but on one or more specific deliverables.  With the proposed set of deliverables, at least one of which occurs in each quarter, we believe that the Government will have a sound basis for gauging project progress and approving payment.

 

The Preliminary Software Design Document 1 (Top Level) will describe the top-level design.  The Preliminary Software Design Document 2 (Detailed) will describe the detailed design, as it exists half-way through the detailed design task (Subtask 4).  These two reports will be combined to form the Software Design Document, at the end of the design process (Subtasks 3 and 4).

The "Presentation Material" is simply copies of briefing materials used to brief the Government at the project meetings / reviews.

 

III. Proposed Project Staffing

 

Table H-1 ("Proposed Allocation of Labor to Project Tasks, by Month") presents a detailed breakdown, by month, of the amount of effort applied by each project staff member to each subtask.  The figures of the table are proportions of a person-month applied to each subtask.  In order to make most efficient use of personnel, we have determined a duration of each subtask that enables a level utilization of personnel throughout the two-year project period.  (This approach enables us to staff the project with a small number of persons, employed at a high level of effort on this project -- in a sense, "dedicated" to the project.  By avoiding "peaks and valleys" in personnel loadings, the project team is held intact, and project team members become very familiar with the project; time invested in bringing new staff "up to speed" is minimized.) 

 

Following Table H-1 is a summary, Table H-2 ("Proposed Staff Loading") that shows the allocation of staff time to each of the proposed project tasks.

 

We propose that Dr. J. G. Caldwell and Dr. W. O. Rasmussen both serve in a principal investigator capacity on the project (although there will be a single project director, viz., Dr. Caldwell).  The following table distinguish between them, as PI1 and PI2.  The legend for the table is as follows:

 

            PI1: Principal Investigator (Dr. Caldwell)

            PI2: Principal Investigator (Dr. Rasmussen)

            SA: Senior Analyst

            TA: Technical Assistant

 

The rationale for including two persons at the PI level is twofold: (1) to capitalize on the knowledge and experience of two senior scientists; and (2) to decrease risk, by having more than one senior staff member aware of all aspects of the project.

 

The staffing levels for the proposed project staff, for the total project, are as follows:

 

            PI1: .8 full time

            PI2: .1 full time

            SA: .8 full time

            TA: .2 full time

 

Table H-1 covers the full two-year duration of the project.  A full work year is 2080 hours.  Vista's fringe benefit package includes 160 hours of annual leave (vacation, personal, sick) and ten holidays (80 hours).  This leaves 1840 hours in a "delivered" person year, or 153.33 hours in a "delivered" person month.  Hence, to convert the person-month figures of Table H-1 to hours, simply multiply by 153.33.

 


 

 

class=Section9>

              Table H-1. Proposed Allocation of Labor to Project Tasks, by Month

                                           (Table entries are delivered person months)

 

 

      Staff                                    Task

Month Member    1    2           3          4          5          6          7   Total

                                                                                                                                   

  1    PI1      .2  .55                                                       .05       .8

       PI2            .1                                             .1

       SA           .8                                             .8

                         TA                              .2                                                                      .2

           

 2         PI1                              .775                                                     .025     .8

                         PI2                              .1                                                         .1

                         SA                              .8                                             .8

                  TA                         .2                                                                    .2

 

             3    PI1                            .05 .675                               .05       .025     .8

                         PI2                                 .1                                                      .1

                         SA                      .05 .7                                   .05                  .8

                         TA                                 .15                            .05      .2

 

             4         PA1                    .05 .675                               .05       .025 .8

                         PI2                                 .1                                                      .1

                         SA                      .05 .7                                   .05                   .8

                         TA                                 .15                            .05                   .2

 

             5    PI1                            .05 .675                               .05       .025     .8

                         PI2                                 .1                                                      .1

                         SA                      .05 .7                                   .05                  .8

                         TA                                 .15                            .05      .2

 

             6         PA1                    .05 .675                               .05       .025 .8

                         PI2                                 .1                                                      .1

                         SA                      .05 .7                                   .05                   .8

                         TA                                 .15                            .05                   .2

 


 

Month Member    1    2           3          4          5          6          7   Total

 

             7    PI1                            .05               .675                 .05       .025     .8

                         PI2                                                      .1                                              .1

                         SA                      .05               .7                     .05                  .8

                         TA                                                      .15                   .05      .2

 

             8    PI1                            .05               .675                 .05       .025     .8

                         PI2                                                      .1                                              .1

                         SA                      .05               .7                     .05                  .8

                         TA                                                      .15                   .05      .2

 

             9    PI1                            .05               .675                 .05       .025     .8

                         PI2                                                      .1                                              .1

                         SA                      .05               .7                     .05                  .8

                         TA                                                      .15                   .05      .2

 

             10   PI1                           .05               .675                 .05       .025     .8

                         PI2                                                      .1                                              .1

                         SA                      .05               .7                     .05                  .8

                         TA                                                      .15                   .05      .2

 

             11   PI1                           .05               .675                 .05       .025     .8

                         PI2                                                      .1                                              .1

                         SA                      .05               .7                     .05                  .8

                         TA                                                      .15                   .05      .2

 

             12   PI1                           .05               .65                   .05       .05       .8

                         PI2                                                      .1                                              .1

                         SA                      .05               .7                     .05                  .8

                         TA                                                      .15                   .05      .2

 


 

Month Member    1    2           3          4          5          6          7   Total

 

             13       PI1                                                                 .725     .05            .025     .8

                         PI2                                                                 .1                                .1

                         SA                                                                 .75       .05                   .8

                         TA                                                                  .15       .05                   .2

 

             14       PI1                                                                 .725     .05            .025     .8

                         PI2                                                                 .1                                .1

                         SA                                                                 .75       .05                   .8

                         TA                                                                  .15       .05                   .2

 

             15       PI1                                                                 .725     .05            .025     .8

                         PI2                                                                 .1                                .1

                         SA                                                                 .75       .05                   .8

                         TA                                                                  .15       .05                   .2

 

             16       PI1                                                                 .725     .05            .025     .8

                         PI2                                                                 .1                                .1

                         SA                                                                 .75       .05                   .8

                         TA                                                                  .15       .05                   .2

 

             17       PI1                                                                 .725     .05            .025     .8

                         PI2                                                                 .1                                .1

                         SA                                                                 .75       .05                   .8

                         TA                                                                  .15       .05                   .2

 

             18       PI1                                                                 .725     .05            .025     .8

                         PI2                                                                 .1                                .1

                         SA                                                                 .75       .05                   .8

                         TA                                                                  .15       .05                   .2


 

Month Member    1    2           3          4          5          6          7   Total

 

             19       PI1                                                                 .725     .05            .025     .8

                         PI2                                                                 .1                                .1

                         SA                                                                 .75       .05                   .8

                         TA                                                                  .15       .05                   .2

 

             20       PI1                                                                 .725     .05            .025     .8

                         PI2                                                                 .1                                .1

                         SA                                                                 .75       .05                   .8

                         TA                                                                  .15       .05                   .2

 

             21       PI1                                                                 .725     .05            .025     .8

                         PI2                                                                 .1                                .1

                         SA                                                                 .75       .05                   .8

                         TA                                                                  .15       .05                   .2

 

             22       PI1                                                                 .725     .05            .025     .8

                         PI2                                                                 .1                                .1

                         SA                                                                 .75       .05                   .8

                         TA                                                                  .15       .05                   .2

 

             23       PI1                                                                                          .8            .8

                         PI2                                                                                          .1            .1

                         SA                                                                                          .8            .8

                         TA                                                                                          .2            .2

 

             24       PI1                                                                                          .8            .8

                         PI2                                                                                          .1            .1

                         SA                                                                                          .8            .8

                         TA                                                                                          .2            .2

 

Month Member    1    2           3          4          5          6          7   Total

 

Total                   .2  4.525 6.5 9.725 17.25 3.0 4.4  45.6


 

                                                  Table H-2. Proposed Staff Loading

                                         (Table entries are delivered person months1/)

 

                                                                                    Task

Month Member    1     2     3     4     5     6     7   Total                                    

               PI1        .2  1.825  2.7   4.025 7.25  1.0   2.2   19.2

               PI2         0   .2     .4    .6   1.0     0    .2    2.4

               SA         0  2.1    2.8   4.2   7.5   1.0   1.6   19.2

               TA         0   .4     .6    .9   1.5   1.0    .4    4.8

Total                   .2  4.525  6.5  9.725 17.25  3.0   4.4   45.6

 

1/ Note: One delivered person month = 153.33 hours


Appendix I. Statement of Work for Short Takeoff / Vertical Landing (STOVL) Aircraft Evaluation

 

                                                    STATEMENT OF WORK

 

1.0  INTRODUCTION

 

1.1  This statement of work outlines the key elements of an operational utility analysis to determine the military worth of incorporating short takeoff/vertical landing (STOVL) aircraft into the USAF tactical force structure.

 

1.2  There is much current interest in developing a STOVL aircraft as a potential combat aircraft for the U.S. Air Force and the U.S. Navy.  Efforts in propulsion and structures technology and in system/subsystem integration have addressed the challenging STOVL design problem.  Recent studies sponsored by the Defense Advanced Research Projects Agency (DARPA) have been organized to develop a STOVL demonstration aircraft.  Assumptions have been made regarding the inherent operational advantages of STOVL capability.  The need remains for determining the answers to such questions as: Under what operational conditions or situations does STOVL present additional or improved mission capability and/or flexibility?  What are the operational advantages and disadvantages of STOVL in the force structure?  What conditions need to be met to best make use of a STOVL vehicle?  What are the field resources and costs associated with STOVL?

 

1.3  To address these and other questions, a comparative analysis is required to qualitatively and quantitatively evaluate a mix of existing and conceptual aircraft in a variety of basing concepts and threat environments.  It must treat the effect of factors such as logistics support, airbase operability, and combat effectiveness.  Due to the myriad of analysis cases that must be considered, minimization of the need for extensive databases and computations will be required.  Analysis methods must be identified or developed that are comprehensive but not data-intensive, so that thresholds to the values of the analysis variables can be realized within this study effort.

 

1.4  Expect results of the comparative analysis will be an array of operational situations and conditions in which either:  (a) the addition of STOVL to the force presents a clear and unchallenged advantage over other aircraft types, (b) STOVL has negative or no advantages, or (c) the outcome is unclear.  Measures of merit of both quantitative and qualitative nature will be generated on a comparative basis between STOVL, conventional takeoff and landing (CTOL), and short takeoff and landing (STOL) aircraft for relevant situations.  Results of this study will also be used in a Phase 2 effort that examines a selected array of situations in more detail.

 

2.0  SCOPE

 

2.1  This study will determine the relative effectiveness and cost of post-2000 STOVL fighter aircraft conducting air-to-air and air-to-surface combat sorties either autonomously or within a mixed force that includes CTOL and STOL vehicles.  The effort will be broad based, taking into account the elements of combat effectiveness, airbase operability, and logistics support.  Emphasis will be placed on analysis of cases in which aircraft force mixes are evaluated under a spectrum of operational environments.  Variations in scenarios, theater characteristics, basing options, threat levels, and missions are representative of a portion of the environment spectrum cases.

 

2.2  This Statement of Work covers the first phase of a two phase study.  Both phases have similar objectives and are expected to follow the same process of analysis.  Phase 1 will develop the required background data and will qualitatively as well quantitatively examine a number of analysis cases.  It will minimize the amount of database development by using existing databases and will perform analyses to a first-order level of detail, where appropriate.  Included in Phase 1 is a "pilot study" to test the methods and process with a limited data set; this is followed by development of databases and analysis of the full data set.  Phase 2, the subject of a follow-on statement of work, will build on the data and results of Phase 1.  This is expected to entail enhancement of required databases and more extensive analyses, but will work with only the most promising STOVL analysis cases identified in Phase 1.

 

2.3  Study Tasks include: background research; qualitative analysis, including the definition of cases for analysis and characterization of aircraft concepts and operational environments; identification and/or development of analysis methods and tools; completion of a pilot study; definition of data requirements and development of data; and analysis of the complete case matrix with effectiveness results.

 

2.4  Products of this study shall include reports and briefings describing the results of each task.  Details of deliverables are outlines in sections 4.0 and 5.0.

 

3.0  BACKGROUND

 

3.1  Initial Vertical/Short Takeoff and Landing (V/STOL) fighter designs were characteristically sized by vertical takeoff requirements, and, as a consequence, takeoff gross weights were 30% and greater than those of CTOL counterpart aircraft.  Because of the ever increasing threat performance, current mission requirements for CTOL fighters require enhanced performance characterized by highly sustained turn rates, high levels of energy maneuverability (Ps), rapid acceleration times, and supersonic speeds.  These requirements drive the fighter combat thrust to weight (T/W) ratio in excess of one.  Since combat weight is normally greater than landing weight at the end of a mission, vertical landing capability becomes a practical goal.  Additionally, some of the required technologies are now available and others are emerging, such as lightweight aircraft materials and structures, advances digital control systems, and propulsion technologies resulting from the near term high performance turbine engine (HPTE) initiative. Earlier studies have investigated the impact of enemy air attack on various fighter basing options and its effect on V/STOL operations.  The results were not always favorable for the combat/cost effectiveness of V/STOL concepts.  Removing the "VT" requirement for initial mission takeoff will improve the competitive combat capability of STOVL at a weight/cost much less than past V/STOL concepts.

 

3.2  Applicable documents that have addressed many of the issues relevant to STOVL fighter concepts are listed below.

 

            a.  V/STOL Technology Requirements for Future Righter Aircraft (U).  Final Report.  AFWAL-TR-80-3153.  Grumman Aerospace Corporation, Bethpage NY.  December 1980.

 

            b.  Combat Aircraft Effectiveness/Cost in an Airbase Attack Environment (U).  Final Report ASD-TR-81-5025.  McDonnell Aircraft Company, Fort Worth TX.  March 1981.  (Secret)

 

            c.  A Design and Comparison Study of V/STOL and C/STOL Aircraft (U).  Final Report.  AFWAL-TR-81-3020.  General Dynamics Corporation, Fort Worth TX.  March 1981.

 

            d.  Berman, M. B., Integrating Basing, Support, and Air Vehicle Requirements (U).  R-3304/1-AF.  The RAND Corporation, Santa Monica CA.  August 1985.

 

            e.  Combat Aircraft Effectiveness/Cost in an Airbase Attack Environment (CAE/CAAE) STudy (U).  Final Report.  ASD-TR-891-5034.  Grumman Aerospace Corporation, Bethpage NY.  January 1982.  (Secret)

 

            f.  Halliday, John M., Tactical Dispersal of Fighter Aircraft: Risk, Uncertainty, and Policy Recommendations (U).  RAND Note.  The RAND Corporation, Santa Monica CA.  February 1987.

 

4.0  TECHNICAL REQUIREMENTS/TASKS.  The contractor shall conduct a six (6) task investigative effort to aid in objective decision making regarding STOVL fighter capability and its military worth to the USAF in the post 2000 timeframe.  The six tasks are identified as: Task I - Background Research, Task II - Case Matrix Development and Qualitative Assessment, Task III - Requirements and Development, and Task VI - Effectiveness and Cost Analysis.  Significant interrelationships exist between many of the tasks, thus requiring the contractor to approach tasking in an iterative fashion to successfully complete this investigation.  Throughout this investigation, the contractor shall make maximum use of related past and on-going efforts within DoD and NASA.

4.1  Task I - Background Research.  By searching appropriate technical information source, the contractor shall develop a historical data base of useful background information relevant to the scope of this effort.  The search shall include comprehensive review of past and on-going Air Force, Navy and NASA STOVL and V/STOL studies concentrating on operational effectiveness evaluations.  The contractor shall document the results of this search by summarizing results and conclusions pertinent to this SOW and by providing title, report identification number, abstract, authorizing agency, and point of contact.  The purpose of the background research is two fold: first, to identify information regarding technology, aircraft concepts, basing and logistics support concepts, cost data, etc., that would support subsequent tasks and second, to avoid duplication of effort in determining the extent to which STOVL fighter concepts have been evaluated for their potential contribution to improving the flexibility/capability of the future USAF tactical fighter force.  Included in this task is the description of current concepts of operation of both CTOL and V/STOL aircraft.  The contractor shall interface with HQ TAC to define current operational doctrine as it relates to deployment into and employment within theaters worldwide.  Included shall be a definition of the basing concepts and corresponding logistics support.  In like manner, the contractor shall examine current V/STOL operations as exercised by the British with the Harrier aircraft.  The results of this task shall be documented (CDRL #3).

 

4.2  Task II - Case Matrix Development and Qualitative Assessment.  In this task, the contractor shall characterize aircraft design concepts and operational environments which will be the basis for cases to be analyzed in Task VI.  Further, the contractor shall perform a qualitative assessment of the advantages and disadvantages of STOVL based on these characterizations.

 

the contractor shall review DoD planning guidance and interface with appropriate DoD organizations including HQ TAC regarding requirements and relevant issues when developing the operational environments.  Existing and notional operational environments shall include the following elements (other factors, such as weather condition, shall be treated in the sensitivity analysis of Task VI):

 

            - Scenarios

            - Mission Concepts

            - Basing Concepts

            - Logistics Support Concepts

 

4.2.1  Case Matrix Development.  The case matrix is an array of aircraft concept options and an array of operational environment options.  An aircraft option (single aircraft type or force mix of different aircraft types) applied to an operational environment option (scenario, mission, basing, and logistic support) defines a "case" for analysis.  Development of this case matrix includes the following sub-tasks: (1) identification of the options, (2) description of the options, and (3) combination of options and selection of cases to be analyzed.

 

4.2.1.1  Identification of Options.  The basic aircraft concept options are that of notional 2005-2015 STOVL, CTOL and STOL aircraft.  To provide comparative analysis data, a current configuration and derivatives of existing aircraft shall also be considered as options.  Variations to these options (e.g., with or without rough field landing gear) shall be treated in Task VI as excursions.  For the operational environment options:

 

            - Scenarios: The contractor shall develop a sufficient set of conflict scenarios to form the basis for the remaining tasks under section 4.2.  The scenarios will be derived from existing DoD and/or Air Force planning documents where appropriate.  One of the scenarios shall be a high intensity war in Europe.  The remaining scenarios shall be chosen, subject to Air Force approval, based on background research and discussions with HQ TAC and other appropriate Air Force sources.  Consideration os and sensitivity to the capability to deploy rapidly and fight in remote areas of potential conflict shall be a criterion for selection.  Possible additional scenarios would be a third-world "brushfire" war and an RDF-like deployment to an area with few in-place friendly facilities, such as South-West Asia.

 

            -Mission Concepts: Options shall include various missions postulated for tactical fighters in the 2005-2015 timeframe.  The contractor shall define appropriate tactical air-to-air and air-to-ground mission concepts to include, but not limited to, defensive counter air (DCA) (to include air base defense), offensive counter air (OCA), and close air support/battlefield air interdiction (CAS/BAI).

 

            - Basing Concepts: The contractor shall explore, evaluate and apply innovative ideas to develop new/alternative basing concepts which take full advantage of the STOVL aircraft characteristics.  Development of basing concepts shall also address possible joint Air Force/Army doctrine supporting the Air Land Battle 2000 Concept and Air Force/Navy directives providing joint tactical wartime operations support.  The basing concepts shall range from the large fixed infrastructure associated with current main operating bases (MOBs) to compact mobile basing concepts exemplified by portions of the British, Swedish and Soviet Air Forces.

 

            -Logistics Support Concepts: Options shall include alternative/innovative logistics support concepts which are compatible with the aircraft concepts and basing concepts.  The contractor shall describe existing as well as new logistics support concepts which emphasize mobility and flexibility.

 

4.2.1.2  Description of Options

 

4.2.1.2.1  Aircraft Concepts.  The contractor shall functionally characterize each aircraft concept using parameters that clearly impact on mission effectiveness and differentiate among the aircraft types.  Data required includes a narrative description of the design features, outline of avionics capabilities, estimates of payload capability, gross weight and size, and representative performance characteristics.

4.2.1.2.2  Scenarios.  Scenario options will include descriptions of the events leading up to the armed conflict, identification of the objectives of each opposing force (Red and Blue) and the basic operational doctrine being pursued by each side.  In addition, a description of the theater of operations and basic support resources will also be included.  Where appropriate, "World Wide Non-Nuclear Threat to Airbases" (SECRET, Sep 88) shall be used as an authoritative document to describe enemy counter-air operations.

 

4.2.1.2.3  Mission Concepts.  Mission concepts shall be describes to include, but not limited to mission objectives, tasks, profiles, and timelines.  Mission concepts must address operations in demanding threat and environmental conditions.  The contractor shall describe the target and threat spectrum for the various mission concepts.  This shall include (1) tactical target types and structure (soft/hard/fixed/mobile/air/ground targets) and (2) typical tactical air-defense threats to include those associated with low intensity/third world conflicts to include those conflicts evolving the latest and most up-to-date aircraft and weapons that could be introduced by the Soviets in a post 2000 high intensity/NATO conflict.  A standardized data sheet shall be developed to qualitatively describe characteristics of the various mission concepts.  These data sheets shall later be supplemented with data generated in Task V (Data Development - paragraph 4.5) to form a complete qualitative as well as quantitative description of the mission concepts.

 

4.2.1.2.4  Basing Concepts.  The contractor shall representatively describe: (1) MOBs, including planned/reasonable modifications for improved MOB capability such as additional runways, taxiways, shelters, shelter ingress/egress routes, soil bearing capacity, runway repair capabilities, command control and communications (C3), camouflage, concealment and deception (CCD), airbase defense systems, etc., (2) a full range of forward operating locations (FOLs) to include operations similar to forward Army aviation units, and (3) a series of remote/austere/dispersed bases/sites to include satellites dispersal (SD), which is defined as aircraft dispersal within the confines of or close proximity to the MOB, and remote dispersal (RD), which is defined as aircraft dispersal at various distances from the MOB, such as road sites or parking lot operations.  Contractor shall describe the vulnerability of basing concepts to various levels of air and ground threats.  The contractor shall develop standard data sheets to describe basing concepts similar to those defined in paragraph 4.2.1.2.3.

 

4.2.1.2.5  Logistics Support Concepts.  Descriptions shall include, but not be limited to, maintenance concepts (levels of repair), chemical/biological/radiological (CBR) maintenance requirements, levels of aircraft self-sufficiency, manpower, support equipment, facilities, supply networks, aircraft servicing/rearming tasks and initial deployment/resupply of various basing concepts.  The contractor shall describe the vulnerability of logistics support concepts to various levels of air and ground threats.  A standardized logistics support concept data sheet shall be developed by the contractor to describe logistics support concepts similar to those defined in paragraph 4.2.1.2.3.  the contractor shall examine the following documents to aid in describing the vulnerability of airbase/logistics support concepts: (1) World Wide Non-Nuclear Threat to Airbase 1985-1995, revised 1988 (HQ USAF/IN); (2) Time Estimates for Interim Bomb Damage Repair Techniques, ESL-TR-84-43.  It is widely known that weapons contribute to the large support requirements for tactical fighters.  Therefore, the contractor shall also address logistics concerns regarding weapons consumption and support.

 

4.2.1.3 Combination of Options, Selection of Cases.  The contractor shall combine each of the options of the elements of scenarios, missions, basing and logistics support, eliminating combinations based on a consideration of the dependency of the options.  One example is that of the logistics support and basing concept dependency.  The resulting combination of options form the basis for cases to be analyzed.  The resulting combination of options form the basis for cases to be analyzed.  The analysis process itself (as in Task VI) will determine the cases that need to be evaluated.  For instance, to analyze the sensitivity of basing options, it may be unnecessary to analyze each basing option within each scenario; rather, it may be more appropriate to analyze a single scenario, supplemented within selected cases from the other scenarios.  This process of structuring cases for evaluation permits a down-selection within this task.  Questions and issues as outlined in Task VI should be used as guidance in selecting the cases.

 

4.2.1.4  The contractor shall document the case matrix development and submit for Air Force review (CDRL #3).  The case matrix shall representatively depict/bound a sound set of CTOL/STOL/STOVL comparative situations.

 

4.2.2  Qualitative Assessment.  The contractor shall apply the characterizations developed in this task and previous task to qualitatively assess the military worth of STOVL aircraft.  The contractor shall address the general questions introduced in paragraph 1.2, the question set of Task VI, and the developed case matrix.  The assessment shall examine the relative advantages or disadvantages that could result from the use of STOVL in the force structure, particularly with regard to basing and base operations, timeliness of response, for effectiveness and flexibility, survivability, and supportability.  Consideration shall be made of operations in peacetime, in rapid reinforcement during crises alerts, and in the conduct of high tempo combat situations.  The unique capabilities of STOVL fighter aircraft may provide new employment opportunities for tactical air forces.  In this task, the contractor shall develop a number of concepts of operation that match the capabilities of STOVL aircraft to the relevant tactical missions in the theaters and scenarios of interest.  The contractor shall apply the concept of basing flexibility (ability to disperse aircraft, locate them closer to their objectives, operate from alternate surfaces, reduce reaction time, etc.) in developing these concepts of operation.  Qualitative measures of merit shall be developed to make comparisons.  The contractor shall document the qualitative assessment (CDRL #3).

 

4.3  Task III - Assessment Methodology Definition

 

4.3.1  The contractor shall identify and/or develop an assessment methodology to evaluate on a comparative basis the relative benefits and limitations of the various fighter aircraft within the operational environments described in Task II.  The contractor's selected methodology shall have the capability to support trade studies identifying the critical differences between CTOL, STOL, and STOVL aircraft in tactical fighter operations.  The principal results from exercising the contractor's selected assessment methodology in regard to STOVL capability and its military worth to the USAF in the post 2000 timeframe.

 

4.3.2  The contractor's assessment methodology shall reflect a balanced analytical design which will permit the evaluation of existing and conceptual aircraft in a variety of basing concepts and threat environments.  It shall be comprehensive to treat the three major factors which affect weapon system capability, i.e., logistics support factors, airbase operability, and mission effectiveness.  The selected methodology shall provide traceable insight of how the aforementioned factors influence effective delivery of tactical air power.  It shall include specific measures of merit which will be used to assess results.  Figure 1 shows in simplest terms the elements which must be included in the contractor's assessment methodology for weapon system comparisons.  The methodology shall have the capability to conduct sensitivity analyses based upon parametric variations in aircraft characteristics, force mixes, basing characteristics, logistic support characteristics, mission requirements, threat levels, and cost constraints.  The methodology shall be suitable to also address the questions and issues outlined in Task VI.  Candidate quantitative measures of merit shall be submitted for Air Force review (CDRL #3).

 

4.3.3  Simulation software shall be capable of modeling the events that occur at the airbase during peacetime and combat operations including the influence of air and ground attacks on the airbase (resultant loss of resources) and different aircraft R&M and support concepts.  Simulation software shall also have the capability to model events that occur during combat engagement as well as those logistics events influencing initial deployment and resupply.  The simulation software shall include cost algorithms permitting LCC studies and cost effectiveness comparisons.  Because the ASD/XR All Mobile Tactical Air Force (AMTAF) model has been developed specifically to satisfy most of these objectives, it shall be used in this contract as the primary tool for quantitative analysis.  The AMTAF model was developed by VERAC, Incorporated, San Diego, California (now Ball Systems Engineering Division) under Air Force Small Business (SBIR) contact.  Use of the AMTAF model does not restrict the contractor from complementing AMTAF capabilities with other models satisfying needs of this study.  Candidate methodologies/models shall be submitted/presented to the Air Force for comment and review (CDRL #3).

 

4.4  Task IV - Pilot Study.

 

4.4.1  The contractor shall employ/utilize the assessment methods defined in Task III and selected data sets in a pilot study to test the appropriateness of each computer simulation model, generate data sensitivities and isolate potential problem areas.  As required, the contractor shall adapt/modify selected analysis methodology, develop additional capability, and/or revise data requirements to satisfy the objectives of Task VI.  Contractor shall comply with government re-direction regarding pilot study results.

4.4.2  The selected data set shall be agreed to by the government prior to conducting the pilot study simulation.  Results of the pilot shall be documented as well as formally presented to the government.  Documentation and presentation shall include organizational arrangement of the calculation procedures, data input/output, data flow, and demonstration of the software (CDRL #3 and CDRL #5).

 

4.5  Task V - Data Requirements and Development.  The contractor shall identify quantitative data requirements and develop data bases commensurate with the input requirements of the proposed analytical simulation models.

 

4.5.1  Data shall be developed which quantitatively represent the spectrum of operational environments as described in the case matrix developed in Task II.  Quantitative description sections of the data sheets initiated in paras 4.2.1.2.3, 4.2.1.2.4, and 4.2.1.2.5 shall be completed under this task.

 

4.5.2  The contractor shall make use of data base management software for automated recordkeeping of data input/data output.  This recordkeeping shall correlate quantitative values with the qualitative descriptions to form complete data item descriptions of the operational environments within the case matrix.  The contractor shall be responsible for maintaining current, consistent and approved information in the data base throughout the contract.  Maximum use of existing data bases shall be made.  The results of Task V shall be documented (CDRL #3).

 

4.6  Task VI - Effectiveness and Cost Analysis.  The efforts to be conducted by the contractor under this task draw upon the results generated by all previous tasks.  the contractor shall exercise the quantitative analysis techniques as developed in Task III, the data developed in Task V, and the changes which resulted from the pilot study in Task IV to assess the benefits and limitations of aircraft concepts in the various combinations of basing concepts and logistics concepts, scenario, and mission from Task II.  The primary focus of this task is to evaluate the combat effectiveness and costs of the force structure in conducting mission sorties.  Analysis shall be accomplished in the context of autonomous operations as well as a mixed force that includes STOVL, CTOL, and STOL vehicles.  Within the case matrix, STOVL may be considered as a replacement to an existing aircraft, as a supplement to the primary force, or as a separate, special-purpose force, as in an airbase defense fighter.  One-to-one comparisons could be made between STOVL and CTOL in the first example, but not in the last two.  However, in all examples, it is expected that the contractor shall evaluate the effectiveness of the overall force, and hence will measure the contribution of the STOVL portion of the force.  To the extent possible, all analysis shall be done on a comparative basis to depict the relative differences between the various CROL, STOL, and STOVL concepts.  Analysis will be first order level with higher level analysis as appropriate for assessment of critical issues.  A technology and cost risk assessment shall also be accomplished under this task.

 

4.6.1  Questions and Issues.  The following questions and issues must be addressed in evaluating the utility of STOVL.

 

            A.  For the European scenario, in what mission applications does STOVL have a particular advantage, if any, over current capability or over advanced CTOL or STOL?

 

            B.  Must STOVL be integrated in large numbers into the TAF, or are there conditions/situations where a small number of STOVL would significantly enhance overall tactical capability (i.e., if STOVL was used as a separate special force, what role would if play and which mission application of the primary force would benefit the most?)

 

            C.  What type of basing is associated with the conclusions of questions A and B?  What is the sensitivity of these conclusions to basing options?

 

            D.  What level of logistics support and logistics support concepts are consistent with the basing options of question C?

 

            E.  What are the key differences between STOVL, CTOL and STOL that affect the conclusions of questions A, B, C and D?

 

            F.  To what extent are the conclusions to questions A, B, C and D dependent upon existing, near-term or projected technological capability?

 

            H.  On a comparative basis, what is the cost/effectiveness associated with the conclusions of questions A through F?  Are cost within projected budget constraints for the TAF?

 

            I.  Of particular interest is how the conclusions to the above questions are sensitive to variations to the following aircraft factors and operational factors.

 

                                                      AIRCRAFT FACTORS

 

-Levels of system/subsystem reliability and maintainability to include amount of aircraft on-board/built-in support equipment

 

- Changes in speed including supersonic persistance

 

-Different range requirements relative to concepts and missions

 

-Different levels of low observables (IR, RCS, visual signatures)

 

-Amount of Aircraft maneuverability

 

-Degree of interservice/intraservice subsystem/parts commonality

 

-Differences in mission equipment (avionics/sensors)

 

- Variations in landing and takeoff distances

 

-Alternative aircraft landing characteristics, i.e., chutes, improved brakes, thrust reversing; and other arresting techniques

 

- Aircraft taxi characteristics/capability

 

 

 

                                                  OPERATIONAL FACTORS

 

- Changes to length and intensity of conflict

 

-Changes to base protection/security capability (i.e., characteristics which influence airbase vulnerability, such as ground security, air defense assets, CCD, sheltering, facility hardening, asset dispersal/mobility)

 

-Degree of vulnerability of base logistics supply lines

 

- Levels of weapon support requirements

 

- Weather conditions at airbase

 

-Characteristics of airbase attack (timing, intensity, assets attacked)

 

-Amount of airbase facility and runway capability

 

4.6.2  Effectiveness Analysis.  The contractor shall conduct peacetime and combat effectiveness analysis of STOVL concepts to answer the questions and issues outlined in paragraph 4.6.1.  The analysis shall be conducted, and the results presented, at the level of analysis consistent with the scope of each question.  It is a comparative analysis or STOVL with other aircraft alternatives, and in most cases, it must be done at the airbase or higher-force level.  The combat effectiveness analysis shall be based upon a 5-7 day surge followed by a 30-60 day sustained combat effort.  Primary combat measures of merit shall be sortie rates, target kill rates, and attrition rates.  Primary peacetime measures of merit shall be expressed in terms of cost measures (para 4.6.4).  To treat some of the questions parametrically, the effectiveness analysis may require the assumption of technical feasibility and/or unconstrained costs.  Criticality of these assumptions are to be addressed in paragraph 4.6.3 and 4.6.4.

 

4.6.3  Technology/Risk Assessment.  For those conditions that have been identified as having particular advantage for an aircraft concept and had required the assumption of technical feasibility, the contractor shall determine the likelihood that the candidate concept could be successfully developed and fielded.  The contractor shall identify the critical technologies or design issues associated with the concept, and shall perform risk assessment based on both technology and cost.

 

4.6.4  Cost Studies.  The purpose of this task is to determine the affordability of those conditions in which STOVL exhibits operational advantages over CTOL or STOL.  Of particular interest is if STOVL capability is cost effective as bound by the realistic budget projections for the TAF in the 2005-2015 timeframe.  The approaches outlined below permit cost effectiveness analyses under various constraints such as combat effectiveness, fleet size and funding limitations.

 

            The contractor shall estimate aircraft life cycle cost (LCC) and combine these with the results of the effectiveness analysis in para 4.6.2 to make rough order of magnitude cost-effectiveness comparisons between STOVL, CTOL and STOL aircraft.  LCC estimates shall be based upon a 25-year life cycle segregated by RDT&E, Production and O&S.  Critical cost factors shall be identified between the various combinations of aircraft concepts and operational environments.  Combat cost-effectiveness comparisons shall be based upon (A) Fixed Effectiveness Analysis (establish the level of combat effectiveness, determine number of aircraft required, determine cost), (B) Fixed Budget Analysis (fix total budget, determine aircraft buy, determine combat effectiveness) and (C) Continuously Fixed Fleet Size (fixed number of aircraft, replace as attrited during combat, determine combat effectiveness).  Combat cost shall consist of increased consumables and other support requirements associated with combat.

 

            Peacetime cost comparisons shall be based upon 25 LCC for (A) Fixed Buy (equal number of aircraft, determine cost) and (B) Fixed Budget (total budget determines number of aircraft).

 

4.6.5  Evaluation of Point Designs.  Distinct from the generic aircraft concepts of the case matrix, the Air Force will provide parametric design data for four specific designs: supersonic CTOL, supersonic STOVL, subsonic CTOL, and subsonic STOVL.  The contractor shall apply these design data to evaluating their relative combat effectiveness.

 

4.6.6  Conclusions.  The contractor shall combine the results of this task to make sound, conclusive recommendations regarding the overall utility of STOVL fighter concepts in the future tactical force structure.  The contractor shall prepare a comprehensive report (CDRL #4) and present a comprehensive briefing (CDRL #5) which summarizes the entire study effort; however, the results, conclusions, and recommendations of Task VI shall be emphasized.

 

5.0  REPORTS, DATA AND REVIEWS

5.1  Reports and data shall be in accordance with the preparation and submission requirements set forth in the Contractor Data Requirements List (CDRL), DD Form 1423.  Project status reports (summarizing progress made and work planned) and performance and cost reports are to be delivered monthly in accordance with CDRL #1 and CDRL #2.  Contract funds status report is CDRL #7.

 

5.2  Meetings and Reviews.  The contractor shall present his plans for accomplishing the required tasks and the results of his work at meetings attended by selected Air Force personnel.  The first will be a kickoff meeting to occur no later than 30 days after contract initiation.  As a minimum, the contractor shall present the work plan to perform the tasks of the statement of work, the schedule with manhour expenditure rates, personnel assignments, and discussion of major issues.  The second and third meetings will occur no later than 20 days following completion of task II and IV, respectively.  In addition, it is anticipated that several informal meetings will be arranged for Air Force review and exchange of information, principally during the accomplishment of tasks V and VI.  The final meeting will be held at the completion of the contract.  The contractor shall present an oral summary of all work performed and the analytical results at this final program review.  The final program review will be held at Wright-Patterson AFB.  The date for the review shall be coordinated with the program manager at least 20 days prior to the meeting.  Following all formal meetings, the contractor shall submit copies of presentation material and minutes covering significant discussions and action items (CDRL #6).

 

CDRL #1  Monthly Status Reports (Performance)

            #2  Monthly Status Reports (Manhours & Cost)

            #3  Interim

            #4  Final

            #5  Briefing

            #6  Meeting Minutes

            #7  Funds Status Report

            #8  Management Plan