Building a Predictive Maintenance Program with Maximo Health and Predict
>
Building a Predictive Maintenance Program with Maximo Health and Predict
The maintenance maturity curve is well understood: reactive maintenance costs the most, preventive maintenance costs less, condition-based maintenance costs less still, and predictive maintenance offers the best balance of cost and reliability. But moving up that curve requires more than just buying software. It requires a systematic approach to data collection, analysis, and decision-making that most organizations struggle to implement.
Maximo Health and Maximo Predict, two applications within the Maximo Application Suite, provide the technical foundation for predictive maintenance. This article explains how to use them together to build a predictive maintenance program that delivers measurable results.
The Predictive Maintenance Technology Stack
Before diving into implementation, it is important to understand how the components fit together:
┌─────────────────────────────────────────────────────────┐│ Data Sources ││ ┌──────────┐ ┌──────────┐ ┌──────────┐ ││ │ IoT │ │ SCADA │ │ Manual │ ││ │ Sensors │ │ Systems │ │ Readings │ ││ └────┬─────┘ └────┬─────┘ └────┬─────┘ ││ │ │ │ ││ ▼ ▼ ▼ ││ ┌──────────────────────────────────────┐ ││ │ Maximo Monitor │ ││ │ (Data ingestion, normalization, │ ││ │ anomaly detection, alerting) │ ││ └────────────────┬─────────────────────┘ ││ │ ││ ▼ ││ ┌──────────────────────────────────────┐ ││ │ Maximo Health │ ││ │ (Asset health scoring, criticality │ ││ │ assessment, KPI dashboards) │ ││ └────────────────┬─────────────────────┘ ││ │ ││ ▼ ││ ┌──────────────────────────────────────┐ ││ │ Maximo Predict │ ││ │ (Failure probability modeling, │ ││ │ remaining useful life estimation) │ ││ └────────────────┬─────────────────────┘ ││ │ ││ ▼ ││ ┌──────────────────────────────────────┐ ││ │ Maximo Manage │ ││ │ (Work order generation, scheduling, │ ││ │ execution, feedback loop) │ ││ └──────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘
Each layer builds on the one below it. You cannot skip directly to Predict without first establishing the data foundation in Monitor and the health framework in Health.
Maximo Health: The Foundation of Asset Health Scoring
Maximo Health provides the framework for assessing and tracking asset health across your entire fleet. It is not a predictive tool on its own. It is the scoring and visualization layer that tells you which assets need attention and why.
The Health Scoring Model
Health scores are calculated from multiple contributing factors:
| Score Component | Data Source | Weight Example | Update Frequency |
|---|---|---|---|
| Condition rating | Manual inspections | 25% | Per inspection |
| Meter-based | Runtime hours, cycles | 20% | Continuous |
| Work order history | Corrective WO frequency | 15% | Per WO completion |
| IoT sensor data | Vibration, temperature, pressure | 25% | Real-time |
| Age/installation date | Asset registry | 10% | Daily |
| Failure history | Failure codes, downtime | 5% | Per failure event |
The scoring formula is configurable:
{
"assetType": "CENTRIFUGAL_PUMP",
"scoringModel": {
"components": [
{
"name": "conditionRating",
"source": "inspection",
"weight": 0.25,
"thresholds": {
"critical": 20,
"poor": 40,
"fair": 60,
"good": 80
}
},
{
"name": "meterBased",
"source": "meter",
"weight": 0.20,
"meterName": "RUNHOURS",
"thresholds": {
"critical": 0.90,
"poor": 0.75,
"fair": 0.50,
"good": 0.25
},
"calculation": "percentageOfOverhaulInterval"
},
{
"name": "iotVibration",
"source": "monitor",
"weight": 0.25,
"metricName": "vibration_rms",
"thresholds": {
"critical": 7.1,
"poor": 4.5,
"fair": 2.8,
"good": 1.8
}
},
{
"name": "correctiveWorkOrders",
"source": "workorder",
"weight": 0.15,
"lookbackDays": 365,
"thresholds": {
"critical": 10,
"poor": 5,
"fair": 2,
"good": 0
}
},
{
"name": "ageFactor",
"source": "asset",
"weight": 0.10,
"thresholds": {
"critical": 25,
"poor": 20,
"fair": 15,
"good": 0
},
"calculation": "yearsSinceInstallation"
},
{
"name": "failureHistory",
"source": "failurecode",
"weight": 0.05,
"lookbackDays": 730,
"thresholds": {
"critical": 5,
"poor": 3,
"fair": 1,
"good": 0
}
}
],
"overallCalculation": "weightedAverage",
"scoreRange": {
"min": 0,
"max": 100
},
"interpretation": {
"critical": { "range": [0, 25], "color": "red", "action": "Immediate intervention required" },
"poor": { "range": [26, 50], "color": "orange", "action": "Schedule maintenance within 30 days" },
"fair": { "range": [51, 75], "color": "yellow", "action": "Monitor and plan for next PM window" },
"good": { "range": [76, 100], "color": "green", "action": "Routine maintenance only" }
}
}
}
Criticality Assessment
Not all assets are equally important. Maximo Health includes a criticality assessment framework that helps prioritize which assets deserve the most attention:
# Conceptual: Criticality scoring logic
def calculate_criticality(asset):
score = 0
# Safety impact (0-30 points)
if asset.has_safety_risk():
score += 30
elif asset.has_environmental_risk():
score += 20
# Production impact (0-25 points)
if asset.is_single_point_of_failure():
score += 25
elif asset.has_redundancy():
score += 10
# Maintenance cost (0-20 points)
annual_maintenance_cost = asset.get_annual_maintenance_cost()
if annual_maintenance_cost > 100000:
score += 20
elif annual_maintenance_cost > 50000:
score += 10
# Replacement cost and lead time (0-15 points)
if asset.replacement_lead_time_days > 180:
score += 15
elif asset.replacement_lead_time_days > 90:
score += 10
# Regulatory compliance (0-10 points)
if asset.is_regulated():
score += 10
return score
The combination of health score and criticality creates a prioritization matrix:
| Low Criticality | Medium Criticality | High Criticality | |
|---|---|---|---|
| Good Health | Routine monitoring | Scheduled PM | Enhanced monitoring |
| Fair Health | Plan maintenance | Schedule within 60 days | Schedule within 30 days |
| Poor Health | Schedule within 90 days | Schedule within 30 days | Schedule within 14 days |
| Critical Health | Schedule within 30 days | Schedule within 7 days | Immediate action |
Maximo Predict: From Health Scoring to Failure Prediction
While Health tells you the current state of an asset, Predict tells you what is likely to happen next. Predict uses machine learning models trained on historical data to estimate the probability of failure and remaining useful life (RUL).
How Predict Models Work
Maximo Predict is not a black box. It provides several model types, and understanding which to use for which scenario is critical:
| Model Type | Best For | Data Requirements | Output |
|---|---|---|---|
| Survival Analysis | Assets with known failure events | Failure timestamps, runtime data | Probability of failure over time |
| Regression | Continuous degradation patterns | Sensor time series, condition data | Remaining useful life estimate |
| Classification | Binary failure prediction | Labeled failure/normal data | Failure probability within window |
| Anomaly Detection | Unknown failure patterns | Normal operating data | Anomaly score, deviation from baseline |
Data Requirements for Effective Predictions
The most common reason Predict implementations fail is insufficient data. Here are the minimum data requirements:
minimum_data_requirements:
failure_events:
count: "At least 20 failure events per asset type"
quality: "Accurate failure timestamps and failure codes"
coverage: "Representative of all common failure modes"
sensor_data:
frequency: "At least hourly readings for 6+ months"
parameters: "Vibration, temperature, pressure, flow rate (as applicable)"
quality: "Clean, with known sensor calibration dates"
maintenance_history:
duration: "2+ years of work order history"
detail: "Failure codes, repair actions, parts replaced"
completeness: "Both corrective and preventive work orders"
asset_registry:
accuracy: "Correct installation dates, specifications, operating context"
hierarchy: "Clear parent-child relationships and functional locations"
Building a Failure Probability Model
Here is a conceptual walkthrough of building a failure prediction model for centrifugal pumps:
# Conceptual: Failure probability model training pipeline
# This represents the logic Predict applies, not actual API code
def train_pump_failure_model(pump_data):
"""
Train a survival analysis model for centrifugal pump failures.
Input features:
- vibration_rms: Root mean square vibration (mm/s)
- temperature: Bearing temperature (Celsius)
- pressure_differential: Inlet vs outlet pressure (bar)
- flow_rate: Measured flow rate (L/min)
- runtime_hours: Total runtime since last overhaul
- maintenance_count: Corrective maintenance events in past 12 months
- age_years: Years since installation
- operating_cycles: Start/stop cycles since last overhaul
Target:
- time_to_failure: Days until next failure event
- event_observed: Boolean (True if failure occurred, False if censored)
"""
# Feature engineering
features = [
'vibration_rms',
'vibration_trend_30d', # 30-day vibration trend
'temperature_max_7d', # Max temperature in past 7 days
'temperature_above_threshold_hours', # Hours above 75C
'pressure_differential',
'flow_rate_deviation', # Deviation from expected flow rate
'runtime_hours',
'runtime_since_last_pm', # Runtime since last preventive maintenance
'maintenance_count_12m',
'age_years',
'operating_cycles',
'mean_time_between_failures_historical'
]
# Model: Cox Proportional Hazards or Random Survival Forest
# Output: Survival function S(t) = P(T > t)
# Where T is time to failure
return trained_model
def predict_failure_probability(model, asset_current_data, horizon_days=30):
"""
Predict probability of failure within the specified horizon.
"""
survival_probability = model.predict_survival(
asset_current_data,
time_horizon=horizon_days
)
failure_probability = 1.0 - survival_probability
return {
"asset_id": asset_current_data["asset_id"],
"horizon_days": horizon_days,
"failure_probability": failure_probability,
"risk_level": classify_risk(failure_probability),
"top_contributing_factors": model.explain_prediction(asset_current_data)
}
def classify_risk(probability):
if probability > 0.70:
return "CRITICAL"
elif probability > 0.40:
return "HIGH"
elif probability > 0.15:
return "MEDIUM"
return "LOW"
Integrating IoT Data with Maximo Monitor
Maximo Monitor is the data ingestion and normalization layer that feeds both Health and Predict. It handles the messy reality of industrial IoT data: different protocols, different sampling rates, gaps in data, and sensor drift.
Data Ingestion Architecture
Monitor supports multiple ingestion paths:
┌──────────────────────────────────────────────────────┐
│ Data Sources │
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ MQTT │ │ OPC-UA │ │ REST │ │ File │ │
│ │ Devices │ │ Servers │ │ APIs │ │ Upload │ │
│ └────┬────┘ └────┬────┘ └────┬────┘ └────┬────┘ │
│ │ │ │ │ │
│ ▼ ▼ ▼ ▼ │
│ ┌──────────────────────────────────────────────┐ │
│ │ Monitor Ingestion Service │ │
│ │ - Protocol translation │ │
│ │ - Schema validation │ │
│ │ - Data normalization │ │
│ │ - Timestamp alignment │ │
│ │ - Gap detection and interpolation │ │
│ └────────────────────┬─────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────┐ │
│ │ Time Series Store │ │
│ │ (Db2 with time series optimization) │ │
│ └──────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────┘
Configuring Anomaly Detection
Monitor includes built-in anomaly detection that can trigger alerts before a failure prediction model is even trained:
# Example: Anomaly detection configuration for a pump
anomaly_detection:
asset_type: CENTRIFUGAL_PUMP
metrics:
- name: vibration_rms
type: threshold
warning: 4.5
critical: 7.1
unit: mm/s
direction: increasing
- name: bearing_temperature
type: threshold
warning: 70
critical: 85
unit: celsius
direction: increasing
- name: pressure_differential
type: statistical
method: moving_average_deviation
window_hours: 24
deviation_threshold: 2.5 # standard deviations
direction: both
- name: flow_rate
type: pattern
method: seasonal_decomposition
training_period_days: 30
anomaly_threshold: 3.0 # standard deviations
Transitioning from Preventive to Predictive
The hardest part of implementing predictive maintenance is not the technology. It is changing the maintenance culture. Here is a practical transition framework:
Phase 1: Data Foundation (Months 1-3)
- Identify pilot assets (high criticality, good data availability)
- Install or connect IoT sensors to Monitor
- Configure Health scoring for pilot assets
- Establish baseline health scores
- Begin collecting failure event data with accurate timestamps and codes
Phase 2: Model Development (Months 3-6)
- Train initial Predict models on pilot assets
- Validate model accuracy against known failure events
- Configure alert thresholds and notification workflows
- Run models in shadow mode (predictions generated but not acted upon)
- Compare model predictions against actual outcomes
Phase 3: Guided Implementation (Months 6-9)
- Begin acting on high-confidence predictions
- Generate work orders from Predict alerts
- Track false positives and false negatives
- Refine models based on feedback
- Expand to additional asset classes
Phase 4: Optimization (Months 9-12+)
- Tune PM schedules based on actual failure patterns
- Reduce unnecessary preventive maintenance
- Expand to full asset fleet
- Integrate with planning and scheduling
- Measure and report ROI
Measuring Success
Define KPIs before you start and track them throughout:
| KPI | Baseline | Target | Measurement |
|---|---|---|---|
| Unplanned downtime | Current hours/year | 50% reduction | Downtime tracking |
| Maintenance cost | Current annual spend | 20% reduction | Cost per asset |
| PM compliance | Current % | Maintain or improve | PM completion rate |
| Emergency work orders | Current count | 40% reduction | WO type distribution |
| Mean time between failures | Current MTBF | 30% improvement | Failure event tracking |
| False positive rate | N/A | <20% | Predict alert accuracy |
Practical Implications
For reliability engineers: Maximo Health and Predict are powerful tools, but they are not a substitute for reliability engineering expertise. The models are only as good as the data and the domain knowledge that goes into configuring them. You still need to understand failure modes, criticality assessment, and root cause analysis. The tools amplify your expertise; they do not replace it.
For maintenance managers: Predictive maintenance changes how you plan and schedule work. Instead of fixed PM schedules, you will receive dynamically generated work orders based on actual asset condition. This requires more flexible planning processes and closer coordination between the reliability and planning teams.
For IT and data teams: The data infrastructure for predictive maintenance is significant. IoT data ingestion, time series storage, and model training all require compute and storage resources. Plan for this infrastructure before starting the implementation, not after.
For executives: Predictive maintenance delivers ROI, but it takes time. The first year is about building the data foundation and training models. Meaningful cost reduction typically appears in year two. Set expectations accordingly and commit to the multi-year journey.
Bottom Line
Predictive maintenance with Maximo Health and Predict is achievable for organizations that are willing to invest in the data foundation and commit to the cultural change. The technology works. The challenge is not the algorithms. It is the data quality, the organizational alignment, and the patience to let the models mature.
Start small. Pick five to ten critical assets with good data. Build the Health scoring model. Train initial Predict models. Prove the concept before expanding. The organizations that succeed with predictive maintenance are the ones that treat it as a continuous improvement program, not a one-time project. The ones that fail are the ones that try to predict failures on every asset on day one without first establishing the data and processes that make prediction possible.