Recovery options for an obsolete HMI

Nobody sends a notice the day a panel becomes hard to replace. You usually find out when you need a spare and the catalog has changed. Manufacturers publish lifecycle states, and the words carry more nuance than the shop floor assumes. A panel can be in series production, marked mature or phase out with a last order date, or limited to spares only.

Enlarged system diagram

×

The stages are the common manufacturer vocabulary, not a clock. Check the notice for the exact reference before acting.

None of those states means the unit is unavailable from every source, and none of them means the unit is safe from disappearing. A phase out notice with a future last order date is a scheduling window, not a deadline you can rely on to hold. Series production can still leave your region early. The status describes the manufacturer's plan, not your machine's future.

Obsolescence also has a local side the manufacturer cannot see. A panel can be an active series product and still be obsolete for your plant because the engineering software no longer runs on available computers, or because the person who held the project has left. Both cases deserve the same documentation as a formal phase out.

The boundary to carry through this guide: lifecycle status is a planning input, and it is not a verdict. Every route in the later sections stays open longer than the status alone suggests, as long as the evidence exists to support it.

Lifecycle status attaches to the reference, not to the family name. Check the status against the manufacturer lifecycle notice for the exact order number, because a family can hold one phase out reference next to a still active sibling. A check that runs on KTP700 or PanelView Plus 7 answers a question nobody asked.

Enlarged system diagram

×

The chain starts from the reference, never the family. A reseller page is a lead, the manufacturer notice is the evidence.

Record three things from the notice: the status, the notice date, and any stated successor model. The notice date matters because lifecycle pages get revised, and a check from three years ago may describe a different world. The successor model matters because it names the migration path the manufacturer themselves expects, even when you decide against it.

A concrete example of why this discipline pays: two panels in one plant share a family name, and the lifecycle check returns phase out for one reference and active production for the other. The plant that checked the family name ordered a spare for the wrong unit and missed the window for the right one. Ten minutes with the exact reference would have caught it.

The limit here is honesty about sources. A lifecycle status found on a reseller page is a lead, and the manufacturer notice for the exact reference is the evidence. Record where your status came from, exactly as you record the source of an alias in the linked reference guide.

Capture the project and firmware before anything else, using the steps in the linked backup guide. On an obsolete panel this is more urgent than on a current one, because the engineering tool, the runtime, and the transfer path can all disappear together. Record which tool version can still open the project and which computer currently runs it. That computer is part of the recovery plan now.

Enlarged system diagram

×

Three streams feed the recovery evidence, and the files are the only stream that cannot be reconstructed later.

Photograph the screens that carry machine specific logic. Passwords, recipe handling, and alarm texts live in the project, but a photo set of every operational screen lets any rebuild be checked against what operators actually use. Include the diagnostics pages, because they show the exact order number and firmware on units whose labels have worn away.

Operators know these screens better than any drawing, and they are the cheapest source of test cases for a future rebuild. Ask them which pages matter, which values they watch, and which button saves them at three in the morning. One conversation gives the rebuild a checklist no document contains.

One limit frames the capture: photos and notes support the project file, they never replace it. A rebuild from photos alone is an estimate, and the estimate gets worse with every screen the project contained. The files come first, and the photos make the files verifiable.

Inventory what exists locally, because it changes the risk picture at no cost. A shelf spare, a second machine with the same panel, or a donor unit on another line each reduce the urgency of every external route. Count how many units of this exact reference the plant runs, because one unit and a fleet of twenty justify different decisions about migration.

Enlarged system diagram

×

Three local streams make up the inventory. Arrows show what the record contains, not any technical dependency.

The inventory extends beyond hardware. Note whether the engineering software and any license it needs are still available locally, and on which computer they run. Both tend to disappear faster than the hardware, and a migration or rebuild that lacks a working engineering station is a paper plan.

Write down the people too. Who holds the project knowledge, who holds the passwords, and who can still read the old program comments. The linked backup guide treats the password owner as part of the backup, and the same logic applies to the whole recovery plan. A name and a phone number belong in the record.

A boundary keeps the inventory honest: a local count is a snapshot, and it ages. Units get scrapped, spares get used, computers get replaced. Date the inventory and note who walked the plant, so the next reader knows how much they can trust the numbers.

The review normally compares four routes. Keeping the panel running with a documented spare suits a fleet with healthy units and a known failure mode. Repairing the installed unit suits a single panel with a defined fault such as a backlight or touch layer. New old stock or a refurbished exact reference preserves the project without engineering work, subject to sourcing evidence. Migration to a current model removes the obsolescence but requires project reengineering and often a cutout or port change.

Enlarged system diagram

×

The same evidence supports all four routes, and each route consumes a different part of it. Choose by evidence, not by preference alone.

Each route needs different evidence, which is why you state which route you prefer and why. A migration question without the project file and a port inventory cannot be answered. A spare purchase question mainly needs the exact reference and the quantity in service. Pick the route that matches your evidence, not the one that sounds best.

The routes also differ in where their risk sits. The spare route risks discovering the failure mode too late. The repair route risks a fault outside the component scope. The exact reference route risks sourcing quality, since refurbished units vary. The migration route risks engineering effort that only becomes visible once the project compiles. Name the risk you are accepting, and the review can check whether it is priced in.

One closing limit applies to all four: the evidence bounds the answer, not the outcome. Lifecycle data confirms status, project files confirm rebuild effort, and port inventories confirm interface work. None of them guarantee a price, a delivery time, or a migration without controller side changes. Providers answer open questions faster than implied ones.

Weigh the routes against the remaining life of the machine, because the same evidence supports opposite decisions at different horizons. A line scheduled for rebuild next year does not warrant a migration project. A panel that gates a critical process for years ahead does. Record the planned horizon for the machine as one line in the request.

Enlarged system diagram

×

The horizon is one input line that reweights all four routes. It frames the decision, it does not settle price or delivery.

The horizon interacts with the lifecycle status from the earlier sections. A phase out notice on a machine with a long horizon pushes toward migration or a documented spare strategy. The same notice on a machine at the end of its life pushes toward the cheapest safe route, which is often the exact reference or a repair. Neither answer is wrong, they serve different horizons.

State the horizon in operating terms rather than promises. Expected production years, planned capacity changes, and any known line rebuild date are useful. What the review needs is the shape of the future, not a commitment, and a one line note gives it that shape.

The closing limit belongs to the whole guide: status, evidence, inventory, and horizon together frame the decision, and none of them settle it. Price, availability, and migration effort stay provider checks. Send the frame with the evidence, and the answers come back fitted to your machine instead of to a generic case.

• Check lifecycle status against the exact order number, never the family name.
• Capture the project, tool version, and screen photos while the panel still runs.
• Count the installed base, including spares and donor machines.
• Compare spares, repair, exact reference sourcing, and migration by their evidence needs.

• the display and operator interface hub
• the replacement constraints to compare
• which files to preserve first