¿Qué es el hardware-in-the-loop (HIL)?

El impacto significativo del tiempo de comercialización se hizo muy visible en la década de 1980 a través de un trabajo innovador del ex consultor de McKinsey Donald G. Reinertsen, indicando que “el retraso de seis meses puede valer el 33 por ciento de las ganancias del ciclo de vida”i causadas por el desarrollo de productos. Además, el lanzamiento y destrucción del cohete Ariane 5 el 4 de junio de 1996, conocido como uno de los errores de software más infames de la historia, enseñó al mundo de la ingeniería la importancia de la calidad del software embebido y la necesidad de pruebas adecuadas. El resultado fue una pérdida de más de 370 millones de dólares. Estas cifras son una prueba clara de las consecuencias de los retrasos y la necesidad de un tiempo de comercialización más corto, así como de la reducción de costos mediante la identificación de errores y fallos a través de pruebas adecuadas en etapas anteriores del ciclo de vida del diseño y desarrollo del producto.

Es clave utilizar tecnología que detecte defectos antes de que comience la producción. Es cada vez más crucial hacer de la prueba un activo integral y estratégico, como parte del ciclo completo de diseño y desarrollo de productos y no solo una idea posterior o incluso un obstáculo al final del proceso. Este entendimiento ha llevado al desarrollo e implementación de métodos y estrategias conocidos como anticipación de pruebas, desplazamiento a la izquierda, diseño basado en modelos y prueba de tipo X-in-the-loop (XIL). Este informe técnico hace un fuerte énfasis en las pruebas HIL como una de las metodologías de prueba cruciales en la validación de software incrustado.

Antes de sumergirse directamente en las pruebas de HIL, es primordial observar el producto real a desarrollar: el dispositivo o sistema bajo prueba (DUT/SUT). Los productos de hoy y de mañana se han vuelto claramente mucho más complejos y centrados en el software. Al considerar ejemplos como enrutadores Wi-Fi, lavavajillas, procesadores de alimentos, etc., ahora todos se basan en software embebido o firmware. Los automóviles, aviones y teléfonos inteligentes son ejemplos excelentes, no solo por ser altamente definidos por software, sino también altamente complejos, porque son un sistema de sistemas basados en software. En última instancia, todos ellos tienen en común que el software es el elemento definitorio de su conjunto de características actual y futuras mejoras que se lanzarán. Las aplicaciones actualizables en un teléfono inteligente que lo convierten en una multiherramienta de miles de características y funciones son la encarnación clara de esta tendencia, que se ha convertido en la expectativa innegable de los clientes de hoy en día para casi todos los demás productos también.

Las aplicaciones, firmware y software en general no pueden funcionar por sí solos, ya que necesitan hardware para ejecutarse. Normalmente, el hardware es una computadora o procesador, o simplemente un controlador. Esto significa que un producto o sistema (incluidos los sistemas de sistemas) requiere la combinación e integración de hardware (controlador) y software, que luego se convierte en el DUT. Además, el controlador también requiere que su entorno interactúe con él. Por ejemplo, el controlador de una lavadora necesita verificar si hay suficiente agua presente, medir la temperatura del agua, controlar la velocidad (RPM) del tambor de la lavadora, etc. Por lo tanto, el controlador requiere la conexión a sensores (temperatura, RPM) y actuadores (calentador, motor eléctrico) que proporcionan datos o retroalimentación como entradas y envían comandos o puntos de ajuste como salidas. Estos son solo los componentes básicos de la teoría del diseño de bucles de control, como se representa en la Figura 1. Aquí, el entorno alrededor del controlador se conoce típicamente como la planta.

Figura 1. Fundamentos del diseño de bucles de control

Al observar el ciclo de diseño y desarrollo del producto, es evidente que no todos los componentes del bucle de control estarán disponibles al comienzo de un proyecto. Aún más, tampoco es realista tener todos los componentes de hardware y software necesarios listos y disponibles en las primeras etapas de desarrollo. Aquí es donde la simulación y el diseño basado en modelos comienzan a llenar los vacíos.

La Figura 2 muestra el ciclo de vida del desarrollo del producto en una representación típica de diagrama en V, con sus diferentes etapas desde el diseño hasta la creación de prototipos, pasando por las pruebas de software y controladores, hasta las pruebas físicas. También muestra las metodologías de prueba de modelo en bucle (MIL), software en bucle (SIL) y hardware en bucle (HIL).

