Acelerar el ciclo de vida del desarrollo del producto con pruebas más rápidas: Navegando por el diagrama V

Los sistemas electromecánicos convierten la energía en trabajo mecánico y viceversa. Cuentan con electrónica de control (por ejemplo, una unidad de control electrónico) o controladores embebidos (por ejemplo, una unidad reemplazable en línea) que ejecutan software especialmente diseñado que controla la mecánica, la actuación y los componentes físicos utilizando entradas de sensores y otros sistemas. Los sistemas electromecánicos proporcionan propulsión de vehículos y cumplen una variedad de otras funciones en aeronaves, vehículos terrestres y barcos.   

Figura 1. Categorías de vehículos de ejemplo y los tipos de sistemas electromecánicos comunes en ellos

Aunque las funciones, los métodos de acción y los requisitos de diseño de estos sistemas pueden variar ampliamente, el desarrollo y las pruebas de los sistemas de vehículos electromecánicos siguen el mismo flujo de trabajo general. Los ingenieros de sistemas diseñan el vehículo en general y los requisitos que deben cumplir los sistemas, los subsistemas y los componentes del vehículo. Diferentes equipos abordan estos requisitos desarrollando la electrónica de control, el software y los componentes mecánicos adecuados según las especificaciones. Estos equipos siguen sus propios procesos de desarrollo (por lo general, una metodología común como Agile adaptada a necesidades organizacionales específicas) para avanzar en los pasos de diseño y validación para sus piezas específicas del sistema electromecánico del vehículo. Luego, el sistema se construye iterativamente, se integra y se prueba en distintas etapas para producir el vehículo terminado.

Figura 2. Proceso generalizado de desarrollo de productos para sistemas electromecánicos

El proceso de avanzar desde los requisitos hasta el diseño y la validación se representa de varias formas, una de las cuales es el modelo V (Figura 3). Incluso con toda la confusión que rodea al modelo V y sus muchas encarnaciones e interpretaciones, sigue siendo un framework útil para examinar los méritos de una arquitectura universal de pruebas para cumplir con las necesidades de prueba en todo el proceso de diseño.

Figura 3. El método del modelo V para representar el proceso de desarrollo y los tipos de pruebas asociados

En general, el lado izquierdo de la V representa el desglose desde requisitos de alto nivel hasta especificaciones de nivel inferior hasta decisiones de diseño progresivas. Estas decisiones se toman utilizando un enfoque de diseño cada vez más basado en modelos que abarca una variedad de herramientas de ingeniería asistida por computadora (CAE) según el tipo de sistema en desarrollo. Para más información sobre este tema, consulte la literatura sobre transformación digital y digital twinning. En la parte inferior de la V, los sistemas se han desglosado en sus componentes de más bajo nivel, el diseño está listo para traducirse en implementación y los prototipos de los componentes están listos para construirse (y el código se implementa en los prototipos que ejecutan el software, por lo que la parte inferior de la V a veces se etiqueta como "implementar"). El lado derecho de la V muestra la integración de estas piezas, la verificación de su funcionamiento frente a las especificaciones y la validación del rendimiento frente a los requisitos en cada paso de la integración, desde los componentes básicos hasta el nivel del vehículo.

Nota: A medida que se proporcionan los detalles del sistema, el subsistema y los componentes, el desarrollo del software, componentes eléctricos y componentes mecánicos avanza en paralelo, como se muestra en la Figura 2. Por lo general, los diferentes equipos de diseño y pruebas con la experiencia en el dominio requerida son los dueños del proceso de desarrollo.

Nota: Los términos "verificación" y "validación" se usan de manera un tanto indiscriminada y algunas veces, se usa el término general "V&V". Generalmente, durante la verificación, usted se pregunta: "¿Estoy construyendo bien?" y quiere asegurarse de que su sistema funcione como se espera (con tolerancia o rango) en comparación con un conjunto de especificaciones. Pero durante la validación, se pregunta: "¿Estoy construyendo lo correcto?" Se asegura de que su sistema, una vez completo, pueda realizar las tareas para las que fue diseñado con un rendimiento aceptable, medido frente a un conjunto de requisitos.

Las descripciones breves y definiciones de las siguientes pruebas están en el orden en que las encuentra en el proceso de diseño del producto, que en la práctica es muy iterativo. La capacidad de avanzar rápida y eficientemente a en el diseño V para iterar en el diseño es una ventaja competitiva y una capacidad clave de una organización de pruebas de primera clase. Una crítica del modelo V es que representa un proceso secuencial como la metodología de diseño en cascada.

Para la prueba MIL, usted modela tanto el controlador como la planta en software. Este tipo de prueba se realiza al inicio del proceso de diseño para probar las estrategias del controlador y los comportamientos del sistema en un entorno de simulación de software.

Para la prueba SIL, usted modela la planta, pero la conecta con el código de control real escrito y ejecutado en su lenguaje de desarrollo seleccionado y compilado y ejecutado en el sistema de desarrollo, algunas veces en una máquina virtual.

