How Manchester Airport is moving from reactive repairs to predictive maintenance using sensor data and cleaner fault coding

Engineers from the scanner manufacturer were on-site at Manchester Airport earlier this year, called in after vibration data flagged a design fault on a batch of newly installed CTX scanners. Nothing had broken yet, and the machines were still running, but the data had caught the issue before it became a problem. This is the point of predictive maintenance, says Linda McGuigan, Terminals Asset Lifecycle Manager at MAG Airports. Her own background is in mechanical engineering rather than data science.

“The main aim for us was to move away from reactive maintenance to something more evidence-based,” she says. “The other element, from an asset lifecycle point of view, is the CapEx piece: really understanding the data-driven decisions of when we need to spend money, and why. That helps us upgrade our infrastructure.”

That shift paid off during Manchester’s recent terminal transformation project, when one of the baggage lines was due to be replaced. The wider project had run late because of COVID-19, so McGuigan’s team delayed the changeover. “We knew we could get away with operating the older system for a little bit longer, because the data told us the system was OK,” she says. “We knew we needed to change it, but we had the data to tell us when.”

She compares it to a car. “You’re told to change your cambelt at whatever mileage the manufacturer says, but often the belt is perfectly fine and could last a lot longer. If you were able to measure it in increments, instead of just changing it on schedule, you’d get more life out of it. Or the other way round: you’d know it was thinning faster than expected, and could change it out before it failed and damaged the valves as well.” Baggage systems, she says, work on the same principle, just with far more moving parts.

Reading the signs in vibration, temperature and heat

Manchester collects four main types of condition data: vibration, temperature, pressure and acoustic monitoring, each suited to a different kind of asset. Vibration tends to go on rotating equipment, picked up through triaxial sensors fitted around bearings, and it was vibration data that flagged the fault on the CTX scanners. Those machines were installed recently under the airport’s Funding Structure Reform programme, and are already showing a higher failure rate than expected. “By monitoring that vibration, we found an early-life design flaw,” McGuigan says. “That’s meant we’ve been able to get the manufacturer in to investigate,

Reading that data properly takes training: Manchester’s own reliability engineers are trained to interpret the readouts, and manufacturers help too, resetting the baseline after their own maintenance visits. Her advice to anyone starting out is to resist collecting everything at once. “It’s good to start small, one sensor at a time,” she says, “but to get a true picture, you need multiple sensors and multiple datasets to build the full profile.”

Temperature sensors do a different job, nowhere more usefully than on Manchester’s Skylink, the enclosed walkway connecting the terminals, which houses several long travelators. “Those links are like glass tubes, and they get very hot and very cold,” McGuigan says, adding, with a laugh, that people might not believe it, but Manchester does get proper hot weather. The oil gauge on the travelator gearboxes had been set on the assumption it would not exceed 50°C, but in the height of summer, inside a glass tube, it did. “We decided to leave the monitors on there permanently,” she says.

Passenger flow has changed the picture too. Since the transformation project, every airline except Ryanair operates out of Terminal 2, while Terminal 3 carries Ryanair alone, and lifts and escalators built for one pattern of use are working a different one now. “We’ve got two large escalators where we were seeing a lot of early-life failures,” McGuigan says, “and the temperature profile was key to working out why.” The team adjusted the oil viscosity, and on the highest-use, worst-ventilated units they have gone further still, fitting dipped probes through a plug to get the actual oil temperature rather than the less accurate external pit reading. A sensor, fitted and installed, costs around £1,500.

Wiring it into the workflow

Sensors and dashboards get an airport only so far. Manchester’s asset data feeds into Maximo, its maintenance management system, and McGuigan is pushing for more work orders to generate automatically. But automation on its own creates a different problem: alert fatigue. “You don’t want a work order raised for something that doesn’t actually need one,” she says.

Her lifts, for example, flag when they have run more times than expected, which on its own is not worth a callout. Working with the planning and scheduling team, McGuigan agreed that only a second, repeated alert should get escalated to an engineer. The thresholds are not uniform across the estate. “For my temperature ranges, I want to know when something’s hitting near 50°C,” she says, “but for escalator gearbox temperatures, I don’t want it anywhere near 50°C because that’s when the oil viscosity starts to become a problem.”

Clean data, and engineers who trust it

The least glamorous part of the job is also, McGuigan suggests, the most important: getting the underlying data clean. Manchester is around 18 months into what is expected to be a three-year programme to standardise the problem-cause-remedy codes engineers log against every job in Maximo. “What one person called a fault wasn’t what another person called the same fault,” she says. “It made the data really difficult to calibrate.” The programme has since expanded across the whole of MAG Group, taking in Stansted and East Midlands, whose asset profiles look nothing like Manchester’s own.

Her advice for airports starting from scratch comes back to sequencing. Start with the assets where failure hurts most, not the ones easiest to sensor. Manchester began with its baggage system, because a failure there can hold up flights directly, and because it meant parts and labour could be lined up in advance instead of dealt with on the spot. Build on whatever computerised maintenance management system and workflows already exist rather than starting a parallel system. And treat the roll-out as a change-management exercise as much as a technical one: bring engineers in early, or predictive maintenance can feel like something being done to them rather than for them.

On the lifts, outputs started out as advisory only: a flag triggers an engineer to check and report back, and only once the pattern held, and engineers trusted it, did it become automatic. Operational teams need to be brought in early too, clear about exactly what data they want to see: when Manchester cleansed its own data, it broke reports other teams were quietly relying on. Pilot before going live, McGuigan says, because a data programme rarely stays contained to the system it started in. Manchester piloted its cleansing work on the baggage system first, where the broken reports turned up, and fixed them before the changes went into full production. “You need the feedback loop,” she says. “You need to calibrate, and then build on it as you go.”

That discipline is visible right now in the CTX scanner fault the vibration sensors caught before it became a failure: a small, unglamorous catch, but exactly the kind a predictive maintenance ecosystem is built to make. Manchester’s system is not finished, and neither is MAG Group’s wider fault-code programme. Both are still being built, one sensor and one standardised code at a time.