Artículo redactado por Alejhandro Navarro, colaborador de Revista de Robots
Alejhandro Navarro es un ingeniero Mecánico con postgrado en Mecatrónica, autor del libro “Robot industrial, Manual de instalación” y actualmente forma parte del equipo de Mecatrónica de Ubyko
Para muchos lograr un diseño a prueba de fallas es algo utópico, para nuestros clientes debería ser al menos el objetivo (es lo que desean y pagan para obtener ese resultado). He aquí la diferencia entre solo ejecutar un proyecto a un cliente o varios.
¿Cómo logramos un sistema realmente robusto?
Algunos podrían pensar que se requiere sobredimensionarlo y otros que es necesario un exhaustivo proceso de testeo y validación. Aunque estas alternativas no son malas ideas, muchas veces la solución es más económica y fácil.
Los diseñadores disponemos de avanzados programas informáticos que nos ayudan a evaluar, simular y hasta predecir el comportamiento deseado de nuestra solución, permitiéndonos asegurar que nuestro diseño es seguro, pero evaluamos el equipo/sistema/producto funcionará bajo el procedimiento de trabajo establecido; ¿Qué pasa cuando el usuario no cumple, no automconoce o simplemente quiere utilizar de otra forma el producto? Los resultados normalmente pueden ser nefastos.
En el mundo informático es frecuente que el personal de QA (Quality Assurance)sea el más odiado o por lo menos el que más retrabajo nos genera. Normalmente si eso sucede debido a que están haciendo correctamente su trabajo, y es que ellos tienen que ver y testear no solo cómo fue ideado, sino bajo todas las variables posibles y garantizar que no existe la posibilidad de que falle.
No importa el sector, siempre en la etapa de ingeniería debe de llegar al momento de evaluar nuestro proyecto con “¿Qué pasa si?”, y es que debemos buscar y analizar todas las posibilidades de ocurrencias y efectos que se le pueden presentar a nuestro proyecto, no sólo a las circunstancias típicas para las que fue diseñado, sino ante cualquier posible acción.
En el mundo de la Robótica y Automatización podemos cumplir dos metodologías muy sencillas que nos aseguran evaluar desde diferentes perspectivas la solución.
El AMEF (Análisis de Modo y Efecto de Fallas) es un proceso muy sencillo muy extendido en el mundo de la automoción al ser una de las técnicas Lean. Existen tres tipos de AMEF:
- Sistema: Asegura la compatibilidad de los componentes del sistema
- Diseño: Reduce los riesgos por errores en el diseño
- Proceso: Revisa los procesos para encontrar posibles fuentes de error
El AMEF es un procedimiento para evaluar cada ítem desde la perspectiva de cómo podría fallar, si falla qué efecto causaría y cuál podría ser la causa. Luego definir las posibilidades de que suceda el fallo (esta podría ser la etapa más complicada del proceso porque se debe revisar las estadísticas o estimar la ocurrencia), es decir si ha ocurrido, si es repetitivo… Lo siguiente es establecer la severidad de que ocurra este fallo, si sólo afecta a un elemento o a toda la solución y sus consecuencias finales. Por último si la solución tiene alguna forma de detectar ese error y si tiene forma de prevenir, cada uno de estos elementos son ponderados a fin de establecer criticidad y relevancia.
La clave del AMEF es evaluar cada parte del producto/sistema/proceso sin obviar nada o disminuir su valor e importancia, buscando siempre ser sinceros, porque está demostrado que las grandes fallas vienen de pequeñas cosas que todos asumen que estaban evaluadas y controladas.
A nivel electrónico tenemos el procedimiento de GEMMA (Guide d’ Etudes des Modes de Marches et d’ Arrêts), el cual nos establece los pasos que debemos evaluar cuando estamos desarrollando cualquier programa de automatización. La tendencia es que hacemos el programa solo pensando en la rutina normal de proceso, pero se obvia una gran cantidad de circunstancias típicas de cualquier proceso de automatización como lo pueden ser:
- ¿Qué ocurre si se acciona una parada de emergencia?
- ¿Qué ocurre cuando se desactiva la parada de emergencia?
- ¿Qué ocurre si se va la energía del sistema y qué ocurre cuando vuelva?
Estas y otras tantas situaciones son típicas de un proceso, que las evaluamos cuando diseñamos el sistema porque de hecho colocamos las paradas de emergencias, pero por alguna razón la gran mayoría de los programadores no generan las rutinas cuandos estos eventos ocurren.
GEMMA nos asegura que, si vamos evaluando nuestro programa por cada uno de los puestos o etapas, el resultado será un programa robusto, ¡a prueba de fallas!
Como conclusión podemos extraer que, a pesar de que en la actualidad disponemos de valiosos softwares que nos permiten evaluar y simular cada elemento del diseño, no nos exonera de utilizar un procedimiento de evaluación de la funcionalidad y en ellos ser metódicos para lograr la confiabilidad.
Artículo redactado por: Alejhandro Navarro
Otros artículos de interés: