Int'l Conf.

Scientific Computing | CSC'15 | 73

Advanced Framework for Simulation, Integration and

Modeling (AFSIM)
(Case Number: 88ABW-2015-2258)

Peter D Clive*, Jeffrey A Johnson*, Michael J Moss*, James M Zeh†, Brian M Birkmire†, and Douglas D Hodson‡
*
The Boeing Company
St. Louis, MO
†
Aerospace Systems Directorate
Air Force Research Laboratory
Wright Patterson Air Force Base, OH
‡
Computer Science and Engineering Department
Air Force Institute of Technology, USA

Abstract— The Advanced Framework for Simulation, environment, visualization tools and AFSIM’s agent modeling
Integration and Modeling (AFSIM) is an engagement and architecture. The following section highlights the
mission level simulation environment written in C++ originally current/planned effort to create a Component Based
developed by Boeing and now managed by the Air Force Architecture for AFSIM which will allow multiple levels of
Research Laboratory (AFRL). AFSIM was developed to address
releasability. The last section provides a conclusion on AFSIM
analysis capability shortcomings in existing legacy simulation
environments as well as to provide an environment built with and its current state.
more modern programming paradigms in mind. AFSIM can A. Background
simulate missions from subsurface to space and across multiple
levels of model fidelity. The AFSIM environment consists of three AFSIM is based on The Boeing Company’s Analytic
pieces of software: the framework itself which provides the Framework for Network-Enabled Systems (AFNES). Under
backbone for defining platforms and interactions, an integrated contract, Boeing delivered AFNES to the Air Force
development environment (IDE) for scenario creation and (specifically AFRL/RQQD) with unlimited rights, including
scripting, and a visualization tool called VESPA. AFSIM also source code, in February 2013. AFRL/RQQD rebranded
provides a flexible and easy to use agent modeling architecture AFNES as AFSIM and has begun to distribute AFSIM within
which utilizes behavior trees and hierarchical tasking called the the Air Force and DoD, including DoD contractors.
Reactive Integrated Planning aRchitecture (RIPR). AFSIM is
currently ITAR restricted and AFRL only distributes AFSIM
The Boeing Company developed and funded the AFNES
within the DoD community. However, work is under way to simulation framework through internal research and
modify the base architecture facilitating the maintenance of development (IR&D) funding from 2003-2014. Beginning in
AFSIM versions across multiple levels of releasability. 2005, Boeing began developing a customized AFNES
capability to simulate threat Integrated Air Defense Systems
Index Terms— Simulation Framework, Mission Level Model, (IADS) to assess advanced air vehicle concepts performing
Artificial Intelligence Framework, Agent Framework Precision Engagement missions. The requirements of this new
IADS simulation capability included being able to match
I. INTRODUCTION results with the Air Force-approved mission level model. The
AFSIM is a government-approved C++ simulation reason for developing an AFNES alternative to the Air Force
framework for use in constructing engagement and mission- IADS modeling capability relates to the limitations associated
level analytic simulations for the Operations Analysis with the Air Force mission level model. Examples of areas in
community, as well as virtual experimentation. The primary which the Air Force mission level model is lacking include:
goal of AFSIM applications is the assessment of new system expansion of representations of Electronic Warfare (EW)
concepts and designs with advanced capabilities not easily techniques; the integration of independent tracking and
assessed within traditional engagement and mission level correlation systems; utilization of vendor-supplied auto-routers
simulations. Development activities include modeling weapon and mission optimization capabilities; net-centric
kinematics, sensor systems, electronic warfare systems, communications systems; the contribution of Space assets; and
communication networks, advanced tracking, correlation, and integration of special, existing models, such as AGI’s System
fusion algorithms, and automated tactics and battle Tool Kit (STK).
management software. The AFNES IADS capability became operational in 2008,
In this section, the reasons for the development and history and is currently being utilized by multiple Boeing development
of AFSIM are presented. The next section provides an programs, as well as government contracted programs, to
overview of the AFSIM architecture, integrated development assess the ability of advanced air vehicle design concepts to

