Cómo la planificación DFT mejora la eficiencia de depuración y pruebas de PCBA

Una PCBA se puede ensamblar correctamente y aun así ser difícil de probar.

Ahí es donde importa la planificación DFT.

El diseño para la capacidad de prueba, o DFT, no se trata solo de agregar más puntos de prueba a un diseño de PCB. En un proyecto PCBA real, la planificación DFT decide si la placa ensamblada se puede alimentar, programar, probar, medir, depurar, reelaborar, volver a probar y liberar en condiciones prácticas de fabricación.

Una prueba de pasa/falla le dice al equipo si un tablero funciona.

Un buen plan DFT ayuda al equipo a comprender dónde buscar cuando no es así.

Esa diferencia es importante durante la generación del prototipo-, la revisión de la primera compilación, la preparación de la compilación piloto y la repetición de la producción de EMS. Un ingeniero de diseño puede depurar una placa con instrumentos de laboratorio, cables de puente y un profundo conocimiento del producto. Un equipo de pruebas de EMS necesita una ruta repetible que funcione en múltiples placas, con pasos documentados y un manejo claro de fallas.

La planificación DFT mejora la eficiencia de depuración y pruebas de PCBA al hacer que la ruta de falla probable sea más fácil de observar antes de que la placa llegue al banco de pruebas.

DFT no es un paso de prueba. Es una decisión de diseño.

Las pruebas se realizan después del montaje.

La planificación DFT ocurre antes de que se construya el tablero.

Esa distinción es fácil de pasar por alto. Muchos equipos tratan las pruebas como algo que la fábrica puede "descifrar" después de que se publican los archivos de PCB. A veces eso funciona para tableros simples. Pero para placas basadas en firmware-, placas de control industrial, diseños SMT densos, paquetes BGA, interfaces de comunicación, relés, sensores o productos integrados en gabinetes-, la planificación de pruebas tardías puede convertirse en un trabajo de depuración tardío.

Es posible que la placa se encienda, pero es posible que la ruta de falla no esté clara.

La prueba puede decir "falla", pero no puede decir si el problema es el ensamblaje, el firmware, el daño de los componentes, el contacto del dispositivo, el cableado del conector, la condición de carga o el comportamiento del diseño.

La planificación de la capacidad de prueba hace avanzar ese pensamiento. Pregunta:

• ¿Qué funciones deben verificarse?
• ¿Qué señales deben ser accesibles?
• ¿Qué rieles eléctricos necesitan medición o aislamiento?
• ¿Qué interfaces necesitan acceso a programación o comunicación?
• ¿Qué fallos deben aislarse rápidamente?
• ¿Qué pasos de prueba deben ser repetibles por el equipo de pruebas de EMS?
• ¿Qué información de depuración se debe registrar después de una falla?

Una placa diseñada únicamente para funcionar puede funcionar en el banco del ingeniero.

Una placa diseñada para pruebas se puede verificar, diagnosticar, reparar y volver a probar con menos conjeturas.

Comience con lo que debe demostrar la prueba

Muchas discusiones sobre DFT comienzan con puntos de prueba.

Por lo general, ese no es el mejor punto de partida.

La mejor primera pregunta es: ¿qué debe demostrar esta PCBA antes de que pueda publicarse?

Para algunos proyectos, la respuesta puede ser simple: ubicación correcta de los componentes, sin cortocircuitos evidentes, encendido-estable y comprobaciones eléctricas básicas. Para otros, la placa puede necesitar carga de firmware, respuesta del sensor, verificación de comunicación, conmutación de relé, medición de corriente, calibración analógica o interacción a nivel de sistema- con otro módulo.

Esas situaciones no necesitan el mismo plan de prueba.

Esto evita uno de los problemas de capacidad de prueba más comunes: la placa tiene puntos de prueba, pero no el acceso de prueba correcto.

Es posible que una plataforma que sea conveniente para el diseño no ayude al equipo de pruebas a aislar una falla. Un conector que funciona durante el proceso de ingeniería-puede bloquearse después del ensamblaje, revestimiento o integración del gabinete. Una interfaz de firmware que funcione para un ingeniero puede no ser práctica para repetir las pruebas de producción.

Una buena planificación DFT comienza con la condición de liberación, luego avanza hacia atrás para acceder, el método de fijación, la entrada de firmware, los puntos de medición y las reglas de nueva prueba.

Vaya más allá de las pruebas de aprobación/rechazo

Un resultado de pasa/falla es útil, pero no es lo mismo que un diagnóstico.

Respuestas de detección: ¿pasó el tablero?

Respuestas del diagnóstico: ¿hacia dónde debería mirar el equipo a continuación?

Esa diferencia se vuelve importante cuando una PCBA falla en FCT, ICT, sonda voladora, programación o verificación de encendido. Si la prueba solo informa una falla general de la placa, es posible que el equipo aún necesite un largo ciclo de depuración manual para encontrar el problema real.

