D03 · L3 · 02 — Maintenance & Asset ReliabilityMantenimiento y Confiabilidad de Activos

Predictive maintenance & IoT sensorsMantenimiento predictivo y sensores IoT

IoT sensors without a criticality strategy, analytics capability, and operational workflow are expensive surveillance that does not prevent failures — data gets generated, nobody uses it, failures keep happening. The three layers are mutually dependent; the difference between PdM programs that cut unplanned downtime 25–45% and PdM programs that show no gain lives entirely in which layers were built versus skipped.

Los sensores IoT sin estrategia de criticidad, capacidad analítica y workflow operativo son vigilancia cara que no previene fallas — los datos se generan, nadie los usa, las fallas siguen ocurriendo. Las tres capas son mutuamente dependientes; la diferencia entre programas PdM que reducen el downtime no planificado 25–45% y los que no muestran ganancia vive enteramente en qué capas se construyeron vs cuáles se saltaron.

01What it isQué es

Predictive maintenance (PdM) is the discipline of using condition-monitoring data — vibration, temperature, oil analysis, ultrasonic, motor current signature — to predict equipment failure before it occurs, enabling intervention in a planned window rather than during a forced outage. The IoT sensor layer is the data-acquisition tier; the analytics layer (rules-based thresholds, statistical anomaly detection, deep-learning models) is where prediction happens; the workflow layer (CMMS integration, planned work-order generation, technician dispatch) is where prediction becomes prevention. All three layers must exist; missing any one converts PdM from prevention into expensive observation.

El mantenimiento predictivo (PdM) es la disciplina de usar datos de monitoreo de condición — vibración, temperatura, análisis de aceite, ultrasónico, signatura de corriente del motor — para predecir falla de equipo antes de que ocurra, habilitando intervención en una ventana planeada en lugar de durante una salida forzada. La capa de sensor IoT es el nivel de adquisición de datos; la capa de analítica (umbrales basados en reglas, detección estadística de anomalías, modelos de deep learning) es donde sucede la predicción; la capa de workflow (integración a CMMS, generación de orden de trabajo planeada, despacho de técnico) es donde la predicción se vuelve prevención. Las tres capas deben existir; la falta de cualquiera convierte al PdM de prevención en observación costosa.

02Why it mattersPor qué importa

Predictive maintenance is the most over-marketed and most under-implemented maintenance discipline of the last decade — and the gap between IoT sensor deployment counts and actual reliability gains has become the dominant pattern in industrial operations. The dominant failure mode is sensors deployed without a criticality strategy, without analytics capability, and without operational workflow — producing terabytes of data that nobody monitors, alerts that nobody triages, and dashboards that nobody consults. The failures the data could have predicted continue to occur. The foundational text on predictive maintenance is explicit about the three-layer requirement (Mobley, 2002 — peer-reviewed, "An Introduction to Predictive Maintenance", 2nd ed., Butterworth-Heinemann): PdM delivers measurable reliability gains only when sensor strategy is driven by equipment criticality, analytics has the capability to convert raw data into actionable predictions, and operational workflow ensures predictions trigger planned interventions. Industry data confirms — well-implemented PdM programs reduce unplanned downtime 25–45% and extend equipment life 20–40%; poorly-implemented programs (sensors-only, no analytics or workflow) show no measurable gain despite 6-figure investments. The asymmetry is structural, and it lives in which layers were built versus which were skipped.