DISTRIBUTION STATEMENT A. Approved for public release; distribution is unlimited.

74 Int'l Conf. Scientific Computing | CSC'15 |

penetrate advanced Air Defense networks and conduct The top-level characteristics and capabilities of the AFSIM
precision engagement missions. In 2010, the AFRL/RQQD framework include:
Aerospace Vehicles Technology Assessment & Simulation x A class hierarchy of simulation objects, including data
(AVTAS) Lab (formerly AFRL/RBCD) commissioned a trade driven platforms, movers, sensors, communications
study of M&S Frameworks for the purpose of assessing networks, processors, weapons, and simulation
potential alternatives to replace or augment their current observers.
constructive simulation environment. The result of the AFRL x Simulation and Event classes to control time and/or
trade study was the selection of AFNES as the best M&S event processing for AFSIM-based models, and the
framework to meet their air vehicle mission effectiveness logging of entity data.
analysis requirements. x Standard math libraries for coordinate systems (WGS-
84, Spherical, ENU, NED), random number
II. AFSIM SOFTWARE SUITE
generation, DIS communication, High-Level
The AFSIM software suite consists of three distinct pieces Architecture (HLA) publish and subscribe, and
or applications. The first piece is the framework itself which generalized software routines, such as container
provides the underlying architecture and services allowing the classes for storing objects and data.
creation of simulation applications. The second piece is the x A common geo-spatial environment and terrain
integrated development environment (IDE) which facilitates representation, importing standard formats such as
the creation of scenarios. Lastly the Visualization Environment National Geospatial-Intelligence Agency (NGA)
for Scenario, Preparation and Analysis (VESPA) application Digital Terrain Elevation Data (DTED), ESRI,
allows for post-processing and visualization of scenario GeoTiff and VMAP database formats.
executions. This section provides detail on all three. x A general-purpose scripting language to provide
A. Functional Architecture access to framework objects using text input files (i.e.,
scripts) rather than through the Application
AFSIM is an object-oriented, C++ simulation environment
Programming Interface (API).
that facilitates the prototyping of customized engagement and
x Communications network modeling, including basic
mission level warfare simulations. AFSIM includes a set of
radio transceivers and advanced communications
software libraries, shown as a functional architecture in Figure
algorithms, including addressable nodes, routers,
1, containing routines commonly used to create analytic
multi-access protocols, contention and queuing.
applications. The AFSIM infrastructure includes routines for
the top-level control and management of the simulation; x Electronic warfare modeling, including noise and
management of time and events within the simulation; deceptive jamming techniques, as well as the ability to
management of terrain databases; general purpose math and jam and degrade any type of electro-magnetic
coordinate transformation utilities; and support of standard receiver, including communications systems.
simulation interfaces, such as those supporting the Distributed x Modeling of information flow and tasking between
Interactive Simulation (DIS) protocol. The AFSIM component player and system elements to define candidate
software routines support the definition of entities (platforms) Network Centric Operation (NCO) concepts.
to populate scenarios. These software routines contain models x The ability to run any AFSIM application in both
for a variety of user-defined movers, sensors, weapons, constructive (batch processing) and virtual (real-time)
processors for defining system behavior and information flow, modes.
communications and track management. x User interface elements for integrated scenario
generation and post-processor visualization software.
In addition to the AFSIM core, several capabilities are
available. Additional capabilities include: multitarget tracking
algorithms; Link-16 modeling of both the physical and
message layers; and Reactive Integrated Planning
aRchitecture (RIPR) intelligent agent algorithms for
implementing complex object behaviors. RIPR utilizes a
Boeing-developed Quantum Tasker concept for commander
subordinate interaction and task de-confliction. Section 3
provides additional details of the RIPR model. Restricted
capabilities include missile flyout models.
The baseline AFSIM constructive application is called the
Simulation of Autonomously Generated Entities (SAGE),
which was one of the first constructive applications developed
Fig. 1. The AFSIM functional architecture. using the AFSIM framework. SAGE is a simple application
that reads in a user-defined input file, executes the simulation,
and outputs any user-defined data files. The original purpose

