Planning around an obsolete PLC CPU

You hear a reference is obsolete and the instinct is to order something, anything, before it disappears. Hold that thought for ten minutes. Check the obsolescence status against the manufacturer's current published information, not against memory or a colleague's recollection. Manufacturers move references through lifecycle phases, and a status that was current at the last audit may have changed since.

Enlarged system diagram

×

The strong path runs through the published source and into the record with a date. Weak claims point back to the same source for confirmation.

Status can also differ by region and by channel. A reference that trades as spare stock in one market may be exhausted in another, and a distributor listing is not the same evidence as a manufacturer lifecycle announcement. Record which source said what, and when. A status note without a date cannot be trusted a year later, because the reference may have moved again. A distributor listing can be current and still prove nothing about the phase-out, because trade stock and lifecycle status are different facts.

The check takes minutes, and it anchors the whole plan to a dated, citable source. The source you record today is the one you re-check when the plan is reviewed, which is why the citation belongs in the planning record and not in someone's inbox. Record the retrieval path too, so the next person can repeat the check without asking how you found it.

Manufacturers usually move a reference through named phases: an active period, a published phase-out announcement, a final delivery date, and then a support tail of varying length. Which phase your reference sits in decides how much time the plan has, so record the phase name and its date rather than only the word obsolete. An announcement dated two years ago and one published last month describe very different amounts of runway for the same reference.

Record the exact reference, revision, and firmware state while the unit still runs. A working obsolete CPU is itself evidence, and it disappears the day it fails. Every fact that could have been read from the running unit, such as the firmware version reported by the engineering tool, becomes unrecoverable afterward. That is the strongest argument for documenting early instead of when the machine stops.

Enlarged system diagram

×

All three captures share one deadline: the day the unit fails. Arrows show what depends on the unit still running.

Note whether a project backup exists and where it is stored, then verify the backup is readable rather than assuming it. Without a usable backup, every recovery route gets harder: a like-for-like exchange becomes a rebuild, and a migration becomes a reprogramming effort. That fact belongs in the planning record, because it changes the cost and time of every route on the list.

Photos of the nameplate taken now cost nothing and answer questions no spare listing can. Capture the rack composition and the network device list the same way, because obsolescence planning covers everything bound to the CPU, not the CPU alone. The same photo also anchors the slot positions you will cite in every later comparison.

If sister machines or lines share the reference, capture them too, even briefly. One line per machine, with its own cabinet location and condition, turns the planning record from a single-unit note into a fleet view. A fleet view changes the economics: a shared spare becomes more defensible, a migration touches more units, and the urgency of any one failure is measured against the number of remaining working units.

Describe what the machine does and what a CPU failure actually stops: one machine, a whole cell, or a function with safety involvement. This risk statement drives how much urgency each recovery route deserves and who needs to be involved in the decision. A CPU that stops one of five identical lines is a different planning problem from a single-sourced unit that halts a whole plant section.

Enlarged system diagram

×

Two inputs size the risk: the blast radius of a failure and the number of bindings a migration would touch.

Ask the people who operate the machine, not only the people who maintain it, because downtime is felt differently on each side. The operating view often surfaces workarounds and sister-line options that a purely technical view misses, and those options change which route deserves investment. The operating view often changes the deadline as much as the priority list.

Capture the surrounding context the same way: the rack composition, the network device list, and the HMI projects that reference the CPU. The migration effort grows with everything bound to the CPU. A successor comparison for a CPU with three connected projects is a different job from one with none.

Safety involvement belongs in the risk statement in its own line. A fail-safe application changes who must be involved, which recovery routes are discussable, and how much revalidation a migration carries. Treat that line as a routing instruction for the plan, not as an adjective. A risk statement that lists safety involvement as one fact among several hides the one fact that reshapes the rest. The effort estimate is also what makes the migration route comparable with the others.

List the candidate routes without committing to one: sourcing a matching unit, a repair or exchange lead, and a migration to a current family. Each route needs different evidence. Sourcing leans on the exact reference and revision; repair leans on the fault history and photos; migration leans on the project and network records. The route list tells you which gaps to close before any other.

Enlarged system diagram

×

Each route names its own evidence needs. The gaps, not the preference, decide what to close next.

Writing the routes down exposes options nobody considered, such as borrowing runtime from a sister line while a unit is sourced. Every binding you capture now is one less unknown during a future migration. The list also keeps a pressured moment from narrowing the choices to whichever supplier calls back first.

Keep the evidence stage separate from the decision stage. A documented reference, risk statement, and route list lets a reviewed decision happen later without repeating the cabinet work. It also keeps the decision from being forced by an outage. A route list reviewed after each event stays short; one revisited after years arrives as archaeology.

Give the route list a review cadence tied to real events rather than the calendar alone. Review it when the phase-out status changes, when a sister unit fails, or when the machine is next serviced, and record what the review changed. A route list that is never revisited drifts out of date silently, and the first forced decision arrives against a list nobody has checked in years.

Stock, lead time, and migration cost stay open questions until a source confirms them, so keep those fields explicit and undated claims out of the plan. The record should state what is known, what is assumed, and what still needs a quote or a supplier confirmation. A reviewed decision needs that separation. Each field can carry its own date, so the known column stays checkable line by line.

Enlarged system diagram

×

The three-way split is what makes the record reviewable. A decision can weigh it without re-deriving the history.

The plan works exactly as intended when the machine fails and the response starts from a completed record instead of a scramble. That is the test of the whole exercise: the outage becomes the moment the plan pays off, not the moment a decision gets forced. That difference is visible only if the plan says what it intended to achieve.

A plan that marks its own gaps can be handed to someone else. The next person sees which fields are facts, which are assumptions, and which routes were never evaluated. That handover quality, more than any single fact in the record, is what keeps the plan alive over the years an obsolete CPU can keep running.

• Verify obsolescence against current manufacturer publications and record the source and date.
• Capture the reference, firmware, backup status, and machine risk while the unit still runs.
• List sourcing, repair or exchange, and migration routes, then close the evidence gaps each one needs.
• Stock and lead time stay open until a source confirms them.

• Ardkor's PLC and CPU section
• how to compare a successor reference
• repair versus replacement evidence