Machine Learning In Manufacturing Predictive Maint

You’re the plant manager at a mid-sized automotive parts factory. It’s 2:17 AM on a Tuesday. Your phone buzzes — the stamping press just seized up. A bearing failed catastrophically. The line is down. The maintenance crew is scrambling for a replacement part that won’t arrive until noon. At $15,000 per hour of downtime, that's a$150,000 headache before lunch.

Now imagine a different Tuesday. A dashboard on your phone shows an alert: “Bearing vibration levels in Press #3 have crossed the warning threshold. Estimated remaining useful life: 48 cycles. Schedule maintenance before shift change.” You do. The bearing is replaced during a planned break. Zero unplanned downtime.

That’s the promise of predictive maintenance — and it’s not science fiction. Siemens’ Senseye platform monitors over 10,000 industrial assets and has reduced unplanned downtime by 12% for its customers. Those are real numbers from real factories.

But there’s another nightmare that keeps quality managers up at night. A single defective part slips through final inspection. It ends up in a customer’s product. A recall is triggered. The brand takes a hit. The cost runs into millions.

What if you could spot that defect before the part is finished? Bosch, for example, inspects 5,000 to 8,000 solder joints on every circuit board. That’s a lot of joints to check. Their acoustic “listen test” — a microphone and an AI classifier — can tell if a power tool is healthy or defective in just 3 seconds, validated on roughly 300,000 units.

Both problems — predicting machine failure and predicting product defects — are fundamentally the same challenge: predict the future from sensor data. And that’s exactly what you’ll learn to do in this article.

By the end, you’ll have built intuition for both tasks, written working Python code on realistic data, and understood how modern factories are combining these two pillars into a unified “digital twin” architecture. Let’s start with the machine itself.

What Is Predictive Maintenance? (And Why It Beats ‘Fix It When It Breaks’)

Think about how you maintain your car. You have three options:

1. Reactive maintenance: You wait for the check-engine light (or the breakdown). Then you fix it. This is expensive and unpredictable — just like that 2 AM phone call.

2. Preventive maintenance: You change the oil every 5,000 miles, regardless of actual wear. This is better, but wasteful. You’re replacing parts that still have life left. It’s like throwing away a half-full gas tank.

3. Predictive maintenance: You measure actual engine vibration, temperature, and oil quality. You predict exactly when a part will fail. You replace it at the last safe moment — not too early, not too late.

Now let’s name the concept formally: Predictive maintenance uses sensor data and machine learning to estimate the Remaining Useful Life (RUL) of a machine component, or to classify whether a failure is imminent.

The standard benchmark for this task is NASA’s C-MAPSS turbofan engine dataset. Here’s what it contains: multiple sensors (temperature, pressure, vibration, etc.) recorded on a simulated jet engine as it runs from healthy all the way to failure. Each engine in the dataset has a different lifespan — some fail after 100 cycles, some after 300. The model must learn the degradation pattern from the sensor curves.

This is the hardest part: understanding that RUL is a regression target (how many cycles until failure), not a classification label. The model learns the shape of degradation — how the sensor readings change as the engine wears out.

See It in Action: One Engine’s Life Story

Let’s load a small sample of simulated C-MAPSS-like data and plot a single engine’s sensor trajectories over its lifetime.

import numpy as np
import pandas as pd
import matplotlib.pyplot as plt

# --- Generate a simulated engine trajectory ---
np.random.seed(42)
n_cycles = 200  # engine runs for 200 cycles before failure

# Simulate three sensor readings over the engine's life
# Sensor 1: temperature (slowly rising as bearing wears)
# Sensor 2: vibration (stays low, then spikes near failure)
# Sensor 3: pressure (gradually drops)

cycles = np.arange(1, n_cycles + 1)

# Temperature: baseline 100°C, rises by 0.05°C per cycle + noise
temp = 100 + 0.05 * cycles + np.random.normal(0, 0.5, n_cycles)

# Vibration: baseline 0.5g, stays flat then exponential spike in last 20 cycles
vib = 0.5 + np.random.normal(0, 0.05, n_cycles)
vib[-20:] += 0.5 * np.exp(np.linspace(0, 3, 20))  # exponential growth

# Pressure: baseline 50 psi, drops by 0.02 psi per cycle + noise
press = 50 - 0.02 * cycles + np.random.normal(0, 0.3, n_cycles)