DISTRIBUTION STATEMENT A. Approved for public release; distribution is unlimited.

Int'l Conf. Scientific Computing | CSC'15 | 75

for SAGE was to simulate background air, road or maritime C. Visual Environment for Scenario Preparation and Analysis
traffic. Although SAGE retains the capability to generate (VESPA)
background traffic, the user can exercise all of the resident To support the analyst, Boeing developed tools to facilitate
AFSIM capabilities. scenario generation and post-process data analysis and
B. AFSIM IDE visualization. Specifically, the Visual Environment for
Scenario Preparation and Analysis (VESPA) software
AFSIM permits the user to create subsystem definitions in
application was developed to support the creation of scenario
separate files and to include those definitions in a hierarchal
initial condition files compatible with any AFSIM-based
manner to define representations. This enables subsystem
application. In addition, VESPA can be used to visualize object
configuration control and reuse. This flexibility leads to large
positional time histories and other event information generated
numbers of subsystem definition files when creating scenarios
as output from any AFSIM-based application. This allows the
with a wide variety of different complex systems. The VESPA
analyst to quickly understand and analyze the output from the
application facilitates the creation of the scenario initial
simulation. Since VESPA is a “DIS-listener” visualization
conditions files. It does not, however, address the problems
tool, it may also be used to display real-time entity interactions
associated with defining and integrating system and subsystem
from any real-time simulation that publishes DIS data.
models or defining system-level relationships such as
VESPA includes a graphical user interface (GUI) that
command chains and peers using ASCII data files. Any input
includes a drawing area with a geospatial map and a data input
file errors are not discovered until an AFSIM application is
area, as shown in Figure 2.
executed.
In early 2011, Boeing initiated the development of the
AFSIM Integrated Development Environment (IDE) to support
the analyst in defining and integrating system and subsystem
models. 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 the AFSIM-based application, and visualize the
output results and any error messages. This iterative process
allows the analyst to receive immediate feedback as system and
subsystem models are defined and scenarios are created.
Current capabilities of the IDE support input file creation
including support for syntax highlighting, auto-completion,
context-sensitive command documentation and a variety of
Fig. 2. The VESPA GUI.
scenario browsers. Syntax highlighting makes reading and
understanding the content easier for the analyst. Unknown
keywords or commands are underlined in red for easy Using VESPA, the analyst can place icons representing
discovery. Examples of unknown keywords or commands objects at specific latitude and longitude locations on a
include misspelling of keywords or using keywords out of geospatial map. Initial conditions can then be assigned for each
scope. The auto-completion feature provides a list of selected object. For example, the initial conditions of an
suggestions for the analyst to choose from, based on the aircraft could be its speed, heading and altitude. Visual features
context. The analyst can select one of the suggestions, and the associated with objects, called attachments, can also be created.
command will be completed without having to manually type Examples include routes, range rings and zones.
the command. Context-sensitive command documentation VESPA can be used to display object positional histories
allows the analyst to bring up documentation associated with a and events using an AFSIM replay file generated during an
command to illustrate the scope and use of the command. AFSIM simulation run. The AFSIM replay file is a binary file
Other IDE capabilities are available to assist the analyst in containing the DIS output from the AFSIM simulation. In
defining system and subsystem models and scenarios. addition, plots can be generated for selected events that
The IDE can execute any AFSIM-based application using occurred during the simulation.
the input files defined by the analyst. Any screen output from
the application is displayed in an IDE output window along III. REACTIVE INTEGRATED PLANNING ARCHITECTURE (RIPR)
with any error messages. Current capabilities of the IDE to RIPR is the framework included with AFSIM that enables
view simulation results include the ability to run the VESPA behavior modeling. RIPR is agent based, meaning that each
application from the IDE using the AFSIM replay file created agent acts according to its own knowledge; however, it is
during the simulation run. common for agents to cooperate and communicate with each
other. RIPR is best thought of as a collection of utilities and
algorithms that are used to construct intelligent agents. Most

