El mantenimiento predictivo comienza con mediciones fiables e historial de mantenimiento relacionados con una pregunta de fallo concreta. Temperatura, corriente o vibración por sí solas no demuestran que se aproxime una avería. Carga, velocidad, producto, modo operativo y cambios de sensor pueden afectar a la señal observada.
Elige un problema de equipo
Empieza por una clase de equipos y un mecanismo de fallo definidos, en vez de predecir todas las averías de la fábrica. ¿Qué cambio podría indicar deterioro, qué medición lo respaldaría y qué mantenimiento seguiría a un aviso útil? Esas preguntas determinan el plan de datos.
No toda medición merece la pena. Los fallos raros pueden dejar muy poca evidencia para evaluar un método. Si el mantenimiento ya sigue un intervalo obligatorio, identifica qué cambiaría un indicador adicional. Un gran volumen no resuelve un beneficio operativo indefinido.
Grupos de datos que conservar
| Grupo | Ejemplos | Finalidad |
|---|---|---|
| Medición | Temperatura, vibración, corriente | Comportamiento físico |
| Operación | Carga, velocidad, producto, modo | Explicar variaciones normales |
| Evento | Fallo, parada, intervención | Relacionar observaciones y resultados |
| Mantenimiento | Sustitución, resultado de inspección | Respaldar etiquetas válidas |
| Calidad | Estado de sensor y conexión | Excluir evidencia engañosa |
El muestreo depende de magnitud y análisis. Una temperatura lenta y el análisis de vibraciones no comparten una frecuencia universal. Elegir equipo y método requiere experiencia pertinente en campo, no una única consulta periódica para todas las señales.
Preparación ilustrativa
Supongamos una bomba con registros de temperatura y corriente. Esta puede aumentar por mayor carga, no por una avería. Registrar resultado de inspección y momento de sustitución ayuda a interpretar las mediciones previas. Registra también sustituciones de sensores: pueden cambiar la referencia observada.
Las etiquetas de fallo tienen incertidumbre. El momento en que se detectó, se registró en mantenimiento y empezó físicamente un problema puede ser distinto. Conserva esas diferencias. La información aprendida después no debe tratarse como si hubiera estado disponible antes para predecir.
Establece primero comprobaciones simples
Revisa completitud, alineación temporal, valores fuera de rango y huecos. Explica el comportamiento normal en condiciones conocidas. Una tendencia o umbral simple puede satisfacer algunas necesidades. Un método complejo debe aportar valor adicional medible y tener un responsable capaz de mantenerlo.
Falsas alarmas y eventos omitidos pueden tener costes distintos. Considera el trabajo para mantenimiento. Un resultado útil para un producto o estación puede no transferirse a otro. Separa adecuadamente periodos y condiciones de evaluación, sin repetir la evidencia usada para desarrollar el enfoque.
La entrega inicial
Una primera fase sólida incluye diccionario de mediciones, registros coherentes de mantenimiento, sincronización, indicadores de calidad y revisión. No afirma que exista un producto de IA listo para predecir cualquier avería. La base industrial debe ser primero visible, trazable y útil para una decisión real.
Cambios de equipos, sensores o prácticas deben activar una revisión de supuestos. Un modelo o regla no sigue siendo fiable solo porque el panel continúe produciendo un número.
Construye un ejemplo de mantenimiento utilizable
Considera un motor ilustrativo con corriente, temperatura y estado registrados. La subida térmica no demuestra automáticamente un fallo incipiente: pueden cambiar carga, ambiente, velocidad o mantenimiento reciente. Conserva el contexto para comparar condiciones semejantes. Ningún modelo ni umbral recupera contexto que no se recopiló.
Vincula cada mantenimiento a identidad del equipo, síntoma comunicado, hallazgo de inspección y acción. Distingue sospecha y hallazgo confirmado. Sustituir una pieza durante mantenimiento previsto no convierte necesariamente el periodo anterior en fallo. Sin estas diferencias, el conjunto de datos puede enseñar hábitos administrativos en lugar del comportamiento del equipo.
Registra cuándo estuvo disponible cada información. Un diagnóstico introducido después de reparar sirve para analizar después, pero no estaba disponible para el aviso previo. Usarlo como entrada en la evaluación produciría un éxito irreal. Conserva historial suficiente para reconstruir qué podía saberse en el momento propuesto de decisión.
Evalúa utilidad antes que sofisticación
Empieza por una referencia transparente que mantenimiento pueda interpretar: comparar mediciones en una condición definida o detectar un alejamiento sostenido de una referencia acordada. El objetivo es comprobar si los datos permiten evaluar algo útil, no llamar mantenimiento predictivo a cualquier umbral. Compara el método propuesto con esa referencia usando periodos que representen la operación futura tan fielmente como permita la evidencia.
Define qué pasa tras el aviso. ¿Quién inspecciona, qué evidencia registra y cómo identifica una falsa alarma? Sin respuesta práctica, un aviso puede añadir trabajo sin mejorar decisiones. Omitir un evento relevante tiene consecuencias distintas de generar una inspección innecesaria. Discútelas explícitamente, sin fusionarlas en un porcentaje de exactitud sin explicar.
Revisa cobertura de cargas, estaciones y estados de mantenimiento. Fallos raros y equipos cambiantes pueden impedir generalizaciones sólidas. Expón los límites y reúne más evidencia cuando haga falta. Un primer proyecto puede centrarse en mediciones y registros fiables sin prometer predicción automática. Lleva históricos existentes, contexto de equipos y ejemplos de hallazgos a la conversación inicial: muestran qué preguntas pueden responderse y dónde hay que preparar primero los datos.