Attachment_1_-_AFSIM.pdf

DISTRIBUTION STATEMENT A. Approved For Public Release. (Case #: 88ABW-2016-6198)

ADVANCED FRAMEWORK FOR SIMULATION, INTEGRATION

AND MODELING (AFSIM)

Version 2.0

OVERVIEW AND TECHNICAL REFERENCE

James Zeh, AFRL/RQQD

Brian Birkmire, AFRL/RQQD

Nicholas A. Chinnici

Peter D. Clive

Jeffrey Johnson

Andrew W. Krisby

Jonathon E. Marjamaa

Luke B. Miklos

Michael J. Moss

Stephen P. Yallaly

August 2016

AIR FORCE RESEARCH LABORATORY

AEROSPACE SYSTEMS

WRIGHT-PATTERSON AIR FORCE BASE, OH 45433-7801

AIR FORCE MATERIEL COMMAND

UNITED STATES AIR FORCE

TABLE OF CONTENTS

Section Page

LIST OF FIGURES & TABLES

1.0 OVERVIEW

1.1 INTRODUCTION

1.2 PLATFORMS

1.3 PLATFORM COMPONENTS

1.3.1 MOVERS

1.3.2 SENSORS

1.3.3 COMMUNICATIONS

1.3.4 WEAPONS

1.3.5 PROCESSORS

1.3.6 OTHER COMPONENTS

1.4 ADDITIONAL PLATFORM CAPABILITIES

1.4.1 ELECTROMAGNETIC INTERACTIONS WITH TRANSMITTERS AND RECEIVERS

1.4.2 ANTENNA PATTERNS

1.4.3 ATTENUATION, PROPAGATION, FLUENCE, AND CLUTTER MODELS

1.4.4 ELECTRONIC WARFARE EFFECTS

1.4.5 COMMUNICATIONS NETWORKS

1.4.6 LINK-16 TADIL-J

1.4.7 TRACKING AND FILTERING

1.4.8 TASKS

1.4.9 BEHAVIOR MODELING

1.5 SIMULATION SERVICES

1.5.1 SCRIPTING LANGUAGE

1.5.2 TERRAIN AND LINE-OF-SIGHT MANAGEMENT

1.5.3 EVENT LOGGING AND STANDARD OUTPUT

1.5.4 EXTENSIONS AND PLUG-INS

1.5.5 DISTRIBUTED SIMULATION INTERFACES

1.5.6 MONTE CARLO ITERATION AND DESIGN OF EXPERIMENTS

1.6 LIMITATIONS AND ASSUMPTIONS

2.0 AFSIM SOFTWARE DISTRIBUTION

2.1 AFSIM APPLICATIONS

2.1.1 WSF EXEC

2.1.2 SENSOR PLOT

2.1.3 WEAPON TOOLS

2.2 AFSIM IDE

2.3 VESPA

2.4 STANDARD IADS SCENARIOS

2.5 TARGET MACHINE REQUIREMENTS

2.6 DISTRIBUTION

APPENDIX A - AFS IM COMMUNICATION, S ENSOR AND JAMMING EQUATIONS

APPENDIX B - AFS IM S YNTHETIC APERTURE RADAR EQUATIONS

APPENDIX C - AFS IM ELECTRONIC WARFARE OVERVIEW

APPENDIX D - REACTIVE INTEGRATED PLANNING ARCHITECTUR E (RIPR)

APPENDIX E - HIS TORICAL DEVELOPMENT OF AFSIM

LIST OF ACRONYMS, ABBREVIATIONS, AND S YMBOLS

List of Figures & Tables

Figure Page

FIGURE 1: AFSIM PLATFORM COMPOSITION

FIGURE 2: GRAPHICAL REPRESENTATION OF AN EXAMPLE TASK PROCESSOR STATE MACHINE

FIGURE 3: AN EXAMPLE RIPR BEHAVIOR TREE

FIGURE 4: AFSIM CONSTRUCTIVE ANALYSIS PROCESS USING THE AFSIM IDE

FIGURE 5: THE AFSIM IDE DEMO BROWSER

FIGURE 6: VESPA GUI

TABLE A-1: TRANSMITTED POWER VARIABLES

TABLE A-2: FREE SPACE PROPAGATION VARIABLES

TABLE A-3: FREE SPACE REFLECTED SIGNAL VARIABLES

TABLE A-4: FREE SPACE RECEIVED POWER VARIABLES

TABLE A-5: BANDWIDTH RATIO VARIABLES

TABLE A-6: RECEIVER POWER VARIABLES

TABLE A-7: ANTENNA GAIN VARIABLES

TABLE A-8: PROCESSED POWER VARIABLES

TABLE A-9. SIGNAL AND NOISE VARIABLES

TABLE A-10. PASSIVE RECEIVER NOISE VARIABLES

TABLE A- 11. SAR COLLECTION TIME VARIABLES

TABLE A-12: COMMUNICATIONS SIGNAL AND NOISE VARIABLES

TABLE A-13: IRST CONTRAST RADIANT INTENSITY VARIABLES

TABLE A-14: IRST PROBABILITY OF DETECTION VARIABLES

TABLE B-1: RADAR RANGE EQUATION VARIABLES

TABLE B-2: RECEIVER NOISE VARIABLES

TABLE B-3: SAR DWELL TIME VARIABLES

TABLE B-4: RANGE PROCESSING GAIN VARIABLES

TABLE B-5: RESOLUTION CELL VARIABLES

TABLE B-6: PSEUDO-IMAGE GENERATION VARIABLES

FIGURE C-1. EW TECHNIQUES ARCHITECTURE

FIGURE C-2. JAMMING SYSTEM ARCHITECTURE IN AFSIM SHOWING EA TECHNIQUES

FIGURE C-3. RADAR SYSTEM ARCHITECTURE IN AFSIM SHOWING EP TECHNIQUES

FIGURE C-4. MAPPING OF EA AND EP INTERACTIONS IN THE AFSIM EW ARCHITECTURE

FIGURE C-5. HIERARCHY OF BASE TYPE EFFECTS FOR EA

FIGURE C-6. HIERARCHY OF BASE TYPE EFFECTS FOR EP

TABLE C-1. EFFECT COHERENCY TYPES

TABLE C-2. JAMMING POWER TYPES

TABLE C-3. JAMMING EFFECTS VARIABLE STRUCTURE

TABLE C-4. SIGNAL EFFECTS VARIABLE STRUCTURE

TABLE C-5. TRACK EFFECTS VARIABLE STRUCTURE

TABLE C-6. MESSAGE EFFECTS VARIABLE STRUCTURE

TABLE C-7. AGGREGATION TYPES

FIGURE C-7. AFSIM EW INTERACTION FLOWCHART

FIGURE D- 1: QUANTUM TASKER METHOD OF OPERATION

FIGURE D- 2: RIPR BEHAVIOR TREE

FIGURE D- 3: RIPR ROUTE FINDER

FIGURE D-4: HEAT MAP EXAMPLE

file:///G:/2016/AFSIM/PublicRelease/AFSIM_V2%200_Overview_Technical_Reference_IST.docx%23_Toc459989108 file:///G:/2016/AFSIM/PublicRelease/AFSIM_V2%200_Overview_Technical_Reference_IST.docx%23_Toc459989109

1.0 OVERVIEW

1.1 Introduction

AFSIM is a government-approved software simulation framework for use in constructing engagement and mission-level analytic simulations for the Operations Analysis community. The primary use of AFSIM applications is the assessment of new and advanced system concepts, and the determination of concepts of employment for those systems.

The framework provides the ability to model the capabilities of the participants and to control the interaction of the participants as they move through space and time. The resulting simulat ions can be:

Constructive/non- interactive (the user invokes the simulation which then runs without further interaction), or interactive (the user or other simulation controls some aspects of the simulation.

Non-real-time (faster or slower depending on the fidelity of the platform component models), or real-time (constrained by some multiple of a real-time clock).

Event-stepped (simulations proceed according to processing of relevant events) or time-stepped (simulations proceed according to events occurring in succeeding time steps)

AFSIM is designed to be generally usable “as is,” so that not only are top-level modeling concepts defined by the framework, but many concrete implementations are also provided.

Examples of standard models delivered with the framework include the following:

Movement models

Sensor systems

Weapon systems and weapon effects

Communication systems

Information processing systems (trackers, etc.)

Decision making systems (command and control, missile guidance, etc.)

Antenna pattern models

Atmospheric attenuation models

Signal propagation models

Clutter models

Electronic warfare effect models

AFSIM is also extensible, providing for ease of incorporating models of the above types, as well as completely new capabilities. Because AFSIM is a framework, simulation details and services are provided, freeing the developer to focus specifically on adding desired new functionality through implementation of the framework’s abstract interfaces. Additiona lly, AFSIM’s Component-Based Architecture (CBA) provides the ability to cleanly and generica lly incorporate nearly any new modeling capability into the framework. Once incorporated, the models are then as much a part of the framework as any of the standard models.

AFSIM simulations are typically used to evaluate the performance of military systems in the context of a mission. To be successful, the framework must provide the capability to model the performance of the participants within the environment of the missions. In AFSIM, the individua l participant is referred to as a platform, which in some simulations is called an entity. Platforms represent things such as aircraft, satellites, missiles, ships, submarines, ground vehicles, structures and life-forms. The platform contains components such as communications, sensors and weapons systems, and information and decision-making systems. These components are used to gather, process, and disseminate information, make command decisions, and carry out the commands. The framework, with its supplied component models, as well other component models that may have been added, provides the capabilities to model the platforms participating in the simulation.

This section provides a general overview of the Advanced Framework for Simulat ion, Integration and Modeling (AFSIM). Section two provides a description of the standard AFSIM software distribution, including standard AFSIM applications, the AFSIM Integrated Development

Environment (IDE), AFSIM IADS scenarios, and Visual Environment for Scenario Preparation and Analysis (VESPA). Specific algorithms and detailed model descriptions are covered in the appendices of this document, which together serve as the AFSIM technical reference guide. This document does not, however, provide detailed descriptions of user inputs, the AFSIM scripting language, or the IDE. These are detailed in the AFSIM Wiki, which serves as the reference manual for AFSIM commands. Similarly, learning to use AFSIM is accomplished either by taking the AFSIM Analyst course or through study of the many examples and demonstrations that accompany the AFSIM release.

1.2 Platforms

AFSIM platforms are composed of attributes, information, components and links (see Figure

1). Attributes include the name, type, affiliation and commander of the platform. Other physical attributes include its radar, optical and infrared signatures, defining its susceptibility to being seen by a sensor at a specified aspect angle. Information stored on the platform includes measurements, tracks, tasks, and human perceptions; these form the basis upon which platforms make decisions.

Platform components include definitions of movement, sensors, communications, weapons and processing (either to model mental or computing components), which are described individually in the following sections. Finally, internal and external links provide communication via messages.

Figure 1: AFSIM Platform Composition

Internal links tie individual internal platform components together in a flexible way. External links provide inter-platform communication through communication devices.

1.3 Platform Components

Platform components provide the models for the physical and mental/computing operating capabilities of a platform. Many standard component models are provided with the framework, some of which are described in the following paragraphs.

Component models delivered with AFSIM are often provided at various levels of fidelity.

For example, an aircraft can be modeled with a simple route mover or with a full pseudo 6-DOF

(six degrees of freedom) aerodynamics and control model. Another example is communicat ions models that can either deliver messages perfectly, or that are based on electromagnetics and subject to signal loss. These choices provide the flexibility to easily configure a simulat ion using lower-fidelity models, or, to provide necessary effects with higher fidelity ones.

AFSIM also allows new component models (sensors, weapons, etc.), as well as completely new component types to be inserted and utilized. Although beyond the scope of this document, describing and teaching this process is a main theme of the AFSIM Software Developer Course.

1.3.1 Movers

A mover is an optional component providing the means by which a platform moves through space-time (a platform without a mover is geographically fixed). The simulation affects the movement of platforms and ensures a platform’s position is current before involving it in any interactions with other platforms or the simulated environment.

There are many types of standard mover models, providing the capability to represent platforms in every domain, from seabed to space. Some examples of movers delivered with AFSIM include the following:

WSF_AIR_MOVER – A route mover for air vehicle motion

WSF_GROUND_MOVER – A route mover for a terrain-following ground vehicle

WSF_ROAD_MOVER – A ground mover that moves on a road network and is able to traverse a shortest path along it

WSF_SURFACE_MOVER – A route mover for a surface ship

WSF_SUBSURFACE_MOVER – A route mover for a submersible vehicle

WSF_NORAD_SPACE_MOVER – A mover for a platform in orbit about the Earth

WSF_GUIDED_MOVER – A mover that is capable of representing a guided glide bomb or a single or multistate guided missile

WSF_TSPI_MOVER – A mover that updates position based on Time Space Position Information (TSPI) data read from a text file

WSF_FIRES_MOVER – A mover for an indirect fire (rocket, artillery, mortar) round

WSF_P6DOF_MOVER – A high-fidelity, pseudo-6DOF mover, providing angular and translational kinematics

1.3.2 Sensors

Sensor systems are used to sense the environment around platforms. There are many types of standard sensor models, some of which are:

WSF_ACOUSTIC_SENSOR - Baseline acoustic sensor model

WSF_AMBER_SENSOR - Provides an interface to the TMAP AMBER radar models

WSF_EOIR_SENSOR - Electro-Optical/Infrared (EOIR) sensor model

WSF_ESM_SENSOR - Baseline passive RF detection sensor

WSF_GEOMETRIC_SENSOR - Baseline sensor based purely on geometry

WSF_IRST_SENSOR - Baseline infrared search-and-track sensor

WSF_OPTICAL_SENSOR - Baseline optical sensor model

WSF_OTH_RADAR_SENSOR - Baseline Over-The-Horizon Backscatter (OTH-B) sky wave radar model

WSF_RADAR_SENSOR - Baseline radar model

WSF_SAR_SENSOR - Baseline synthetic aperture radar (SAR) model

WSF_SOSM_SENSOR - Interface to the Spectral Optical (IR) Sensing Model (SOSM)

WSF_SURFACE_WAVE_RADAR_SENSOR - Over-the-horizon radar surface wave sensor model

Many sensors, such as the RADAR sensor models, implement modeled electromagne tic interactions and are subject to jamming.

1.3.3 Communications

Communications systems are used to transmit information from one platform to another. In addition to model choice, the framework also provides a rich set of networking options, detailed in the next section. AFSIM offers three system models:

WSF_COMM_TRANSCEIVER – Implements perfect or wired communications

WSF_RADIO_TRANSCEIVER – Implements radio frequency communications

WSF_JTIDS_TRANSCEIVER – Implements JTIDS/Link 16 communications

WSF_RADIO_TRANSCEIVER and WSF_JTIDS_TRANSCEIVER both implement modeled electromagnetic interactions and are subject to jamming.

1.3.4 Weapons

Weapons systems are used to either lethally or non-lethally attack another platform or platform component. Weapons can utilize launch computers to make firing decisions, and they employ configurable weapon effects. AFSIM weapons can be either explicit or implicit. Explicit weapons create new (weapon) platforms representing missiles, bombs, etc., when fired. Implicit weapons do not create weapon platforms and are used to model non-kinetic weapons such as high-energy lasers and jammers, as well as kinetic weapons with predictable trajectories, such as artillery.

The weapon components delivered with AFSIM are the following:

WSF_EXPLICIT_WEAPON represents a weapon that is modeled as an independent platform when it is fired.

WSF_IMPLICIT_WEAPON represents a weapon that does not require an independent flyout.

WSF_RF_JAMMER is a radio frequency jammer that can be used to disrupt radar, ESM and radio communication systems.

WSF_LASER_WEAPON represents a High-Energy Laser (HEL) weapon with an independently configurable laser fluence model.

WSF_CUED_LASER_WEAPON is an implementation of WSF_LASER_WEAPON that is cued by a separate beam director sensor.

Note that there is only one explicit weapon model. This is because the wide range of possibilit ies for missiles, bombs, etc., is achieved by configuring weapon platform types with their own unique platform components. For example, a missile can be specified as a weapon platform type configured with a guided mover and guidance computer (processor), and it is the mover and guidance computer that are configured to model the unique characteristics of the missile.

1.3.5 Processors

Processors are used to implement the mental or computing processing capabilities of a platform. There are many processors available in the standard framework, among the most common being:

WSF_SCRIPT_PROCESSOR – A general purpose processor for executing scripts, written with the AFSIM scripting language, to implement custom behaviors and custom processing

WSF_TASK_PROCESSOR – A scriptable, finite-state machine for making command and control decisions about the tracks known to a platform.

WSF_RIPR_PROCESSOR – A more advanced scriptable processor for making command and control decisions

WSF_GUIDANCE_COMPUTER – Implements a guidance computer for missiles

WSF_GROUND_TARGET_FUSE and WSF_AIR_TARGET_FUSE – Implements a fusing mechanism for a weapon platform

WSF_IMAGE_PROCESSOR – Simulates analysis of ‘images’ produced by imaging sensors

WSF_MESSAGE_PROCESSOR – A scriptable router and interpreter of messages

WSF_TRACK_PROCESSOR – Accepts tracks from on-board and off-board sources and feeds them to the track manager. Also sends periodic updates of local tracks to other platforms

Depending on its implementation, a processor may be invoked periodically or as the result of some event such as the reception of a message or the expiration of a time interval.

1.3.6 Other Components

AFSIM platforms can also utilize other component types, such as the following:

Command Chain – Provides the platform’s command and control reporting structure

Fuel – Provides fuel consumption and refuel capability

Intersection Mesh – Provides a representation of the platform’s detailed geometry, against which ray-tracing calculations can be made

Navigation Errors – Models the platform’s computed location

Visual Part – Provides a component that can be used for visualization purposes and to compute geometry

If a new component type is needed that is not provided with the standard AFSIM distribution, it can be integrated using the AFSIM’s Component Based Architecture (CBA, newly introduced in version 2.0). AFSIM CBA provides an abstract platform component interface that is extended to easily add new and existing base component types, as well as component “extensions” that add additional functionality for existing sensor, processor, and weapon components. Using CBA, integrating new and existing capabilities on platforms is not only generic and simple, but using and understanding them is often much easier as well.

1.4 Additional Platform Capabilities

1.4.1 Electromagnetic Interactions with Transmitters and Receivers

Representations of transmitters and receivers are used by platform components (sensors, communications, and certain types of weapons) to simulate the transmission and reception of electromagnetic (EM) radiation. The framework accomplishes this simulation through ensuring a consistent set of EM interactions between transmitters and receivers. Utilizing this software architecture, AFSIM naturally allows for such effects as jamming and passive detection.

1.4.2 Antenna Patterns

Antenna patterns are attached to transmitters and receivers. A simple antenna pattern is a two-dimensional table that provides gain as a function of azimuth and elevation off the pointing angle of the antenna. The framework allows patterns to be defined using two-dimensional tables or using one of several algorithmic patterns. There are also several other optional sensor models that provide additional pattern models. A polarization and frequency-dependent antenna pattern may also be defined.

1.4.3 Attenuation, Propagation, Fluence, and Clutter Models

Attenuation models are available to limit (attenuate) propagated EM signal. Among the attenuation model choices available in the framework are several standard radar-specific options as well as a general model for optical attenuation.

Propagation models in AFSIM are designed to model specific effects at radar wavelengths;

options for multipath, ground wave propagation, and knife edge effects are available.

Fluence models simulate high energy laser propagation. AFSIM provides a core fluence model as well as an interface to the industry-standard HELCoMES fluence model.

AFSIM also provides the ability to employ a low-angle clutter model to simulating radar backscatter, and the resulting noise, from terrain. These models utilize the full set of clutter backscatter coefficients from MIT/Lincoln Labs studies.

1.4.4 Electronic Warfare Effects

Transmitters associated with systems such as RF jammers (e.g., WSF_RF_JAMMER) may define the abilities of the transmitter to electronically attack receivers, thus implementing Electronic Attack (EA) techniques. Similarly, receivers associated with sensors or communicat ions systems (e.g., WSF_RADAR_SENSOR or WSF_RADIO_TRANSCEIVER) may define the ability of the receiver to mitigate the effects of an electronic attack, thus implementing Electronic

Protect (EP) techniques. The list of available EA and EP techniques, and their effects, is fully described in Appendix D, “AFSIM EW Architecture.”

1.4.5 Communications Networks

AFSIM provides the capability to model the network associated with the passing of messages by communications devices. Multiple communications devices act as nodes on a network, and networks can have gateways to other networks. Messages are intelligently routed from source to destination. One can specify a link-layer protocol for realistic transmission times. Message queuing and filtering are also supported.

1.4.6 Link-16 Tadil-J

AFSIM is delivered with the capability to send and receive Link-16 Tadil-J messages over communications devices. Received messages are processed with user-defined AFSIM scripts. One may also send and receive these messages over distributed simulation interfaces, so that AFSIM platforms can participate as nodes in a virtual distributed command and control network.

1.4.7 Tracking and Filtering

The track is the fundamental object that represents the information known about another object such as a platform or a transmitter. That information may describe the physical state of an object (location, velocity, etc.), or it may describe other features (side, type, etc.). The object may or may not be real, and the information generally contains errors. Thus, a track represents the imperfect knowledge of what a platform perceives about another object. It is the primary input to most of the decision-making process, and because it can represent flawed knowledge, poor decisions can be made.

The amount of information in a track depends on its source and filtering or fusion processes that may have been applied. A sensor may provide range and bearing, or it may only produce range bearing and elevation. It may also provide affiliation and type (e.g., IFF), measurement quality, etc.

Overwhelmingly, tracks represent the products of sensor measurements. Multip le measurements must be associated, or “correlated” with each other to create and update a track. This correlation process presents the opportunity to mistakenly group measurements with incorrect objects or with no object at all. In the latter case, false targets are produced. AFSIM offers several options for correlation, giving the analyst the option to either explore or ignore such effects.

A primary role of tracking is to provide as accurate an estimate as possible to truth. It is the job of filtering to provide these estimates, especially for the kinematic data. For this purpose, AFSIM includes a standard set of filters, providing location and velocity state estimates. The framework is also flexible enough to allow integration of nearly any kind of filter.

The other very important goal of tracking is to intelligently combine data from measurements and tracks to produce as complete an operational picture as possible. Often, new data will be computed or inferred in this process called fusion. AFSIM is delivered with a standard fusion engine, and the framework allows substitution with other fusion algorithms as desired.

1.4.8 Tasks

The AFSIM task management service provides the capability to send and receive task assignments, perform the tasks, and provide the status information for dealing with those assignments. Tasks are usually associated with a track; for example, initiate a sensor tracking request cued to a track location, fire a weapon at the given track location, etc.

1.4.9 Behavior Modeling

The execution of tasks is performed with the AFSIM scripting language, and this is the most common method by which platform behaviors are implemented. Two options provided by the framework for task execution are the

WSF_TASK_PROCESSOR and the WSF_QUANTUM_TASK_PROCESSOR. The

WSF_TASK_PROCESSOR utilizes a finite state machine, for which tracks move between states, and scripts implement behaviors based on the current state (see Figure 2, in which the circles represent states and arrows represent transition rules). The

WSF_QUANTUM_TASK_PROCESSOR utilizes a behavior tree (Figure 3), an artific ia l intelligence technology in which behaviors are created and arranged as nodes in a graph or “tree.”

The behavior nodes can be arranged together in interesting and interrelated ways, providing more flexibility in how behaviors are selected and executed. The artificial intelligence architecture and behavior trees are described further in Appendix D.

Figure 2: Graphical representation of an example task processor state machine.

Figure 3: An Example RIPR Behavior Tree

1.5 Simulation Services

1.5.1 Scripting Language

The AFSIM scripting language provides a mechanism for the user to execute a complex set of instructions based upon events that occur in the simulation. The language is similar to C# and Java and should be familiar to anyone with basic programming skills. It is block-structured and contains familiar declaration, assignment, and flow control statements that allow the user to examine and manipulate the simulation environment. Some uses of the scripting language include the following:

Implement tactics and doctrine

Data collection

Dynamic configuration of objects based on mission options

Simulation control

1.5.2 Terrain and Line-of-Sight Management

Terrain is used by the framework to perform such actions as determining if objects involved in interactions are obscured by terrain, determining if an airborne object crashes into the ground, or to constrain a ground vehicle to the ground. Acceptable forms of terrain data include National

Geospatial Agency (NGA) Digital Terrain Elevation Data (DTED) and Arc-Info Float Grid format.

1.5.3 Event Logging and Standard Output

The framework implements an “observer” capability that allows simulation components to be notified of the occurrence of certain events (e.g.: turning a sensor on, sensor detection attempts, firing a weapon, sending a message assigning a task, etc.). This capability is used to implement event logging without having to modify all sections of the code. Several forms of standard output are provided. Additionally, AFSIM provides the capability for the user to write scripts to perform any desired functions such as writing a custom output file or accumulating statistics.

1.5.4 Extensions and Plug-Ins

Extensions and plug-ins are the primary mechanisms by which the framework is extended to integrate new platform component models, new and extended platform capabilities, and new and extended simulation services. The plug-in capability is a form of extension that allows one to add capabilities without re-compiling the core AFSIM code. Use of plug-ins allows for easier distribution of extended capabilities, and they provide the ability to choose which extended capabilities to use for a given analysis.

1.5.5 Distributed Simulation Interfaces

The observer capability is also utilized to implement distributed simulation interfaces. AFSIM provides three such standard interfaces:

DIS (Distributed Interactive Simulation) interface, which allows an AFSIM simula t ion to participate as one application in a DIS exercise.

High Level Architecture (HLA) interface, which allows an AFSIM simulation to participate as one HLA federate in a HLA exercise.

XIO (eXternal Input/Output) interface, providing a multi-machine capability, wherein two or more AFSIM simulations interact without the limitations of DIS and HLA. XIO can also be used to interface AFSIM simulations with GUIs and other user input devices, providing operator-in-the-loop capabilities.

1.5.6 Monte Carlo Iteration and Design of Experiments

AFSIM provides the capability to perform a set of simulation runs at a time, where each run starts with a different random number seed, and variability is introduced among the runs due to the differing set of random numbers produced. This is often called Monte Carlo iteration. There are many options within AFSIM to introduce this desired variability among runs, enabling its use in design of experiments (DOE) studies.

1.6 Limitations and Assumptions

There are very few constraints on the bounds of the mission. The number of platforms is limited only by the amount of memory available and the amount of time one is willing to wait. The mission may cover the whole world from underwater to space. Mission duration can be very long:

months or years.

There are no inherent limitations imposed by the framework on platforms or their components with regard to their performance. Any platform can detect, communicate with, shoot or control any other platform. Any limitations are due either to the how the model is configured (user input) or limitations of a platform component model. Such limitations can be overcome through

Changing the parameters of the existing platform component model to reflect the desired fidelity.

Choosing a different platform component model with the desired fidelity.

Acquiring a different platform component model with the desired fidelity.

For example, unless otherwise indicated, a sensor will attempt to detect all other platforms in the simulation. The user can make the assumption that it can distinguish friends from enemies and prevent detection attempts against friendly platforms, thus saving a lot of computation time.

Another example is that a user may choose WSF_GEOMETRIC_SENSOR to model a radar system very simply (e.g. if the target is within 50 miles it can be seen). The user has assumed that this is a viable assumption, but if proven otherwise, the user can choose WSF_RADAR_SENSOR for more fidelity. The point is that the user is in charge of most limitations of this kind.

In order to complete a mission, platforms must have some sort of information on which to act. The truthfulness and accuracy of the information often governs the success of the mission.

Assume a commander receives information that a target is located at a specific location and commands an asset to destroy the target. If the location had significant errors, or if the target did not really exist (it was a false report or the target had already been destroyed and the commander had not been informed), time and resources would have been wasted chasing a target that wasn’t there, thus potentially preventing the destruction of a real target. The framework imposes no inherent limitation on the viability of the information in a track. It can contain errors and does not have to correspond to a real platform.

2.0 AFSIM SOFTWARE DISTRIBUTION

2.1 AFSIM Applications

2.1.1 WSF Exec

The baseline AFSIM simulation application is called the World Simulation Framework

Executive (Wsf Exec). Wsf Exec reads a user-defined input file, executes the simulation, and outputs any user-defined data files. As Wsf Exec incorporates all standard AFSIM features, it is used to execute all simulation demos and scenarios included with AFSIM releases, including the

AFSIM IADS scenarios. Wsf Exec also most often provides the simulation engine used by the AFSIM IDE to execute simulation scenarios within an information-rich, graphical context.

Note: Wsf Exec is likely to undergo a name change, to become “AFSIM Mission.”

2.1.2 Sensor Plot

Sensor Plot is an AFSIM application that is used to evaluate sensor characteristics and interactions with user-specified geometries. It has the ability to create files that produce plots of

Sensor vertical coverage

Sensor horizontal coverage

Sensor spherical coverage

Defended area of a collection of sensors

Antenna patterns

2.1.3 Weapon Tools

Weapon tools is an AFSIM application that repeatedly fires a predefined WSF_EXPLICIT_WEAPON over widely varied engagement conditions for the purpose of creating the various launch computers required for making acceptable weapon firing decisions. It currently allows for creation/generation of launch computers for air/air, air/ground, and ballistic missile (ground/ground).

2.2 AFSIM IDE

The AFSIM Integrated Development Environment (IDE) supports the analyst in defining and integrating AFSIM platforms and platform components. The AFSIM IDE patterns itself on IDEs created for use with software development. With software IDEs, a single application is used to edit files, compile, link, and run the software executable, and view output results or error messages.

Likewise, the AFSIM IDE permits the analyst to edit input files, execute an AFSIM application, and visualize the output results and any error messages. The iterative process that allows the analyst to receive immediate feedback as platform and component models are defined and scenarios created is illustrated in Figure 4.

Note: AFSIM IDE is likely to undergo a name change, to become “AFSIM Wizard.”

Figure 4: AFSIM Constructive Analysis Process Using the AFSIM IDE

Current capabilities of the AFSIM IDE to support input file creation include file syntax highlighting, auto-completion, context-sensitive command documentation, a variety of scenario browsers, and a script debugger. Syntax highlighting makes reading and understanding the content easier for the analyst. Unknown keywords or commands are underlined in red for easy discovery.

Examples of unknown keywords or commands include misspelling of keywords or using keywords out of scope. The auto-completion feature provides a list of suggestions for the analyst to choose from, based on the context. The analyst can select one of the suggestions, and the command will be completed without having to manually type the command. Context-sensitive command documentation allows the analyst to bring up documentation associated with a command to illustrate the scope and use of the command. Other AFSIM IDE capabilities are available to assist the analyst in defining platform and component models and scenarios.

With the IDE’s built-in Demo Browser, analysts can look through over thirty example scenarios. These scenarios demonstrate the vast capabilities of AFSIM broken down into smaller, focused pieces. The demos serve as a great starting point for creating new scenarios as well as reference for adding to existing scenarios.

Figure 5: The AFSIM IDE Demo Browser

The AFSIM IDE can execute any AFSIM-based application using the input files defined by the analyst. Any screen output from the application is displayed in an IDE output window along with any error messages.

Current capabilities of the IDE to view simulation results include the ability to run the VESPA application from the IDE using the AFSIM replay file created during the simulation run.

A general plug-in capability is also part of the AFSIM IDE. This supports the development of features that are needed by a limited user set. This feature includes the plug-in interface to the application, and user-interface to manage plug-ins within the applications.

2.3 VESPA

The Visual Environment for Scenario Preparation and Analysis (VESPA) software application enables creation of scenario initial condition files compatible with any AFSIM-based application. In addition, VESPA can be used to visualize object positional time histories and other event information generated as output from any AFSIM-based application. This allows the analyst to quickly understand and analyze the output from the simulation. Since VESPA is a “DIS-listener” visualization tool, it may also be used to display real-time entity interactions from any real- time simulation that publishes DIS data.

Figure 6: VESPA GUI

VESPA includes a graphical user interface (GUI) that includes a drawing area with a geospatial map and a data input area, as shown in Figure 5.

Using VESPA, the analyst can place icons representing objects at specific latitude and longitude locations on a geospatial map. Initial conditions can then be assigned for each selected object. For example, the initial conditions of an aircraft could be its speed, heading and altitude.

Visual features associated with objects, called attachments, can also be created. Examples include routes, range rings and zones.

VESPA can be used to display object positional histories and events using an AFSIM replay file generated during an AFSIM simulation run. The AFSIM replay file is a binary file containing the DIS output from the AFSIM simulation. In addition, plots can be generated for selected events that occurred during the simulation.

2.4 Standard IADS Scenarios

The AFSIM classified distribution includes several standard IADS (Integrated Air Defense System) based scenarios. Algorithms and software from the Air Force mission level model were incorporated into the AFSIM, including sensor modeling algorithms, the missile flyout code, and the command chain logic in standard scenarios. Both the scenario data base (SDB) and type data base (TDB) files for these scenarios have been translated into AFSIM input format, and all Air

Force mission level model updates are then performance verified with the AFSIM IADS. This includes comparisons of sensor vertical coverage diagram (VCD) plots for all sensor types in these scenarios, as well as missile flyout comparisons for all surface-to-air missile (SAM) types. The result is a continuous verification and validation (V&V) process to standard scenarios. Additiona l information on the pedigree of the AFSIM IADS model can be requested by contacting the AFSIM model manager.

2.5 Target Machine Requirements

AFSIM applications are currently distributed as 32-bit and 64-bit Linux and Windows executables. As they can be run from the command line, there are few restrictions on the target machine’s configuration, other than the operating system. However, because the IDE and VESPA are graphical applications, there is the added restriction that the target machine should possess a relatively modern graphics chip or card. Although compatibility is not guaranteed, VESPA and IDE will generally function well with graphics chips/cards manufactured on or after 2005. Four or more GB of memory is recommended.

2.6 Distribution

Distribution of AFSIM is coordinated through AFRL/RQQD (Aerospace Systems

Directorate, POC Brian Birkmire). An Information Transfer Agreement (ITA) must be completed to receive either the unclassified or classified distribution, and an appropriate DD254 must be presented by government contractors to acquire the classified distribution.

Appendix A- AFSIM Communication, Sensor and Jamming Equations

A.1 Overview

The purpose of this document is to describe the equations and algorithms used in the interactions between objects in AFSIM. This includes:

Sensor interactions

Communication interactions

Disruption (jamming) interactions

A.2 Common Radio Frequency Equations

AFSIM utilizes a common set of classes to encapsulate the components involved in radio frequency (RF) interactions (in reality, some features of these classes are also used for non-RF interactions, but that is not important here). The first section of the document will deal with the basics of signal transmission and reception. Subsequent sections of the document will deal with specific uses (radar, SAR, ESM, jamming, communications).

Ignoring the details of the processing of the received signal, RF interactions fall into two classes:

Direct or one-way, i.e., an emitted signal going directly to a receiver

Indirect or two-way: i.e., an emitted signal reflected from an object and then received

The computation of the received signal power can be broken into distinct steps:

Emission from the transmitting antenna

Propagation to the target or the receiver

For indirect or two-way interactions

Reflection from the target

Propagation from the target to the receiver

Reception by the receiving antenna

A.3 Calculation of direct transmitted power

(RF.1)

x x peakx

L

G

DCPP

Table A-1: Transmitted Power Variables

Symbol Source Description

Gx transmitter antenna_pattern

The gain of the transmitting antenna in the direction of the target object

(receiver or platform). This includes any electronic beam steering losses

(Equation RF.6).

Lx transmitter internal_loss

The internal losses in the transmitter between the power source and the antenna.

DC transmitter duty_cycle

The user defined duty-cycle of the transmitter (default: 1.0, if not defined).

Ppeak transmitter power

The peak power of the transmitter. This should be the power of a single pulse.

Px Computed The transmitted power.

A.3.1 Propagation of the signal in free space

The propagation of a free space signal from the source (s) to the destination (d) is computed using the following equation. In a one-way interaction, ‘s’ and ‘d’ are the transmitter and receiver respectively (Equation RF.2b). In a two-way interaction, there are two propagation paths. The first is from the transmitter to the target (Equation RF.2c) and the second is from the target to receiver

(Equation RF.2d).

(RF.2d)receiver-to-Target

(RF.2c)target-to-rTransmitte

(RF.2b)receiver-to-rTransmitte

(RF.2a) FormGeneral tr tr ttr xt xt xxt xr xr xxr sd sd ssd

R

A

PD

R

A

PD

R

A

PD

R

A

PD

Table A-2: Free Space Propagation Variables

Asd transmitter attenuation_model

The fraction of the signal that remains after computing the effects of atmospheric attenuation while propagating the signal from the source

(s) to the destination (d).

Dsd Computed The computed free space power density at the destination (d) that originated from the source (s).

Ps Computed The power emitted from the source (s). This will be either the transmitted power (Equation RF.1) or the reflected power from a target

(Equation RF.3).

Rsd Computed The slant range from the source (s) to the destination (d).

A.3.2 Reflecting a free space signal

A target that reflects a free space signal effectively creates a new ‘transmitting source’. The power of the source is simply the product of the signal density of the incoming signal times the effective area of the reflecting source. The reflector can be a platform (such as when performing a two-way radar interaction) or can be the surface of the earth (when performing clutter calculations).

The reflected power can then be propagated to a receiver by application of equation RF.3.

(RF.3)txtt DP

Table A-3: Free Space Reflected Signal Variables

Dxt Equation RF.2c The power density at the target (t) of the signal that originated from the transmitter (x).

Pt Computed The power created by the reflection of the incoming signal off of the target.

σt radar_signature of the target platform

The radar cross section of the target.

A.3.3 Reception of a free space signal

RF.4a is used for direct, one-way (communications, passive RF and jamming). RF.4b is used two-way (Radar, SAR).

(RF.4b)receiver-to-Target way,-Two

(RF.4a)receiver-to-rTransmitte way,-One

F L

G

DP

FF

L

G

DP

r r trr

POLBW

r r xrr

Table A-4: Free Space Received Power Variables

FBW See section 2.5

The fraction of the received signal that is admitted, accounting for possible mismatches in the frequency/bandwidth of the transmitted and the frequency/bandwidth of the receiver.

Note: this is not incorporated for radar interactions because it is assumed that the transmitter and receiver are matched.

FPOL transmitter polarization receiver polarization polarization_effects antenna_pattern

The fraction of the received signal that is admitted, accounting for possible mismatches in the polarization of the transmitter and the receiver.

Note: This is not incorporated for radar interactions because it is assumed that the transmitter and receiver are matched.

F40 transmitter propagation_model

The pattern propagation factor. This accounts for the constructive/destructive interference between the direct and indirect signal paths.

Note: This is currently only implemented for radar interactions.

Dxr Equation RF.2b The power density at the receiver of the signal that originated from the transmitter.

Dtr Equation RF.2d The power density at the receiver of the signal that was reflected from the target.

transmitter wavelength

The wavelength of the transmitted signal.

Gr receiver antenna_pattern

The gain of the receiving antenna in the direction of the target object

(receiver or platform). This includes any effects of electronic beam steering (Equation RF.6).

Lr receiver internal_loss

The internal losses in the receiver between the output of the antenna and the receiver.

Pr Computed The received power.

A.3.4 Bandwidth ratio

The factor FBW is used to account for the fact that the frequency spectrum of the transmit ter may not match the tuning band of the receiver. It is the fraction of the transmitter spectrum that is within the tuning band of the receiver.

receiver theoffrequency ngUpper tuni receiver theoffrequency ngLower tuni spectrum ed transmittoffrequency Upper spectrum ed transmittoffrequency Lower rrru rrrl tttu tttl

BFF

BFF

BFF

BFF

Table A-5: Bandwidth Ratio Variables

Br receiver bandwidth

The bandwidth of the receiver.

Bt transmitter bandwidth

The bandwidth of the transmitter.

Fr receiver frequency

The center frequency of the range of frequencies the receiver can receive.

Ft transmitter frequency

The center frequency of the transmitter frequency spectrum.

The resulting value of FBW depends on the relationship of the upper and lower frequencies of the transmitter and receiver.

(RF.5)0.1,

),max(),min( min xlxu rlxlruxu

BW

ruxlBW rlxuBW

FF

FFFF

F

FFifF

FFifF

A.3.5 Receiver noise power

The following definitions apply to the computation of receiver noise power:

Table A-6: Receiver Power Variables k Internal constant Boltzmann’s constant (1.3806505E-23 J/deg-K).

B receiver bandwidth

-- or --transmitter pulse_width

The bandwidth of the receiver. If the bandwidth was not specified AND if the transmitter is pulsed, the bandwidth will be computed as (1 / pulse_width) (i.e.: A matched filter will be assumed).

N Computed The noise power.

NF receiver noise_figure

The receiver noise figure (default 1.0).

T0 Internal constant Standard temperature (290 deg-K).

Ts Computed The system noise temperature.

The noise power will be computed using the following process. The value from the first step whose conditions for use are satisfied will be used:

1. If noise_power was specified, used the defined value.

2. If the bandwidth cannot be determined, use the value of -160 dBW.

3. If noise_figure was specified and both antenna_ohmic_loss and receive_line_loss were omitted, compute the noise power as:

(RF.6a)0 NFBTkN

4. Compute the noise power using the algorithm defined in “Radar Range Performance”, Lamont V. Blake, 1986, Artech House, Inc., Chapter 4.

Noise temperature due to the antenna (Tant = sky temperature due to the antenna pointing angle):

(RF.6b)__/)0.254876.0(0 lossohmicantennaTTT anta

Noise temperature contribution due to receive line loss:

(RF.6c))0.1__(0 losslinereceiveTTl

Noise temperature contribution due to the receiver:

(RF.6d))0.1_(0 figurenoiseTTr

Total system temperature:

(RF.6e))__( rlas TlosslinereceiveTTT

Noise power:

(RF.6f)BTkN s

A.3.6 Antenna Gain Patterns

Each transmitter and receiver has associated with it an antenna gain pattern. Antenna patterns are created using the global antenna_pattern command. An antenna pattern is attached to a transmitter or receiver by using the antenna pattern command inside the transmitter and receiver block. If an antenna pattern has not been selected for a transmitter or receiver, a uniform gain of

1.0 will be assumed.

The gain pattern is a function of azimuth and elevation with respect to the pattern origin

(typically the bore sight or pointing angle). For a given interaction, the azimuth and elevation of the point of interest with respect to the pattern origin is computed.

Antenna gain patterns may be represented in several ways:

A rectangular table which provides the gain as a function of azimuth and elevation.

A table.

A uniform (constant) pattern.

A circular sin(x)/x pattern.

A rectangular sin(x)/x pattern.

A cosecant pattern.

A GENAP pattern (GENAP is a subset of the functionality provided by generalized antenna pattern routine found in the government TRAMS model).

Collections of tables may be used to form a composite pattern of polarization and frequency.

The gain of an electronically steered beam can be optionally modified to include the effects of pointing the beam at an angle off the normal of the array. This capability is enabled by using the electronic_beam_steering command in the transmitter or receiver. The following equation is used:

RF.7)(cos0 nGG

Table A-7: Antenna Gain Variables

G0 antenna_pattern The unmodified gain of the antenna when looking at the point of interest.

G Computed The gain, modified to include the effects of electronic beam steering.

θ Computed The angle between the normal to the antenna face and the vector to the point of interest.

N electronic_beam_ steering_loss_ exponent

An optional exponent to reflect the amount of degradation of the gain as the beam is moved away from the normal of the antenna face.

A.3.7 Atmospheric Attenuation

Computation of atmospheric attenuation is enabled by the presence of the atmospheric_attenuation command inside the transmitter block.

There are currently two models available. These were extracted from Air Force models and are currently only applicable to ground-based systems (the tables assume the emitter is on the ground).

An atmospheric absorption model written by L.V. Blake, Naval Research Laboratory.

This is based on a family of 42 attenuation curves for frequencies between 100 MHz and 10 GHz and elevation angles between 0 and 10 degrees. The curves are flat beyond 300 nautical miles. These tables were published in 'Radar Systems Analysis’, Section

15.1, David K. Barton, Artech Publishing.

A collection of pre-computed tables that are valid for frequencies in the range 100 MHz to 18 GHz and 27 GHz to 40 GHz. Frequencies less than 100 MHz will assume 100 MHz. Frequencies between 18 GHz and 27 GHz and above 40 GHz will use a very computationally- intensive method to determine the attenuation and should be avoided.

There is another model in development based on the International Telecommunications Union

(ITU) Recommendation ITU-R P.676. That implementation will work for air and surface platforms and support a wider range of frequencies.

A.3.8 Propagation Algorithms

Computation of propagation effects (other than atmospheric attenuation) is enabled by the presence of the propagation_model command inside the transmitter block.

This currently supports one model:

fast_multipath - An implementation of the method defined in 'Radar Range Performance Analysis’, Lamont V. Blake, 1986, Artech House, Inc. It computes the effects of constructive or destructive interference due to the specular reflection of the signal off of a round, rough Earth.