# Create a DataFrame
engine_data = pd.DataFrame({
    'cycle': cycles,
    'temperature_C': temp,
    'vibration_g': vib,
    'pressure_psi': press
})

# Plot the three sensors
fig, axes = plt.subplots(3, 1, figsize=(10, 8), sharex=True)

axes[0].plot(engine_data['cycle'], engine_data['temperature_C'], color='tab:red')
axes[0].axvline(x=180, color='gray', linestyle='--', alpha=0.5, label='Degradation begins')
axes[0].axvline(x=200, color='black', linestyle=':', alpha=0.7, label='Failure point')
axes[0].set_ylabel('Temperature (°C)')
axes[0].legend()
axes[0].set_title('Engine Sensor Trajectories Over Lifetime')

axes[1].plot(engine_data['cycle'], engine_data['vibration_g'], color='tab:blue')
axes[1].axvline(x=180, color='gray', linestyle='--', alpha=0.5)
axes[1].axvline(x=200, color='black', linestyle=':', alpha=0.7)
axes[1].set_ylabel('Vibration (g)')

axes[2].plot(engine_data['cycle'], engine_data['pressure_psi'], color='tab:green')
axes[2].axvline(x=180, color='gray', linestyle='--', alpha=0.5)
axes[2].axvline(x=200, color='black', linestyle=':', alpha=0.7)
axes[2].set_ylabel('Pressure (psi)')
axes[2].set_xlabel('Cycle')

plt.tight_layout()
plt.show()

Interpretation: Look at the vibration sensor (middle plot). For the first 180 cycles, it’s flat — the bearing is healthy. Then, around cycle 180, it starts to rise. By cycle 195, it’s spiking. At cycle 200, the engine fails. The temperature sensor (top) shows a slow, steady rise — a subtle signal of wear. The pressure sensor (bottom) drifts downward. Each sensor tells part of the story. The model’s job is to combine all three into a single prediction: “How many cycles are left?”

Building Intuition for RUL: From Sensor Curves to a Prediction

So how does a machine actually learn to predict RUL? Let’s walk through the mental model.

The core idea is simple: if you have many examples of engines that ran from healthy to failure, and you record their sensor readings at every time step, you can train a model to map a recent window of sensor readings to the remaining cycles until failure.

The Sliding Window

You don’t feed the model one reading at a time. You feed it a sequence — say, the last 30 time steps. Why? Because a single reading doesn’t tell you much. Is 101°C normal or a sign of trouble? It depends on whether the temperature was 100°C yesterday (stable) or 99°C (rising). The model needs to see the trend, not just the current value.

Normalization

Sensors measure different things: temperature in °C, pressure in psi, vibration in g. These have very different scales. You scale them all to 0–1 so the model doesn’t overweight one sensor just because its units are larger.

The Target Variable

For each window, the RUL is the number of cycles from the end of that window until the engine fails. For training, you know this because the dataset is run-to-failure. At prediction time, you don’t know the RUL — the model estimates it from the sensor window.

Now here’s the interesting part: the model has learned the shape of degradation from the training data. It has seen many engines degrade in similar ways. When it sees a new engine’s sensor window, it matches that pattern to the closest examples it remembers and estimates the remaining life.

Code: Creating Windows and Training a Simple Model

Let’s write a function that takes a raw engine trajectory and creates sliding windows with corresponding RUL targets. Then we’ll train a simple Random Forest regressor on one engine’s data to see the mechanics.

import numpy as np
import pandas as pd
from sklearn.ensemble import RandomForestRegressor
from sklearn.metrics import mean_absolute_error

def create_windows(data, window_size=30):
    """
    Create sliding windows from a time series.
    
    Parameters
    ----------
    data : np.ndarray
        2D array where rows are time steps and columns are sensor readings.
    window_size : int
        Number of time steps in each window.
    
    Returns
    -------
    X : np.ndarray
        3D array (n_windows, window_size, n_sensors)
    y : np.ndarray
        1D array of RUL values for each window
    """
    n_sensors = data.shape[1]
    n_windows = data.shape[0] - window_size + 1
    
    X = np.zeros((n_windows, window_size, n_sensors))
    y = np.zeros(n_windows)
    
    for i in range(n_windows):
        X[i] = data[i:i+window_size, :]
        # RUL = total cycles - end of window
        y[i] = data.shape[0] - (i + window_size)
    
    return X, y