El mantenimiento predictivo es la disciplina de mantenimiento más sobre-comercializada y más sub-implementada de la última década — y la brecha entre conteos de despliegue de sensores IoT y ganancias reales de confiabilidad se ha vuelto el patrón dominante en operaciones industriales. El modo de falla dominante es sensores desplegados sin estrategia de criticidad, sin capacidad analítica y sin workflow operativo — produciendo terabytes de datos que nadie monitorea, alertas que nadie triagia y tableros que nadie consulta. Las fallas que los datos pudieron haber predicho continúan ocurriendo. El texto fundacional sobre mantenimiento predictivo es explícito sobre el requisito de tres capas (Mobley, 2002 — peer-reviewed, "An Introduction to Predictive Maintenance", 2da ed., Butterworth-Heinemann): PdM entrega ganancias medibles de confiabilidad solo cuando la estrategia de sensores está impulsada por criticidad del equipo, la analítica tiene la capacidad de convertir datos crudos en predicciones accionables y el workflow operativo asegura que las predicciones disparen intervenciones planeadas. Los datos de industria confirman — los programas PdM bien implementados reducen el paro no planeado del 25 al 45% y extienden la vida del equipo del 20 al 40%; los programas mal implementados (solo-sensores, sin analítica o workflow) muestran cero ganancia medible a pesar de inversiones de 6 cifras. La asimetría es estructural, y vive en cuáles capas se construyeron versus cuáles se saltaron.

03How it is doneCómo se hace

