Developing AI Predictive Maintenance Systems for Equipment

Picture this: a plant with thousands of electric motors, pumps, and compressors. One sudden failure — and the conveyor stops for 4 hours. Losses up to 2 million rubles per stoppage. Most enterprises follow a replacement schedule of "every 1000 operating hours" while the actual condition of the units remains a mystery until the last moment. We build an AI predictive maintenance (PdM) system that removes uncertainty.

We use data from vibration, current, and temperature sensors. We train models to detect incipient defects 2-6 weeks before failure. We connect to CMMS so that work orders are created automatically. The customer receives a Health Index for each asset, maintenance timing recommendations, and transparent ROI. Our experience: 5+ years in industrial AI, dozens of deployed systems. PdM reduces unplanned downtime 3-5 times compared to scheduled maintenance.

What Problems Does the AI Predictive Maintenance System Solve?

• Unexpected downtime: traditional maintenance is schedule-based or after failure. We predict remaining useful life (RUL) and set precise maintenance dates.
• Suboptimal maintenance frequency: too often — waste; too rare — risk. We optimize based on FMEA and an economic model.
• False alarms: standard threshold methods give 30-60% false positives. Our ML ensemble reduces FP to 5%.

How We Build the System: Platform Architecture

The system covers all levels from sensors to business KPIs:

Level 0: Edge (on equipment)
    Modules: vibration sensor, temperature sensor, current meter
    Protocol: Modbus RTU / OPC-UA
    Edge gateway: Raspberry Pi / Industrial PC

Level 1: Fog (workshop level)
    OPC-UA Server → MQTT broker → Edge computing node
    Local storage and initial processing

Level 2: Cloud (enterprise level)
    Kafka → TimescaleDB / InfluxDB
    ML Training Pipeline (Airflow + MLflow)
    Inference Service (FastAPI)

Level 3: Business
    CMMS / ERP integration
    KPI Dashboard (Grafana / Tableau)
    Mobile app for technicians

For each asset we create a record in the Asset Registry:

@dataclass
class Asset:
    asset_id: str
    name: str
    type: AssetType  # motor, pump, compressor, conveyor, gearbox
    manufacturer: str
    model: str
    install_date: datetime
    rated_power_kw: float
    location: dict  # plant, line, cell
    criticality: int  # 1-5 (5 = most critical)
    sensors: list[SensorConfig]
    maintenance_history: list[WorkOrder]
    failure_modes: list[FailureMode]  # from FMEA document

FMEA-Driven Failure Analysis: The Prediction Foundation

Instead of a black box, we use FMEA — we document each expected failure, its indicators, and typical development time. Example for an electric motor:

failure_modes_motor = [
    FailureMode(
        name='bearing_outer_race_defect',
        detection_method='vibration_envelope_bpfo',
        leading_indicators=['kurtosis > 3', 'bpfo_amplitude_rise'],
        typical_development_days=30,
        severity=4
    ),
    FailureMode(
        name='stator_winding_degradation',
        detection_method='motor_current_signature_mcsa',
        leading_indicators=['current_imbalance > 5%', 'sideband_frequencies'],
        typical_development_days=60,
        severity=5
    ),
    FailureMode(
        name='misalignment',
        detection_method='vibration_1x_2x',
        leading_indicators=['high_1x_radial', '2x_axial_component'],
        typical_development_days=14,
        severity=3
    )
]

Hierarchical Health Index: From Sensor to Plant

Health Index — from 0 (failure) to 1 (perfect). Calculated at each level: sensor → asset → line → workshop. Each failure mode has its own ML model, results aggregated with severity weight:

class AssetHealthEnsemble:
    def __init__(self, failure_modes, weights=None):
        self.failure_modes = failure_modes
        self.models = {fm.name: load_model(fm) for fm in failure_modes}
        self.weights = weights or {fm.name: fm.severity for fm in failure_modes}

    def compute_health(self, sensor_data):
        fm_scores = {}
        for fm_name, model in self.models.items():
            features = extract_features_for_fm(sensor_data, fm_name)
            failure_prob = model.predict_proba([features])[0][1]
            fm_scores[fm_name] = 1.0 - failure_prob
        weighted_health = sum(score * self.weights[name] for name, score in fm_scores.items()) / sum(self.weights.values())
        min_score = min(fm_scores.values())
        if min_score < 0.3:
            weighted_health = min(weighted_health, min_score * 1.5)
        return weighted_health, fm_scores