La prueba PIL es similar a la prueba SIL, pero el código de control se escribe y compila para la arquitectura del procesador y el sistema operativo específicos que se utilizarán en el sistema implementado. Por ejemplo, si usted está ejecutando el código en un FPGA específico con configuraciones específicas, compila el código para ese escenario específico para garantizar la funcionalidad adecuada en la arquitectura de procesamiento real y garantizar la disponibilidad de suficientes recursos. Este es un paso de prueba con nombre distinto porque la implementación de la arquitectura de procesamiento y el hardware implementados puede ser un proceso complicado y lento, especialmente cuando las optimizaciones de diseño en la unidad de control electrónico (ECU) causan limitaciones en la funcionalidad y las características del software.

RCP se usa para iterar rápidamente en posibles esquemas de control utilizando modelos matemáticos que se ejecutan en un controlador en tiempo real y/o un FPGA conectado a través de E/S reales a una planta real.

HIL es una prueba de software en el controlador embebido real con los componentes físicos alrededor y los sensores simulados para que la ECU esté realizando su E/S eléctrica real con acondicionamiento de señales, niveles de carga reales y la capacidad de insertar fallas.

Las aplicaciones de prueba física utilizan medidas basadas en transductores (como temperatura, presión, esfuerzo/tensión, sonido, aceleración, desplazamiento, etc.) para probar las características físicas del componente o sistema bajo prueba. Los ejemplos de aplicación incluyen prueba de ruido, vibración y severidad (NVH), que implica realizar medidas de sonido y vibración de micrófonos y acelerómetros. Otro ejemplo es la prueba de durabilidad/prueba de ciclo de vida (prueba de vida altamente acelerada, o HALT, y pantalla de tensión altamente acelerada, o HASS), que se enfoca en determinar cómo se comportará el DUT bajo una variedad de condiciones de operación.

1. Todo el lado derecho del modelo V enfatiza los niveles sucesivos de prueba de integración. La integración generalmente implica el uso de dos tipos clave de sistemas:
   Las instalaciones de prueba se utilizan para probar la integración de varios componentes en un solo (sub)sistema para la prueba a nivel del sistema. Las instalaciones de prueba son adecuados para manejar una amplia variedad de posibles pruebas porque reúnen los diversos componentes de nivel básico en un sistema funcional. Tener un sistema en funcionamiento facilita la configuración y la ejecución de las pruebas.
2. El laboratorio de integración de sistemas o "iron bird", que es la integración de múltiples subsistemas para realizar pruebas a nivel del vehículo, se asemeja al diseño real del vehículo y las conexiones del sistema. Se utiliza para pruebas de sistema de sistemas y pruebas de comunicaciones/interacciones/condiciones de borde entre sistemas. Algunos casos de prueba solo pueden cubrirse teniendo esta magnitud fuera de la infraestructura de prueba. Este es el último nivel de prueba antes de que se construyan prototipos de vehículos para pruebas/ensayos en campo/vuelo reales.

La MRO o prueba de depósito proporciona los servicios, reparaciones y actualizaciones que los sistemas de vehículos necesitan durante su vida útil, a menudo con duración de varias décadas y varias generaciones. A veces, se utiliza el mismo equipo, o una versión modificada del mismo, para las instalaciones de prueba del sistema. Un desafío con la prueba MRO es mantener de manera eficiente la capacidad de la prueba durante la vida útil de un programa ante los problemas de obsolescencia del hardware y software del probador, la rotación de personal y los cambiantes requisitos debido a las actualizaciones periódicas del sistema.  

Los vehículos utilizados para las pruebas en campo suelen estar bien instrumentados para proporcionar la mayor cantidad de datos posible sobre el funcionamiento del vehículo durante este costoso tipo de prueba. Las consideraciones clave son el peso/tamaño, la capacidad de alimentar el equipo de prueba y el almacenamiento y recuperación de los datos. Aunque requiere mucho tiempo y es costosa, la prueba en campo sigue siendo una parte clave del proceso de desarrollo del producto porque los modelos nunca son perfectos y las interacciones del sistema son complejas y pueden dar como resultado un comportamiento inesperado que no se cubrió en los procedimientos de pruebas anteriores. La prueba en campo determina la preparación operativa.

Ahora que usted está familiarizado con el proceso de desarrollo y los tipos de pruebas asociados, puede ver la potente ventaja de una arquitectura de pruebas unificada. La capacidad de cubrir las necesidades de prueba a lo largo del ciclo de diseño, desde la generación temprana de prototipos hasta la validación de software, eléctrica y mecánica, hasta celdas de prueba a nivel de sistema y laboratorios de integración de sistemas, con una plataforma de pruebas permite un desarrollo de pruebas más rápido y una utilización de recursos más eficiente. Tanto el equipo como las personas son más interoperables e intercambiables en el diseño V y en los programas. Esta capacidad de avanzar en el modelo V con respecto a las capacidades de pruebas y las iteraciones es extremadamente valiosa.

