AFSIM: The Air Force Research Laboratory’s Approach to Making M&S Ubiquitous in the Weapon System Concept Development Process


Posted: January 9, 2020 | By: Colonel Timothy D. West, Mr. Brian Birkmire

The idea behind AFSIM is a common modeling framework, using common models in a common environment with a common threat laydown. To encourage buy-in across government and industry, AFRL not only built a robust product but also made the software, source code, and training available to approved users free of charge.  To date, AFRL has licensed AFSIM to over 275 government, industry, and academic organizations, and provided training to over 1200 users. AFRL’s overall approach to software development, distribution, support, and governance could serve as a model for encouraging widespread adoption of future freeware software products.


Arguably, one indication that a bourgeoning technical concept or capability is on the precipice of widespread usage and acceptance is when it enters the United States (US) Congressional record. For Digital Twin, the notion of building realistic digital models of real-world systems, that moment has arrived. The House Armed Services Committee’s Subcommittee on Tactical Air and Land Forces recently drafted language for the Fiscal Year 2020 National Defense Authorization Bill directing the US Secretary of Defense to provide a briefing to the Committee explaining “how the F-35 program is implementing the use of digital twinning technology across the F-35 system enterprise” [1].

In order to mainstream the effective “digital twinning” of F-35 and other weapon systems, the US Department of Defense (DoD) must have a modeling framework that is effective, available, affordable, and relatively easy to use. DoD must also have a culture that is accepting of the results produced by these digital models. The Air Force Research Laboratory (AFRL) is making clear headway on both fronts with its Advanced Framework for Simulation, Integration and Modeling (AFSIM), a C++ based modular object-oriented, multi-domain, multi-resolution modeling and simulation (M&S) framework for military simulations focused on analysis, experimentation and wargaming. The AFSIM community already encompasses over 1200 trained users across 275 organizations, including all branches of the US military; other US Government agencies; industry; academia; and our five closest allies.  This broad-based community is already widely using AFSIM to assess and compare various weapon system concepts, refine operational employment tactics for the most promising concepts, and ultimately to inform the weapon system investment decisions within AFRL and across the DoD. This paper describes the steps AFRL is taking and the progress achieved in making AFSIM as ubiquitous in the defense M&S community as MATLAB is in the academic community.


In its present form, AFSIM represents a government/industry investment in excess of $50M. Between 2003 and 2013, Boeing invested approximately $35M of Independent Research & Development (IR&D) funding into what it called the Analytic Framework for Network-Enabled Systems (AFNES) that Boeing designed to simulate threat integrated air defense systems (IADS). Frustrated with the proprietary, inflexible M&S tools available to the Government at the time, AFRL conducted a head-to-head showdown of available tools in 2011, selecting AFNES as the framework of choice for its trade-space analysis and technology maturation M&S work. In 2013, Boeing transferred AFNES to AFRL with unlimited rights, which AFRL subsequently rebranded as AFSIM. [2]

Note that the “AF” in the AFSIM name does not stand for Air Force. This reflects AFRL’s belief that AFSIM should not be just an internal Air Force tool, but rather a common framework used broadly across the entire defense M&S community. This naming choice also signifies that AFSIM is more than just a framework for simulating aircraft. It was designed to be a multi-domain platform, meaning it can model land-, sea-, air-, and space-based platforms, enabling modelers to include submarines, naval vessels, tanks, airplanes, helicopters, satellites, and even cyber agents in the same simulation, if needed.

From its earliest conception, AFSIM was also envisioned to be an open system, utilizing “plug and play” modules to overcome expansion and compatibility constraints of earlier frameworks. This modular approach allows the modeler, rather than the AFSIM programmer, to determine the appropriate level of fidelity (i.e., the degree to which the underlying physics are simulated) for the models used in the simulation. Likewise, users can adjust the fidelity of each platform to meet their specific simulation needs. The fidelity of an airplane model, for instance, could vary between a point in space moving along a predefined vector to a full six degree of freedom model that changes speed, direction, altitude, etc. based on the displacement of the virtual cockpit controls. The modular approach also enables the reuse and/or modification of existing models of various platforms without changing the core AFSIM code.