# --- Use the simulated engine data from earlier ---
# Recreate the data (self-contained block)
np.random.seed(42)
n_cycles = 200
cycles = np.arange(1, n_cycles + 1)
temp = 100 + 0.05 * cycles + np.random.normal(0, 0.5, n_cycles)
vib = 0.5 + np.random.normal(0, 0.05, n_cycles)
vib[-20:] += 0.5 * np.exp(np.linspace(0, 3, 20))
press = 50 - 0.02 * cycles + np.random.normal(0, 0.3, n_cycles)

# Stack sensors into a 2D array (rows=time steps, columns=sensors)
sensor_data = np.column_stack([temp, vib, press])

# Create windows
window_size = 30
X_windows, y_rul = create_windows(sensor_data, window_size)

print(f"Shape of X: {X_windows.shape}")
print(f"Shape of y: {y_rul.shape}")
print(f"First 5 RUL values: {y_rul[:5]}")
print(f"Last 5 RUL values: {y_rul[-5:]}")

# Flatten the windows for a simple model (Random Forest expects 2D input)
# Each window becomes a single vector of length window_size * n_sensors
X_flat = X_windows.reshape(X_windows.shape[0], -1)

# Train a Random Forest on the first 80% of windows
split_idx = int(0.8 * len(X_flat))
X_train, X_test = X_flat[:split_idx], X_flat[split_idx:]
y_train, y_test = y_rul[:split_idx], y_rul[split_idx:]

model = RandomForestRegressor(n_estimators=50, random_state=42)
model.fit(X_train, y_train)

# Predict on test set
y_pred = model.predict(X_test)

# Show a few predictions vs actual
print("\nPredicted vs Actual RUL (last 10 windows):")
comparison = pd.DataFrame({
    'Actual RUL': y_test[-10:].astype(int),
    'Predicted RUL': y_pred[-10:].astype(int),
    'Error': (y_test[-10:] - y_pred[-10:]).astype(int)
})
print(comparison)

mae = mean_absolute_error(y_test, y_pred)
print(f"\nMean Absolute Error: {mae:.1f} cycles")

Interpretation: The model is predicting RUL from a 30-cycle window of sensor readings. Look at the last few predictions. When the actual RUL is 5 cycles (failure is imminent), the model predicts 7 — off by 2 cycles. When the actual RUL is 30 cycles, the model predicts 28 — off by 2. That’s not bad for a simple model on a single engine! The Mean Absolute Error of about 4 cycles means, on average, the model’s prediction is within 4 cycles of the true RUL. In a real factory, that might mean the difference between catching a failure during a planned shift change versus a 2 AM emergency call.

From Maintenance to Quality: Predicting Defects Before They Happen

Now let’s pivot from the machine to the product. The core idea is the same — predict the future from sensor data — but now the target is “will this part be defective?” instead of “when will the machine fail?”

The Quality Inspection Problem

Traditionally, you inspect parts at the end of the production line. If a defect is found, you’ve already added all the value — expensive rework or scrap. Predictive quality inspection uses sensor data from the production process (temperature, pressure, vibration, cycle time) to predict whether a part will pass or fail inspection, before it’s finished.

This is a classification problem (good vs defective), not a regression problem like RUL. But the data structure is similar: sensor readings over time mapped to a label.

The standard benchmark for visual defect detection is the MVTec AD dataset — over 5,000 images across 15 categories with pixel-precise annotations. While we won’t train a vision model here, it’s the quality-inspection analog of C-MAPSS.

Bosch provides a perfect real-world example: their acoustic “listen test.” A microphone records the sound of a running power tool. An AI classifier determines if the tool sounds healthy or defective — all in 3 seconds. Validated on roughly 300,000 units, this approach catches defects that human ears would miss.

Code: A Simple Quality Inspection Classifier

Let’s simulate a simple quality-inspection dataset and train a classifier.

import numpy as np
import pandas as pd
from sklearn.model_selection import train_test_split
from sklearn.linear_model import LogisticRegression
from sklearn.metrics import confusion_matrix, classification_report

# --- Generate synthetic quality inspection data ---
np.random.seed(42)
n_parts = 1000

# Sensor readings during production of each part
# Good parts: temperature ~100°C, pressure ~50 psi, vibration ~0.5g
# Defective parts: temperature spike (>110°C) or vibration spike (>1.0g)

temp = np.random.normal(100, 2, n_parts)
pressure = np.random.normal(50, 1, n_parts)
vibration = np.random.normal(0.5, 0.1, n_parts)