Un enfoque DFT más sólido le da más visibilidad al proceso de prueba.

Por ejemplo, si falla un puerto de comunicación, es posible que la ruta de depuración necesite acceso a:

• referencias de potencia y tierra para el circuito de interfaz;
• restablecer, habilitar o iniciar señales;
• salida de reloj u oscilador;
• confirmación de asignación de pines del conector;
• versión del firmware o estado de programación;
• confirmación de contacto del accesorio;
• conocido-buen estado del cable, la carga o el módulo externo;
• Puntos de señal intermedios entre bloques funcionales.

Esto no significa que todas las placas necesiten una arquitectura de diagnóstico pesada.

No se debe diseñar demasiado-una placa simple para realizar pruebas. Pero si el producto contiene firmware, componentes de alta-densidad, cableado de campo, E/S industriales, conmutación de energía, sensores o interfaces específicas-del cliente, la planificación DFT debe pensar más allá de un único resultado de aprobación/falla.

Un resultado de prueba que dice "falla" sin una ruta de depuración puede convertir una placa defectuosa en una larga investigación.

El acceso a la prueba comienza en el diseño, no en la estación de prueba

El departamento de pruebas no puede acceder a una señal que el diseño nunca hizo accesible.

Esto suena obvio, pero es una de las cosas más fáciles de pasar por alto cuando el equipo de diseño está bajo presión de cronograma.

El acceso a la prueba depende de las decisiones de diseño:

• si las redes críticas tienen acceso práctico a la sonda;
• si los puntos de prueba son accesibles mediante sondas de fijación;
• si los componentes altos bloquean el recorrido de la sonda;
• si los puntos de prueba están demasiado cerca de los cuerpos de los componentes o de los bordes de las placas;
• si los fiduciales y los orificios para herramientas admiten una alineación repetible de los accesorios;
• si los encabezados de programación permanecen accesibles después del ensamblaje;
• si una placa se puede probar antes o después de la integración del revestimiento o del gabinete.

Un punto de prueba colocado en el lugar equivocado puede ser casi tan inútil como no tener ningún punto de prueba.

Para placas de alta-densidad, la respuesta no siempre es "agregar un punto de prueba a cada red". El espacio de la placa, la integridad de la señal, el costo, el volumen de producción y el método de prueba son importantes. En algunos casos, las redes críticas, los rieles eléctricos, las líneas de reinicio, los relojes, las señales de programación y las interfaces de alto-riesgo merecen prioridad. En otros casos, el escaneo de límites, la sonda voladora o la prueba funcional pueden cubrir partes de la prueba que se necesitan de manera más efectiva.

La planificación DFT no se trata de agregar funciones a ciegas.

Se trata de darle al equipo de prueba acceso a las señales importantes.

El escaneo de límites puede reducir el problema de la caja negra

La exploración de límites, a menudo asociada con IEEE 1149.1 y JTAG, puede resultar valiosa cuando el acceso a la sonda física es limitado.

Esto es especialmente relevante para placas con BGA, circuitos integrados{0}}de paso fino, procesadores, FPGA, dispositivos de memoria o interconexiones digitales densas. En esos diseños, muchos pasadores importantes no son físicamente accesibles después del montaje. Sin una ruta de escaneo u otro método de diagnóstico, la placa puede comportarse como una caja negra cuando falla.

El escaneo de límites puede ayudar a verificar las interconexiones entre dispositivos compatibles, admitir flujos de trabajo de programación o configuración y proporcionar visibilidad de diagnóstico donde el sondeo físico es difícil.

Pero sólo ayuda si se planifica.

La planificación útil del escaneo de límites puede incluir:

• enrutar señales de escaneo a un conector accesible o interfaz de prueba;
• confirmar qué dispositivos admiten escaneo de límites;
• definir correctamente la cadena de escaneo;
• proporcionar archivos BSDL cuando sea necesario;
• confirmar si el escaneo de límites se utiliza para pruebas de producción, depuración de ingeniería o ambas;
• asegurándose de que la interfaz de prueba no esté bloqueada por el diseño mecánico o las restricciones del gabinete.

El escaneo de límites no reemplaza todo el acceso de prueba física y no verifica todas las condiciones analógicas, de alimentación o de los conectores. Es más útil cuando la cadena de escaneo está planificada, documentada y respaldada por los dispositivos seleccionados.

Para una placa simple con complejidad digital limitada, el escaneo de límites puede agregar poco valor. Para una placa de control densa o un ensamblaje basado en un procesador-, puede marcar la diferencia entre un aislamiento de fallas útil y una falla funcional genérica.

La partición de energía y señal puede acortar los bucles de depuración

Algunas fallas son difíciles de depurar porque el circuito no fue diseñado para estar aislado.

