Vamos a traducir un artículo, relacionado muy íntimamente con los ya existentes sistemas expertos en el campo del software de mantenimiento Industrial.
Aquí tenéis el original:
Condition Lies in Data, (que desaparece en 2026 porque es antiguo el texto)
Si bien El artículo se podría titular:
Análisis de Condición pasará por Filtrar Datos en el Software de Mantenimiento
TRADUCCION DEL ARTÍCULO
Todos sabemos que el pronosticar ayuda a evitar mal funcionamiento y gestionar el tiempo de vida útil en maquinaria.
De hecho cada vez más las compañías se encuentran alimentadas de un flujo incremental de datos complejos (Big Data).
De hecho, aquellas empresas capaces de obtener algún valor de los datos pueden obtener una ventaja significativa, en base a reconocer los verdaderos problemas, evitando consumir recursos en aquellos que son realmente
Potenciales problemas.
Se trata simplemente de aprovechar las ventajas que el entorno software de mantenimiento ofrece a través del Internet de las Cosas,
especialmente cuando se trata de hablar de optimización y automatización.
En definitiva, se trata de
Usar datos
eficientemente,
pues ya es un hecho el que las máquinas estén controladas, en la actualidad con modernas tecnologías que podrían ser aprovechables para lograr cotas importantes de coordinación y mejoras en eficiencia.
Además si nos referimos a
Software de Mantenimiento
toda esa información se puede utilizar como base para una estrategia predictiva futura.
A nadie debería sorprenderle, por tanto, la posible realización de pronósticos sobre la condición de la maquinaria o de cada uno de los componentes individuales.
Esta aproximación permite un modo de actuación proactivo en la gestión de los planes.
Todo ello lleva a evitar averías y las consecuencias derivadas, optimizando además los costes de reemplazo de componentes.
En este contexto de software, hablar de pronóstico puede sonar fuera de lugar, si bien no es así cuando lo definimos como un objetivo futuro de
- condición de las máquinas basado en datos y variables objetivas.
Por tanto, los informes de pronóstico desde el software de mantenimiento pueden aportar información sobre la condición futura de las máquinas o componentes desde un período de semanas, meses o incluso años.
Entonces, ¿son conceptos distintos ….
DiagnosticosyPronósticos?
Los diagnósticos predictivos reconocen los estados iniciales de falla de futuros problemas en base a excepciones en los datos medidos u observados, aportando además las herramientas de diagnóstico para establecer la condición en maquinaria.
Sin embargo, no aporta información sobre cuando la problemática aparecerá (puede ser mañana o quizás en 6 meses).
- Los pronósticos, por el contrario, no sólo avisarán de la existencia de anomalías sino que nos avisarán de cuando se ha de prestar una mayor atención a la maquinaria.
Esto es así puesto que se analizará el
comportamiento histórico
de cada equipo, sin prestar atención a otras máquinas o a las especificaciones del fabricante.
Todo ello a través de la posiblidad de incluir en el software de mantenimiento:
- Datos Históricos de Producción
- Curvas de Operación y Rendimiento
- Ciclos de Fabricación
e incluso
INTERVENCIONES DE MANTENIMIENTO ya realizadas en el equipo.
En definitiva, que se lograrán mayores
Niveles de PrecisiónyFiabilidad;
para ello, se filtrarán todos los datos disponibles en base a ciertas rutinas y correlaciones previamente desarrolladas por programación del software de mantenimiento.
De ese modo, se logrará un perfil futuro de riesgos que ilustrará la probabilidad de mal funcionamiento futuro.
¿Qué necesitarán?
Pues simplemente una cantidad de datos suficientes:
- En relación a Operación
- (velocidad, temperatura, presión, …)
- En relación a Condición de la Maquinaria
- (datos de vibración, lubricación y temperatura en cajeras).
El espacio de tiempo (time span) que se precisa puede variar, si bien idealmente se precisaría entre 3 y 5 años de historia.
Lo importante es que los datos sean
necesarios y correctos para definir operación y condición de maquinaria en software de mantenimiento.
Pero, ojo, los sistemas permitirán seguir con nuestro
Mantenimiento Basado en la Condición,
es decir, seguir tendencias con el fin de evitar las intervenciones basadas en calendario, si bien añadiendo la coordinación casi automática con las necesidades de producción.
Pero la ventaja fundamental de estos nuevos protocolos de trabajo será el análisis de los diferentes escenarios futuros de operación por parte del software de mantenimiento, y la influencia que cada uno de ellos tendrá en la Vida Residual de cada Equipo al final del período de estudio.
De ese modo, se podrá coordinar la producción para minimizar sus efectos sobre este ese parámetro, clave en los niveles de costo en cada activo a controlar.
El artículo también incluye un
Ejemplo de Proyecto Piloto en una Central Hidroeléctrica,
realizado en una
Compañía Sueca
por la que se contrató a un proveedor específico con el que trabajó en el desarrollo de este software de mantenimiento para el análisis de los datos de vibración, temperatura y operación.
Para ello se estudió la relación entre esos datos de operación y las posibles anomalías que pudieran existir en maquinaria, orientando los esfuerzos finales al cálculo y pronóstico de mal funcionamiento, vía la definición de unos adecuados niveles de aviso y alarma.
Y se concluyó que vuestra operativa lleva a que
¡El TiempoVida es demasiado Corto!
Para solucionarlo se escenificaron diferentes escenarios de explotación para mejorar los modos de operar del generador, minimizando así sus necesidades de mantenimiento, aumentando fiabilidad y tiempo de vida útil.
Por supuesto, esta mejora llevó a puntos donde no se podía pensar con cualquier sistema de monitorizado de condición.
En resumen, con el sistema se llegó a concluir el modo de operación del equipo cara a optimizar los 3 siguientes aspectos:
- Extender el Período de Vida Útil.
- Minimizar los Costos,
- Información Específica sobre Fechas de Reemplazo de Ciertos Componentes.
Por supuesto, este modelo se extendió a otros equipos de similares características en planta
.
Artículo
finaliza mostrando las ventajas de este tipo de estrategias de pronóstico que no difieren en gran medida de las que pueden obtenerse por la aplicación de una estrategia de mantenimiento basado en condición.
Fin de traducción del texto
¿Realidad?
Esta, sin lugar a dudas; no tenéis más que consultar en cualquiera de las empresas punteras del sector en monitorizado de condición (por ejemplo, la empresa en la que trabaje Preditec) para comprobar que los
sistemas inteligentes
son el futuro en Software de Mantenimiento.
Ya en muchas de las entradas del portal, por ejemplo:
- en aquella que se mostraba un estudio con el Caudal de Bombas Centrífugas
- aquella otra con diferentes métodos de mantenimiento de Centrifugas de Cesta
se ven datos o formas de correlacionar históricamente operación y condición, algo que podría ser reproducible teóricamente mediante técnicas de programación informática.
Remarco el aspecto de teoría pues en realidad hay ciertos aspectos de la realidad nunca planteables en modelos informáticos, pero no este el objeto obviamente de esta entrada sobre software de mantenimiento.
Lo que sí os voy a mostrar en esta entrada son algunas
Ejemplo
que se estaban desarrollando en una empresa como Rockwell Automation, originariamente dedicada al control de procesos y en la actualidad diversificada hacia el monitorizado de condición mediante software de mantenimiento.
Se trataba de una de las prácticas realizadas en uno de los seminarios sobre sistemas que solían realizar (este concretamente de 3 días de duración).
El ejercicio consistía en
Maqueta de Control
de datos vibracionales y de proceso para un puesto en remoto (por ejemplo, una sala de control) utilizando como entradas:
Modulo de adquisición;
se trata de un sistema de registro y almacenamiento de datos de vibración (con diferentes posibilidades en su tratamiento), temperatura y datos de operación;
en este caso, el usado se llamaba XM.
Plataforma de Visualización de Datos Operativos;
programa de la misma compañía que permitía la interacción y comunicación de los datos operativos de planta,
de nombre Factory Talk,
XM
Elemento 1Maqueta.
Tenía su propio interfaz de comunicación donde se configuraba, además de la correspondencia entre máquinas y canales de medida, el momento de volcado de datos (para casos de descarga manual).
Así como la comprobación del correcto funcionamiento del mismo.
Ahora bien, se trataban de aplicaciones no integrables en windows, por lo que se debía utliizar una extensión de
Proyectos OPC,
que se trata de un standard de control de proceso industrial (OLE for Process Control).
Por eso, el software de mantenimiento para el control de las arquitecturas de módulos XM integraba una funcionalidad de trabajo con el OPC. Entrando en ella se debía definir:
- Canales (=Módulos) de medida a incluir en la Maqueta como una fuente de datos para OPC,
- concretamente la frecuencia y sincronización de los datos en la red de comunicación.
Nota: En este caso concreto estos adquisidores de medida se integraban en una red de datos DeviceNet que requería configurar frecuencias de comunicación entre el master y slave (terminología de protocolos de comunicación), así como el máximo número de paquetes en cada transacción.
Con posterioridad se establecía una
Red Cliente-Servidor
entre OPC (server) y el programa de control de módulos (client), con una red de nodos entre las diferentes medidas tomadas por el(los) adquisidor(es) XM.
Desde ese momento se establecía un vínculo entre el sistema DeviceNet y este interfaz de trabajo del OPC pudiendo visualizar en formato crudo cada una de las variables configuradas (por ejemplo en vibración archivos tipo WAV).
El eLEMENTO 2mAQUETA era
Factory Talk View Studio,
programa para la configuración de LAYOUT de planta.
Se debía entrar al sistema por
máquinas a configurar,
con posterioridad se accedía a una ventaja de trabajo en la que se crea una aplicación con un nombre identificativo, configurando entre sus propiedades la comunicación con el servidor OPC previamente definido.
Luego se configuraba LAYOUT desde librerías como:
- Croquis de elementos como
- bombas, tuberías, motores, ..
- Textos de Etiquetas, letreros, indicadores, … con el que leer valores o alarmas
Finalmente, desde la gráfica del equipo, o bien mejor por cuestiones de estética desde la botonera de etiquetas elegida
se vincula cada canal real con la con la arquitectura ya establecida en el Servidor OPC.
En todo momento se puede comprobar su correcta operación mediante las funcilonalidades de prueba existentes, …
Pero la gran utilidad de LAYOUT es la posiblidad de crear un
Archivo Real Visualización,
algo simple sin más que seguir las indicaciones del programa para crear un Real Time File, debiendo configurar ùnicamente la resolución gráfica del display elegido.
En definitiva, que tendremos una
archivo de panel view (o visualizador gráfico)
guardado en nuestro escritorio de trabajo, con acceso con un doble click para poder visualizar así las diferentes zonas de planta y sus niveles de operación.
Para que os hagáis una idea toda esta práctica se realizaba en media hora con un guía burros pues el seminario era fundamentalmente teórico.
En definitiva, ¿qué no podíais pensar que haría un software de mantenimiento computerizado a la carta para simular en lugar de una máquina, todas las de nuestra planta?
Pues auténticas virguerias, que duda cabe.
Infografía Resumen
En cualquier caso, yo os diría que estos software de mantenimiento son costosos.
Fíjate que el ejemplo mostrado se desarrolla en
Suiza millonaria
y es real, aunque piloto experimental.
Obviamente, las limitaciones y posibilidades de estos software de mantenimiento radican en la parametrización realizada a nivel de programación, es decir,
¿cómo se correlacionan las diferentes entradas y en base a qué criterios?.
Por ejemplo, los modelos de simulacion pueden resumir esa relación entre variables, si bien a nivel de secuencia de flujo, no a nivel de comportamiento de cada equipo.
Por eso resulta fundamental
Establecer un cómo
Poder Relacionar
variables de proceso y comportamiento de la máquina (mecánico – vibración, eléctrico – consumo, …).
A ese respecto el ejemplo de caudal de bombas centrífugas ya planteado resulta bastante esclarecedor, puesto que en base experimental se correlacionó:
- el caudal de operación (como una variable real de relevancia en operación)
con
- los niveles de vibración existentes (como variable real de fiabilidad mecánica, pero ojo no en relación al único modo de fallo).
Con todo esto siempre llegaríamos a una única
pregunta;
¿es realmente suplantable la capacidad analítica humana por este tipo de máquinas?
Pregunta de carácter mucho más profundo y que se extiende a otros muchos campos menos automatizables que la ingeniería.
Pero fijaros que ya a este nivel pueden surgir dudas sobre ¿suplen estos software de mantenimiento el 100% de las tareas humanas?
Pero bueno como podrás suponer este es el final del post y espero no haber caído en lo filosófico pues ya complicada es la ingeniería como para encima liarlo aún más.
Charge Time
El servidor de webempresa, donde alojo este dominio, versus 7 servidores worldwide y el kurtosis de sus tiempos de carga.
Porque el software de mantenimiento, como otros, fallaron con el cliente – servidor: arquitectura fallida como podéis ver:
Deja una respuesta