Obsolescence Management in the Aerospace and Defense Industries

The B-52 Stratofortress first flew in April 1952. The U.S. Air Force now plans to keep it flying into the 2050s, which would push some airframes toward a hundred years of service. Its original TF33 engines, on the other hand, won't make the trip. The Air Force considers them unsustainable beyond 2030, because spare parts are becoming too hard to find.

The test systems that support the aircraft age on that same clock, yet they get far less attention. Every avionics unit pulled from an aircraft goes back to a test system before it flies again, and that test system depends on instruments and software that were current the year it was commissioned… until they're not anymore!

This guide explains what this discipline entails and how it fits into military programs. We will address an often-overlooked aspect: maintaining the operational readiness of test systems for as long as the aircraft they support.

Key Takeaways

• Obsolescence management means planning for the day a part or piece of software can no longer be bought, before it stops a system.
• Complete test systems are often left out of obsolescence plans, yet an aircraft can't return to service if the bench that checks its equipment is down.
• Many obsolescence cases can be solved without a redesign when they are spotted early.

Obsolescence Management: Definition

Obsolescence management is the discipline of anticipating and resolving the loss of availability of the items a system depends on, whether hardware parts or software, ideally before that loss takes the system out of service.

Availability is the defining criterion. IEC 62402, the international standard for obsolescence management, defines obsolescence as the moment an item still in use moves from being available to no longer being available from its manufacturer. A component or system can therefore be perfectly functional and still obsolete if its manufacturer no longer produces or supports it.

Seen this way, obsolescence becomes a supply event that can be planned for well before it disrupts operations. The 2019 edition of IEC 62402 made this explicit by turning what used to be an application guide into a standard with actual requirements, applicable across every phase of an item's life cycle.

Companies will either do reactive management, which is waiting for an end-of-life notice, or proactive management, which is monitoring lifecycle data continuously. To no one's surprise, it's better to be proactive, because low-cost (and lower effort) solutions can still be on the table.

Obsolescence Management vs. Diminishing Manufacturing Sources and Material Shortages (DMSMS)

If you work on U.S. defense programs, obsolescence is recognized under a different name. The Department of Defense (DoD) calls the same problem DMSMS, short for Diminishing Manufacturing Sources and Material Shortages. The scope is deliberately broad. DoD policy applies proactive, risk-based DMSMS management to hardware and software items alike, throughout their life cycle.

Obsolescence Management in Aerospace and Defense: Even More Important

Aerospace and defense programs must find solutions for obsolete parts over service lives that few other industries approach.

Component Lifecycles vs. Platform Lifecycles

The core problem is a mismatch of clocks. Electronic components follow the pace of commercial markets. Their lifespans keep getting shorter. But the platforms they end up in are built to serve for decades. Some tested platforms stay in service for more than 40 years, long enough to watch several generations of their own parts disappear!

Test Systems Become Obsolete Too

Obsolescence plans usually center on the aircraft and its onboard electronics. They give far less attention to the test equipment behind them. Yet a test system must stay available as long as the system it supports, while its own components age at the same pace. When a station goes down, every unit waiting for it stays grounded too.

One of the biggest issues we face is that the software that runs on a test system is part of the airworthiness acceptance of the product that flies, whether it is military or civil. Once it's 30 years old, nobody has the technical or commercial appetite to change it as recertification costs will likely run into the hundreds of thousands of pounds (that's millions of dollars to you). This means that we have to retain the original software but run it on new hardware and that's where the biggest challenges lie. Simply put, it's not an easy task. On one replacement program we handled, rehosting the software was ruled out from the start. Nobody could say for sure which source code matched what was actually running.

For test systems, obsolescence management is really one part of a broader lifecycle support approach, covering modernization and life extension as much as parts replacement.

We know this territory well. Averna Powered by Spherea delivered its first ATEC test bench for Concorde and the Mirage F1 in 1965, and many benches our teams built in the 1980s and 1990s are still in service today. That experience now shapes our obsolescence management services for test systems.

How to Manage Obsolescence of Military Parts?

Obsolescence management in the military follows the same logic: defense ministries write it into policies and contracts, and extend it to the support and test equipment programs around each weapon system. Only the vocabulary and the reference documents vary by country.

In the United States, the DoD Instruction 4245.15 requires every program to manage DMSMS proactively over the full life cycle of its systems, and the SD-22 guidebook documents the best practices behind it. The Defense Acquisition University also points out that shortages can endanger test equipment, beyond the parts built into the weapon system itself.