DISTRIBUTION STATEMENT A. Approved for public release; distribution is unlimited.

76 Int'l Conf. Scientific Computing | CSC'15 |

modern RIPR agents, however, do contain a Perception x Tasks are assigned over comm, handshaking
Processor and a Quantum Tasker Processor. The agent senses performed for acceptance/rejection.
the world by querying the platform and its subsystems, for
information. The agent builds knowledge internally, makes C. Behavior Tree
decisions, and then takes action by controlling its platform RIPR agents typically make use of a RIPR behavior tree to
accordingly. Most platform queries and control actions take define their behavior. A behavior is a compact modular piece
place inside of the AFSIM scripting language. The knowledge- of script that performs some unique action. Behaviors should
building and decision-making actions that RIPR performs are be parameterized and reusable. A behavior tree allows
aided by various artificial intelligence technologies described connection of behaviors in interesting ways so they perform in
in this section. certain orders or subsets. The whole tree aggregates the
behaviors to model an agent’s behavior. Figure 4 provides an
A. Cognitive Model example of a RIPR behavior tree.
A RIPR agent maintains its own perception of threats, RIPR behavior trees provide five different intermediate
assets, and peers. This represents an agent’s limited brain and connector-node types:
the information can be delayed or erroneous. To represent x Selector - chooses and performs first child behavior to
players of varying skill, each agent has its own tunable pass its precondition check.
cognitive model. For example, an “expert” pilot agent can x Sequence - performs all child behaviors in sequence
maintain knowledge of 16 threats that he updates (looks at until one fails its precondition check.
radar) every 5 seconds. Much of the cognitive model’s ability x Parallel - performs all child behaviors whose
is contained within the Perception Processor. precondition check passes.
B. Quantum Tasker x Weight Random - makes a weighted random selection
The RIPR Quantum from its child behaviors.
Tasker is used for x Priority Selector - selects the child behavior who
commander subordinate returns the largest precondition value.
interaction and task de- Behavior trees provide for maximum utility for developing
confliction. The Quantum and editing agents. A properly constructed behavior tree allows
Tasker comprises task a user to find relevant script fast, and swap in other behaviors
generator(s), task-asset at appropriate places. For example: try separating out behaviors
pair evaluator(s), an for choosing desired heading, altitude, and speed from the
allocation algorithm, and behavior that actually performs the flight task. When you
various strategy settings develop a new flying behavior, e.g. one that used a new route
(such as how to handle finder, you can swap that for the old one while keeping the
rejected task assignments). logic in place for calculating desired direction.
Each component
(generator, evaluator,
allocator) can be selected
Fig. 3. Quantum tasker mode of
from pre-defined options, operation.
or custom created in
script. The RIPR Quantum Tasker tasking system is also
compatible with platforms using the older task manager
(WSF_TASK_MANAGER and WSF_TASK_PROCESSOR).
It can send and/or receive tasks to/from other RIPR agents and
other task manager platforms. Figure 3 illustrates the various
pieces of the Quantum Tasker and their connections.
The Quantum Tasker’s method of operation:
x Acquire perception of assets from cognitive model for
matrix columns.
x Acquire perception of threats from cognitive model
x Generator generates tasks for matrix rows. Fig. 4. Example RIPR behavior tree.
x Strategy dictates how previously assigned tasks,
rejected tasks, or new tasks are handled. D. Cluster Manager
x Evaluator calculates values for possible asset-task
pairs for matrix body. Some RIPR agents take advantage of the Cluster Manager
to perform clustering on threat or asset perception in order to
x The allocator runs on the task-asset matrix to find
think of these larger sets as smaller groups. For example, it is
appropriate task allocation, e.g. greedy, optimal, etc.
common for a commander to group incoming threats into two
clusters so it can send each of its two squadrons after separate