Plant health is a criticality-weighted average of asset health. A critical defect on one unit lowers the overall index.

Optimizing Maintenance Timing: Balancing Cost and Risk

We balance maintenance cost against failure risk. The model uses the remaining useful life (RUL) distribution and solves for expected cost minimization:

from scipy.optimize import minimize_scalar

def optimal_maintenance_time(rul_distribution, maintenance_cost, failure_cost, holding_cost_per_day):
    def expected_cost(t_maintenance):
        p_failure_before_maintenance = rul_distribution.cdf(t_maintenance)
        cost_if_maintain = maintenance_cost + t_maintenance * holding_cost_per_day
        cost_if_fail = failure_cost * p_failure_before_maintenance
        return cost_if_maintain * (1 - p_failure_before_maintenance) + cost_if_fail

    result = minimize_scalar(expected_cost, bounds=(1, 180), method='bounded')
    return result.x  # optimal days until maintenance

Result: a Work Order with specific due date and priority. At one cement plant, this algorithm predicted a mill bearing failure 18 days in advance, allowing replacement during scheduled downtime and avoiding an emergency stop. System ROI was 400% in the first year.

Maintenance Approach Comparison

What Does Predictive Maintenance Deliver in Practice?

Typical results 6 months after deployment: 70-80% reduction in unplanned downtime, 30% increase in mean time between interventions, 20% reduction in maintenance costs. The system automatically generates Work Orders in CMMS (SAP, 1C) based on predictions, with no human intervention.

What's Included in the Work

• Equipment audit and data collection (SCADA archives, logs, schematics)
• IoT network architecture design and edge devices
• Asset Registry creation and FMEA model
• ML model development (vibration, current, temperature) and ensemble
• Model deployment on edge/cloud with inference service
• CMMS integration (SAP, 1C, custom)
• Health Index dashboard and KPIs (Grafana / Tableau)
• Technician training on the system
• 6 months of post-launch support

What Guarantees Do We Offer?

Our team: 5+ years in industrial AI and IoT. 10+ deployments in plants across Russia and CIS. We guarantee quality: if the system does not prove its effectiveness within 3 months, we refine it free of charge.

Timeline and Cost

Basic solution (up to 10 assets): 8-10 weeks. Full-scale system (100+ assets): 5-8 months. Cost is calculated individually. Contact us for a project assessment — get an engineer consultation.

Get a calculation for your plant. Order a preliminary audit.

Anomaly Detection: Autoencoders, Isolation Forest, PyOD

Server monitoring shows CPU 85%, memory 91% — is this the start of an attack or normal peak load? A classifier won’t help: anomalies are by definition rare, diverse, and not pre-labeled. Supervised learning requires examples of anomalies in the training set — so it fails on what you haven’t seen yet. Without an unsupervised approach, detection turns into guesswork.

Why Does Anomaly Detection Require an Unsupervised Approach?

The main problem: no labels and extreme class imbalance. Fraud transactions account for 0.01–0.1% of total volume, production defects 0.5–3%. With such ratios, a naive “all normal” classifier gives 99.9% accuracy but recall for the anomalous class near zero. Supervised models are powerless.

Second: “normality” is always contextual. A login at 3 AM may be normal for a night‑shift user but suspicious for a day‑worker. Bearing vibration at 2.3 mm/s depends on operating mode and machine age. So we embed context via feature engineering and time windows.

Third: quality assessment without ground truth. No standard test set — AUC‑ROC is possible only if a few labeled examples exist. For fully unlabeled data, only domain expert validation and indirect metrics work.

How to Distinguish an Anomaly from Noise in Real Time?

With adaptive thresholds and continuous monitoring of model statistics. In the case section we show how.

Isolation Forest is the standard baseline for tabular data. Idea: anomalies are isolated faster by random partitioning of the feature space. Works well at contamination=0.01–0.1, robust to feature scale, no normalization required. Implementation in sklearn.ensemble.IsolationForest.

Typical mistake: setting contamination='auto' without understanding the data. Auto mode assumes a threshold of -0.5, which may not match the actual anomaly proportion. Better: estimate expected anomaly percentage through domain knowledge and set it explicitly. We guarantee contamination tuning for your case.

PyOD (Python Outlier Detection) is a library with 40+ algorithms under a unified API — OCSVM, LOF, COPOD, ECOD, DeepSVDD, AutoEncoder. Useful for quickly comparing methods on the same data.