In the United Kingdom, the Ministry of Defence writes obsolescence into its contracts. A recent MoD requirement asks the supplier for an obsolescence management plan compliant with Def Stan 00-600 and BS EN IEC 62402:2019, covering spares along with support and test equipment down to their constituent parts.

Across NATO, STANAG 4597 brings obsolescence management into military project planning and matches the 2007 edition of IEC 62402, giving allied programs a shared reference with the civil standard. In France, for instance, obsolescence is handled within MCO (maintien en condition opérationnelle), the discipline of keeping equipment mission-ready throughout its service life.

What Are the Main Obsolescence Resolution Strategies?

Once a part reaches end of life, the available options differ widely in cost and effort. SD-22 defines nine resolution options and assigns each an average cost, so programs can budget.

Fortunately, most cases never require the expensive options. In one DoD case summary presented in 2024, half of the 8,358 cases reviewed turned out to have no actual issue, and about a third were solved with a simple substitution. Life-of-need buys covered roughly 15%. Redesigns accounted for less than 1%, meaning 99.3% of cases were resolved without one. That result reflects how much early detection widens the options.

Last-Time Buy and Drop-In Replacement

A last-time buy, also called a life-of-need buy, secures enough stock to cover projected demand until the system retires. It requires almost no engineering, which explains its popularity. It also moves the entire supply risk onto your own shelves: the stock must be sized correctly and kept in controlled storage until the day it's needed, sometimes decades later.

A drop-in replacement swaps the obsolete part for a form, fit and function equivalent. Although it sounds like the simple option, in aerospace and defense even a functionally identical part changes the approved design. The change has to be accepted by the Design Authority (DA) and, where airworthiness is affected, by the relevant airworthiness authority, such as the Military Aviation Authority (MAA) in the UK, or EASA and the FAA for civil aircraft. Knowing how to build and submit that case is a skill in itself, and the process takes significant time and money.

Emulation and Behavioral Equivalence

Emulation reproduces the behavior of an obsolete item with current technology. At the part level, a modern device mimics the electrical behavior of the original. At the test system level, new hardware reproduces the signal and timing behavior of the legacy instruments, so existing test programs keep running unchanged.

That is why emulation is often the easiest way forward in aerospace and defense. Because the test system keeps behaving exactly as before, the approved test programs stay the same, which can greatly reduce the approval effort compared with a replacement.

Redesign and Platform Migration

Redesign removes the dependency entirely, by rebuilding the assembly around current parts or by migrating the test system to a modern platform. It is the most expensive option and also the one with the most longevity. An architecture built on Commercial Off-The-Shelf (COTS) components and open industry standards can absorb future obsolescence one module at a time, instead of forcing another full replacement down the road.

Migration doesn't have to happen in a single step. Some programs replace instruments one by one inside the existing infrastructure, then finally retire the old chassis and controller. The cost spreads across several budget cycles, and the station stays in service throughout the transition.

Regardless of which option a program ultimately chooses, it is much easier to make that decision well in advance. That is the goal of an obsolescence management plan.

What Is an Obsolescence Management Plan and What Should It Include?

An obsolescence management plan (OMP) records the items exposed to obsolescence and the action planned for each one when supply runs out. Every framework covered above expects one. IEC 62402 lists the development of an OMP among its core areas, and U.S. programs formalize the equivalent as a DMSMS management plan. The U.K. MoD requirement mentioned earlier also asks the supplier to name the standard the plan follows, and to have it agreed upon by the authority.

For a test system, the best moment to write the plan is at delivery, while its designers are still available. The team that built a platform knows why each component was chosen and what replacing it would involve. The goal is to preserve this knowledge securely.

Core Elements of an Obsolescence Plan

• Policy and governance: the plan starts by naming who owns obsolescence decisions and which standard applies, such as IEC 62402. It also sets the budget, since an unfunded plan tends to become a reactive one.
• BOM and inventory mapping: a live bill of materials lists every item that can become obsolete, down to constituent parts, including spares and test equipment. Software belongs here as well: operating systems, drivers, development environments and licenses all reach end of life.
• Criticality and risk: each item receives a criticality rating, which measures the impact on the test system if it disappears, and a risk rating, which estimates how likely and how soon that will happen. Sole-source dependencies and long lead times push an item higher in the ranking.
• Monitoring method: document which lifecycle data sources are tracked and who watches them, so end-of-life notices reach someone effectively.
• Plan of record: for each item, a plan of record defines the response chosen in advance, whether a last-time buy, a form-fit-function replacement, emulation or a redesign, along with its timing.
• Performance review: IEC 62402 also requires organizations to measure how well their obsolescence management performs and how to improve it. Comparing the cases resolved in time with the end-of-life events that caught the team by surprise shows whether the plan actually works.