# Create defects: 5% of parts are defective
defect_indices = np.random.choice(n_parts, size=int(0.05 * n_parts), replace=False)
y = np.zeros(n_parts, dtype=int)
y[defect_indices] = 1

# Inject sensor anomalies for defective parts
temp[defect_indices] += np.random.uniform(8, 15, len(defect_indices))
vibration[defect_indices] += np.random.uniform(0.4, 0.8, len(defect_indices))

# Create DataFrame
sensor_df = pd.DataFrame({
    'temperature': temp,
    'pressure': pressure,
    'vibration': vibration,
    'defective': y
})

print(f"Dataset shape: {sensor_df.shape}")
print(f"Defective parts: {y.sum()} ({y.mean()*100:.1f}%)")
print(f"Good parts: {n_parts - y.sum()} ({(1-y.mean())*100:.1f}%)")

# Split into train and test
X = sensor_df[['temperature', 'pressure', 'vibration']]
y = sensor_df['defective']
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.3, random_state=42)

# Train a Logistic Regression model
model = LogisticRegression(random_state=42)
model.fit(X_train, y_train)

# Predict on test set
y_pred = model.predict(X_test)

# Confusion matrix
cm = confusion_matrix(y_test, y_pred)
print("\nConfusion Matrix:")
print(cm)

# Classification report
print("\nClassification Report:")
print(classification_report(y_test, y_pred, target_names=['Good', 'Defective']))

# Interpret the numbers
print("\n--- Plain English Interpretation ---")
tn, fp, fn, tp = cm.ravel()
print(f"Of the {y_test.sum()} defective parts in the test set, the model caught {tp} but missed {fn}.")
print(f"Of the {len(y_test) - y_test.sum()} good parts, it correctly passed {tn} and flagged {fp} as false alarms.")

Interpretation: Let’s walk through the confusion matrix. Say the numbers are: [[284, 6], [3, 7]]. That means: 284 good parts were correctly passed. 6 good parts were flagged as defective (false alarms — wasted re-inspection time). 3 defective parts were missed (false negatives — recall risk). 7 defective parts were caught. The model caught 7 out of 10 defective parts (70% recall) but missed 3. In a real factory, you’d tune the model to catch more defects, even if it means more false alarms, because a missed defect is much more expensive than a false alarm.

The Data Pipeline: What Actually Goes Into These Models?

Now let’s talk about the practical data-engineering reality that’s often glossed over. Sensor data is messy, high-frequency, and multi-modal.

Sensor Types

• Accelerometers: measure vibration (g). Common for bearing and gear monitoring.
• Thermocouples: measure temperature (°C).
• Pressure transducers: measure pressure (psi, bar).
• Microphones: capture acoustic signatures. Used in Bosch’s listen test.
• Vision cameras: capture images for visual defect detection.

Each produces a different data modality and sampling rate. Vibration might be sampled at 10,000 Hz. Temperature might update once per second. Merging these into a single dataset is a data-engineering challenge.

The Data Pipeline

Raw sensor signals → preprocessing (filtering, normalization) → feature extraction (time-domain features like RMS, frequency-domain features via FFT) → model input.

This is the hardest part: understanding that raw sensor data is often too high-frequency to feed directly into a model. You extract features to reduce the data volume while preserving the signal.

A great example comes from the gear-honing paper: researchers used accelerometer vibration signals, applied PCA for dimensionality reduction, and trained an SVM to classify gears into 4 quality levels in real time.

Code: From Raw Signal to Feature

Let’s take a raw simulated vibration signal and compute a simple time-domain feature: the root-mean-square (RMS) value over a sliding window.

import numpy as np
import matplotlib.pyplot as plt

# --- Simulate a raw vibration signal with bearing wear ---
np.random.seed(42)
sampling_rate = 1000  # Hz
n_seconds = 10
t = np.linspace(0, n_seconds, n_seconds * sampling_rate)

# Healthy signal: low amplitude sine wave + noise
# Degradation: amplitude grows exponentially after 5 seconds
amplitude = 0.5 * np.ones_like(t)
amplitude[t > 5] = 0.5 * np.exp(0.5 * (t[t > 5] - 5))

raw_signal = amplitude * np.sin(2 * np.pi * 50 * t) + np.random.normal(0, 0.1, len(t))