Autoencoders are the main method for unstructured data (time series, images, logs). Train the network to reconstruct normal data; anomalies yield high reconstruction error. Anomaly threshold is the 95th or 99th percentile of error on a validation set of normal data.

Practical problem with autoencoders: overfitting on “normal” patterns that are still rare. If the training set contains even a few anomalies, the model may learn to reconstruct them well. Solution: thorough cleaning of training data or using a Variational Autoencoder (VAE), which generalizes better.

LSTM‑AE for time series captures temporal dependencies better than a regular AE. Especially effective for multivariate time series (10+ sensors simultaneously). Implementation via PyTorch, training with MSELoss on sliding windows.

In Detail: Anomaly Detection in Industrial Time Series

Problem: vibration sensors on 12 pumps at a chemical plant, 6 sensors per pump, frequency 100 Hz. Need to warn of impending failure 4–24 hours in advance.

Solution architecture: raw data → feature extraction (RMS, kurtosis, peak factor, FFT amplitudes at resonant frequencies) → normalization by 24‑hour sliding window → LSTM‑AE → reconstruction error → threshold logic + alerting.

LSTM window size: 60 seconds (6000 points at 100 Hz). Too small a window misses slow patterns, too large loses sensitivity to rapid changes.

Anomaly threshold: not fixed, but adaptive. threshold = mean(errors_last_7d) + 3 * std(errors_last_7d). As normal state drifts (planned wear), the threshold adapts, avoiding false positives.

Result over a 6‑month pilot: detected 4 out of 5 real pre‑failure conditions (recall 0.8), with 2 false alarms over 6 months (precision 0.67). Before implementation: 3 unplanned shutdowns. After implementation: cost savings verified in the pilot report.

What Specifics Does Fraud Detection Face?

Financial transactions have several features that complicate detection:

• Concept drift: fraud patterns change faster than normal behavior. A model trained six months ago becomes obsolete.
• Adversarial adaptation: advanced fraudsters adapt — making transactions resemble normal ones.
• Temporal dependency: a series of normal transactions followed by one unusual transfer is a sequence anomaly, not a single point.

Practical stack for fraud detection: LightGBM with SMOTE oversampling for the supervised part (known fraud cases) + Isolation Forest for unsupervised (new patterns). Both signals combined in an ensemble; final decision via thresholds tuned for acceptable FPR (0.1–1% of transactions sent to manual review).

How to Evaluate Quality Without Labels?

When ground truth is absent, we evaluate using:

• Synthetic anomaly injection: add artificial anomalies (spike, level shift, point outlier) and check if the model detects them.
• Expert validation: random sample of top‑K anomalies → expert review → precision.
• Business metric: did the number of missed incidents / false alarms decrease after deployment?

Technical detail: the adaptive threshold is computed as mean(errors) + k * std(errors) on a 7‑day sliding window. Coefficient k is tuned on a validation set with synthetic anomalies to achieve FPR < 0.1%. When features drift, the window automatically shifts.

Process

1. Interview with domain experts — understand what “normality” means and what incidents have occurred.
2. EDA and data preparation — cleaning, feature creation, time windows.
3. Baseline (Isolation Forest) — fast validation on known incidents.
4. Model selection and customization — Autoencoder / LSTM‑AE / ensemble.
5. Training, validation with synthetic anomalies.
6. Deployment to production — pipeline on Kafka + Flink / Airflow, alerting to Telegram/Slack, drift monitoring.
7. Post‑deployment support — monitor model metrics, update thresholds.

What's Included

• Audit of current data and processes
• Development and training of models (Isolation Forest / Autoencoder / LSTM‑AE / ensemble)
• Configuration of adaptive thresholds and alerting
• Anomaly monitoring dashboard (Grafana / Streamlit)
• Model card and pipeline documentation
• Training for your team (2–3 sessions)
• 3‑month warranty support

Timeline: baseline system with one method — 2–4 weeks. Production system with adaptive thresholds, alerting, and monitoring — 2–5 months. Pricing is calculated individually for your case.

Our team has 8+ years of experience in industrial analytics and 15+ successful projects in anomaly detection for telemetry, finance, and IT monitoring. Get a consultation — we’ll tell you how to solve your problem. Contact us to discuss your data and receive a preliminary architecture proposal.