How the Army’s FUTURA Program Is Reshaping Ground Vehicle Systems Engineering
The Requirements Problem Is Bigger Than the Vehicle
The U.S. Army’s Future Unmanned and Teamed Robotics Architecture — FUTURA — is not, at its core, a vehicle program. It is a requirements problem disguised as one.
The Army needs a family of ground platforms that can operate in GPS-denied terrain, under active jamming, in temperature extremes from the Artic to the Kuwaiti desert, survive direct fire threats that are evolving faster than any acquisition program can formally track, and accept software and hardware modifications at the unit level within weeks of an operational need emerging. Each of those demands, taken alone, is a difficult engineering constraint. Taken together, they describe a system that has to be simultaneously hardened and soft, locked down and modifiable, autonomous and human-controlled.
The contractors and integrators building these systems — among them General Dynamics Land Systems, Oshkosh Defense, L3Harris, Textron Systems, and a growing layer of defense tech firms working the autonomy and electronics stacks — are confronting systems engineering processes that were designed for a different era. Understanding what is actually hard about FUTURA’s systems engineering, and what the industry is doing about it, requires looking past the platform renders and understanding the requirements architecture underneath.
What FUTURA Actually Demands From Systems Engineering Teams
FUTURA encompasses multiple overlapping vehicle families: optionally manned fighting vehicles derived from the Robotic Combat Vehicle program lineage, unmanned logistics and resupply platforms, and manned-unmanned teaming (MUM-T) systems that extend the operational reach of crewed platforms through tightly coordinated unmanned surrogates. The Army has been explicit that all of these must comply with Modular Open Systems Architecture (MOSA) principles — which sounds straightforward until you realize that MOSA is not a technical standard. It is a design philosophy that demands your requirements process can accommodate vendors you haven’t contracted yet, interfaces you haven’t defined yet, and capability upgrades that don’t exist yet.
That is a fundamentally different requirements posture than what built the Bradley or the Abrams. Those programs had stable threat assumptions, stable technology assumptions, and acquisition timelines long enough to converge on mature designs before production. FUTURA has none of those luxuries.
The Interface Problem Is the Real Problem
Every FUTURA-class vehicle must integrate, at minimum: a propulsion and mobility system, an active protection system, a remote weapon station or lethality package, a suite of optronics and sensor fusion hardware, a vehicle management computer running real-time OS software, a communications and networking stack capable of operating degraded in a jammed environment, a crew interface system, and — for unmanned variants — an autonomy compute stack with its own sensor suite.
These subsystems are being developed by different contractors on different schedules. Some are government-furnished equipment. Some are vendor-selected. Some are still in competitive source selection. What this means operationally for a systems engineer is that Interface Control Documents (ICDs) are being written before the systems on either side of the interface are finalized. This is not unusual in defense programs, but the pace at which FUTURA requires these interfaces to evolve is.
A legacy ICD revision cycle runs through formal engineering change proposals (ECPs), configuration control boards, and often contract modifications. That cycle is measured in months. When a new electronic warfare threat emerges from theater and changes the requirements on the communications stack, the ripple through an ICD-centric requirements architecture can take 18 months to formally propagate. FUTURA’s operational concept doesn’t accommodate 18 months.
The Four Hardest Requirements Domains in Ground Combat Systems
1. Environmental Envelopes
Ground combat vehicles operate in environmental conditions that would destroy most commercial electronics within hours. The MIL-STD-810 test regimes — thermal shock, vibration, humidity, sand and dust, immersion — define the floor, not the ceiling, of what FUTURA platforms must survive. Active combat adds blast overpressure, electromagnetic pulse from nearby detonations, and the specific vibration signature of continuous high-speed cross-country movement.
The systems engineering challenge is that these environmental constraints interact. A thermal management solution that works in Arctic conditions — insulating electronics to prevent cold soak — actively degrades performance in desert operations where you need maximum heat dissipation. Requirements teams that model these environments in isolation write requirements that cannot coexist in a single hardware configuration. The only workable approach is to model the environmental envelope as a unified multi-variable constraint space and propagate it through every subsystem requirement simultaneously.
This is exactly the kind of analysis that exposes the limitations of document-based requirements management. When your thermal requirement lives in one Word document, your electronics density requirement in another, and your weight budget in a spreadsheet, tracing the interaction between them during a design review is a manual, error-prone process. By the time the conflict surfaces, hardware has often already been ordered.
2. Contested Electromagnetic Environment
Every FUTURA platform operates under the assumption that adversaries will actively jam GPS, tactical datalinks, and radio communications. This means requirements must account for degraded-mode operation across every capability that touches the RF spectrum — which is nearly every capability on a modern combat vehicle.
The systems engineering implication is that “operates in a jammed environment” cannot be a single system-level requirement. It must decompose into specific degraded-mode behaviors for every subsystem: How does the autonomy stack navigate without GPS? How does the crew interface present situational awareness when the data network drops? How does the remote weapon station acquire targets when the sensor fusion pipeline loses its network feed? Each of these is a distinct requirement with its own verification approach.
The failure mode in many current programs is treating EW survivability as an add-on — a set of requirements layered on top of a baseline architecture after the fact. This produces systems that technically satisfy individual requirements but degrade catastrophically when multiple subsystems lose connectivity simultaneously, which is exactly what a sophisticated jammer is designed to cause.
3. Crew Survivability and Human Factors
Crew survivability requirements in ground combat systems span ballistic protection, blast mitigation, toxic fume suppression, emergency egress, and — increasingly — cognitive load management. The last category is where modern vehicle programs consistently underinvest at the requirements level.
A FUTURA crew compartment may present the operator with simultaneous feeds from autonomous wingman vehicles, active protection system status, weapon station optics, Blue Force Tracking, and vehicle health monitoring — all while the vehicle is moving at speed across complex terrain. The requirement to “not overload the crew” is real, but it is rarely operationalized into measurable, verifiable human factors requirements early enough to constrain the interface designs of the systems being integrated.
What tends to happen instead is that human factors analysis occurs late in the program, discovers that the integrated crew interface violates cognitive load limits, and triggers redesign of interface elements that were already contracted and partially built. This is a requirements sequencing failure, not a design failure.
4. Rapid Field Modification
The Army’s experience in Ukraine-conflict observation and Red Sea operations has made explicit something operators have always known: the threat environment changes faster than defense acquisition programs. FUTURA’s operational requirements include the expectation that units in the field must be able to integrate new countermeasures, updated software loads, and modified mission configurations within weeks of an operational need emerging — without depot-level maintenance.
This is a profound systems engineering constraint. It means the requirements architecture must define not just what the system does, but how modifiable it is. Interfaces must be designed with modification in mind. Software must be architected to accept updates without requiring hardware changes. Hardware must be physically accessible in a field environment. And configuration management must track what variant of the system is deployed at unit level, not just what variant shipped from the factory.
Current ECP processes are not adequate for this. Some FUTURA contractors are experimenting with continuous integration pipelines borrowed from software-intensive commercial programs, adapted for the hardware verification requirements of a defense platform. Others are working with the Army to define tiered modification categories — Tier 1 modifications executable at unit level, Tier 2 at brigade support, Tier 3 at depot — with distinct requirements governing each tier.
What Prime Contractors Are Actually Doing Differently
The contractors navigating FUTURA most effectively share a recognizable pattern in their systems engineering approach: they are treating requirements as a connected, living model rather than a document set.
This means moving away from requirements managed in DOORS or DOORS Next as standalone text databases toward architectures where requirements are nodes in a graph — connected to the design elements they constrain, the verification activities that will close them, the interface definitions they depend on, and the test data that demonstrates compliance. When a requirement changes — because a threat estimate changes, because a government-furnished component is substituted, because an ICD is revised — the impact propagates automatically to the teams and artifacts downstream.
This is not a new idea. Model-Based Systems Engineering (MBSE) practitioners have been advocating connected requirements models for over a decade. What is changing is the tooling maturity and, critically, the AI-assisted analysis capability. Requirements sets for a FUTURA-class vehicle run into the tens of thousands of lines. Manually tracing the impact of a single interface change through a requirements set of that scale takes weeks. AI-assisted impact analysis — where the tooling can surface candidate affected requirements and flag likely conflicts — compresses that to hours.
Tools like Flow Engineering are representative of this shift: purpose-built for hardware and systems engineering teams, with graph-based traceability as the native data model rather than a reporting feature bolted onto a document system. On programs where requirement changes are frequent and interface complexity is high — which describes every FUTURA vehicle program — the operational difference between a connected model and a document archive compounds quickly. Teams using connected models catch interface conflicts during requirements review. Teams using document archives catch them during integration testing, when the cost of correction is an order of magnitude higher.
The contractors most exposed on FUTURA are those still running requirements in legacy document-centric tools with traceability maintained manually in spreadsheets. In a program with stable requirements and long development horizons, this is manageable. In FUTURA’s environment, it is a systematic risk.
The Honest Assessment
FUTURA is asking systems engineers to do something genuinely hard: build a family of platforms that are simultaneously mature enough to be producible, open enough to accept capabilities that don’t exist yet, hardened enough for direct combat, and agile enough to be modified in the field by soldiers, not engineers. These demands are not fully compatible, and the requirements documents that claim they are should be read with skepticism.
The programs that will deliver on FUTURA’s promise are the ones that have internalized that requirements management is a continuous engineering discipline, not a program-start deliverable. The threat changes. The technology changes. The interfaces change. A requirements architecture that cannot absorb change without a 12-month ECP cycle is a liability on a program defined by change.
Prime contractors who have restructured their systems engineering workflows around connected, model-based requirements management — where traceability is automatic, impact analysis is AI-assisted, and every interface definition is linked to the requirements it satisfies and the tests that will verify it — have a structural advantage. That advantage will be most visible not at program start, when everything is hypothetically compliant, but at the first major requirements revision. And on FUTURA, that first major revision has already happened. Several times.
The platforms will eventually be built. The question is how much rework, how many late integration surprises, and how many requirements conflicts that should have been caught in review will instead be caught on test ranges in the Mojave or, worse, in theater. The systems engineering processes the industry adopts in the next 18 months will largely determine that answer.