Obsolescence: planning for the system you cannot buy any more

Control systems are installed with a design life of fifteen to twenty years and frequently run longer. The hardware is robust; what fails first is the commercial support around it.

The characteristic sequence is that the vendor announces a successor, then classifies the installed product as mature, then limits support to fault correction, then ends support, and finally stops supplying spares. Each step is announced in advance and the notice is frequently filed rather than acted on.

Recognising the position you are in

Several indicators together give a reliable picture.

• The vendor's published lifecycle status for the specific product and version.
• Spare part availability and lead time — a lead time that has moved from days to months is a stronger signal than any announcement.
• Whether new modules are still manufactured or only refurbished.
• Operating system dependency: a system requiring a version no longer receiving security updates is unsupportable regardless of the control vendor's position.
• Availability of engineering software licences and whether they run on current hardware.
• The number of engineers, internally and at the vendor, who still know the platform.

The last is the one that gets overlooked. A system can be perfectly supportable in principle and unsupportable in practice because the two people who understood it have retired.

Operational output and efficient use of effort are related measures, but they are not interchangeable. Further details are available at this link.

Security decisions should also be checked against NIST guidance on operational technology security.

The lifecycle stages

Most vendors publish a staged model, and while the terminology varies the substance is consistent: full support, then limited support with no new development, then a period where only spares and fault correction are available, then end of everything.

The practically important question is not which stage the product is in but how long the current stage lasts and what the next transition removes.

Building the case before it is urgent

Control system replacement is expensive, produces no visible improvement in production, and competes with projects that do. It is therefore deferred until something forces it, and the forcing event is usually a failure.

The argument that works is risk expressed in operational terms: how long the plant would be down if a specific module failed and no spare existed, what that costs, and how that probability is changing.

A concrete example carries more weight than a lifecycle chart. If the controller for a critical unit has a single spare, no source of more, and a six-week rebuild option, that is a sentence that gets attention.

Interim measures

Between doing nothing and full replacement there is a range of actions that extend the usable life and buy time.

Strategic spares: buying critical modules while they are still available, including from the secondary market, and testing them on receipt so that a spare is known good rather than assumed.

Isolating the obsolete system behind a firewall so that an unpatchable operating system is not the site's exposure.

Migrating peripheral functions — historian, reporting, engineering workstations — to current platforms while leaving the control layer in place.

Documenting the configuration thoroughly, so that a replacement project has a specification and does not depend on reverse engineering.

Phased replacement

Full replacement in one outage is the highest-risk option and sometimes the only practical one where the architecture is monolithic.

Where the system is divided into units that can be migrated independently, phasing spreads cost and risk and allows lessons from the first unit to improve the rest. It also produces a period of running two systems in parallel, with the integration and operator burden that implies.

Plan the data

Replacement projects concentrate on the control layer. The historical data, the alarm rationalisation records, the graphics and the documentation are separate assets that need explicit treatment.

A migration that delivers a working control system and loses fifteen years of history has succeeded technically and destroyed something irreplaceable.

Keep the lifecycle position visible

The practical governance measure is a short annual review: current lifecycle status for each major component, spare holdings against critical items, lead times, and the year in which each becomes unsupportable.

One page, reviewed by someone with a budget. Most sites discover their position during an outage instead.

The skills dimension

A system remains supportable only while people who understand it are available, and that population shrinks faster than the hardware fails.

The measures available are ordinary: documenting configuration and reasoning thoroughly, ensuring more than one person can work on each system, and recording the informal knowledge before the individuals holding it leave.

This is frequently the binding constraint rather than parts availability, and it is the one least visible in a lifecycle assessment based on vendor announcements.

Making the replacement case in operational terms

Obsolescence cases presented as technical arguments compete poorly against projects with production benefits. Presented as availability risk, they compete better.

The framing that works states the exposure concretely: the number of days production would be lost given a specific failure, the probability of that failure over the planning horizon, and how both change if the replacement is deferred another two years.

Not everything has to move at once

Obsolescence rarely affects the whole system uniformly. Operator stations and servers age faster than controllers; network equipment faster than field devices.

Addressing the layers on their own cycles, rather than treating the system as a single unit with a single replacement date, spreads cost and frequently extends the usable life of the parts that are still sound.

Virtualisation as a life-extension measure

Where the constraint is server hardware rather than the control software, virtualising the affected servers can extend usable life considerably: the application continues to run on its validated operating system while the underlying hardware is modern and supportable.

The considerations are vendor support for virtualised deployment, which varies, and the additional dependency on the virtualisation platform itself.

It does not address software obsolescence and it addresses a common practical constraint, which makes it worth assessing before concluding that replacement is the only option.

Watching the supply chain, not just the vendor

A control platform can remain supported while a critical component within it becomes unobtainable, because the component's own manufacturer discontinued it.

Power supplies, communication modules and specialist interface cards frequently come from third parties, and their lifecycle is not announced through the control vendor.

Identifying which parts of the system depend on third-party components, and tracking those separately, closes a gap that a vendor lifecycle statement does not cover.