Obsolescence Management Plan Example for a Test System

The table below shows what an obsolescence management plan could look like for an aging avionics test bench. The entries are illustrative.

What Are the Best Practices for Test System Obsolescence Management?

The following practices reduce how often obsolescence disrupts a test system:

• Ecosystem audit
• Maximizing COTS components and open standards
• Layered software and abstraction layers
• Flexible common-core architecture
• Planned technology insertions

Most of them are decided at design or modernization time, when they cost the least.

Test Ecosystem Audit

A test ecosystem audit identifies the technical and business risks associated with each environment operated by an organization and assesses the degree to which each is vulnerable to obsolescence. This audit must also determine the actual functionality of each system, which rarely matches what is stated in its documentation after decades of modifications. Reliable records matter here as much as in daily operations, a point we cover in managing test data for aerospace MROs.

This is exactly what we encountered when working on a low-speed wind tunnel at a major aerospace manufacturer in the United Kingdom. The facility had undergone several modifications over the years, and the original documentation and drawings were limited; as a result, there was significant uncertainty regarding the exact operation of the system we were tasked with replacing. We began by conducting a comprehensive site survey, examining the hardware and software as well as all available documentation to establish a requirements specification. This specification enabled us to evaluate each existing subsystem and propose options for streamlining and modernization, while adhering to fixed constraints such as the existing wiring.

Lifecycle Monitoring and Supplier Alerts

End-of-life notices and product change notifications (PCNs) are an early warning. Track them with a monitoring tool or service. Stay in regular contact with your suppliers to hear about discontinuations before the last-time-buy deadline. Suppliers willing to share their product roadmaps give you more time to plan.

Shared Ownership Across Teams

Obsolescence decisions involve engineering as much as procurement. When buyers know which instruments are critical, they can write long-term support and spares into contracts from the start, instead of negotiating them in an emergency.

Standard, Off-the-Shelf Components

COTS instruments are used by many companies; their manufacturers therefore continue to support them and release successor models. Industry standards shared by multiple suppliers provide a safety net: if one supplier stops manufacturing a module, another can provide a compatible one. PXI, a modular instrumentation standard used worldwide and supported by more than 60 companies, is a good example. The same logic applies when designing flexible test stations for production.

Test Software Independent of the Hardware

If test programs communicate directly with the instruments, replacing an instrument requires rewriting and revalidating those programs. An abstraction layer, software interposed between the tests and the instruments, allows you to avoid this: when you replace the instrument, only the layer changes. In the United States, the Marine Corps has adopted this approach for its VIPER/T test system. Our NewWaveX platform implements it through the international IEEE 1641 standard, which defines tests based on the signals they require rather than on the instruments that generate them.

Standardized Test Systems

Ten test systems built by ten suppliers mean ten different obsolescence problems. Building them on the same base design, with only the product-specific interfaces changing, lets you address each obsolescence issue once for the whole fleet.

On one program, replacing an obsolete test system was only our first objective. The second was defining a common architecture for the replacement of twelve more, because we knew a single shared core would be far easier for our customer to support over the years than a dozen separate systems.

Planned Upgrades

Rather than replacing parts on an ad hoc basis in emergencies, consolidate multiple replacements into a single planned upgrade, synchronized with lifecycle data. This means you get to choose when the test system is taken out of service.

Get Averna Powered by Spherea's Support for Your Aerospace & Defense Test Equipment

On programs that last decades, obsolescence can't be avoided, but its cost depends largely on how early you start managing it.

Averna Powered by Spherea provides custom obsolescence management and DMSMS solutions for your critical test platforms, as part of a complete test system lifecycle support offer, covering modernization and life extension. Our teams can audit your existing test fleet, keep legacy benches running with maintenance and repair support, or replace them with modern systems that preserve your validated test programs.

For organizations ready to consolidate, SiClone, our next-generation general purpose automatic test equipment (GPATE), handles fully automated and manual testing, and everything in between, on a single platform built from easily replaceable COTS components.

Explore how SiClone replaces obsolete avionics test equipment or talk to our test experts about your legacy test systems.

Reviewed and edited by

Max Strover

VP Sales & Business Development – Aerospace Europe

LinkedIn

You may also be interested in…

Download our brochure on SiClone, our modular system designed to replace and replicate obsolete avionics test equipment