En el mundo acelerado de hoy, donde las iteraciones de electrónica se realizan a velocidades impresionantes, a menudo olvidamos uno de los aspectos más críticos del desarrollo: las pruebas. Siempre es fácil pasar por alto las pruebas simplemente porque es la última etapa que nos impide lanzar nuestro producto. En el desarrollo de productos, constantemente nos encontramos en el campo de batalla entre "lo suficientemente bueno" versus "probado exhaustivamente". Esta situación suele ocurrir porque no tenemos tiempo para probar, volver a probar y luego probar un poco más.
En la mejor de las situaciones, habríamos contratado a un equipo de pruebas completo que esté equipado para realizar pruebas exhaustivas. Incluso si tenemos ese equipo de pruebas tan sofisticado, ¿realmente podemos utilizarlos para cada modificación, cada cambio pequeño e insignificante que hacemos en nuestros prototipos? En la mayoría de los casos, la respuesta es no, y en este artículo, me gustaría abordar el problema con una solución donde puedas tener tu pastel y comértelo también. En este artículo, revisaremos un sistema de pruebas muy económico, pero altamente efectivo y bastante exhaustivo que te dará esa rentabilidad que has estado buscando.
Es bastante común en la industria tener un conjunto de pruebas automatizado (principalmente para pruebas a nivel de producción). Sin embargo, para el desarrollo de productos, no es una práctica común. Como se mencionó anteriormente, el costo y el tiempo de desarrollo para configurar equipos de prueba automatizados sofisticados requiere un alto nivel de esfuerzo. Este tipo de costo y esfuerzo solo se justifica para la producción en volúmenes masivos o volúmenes bajos con configuraciones de prueba muy sofisticadas (por ejemplo, sistemas espaciales de bajo volumen que deben ser probados ambientalmente muchas veces). Para el resto del mundo, recurrimos a pruebas manuales básicas y tediosas. Este tipo de pruebas puede variar desde la validación de ADC/DAC, verificaciones de protocolo, pruebas de consumo de energía, etc. Independientemente del tipo de prueba, la esperanza es que solo necesite hacerse una o dos veces, y luego pueda ser entregado al grupo de pruebas.
La realidad es que durante nuestro desarrollo, ya sea en las fases de diseño de hardware/respin o en el desarrollo de software embebido, sin querer causamos que algo se rompa. Algunos ejemplos podrían ser un puente de soldadura entre pads o código de controlador que se filtra en otros códigos de controlador podría causar que algo se rompa. Independientemente del resultado, está claro que las pruebas no ocurren solo una o dos veces. Los problemas surgen, y realizar pruebas exhaustivas suele ser demasiado agotador después de la décima vez de rehacer una placa. La respuesta obvia al problema es tener sistemas automatizados que realicen pruebas de regresión exhaustivas. Pero, ¿cuál es la solución para el ingeniero embebido que tiene poco dinero y tiempo para desarrollar un sistema de prueba automatizado exhaustivo?
Para los sistemas embebidos, existe una solución de prueba automatizada de bajo costo, muy escalable y práctica. Aunque no es perfecta, proporcionará al ingeniero de diseño el mayor retorno de la inversión. El concepto es utilizar un dispositivo simple que pueda generar señales analógicas, leer señales analógicas, generar diversos flujos seriales de protocolo y analizar formas de onda. Un ejemplo de un dispositivo de bajo costo que posee tales especificaciones es el Analog Discovery 2. Aunque este es un dispositivo de 5V, aún tiene bastante potencial. Lo considero mi navaja suiza para el desarrollo de sistemas embebidos. Hay otros productos comparables en el mercado, pero encontré que este dispositivo funciona particularmente bien para mis aplicaciones. Este dispositivo puede funcionar desde tu computadora de escritorio o incluso un Raspberry Pi. También tiene una biblioteca de Python que permite al usuario armar rápidamente ejecutivos de prueba. Por conveniencia, he dockerizado la configuración completa y la he construido para todas las arquitecturas.
Consideremos un ejemplo real que se puede encontrar en este repositorio. Por simplicidad, nuestro objetivo embebido será un Arduino Duo. A continuación, se muestra cómo luce nuestra configuración de prueba completa:
La idea aquí es demostrar:
¿Por qué querríamos automatizar algo así? Supongamos que reparamos una placa cerca del ADC, o alguien cambia los controladores que interfieren con el ADC. ¿Estamos 100% seguros de que una simple lectura manual del ADC con unos cuantos ajustes en una fuente de alimentación es suficiente para probar nuestro hardware/software? Si no, ¿por qué no dejar que la automatización cubra todas las permutaciones y todos los casos límite, para que no tengamos que hacerlo? Y, ya que estamos, ¿por qué no ejecutar la misma operación 100 veces... solo porque podemos? Esto puede volverse mucho más sofisticado y complicado (por ejemplo, pruebas de protocolo, pruebas de filtrado del ADC, etc.), pero este artículo se centrará solo en los conceptos básicos.
El script de prueba es bastante básico. Asumiendo que tu Arduino (es decir, el dispositivo embebido bajo prueba) ha sido cargado con los archivos de programación adecuados y todo ha sido conectado correctamente, ejecutarías el script de prueba en tu computadora de la siguiente manera:
python -m pytest test_arduino_hil.py
Esto activará el Analog Discovery 2 para barrer a través del rango de voltaje del ADC de Arduino y validar que el voltaje de entrada coincide con el voltaje de salida leído del ADC. En lugar de barrer manualmente con una fuente de alimentación de banco, el script lo hizo por ti con un solo comando. Para un ejemplo trivial como este, parece innecesario, pero este proceso rinde dividendos cuando se combinan pruebas de manera similar a una regresión.
Al combinar esto con nuestro sistema CI/CD, podemos ver las siguientes etapas ejecutándose y pasando:
Las etapas mencionadas arriba son:
Si examinamos más de cerca la sección de Pruebas, podemos ver que estas pruebas fueron capturadas y analizadas por Gitlab:
Ahora tenemos una configuración de software que nos permite probar nuestro diseño local y remotamente (usando nuestro sistema CI/CD). Esto permite que el ingeniero de diseño continúe enfocándose en diseñar en lugar de probar y depurar más adelante.
En este artículo, revisamos el concepto de usar pruebas automatizadas para validar un diseño de manera concurrente y a posteriori. Ya sea una modificación menor o un cambio de diseño monumental, tener pruebas de regresión automatizadas es muy beneficioso cuando se trata de descartar consecuencias no intencionadas (es decir, arreglar una cosa, romper otra). El proceso recomendado es escribir estos scripts de prueba junto con el proceso de desarrollo del diseño (similar a Desarrollo Guiado por Pruebas). Acoplar estas pruebas automatizadas con un sistema CI/CD añade un beneficio extra para demostrar que nuestras placas están funcionando en un objetivo remoto y pueden ser probadas por cualquiera, en cualquier lugar, en cualquier momento.
¿Te gustaría saber más sobre cómo Altium puede ayudarte con tu próximo diseño de PCB? Habla con un experto en Altium o descubre más sobre los principales problemas de DFM y sus soluciones. Puedes descargar una prueba gratuita de Altium Designer aquí.