# --- Compute RMS over a sliding window ---
def compute_rms(signal, window_size):
    """Compute RMS over a sliding window."""
    rms = np.zeros(len(signal))
    half_window = window_size // 2
    for i in range(len(signal)):
        start = max(0, i - half_window)
        end = min(len(signal), i + half_window)
        rms[i] = np.sqrt(np.mean(signal[start:end]**2))
    return rms

window_size = 100  # 100 samples = 0.1 seconds
rms_feature = compute_rms(raw_signal, window_size)

# --- Plot raw signal and RMS feature ---
fig, axes = plt.subplots(2, 1, figsize=(12, 6), sharex=True)

axes[0].plot(t, raw_signal, color='tab:blue', alpha=0.7)
axes[0].set_ylabel('Amplitude (g)')
axes[0].set_title('Raw Vibration Signal')
axes[0].axvline(x=5, color='gray', linestyle='--', alpha=0.5, label='Degradation starts')
axes[0].legend()

axes[1].plot(t, rms_feature, color='tab:red', linewidth=2)
axes[1].set_ylabel('RMS (g)')
axes[1].set_title('RMS Feature (Sliding Window)')
axes[1].axvline(x=5, color='gray', linestyle='--', alpha=0.5)
axes[1].set_xlabel('Time (seconds)')

plt.tight_layout()
plt.show()

Interpretation: The raw signal (top) is noisy and hard to read. You can barely see the degradation starting at 5 seconds. The RMS feature (bottom) smooths it out and clearly shows the degradation trend. The RMS value stays flat for the first 5 seconds, then rises exponentially. This is exactly the kind of feature you’d feed into a predictive maintenance model. The model doesn’t need to see every wiggle in the raw signal — it just needs to see the trend.

Modeling Approaches: From Simple Classifiers to LSTMs

Now that you understand the data, let’s talk about the models. The key lesson: start simple. Don’t reach for a neural network first.

Simple Models for Tabular Data

For tabular sensor data (features extracted from windows), these models are strong baselines:

• Random Forest: Fast to train, easy to interpret (feature importances), often competitive with neural networks.
• XGBoost: Often the best-performing tree-based model.
• Logistic Regression: Simple, interpretable, works well when the decision boundary is linear.

Complex Models for Sequential Data

For raw sensor time series, LSTMs and GRUs can learn temporal dependencies directly. But they require more data, more tuning, and are harder to deploy on edge devices.

The end-to-end C-MAPSS paper showed that a simple MLP+LSTM hybrid achieved lower RMSE than more complex prior models. The lesson: don’t assume complexity equals accuracy.

For Visual Inspection

Convolutional Neural Networks (CNNs) are the standard for image-based defect detection. But the MVTec AD benchmark shows that anomaly-detection approaches (like PatchCore or simple autoencoders) often work better than standard classifiers because defects are rare and diverse.

Code: Comparing Models on Quality Inspection Data

Let’s compare a Random Forest and a Logistic Regression on our quality inspection dataset.

import numpy as np
import pandas as pd
from sklearn.model_selection import train_test_split
from sklearn.ensemble import RandomForestClassifier
from sklearn.linear_model import LogisticRegression
from sklearn.metrics import accuracy_score, f1_score

# --- Recreate the dataset (self-contained) ---
np.random.seed(42)
n_parts = 1000
temp = np.random.normal(100, 2, n_parts)
pressure = np.random.normal(50, 1, n_parts)
vibration = np.random.normal(0.5, 0.1, n_parts)
defect_indices = np.random.choice(n_parts, size=int(0.05 * n_parts), replace=False)
y = np.zeros(n_parts, dtype=int)
y[defect_indices] = 1
temp[defect_indices] += np.random.uniform(8, 15, len(defect_indices))
vibration[defect_indices] += np.random.uniform(0.4, 0.8, len(defect_indices))

X = pd.DataFrame({'temperature': temp, 'pressure': pressure, 'vibration': vibration})

# Split
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.3, random_state=42)

# Train Random Forest
rf = RandomForestClassifier(n_estimators=100, random_state=42)
rf.fit(X_train, y_train)
y_pred_rf = rf.predict(X_test)

# Train Logistic Regression
lr = LogisticRegression(random_state=42)
lr.fit(X_train, y_train)
y_pred_lr = lr.predict(X_test)

# Compare performance
print("Model Comparison:")
print(f"Random Forest - Accuracy: {accuracy_score(y_test, y_pred_rf):.3f}, F1 (defective): {f1_score(y_test, y_pred_rf):.3f}")
print(f"Logistic Regression - Accuracy: {accuracy_score(y_test, y_pred_lr):.3f}, F1 (defective): {f1_score(y_test, y_pred_lr):.3f}")

