Obsolescence Management & Platform Migration

What does legacy PLC obsolescence management cover?

Legacy PLC obsolescence management covers the whole distance from the first lifecycle notice to shipping the replacement.

Two things have to survive that distance unchanged: what the equipment does, and the application logic accumulated inside it. As an example, our team has delivered form-fit-function replacement boards across a ten-board family moving from a Spartan-class FPGA to an Artix-class successor, with nothing the machine could observe changing. The engagement is usually one of these shapes:

• An audit before it is urgent. Obsolescence risk audit and BOM screening, which is far cheaper than reaching the same finding under a notice deadline.
• A notice that has arrived. EOL, PCN or PDN. PCN PDN response engineering, establishing what it affects, what it costs, and which path to take.
• A bridge. Last-time-buy bridge engineering, with the quantity justified against the redesign timeline.
• A replacement board. Form-fit-function replacement PCB work, or drop-in replacement components where the change has to be invisible.
• A platform move. Controller and OS platform migration, VxWorks, eCos or SYS/BIOS onto Linux or FreeRTOS, or SoC and FPGA family migration.
• A kernel move. Linux kernel version migration for device drivers, which stays a contained job until the drivers are out of tree.
• Ongoing cover. Long-term product support for an embedded product, so the next notice arrives against a plan that already exists.

Screening a bill of materials against lifecycle status catches an at-risk part early. When a notice arrives, we run an assessment before any purchase order is committed. Last-time-buy stock is estimated against the redesign it is buying time for, and a substitution is complete only after it has been re-verified against the envelope the original was accepted under. In every case the result has to be indistinguishable from the original where it matters, with evidence that can be retraced.

We do not commission machines or plants. The replacement design, the migration and the evidence behind them are ours to produce, and we integrate and test with your engineers onshore and remotely.

Why is a platform migration planned differently from a component EOL?

The difference is what triggers them.

A component end-of-life arrives as a letter with a date on it. A platform ending has to be assembled from several sources: the RTOS vendor’s roadmap, the FPGA family’s last order date, and the end of the kernel’s long-term support (LTS). The second is more predictable, which also makes it easier to postpone. Either way, both end in the same place: the same function, on new hardware or a new platform, with the logic preserved.

How do you decide a last-time-buy quantity?

It is derived backwards from the redesign, not forwards from current consumption.

• What that avoids. A common miscalculation, buying a round number of years of demand, which either strands capital in stock that outlives the product or runs out during a redesign that took longer than the optimistic estimate.
• What it depends on. How long the replacement will genuinely take to design, qualify and ramp, plus the margin you want between the replacement reaching production and the stock running dry.

How do you plan around a part’s published lifecycle?

We make the published support date part of the design checklist and track it through production.

We re-check it when the vendor landscape changes. For example, Altera, independent again since 2025, extended lifecycle support for its Agilex, MAX 10 and Cyclone V families through 2045 in April 2026. For anyone doing FPGA lifecycle and long-term availability planning, a published date that far out is a real input. That does not remove the need to plan. It changes what the plan is: with a twenty-year horizon the risk moves from the silicon to the toolchain, the build environment and the people who understand the design. A rebuildable build environment is therefore another deliverable on every engagement we take.

What does re-qualification after a component substitution require?

Re-qualification proves that the substitution changed nothing it was not allowed to change.

In practice that is three things:

• EMC re-verification.
• Environmental re-testing against the original envelope.
• Functional-safety re-verification against IEC 61508, where the component sits in a safety-related loop.

Where a machine’s wiring is being opened anyway, that is also the cheapest moment to remove hardwired IO that a networked device can replace, because the redesign is already paying for the access.