En la parte 1 y la parte 2 de esta serie de análisis de fallas, analizamos de dónde provienen las fallas y qué herramientas desea tener en su kit de herramientas para abordarlas. Ahora viene la parte difícil: poner a trabajar todas esas herramientas. En esencia, el análisis de fallos consiste en identificar qué conjunto de entradas causaron el fallo de una salida y qué acción correctiva desea tomar para solucionarlo. Por lo tanto, si hizo todo el trabajo duro para encontrar e identificar fallas, profundicemos en algunos pasos que puede seguir para comenzar su proceso.
Normalmente, encontrará fallos durante una compilación o en pruebas de fiabilidad y solo tendrá poco tiempo para encontrarlos y corregirlos. Cuando se dé cuenta del problema, hágase las siguientes preguntas para organizar sus pensamientos al realizar un análisis de fallas:
- ¿Qué es el modo de falla?
- ¿Cuán crítico es el fallo?
- ¿Es repetible el fallo?
- ¿Cuál es su hipótesis?
- hay otros factores potenciales?
- ¿Qué datos tiene?
- ¿Qué datos necesita?
- ¿Tiene alguna solución propuesta?
- ¿Tiene una forma de probar sus soluciones?
- ¿Su solución afecta a otro equipo?
- habrá consecuencias no deseadas?
Para ilustrar un análisis de fallos típico, analizaremos las preguntas anteriores en un escenario de ejemplo.
- EJEMPLO: Reloj de seguimiento de actividad física portátil
- ¿Cuál es el modo de fallo?
- ¿Cuán crítico es el fallo?
- ¿Es repetible el fallo?
- ¿Cuál es tu hipótesis?
- hay otros factores potenciales?
- ¿Qué datos tiene para el análisis de fallos?
- ¿Qué datos necesita para el análisis de fallos?
- ¿Tiene alguna solución propuesta?
- ¿Tiene una forma de probar sus soluciones?
- ¿Su solución afecta a otro equipo?
- habrá consecuencias no deseadas?
- Revisión de este ejemplo de análisis de fallos:
- Monitoreo de acciones correctivas
- Conclusión
EJEMPLO: Reloj de seguimiento de actividad física portátil
Se está evaluando un nuevo reloj de actividad física portátil en su versión EVT. Durante la construcción surgen algunos pequeños problemas, pero generalmente los dispositivos funcionan. Sin embargo, después de la compilación, se encuentra un fallo durante la prueba de caída. Así comienza el análisis de fallos.
¿Cuál es el modo de fallo?
A veces es fácil encontrar una falla, pero más a menudo, es posible que solo vea síntomas de una falla y no pueda estar seguro de cuál es la causa raíz en realidad. En nuestro ejemplo de reloj, encontramos que un evento de prueba de caída hace que la pantalla falle en 6 de cada 10 dispositivos probados. Lo que sabemos es que algo salió mal con la pantalla después del evento de caída, pero aún no sabemos por qué ocurrió el fallo. Comenzamos examinando en qué estado se encuentra el dispositivo.
- ¿El modo de fallo se presenta de la misma manera en los dispositivos fallidos?
- Si hay diferentes tipos de fallos de visualización, el evento de eliminación puede haber expuesto varios modos de fallo, cada uno de los cuales podría tener una causa raíz ligeramente diferente.
- ¿La pantalla se volvió blanca?
- hay líneas en ciertas filas o columnas?
- ¿Se rompió la lente de la cubierta?
- ¿Se rompió la pantalla?
- el resto del dispositivo parece estar funcionando? – ¿Carga, motores, tacto, etc.?
- ¿cuáles fueron las pruebas específicas que falló?
- ¿Desde qué altura se cayó el reloj?
- ¿En qué sustrato se cayó el dispositivo?
- ¿En qué orientación se produjeron los fallos?
- ¿Hay otros problemas obvios que puedan observarse?
- ¿hay algún daño mecánico en el perímetro del dispositivo?
Después de un cuidadoso interrogatorio de las muestras, encontramos que 4 de las 6 fallas provenían de pruebas realizadas en un sustrato de granito y 2 provenían del sustrato de tableros de partículas, todo caído desde la altura de la mesa de 1 metro. En 5 de los fallos, la pantalla se vuelve blanca y no responde. En el sexto fallo, la lente de la cubierta se agrietó, pero aún mostraba imágenes. En 2 de los dispositivos, podríamos ver algunas marcas de arañazos en la lente de la cubierta, y en 3 de los dispositivos, hay algunos arañazos en la carcasa en un borde.
¿Cuán crítico es el fallo?
Las fallas varían en gravedad de baja a alta y muchos niveles intermedios. A veces, lo que parece ser un problema menor se convierte en algo más grande. Un wearable típico será usado y abusado por su propietario. Cada vez que el usuario se quita el reloj es una oportunidad potencial para un evento de entrega. En este caso, un fallo de caída en el que la pantalla no responde parece un problema crítico a resolver. Una pantalla que no respondiera haría que el dispositivo fuera inutilizable y daría lugar a una alta tasa de retorno y a clientes insatisfechos. Este problema merece atención y debe resolverse antes de que el programa pase a los siguientes pasos.
¿Es repetible el fallo?
La repetibilidad significa que el mismo proceso puede inducir un fallo de forma consistente. Para el portátil, 6 de cada 10 dispositivos fallaron y 5 de esos 6 de la misma manera. Esto sugiere que una falla era repetible y la falla restante era probablemente un problema único que deberíamos monitorear pero no abordar en este momento. Aún así, necesitamos averiguar si el problema de la pantalla que no responde es verdaderamente repetible profundizando un poco en los datos.
- ¿El error se produce en la misma orientación de caída?
- Las secuencias de prueba de caída generalmente se realizan de la misma manera cada vez. Podría comenzar con la cara frontal, luego la cara posterior, luego las 4 caras laterales, luego las esquinas. Si la caída de la cara frontal siempre causa el problema, no está claro si la falla se debe a la orientación particular de una caída de la cara frontal o si el problema se produciría a partir de cualquier caída a la misma altura.
- Para combatir esto, haga que el equipo de confiabilidad pruebe más unidades usando una secuencia diferente o colocando la orientación fallida en último lugar.
- ¿Todas las unidades fallidas tenían la misma cascada de pruebas de confiabilidad antes de la falla?
- En un buen plan de pruebas de confiabilidad, las pruebas ambientales a menudo se realizan primero para precondicionar los dispositivos. Algunos se someterán a pruebas de calor en remojo o ciclos de temperatura que pueden impactar el sistema o debilitar las uniones adhesivas.
- Si la falla ocurre en unidades nuevas y en unidades preacondicionadas, entonces la falla parecería ser un problema localizado. Si no es así, es posible que necesitemos comprender a qué condiciones se expuso el producto antes de la prueba de caída.
¿Cuál es tu hipótesis?
Para nuestro reloj, puede haber 2 o más problemas subyacentes. La primera es que la pantalla se vuelve blanca y no responde. Podríamos inferir que se ha cortado la alimentación del sistema, lo que indicaría un problema con la pantalla en sí, el conector de la pantalla, o un pinzamiento mecánico o desgarro en el cable de la pantalla. Como alternativa, la conexión a la batería o a la administración de energía puede provocar un error en el dispositivo.
hay otros factores potenciales?
A menudo, las fallas difíciles tienen muchas causas que dificultan identificar claramente dónde enfocar su tiempo. Si tiene problemas con sus hipótesis iniciales durante el análisis de fallas, haga una lluvia de ideas con una lista de posibles áreas para investigar.
En el wearable, la construcción EVT es la primera vez que armamos algo. A menudo, los subcomponentes como el módulo de visualización y otros componentes principales se fabrican con parámetros que aún no están finalizados. Como tal, los conectores, la pantalla o el conjunto mecánico podrían contribuir al fallo de la pantalla.
Para descartar otras fuentes de error, es posible que necesitemos clasificar los parámetros del proceso de fabricación, los datos de medición y las fotos de ensamblaje. Es posible que necesitemos profundizar en nuestros proveedores iniciales para buscar información adicional. Para este ejemplo, supongamos que la pantalla fue un componente estándar en producción durante mucho tiempo, lo que sugiere que no se producirán cambios importantes en la pantalla y que debemos centrarnos en el diseño mecánico.
¿Qué datos tiene para el análisis de fallos?
En la falla de confiabilidad del wearable, debemos recopilar toda la información disponible a la que tenemos acceso que pueda ayudarnos a verificar nuestras hipótesis. Dado que la falla ocurrió durante una prueba mecánica, debemos comenzar inspeccionando físicamente las unidades fallidas y revisando las fotos de antes y después y el video de alta velocidad de la prueba, especialmente en la orientación de la falla.
Estamos buscando deformaciones o roturas obvias. Si es posible, deberíamos inspeccionar algunos de los dispositivos fallidos y abrirlos para ver si podemos encontrar algo malo en el interior. Las fotos de antes y después de las unidades nos mostrarán si había algo obviamente mal con el ensamblaje antes de la entrega. El vídeo de alta velocidad nos permite observar la compresión y el estiramiento del material que ocurre en un abrir y cerrar de ojos. Si la pantalla y la carcasa se mueven en direcciones opuestas después del impacto, puede haber algo que valga la pena investigar más a fondo.
Además, desearemos revisar el informe IQC en los módulos de visualización y los informes FAI / Cpk de medición de las partes principales del conjunto, incluida la carcasa mecánica. Estamos analizando cómo se comparan las piezas reales con las dimensiones y tolerancias que utilizamos en nuestros análisis de tolerancia iniciales.
Si combinamos estos conjuntos de datos, deberíamos ser capaces de refinar nuestra hipótesis inicial y pensar en qué datos nos faltan a medida que continuamos nuestra investigación de análisis de fallas.
¿Qué datos necesita para el análisis de fallos?
Aunque tenemos acceso físico a los dispositivos, todavía no sabemos qué está mal hasta que desmontamos los dispositivos. Cuando abrimos 3 relojes, descubrimos que los conectores de placa a placa en 2 de 3 se habían soltado. El último, no pudimos desmontarlo correctamente y no pudimos saber cuál era el estado del conector. Pero como 2 de los que abrimos mostraban el mismo problema, querríamos explorar por qué el conector se soltó.
Queremos revisar nuestras simulaciones para centrarnos en las fuerzas experimentadas por el conector y otros componentes de acoplamiento. También debemos revisar la especificación del conector para la retención de fuerza y verificar de forma independiente que los conectores de estas pantallas y la placa de circuito principal cumplan o excedan la especificación. También es posible que el proveedor haya utilizado una versión de bajo costo del conector o incluso el conector incorrecto por una variedad de razones, por lo que desearemos verificar los códigos de lote y los números de pieza del conector.
Es posible que necesitemos probar más dispositivos para ver si diferentes proveedores de pantallas u otras configuraciones funcionan de la misma manera.
¿Tiene alguna solución propuesta?
En nuestro wearable, nos hemos reducido en el conector de pantalla y el conjunto mecánico que lo rodea como un área de interés. El equipo pasó algún tiempo analizando el montaje y propuso algunas soluciones. Estos incluyen:
- Agregar un pequeño trozo de espuma compresible sobre el conector para ocupar el espacio de aire entre el conector y la carcasa principal.
- Usar una resina epoxi en el conector una vez que esté en su lugar.
- Agregar un soporte de metal y algunos tornillos para fijar el conector de forma segura en su lugar.
- Cambiar el conector en la pantalla FPC y la placa.
Cada una de estas soluciones tiene sus pros y sus contras y requeriría trabajo adicional para probarlas. Podemos eliminar la opción 4 después de que el equipo de operaciones nos diga que la pantalla es un componente estándar y que los costos y los plazos de entrega aumentarían significativamente si nos mudáramos a un nuevo conector.
Las soluciones mecánicas requieren cambios de diseño y montaje que también pueden tener efectos posteriores potenciales en el rendimiento mecánico y eléctrico.
Con la solución de espuma, debemos revisar el tamaño de la brecha en la condición nominal, así como en la condición de prueba de caída para seleccionar un material apropiado. Si la espuma también presionará la parte inferior de la pantalla, debemos asegurarnos de que no empuje demasiado fuerte por detrás para distorsionar la pantalla.
La solución epoxi podría ser una solución rápida, pero podría abrir una lata de gusanos sobre las configuraciones del proceso y las opciones de materiales. Además, una vez que un componente se ha epoxiado, es casi imposible volver a trabajar, lo que significa que una vez que se realiza este paso en la línea de ensamblaje, si algo sale mal posteriormente, es posible que sea necesario desechar todo el ensamblaje.
Con el soporte de metal, necesitaríamos encontrar el espacio para sujetar el soporte y asegurarnos de que no haya problemas de cortocircuito. Si lo fijamos con tornillos, el enrutamiento de la pantalla se volverá más difícil, ya que es probable que haya muchos rastros en el camino.
¿Tiene una forma de probar sus soluciones?
Dos de las soluciones pueden ser fáciles de crear prototipos: la espuma y el epoxi. Sin embargo, ambos vienen con algunos riesgos, especialmente después de que se haya completado la construcción. Necesitaríamos desmontar algunos dispositivos para agregar espuma o epoxi. Durante el desmontaje, siempre existe la posibilidad de que podamos introducir otro problema más relacionado con el proceso de montaje incontrolado que la opción que estamos tratando de investigar. Sin embargo, si los prototipos son prometedores, esta sería una forma rápida de ganar confianza en una solución.
El soporte metálico podría simularse en CAD o aproximarse con algunas piezas mecanizadas, pero sería difícil de adaptar funcionalmente en la carcasa existente. Debido a que la placa tendría que ser modificada para acomodar los jefes de tornillo y la propia placa necesitaría agujeros perforados a través de ella, es poco probable que se pueda hacer un prototipo funcional antes de la próxima construcción. Así que, en su lugar, podríamos confiar en la combinación de una maqueta mecánica y simulaciones para aproximar el rendimiento del cambio de diseño.
¿Su solución afecta a otro equipo?
Todas las correcciones para el impacto portátil en otros equipos. Lo menos perjudicial para los demás probablemente sería agregar espuma detrás del conector. Esta es una opción fácil de probar y solo requiere cambios mínimos o evaluación por parte de otros equipos. Al mismo tiempo, no está claro si la espuma será suficiente para evitar que el conector se suelte. Además, si la espuma ejerce demasiada fuerza en la pantalla, podría funcionar en nuestra contra al servir como punto de presión en la pantalla durante un evento de caída o dañarnos al empujar hacia arriba la pantalla y exponer los bordes de la lente de la cubierta a grietas de araña.
La solución epoxi requeriría una inversión en el proceso de ensamblaje para garantizar que el epoxi se pueda dispensar correctamente. Los procesos de pegamento líquido son notoriamente difíciles de finalizar, por lo que, aunque valga la pena crear prototipos, esperamos no usar esta opción. Además, habría un impacto en el costo del producto, ya que la pérdida de rendimiento probablemente será mayor y la reelaboración será más difícil.
El soporte de chapa metálica tardará más tiempo en implementarse y requerirá que los equipos eléctricos vuelvan a diseñar las trazas de la placa. Además, necesitaríamos evaluar si el blindaje metálico causaría radiación no intencional o interferiría con las señales inalámbricas en el producto.
habrá consecuencias no deseadas?
Al hacer cambios de diseño para solucionar un problema, es fácil quedar atrapado en el problema que está tratando de resolver y es posible que se olvide de evaluar el diseño para ver qué más podría salir mal. En este ejemplo, es posible que al hacer agujeros en la placa de circuito impreso y atornillar un soporte sobre el conector, esta área de la placa se debilite y, en lugar de que el conector se suelte durante una prueba de caída, la placa en sí se rompa causando un fallo mayor que el que pretendíamos resolver.
Revisión de este ejemplo de análisis de fallos:
A través del proceso de revisión de los datos disponibles, creación de hipótesis y pruebas, hemos encontrado la causa raíz potencial del problema. Sospechamos que el conector experimentó más fuerza de la nominal y, debido al espacio de aire diseñado entre la parte superior del conector y la carcasa, se aflojaría durante el evento de caída cuando el espacio de aire se agrandara temporalmente. Para solucionar este problema, hemos identificado 3 posibles soluciones para probar e implementar. El camino que elijamos seguir depende de qué tan bien funcionen las soluciones y cómo impacten potencialmente en el calendario y los costos del proyecto.
Monitoreo de acciones correctivas
Una vez que se haya elegido un curso de acción, el equipo no solo tendría que pasar por el proceso de hacer los cambios de diseño, sino que tendría que desarrollar un plan para implementar y monitorear las soluciones en la siguiente compilación.
Para preservar la opcionalidad, el equipo podría decidir seguir adelante con el cambio de diseño para agregar el soporte y también preparar la espuma. Esto implicaría el pequeño golpe de horario requerido de un cambio de herramienta y trabajo de diseño para el equipo eléctrico, pero proporcionaría la opcionalidad de probar múltiples soluciones durante la compilación, con la esperanza de limitar el número de compilaciones de EVT adicionales a solo una.
Sabiendo que hay una vulnerabilidad importante que probar, el equipo puede organizar la compilación para priorizar la recopilación de datos para este problema. Esta estructura podría incluir configuraciones de solo espuma, solo el soporte de metal y una que incluya la espuma y el soporte juntos.
Antes de la construcción, el equipo podía realizar un nuevo FMEA y predecir dónde podrían surgir problemas potenciales de los nuevos diseños. Utilizando el FMEA como punto de partida, el equipo podría organizar más pasos de comprobación en las transformaciones críticas donde se implementan los cambios. También se debe alentar a los ingenieros in situ a prestar atención cuidadosa a la construcción en estos pasos.
Por ejemplo, el equipo debe observar lo difícil que es montar el nuevo soporte. Este cambio de diseño puede requerir plantillas nuevas o actualizadas para colocar la pieza correctamente sin dañar los componentes cercanos. Además, los bordes afilados del soporte en sí podrían dañar el cable flexible durante el ensamblaje o las pruebas de confiabilidad, por lo que debemos verificar los resultados de la estación de prueba funcional con anticipación para detectar cualquier signo de caída del rendimiento.
Finalmente, debemos organizar que el primer lote de dispositivos de la nueva construcción se asigne para pruebas de confiabilidad. Podemos trabajar con el equipo de confiabilidad para determinar cuántas unidades necesitaríamos probar y aprobar para sentirnos seguros de nuestra solución. Mientras la compilación está en curso, podríamos obtener una imagen más clara de si una o más de las configuraciones resuelven el problema mientras nos aseguramos de que no surjan nuevos problemas.
Conclusión
El ejemplo wearable muestra que incluso en problemas relativamente sencillos, hay muchas cosas a considerar durante el análisis de fallas. Los informes de fiabilidad, los dispositivos físicos, los datos de compilación e incluso los datos de los proveedores de upstream ayudan a llenar los vacíos mientras tratamos de entender qué salió mal y cómo solucionarlo.
En programas reales, los ingenieros se enfrentarán a muchos problemas diferentes y tendrán que resolverlos todos en paralelo. A menudo, hay poco tiempo para realizar análisis profundos de todos los problemas antes de la siguiente compilación. Por lo tanto, es importante eliminar los pequeños problemas rápidamente para que puedan centrarse en los desafíos críticos con una arquitectura determinada. Cualquier herramienta que pueda ayudar a los ingenieros a recopilar y conectar conjuntos de datos dispares es inmensamente útil para identificar las causas raíz potenciales y resolver más problemas en la misma cantidad de tiempo. Una vez que se haya encontrado una solución, se analizará el costo, la velocidad y la facilidad de implementación y todos tendrán una opinión diferente sobre cuál será el mejor curso de acción. Incluso después de que se ha encontrado la causa raíz y se ha propuesto una solución, esto solo establece una nueva línea de base a partir de la cual pueden ocurrir fallas. La prueba real será en la próxima compilación porque podría estar introduciendo una serie de consecuencias no deseadas. Este proceso se repite hasta que se te acaba el tiempo o en un mundo ideal, resuelves todos los problemas.
Instrumental ha creado un conjunto único de herramientas para reducir la fricción involucrada en cada paso del análisis de fallas. Al recopilar datos de productos y ejecutar imágenes a través de inteligencia artificial, podemos encontrar posibles anomalías antes de que sea demasiado tarde para detenerlas. También podemos almacenar y rastrear datos importantes en nuestra Plataforma de Optimización de fabricación, agregando correlaciones entre los datos de pruebas fallidas y la información de ensamblaje del producto. No solo estamos reduciendo el tiempo y el esfuerzo dedicados a pequeños fallos, sino que también estamos recopilando y transformando datos para resolver los grandes problemas y, en última instancia, mejorar los productos. Póngase en contacto con nosotros para obtener más información sobre cómo podemos ayudarle a mejorar su proceso de análisis de fallos.