Leonardo DRS: Sustaining Combat Electronics While the Army Goes Digital

Leonardo DRS sits in a structural position that few defense electronics companies navigate well: it is simultaneously a sustaining contractor for some of the most mature platforms in the U.S. Army inventory and a development contractor for programs that will define what Army ground combat looks like in the 2030s. That dual role—sustaining the Abrams and Bradley fleets while pursuing next-generation power, targeting, and vehicle electronics contracts—shapes everything about how the company structures its systems engineering.

What DRS Actually Builds

The public-facing product portfolio understates the technical complexity inside. DRS’s ground vehicle electronics business divides roughly into three domains.

Power and thermal management covers the vehicle power architecture for combat platforms—power conditioning units, auxiliary power units, thermal management subsystems for electronics bays that have to survive temperature extremes from Arctic Norway to Saudi Arabia. As platforms add electronic warfare payloads, active protection systems, and high-definition sensor suites, the electrical load budgets established in original platform designs are under constant pressure. DRS manages that pressure through incremental load growth analysis and power architecture redesigns that have to be backward-compatible with decades-old vehicle wiring harnesses.

Electro-optical and infrared targeting is the higher-profile business. DRS’s Commander’s Independent Thermal Viewer (CITV) and related targeting systems appear on Abrams variants and have been updated repeatedly as detector technology advanced. These systems sit at the intersection of optics, cryogenic cooling, image processing firmware, and ballistic fire control software. The hardware generations are discrete—new detector arrays, new cooler designs—but the fire control interface has to maintain backward compatibility with vehicle systems that may not be upgraded on the same schedule.

Vehicle electronics and computing covers mission computers, driver’s vision enhancement systems, and the electronics integration work that ties payloads together inside the vehicle. This is where DRS touches the Army’s emerging software-defined vehicle architecture ambitions most directly.

The Lifecycle Tension

The Abrams M1A2 SEPv3 has been in service in various forms since 1980. The Bradley M2A3 entered service in 1988. Both platforms are expected to remain in the active fleet into the 2030s and potentially beyond, even as the Army pursues XM30 (the Bradley replacement) and the Optionally Manned Fighting Vehicle concept. Leonardo DRS supports electronics on both legacy platforms while simultaneously competing for electronics roles on successor programs.

This creates what program managers inside the defense industry call the sustaining-developing split, and it is genuinely difficult to manage. Sustaining work operates under configuration control disciplines that prioritize stability—any change to a fielded system triggers formal regression testing, safety case updates, and potentially a formal modification or RESET program with Army approval. The engineering artifacts governing those systems often date from original development: requirements documents in Word or DOORS databases structured to MIL-STD-498 practices, interface control documents maintained in PDF, test procedures stored in proprietary formats.

Next-generation development work, by contrast, operates under Army Acquisition Workforce Modernization mandates that increasingly require digital engineering artifacts from contract award. Model-based systems engineering deliverables, digital interface definitions compatible with the Army’s Common Operating Environment, and requirements structures that support automated traceability are now standard source selection criteria rather than optional enhancements.

The engineers doing sustaining work and the engineers doing new development work are, in many cases, the same people. The knowledge about how a specific CITV variant interfaces with the SEPv3 fire control system lives in the heads of engineers who have maintained that system for a decade—not in a structured model that a new program team can query.

Hardware, Software, and Firmware: Where the Boundaries Bite

The technical risk in DRS’s portfolio concentrates at hardware-software-firmware boundaries, and those boundaries are where lifecycle mismatches create the most operational difficulty.

Consider a targeting system upgrade. The Army wants improved detector sensitivity—a hardware change. The detector drives a new focal plane array with different readout timing, which requires firmware changes to the image processor. Those firmware changes affect the image stabilization algorithm, which is software. The software change affects the fire control interface behavior, which is governed by an ICD negotiated with a different prime contractor. That ICD was written in 2009 and lives in a PDF on a shared drive.

This is not a hypothetical. It is the routine structure of any non-trivial electronics upgrade on a mature platform. Managing it requires that the relationships between hardware specifications, firmware build configurations, and software behavioral requirements be traceable and queryable—not just documented in a pile of controlled artifacts, but connected in a way that lets engineers assess change impact before committing to a design path.