Figura 2. El diagrama V: De cualquier cosa en el bucle (XIL) a la prueba física

La simulación digital y el diseño basado en modelos son clave en todo el proceso de diseño porque:

• Permitir el desarrollo y las pruebas antes de que los componentes físicos requeridos estén disponibles
• Aumente la cobertura de prueba, cree iteraciones de diseño más rápidas
• Mejora la velocidad minimizando el número de pruebas redundantes (físicas)
• Acelere las pruebas de calidad del producto para casos de esquina y todos los escenarios posibles

La simulación y el diseño basado en modelos permiten el inicio de las pruebas mucho antes (denominado prueba de carga frontal) a través de metodologías de prueba como MIL, SIL e HIL. Como se muestra en la parte inferior de la Figura 2, los componentes del bucle de control se reemplazan paso a paso cuando se mueven de derecha a izquierda en el diagrama en V (también conocido como desplazamiento a la izquierda), mientras que se mueven a la derecha en línea con el diseño real del producto y el ciclo de vida de desarrollo, los componentes se reemplazan con el hardware y software real a medida que están disponibles.

Además, las pruebas virtuales maximizan la cobertura de las pruebas y reducen la cantidad de pruebas físicas costosas y que consumen mucho tiempo. Una estimación aproximada del número de defectos encontrados en el software integrado es de 10 a 20 por cada 1.000 líneas de código. Esto puede no parecer mucho a primera vista, pero cuando se observa cuántas líneas de código hay ahora en los sistemas cotidianos, el número estimado de defectos puede ser increíblemente alto. Teniendo en cuenta los dispositivos médicos, como los marcapasos, que tienen 80.000 líneas de código (~800 a 1.600 defectos), o un escáner de resonancia magnética con 7.000.000 (~70.000 a 140.000 defectos), el impacto de la expansión en la complejidad del software se hace evidente y mucho más grave.

La complejidad de estos sistemas es abrumadora hasta el punto de que resulta imposible probarlos exhaustivamente de la manera tradicional. Probar físicamente todos los escenarios es imposible y requiere una cantidad irrazonable de tiempo y dinero. Además, es importante estar seguro de que los casos de prueba cubren todas las condiciones posibles del mundo real. Las grandes fallas, desastres y retiradas de dispositivos son muy costosas, como se señala en el ejemplo de Ariane 5 en la introducción de este libro blanco. Pero aún más, el impacto negativo de estas consecuencias en la imagen de marca y la reputación de la empresa es simplemente invaluable. La mitigación de este riesgo puede lograrse mediante el modelado y la simulación. Prácticamente, es factible probar productos en todos los escenarios posibles y repetibles y con confianza, por lo que la prueba física final es solo la última comprobación y no un evento catastrófico costoso.

Las pruebas de software integrado sirven como metodología para la detección de problemas, conectando equipos de diseño y prueba con un flujo de trabajo compatible que utiliza en gran medida simulación y diseño basado en modelos.

Figura 3. MIL, SIL, HIL y prueba física en la representación de bucles de control

La primera etapa, MIL (cuadrante 1 en la Figura 3), simula todo, incluyendo el controlador y toda la planta (ambiente) alrededor del controlador.

Durante la segunda etapa, SIL (cuadrante 2 en la Figura 3), los ingenieros de software generan código listo para el objetivo solo a partir del modelo de control, reemplazando el bloque y creando un prototipo de software mientras la planta aún está simulada. Estas dos primeras etapas permiten la ejecución de pruebas mediante simulación y los modelos apenas requieren componentes físicos de hardware reales.

La tercera etapa, HIL (cuadrante 3 en la Figura 3), es fundamental en esta metodología. El código se implementa y ejecuta en una unidad de control física basada en hardware (una plataforma de prototipado de control rápido o un controlador producido), lo que permite probar todos los escenarios posibles del mundo real utilizando la planta simulada y de nuevo antes de pasar a las pruebas físicas (finales) (cuadrante 4 en la figura 3).

Por lo tanto, HIL puede considerarse como el equivalente al matrimonio entre el chasis y el tren de transmisión de un vehículo con su carrocería en una línea de producción de vehículos. Es esencial ejecutar el código de software desarrollado en el hardware del controlador real, para asegurarse de que se puedan identificar todos los fallos de temporización, sincronización y ejecución, que normalmente no están presentes cuando se ejecuta el código incrustado en un entorno SIL, por ejemplo.