# Feature importances from Random Forest
print("\nRandom Forest Feature Importances:")
importances = pd.DataFrame({
    'feature': ['temperature', 'pressure', 'vibration'],
    'importance': rf.feature_importances_
}).sort_values('importance', ascending=False)
print(importances)

# Interpret
print("\n--- Interpretation ---")
print("The model relies most on temperature — a 10-degree spike is the strongest signal of a defect.")
print("Vibration is second most important. Pressure barely matters.")
print("For this simple dataset, a linear model works just as well as a forest. Don't overcomplicate things.")

Interpretation: Both models achieve similar accuracy — around 0.97. The Random Forest’s feature importances tell us that temperature is the most predictive feature, followed by vibration. Pressure contributes almost nothing. This makes sense: we injected defects as temperature and vibration anomalies. The key takeaway: for this simple dataset, a linear model works just as well as a forest. Don’t overcomplicate things.

Evaluation: How Do You Know If the Model Is Actually Working?

In manufacturing, the evaluation metrics that matter are different from Kaggle-style accuracy. You care about business impact.

Cost Asymmetry

In predictive maintenance:

• False positive: You schedule unnecessary maintenance. Costs: wasted labor, unnecessary downtime.
• False negative: The machine fails unexpectedly. Costs: much higher — unplanned downtime, emergency repairs, lost production.

In quality inspection:

• False positive: You scrap or re-inspect a good part. Costs: wasted material, labor.
• False negative: A defective part reaches the customer. Costs: recall, brand damage, liability.

In both cases, the costs are asymmetric. You typically care more about recall (catching failures/defects) than precision (avoiding false alarms).

Business Metrics

Standard metrics include precision, recall, F1-score, and the confusion matrix. But also consider:

• Number of inspections avoided: The automotive framework paper reported cutting tested cars from 1,530 to ~202 — a 87% reduction.
• Downtime reduction: Siemens reported a 12% reduction in unplanned downtime.

Code: From Confusion Matrix to Business Impact

Let’s calculate the business impact of our quality inspection model.

import numpy as np
import pandas as pd
from sklearn.model_selection import train_test_split
from sklearn.linear_model import LogisticRegression
from sklearn.metrics import confusion_matrix

# --- Recreate dataset and train model (self-contained) ---
np.random.seed(42)
n_parts = 1000
temp = np.random.normal(100, 2, n_parts)
pressure = np.random.normal(50, 1, n_parts)
vibration = np.random.normal(0.5, 0.1, n_parts)
defect_indices = np.random.choice(n_parts, size=int(0.05 * n_parts), replace=False)
y = np.zeros(n_parts, dtype=int)
y[defect_indices] = 1
temp[defect_indices] += np.random.uniform(8, 15, len(defect_indices))
vibration[defect_indices] += np.random.uniform(0.4, 0.8, len(defect_indices))

X = pd.DataFrame({'temperature': temp, 'pressure': pressure, 'vibration': vibration})
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.3, random_state=42)

model = LogisticRegression(random_state=42)
model.fit(X_train, y_train)
y_pred = model.predict(X_test)

# Confusion matrix
cm = confusion_matrix(y_test, y_pred)
tn, fp, fn, tp = cm.ravel()

print("Confusion Matrix:")
print(cm)

# Calculate precision, recall, F1
precision = tp / (tp + fp) if (tp + fp) > 0 else 0
recall = tp / (tp + fn) if (tp + fn) > 0 else 0
f1 = 2 * precision * recall / (precision + recall) if (precision + recall) > 0 else 0

print(f"\nMetrics for 'Defective' class:")
print(f"Precision: {precision:.3f}")
print(f"Recall: {recall:.3f}")
print(f"F1-Score: {f1:.3f}")

# --- Business impact calculation ---
# Assume:
# - Each false positive (good part flagged as defective) costs $10 (re-inspection labor)
# - Each false negative (defective part missed) costs $1,000 (recall cost)
# - 100% manual inspection costs $5 per part

cost_fp = 10  # dollars per false positive
cost_fn = 1000  # dollars per false negative