Una arquitectura de pruebas unificada ofrece beneficios similares a los modelos de programación orientada a objetos. Si sabe que necesita desarrollar el mismo tipo de sistemas usando métodos similares, puede invertir en componentes básicos que se pueden usar en todos los proyectos y personalizar para las especificaciones únicas de cada proyecto.  

Este enfoque de pruebas basado en plataforma es más sólido porque con una plataforma extensible y flexible que respalda su arquitectura de pruebas, usted puede estar seguro de que los cambiantes requisitos y las futuras demandas imprevistas en el sistema no lo "sorprenderán" en términos de funcionalidad del sistema y capacidad de pruebas. O, para decirlo de otra manera, con este enfoque, usted puede prepararse para lo desconocido pero anticiparse a los requisitos futuros al no diseñar explícitamente la funcionalidad. Esto es mucho mejor que los sistemas de funciones fijas para los cuales debe diseñar explícitamente la flexibilidad y la extensibilidad que usted cree que puede necesitar en el futuro. Estos sistemas de funciones fijas lo obligan a hacer concesiones de tiempo y costo versus capacidades.

Usted debe realizar la mayor cantidad de pruebas posible lo antes posible en el proceso de desarrollo para iterar más rápido y garantizar pruebas más económicas y seguras. Puede hacerlo utilizando control y simulación basados en modelos para representar adecuadamente los estímulos y las condiciones del mundo real en el laboratorio. Esto lo ayuda a mover el análisis que anteriormente solo era posible con pruebas en campo al laboratorio de integración de sistemas o plataformas de pruebas a nivel de sistema. Técnicas como la grabación de estímulos del mundo real en campo y "reproducirlos" en el sistema a través de la actuación controlada por modelos están mejorando este tipo de pruebas.
Usted también puede desvincular los requisitos de prueba de los cronogramas de otros equipos simulando sus componentes. Pero para garantizar una fidelidad suficiente en los resultados de las pruebas, debe dedicar tiempo a validar la precisión y la eficacia de los modelos y los métodos utilizados para simular los componentes.
Otro beneficio es la capacidad de probar mejor casos de prueba que son difíciles de replicar, peligrosos y extremos. Esta mayor cobertura de pruebas da como resultado una mayor confianza en el diseño.

A veces, usted no tiene muchas opciones en cuanto al tipo o marca de sensor, actuador, instrumento o software que puede usar para una función en particular. Por lo general, hacer que las distintas piezas de un sistema funcionen juntas es una parte importante del costo del diseño de un sistema de pruebas, especialmente cuando se trata de componentes antiguos del sistema en una actualización o rediseño de un probador heredado. La capacidad de aprovechar una plataforma con una amplia variedad de E/S y capacidades de dispositivos de terceros integradas puede mejorar la eficiencia, maximizando la reutilización y minimizando el trabajo de integración. Una arquitectura de E/S configurable/expansible y distribuida/sincronizada se adapta a las diferentes necesidades de E/S para casos de pruebas a lo largo del proceso de diseño y promueve la reutilización entre programas.

Más medidas a velocidades más altas están creando más datos, muchos más datos, en una variedad de formatos. Y más clientes deben acceder a estos datos a través de los distintos tipos de pruebas en el ciclo de diseño para satisfacer más demandas de reportes. Garantizar que los datos sean útiles, y que realmente se usen, ya es un desafío. Usted debe poder ubicar y cargar datos de manera efectiva, visualizar y analizar de forma interactiva esos datos y ahorrar tiempo al automatizar los reportes. Una arquitectura de pruebas unificada debe proporcionar frameworks de nivel empresarial para gestión de sistemas y gestión de datos compatibles con TI y para mejorar la toma de decisiones, reducir la repetición de pruebas, disminuir el tiempo y el esfuerzo de generación de reportes y aumentar la utilización de activos y el tiempo de operación convirtiendo los datos en un activo, no en una responsabilidad.

Cada vez más, los equipos de pruebas y desarrollo distribuidos globalmente presentan desafíos para administrar de manera efectiva los probadores implementados en esos sitios y correlacionar los datos generados en ellos. Una gestión eficaz de los datos y los sistemas de pruebas distribuidos puede generar grandes ahorros cuando se trata de mejorar información operativa, disminuir el tiempo de inactividad y aumentar la confianza en los datos generados.

Invertir en una arquitectura de pruebas unificada basada en una plataforma de pruebas definida por software es el mejor enfoque en su clase para los equipos que diseñan y prueban sistemas de vehículos electromecánicos avanzados. Este enfoque permite un desarrollo de pruebas más rápido, una mejor cobertura de pruebas, una operación más eficiente, un equipo más ágil y capaz, un menor gasto de capital y un mejor tiempo de actividad y mantenimiento del sistema de pruebas a largo plazo en comparación con el desarrollo personalizado e interno o la subcontratación.