Hay grandes expectativas y una evolución considerable de la situación para seguir haciendo hincapié en la utilización de la MIL y la SIL. Pero HIL será y debe ser siempre el punto de prueba para ejecutar software integrado en la plataforma controladora real, para lanzar productos seguros centrados en el software con confianza al mercado. En resumen, las pruebas HIL proporcionan los siguientes beneficios:

• Pruebas seguras: evita riesgos de dañar equipos costosos o peligrosos
• Rentabilidad: reduce la necesidad de prototipos completos
• Desarrollo rápido: permite pruebas tempranas antes de que se cree el sistema completo
• Escenarios repetibles: simular casos y fallas comunes y/o de borde de manera confiable

Figura 4. La analogía de los peces: Un sistema HIL es el equivalente a un acuario.

HIL es una metodología de pruebas que proporciona un entorno virtual o realidad virtual (gemelo digital) alrededor del DUT físico (software integrado que se ejecuta en un controlador) para hacerle “creer” que en realidad está conectado al entorno real (gemelo físico). Una analogía muy simple a esto es un pez en un acuario o pecera, como se representa en la Figura 4. El acuario imita perfectamente el entorno del mundo real del océano, proporcionando un entorno simulado controlado, para asegurarse de que los peces tienen todo lo que necesitan para sobrevivir (alimento, agua, temperatura, salinidad, etc.).

Cuando se mira el lado técnico y se enfoca en productos centrados en software como un DUT, HIL es una técnica de prueba de software incrustado durante el cual las señales reales de un controlador se conectan a un sistema de prueba (planta). HIL simula la realidad utilizando modelos de software y simulación. Por lo tanto, el sistema de prueba HIL que imita el entorno del mundo real es el equivalente del acuario, y el DUT (controlador físico que ejecuta software incrustado) es el equivalente del pez. Esto hace que el controlador (o DUT) crea que está instalado en el producto ensamblado como una lavadora, un avión o un automóvil.

Las iteraciones de prueba y diseño tienen lugar como si estuvieran conectadas al sistema del mundo real, pero a través de una planta simulada. Mediante el uso de escenarios repetibles y virtualizados, los ingenieros pueden ejercer el controlador en miles de condiciones sin la necesidad de tener todos los componentes reales disponibles, el costo, la complejidad o las restricciones de programación de las pruebas físicas basadas en hardware. El controlador real o DUT obtiene sus entradas del sistema HIL y envía sus salidas de vuelta al sistema HIL. El sistema HIL consiste en entradas y salidas, incluidas las interfaces de bus, así como un núcleo de cómputo en tiempo real que ejecuta el software de aplicación HIL, incluidos los modelos de planta requeridos. Para asegurarse de que una configuración de sistema de prueba HIL cumple con todos los requisitos para proporcionar una realidad virtual extensa alrededor del DUT, debe consistir en al menos estos elementos centrales, como se muestra en la Figura 5:

• DUT (software integrado que se ejecuta en un controlador)
• Interfaces de E/S y buses para conectarse al DUT
• Cómputo en tiempo real para leer, escribir y controlar los buses de E/S y comunicación de forma determinista, así como ejecutar software de aplicación
• Software de aplicación para configurar el sistema de pruebas, integrar y desplegar modelos de simulación, ejecutar una prueba o múltiples casos de prueba (manual y automatizada) así como analizar y depurar resultados y comportamientos
• Modelo(s) de simulación

Figura 5. Bucle de control en una configuración de sistema de prueba HIL

Como se mencionó anteriormente, estos son solo los elementos centrales de un sistema HIL. Entre los elementos adicionales también pueden figurar los siguientes:

• Inserción de Fallas
• E/S basadas en FPGA
• Conmutación I/O
• Acondicionamiento de señales
• Conexiones con cargas o cargas emuladas
• Simulación de reposo (entradas necesarias de otros controladores; por ejemplo, en un sistema de sistemas)
• Pruebe la automatización hasta la integración continua y la implementación continua (CI/CD)

