Skip to content
Jonny Wilson

Replacing a Legacy Turbine HMI

Published on

4 min read

Engineering notes from replacing a legacy turbine HMI while preserving serial communications, alarm handling, historian exports and familiar operator behaviour.

  • Jonny Wilson profile photograph

    Design Engineer · EngTech TMIET

    Electrical and control systems design engineer writing about practical engineering, industrial automation and OT cyber security.

One of the first industrial control projects I worked on involved a legacy turbine monitoring system connected to standby gas turbines at an industrial generation site.

At first glance, it looked deceptively simple: industrial PCs, serial links, old SCADA software, alarm printers and fibre converters. Underneath it sat a system that people still depended on. That changes everything.

Some details have been simplified or generalised to avoid disclosing sensitive project information.

The starting point

The existing arrangement used a single HMI/SCADA machine to monitor multiple turbine controller units. The controllers were still operational. The concern was the ageing supervisory layer around them: obsolete hardware, an unsupported operating system, fragile communications and the risk created by one workstation becoming a dependency for the whole monitoring function.

The system had not failed. The engineering problem was that eventually it would become difficult or impossible to support safely.

Industrial systems are often retained far longer than originally expected because replacing an operational system is difficult, disruptive and risky. The existing installation also had years of operational familiarity built into it:

  • operators knew the screens and navigation;
  • maintenance teams understood the alarm behaviour;
  • alarm and report printers formed part of operating routines;
  • historian exports fed other established processes;
  • startup and fault-finding behaviour was familiar.

In this setting, familiar behaviour was not merely a preference. It was part of the operational requirement.

What made the replacement difficult

Replacing the computer and reinstalling the software would not address the whole system. The replacement still had to preserve or deliberately change assumptions accumulated over years:

  • serial communications had to remain dependable;
  • legacy SCADA software had to behave predictably;
  • alarm handling and navigation had to remain understandable;
  • historical data exports had to continue;
  • printer outputs still mattered to operators.

The work therefore became less about redesigning the interface and more about preserving required behaviour while reducing obsolescence and single-point dependency.

The engineering approach

The replacement moved away from one supervisory machine and split monitoring across multiple systems. Each turbine controller could be associated with its own dedicated supervisory environment, reducing reliance on a single workstation and making faults easier to isolate.

The architecture still depended on practical industrial interfaces:

  • serial communications and fibre converters;
  • Modbus-style protocols;
  • historian exports;
  • alarm and report printers;
  • existing controller interfaces.

Legacy software was retained within a controlled virtualised environment on supportable industrial hardware. That created a boundary between the application and the modern host, but it did not remove the need to manage licences, backups, time synchronisation, hardware interfaces, cyber security and long-term recovery.

Testing and acceptance

The replacement could not be powered on and declared complete. It had to be checked against the behaviours on which operators and connected systems relied:

  • controller communications;
  • alarm generation, acknowledgement and display;
  • historical logging and historian exports;
  • startup and recovery sequences;
  • printer outputs;
  • response times and navigation;
  • long-duration stability.

Soak testing was especially important. A system may work on a bench for ten minutes and still fail after days through timing drift, logging problems, resource exhaustion or an unusual sequence of events. The distinction is between showing that something can work and gathering evidence that it is suitable for service.

What I learned

This project changed how I think about engineering because it brought together operational dependency, obsolescence, maintainability, human factors, backwards compatibility, controlled change and operational trust.

A great deal of brownfield engineering is not about building something new. It is about making careful, testable changes to systems people already rely on, without losing the behaviour that matters.

Related resources