Spectral Autonomy

AMS-GRA: The Air Force's Modular Mission-Systems Reference Architecture

Part of the Open Architecture Field Guide. All information is derived from unclassified, publicly releasable (Distribution A) sources.

AMS-GRA, the Agile Mission Suite Government Reference Architecture, is the Air Force standard for building a modular mission system from competitively sourced, interchangeable units instead of a single-vendor box. It defines the sensing, processing, and mission-software parts and the interfaces between them, and it is owned by AFLCMC/WA.

What it does

A mission system, the sensing and processing payload a platform carries, has usually been delivered as a vendor-specific unit. Upgrading a sensor or adding a capability means going back to the original vendor, because the internal interfaces are proprietary. That locks the government into one supplier for the life of the system.

AMS-GRA breaks the mission system into parts with defined boundaries between them. Each part is a Minimum Procurable Unit (MPU): the aperture, the digital processors, storage, switches, the cryptographic unit, and others. Because the interfaces between MPUs are specified, each MPU can be bought, replaced, or upgraded on its own, from whichever vendor offers the best one.

How it is built

Data moves through an AMS-GRA mission system along a consistent path. A Multi-Function Aperture (MFA) collects raw radio-frequency and infrared signals. Those raw signals cross the MFA Encapsulation Layer (MEL) to Skills, the software services that process them. Skills publish their results as UCI messages over the Open Mission Systems (OMS) bus. The Mission Agnostic Service Infrastructure (MASI) deploys those services and monitors their health and status.

Two features are worth calling out. The MFA supports aperture virtualization, which lets one physical aperture be shared across several functions rather than dedicating hardware to each. And Skills are portable software: because they consume raw data through the standard MEL interface and report through OMS and UCI, the same processing software can move between platforms.

AMS-GRA mission system: apertures, processing, and mission softwareAMS-GRA partitions a sensor subsystem into three layers. Software-defined Multi-Function Apertures (RF and IR) connect over the Avionics Backplane Bus to the Multi-Function Processing layer, a compute cluster farm that runs portable software Skills and the Countermeasures Manager. The Mission Processing subsystem holds mission-agnostic and mission-specific skills. The Abstract Service Bus carries OMS and UCI data exchanges out to the platform and to legacy subsystems.MULTI-FUNCTION APERTURESsoftware-defined RF & IRRF MFAIR MFAhosts optional Local Functions;shared as Virtual AperturesABBMULTI-FUNCTION PROCESSINGcompute cluster farmSkills (software)DPP: GPP · FPGA · GPUCountermeasures MgrMISSION PROCESSINGmission subsystem (MPS)Mission-agnostic skillsMission-specific skillsTrack · resource · healthAbstract Service Bus (ASB): OMS / UCI data exchangesPlatform (PVI, stores)Legacy subsystems
Spectral Autonomy
AMS-GRA decomposes a sensor subsystem into software-defined apertures, processing, and mission software, tied together by the Avionics Backplane Bus and exposed to the platform over OMS and UCI.

Where it sits

AMS-GRA is one of the Air Force's Government Reference Architectures. It is a sibling of A-GRA, GARA, and W-GRA, separate architectures owned by different offices, not a nested set.

The Air Force Government Reference Architecture familyFour separate Government Reference Architectures, each owned by a different Air Force office: A-GRA for autonomy, AMS-GRA for mission systems, GARA for avionics integration, and W-GRA for weapons. They are siblings, not a nested set.GOVERNMENT REFERENCE ARCHITECTURES · U.S. AIR FORCEA-GRAAutonomyAir Force (CCA)AMS-GRAMission systemsAFLCMC/WAGARAAvionics integrationAFLCMC OAMOW-GRAWeaponsAFLCMC ArmamentSiblings owned by different offices, not a nested set.
Spectral Autonomy
AMS-GRA is one of four Air Force Government Reference Architectures. They are owned by different offices and are siblings, not a nested hierarchy.

As of AMS-GRA version 14.0 (April 2026), the Big Iron electronic-warfare architecture was absorbed into AMS-GRA. Both come from the same directorate, AFLCMC/WA, which is why they converged. Big Iron still describes fielded electronic-warfare programs, but it is no longer developed as a separate architecture.

Big Iron before and after its integration into AMS-GRABefore AMS-GRA version 14.0, Big Iron was a standalone Air Force electronic-warfare architecture owned by AFLCMC/WA. As of version 14.0 in April 2026, Big Iron is integrated into AMS-GRA, owned by the same office, and a new Assembly entry point was added. Big Iron remains valid for fielded programs but is no longer developed as a separate architecture.BEFORE v14.0AMS-GRAAFLCMC/WABig Iron (EW)AFLCMC/WA, standaloneSame owner, separate documentsAS OF v14.0 (APR 2026)AMS-GRA v14.0AFLCMC/WABig Iron, integratedAssembly (new entry point)No longer a separate architecture,still valid for fielded programs
Spectral Autonomy
Big Iron was folded into AMS-GRA at version 14.0. It still describes fielded EW programs but is no longer developed on its own.

Two ways to adopt it

A full Mission System implements the complete set of MPUs. An Assembly is a lighter entry point, introduced with the Big Iron integration. It lets a program bring a legacy system, a low size-weight-and-power payload, or hardware that does not fit cleanly into MPU boundaries into partial compliance, then grow toward a full mission system over time. Compliance is scored in tiers rather than as a single pass or fail.

Where this fits

FAQ

Does AMS-GRA replace an earlier standard?
Yes. AMS-GRA fully incorporates and supersedes the Open Communications Subsystem (OCS) 2.0 standard, and it added electronic warfare at version 14.0 when Big Iron was absorbed into it.
Who owns it?
The Air Force Life Cycle Management Center's Warfare Directorate, AFLCMC/WA.
What is a Minimum Procurable Unit?
A defined part of a mission system, such as an aperture, a processor, or storage, that can be sourced and replaced on its own because its interfaces are standardized.
What is the difference between a Mission System and an Assembly?
A Mission System implements the full architecture. An Assembly is a lighter, partial-compliance entry point for legacy or constrained systems.

Sources