El enfoque basado en la plataforma NI para las pruebas de HIL proporciona a los desarrolladores y usuarios una caja de herramientas de bloques de construcción abiertos y flexibles, que permiten una gran personalización utilizando productos comerciales del estante (COTS), y escalar desde una pequeña mesa de trabajo hasta componentes y sistemas, así como configuraciones de HIL de integración completa. Los usuarios pueden decidir qué usar y cómo extenderse y expandirse para los desafíos actuales y futuros. Mantienen el control total de su flujo de trabajo, así como el desarrollo y mantenimiento de sus activos de prueba, al tiempo que minimizan la dependencia de los proveedores.

La arquitectura del sistema de prueba NI HIL ofrece una plataforma integral de hardware y software que aborda los diferentes elementos de un sistema HIL. Su cadena de herramientas abierta y personalizable maximiza la capacidad de adaptar, escalar y expandir un sistema de pruebas HIL con una mezcla de hardware y software de NI, NI Partner y de terceros.

PXI es una plataforma de hardware líder en la industria, construida sobre la verdadera tecnología COTS. Ofrece las mejores capacidades de sincronización y temporización de su clase y sirve como elemento fundamental de los sistemas de prueba HIL. PXI también soporta una amplia gama de interfaces de E/S y bus, desde DC hasta RF, incluyendo tecnología basada en FPGA, interfaces de propósito general y protocolos de comunicación específicos de la industria.

Estas ofertas de E/S y bus se pueden ampliar aún más mediante la adición de la plataforma de carga y acondicionamiento de señales (SLSC) de NI Switch. SLSC añade módulos frontales personalizados a la ruta de señal entre las interfaces de E/S y bus reales en el lado del sistema de prueba y el DUT. A través de la conectividad COTS estandarizada y factores de forma, elimina el proceso de cableado punto a punto propenso a fallas. Esto simplifica el sistema en general y permite la conmutación y acondicionamiento de señales, la integración de cargas, la inserción de fallas y más.

NI VeriStand es el software de aplicación básico para sistemas NI HIL y pruebas de software integrado en tiempo real. Acelera el ciclo de vida del desarrollo de productos a través de la configuración y el control del sistema HIL basado en configuración (UI y API), depuración, integración de modelos, generación de estímulos en tiempo real, automatización en el producto, así como una amplia funcionalidad de API de automatización personalizada a través de NI LabVIEW, C/C++, Python y más.

Obtenga más información sobre la arquitectura NI HIL Test System aquí.

Los productos actuales se han centrado en el software, y la base subyacente a las expectativas del cliente es que un producto evolucionará y mejorará en el futuro, proporcionando un valor continuo e incluso nuevo. La prueba de validación virtual utilizando simulación, diseño basado en modelos y pruebas HIL son metodologías clave para aumentar la cobertura de la prueba y la calidad del producto. Estas metodologías también reducen el tiempo de comercialización al iniciar e integrar las pruebas en los primeros ciclos de diseño y desarrollo, al tiempo que minimizan la necesidad de pruebas físicas costosas y que requieren mucho tiempo.

Esto convierte la palabra “prueba”, que a menudo se define y utiliza como los pasos finales necesarios para mover un diseño a la producción y, en última instancia, al mercado, en una ventaja estratégica para la innovación general del producto. HIL eleva las pruebas a algo más que una casilla de verificación en un plan de proyecto. Se convierte en una parte integral de la innovación que hace que un diseño y una empresa tengan éxito (ver “seis meses de retraso pueden valer el 33 por ciento de los beneficios del ciclo de vida”).

Las empresas con visión de futuro están utilizando HIL fuera del camino tradicional hacia las pruebas de mercado. Aunque el objetivo a largo plazo de HIL es evitar errores costosos (como en el ejemplo de Ariane 5) en un producto final caro y/o producido en masa, también es una herramienta de diseño que los ingenieros de software pueden usar para probar y ajustar iterativamente sus diseños de software. Esto conduce a un producto investigado antes de que comiencen las pruebas formales. Además, los ingenieros de software pueden concebir y probar nuevas ideas rápidamente, lo que les ayuda a maximizar la innovación a través de comentarios oportunos.

• Explore las arquitecturas del sistema de pruebas HIL
• Vea cómo Whirlpool usa las pruebas HIL
• Descubra cómo HIL Accelerated Archer Aviation
• Vea cómo ZF valida ADAS con HIL