Aparece el primer apunte, esta semana sobre las posibilidades que ofrece el coeficiente de curtosis para el filtrado y análisis de datos, y otra tira cómica, en este caso con una tensa situación ante un diagnostico de mantenimiento (palabra que intento posicionar con esta entrada).
Con esta entrada lanzamos el segundo boletín, con el verano aquí mismo, pero con actividad en el sector.
Gestión de Activos
El congreso se celebrará los próximos 25 y 26 de Junio el argemant, evento sobre mantenimiento y gestión de activos, en la universidad tecnológica nacional de Buenos Aires. (todavía se sigue celebrando en 2026 cuando actualizo esta entrada desde 2015).
A nivel personal indicaros que me resultan de particular interés las siguientes:
Management Centrado en la Confiabilidad
Desafíos de diagnostico de Mantenimiento en PYMES
Ciclo de Vida del Lubricante y su Aporte a la Confiabilidad de los Activos de la Empresa
Uso Eficiente de Vapor y recuperación de Condensados para el ahorro Energético y la Optimización de Procesos
Maximización de la Productividad Laboral
Habilidades y Competencias para la correcta aplicación del Monitoreo de Condición
Benchmarking Multisectorial de Indicadores
Diagnostico por Vibraciones
La popular compañía Crystal Instruments ha lanzado un sistema de control por vibraciones, con conexión en sincronismo con la red ethernet.
Es habitual que estas redes funcionen con protocolos de maestro-esclavo por lo que siempre existe cierto asincronismo en la conexión de datos. No así como veréis con el protocolo cliente-servidor, fallido según mi criterio y formación (véase final de la entrada con gráfico de curtosis).
Con este avance se logran ventajas a nivel de:
Posibilidades de Control
Protección por Vibraciones
De manera secundaria, permite una configuración de un gran número de canales sin perjudicar al rendimiento.
Se trata de una herramienta interesante para el predictivo pues permite afinar el diagnostico de mantenimiento.
Espero os resulte de utilidad. Es breve, pues es el primer apunte que se suministra en el blog: únicamente 2 páginas.
No será un elemento habitual en las entradas pero sí existe una tira cómica porque es realmente difícil el
Diagnostico de Mantenimiento.
Se trata de una situación real vivida como responsable de un cliente papelero.
Se trata de un día que falté a la oficina por baja médica y surgió una emergencia en el programa de mantenimiento basado en vibración de uno de los clientes por la existencia de niveles inadmisibles en un ventilador de alta criticidad.
En la situación participó:
Analista de Mantenimiento Predictivo
especializado en Inspecciones de Termografia y Ultrasonidos, el único por allí en ingeniería aquella mañana.
Tipo con muchos años en el departamento y más que harto de situaciones como las que os describo a continuación. Pero no hábil con el diagnostico de mantenimiento.
Responsable de Taller Mecánico
de reputado prestigio en el sector, pero un mecánico de mantenimiento hecho a sí mismo desde que empezó de aprendiz, posteriormente técnico, supervisor y finalmente director técnico.
Se trataba además de uno de los accionistas de la compañía.
Escéptico por naturaleza ante la aplicación de técnicas y métodos de ingeniería, siempre recordaré frases como:
«Cuando estoy ante una máquina sé lo que le pasa de inmediato, no me hace falta medir ni vibración ni ultrasonidos para hacer diagnostico de mantenimiento. La prueba es que más de una vez ha venido a felicitarme el director de la empresa por mis trabajos. Yo aprovecho y me voy con él, le invito a un par de cervezas, apalabro un par de pedidos y tras un buen trabajo, de vuelta para Madrid.»
Controller.
Su función era el control presencial de recursos humanos, gestión administrativa y de viajes, apertura y cierre de la oficina.
También realizaba funciones de responsable financiero.
Ingeniería (IN)
En este contexto, este departamento:
Lanzaba las ordenes de trabajo
basadas en el resultado de las inspecciones de control, y cuando el cliente lo estimaba oportuno bien por la severidad del problema bien porque podía realizar la reparación en ese momento, nos demandaba un servicio de taller y su personal iba a realizar la intervención.
Supervisaba y Verificaba la Corrección en Mantenimiento,
a nivel de diagnostico, pues taller asumía la responsabilidad de dar el OK ante cualquier nivel de vibración; tenían formación básica en vibraciones.
Evidentemente, esto generaba problemas cuando tras una reparación los niveles no eran los deseados, pues no se podía dar por finalizado el trabajo y se generaba una no conformidad.
El problema que hay en Predictivo es que en el informe centras la recomendación sobre el problema principal del equipo, máxime los 2 principales, y cuando vas a realizar la intervención debes controlar más aspectos. Taller se puede quejar, pero en definitiva si tienes limitaciones en las herramientas usadas para el diagnostico de mantenimiento eso se traduce en deficiencias en la programación de los trabajos.
Taller (TL)
Se dedicaba con plena autoridad a la reparación de maquinaria debiendo seguir el protocolo realizado por ingeniería para la verificación de la condición; ahora bien, los que habéis reparado máquinas sabéis que:
vas a hacer esto y te encuentras con que tienes que hacer eso y 4 cosas más.
El problema existe cuando tras la reparación y verificar los niveles de vibración estos son inaceptables, por errores en diagnostico de mantenimiento.
Por tanto:
Había tensión entre Predictivo y Taller,
positiva al generar una sana competitividad.
Controller (CT)
Su posición era complicada puesto que debía actuar de manera imparcial tratando de imponer algún tipo de consenso basado en los objetivos que maneja en su área de responsabilidad como nivel de facturación mensual o departamental, situación de pagos o perfil histórico de la cuenta, …. .
Incluso en muchos casos debía actuar en base a criterios puramente personales de prestigio de cada uno de los interlocutores implicados.
Vaya «Marrón» que tienes delante, controller
Cliente (CUSTOMER)
Este solo tiene un objetivo que es:
subsanar el problema detectado con diagnostico de mantenimiento
preferiblemente con el menor tiempo y costo posible.
Comienza tira cómica
CT
Han llamado de la papelera para hacer un DIAGNOSTICO DE MANTENIMIENTO.
Hoy no puede venir Rubén por baja, por lo que has de planificar el trabajo; dice el cliente que ha enviado los datos a su correo electrónico.
IN
Pero yo no tengo acceso a su correo y no sé la contraseña de su PC ni de su CORREO. ¿Te han comentado cuál era el problema CT?
CT
Llámales por teléfono y que te digan. Ahora, sí que te digo que hay que ir para allá pues se necesita facturar ESTE DIAGNOSTICO DE MANTENIMIENTO.
IN
Buenos días papelera, ¿podéis indicarme cuáles son los datos más significativos para la alarma?
CUSTOMER
La máquina vibra al 1x SEGÚN DIAGNOSTICO DE MANTENIMIENTO. Las lecturas salen 5 veces más de lo habitual. Queremos equilibrar.
IN
No es la mejor práctica esta urgencia para los trabajos; te sugeriría que me mandarás los espectros para realizar un diagnóstico más detallado.
CUSTOMER
Producción se ha enterado del problema y están que crujen, venir para acá y a ver si podemos llevar el equipo a los niveles que tenía con anterioridad. Ya tenemos personal de apoyo para el trabajo.
IN
Ok, te mando un técnico del taller inmediatamente.
(dirigiéndose a taller)
¡TL, hay que mandar a alguien a equilibrar a la papelera!
TL
¿Qué? Ahora les tengo ocupados en otro tema. ¿Qué datos tienes DEL DIAGNOSTICO DE MANTENIMIENTO? ¿Qué equipo nos llevamos para el trabajo? Por cierto, ¿dónde está Rubén?
IN
¿Datos? Ninguno, todo esto me llega de terceros, el equipo vibra como un caballo. Todo está dispuesto, llévate el 246 y todo lo demás corre de tu cuenta, pues tendréis apoyos del personal de fábrica.
TL
Siempre igual, esto es un cachondeo. Ahora nos tenemos que meter 15 kms para el cuerpo hasta la planta, llegar allí corriendo, hacer un trabajo contrarreloj. Lo que no sé es porque siempre nos pasa esto a nosotros. Como sigamos así nos vamos a pique.
Ahora mando para allá a Julio; YO NO VOY SIN SABER DIAGNOSTICO DE MANTENIMIENTO.
IN
Esto es lo que hay, tratar de hacer un trabajo aceptable y no olvidéis tomar las lecturas tras el trabajo.
Sale un Técnico de taller para la papelera,
y a las 4 horas llama por teléfono a ingeniería:
customer
Oye, esto un desastre, han equilibrado la máquina y está peor que antes. Dicen que el problema puede ser alineación.
IN
No tengo los datos, pero me fío del criterio de Julio. No se va a solucionar el problema equilibrando.
CL
Pero si toda la vibración es al 1x y en radial. Esto es desequilibrio seguro.
IN
Que se vengan para la oficina, analizamos los datos y te decimos como proceder. Esta conversación ya no lleva a ningún sitio.
Ha habido un error en diagnostico de mantenimiento.
Los datos se analizan en la oficina
y se concluye que:
IN
La máquina se ha de alinear de manera previa al equilibrado, pues existen síntomas de vibración mejorable fundamentalmente en axial.
Además no descartamos una problemática de vibración en resonancia.
CUSTOMER
Pero bueno, esto es un tremendo problema pues nos toca parar la máquina mañana también. ¿Estás seguro al 100% DEL DIAGNOSTICO DE MANTENIMIENTO?
IN
Seguridad nunca se tiene al 100% con una medida de espectro nada más.
Te recomendaría realizar un ensayo ODS para valorar el modo de vibración que presenta la máquina en resonancia.
Así matas 2 pájaros de un tiro, eliminas esa posibilidad y, por otro lado, ganas seguridad en el diagnOstico de desalineación.
customer
Me parece bien. Oye, saluda al técnico que ha venido por aquí; vaya bronca que le ha caído y el fallo ha sido nuestro. No se puede actuar con tanta precipitación.
El diagnostico de mantenimiento debe ser paciente.
IN
Totalmente de acuerdo, y tranquilo por Julio. Es un tío curtido en mil batallas, seguro que entiende la situación, aclararlo con él y decirle que se venga de vuelta para la oficina.
Al día siguiente se realizó el trabajo y se concluyó que existía un
problema estructural,
por falta de rigídez, apareciendo un fenómeno de resonancia. Se recomendaba rigidizar la bancada en base a la modelización ODS realizada y posteriormente alinear el equipo.
Día a día en tú empresa?
Seguro que has vivido algo similar, pues esto pasó en una empresa de ingeniería.
Evidentemente se trata de algo ocasional, una coincidencia que he vivido sólo una vez en mis 15 años de experiencia: enfermedad en el responsable de una cuenta, y problema serio en un equipo crítico.
Afortunadamente, la planta estaba en Madrid y el desplazamiento se podía realizar en coche.
En cualquier caso de lo anterior se deben sacar las siguientes conclusiones más allá de posibles situaciones azarosas:
El diagnostico de mantenimiento es una función empresarial con entidad propia, nunca un servicio de reparación de maquinaria.
Una mentalidad reactiva no garantiza eficiencia alguna en producción, pues los tiempos de parada siempre son mayores que ante cualquier situación adecuadamente planificada.
Ambas situaciones, daros cuenta, no fueron subsanables pese a contar con una adecuada
Organización
de Recursos Humanos y Procedimientos,
puesto que:
El analizador de vibración y Equilibrador sale de una hoja de almacén automáticamente generada por el controller, que se «gana bien la vida»
El Técnico que va a equilibrar tiene años de experiencia; pese a que no vaya el más competente del taller, director técnico.
Se Dispone de las herramientas adecuadas para realizar el trabajo.
Pero bueno, como te digo afortunadamente todo quedó en eso y el caso fue todo un éxito.
Kurtosis de tiempos
curtosis con «c» en español, o como anglicismo con «k». El protocolo cliente-servidor es preocupante como ya se dijo en el texto previo:
La arquitectura cliente-servidor proporciona errores; por ejemplo estar trabajando y cerrarse el programa por sí solo. Muchos usuarios prefieren trabajar en arquitectura monopuesto. Con el tiempo las redes DEVICENET han sustituido a estos protocolos, que por el error pueden considerarse arcaicos como pasa cuando se trabaja con información de responsabilidad como en mantenimiento predictivo. De hecho los datos crudos de señal recolectados por los hadware de tecnología son directamente llevados a buses de datos. En el termino de bases de datos existe un progreso lento en esa evolución pues las redes DEVICENET no permiten trabajar de modo simultáneo con varios puestos de trabajo (arquitectura S/M SLAVE – MASTER en terminología FRIKI). PoR TANTO SE prefiere aún las arquitecturas cliente – servidor pues los errores se producen muy de vez en cuando; y lo otro (el no trabajar al mismo tiempo con varios puestos de trabajo) es un problema continuo.
Web que usa cookies para mejorar la experiencia de usuario. Se supone que estás de acuerdo, pero puedes cancelar esta opción. AceptarCancelarLeer más
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
Management Centrado en la Confiabilidad
Deja una respuesta