AFSIM’s modular structure enables AFRL to distribute the code at two security classification levels, which users can adapt to meet their specific security requirements by adding additional software modules. AFRL offers both an unclassified and classified (US Secret) variant of the code. The primary difference between the two available variants is simply the number, type, and fidelity of included models. To receive the classified variant of the software, contractors must also provide a current, certified DD Form 254 Contract Security Classification Specification. The classified version also comes standard with National Air and Space Intelligence Center (NASIC) approved models of many threat systems, and a National Geospatial-Intelligence Agency (NGA) Digital Terrain Elevation Data (DTED) model. End users may then add their own modules to incorporate models of other platforms of interest for their specialized use. The overall classification of a given instantiation of AFSIM is then driven not only by the initial variant of the software, but also by the classification of modules added to that instantiation. Because of their inherent military utility, both variants are subject to International Traffic in Arms Regulations (ITAR) restrictions, meaning individuals and organizations can be fined or prosecuted for unauthorized release or export of the software. Because of these restrictions, academic institutions must have an approved ITAR-compliant environment before AFRL can release AFSIM to them. Despite this restriction, the pool of academic users is growing. Georgia Tech, Purdue, Ohio State, University of Central Florida, University of Alabama in Huntsville, and the University of Illinois – Champaign Urbana are already part of the AFSIM family.

AFSIM spans a broad spectrum of military simulations, to include the engineering, engagement, mission, and ‘campaign-lite’ level via analytic wargaming and experimentation. As Table 1 depicts, the Engineering level consists of short-duration subsystem interaction with other subsystems. One example of this could be a radio frequency (RF) transmitter interacting with a receiver to identify subsystem level capabilities and limitations. The Engagement level consists of “mano a mano” combat, that is, a brief exchange between two entities, or platforms, in the AFSIM vernacular. For instance, a missile exchange between a Blue (Friend) and Red (Foe) aircraft would constitute an engagement level simulation. The next level of complexity would be the Mission level, simulating, for example, a series of combat exchanges between multiple Red and Blue aircraft over the duration of a single sortie or mission, nominally a few hours. These simulations can contain up to thousands of entities. Campaign level engagements extend this even further, potentially including all the Red and Blue platforms in a given area over an extended period, i.e., days or even months. The focus for AFSIM development has been primarily at the engagement and mission level, with recent development expanding AFSIM’s to include “campaign-lite” capabilities via analytic wargaming. Other M&S tools are leveraged when needing to more fully explore engineering or full campaign modeling, such as the Synthetic Theater Operations Research Model (STORM) used by the Air Force Studies, Analyses and Assessments Office (AF/A9).

Table 1: Levels of Wargaming Simulations

AFSIM enables its user to scale the scenario to the appropriate simulation level to best study the item(s) of interest. Each subsequent level logically builds on the lower levels to create a more intricate simulation in order to identify system-of-systems emergent properties that may not be apparent in simpler simulations. For instance, the combat effects of depleting munitions and fuel reserves may be unnoticeable at the Engagement or Mission level, but a total game-changer in the Campaign level simulation. The limiting factor in the size and complexity of an AFSIM simulation is the storage, memory, and computing power of the host platform – and the associated wall clock time required to run the simulation. AFSIM allows users to set the desired balance between processing time and output fidelity by adjusting the various parameters and behaviors associated with platform.

To achieve the degree of flexibility in platform type, fidelity, simulation type described above, AFSIM uses four architectural elements (Attributes, Elements, Components, and Links) to describe each platform in the simulation, as Figure 1 depicts. Attributes include standard data as platform name, type, and affiliation. This sub-element can be expanded to include mission-unique information such as radar, optical, and infrared signature data to determine an aircraft’s vulnerability to detection by enemy sensors. The Information element encompasses data resident on the platform, along with details on how these data are perceived by the humans that receive them. For an aircraft, this would include the sort of data that would be displayed to the pilot (i.e., altitude, speed, heading, radar indications, etc.), along with the myriad raw data driving these displays. The Components element consists of various models that directly control how the platform behaves. These models describe how the platform moves through space-time, senses the surrounding environment, processes the information it collects, communicates with other platforms, and employs its arsenal of kinetic and non-kinetic weapons against adversary platforms, and conducts various other tasks. Finally, the Links element coordinates the data exchanges between various subsystems on the platform, as well as communications with other platforms.

Figure 1: AFSIM Architectural Elements

Another notable AFSIM is its support of both virtual and constructive simulations. In a constructive simulation, simulated operators control simulated systems – such as a military battle where the red and blue players are all computer controlled. In a virtual simulation, you have real operators controlling simulated systems – such as a pilot flying a flight simulator. AFSIM can be used constructively to conduct large trade space exploration of military capabilities, potentially involving tens of thousands of unique test points executing in a non-real-time manner. The results of such constructive sim activities can then be utilized to define and conduct a virtual simulation that runs in real-time to investigate a narrower trade space (informed by the constructive simulation) for a more focused assessment with operational pilot participation. This allows the same underlying simulation models to be utilized in both the constructive simulation and the virtual simulation, providing more consistent modeling and analysis across both environments. In addition, AFSIM can also be linked into other simulations or other simulators/emulators to provide a true Live-Virtual-Constructive (LVC) simulation capability. Using Distributed Interactive Simulation (DIS) or other supported communication protocols, AFSIM can interact with other simulations or live experiments in order to provide additional entities (both virtual and constructive), system and sub-system models, threat systems or potentially other simulated capabilities. This allows AFSIM to augment and/or complement a larger simulation or experimentation environment with additional capabilities, as needed to best achieve any given test and analysis objectives.