1
Run a criticality analysis before sensoring anything — most operations have 5–15% of equipment that warrants PdM and 85–95% that does not. Criticality is a function of (a) consequence of failure (downtime cost, safety impact, quality impact, environmental impact) and (b) probability of failure under current maintenance strategy. PdM is economically justified on assets where consequence × probability exceeds the PdM investment threshold; on lower-criticality assets, simpler strategies (run-to-failure with adequate spares, time-based PM) win. Plants that sensor everything indiscriminately produce data exhaust; plants that sensor the critical 10% with depth produce reliability gains.
2
Choose the sensing modality to the failure mode — not to the vendor offering. Vibration sensors for rotating equipment with bearing/imbalance failure modes; thermal imaging for electrical and friction failure modes; oil analysis for hydraulic, gearbox, and lubrication system failures; ultrasonic for compressed air leaks and electrical partial discharge; motor current signature analysis for motor and load-coupled failures. Each modality detects a specific failure-mode signature; deploying vibration sensors on equipment whose failures are thermal, or thermal cameras on equipment whose failures are bearing-driven, produces data that does not predict the relevant failures.
3
Build or buy the analytics capability before scaling the sensor deployment — a sensor without analytics is just an expensive dial gauge. Rules-based thresholds (vibration above X, temperature above Y) catch obvious degradation but miss complex multi-variable failure signatures; statistical anomaly detection catches drift from baseline; deep-learning models trained on labeled failure data catch specific failure-mode signatures with weeks of lead time. The analytics maturity must match the failure-mode complexity. Plants that deploy 200 sensors against a 3-rule threshold engine produce 199 false alarms and 1 missed failure per quarter.
4
Integrate PdM alerts into the CMMS/EAM workflow — predictions that do not trigger planned work orders are predictions wasted. The PdM platform must integrate with the CMMS such that a high-confidence prediction automatically generates a planned work order assigned to the appropriate technician with the diagnosed failure mode, required parts, and recommended intervention window. Without this integration, alerts pile up in a separate PdM dashboard that gets reviewed monthly while the predicted failures continue to occur as unplanned events.
5
Train reliability engineers to interpret PdM data — analytics produces a probability, not a decision. A vibration-analytics system flagging a pump as 73% likely to fail within 4 weeks does not tell the reliability engineer whether to replace the pump, replace just the bearing, schedule a rebuild during the next planned outage, or continue monitoring. The interpretation requires reliability-engineering judgment combined with operational context (criticality, available redundancy, planned outage timing, spare parts availability). Plants that treat the analytics output as the decision produce poor decisions; plants that treat it as the input to a reliability-engineering decision produce sound ones.
6
Measure the PdM program by failures prevented — not by sensors deployed. The vanity metrics (sensor count, data volume, alerts generated, dashboard views) measure activity; the economic metric (unplanned failures prevented vs same period prior year, on-time-to-prediction interventions, planned-to-unplanned ratio change) measures the value the program is creating. Plants that report sensor count to leadership produce sensor expansion; plants that report failures prevented produce reliability improvement.
Worked example — illustrativeA petrochemical plant deploys 47 wireless vibration and temperature sensors on critical pumps and compressors as part of a $680K PdM initiative. After 18 months: 3 critical equipment failures occurred that the deployed sensor data, reviewed in retrospect, showed clear precursor signatures for — but no one had been actively monitoring the data, no alerting workflow had been built, and the PdM "dashboard" was opened approximately once per quarter. The total downtime from the 3 failures was 28 days at $340K/day. The remediation: (1) criticality screening reduces the active PdM scope from 47 assets to 14 truly critical assets where the economic case justifies the program; (2) deployment of an AI-driven analytics platform (Augury) trained on industry-standard failure-mode signatures for centrifugal pumps and reciprocating compressors; (3) integration with the plant CMMS such that high-confidence predictions auto-generate planned work orders; (4) a dedicated reliability engineer with PdM-platform certification owns daily review of alerts and triage. Results 14 months after remediation: 0 unplanned failures on the 14 monitored critical assets (vs 3 in the prior 18 months on the broader set), MTBF on monitored critical equipment +130%, total downtime cost avoided estimated at $4.8M, 12 high-confidence predictions converted into planned interventions during scheduled outages. The sensor count dropped (47 → 14); the reliability gain emerged because the analytics and workflow layers were built where they had been missing.
1
Corre un análisis de criticidad antes de sensoriar cualquier cosa — la mayoría de las operaciones tiene del 5 al 15% de equipo que amerita PdM y del 85 al 95% que no. La criticidad es función de (a) consecuencia de falla (costo de paro, impacto de seguridad, impacto de calidad, impacto ambiental) y (b) probabilidad de falla bajo la estrategia actual de mantenimiento. PdM se justifica económicamente en activos donde consecuencia × probabilidad excede el umbral de inversión de PdM; en activos de menor criticidad, estrategias más simples (run-to-failure con refacciones adecuadas, PM basado en tiempo) ganan. Las plantas que sensorian todo indiscriminadamente producen exhausto de datos; las plantas que sensorian el 10% crítico con profundidad producen ganancias de confiabilidad.
2
Elige la modalidad de sensado contra el modo de falla — no contra la oferta del vendor. Sensores de vibración para equipo rotativo con modos de falla de cojinete/desbalance; imagen térmica para modos de falla eléctrica y por fricción; análisis de aceite para fallas de sistemas hidráulicos, caja de engranes y lubricación; ultrasónico para fugas de aire comprimido y descarga parcial eléctrica; análisis de signatura de corriente del motor para fallas de motor y carga acoplada. Cada modalidad detecta una signatura específica de modo de falla; desplegar sensores de vibración en equipo cuyas fallas son térmicas, o cámaras térmicas en equipo cuyas fallas son impulsadas por cojinete, produce datos que no predicen las fallas relevantes.
3
Construye o compra la capacidad analítica antes de escalar el despliegue de sensores — un sensor sin analítica es solo una galga cara. Los umbrales basados en reglas (vibración arriba de X, temperatura arriba de Y) atrapan degradación obvia pero pierden signaturas complejas multi-variable de falla; la detección estadística de anomalías atrapa deriva del baseline; los modelos de deep learning entrenados en datos etiquetados de falla atrapan signaturas específicas de modo de falla con semanas de lead time. La madurez analítica debe coincidir con la complejidad del modo de falla. Las plantas que despliegan 200 sensores contra un motor de 3 reglas de umbral producen 199 falsas alarmas y 1 falla perdida por trimestre.
4
Integra las alertas PdM al workflow de CMMS/EAM — las predicciones que no disparan órdenes de trabajo planeadas son predicciones desperdiciadas. La plataforma PdM debe integrarse con el CMMS de modo que una predicción de alta confianza genere automáticamente una orden de trabajo planeada asignada al técnico apropiado con el modo de falla diagnosticado, las partes requeridas y la ventana de intervención recomendada. Sin esta integración, las alertas se apilan en un tablero PdM separado que se revisa mensualmente mientras las fallas predichas continúan ocurriendo como eventos no planeados.
5
Capacita a los ingenieros de confiabilidad para interpretar los datos PdM — la analítica produce una probabilidad, no una decisión. Un sistema de analítica de vibración marcando una bomba como 73% probable a fallar dentro de 4 semanas no le dice al ingeniero de confiabilidad si reemplazar la bomba, reemplazar solo el cojinete, programar un overhaul durante el siguiente paro planeado o continuar monitoreando. La interpretación requiere juicio de ingeniería de confiabilidad combinado con contexto operativo (criticidad, redundancia disponible, timing de paro planeado, disponibilidad de refacciones). Las plantas que tratan al output de analítica como la decisión producen malas decisiones; las plantas que lo tratan como el input a una decisión de ingeniería de confiabilidad producen decisiones sólidas.
6
Mide el programa PdM por fallas prevenidas — no por sensores desplegados. Las métricas de vanidad (conteo de sensores, volumen de datos, alertas generadas, vistas de tablero) miden actividad; la métrica económica (fallas no planeadas prevenidas vs mismo período del año previo, intervenciones on-time-to-prediction, cambio en razón planeado-a-no-planeado) mide el valor que el programa está creando. Las plantas que reportan conteo de sensores al liderazgo producen expansión de sensores; las plantas que reportan fallas prevenidas producen mejora de confiabilidad.
Ejemplo trabajado — ilustrativoUna planta petroquímica despliega 47 sensores inalámbricos de vibración y temperatura en bombas y compresores críticos como parte de una iniciativa PdM de $680K. Después de 18 meses: 3 fallas de equipo crítico ocurrieron que los datos de sensor desplegado, revisados retrospectivamente, mostraron signaturas precursoras claras para — pero nadie había estado activamente monitoreando los datos, ningún workflow de alerta había sido construido y el "tablero" PdM se abría aproximadamente una vez por trimestre. El paro total de las 3 fallas fue de 28 días a $340K/día. La remediación: (1) el screening de criticidad reduce el alcance activo de PdM de 47 activos a 14 activos verdaderamente críticos donde el caso económico justifica el programa; (2) despliegue de una plataforma de analítica impulsada por IA (Augury) entrenada en signaturas de modo de falla estándar de industria para bombas centrífugas y compresores reciprocantes; (3) integración con el CMMS de planta de modo que las predicciones de alta confianza auto-generen órdenes de trabajo planeadas; (4) un ingeniero de confiabilidad dedicado con certificación de la plataforma PdM dueña la revisión diaria de alertas y el triage. Resultados 14 meses después de la remediación: 0 fallas no planeadas en los 14 activos críticos monitoreados (vs 3 en los 18 meses previos en el conjunto más amplio), MTBF en equipo crítico monitoreado +130%, costo total de paro evitado estimado en $4.8M, 12 predicciones de alta confianza convertidas en intervenciones planeadas durante paros programados. El conteo de sensores cayó (47 → 14); la ganancia de confiabilidad emergió porque las capas de analítica y workflow se construyeron donde habían estado faltando.

