Manufacturing & Energy
Predictive maintenance on Vertex AI
A global manufacturer moves from a stalled proof of concept to monitored models in production, catching failures before they stop a line.
- Sector
- Global industrial manufacturing
- Scale
- Multiple plants, thousands of instrumented assets
- Engagement
- AI readiness workshop, implementation and MLOps enablement
- Duration
- Approximately seven months
The challenge
Where this started
Maintenance ran on fixed intervals: components were replaced whether or not they needed it, while unexpected failures still halted production. Sensor telemetry was being collected but was used mainly for post-incident investigation.
A data science team had built a promising failure-prediction notebook a year earlier. It had never reached production because there was no deployment path, no agreed definition of a good prediction, no monitoring, and no answer to who would own it at three in the morning when it misfired.
Our approach
What we did, and why
The decisions that mattered, including the ones that were unglamorous.
- 01
Start with the decision, not the model
We began with the maintenance planners: what warning window is actionable, what does a false alarm cost, and what would make them trust an alert enough to schedule work? Those answers set the evaluation criteria before any modelling resumed.
- 02
Build the feature pipeline first
Telemetry was consolidated into reproducible feature pipelines on Dataflow and BigQuery, so training and serving computed features identically — the mismatch that had quietly undermined the original notebook.
- 03
Evaluate against agreed thresholds
A held-out set of historical failures became the evaluation harness. Precision at the agreed warning horizon had to clear a threshold that planners themselves signed off before any release.
- 04
Make deployment routine
Vertex AI Pipelines handled training, evaluation and staged deployment, with a model registry and one-command rollback. Shipping a retrained model became unremarkable rather than a project.
- 05
Monitor drift and close the loop
Feature distributions, prediction rates and realised outcomes are monitored continuously. Confirmed and false alerts feed back into the evaluation set so quality is measured against reality, not the original snapshot.
Architecture
How the pieces fit together
01
Sources
- Machine telemetry
- Maintenance work orders
- Production schedules
02
Ingestion
- Pub/Sub streaming
- Dataflow processing
03
Features
- BigQuery feature tables
- Shared training and serving logic
04
Models
- Vertex AI training
- Model registry
- Staged deployment
05
Operations
- Drift and outcome monitoring
- Alerts into maintenance planning
Technologies
- Vertex AI
- BigQuery
- Dataflow
- Pub/Sub
- Cloud Monitoring
- Terraform
Outcomes
What changed
Described qualitatively. We publish client-specific figures only where the client has approved them.
Unplanned stoppages caught earlier
Failures that previously surfaced as line stoppages are now flagged far enough ahead to be scheduled into planned windows.
Maintenance driven by condition
Fixed-interval replacement gave way to condition-based scheduling, so parts are changed when the evidence supports it.
Retraining became routine
A pipeline that runs on demand replaced the manual, weeks-long path from notebook to production.
Alerts planners act on
Because thresholds were agreed with the people receiving the alerts, predictions are treated as decision input rather than noise.
Owned in-house
The client's engineers run the pipelines, interpret the monitoring and retrain models without us.
This engagement is anonymized and presented as a representative scenario. It reflects the architecture patterns, decisions and trade-offs typical of our work in this area rather than the details of one named client. Identifiable engagement details are published only with written client approval.
Related services
Other engagements
- Enterprise data warehouse migration to BigQuery
Retail
- Document processing automation with generative AI
Financial Services