The twenty-year fleet and the seven-year part

A transport aircraft entering service today will still be flying in 2050. The controller inside it contains parts whose production life is measured in single-digit years. Everybody knows this. Almost nobody plans for it.

The conversation usually starts the same way: a last-time-buy notification arrives, an aircraft on ground somewhere needs a board, and the spares pool is thinner than anybody thought. It is treated as a purchasing emergency. It is not. It is a design decision, made years earlier, arriving on schedule.

Buying the problem forward

The instinctive response is a lifetime buy: purchase enough devices to cover projected demand for the rest of the programme and put them in a cupboard.

It has real limits. Demand forecasts over twenty years are guesses, and they are usually low, because they are made by people who are optimistic about reliability. Stored semiconductors are not inert — solderability degrades, moisture-sensitive parts need controlled storage, and plastic packages have a real shelf life. And the money is spent now for a benefit that arrives, if at all, in a decade.

It also does nothing about the second obsolescence. There is always a second one.

A lifetime buy is a bet that your demand forecast is right. In our experience the forecast is short about two-thirds of the time.

Designing so the replacement is contained

The alternative is to accept that parts will be replaced and to make sure the replacement is a small job. That is an architectural property, and it has to be decided early:

• Put a real boundary around the volatile parts. Processors, memory and programmable logic churn fastest. If everything else in the system reaches through them, everything else is in scope when they change.
• Specify the interface, not the implementation. Downstream systems should depend on the electrical interface, timing contract and fault semantics — never on which device happens to be behind it.
• Know what your qualification is attached to. If the evidence is tied to a specific device, replacing it re-opens all of it. If it is tied to a characterised interface, a lot of it survives.
• Review lifecycle status at every design gate. Not annually, and not as a procurement report. A part entering not-recommended-for-new-design status is a design input.

What it looks like when it works

We have written up the Meridian case separately: a rad-hard FPGA went end-of-life mid-constellation and the redesign took nine weeks instead of the six months it would otherwise have needed. The whole difference was a boundary drawn three years earlier around the processing core.

That boundary was not free. It cost measurable performance in one data path, and an engineer argued against it at the time with a perfectly good technical case. It survived because someone insisted the core would outlive at least one silicon generation.

The honest version

Obsolescence management is not a spares strategy. It is a set of design decisions made a decade before the consequences show up, by people who will mostly have moved on before anyone finds out whether they were right.

Which is exactly why it needs to be written down as a decision, with its reasoning, at the time it is made. Not so anybody gets credit — so the argument does not have to be won again from scratch by whoever is holding the line in year eight.