04In practiceEn la práctica

🎯Run criticality analysis before sensoring anything›
Sensors deployed against non-critical assets generate data exhaust nobody monitors; sensors deployed against critical assets without first ranking failure-mode consequences attack symptoms rather than the highest-impact failures. Criticality analysis determines which 5–15% of assets warrant the analytics investment.
🧠Match sensing modality to failure mode, not to vendor offering›
Vibration for bearings, oil analysis for lubrication wear, motor-current signature for electrical-mechanical coupling, thermography for heat-pattern anomalies, ultrasonic for early-stage leak detection (Mobley, 2002 — peer-reviewed, Butterworth-Heinemann). The vendor that sells one modality will recommend that modality for every failure.
🔁Integrate alerts into the CMMS so predictions trigger planned work orders›
A prediction that does not generate a work order is a prediction that did not happen. The workflow layer — CMMS integration, automated work-order generation, technician dispatch, predicted-failure date driving scheduling — is what converts prediction into prevention. Without it the alert lives in a dashboard nobody monitors.
👤Reliability engineering owns all three layers, not just sensors›
Maintenance engineering owns sensor deployment; IT/OT owns platform infrastructure; nobody owns analytics or workflow integration. The structural fix is a reliability-engineering function with explicit cross-layer ownership, senior enough to negotiate across maintenance, operations, IT, and engineering.
🎯Corre análisis de criticidad antes de sensorear nada›
Los sensores desplegados contra activos no críticos generan data exhaust que nadie monitorea; los sensores desplegados contra activos críticos sin primero ranquear las consecuencias del modo de falla atacan síntomas en lugar de las fallas de mayor impacto. El análisis de criticidad determina cuál 5–15% de los activos amerita la inversión analítica.
🧠Empata la modalidad de sensado al modo de falla, no a la oferta del vendor›
Vibración para rodamientos, análisis de aceite para desgaste de lubricación, firma de corriente de motor para acoplamiento eléctrico-mecánico, termografía para anomalías de patrón térmico, ultrasónico para detección temprana de fugas (Mobley, 2002 — peer-reviewed, Butterworth-Heinemann). El vendor que vende una modalidad va a recomendar esa modalidad para cada falla.
🔁Integra alertas al CMMS para que las predicciones disparen órdenes de trabajo planeadas›
Una predicción que no genera una orden de trabajo es una predicción que no ocurrió. La capa de workflow — integración con CMMS, generación automatizada de órdenes de trabajo, dispatch de técnicos, fecha predicha de falla manejando el scheduling — es lo que convierte predicción en prevención. Sin esto, la alerta vive en un dashboard que nadie monitorea.
👤Ingeniería de confiabilidad es dueña de las tres capas, no solo de los sensores›
Ingeniería de mantenimiento es dueña del despliegue de sensores; IT/OT es dueño de la infraestructura de plataforma; nadie es dueño de la analítica o la integración de workflow. El arreglo estructural es una función de ingeniería de confiabilidad con titularidad explícita cross-capa, suficientemente senior para negociar across mantenimiento, operaciones, IT e ingeniería.

