Engineering for Decades: How Defense Electronics Manufacturers Are Managing Component Obsolescence

An Arleigh Burke-class destroyer has a designed service life of roughly 35 years. An F-35 purchased off the current production line is expected to fly operationally through at least the early 2060s. The AN/APG-83 radar that equips the F-16V runs on processors whose commercial equivalents were discontinued before the programs that depend on them reached initial operational capability.

This is the structural reality of defense electronics: systems designed for one semiconductor generation must survive four or five generations of commercial silicon cycles. The industry has lived with this tension since the transition from military-specific components (MIL-SPEC parts with guaranteed long-term supply) to commercial off-the-shelf (COTS) procurement in the 1990s. The COTS pivot delivered real capability gains and cost reductions. It also transferred a serious long-term risk onto program offices that were poorly equipped to manage it.

That risk is now materializing at scale. The pace of commercial semiconductor innovation has accelerated — driven by AI, automotive, and mobile demand — while defense acquisition timelines have not shortened. Understanding how serious defense electronics manufacturers are engineering around this reality is no longer a niche concern. It is a core systems engineering competency.

The Structural Mismatch, Quantified

The numbers frame the problem clearly. Commercial microprocessors and FPGAs have product life cycles of approximately three to seven years from introduction to end-of-life notice. Military programs have acquisition phases that can span a decade, followed by production runs of another decade, followed by sustainment periods of 20 to 30 years. The total exposure window for a single program can exceed 40 years.

The IHS Markit (now S&P Global) electronic components obsolescence database has historically tracked tens of thousands of active end-of-life notices per year. Defense programs typically receive 18 to 24 months of notice before a part is discontinued — occasionally less, particularly when a semiconductor manufacturer exits a product line due to fab consolidation or market pressure.

The economics of reactive response are punishing. A 2019 analysis by the Government Accountability Office found that the Navy’s surface combatant programs were spending between $10,000 and $1.5 million per obsolete component resolution, depending on whether a direct replacement was available or a board-level redesign was required. When redesign triggers re-qualification to MIL-STD environmental standards — vibration, thermal cycling, EMI — costs climb further and schedules stretch by 18 to 36 months.

Against that baseline, even expensive proactive management pays for itself.

Four Strategies That Actually Work

Serious defense electronics houses are deploying a combination of four interlocking approaches. They work together; programs that implement only one or two tend to find the gaps later.

1. Parts Selection Policy and Continuous Monitoring

The first line of defense is structured parts selection at design time. Mature organizations maintain Qualified Parts Lists (QPLs) that overlay commercial availability data — specifically, estimated time to end-of-life based on the part’s position in its commercial product cycle — against program duration requirements. Parts entering the design at the beginning of a production run that will span ten years need a remaining commercial life of at least that length, or a documented mitigation strategy.

This is not a one-time gate. Best-in-class programs implement continuous parts monitoring throughout production and into sustainment, tracking end-of-life notices, distributor inventory trends, and manufacturer roadmap signals. Tools like SiliconExpert and Siliconexpert’s competitive set (Part Analytics, Supplyframe DesignLine) automate much of this signal collection, but the human interpretation layer — translating signals into program risk — remains essential and is often where programs fall short.

The monitoring discipline also surfaces a counterintuitive insight: the most dangerous obsolescence events are not the ones you see coming with 24 months of notice. They are the ones triggered by upstream supply chain events — a fab shutdown, a raw material shortage, a foundry customer prioritization decision — that bypass normal end-of-life notification processes entirely. Diversified sourcing strategies and second-source qualification at design time are the hedge against those scenarios.

2. Proactive Lifetime Buy Strategies

When a critical component is approaching end-of-life and no form-fit-function replacement exists, lifetime buys — purchasing sufficient inventory to supply the program through its projected service life — are a legitimate tool. They are also frequently misapplied.

Lifetime buys require accurate demand modeling across production, fielded system maintenance, and potential attrition replacement. Programs that underestimate end up back at the redesign decision point years later, with less time and money. Programs that overestimate carry inventory costs and storage risks — electrolytic capacitors degrade; solderability of plated components degrades; static-sensitive devices require controlled storage conditions that add cost and management overhead.

The better-managed programs treat lifetime buy as a last resort, implemented only after form-fit-function qualification of alternatives has been exhausted. When it is executed, it is done with actuarial rigor: demand modeling informed by historical maintenance data, attrition assumptions validated against fleet data, and storage qualification testing to verify that the purchased inventory will still meet specifications at the projected draw-down date.

3. Form-Fit-Function (F3) Equivalent Qualification

The preferred alternative to lifetime buy is qualification of an equivalent replacement: a component that meets the same form (physical footprint), fit (interface and pinout), and function (electrical performance) as the obsolete part, sourced from a continuing manufacturer or synthesized using updated silicon.

F3 qualification is faster and cheaper than full redesign but is not trivial. The qualification process typically involves characterization testing to verify that the replacement meets or exceeds the original part’s performance envelope, followed by qualification testing to the applicable MIL-STD standards for the application environment. For flight-critical systems, this process runs through formal certification channels. For less critical subsystems, program-level qualification authority may apply.

The harder challenge is traceability. Which systems in the fleet contain the original part? Which production lots received the qualified replacement? Which systems had field modifications applied? Programs without rigorous configuration management infrastructure — and many long-running programs do not have it, because that infrastructure was not required at program inception — face significant cost and risk in answering those questions during sustainment.

This is where the requirements and systems engineering infrastructure intersects directly with the hardware problem.

4. Architecture-Level Obsolescence Tolerance: FPGAs and SDR