Legacy requirements infrastructure, whether that is IBM DOORS databases from the original development program or document trees maintained under configuration management, stores this information but does not connect it. Finding the impact of a detector timing change on the fire control ICD requires someone who knows where to look and can interpret documents written in different eras by different teams. That knowledge is not scalable, and it is not transferable when the engineers who hold it retire.

The Army’s Digital Engineering Mandate

The Army’s Digital Engineering Strategy, formalized through the Office of the Assistant Secretary of the Army for Acquisition, Logistics and Technology, now expects prime contractors and major subcontractors to maintain authoritative digital sources of truth for program technical data. The specific implementation varies by program, but the direction is consistent: requirements should be machine-readable, interfaces should be defined in structured formats compatible with SysML or equivalent, and verification should be traceable from requirement to test result in a queryable artifact—not reconstructed from a collection of PDFs at the end of a program phase.

For a company like Leonardo DRS, this mandate has two distinct effects.

On new programs, it establishes the expected delivery standard from the outset. Source selections for XM30-related electronics work, Army Futures Command-sponsored development programs, and modernization efforts under the Next Generation Combat Vehicle portfolio will evaluate offerors’ digital engineering infrastructure as a technical differentiator. DRS competes against larger primes—Raytheon, L3Harris, BAE Systems—that have invested heavily in MBSE infrastructure. A mid-tier integrator without a credible digital engineering story is at a structural disadvantage in those source selections.

On legacy programs, it creates a data recovery problem. The Army increasingly wants digital artifacts that reflect the current state of fielded systems, not just the state at original delivery. Generating those artifacts from legacy documentation requires structured effort—not a one-time conversion, but an ongoing process of capturing engineering decisions in structured form as sustaining work proceeds.

How Mid-Tier Integrators Are Responding

The strategic options for a company in DRS’s position are not complicated, but execution is.

One path is to invest in MBSE tooling and training to the point where new development programs are natively digital from the start, and then use sustaining work as an opportunity to incrementally build digital representations of legacy systems. This requires tooling investment and, more importantly, a change in engineering workflow—requirements captured in structured tools rather than Word documents, interfaces defined in models rather than PDFs, verification traced in databases rather than spreadsheets.

The tooling landscape has moved toward this capability. Modern requirements management platforms have shifted from document-centric paradigms toward graph-based models where requirements, interfaces, and verification records are nodes with explicit relationships. That architecture is what makes impact analysis tractable—when a firmware change touches a requirement, the system can surface which interfaces and test cases are downstream of that requirement without a manual search.

Tools like Flow Engineering have built this graph-based, AI-assisted traceability model natively for hardware and systems engineering teams, rather than retrofitting AI features onto legacy document management infrastructure. For a mid-tier integrator managing concurrent sustaining and development work, the operational benefit is concrete: engineers assessing change impact on a platform upgrade can query requirement relationships rather than reconstructing them from institutional memory. That capability directly addresses the lifecycle knowledge transfer problem that mid-tier defense electronics companies face when experienced engineers transition off programs.

The alternative path—continuing with document-centric practices on new programs and treating digital engineering as a compliance checkbox rather than a functional workflow—is available in the short term but narrows with each source selection cycle. Army program offices are getting more specific about what digital engineering artifacts they expect and when, and source selection evaluators are developing the technical literacy to distinguish functional MBSE from decorated Word documents.

Honest Assessment

Leonardo DRS has genuine technical depth in power, thermal, and electro-optical engineering for ground combat systems. The institutional knowledge about how Army vehicle electronics actually behave in the field—the thermal management problems that manifest only in sustained high-ambient operations, the power quality issues that correlate with specific engine RPM ranges, the image processing artifacts that appear in specific sensor configurations—is not easily replicated by a competitor without similar field history.

That knowledge is also a liability if it remains tacit. The Army’s digital modernization programs are, among other things, a mechanism for capturing and formalizing engineering knowledge that currently lives in experienced engineers and legacy documentation. Mid-tier integrators that participate actively in that knowledge formalization—that build systems engineering infrastructure capable of supporting the digital artifact requirements on next-generation programs—will find themselves better positioned for the sustained competition that defines defense electronics over 20-year program horizons.

The companies that treat digital engineering as a procurement formality rather than a functional engineering capability will find that the gap between what they can deliver and what source selections require widens over the next five years. For Leonardo DRS, the window to build that infrastructure while sustaining work provides revenue stability is open. It will not stay open indefinitely.