05What you would useQué se usa

📌 PREDICTIVE MAINTENANCE STACK
🟦Augury / Senseye (Siemens) / SparkCognition / Aspen Mtell›
AI-driven PdM platforms with pre-trained failure-mode models for common rotating equipment (pumps, motors, compressors, gearboxes); the right fit for operations that need analytics capability without building data science in-house (Augury — vendor; Siemens — vendor; Aspen Technology — vendor).
🟩Emerson AMS / GE Bently Nevada System 1 / SKF @ptitude — traditional condition monitoring›
Enterprise condition-monitoring platforms with deep installed bases in process industries — strong for vibration analysis on rotating equipment, with integration into broader Emerson/GE/SKF instrumentation ecosystems (Emerson — vendor; GE Vernova — vendor; SKF — vendor).
🟥AWS IoT SiteWise / Azure IoT Hub / PTC ThingWorx — IoT platform infrastructure›
Cloud-based IoT platforms for sensor data ingestion, edge processing, time-series storage, and integration with analytics and CMMS; the platform layer when the PdM stack is built in-house rather than purchased turnkey (AWS — vendor; Microsoft — vendor; PTC — vendor).
⬜Targeted handheld vibration analyzer + reliability-engineer-led monthly route + CMMS integration›
For operations where continuous monitoring is not justified — a portable analyzer (Emerson CSI 2140, SKF CMU 100) used on a monthly route by a trained reliability engineer, with results captured in CMMS and trended over time. The high-discipline manual option produces solid reliability gains on operations where the 24/7 monitoring economics do not justify continuous PdM.
📌 STACK DE MANTENIMIENTO PREDICTIVO
🟦Augury / Senseye (Siemens) / SparkCognition / Aspen Mtell›
Plataformas PdM impulsadas por IA con modelos pre-entrenados de modo de falla para equipo rotativo común (bombas, motores, compresores, cajas de engranes); el fit correcto para operaciones que necesitan capacidad analítica sin construir data science in-house (Augury — vendor; Siemens — vendor; Aspen Technology — vendor).
🟩Emerson AMS / GE Bently Nevada System 1 / SKF @ptitude — monitoreo tradicional de condición›
Plataformas empresariales de monitoreo de condición con bases instaladas profundas en industrias de proceso — robustas para análisis de vibración en equipo rotativo, con integración a los ecosistemas más amplios de instrumentación Emerson/GE/SKF (Emerson — vendor; GE Vernova — vendor; SKF — vendor).
🟥AWS IoT SiteWise / Azure IoT Hub / PTC ThingWorx — infraestructura de plataforma IoT›
Plataformas IoT basadas en la nube para ingesta de datos de sensores, procesamiento en edge, almacenamiento de series de tiempo e integración con analítica y CMMS; la capa de plataforma cuando el stack PdM se construye in-house en lugar de comprarse llave en mano (AWS — vendor; Microsoft — vendor; PTC — vendor).
⬜Analizador de vibración portátil dirigido + ruta mensual liderada por ingeniero de confiabilidad + integración a CMMS›
Para operaciones donde el monitoreo continuo no se justifica — un analizador portátil (Emerson CSI 2140, SKF CMU 100) usado en una ruta mensual por un ingeniero de confiabilidad capacitado, con resultados capturados en CMMS y tendenciados en el tiempo. La opción manual de alta disciplina produce ganancias sólidas de confiabilidad en operaciones donde la economía de monitoreo 24/7 no justifica el PdM continuo.
The bottom lineEn corto