Un cortocircuito en un riel eléctrico compartido puede afectar muchas partes del tablero. Una interfaz de comunicación fallida puede ser difícil de separar del firmware, el cableado del conector, el daño del transceptor o el contacto del dispositivo. Una cadena de señal analógica puede fallar en la salida, mientras que el problema real se encuentra varias etapas antes.

La planificación DFT puede reducir esta incertidumbre.

Las opciones de diseño útiles pueden incluir:

• puntos de medición accesibles en importantes líneas eléctricas;
• referencias terrestres prácticas cerca de señales medidas;
• opciones de aislamiento como enlaces de 0 ohmios, puentes o conexiones extraíbles cuando corresponda;
• puntos de prueba intermedios en cadenas de señales;
• habilitar o restablecer el control de bloques funcionales;
• conocidas-buenas opciones de carga o loopback para interfaces seleccionadas;
• separación clara entre falla de programación, falla de dispositivo y falla de placa.

Estos no siempre son cambios de diseño costosos. A menudo, son pequeñas decisiones que se toman con suficiente antelación.

La clave es pensar en lo que verá el técnico cuando falle la placa.

Si todo lo que el sistema de prueba puede informar es "falla en la placa", la ruta de depuración comienza con incertidumbre. Si la planificación DFT brinda acceso a bloques funcionales, dominios de energía e interfaces críticas, el equipo tiene más posibilidades de convertir la falla en una acción específica.

El firmware y la programación pertenecen a la planificación DFT

Para muchos PCBA modernos, las pruebas no son solo eléctricas.

También depende del software-.

Es posible que una placa necesite firmware antes de poder probarse funcionalmente. Puede requerir un gestor de arranque, una imagen de prueba, una imagen de producción, un archivo de configuración, un número de serie, una dirección MAC, datos de calibración o un script de comunicación. Si esas entradas no se controlan, una placa ensamblada correctamente aún puede fallar la prueba por el motivo equivocado.

La planificación DFT debe aclarar:

• quién proporciona el firmware;
• qué versión de firmware se utiliza para la prueba de producción;
• si la placa está programada antes o después de la inspección;
• qué interfaz se utiliza para la programación;
• si el conector de programación permanece accesible;
• si se requiere una suma de verificación, un archivo de registro o un registro de versión;
• ¿Qué pasa si falla la programación?
• si la placa debe reprogramarse después del retrabajo.

Esta es una de las brechas más comunes entre las pruebas de ingeniería y las pruebas de producción.

Es posible que el equipo de diseño sepa cómo cargar firmware desde una computadora de laboratorio. El equipo de pruebas de EMS necesita un método que pueda documentarse, seguirse, verificarse y repetirse.

Si el firmware no forma parte de la planificación de DFT, las pruebas funcionales pueden convertirse en una sesión de solución de problemas de programación incluso antes de que comience la prueba real.

La preparación del accesorio depende de las decisiones del DFT

Un dispositivo de prueba no es sólo un soporte mecánico.

Es el resultado físico de decisiones anteriores de comprobabilidad.

La preparación del dispositivo depende de:

• dónde las sondas pueden hacer contacto con la placa;
• si las almohadillas son lo suficientemente grandes y están espaciadas adecuadamente para el método previsto;
• si la altura del componente bloquea el acceso;
• si el soporte de la tabla evita la flexión durante el contacto;
• si los conectores necesitan cables de acoplamiento;
• si el tablero se prueba por un lado o por ambos lados;
• si la prueba se realiza antes o después de la integración del revestimiento o del recinto;
• si el operador necesita interacción con códigos de barras, etiquetas o números de serie;
• si las unidades fallidas requieren separación y nueva prueba.

Si estas decisiones se dejan para tarde, la asamblea puede avanzar mientras las pruebas se convierten en el cuello de botella.

El equipo de EMS no necesita un dispositivo de producción completo para cada construcción de ingeniería inicial. Pero sí necesita conocer la ruta esperada: prueba manual, sonda voladora, ICT, escaneo de límites, FCT, instalación temporal, configuración proporcionada por el cliente- o instalación con intención de producción-.

Esas son suposiciones de construcción diferentes.

Un problema con un dispositivo a menudo parece una falla en la placa hasta que el equipo demuestra que el contacto, el cable o la configuración son estables.

Un proyecto puede estar listo paraAsamblea del PWBy aún no estar listo para pruebas repetibles.

La planificación de DFT debe definir el ciclo de retrabajo y prueba

Las pruebas no terminan cuando falla una placa.

La siguiente pregunta es qué sucede después del fracaso.

Sin una ruta de repetición de pruebas definida, las decisiones de reelaboración pueden volverse inconsistentes. Un técnico puede reemplazar un componente sospechoso y repetir solo el paso fallido. Otro puede volver a ejecutar la prueba funcional completa. Un tercero puede pasar el foro después de una rápida-verificación de encendido porque el síntoma original desapareció.