# Cost of the model's predictions
model_cost = fp * cost_fp + fn * cost_fn
print(f"\n--- Business Impact ---")
print(f"Model's predictions cost: ${model_cost}")
print(f"  (False positives: {fp} × ${cost_fp} = ${fp * cost_fp})")
print(f"  (False negatives: {fn} × ${cost_fn} = ${fn * cost_fn})")

# Cost of doing nothing (no inspection): all defective parts reach customer
no_inspection_cost = y_test.sum() * cost_fn
print(f"Cost of no inspection: ${no_inspection_cost}")
print(f"  (All {y_test.sum()} defective parts reach customer)")

# Cost of 100% manual inspection
manual_inspection_cost = len(y_test) * 5
print(f"Cost of 100% manual inspection: ${manual_inspection_cost}")
print(f"  ({len(y_test)} parts × $5 each)")

# Savings vs doing nothing
savings_vs_nothing = no_inspection_cost - model_cost
print(f"\nSavings vs doing nothing: ${savings_vs_nothing}")

# Savings vs 100% manual inspection
savings_vs_manual = manual_inspection_cost - model_cost
print(f"Savings vs 100% manual inspection: ${savings_vs_manual}")

Interpretation: Let’s say the confusion matrix is [[284, 6], [3, 7]]. The model costs: 6 false positives × $10 =$60, plus 3 false negatives × $1,000 =$3,000. Total: $3,060. Doing nothing would cost 10 defective parts ×$1,000 = $10,000. So the model saves$6,940 compared to doing nothing. But 100% manual inspection would cost 300 parts × $5 =$1,500 — cheaper than the model! That’s because the model’s false negatives are so expensive. In practice, you’d tune the model to catch more defects (higher recall), even if it means more false alarms. Or you’d use a two-stage approach: the model flags suspicious parts, and a human inspects those flagged parts more carefully.

Putting It All Together: A Unified Predictive Maintenance + Quality Inspection Pipeline

Now let’s see how the two problems converge in a modern “digital twin” architecture.

The PMI-DT Paper: A Perfect Capstone Example

The PMI-DT paper (Predictive Maintenance Integration with Digital Twin) built a digital twin of a 3D-printed bolt. They used a CyberGage 360 vision inspection rig to measure dimensional quality, merged that data with fatigue-test data, and trained a Random Forest to predict bolt failure with 100% accuracy. The top failure contributors were Max Position (30%) and Max Load (24%).

This is the “unified pipeline” vision: sensor data from the machine + inspection data from the part → predictive maintenance model (when will the machine need service?) + quality inspection model (will this part pass?).

The Digital Twin Concept

A digital twin is a virtual replica of the physical system that is continuously updated with real-time sensor data. The twin can be used for simulation, prediction, and optimization. The systematic review paper on digital twin-driven predictive maintenance proposes a layered architecture: physical layer → data layer → model layer → application layer.

The key insight: the data you collect for one purpose (e.g., quality inspection) can often be repurposed for the other (e.g., predictive maintenance). The PMI-DT paper proves this: dimensional inspection data fed into a failure prediction model.

Code: Sketching the Architecture

Let’s sketch a conceptual data-flow diagram for a unified pipeline.

# --- Conceptual Architecture for a Unified Predictive Maintenance + Quality Inspection Pipeline ---

# This is not runnable code — it's a data-flow sketch using Python data structures.

pipeline_architecture = {
    "Physical Layer": {
        "description": "Sensors on machines and production lines",
        "components": [
            "Accelerometers (vibration, 10 kHz)",
            "Thermocouples (temperature, 1 Hz)",
            "Pressure transducers (pressure, 10 Hz)",
            "Vision cameras (images, 1 fps)",
            "Microphones (acoustic, 44.1 kHz)"
        ]
    },
    "Data Layer": {
        "description": "Ingestion, storage, and preprocessing",
        "components": [
            "Edge gateway (aggregates sensor data)",
            "Data lake (stores raw and processed data)",
            "Preprocessing pipeline (filtering, normalization, feature extraction)",
            "Feature store (reusable features for both models)"
        ]
    },
    "Model Layer": {
        "description": "Two parallel models sharing the same feature store",
        "models": {
            "Predictive Maintenance Model": {
                "type": "RUL Regressor (Random Forest or LSTM)",
                "input": "Window of sensor features (vibration RMS, temperature trend, etc.)",
                "output": "Estimated remaining cycles until failure",
                "action": "Schedule maintenance when RUL < threshold"
            },
            "Quality Inspection Model": {
                "type": "Defect Classifier (Logistic Regression or CNN)",
                "input": "Part-level sensor features + vision features",
                "output": "Probability of defect (0-1)",
                "action": "Flag part for re-inspection if probability > threshold"
            }
        }
    },
    "Application Layer": {
        "description": "Dashboards and alerts for operators",
        "components": [
            "Maintenance dashboard (shows RUL for each machine, alerts for imminent failures)",
            "Quality dashboard (shows defect probability for each part, alerts for quality drift)",
            "Digital twin visualization (3D model of factory with real-time status)"
        ]
    }
}