IoT sensors deployed without a criticality strategy, analytics capability, and operational workflow are expensive surveillance that does not prevent failures — the data gets generated, nobody uses it, the failures keep happening. Run criticality analysis before sensoring anything, match sensing modality to failure mode not to vendor offering, build or buy analytics capability proportional to failure-mode complexity, integrate alerts into the CMMS workflow so predictions trigger planned work orders, train reliability engineers to interpret outputs as inputs to engineering judgment, and measure the program by failures prevented not by sensors deployed. The three layers (sensor, analytics, workflow) are mutually dependent — and the difference between PdM programs that reduce unplanned downtime 25–45% and PdM programs that produce no measurable gain lives entirely in which layers were built versus skipped.

Los sensores IoT desplegados sin estrategia de criticidad, capacidad analítica y workflow operativo son vigilancia costosa que no previene fallas — los datos se generan, nadie los usa, las fallas siguen pasando. Corre el análisis de criticidad antes de sensoriar cualquier cosa, empareja la modalidad de sensado con el modo de falla no con la oferta del vendor, construye o compra capacidad analítica proporcional a la complejidad del modo de falla, integra las alertas al workflow del CMMS para que las predicciones disparen órdenes de trabajo planeadas, capacita a los ingenieros de confiabilidad para interpretar outputs como inputs al juicio de ingeniería, y mide el programa por fallas prevenidas no por sensores desplegados. Las tres capas (sensor, analítica, workflow) son mutuamente dependientes — y la diferencia entre programas PdM que reducen el paro no planeado del 25 al 45% y programas PdM que no producen ganancia medible vive enteramente en cuáles capas se construyeron versus cuáles se saltaron.

← PreviousAnteriorTPM — Total Productive MaintenanceTPM — Mantenimiento Productivo TotalNextSiguiente →Reliability-Centered Maintenance (RCM)Mantenimiento Centrado en Confiabilidad (RCM)

All D03 componentsTodos los componentes de D03D03 artifactsArtifacts de D03SCRA