Building a Condition-Based Maintenance Program with Maximo: From Sensor to Work Order
A practitioner's guide to building a condition-based maintenance program in Maximo: from IoT sensor data ingestion through Health scoring, Predict modeling, Condition Insight, and automatic work order generation. Includes configuration examples and production patterns.
Building a Condition-Based Maintenance Program with Maximo: From Sensor to Work Order
Condition-based maintenance (CBM) has been the stated goal of maintenance organizations for decades. The promise is clear: instead of fixing assets when they fail (reactive) or on a fixed schedule (preventive), you monitor the actual condition of the asset and perform maintenance only when the condition indicates that failure is approaching. This approach reduces unnecessary maintenance, extends asset life, and prevents catastrophic failures. The challenge has always been execution: connecting sensor data to maintenance decisions in a closed-loop process that actually works in production.
IBM Maximo Application Suite 9.x provides the most complete set of tools for building a CBM program that the platform has ever offered. The APM stack (Monitor, Health, Predict, Condition Insight, Reliability Strategies, Visual Inspection) is integrated with the EAM application (Manage) in a way that creates a closed loop from condition monitoring to work order execution. This article is a practitioner's guide to building that closed-loop process. We will walk through each stage of the CBM pipeline, from sensor data ingestion through condition assessment, failure prediction, AI-driven interpretation, and automatic work order generation.
The CBM Pipeline: An Overview
Before diving into the individual components, it is essential to understand the overall architecture of a condition-based maintenance program in Maximo. The CBM pipeline is a sequence of data flows and processing steps that starts with sensor data and ends with a completed work order.
The pipeline has five stages. First, Maximo Monitor ingests real-time sensor data from IoT devices, SCADA systems, and other operational data sources. It applies analytics pipelines to detect anomalies and generate alerts. Second, Maximo Health takes the sensor data from Monitor, combines it with maintenance history from Manage, and calculates asset health scores, criticality ratings, and risk scores. Third, Maximo Predict uses AI and machine learning to analyze historical failure data and sensor trends to forecast when assets are likely to fail. Fourth, Maximo Condition Insight interprets the outputs of Monitor, Health, and Predict using agentic AI to explain asset condition in natural language and recommend corrective actions. Fifth, the recommended actions are converted into work orders in Maximo Manage, closing the loop.
The key architectural principle is that these applications are integrated, not just connected. They share a common asset registry, a common security model, and a common deployment environment. Data flows between them through APIs and event streams, not through file transfers or batch jobs. This integration is what makes the closed-loop process possible: a sensor reading that indicates an anomaly can trigger a health score update, which can trigger a predictive model re-evaluation, which can trigger a Condition Insight recommendation, which can generate a work order, all within the same platform.
Stage 1: Maximo Monitor - Sensor Data Ingestion and Anomaly Detection
Maximo Monitor is the data ingestion and real-time monitoring layer of the APM stack. It connects to IoT sensors, PLCs, SCADA systems, historians, and other operational data sources, ingests time-series data, and provides real-time analytics and alerting. Without good sensor data, the rest of the CBM pipeline cannot function, so configuring Monitor correctly is the foundation of a successful CBM program.
Monitor connects to data sources through a set of pre-built connectors and a generic HTTP/REST connector for custom data sources. For common industrial protocols (OPC UA, Modbus, MQTT), Monitor provides pre-built connector agents that can be deployed on edge devices or on servers in the plant network. The connectors handle the protocol translation, data buffering, and secure transmission of data to the Monitor service running in OpenShift.
Once data is ingested, Monitor runs analytics pipelines on the incoming data stream. These pipelines can be simple threshold alerts (temperature exceeds 80 degrees Celsius), statistical anomaly detection (vibration pattern deviates from the baseline by more than 3 standard deviations), or more complex calculation pipelines that derive metrics from raw sensor data. The derived metrics are often more useful than the raw data for condition assessment: a bearing health indicator derived from vibration frequency analysis is more informative than raw vibration amplitude.
Here is an example of a Monitor calculation pipeline for a bearing health indicator:
{
"pipelineName": "BearingHealthIndicator",
"description": "Calculate rolling bearing health from vibration RMS and temperature",
"inputs": [
{"metric": "vibration_rms", "source": "sensor:PUMP-301-VIB"},
{"metric": "bearing_temp_c", "source": "sensor:PUMP-301-TEMP"}
],
"steps": [
{"type": "WINDOW", "windowType": "rolling", "windowSize": "1h", "aggregation": "mean"},
{"type": "CALCULATE", "expression": "vibration_rms_mean * (1 + bearing_temp_c_mean / 100)"},
{"type": "THRESHOLD", "alertOn": true, "warningLevel": 2.5, "criticalLevel": 4.0,
"alertMessage": "Bearing health indicator exceeded threshold for pump P-301"}
],
"output": {"metric": "bearing_health_index", "store": true, "alert": true}
}
This pipeline takes the rolling 1-hour mean of vibration RMS and bearing temperature, combines them into a composite health indicator, and generates an alert when the indicator exceeds defined thresholds. The alert is the key output of Monitor: it is the signal that something has changed in the asset's condition and that the rest of the CBM pipeline should take action.
The alerting configuration is critical. Too many alerts create alert fatigue, where maintenance teams start ignoring notifications because they are overwhelmed by false positives. Too few alerts mean real issues are missed. The best practice is to start with conservative thresholds and gradually tune them based on operational experience. A common starting point is to set the warning threshold at 2 sigma above the baseline mean and the critical threshold at 3 sigma. After 30 to 60 days of operation, analyze the alert history and adjust thresholds to achieve a target false-positive rate of less than 10%.
Stage 2: Maximo Health - Asset Condition Scoring
Maximo Health is the asset condition and risk assessment layer. It takes data from Monitor (real-time sensor data), Manage (maintenance history, failure records, asset attributes), and external sources (inspection reports, environmental data) to calculate asset health scores, criticality ratings, and risk scores. Health is where the raw data from sensors is translated into a condition assessment that maintenance teams can act on.
Health uses scoring methodologies that can be configured per asset type. Different assets degrade in different ways, and a single scoring model cannot capture the condition of all asset types. For example, a pump might be scored on vibration, temperature, and oil quality metrics. A transformer might be scored on dissolved gas analysis, oil temperature, and load history. A motor might be scored on bearing vibration, stator temperature, and run hours. Health supports multiple scoring models, and each asset type can be assigned a specific model.
IBM provides pre-built scoring models for common asset types in the utilities and energy sectors. For organizations in other industries, custom scoring models can be built using the Health scoring framework. The framework supports formula-based scoring (weighted averages of individual metrics) and model-based scoring (machine learning models that predict health based on historical patterns).
A key concept in Health is the distinction between asset health, asset criticality, and asset risk. Health is the current condition of the asset: how close is it to failure? Criticality is the impact of the asset's failure on the business: how much does it cost if this asset goes down? Risk is the combination of health and criticality: what is the probability of failure multiplied by the impact of failure? All three scores are important for prioritizing maintenance work, and Health calculates all three.
The risk score is particularly useful for maintenance planning. An asset with poor health but low criticality might be a lower priority than an asset with moderate health but high criticality. The risk score quantifies this trade-off and gives maintenance planners a single metric for prioritizing work. Health displays the risk score in a color-coded matrix (green, yellow, red) that makes it easy to identify the highest-priority assets at a glance.
For organizations in the utilities sector, MAS 9.2 includes pre-built scoring models for electrical distribution and transmission assets. These models incorporate industry-standard health, criticality, effective age, and end-of-life probability calculations. The pre-built models save significant configuration effort and provide a starting point that can be customized for specific asset populations.
Stage 3: Maximo Predict - Failure Forecasting with AI
Maximo Predict is the failure prediction layer. It uses AI and machine learning to forecast asset failures before they occur. While Health tells you the current condition of an asset, Predict tells you when that condition is likely to result in failure. This forward-looking view is essential for planning maintenance: it allows you to schedule maintenance before the failure occurs, rather than reacting to the failure after it happens.
Predict works by analyzing historical failure data from Manage and sensor data from Monitor to build predictive models. Data scientists use the provided Jupyter notebooks to train models on asset groups. The models estimate days to failure, probability of failure, and failure mode. Once a model is trained and deployed, it continuously scores assets and updates predictions as new data arrives.
The model training process starts with defining an asset group: a set of assets that share similar characteristics (same asset type, similar operating conditions, similar maintenance history). The asset group should be large enough to provide a meaningful training dataset. IBM recommends at least 50 assets and at least 100 historical failure events for a reliable model. For organizations with limited historical data, Predict provides pre-trained models for common asset types that can be fine-tuned with the organization's data.
Predict generates several outputs for each asset. The failure probability output estimates the probability that the asset will fail within a specified time window (typically 30, 60, or 90 days). The predicted failure date output estimates the specific date when the asset is most likely to fail. The failure contribution breakdown identifies which factors (vibration, temperature, run hours, age) are contributing most to the predicted failure. The anomaly detection output flags assets whose current behavior deviates significantly from their historical patterns.
The work queue integration is what connects Predict to the maintenance execution process. Assets with a high probability of failure or a predicted failure date within the next maintenance window are automatically added to a work queue in Manage. The work queue is visible to maintenance planners, who can review the predictions, create work orders for the recommended maintenance, and track the status of the work. This is the mechanism that turns a prediction into an action.
Stage 4: Condition Insight - AI-Driven Interpretation and Recommendations
Maximo Condition Insight, introduced in late 2025 and matured through MAS 9.2, is the most significant AI capability in the APM stack. It is an agentic AI capability that interprets asset data across the APM stack to explain asset condition and recommend corrective actions in natural language. Condition Insight is what makes the CBM pipeline practical: instead of requiring a reliability engineer to interpret the outputs of Monitor, Health, and Predict manually, Condition Insight does the interpretation and presents a clear recommendation.
Condition Insight works by aggregating data from multiple sources. It reads the current alerts from Monitor, the health and risk scores from Health, the failure predictions from Predict, the work order history from Manage, the inspection results from the inspection framework, and the failure modes from Reliability Strategies. It then uses a language model to compose a natural language explanation of the asset's condition and a recommendation for corrective action.
The recommendation is not just a text message. It includes specific, actionable information: the asset that needs attention, the condition that triggered the recommendation, the recommended action (inspection, repair, replacement, monitoring), the recommended timing (immediate, within 7 days, within 30 days), and the suggested work type (corrective, preventive, emergency). The recommendation can be reviewed by a reliability engineer or automatically converted into a work order, depending on the configuration.
For organizations that are ready to automate the closed loop, Condition Insight can be configured to automatically generate work orders for certain types of recommendations. The configuration is rule-based: you define the conditions under which automatic work order generation is allowed (for example, only for assets with criticality below a certain threshold, only for recommendations with suggested timing of "within 7 days," and only for work types of "corrective"). For higher-risk recommendations, the system generates a draft work order that requires approval before it is committed.
Stage 5: Closing the Loop - From Recommendation to Work Order
The final stage of the CBM pipeline is the conversion of recommendations into work orders. This is where the APM stack connects back to the EAM application, and where the condition-based maintenance program delivers measurable value. A CBM program that generates insights but does not convert them into completed maintenance work is a failure, regardless of how sophisticated the analytics are.
In MAS 9.x, the work order generation from APM recommendations is handled through the standard Maximo work order creation process. When Condition Insight generates a recommendation that meets the auto-generation criteria, the system creates a work order in Manage with the following pre-populated fields: the asset number, the site, the recommended work type, the description (generated by Condition Insight in natural language), the priority (derived from the risk score), and the target start date (derived from the predicted failure date or the recommended timing).
The work order is then processed through standard Maximo workflows: planning, scheduling, assignment, execution, and completion. The technician who performs the work can see the APM data that triggered the work order in the work order record, which provides context for the maintenance task. After the work is completed, the asset's condition data is updated, the health score is recalculated, and the CBM pipeline continues.
Practical Implications
Building a condition-based maintenance program with Maximo is a multi-stage project that requires investment in sensor infrastructure, data integration, model training, and process change. The technology is capable, but the technology alone is not enough. The success factors are data quality, model accuracy, organizational readiness, and process integration.
Start with a pilot: select one asset type, one plant, and one set of sensors. Configure Monitor, Health, and Predict for that asset type. Train the predictive model on historical data. Deploy Condition Insight and review the recommendations. Generate work orders and track the results. Measure the impact on downtime, maintenance costs, and asset reliability. Use the pilot results to justify the investment in expanding the program.
The timeline for a CBM pilot is typically 3 to 6 months. The first month is spent configuring Monitor and Health and validating the sensor data. The second month is spent training and deploying the Predict model. The third month is spent running the system and collecting recommendations. The fourth through sixth months are spent executing the recommended maintenance and measuring the results. A successful pilot will demonstrate a measurable reduction in unplanned downtime and a positive return on investment.
Bottom Line
Maximo Application Suite 9.x provides the most integrated, capable platform for condition-based maintenance that IBM has ever offered. The APM stack creates a closed loop from sensor data to work order execution, and Condition Insight adds an AI layer that makes the loop practical by translating complex analytics into clear, actionable recommendations. Building a CBM program is a significant effort, but the platform provides the tools, the integration, and the AI capabilities to make it work. Start with a pilot, measure the results, and expand from there.