Leveraging its Warlock graphical user interface (GUI), AFSIM likewise allows “operator in the loop” execution to facilitate analytic wargaming. Specifically, Warlock> enables operators to trigger various scenario events, control individual platforms, and even experience the mission from inside the platform – much like Flight Simulator. Warlock also facilitates the creation of “cells” of operators, e.g., a Blue Cell of friendly platform operators and a Red Cell of adversary platform operators, each of which only have access to virtual information collected by that cell’s platform. In other words, the Red Cell and the Blue Cell each have imperfect information about the other. AFSIM can add further realism to the wargame by degrading the flow of information between members of the same cell. Warlock also supports the creation of a White Cell – the referees – that have perfect information about all platforms, which they leverage to control the flow of the overall wargame.

Before any type of AFSIM simulation can be executed, however, the user must define the various platform and component models and then craft the wargame scenario. To facilitate this process, AFRL distributes Wizard, AFSIM’s Integrated Development Environment (IDE), as a supporting tool (like Warlock). Much like a modern software development IDE, Wizard serves as a single application to edit scenario files; write AFSIM script; graphically manipulate scenario laydowns; run software executable (i.e. run the scenario in AFSIM); and view the resulting output or error messages. It also highlights file syntax, flags unknown commands, and provides context-sensitive documentation. Wizard even comes with an auto-completion feature and a script debugger to minimize the time required to develop and debug models and scenarios.


Recognizing that widespread adoption is more probable leveraging incentives rather than mandates, AFRL has taken several steps to grow the AFSIM following. First, AFRL decided it would give away the product to both Government and industry partners. Intra-government sharing could easily be accomplished under Memoranda of Understanding (MoU). However, sharing software with industry partners initially proved tricky, as existing contract mechanisms only allowed the sharing of government property and information with industry partners as part of a larger contract. The F-22 aircraft program could loan Lockheed-Martin the software as part of the larger F-22 contract, but the ruleset associated with government furnished property meant the software could only be used for M&S work within the scope of the F-22 contract, and the software must be returned to the government at the conclusion of that contract. To overcome this obstacle, AFRL created a new type of contractual agreement, an Information Transfer Agreement (ITA), that gives industry partners full access to the software, without constraining its use to a single program [3], [4].

AFRL also chose to provide free training at its Dayton, Ohio, headquarters. AFRL currently offers two courses: one for general users and one for code developers. The user course is offered monthly while the developer course is offered every other month. The only costs to attendees are travel-related expenses. This combination of free software and free training makes AFSIM very attractive to organizations who might otherwise be forced to use costly commercial off the shelf (COTS) products, along with the recurring expenses associated with license renewals, specialized training, and product support.

To further sweeten the deal, AFRL also opted to provide users and developers with the source code for both the framework and all supporting tools. This decision was borne from the Lab’s own frustration with other “black box” software tools that provided limited insight into how the tool transformed inputs into outputs. AFRL recognized that providing source code would enable savvy users to see for themselves the logic, algorithms, equations, and associated assumptions behind every AFSIM result. AFRL also realized that source code access could leverage the user community as code debuggers, knowing that inquisitive users would likely dig into the source code to understand anomalous results, unearthing logic errors and faulty assumptions that could be corrected in future software updates.

Deliberate community engagement has also been a core element of AFRL’s strategy for AFSIM. In addition to actively soliciting feedback on the user experience and leveraging them to find and repair minor coding issues, AFRL has incorporated the user community into its governance model, establishing eight domain-centric working groups (Sensors, Space, Threats & Scenarios, Kinetic Weapons, Directed Energy, Standardization, Virtual Simulation and Wargaming, Cyber/C3) to help establish the vision for capability development within each group’s respective domain. Each working group is a self-organized entity whose leadership structure is driven more by consensus of the subject matter experts in that group rather than AFRL dictate. Nearly half the groups are led by non-AFRL personnel, some by other military services. A central program management team integrates and prioritizes the inputs from each group in order to develop an annual execution plan within the available funding limits.

As the AFSIM community has grown, so, too, has the need to scale the AFSIM software development and maintenance effort. The AFSIM software team now consists of over 40 full-time developers and analysts to maintain both the Windows and Linux variants. Software increments for both variants are released on a six-month cycle, with user support and bug fixes provided for both the latest version and one prior version. This approach enables a steady flow of cutting-edge capabilities, while providing longer-term stability for users who do not require the latest release. Each release of AFSIM has a one year support window. As of this writing, AFSIM 2.3 is the “stable” version, AFSIM 2.4 is the latest version, and 2.5 is in development.  The AFSIM development team works closely with network approval authorities to ensure authority to operate on multiple government systems across a range of security classifications. To facilitate these network approvals, the development team utilizes a continuous integration and build process which incorporates automatic builds, static code analysis, regression testing, and rigorous vulnerability scanning.

