AI Hints
Home›MLOps Tutorial›Case Studies
MLOps · Lesson 51 of 80

Case Study: Maintenance

Predicting machine failures.

⏱ 2 min read▶ Video at 2:08:11🎓 Free
Watch this lesson in the MLOps courseWatch on YouTube ↗Full MLOps course

Factories, wind farms, and delivery fleets all run on machines that sometimes fail. If you can predict a failure a few days ahead, you can fix it on your own schedule, instead of during a costly breakdown. This is predictive maintenance. It brings sensors, streams, and the edge into the picture. Let's see what operating it involves.

Case Study: Maintenance
From the video: Case Study: Maintenance
  • Sensors stream data
  • Predict failures early
  • Fix on your schedule

From sensor to work order

The flow starts at the machine. Sensors measure vibration, temperature, and pressure, many times a second. Data is aggregated nearby, on a small computer at the edge, because sending everything to the cloud is expensive. Summaries flow to the cloud, into a stream, and then to features, such as the average vibration of the last hour. A model estimates the chance of failure, in the coming days. When it crosses a threshold, a work order is created, for the maintenance team. Each hop is a place that needs monitoring.

  1. Sensorsvibration, temperature, pressure
  2. Edge aggregationsummarise near the machine
  3. Cloud features and modelrisk of failure
  4. Work orderaction for the team
Every hop needs monitoring
From sensor to work order
From the video: From sensor to work order

Challenges unique to machines

Machines bring special challenges. Labels are rare, because failures are rare, and each failure is expensive to collect. Sensors drift, and break themselves, so you must tell a failing sensor from a failing machine. Every machine is slightly different, so models may need per machine calibration. Connectivity is unreliable, so the edge must work offline, and catch up later. And the cost of a false alarm, is a technician's trip, so thresholds need business input. Data quality monitoring is as important as model monitoring.

Rare labelsfew failures to learn from
Sensor faultsa broken sensor is not a broken machine
Machine differencescalibrate per machine
Offline edgework without a connection

Edge versus cloud

A key design choice is where to run the model. At the edge, on the machine, answers are instant, the system works offline, and little data travels. But the hardware is small, so models must be compact, and updating thousands of devices is hard. In the cloud, you have unlimited compute, and easy updates, but you pay for data transfer, and you depend on the connection. Many systems split the work. Small models, at the edge, for urgent decisions. Large models, in the cloud, for deeper analysis, and retraining.

PlaceStrengthsLimits
Edgeinstant, offline, little data movedsmall models, hard fleet updates
Cloudbig models, easy updatesdata costs, needs connectivity
Bothurgent at the edge, deep in the cloudmore moving parts

Summary

Wonderful. Predictive maintenance streams sensor data, summarises it at the edge, predicts failures in the cloud, and creates work orders. Expect rare labels, sensor faults, and spotty connectivity. Choose between edge and cloud by latency, bandwidth, and updates. You have now seen the ideas at work. Next, your turn, a capstone project, built end to end.

Key takeaways
  • Sensors, edge, cloud, work orders
  • Rare labels and sensor faults
  • Edge for speed, cloud for depth
Next up: Capstone: Plan — one project, start to finish