DISTRIBUTION STATEMENT A. Approved for public release; distribution is unlimited.

Int'l Conf. Scientific Computing | CSC'15 | 77

groups. The Cluster Manager can cluster based on desired A. Component Based Architecture
similarity thresholds or based on the desired number of Figure 5 details the current base level architecture of
clusters. Similarity measurements can be based on ground AFSIM. Since the base components of AFSIM are directly
distance, 3D distance, or 3D distance and speed. The Cluster named in code this makes it difficult to add or remove base
Manager can use one of three clustering algorithms: component types. Also it is currently difficult to extend other
x Hierarchical Tree Max - default, guaranteed to be non-platform components.
optimal, no cluster member dissimilar to any other
member past the threshold (this method provides for
tighter “classic” groups of members)
x Hierarchical Tree Min - guaranteed to be optimal, no
cluster member dissimilar to at least one other
member past the threshold (this method allows for
Fig. 5. Existing AFSIM base level architecture.
long “stringy” chains of members)
x K-Means - not guaranteed to be optimal, fastest, In order to better facilitate the ability to add and remove
clusters are centered on K different mean points. base components work is underway to create a Component
Based Architecture, which relies on an underlying generic
E. Example Agent Interaction component class where all components can be derived from.
Below is an example sequence of interactions within the This architecture allows access via naming for components that
RIPR architecture for a group of agents: already exist and will ease the addition and removal of certain
1. A commander agent obtains threats from his cognitive component types. This solution maximizes commonality with
model (Perception Processor). the original architecture while at the same time providing a
2. Commander’s Quantum Tasker generator clusters means to maintain a release version with no weapons or
threats into groups and creates a task for each group. electronic warfare capabilities included as well as an ITAR
3. Commander’s Quantum Tasker evaluator scores his release, which would include those components. The new
squadrons (assets) against each group. architecture is shown in Figure 6.
4. Commander’s Quantum Tasker allocator finds
optimal task assignment.
5. Commander assigns task(s) to subordinate flight leads
over comm.
6. Flight lead uses asset and threat perception from
cognitive model while interpreting task.
7. Flight lead agent’s Quantum Tasker generates,
evaluates, allocates, and assigns tasks to pilot agents.
8. Pilot agent uses peer and threat perception from
cognitive model. Fig. 6. New AFSIM Component Based Architecture.
9. Pilot agent’s behavior tree checks for evade,
disengage, bingo conditions.
V. CONCLUSION
10. Pilot agent’s behavior tree flies to intercept and
eventually engages threat from task. In this paper we have provided a high level overview of the
11. Pilot agent uses route finder to fly around SAM zones AFSIM simulation environment. AFSIM has been under
during ingress towards target. development by Boeing under IR&D funds for more than 10
years. Under contract, Boeing delivered AFSIM to the Air
IV. FUTURE WORK Force (specifically AFRL/RQQD) with unlimited government
The current state of the AFSIM framework only allows rights (including source code) in February 2013. AFRL has
distribution to DoD agencies and DoD contractor’s due to now begun to distribute AFSIM within the DoD community.
International Traffic in Arms Regulations (ITAR) restrictions. The AFSIM distribution comes with three pieces of software:
It is the desire of the AFRL to allow wider dissemination of the the framework itself, an IDE and the visualization tool VESPA.
framework in order to provide more modeling and simulation Although AFSIM is currently ITAR restricted future work is
collaboration opportunities. However, the current architecture planned to modify the underlying architecture to facilitate
of AFSIM does not easily lend itself to maintaining multiple maintaining multiple versions with varying releasability. Under
versions across multiple release restrictions, which is why an AFRL management AFSIM will continue to grow as a valuable
architecture rework is underway to create a Component Based modeling and simulation tool.
Architecture.

DISTRIBUTION STATEMENT A. Approved for public release; distribution is unlimited.