The strategies above are defensive — they manage obsolescence events as they occur. The most durable long-term strategy is architectural: designing hardware so that capability can be updated or replaced without structural hardware redesign.

Two approaches dominate in defense electronics.

FPGA-Based Processing Architectures

Field-programmable gate arrays have been a staple of defense signal processing for 25 years, but their role in obsolescence management has grown more deliberate. The logic: FPGA vendors — Xilinx (now AMD) and Intel (formerly Altera) in particular — maintain architectural compatibility across device generations more carefully than microprocessor vendors, and the programmable fabric means that a design can migrate to a newer device with updated HDL rather than a board redesign. Lockheed Martin’s radar programs, Raytheon’s electronic warfare systems, and multiple missile seeker programs explicitly use FPGA replacement strategy as a documented obsolescence mitigation.

The limits of this approach are real. FPGA migration is not free — timing closure on a new device requires engineering effort, and design tools must be maintained across tool generations. The approach also depends on continued support for the hardware description language toolchain, which itself has lifecycle implications. But as mitigation strategies go, it provides meaningful flexibility that pure ASIC or commercial processor designs do not.

Software-Defined Radio (SDR) Architectures

In communications and radar systems, software-defined radio architectures move as much functionality as possible into software executing on programmable hardware, with the RF front end defined at a higher level of abstraction. The Joint Tactical Radio System (JTRS) program — troubled as a program, but influential as an architecture concept — established the Software Communications Architecture (SCA) that underpins most current military SDR implementations.

The obsolescence benefit is significant: when the underlying waveform processor is upgraded or replaced, the waveform software can be retained, re-hosted, and recertified independently of the hardware change. In practice this is still expensive, but it is substantially cheaper than redesigning both hardware and software simultaneously.

Current naval programs and the Air Force’s Next Generation Jammer both use SDR-derived architectures specifically because the anticipated service life of the platforms they will serve extends far beyond the plausible service life of any specific processor implementation.

The Requirements Problem Is Harder Than the Hardware Problem

Engineering teams that have gone through a difficult obsolescence-driven redesign consistently identify the same root cause: the original system requirements did not adequately specify supportability and obsolescence tolerance as first-class design requirements.

This is not negligence. Early in a program, before the design baseline is established, it is genuinely difficult to write testable requirements for obsolescence tolerance. What exactly does it mean to require that a system be “supportable for 30 years”? The answer requires decomposing that high-level objective into specific, verifiable requirements: maximum allowable percentage of single-source components in the design, minimum required parts availability horizon at initial design authority approval, required FPGA architectural migration documentation, required configuration management granularity at the component level, required inclusion of parts monitoring in the program’s integrated master schedule.

Each of those derived requirements connects back to design decisions made at the component, board, subsystem, and architecture level. Maintaining those connections — understanding, years into sustainment, why a specific component was selected, what the documented mitigation strategy was, and whether that strategy was actually implemented — requires requirements management infrastructure that most long-running programs do not have in a useful state.

The data is typically there, somewhere. It lives in program documentation databases, in PDFs filed in SharePoint, in email threads that have changed hands through three program manager transitions. The traceability — the live, queryable connection between a requirement and the design decision that satisfies it — is usually not maintained.

This is where modern requirements tooling changes the calculus. Tools like Flow Engineering, which builds AI-native requirements management specifically for hardware and systems engineering teams, approach this differently from legacy document-based systems. Rather than treating requirements as a document hierarchy with manual traceability links, the approach models requirements as a graph — where the relationship between a top-level supportability requirement, its derived component-selection criteria, and the specific design decisions that implement those criteria is a traversable, queryable data structure, not a PDF with color-coded cells. When an obsolescence event surfaces years into sustainment, that traceability infrastructure tells you which systems are affected, what the original design rationale was, and whether a proposed substitution satisfies the original requirement — rather than requiring an engineering team to reconstruct that analysis from scratch.

The contrast with tools like IBM DOORS or Polarion is not that those platforms cannot store traceability information — they can. It is that maintaining live traceability in those environments requires sustained manual discipline that erodes over the lifecycle of a 30-year program. AI-assisted traceability maintenance, where the tool actively identifies gaps and suggests links based on semantic relationships between requirements and design artifacts, is a meaningful operational improvement for exactly the long-lifecycle sustainment scenario that defense programs face.

Where the Industry Is Today: An Honest Assessment

The defense electronics industry has made real progress on obsolescence management since the early COTS transition stumbles of the late 1990s and early 2000s. MIL-HDBK-61B establishes configuration management practices that, when followed, provide the foundation for coherent obsolescence response. SAE standards for diminishing manufacturing sources and material shortages (DMSMS) provide a structured framework. Major primes — Lockheed, Raytheon, Northrop, BAE Systems — have dedicated DMSMS organizations with real capability.

The gap is in the middle tier: subsystem suppliers, component integrators, and smaller platform integrators who carry real program risk but lack the infrastructure of the large primes. For those organizations, obsolescence management is often still reactive, still triggered by end-of-life notices rather than managed proactively, and still disconnected from the requirements infrastructure that would make response faster and cheaper.

The accelerating commercial semiconductor cycle — driven by AI compute demand and leading-edge node investment that is economically indifferent to defense program schedules — means this problem will intensify before it stabilizes. Programs being designed today for 2055 delivery will encounter silicon generations that do not yet exist, manufactured at fabs that have not yet been built. The engineering response has to be structural: architecture designed for replaceability, requirements written to specify supportability, and configuration management infrastructure maintained well enough to support decisions 30 years from now.

The programs that get this right will spend their sustainment budgets on capability upgrades. The ones that do not will spend them on emergency redesigns.