Eso crea riesgo.

Un plan práctico de DFT debe definir:

• qué fallas requieren revisión de ingeniería;
• qué retrabajo está permitido;
• qué debe inspeccionarse después del retrabajo;
• si se debe repetir la secuencia de prueba completa;
• si es aceptable una nueva prueba enfocada;
• qué datos de falla deben registrarse;
• cómo se intensifican los fracasos repetidos.

Esto no es papeleo por sí solo.

Una PCBA reelaborada no debería publicarse porque "ahora parece estar bien". Debería publicarse porque la ruta de nueva prueba acordada confirma que el problema está cerrado.

Aquí es donde la planificación DFT respalda tanto la eficiencia de la producción como el control de calidad.

Qué debe incluir un paquete PCBA listo para DFT-

La planificación DFT resulta útil cuando está visible en el paquete de ingeniería.

Este no es un documento obligatorio establecido para cada compilación. Es una forma de mostrar qué información puede ser necesaria cuando el alcance de la prueba va más allá de una simple inspección visual o verificación de encendido-.

Para los compradores OEM, un práctico paquete listo para DFT-puede incluir:

Es posible que una placa simple solo necesite una ruta de prueba más ligera. Es posible que una placa de control industrial basada en firmware- necesite un paquete DFT más completo. Una construcción piloto puede necesitar más registros repetibles que una primera muestra de ingeniería.

Lo importante no es el volumen de documentos.

El punto importante es si el equipo de EMS tiene suficiente información para probar la placa sin crear el método de prueba a partir de conjeturas.

Utilice los resultados de las pruebas para mejorar la próxima revisión

DFT no es una lista de verificación-que se usa una sola vez.

La primera compilación a menudo le enseña al equipo algo que no era obvio durante la revisión del diseño.

Después de la prueba y depuración de PCBA, el equipo de OEM y EMS debe preguntar:

• ¿Qué fallas fueron difíciles de aislar?
• ¿Qué pasos de la prueba tardaron más de lo esperado?
• ¿Qué funciones no se pudieron probar de forma fiable?
• ¿A qué puntos de la sonda fue difícil acceder?
• ¿Qué contactos del dispositivo causaron fallas falsas?
• ¿Qué pasos de firmware o programación crearon confusión?
• ¿Qué tableros reelaborados requirieron más pruebas de lo esperado?
• ¿Qué resultados de las pruebas deberían registrarse de forma diferente la próxima vez?

Esta retroalimentación no debe quedarse sólo en el área de prueba.

Debería alimentar la próxima revisión de PCB, el próximo procedimiento de prueba, el próximo diseño de dispositivo y el próximo paquete NPI.

Un buen proceso DFT convierte la primera compilación en un ciclo de aprendizaje.

Cómo se conecta esto al soporte de prueba y ensamblaje de PCB

Para los compradores OEM, la planificación DFT es más útil cuando conecta el diseño de la placa, el alcance del ensamblaje, las necesidades de programación, el acceso a las pruebas y las expectativas de lanzamiento antes de que comience la producción.

STHL apoya proyectos OEM a través de la preparación del ensamblaje, la planificación de pruebas yPruebas e inspección, incluidas discusiones sobre AOI, ICT, FCT, inspección por rayos X-, entradas de programación de firmware, preparación de dispositivos, expectativas de reelaboración y reprueba, y necesidades de trazabilidad.

El objetivo no es agregar pruebas innecesarias.

El objetivo es hacer que el alcance de las pruebas sea lo suficientemente práctico para la función de la placa, la etapa de producción y el nivel de riesgo.

¿Está preparando una compilación de PCBA que necesita un acceso de prueba más claro o una planificación de pruebas funcionales? Envía tu proyecto a travésSolicitar una cotizacióno correo electrónicoinfo@pcba-china.com.

Conclusión

La planificación DFT mejora la eficiencia de depuración y pruebas de PCBA porque mueve el pensamiento de prueba en sentido ascendente, antes de que la placa llegue a la línea.

Ayuda al equipo OEM y EMS a definir qué se debe probar, dónde se necesita acceso, cómo se cargará el firmware, qué dispositivo o configuración de cable se requiere, qué resultado cuenta como aprobado o fallido y cómo se deben depurar, reelaborar y volver a probar las placas fallidas.

Una placa que es fácil de montar no siempre es fácil de probar.

Una placa que es fácil de probar suele ser aquella en la que se consideraron el acceso a las pruebas, la programación, la preparación de los accesorios y la visibilidad de depuración antes del montaje.

Para los compradores de OEM, la lección práctica es simple: el mejor momento para preguntar cómo se probará una placa es antes de que se bloqueen el diseño y el paquete de construcción.