One of AFSIM’s primary use cases is as a simulation platform for technology maturation. Over the past few years AFRL has made a significant investment in using AFSIM as a testbed for maturing air vehicle autonomy. Utilizing AFSIM as a simulation testbed for autonomy has created a single, unified environment for developing, maturing, and testing autonomy algorithms for basic and applied research, as well as advanced applications. Using AFSIM as a virtual testbed for accelerating air vehicle autonomy development has proven so effective that several government agencies and industry partners have also adopted it for similar efforts, to include the Defense Advanced Research Projects Agency (DARPA), Johns Hopkins University Applied Physics Laboratory (JHU APL), Georgia Tech Research Institute (GTRI), and Leidos.  AFRL is also teaming with the Air Force Lifecycle Management Center (AFLCMC) and the Air Force Warfighting Integration Center (AFWIC) to make AFSIM the tool of choice for analyses of alternatives (AoAs) for future weapon system concepts.  Additionally, AFWIC has incorporated AFSIM into its capability development guide. AFRL has also communicated to its industry partners that AFSIM will be a key tool it uses to evaluate their proposals.  Lockheed-Martin’s recent announcement that it is investing $5M into their AFSIM infrastructure is a clear indicator that industry is listening.  Boeing, who developed the predecessor to AFSIM, has been a committed user for over a decade.


Representing a $50M investment to date and another $6M per year for the foreseeable future, AFSIM is not an inexpensive framework. However, AFRL believes the DoD will ultimately recoup this investment by reducing schedule delays and the associated cost overruns through earlier identification and correction of murky requirements, invalid assumptions, and flawed design decisions. Despite its shortcomings, AFSIM is already enhancing the DoD’s “model centric” approach to acquisition. AFRL’s conscientious efforts to make AFSIM useful, available, affordable, and user friendly have undoubtedly helped in this regard. AFRL believes that AFSIM will be key to helping the Secretary of the Air Force attain her vision of building an innovative Air Force that “dominates time, space, and complexity in future conflict across all operating domains to project power and defend the homeland” [5]. Will AFSIM ultimately help the Air Force achieve this lofty goal? Only time will tell.


  • AF/A9 Air Force Studies, Analyses and Assessments Office
  • AFLCMC Air Force Lifecycle Management Center
  • AFNES Analytic Framework for Network-Enabled Systems
  • AFRL Air Force Research Laboratory
  • AFSIM Advanced Framework for Simulation, Integration and Modeling
  • AFWIC Air Force Warfighting Integration Center
  • AoA Analysis of Alternative
  • COTS Commercial Off The Shelf
  • DARPA Defense Advanced Research Projects Agency
  • DoD Department of Defense
  • DIS Distributed Interactive Simulation
  • DTED Digital Terrain Elevation Data
  • GTRI Georgia Tech Research Institute
  • GUI Graphical User Interface
  • IADS Integrated Air Defense Systems
  • IDE Integrated Development Environment
  • IR&D Independent Research & Development
  • ITA Information Transfer Agreement
  • ITAR International Traffic in Arms Regulations
  • JHU APL Johns Hopkins University Applied Physics Laboratory
  • LVC Live-Virtual-Constructive
  • M&S Modeling and Simulation
  • MoU Memoranda of Understanding
  • NASIC National Air and Space Intelligence Center
  • NGA National Geospatial-Intelligence Agency
  • RF Radio Frequency
  • STORM Synthetic Theater Operations Research Model
  • US United States


  1. U.S. House of Representatives, “H.R. 2500 – FY20 National Devense Authorization Bill – Subcomittee on Tactical Air and Land Forces,” Washington DC, Jun. 2019.
  2. P. D. Clive et al., “Advanced Framework for Simulation, Integration and Modeling (AFSIM),” p. 5, 2015.
  3. L. Daigle, “AFRL uses new Information Transfer Agreement to share software with industry,” Military Embedded Systems, 2017. [Online]. Available: [Accessed: 07-Jul-2019].
  4. J. Knapp, “Information Transfer Agreement enables AFRL software sharing with industry,” Wright-Patterson AFB, 10-Mar-2017. [Online]. Available: [Accessed: 07-Jul-2019].
  5. US Air Force, “U.S. Air Force Science and Technology Strategy.” 17-Apr-2019.

Focus Areas

Want to find out more about this topic?

Request a FREE Technical Inquiry!