Si realizas una búsqueda sobre pruebas de "Hardware-in-the-Loop" (HIL), frecuentemente encontrarás ejemplos de sistemas complejos en tiempo real. Este artículo de National Instruments, por ejemplo, ofrece una buena explicación y antecedentes sobre qué es el hardware-in-the-loop (HIL) y proporciona un ejemplo de pruebas de unidades de control electrónico dentro de un automóvil. En este artículo, nos centraremos en una versión más pequeña y más digerible de los conceptos de pruebas HIL.
Para los propósitos de este artículo, definiremos las pruebas de hardware-in-the-loop de una manera un poco diferente a como se presenta convencionalmente (por ejemplo, dentro de aplicaciones automotrices). Observemos tres diferentes niveles de complejidad cuando se trata de probar un producto.
En esta forma de prueba, un ingeniero probará manualmente el dispositivo. Esto puede consistir en sondear puntos de prueba en una placa con un multímetro digital, observar formas de onda en un osciloscopio o analizar manualmente una lectura de telemetría en una pantalla de computadora. El ingeniero probará el producto mediante pruebas de verificación de diseño manual.
Esta configuración de prueba realiza las mismas mediciones y verificaciones que normalmente haría un ingeniero, pero es realizada por una computadora de manera automatizada. La computadora anfitriona hablaría directamente con los instrumentos (por ejemplo, multímetros, osciloscopios, etc.), analizaría la telemetría del dispositivo y luego verificaría el conjunto de pruebas basado en los criterios establecidos por el ingeniero.
Las pruebas de hardware en el bucle llevan las pruebas automatizadas a un nuevo nivel al agregar estímulos extras para simular una aplicación del mundo real. Por ejemplo, el dispositivo bajo prueba (DUT) puede tener una serie de sensores que requieren excitación. El equipo de prueba simularía el otro extremo de esos sensores para excitar el lado del sensor del DUT. Otro ejemplo podría ser algo tan simple como conducir tráfico RS-422 hacia un receptor RS-422 en el DUT. La idea es que somos capaces de introducir nuevos estímulos en el DUT, leer de vuelta la telemetría desde la computadora anfitriona y ajustar nuestras pruebas adecuadamente si es necesario (por ejemplo, conducir tráfico RS-422 más rápido y en mayor cantidad después de pasar una prueba inicial).
Basado en la aplicación, puede ser claro por qué uno elegiría adoptar pruebas de hardware en el bucle sobre pruebas automatizadas (y ciertamente pruebas manuales). Si uno intenta integrar un sistema complejo o (sistemas de sistemas), con muchos estímulos externos requeridos, una prueba básica de comprobación automatizada no será suficiente. Considera un cargador de baterías básico. Aunque podrías simular una fuente de alimentación, carga y batería para probar tu circuito controlador (ya sea físicamente o a través de software), sería más realista usar una fuente de alimentación real, batería y carga para probar el diseño. Además, si puedes automatizar este proceso, tus ingenieros ahora pueden dedicar su tiempo al desarrollo en lugar de a las pruebas.
Al decidir si adoptar pruebas de hardware en el bucle, se deben considerar los siguientes factores:
Una vez que hayas considerado estos y otros factores, puedes comenzar a tomar una decisión sobre si continuar con las pruebas manuales o invertir en pruebas automatizadas/hardware-in-the-loop.
Basado en mi experiencia, he encontrado que, sin duda, la entrada más fácil al testing hardware-in-the-loop sería utilizando un marco de prueba todo incluido como el que ofrece National Instruments (NI). NI tiene una plataforma de hardware/software todo incluido que es plug and play. Aquí hay algunos pros y contras a considerar al pensar en un marco todo incluido:
Durante el tiempo que pasé trabajando en sistemas complejos, LabVIEW fue mi opción predilecta para las pruebas automatizadas, incluyendo la construcción de un pipeline completo de Integración Continua y Despliegue Continuo para proyectos y VIs de LabVIEW. A medida que hice la transición hacia sistemas más pequeños que requerían un soporte más simple en bucle cerrado, comencé a migrar hacia hardware personalizado o comercial de estantería (COTS) y scripts de Python (usando el framework de pytest). Nuevamente, todo esto depende de la aplicación y, como se mencionó anteriormente, el tiempo de prueba, la recurrencia de la prueba y el equipo de prueba son los principales factores que impulsan esta decisión.
En este artículo, revisamos el concepto de pruebas en bucle cerrado con hardware y cómo se diferencia tanto de las pruebas manuales como de las automatizadas. También revisamos los beneficios de adoptar pruebas en bucle cerrado con hardware y cómo evaluar si realmente es lo que el usuario necesita. Finalmente, discutimos algunas formas de comenzar. Aunque las pruebas en bucle cerrado con hardware no sean para todos, está claro que para la aplicación correcta, la inversión rendirá dividendos muy rápidamente.
¿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.