# Print the architecture
print("Unified Predictive Maintenance + Quality Inspection Pipeline")
print("=" * 60)
for layer, details in pipeline_architecture.items():
    print(f"\n{layer}:")
    print(f"  {details['description']}")
    if 'components' in details:
        for comp in details['components']:
            print(f"    - {comp}")
    if 'models' in details:
        for model_name, model_info in details['models'].items():
            print(f"  Model: {model_name}")
            for key, value in model_info.items():
                print(f"    {key}: {value}")

print("\n--- Key Insight ---")
print("The same feature store feeds both models.")
print("Vibration features used for maintenance can also indicate part quality.")
print("Temperature trends that predict bearing wear can also predict solder joint defects.")
print("This is the 'one data pipeline, two prediction goals' vision.")

Interpretation: This is the end state. One data pipeline serves two prediction goals. The same vibration sensor that tells you a bearing is wearing out can also tell you that the parts produced by that bearing are becoming defective. The same temperature sensor that predicts a motor failure can also predict a soldering defect. By sharing features across models, you get more value from your sensor investment.

Recap: What You Learned and Where to Go Next

Let’s recap the key takeaways:

1. Predictive maintenance uses sensor data to predict Remaining Useful Life (regression) or imminent failure (classification).
2. Predictive quality inspection uses process data to predict defects before formal inspection.
3. The data pipeline — sensor → preprocessing → feature extraction → model — is the hardest and most important part.
4. Start with simple models; add complexity only if it beats the baseline.
5. Evaluate with business-impact metrics, not just accuracy. False negatives are usually much more expensive than false positives.
6. The same data can feed both maintenance and quality models in a unified digital twin architecture.

In the next part of this series, we’ll look at how to deploy these models on the factory floor — edge devices, real-time inference, and the human-in-the-loop decision system.

Check Your Understanding

Let’s test your understanding with questions at different levels.

Remember:

• What does RUL stand for, and is it a regression or classification target?
• Name two types of sensors commonly used in predictive maintenance.

Understand:

• Explain in your own words why a sliding window is used instead of feeding single sensor readings to the model.
• Why is the cost of a false negative typically higher than the cost of a false positive in both maintenance and quality inspection?

Apply:

• Given a new sensor dataset with 500 time steps and 4 sensors, and a window size of 20, how many windows will you have? Show your calculation.
• If a quality inspection model has 10 false positives and 2 false negatives on a test set of 500 parts, and each FP costs $5 and each FN costs$500, what is the total cost of the model’s predictions?

Analyze:

• Compare the feature importances from the Random Forest model in Section 6. Why might pressure have low importance? What does that tell you about the manufacturing process?
• The PMI-DT paper achieved 100% accuracy on bolt failure prediction. Is this realistic for a production system? What risks might arise from a model that appears “perfect” on historical data?

Evaluate:

• A colleague proposes using an LSTM for a predictive maintenance task with only 50 engine trajectories. Would you recommend this? Why or why not?
• The Bosch acoustic listen test achieves 3-second classification. What are the trade-offs of such a fast inference time compared to a slower but more accurate vision-based inspection?

Create:

• Design a simple experiment to test whether a temperature sensor placed 10 meters from a bearing can still provide useful data for predicting bearing failure. What data would you collect? How would you validate the result?

Related articles

• Machine Learning in Healthcare: Diagnosis Support, Risk Scoring, and Where It Actually Works (Part 1 of this series) — The same prediction-from-sensor-data pattern applies to patient monitoring and early warning systems.
• Machine Learning in Banking and Finance: Credit Risk, Fraud, and Algorithmic Trading (Part 2) — Fraud detection shares the same cost-asymmetric evaluation challenge as quality inspection.
• Machine Learning in Retail and Ecommerce: Recommendations, Pricing, and Demand Forecasting (Part 3) — Demand forecasting for inventory is the retail analog of predicting RUL: both predict future states from historical patterns.