Modelado de vehículos virtuales para simulaciones a gran escala en la nube

Las empresas de automoción de toda la industria dependen cada vez más de métodos de desarrollo virtuales que utilizan modelos de vehículos para permitir la creación, validación e integración de prototipos virtuales. Este enfoque ofrece ventajas significativas, tanto en ahorro de costos como en reducción del tiempo de desarrollo, porque los prototipos físicos se utilizan únicamente para la validación final.

Sin embargo, los equipos de ingeniería están descubriendo que es necesario superar algunos obstáculos antes de poder aprovechar los beneficios del desarrollo virtual. En primer lugar, los equipos deben crear modelos de vehículos virtuales con el nivel adecuado de fidelidad. Es decir, el modelo debe ser lo suficientemente detallado para capturar los efectos de interés, pero no tanto como para que los tiempos de simulación sean prohibitivos. A continuación, deben integrarse modelos de plantas físicas y modelos de software. Los equipos de ingeniería también necesitan incorporar escenarios de conducción que ejecuten el modelo de bucle cerrado y visualizar los resultados de la simulación para extraer información útil. En muchos casos, también necesitan una forma de ejecutar simulaciones a gran escala para respaldar los estudios de tradeoff u optimizaciones del diseño.

En este artículo, describimos un flujo de trabajo que aborda todas estas áreas clave. El flujo de trabajo incluye la construcción de un modelo con la app Virtual Vehicle Composer , personalizando ese modelo, usándolo para ejecutar simulaciones en escritorio y luego implementándolo en la nube para ejecutar estudios a gran escala (Figura 1). Muchos clientes de MathWorks ya utilizan este flujo de trabajo o uno similar para reducir el tiempo de simulación, simplificar las simulaciones basadas en la nube y dar soporte a un número creciente de casos prácticos de modelado de vehículos virtuales.

Generación y personalización de un modelo de vehículo virtual

Construir un modelo de vehículo desde cero no es una tarea trivial. Es de gran ayuda comenzar con un modelo de referencia antes de personalizarlo para cumplir con los requisitos de un proyecto en particular. Esa es una de las razones por las que MathWorks, durante varios años, ha estado proporcionando aplicaciones de referencia de vehículos para una amplia variedad de pruebas y maniobras vehiculares. En R2022a, MathWorks lanzó la app Virtual Vehicle Composer en Powertrain Blockset™ y Vehicle Dynamics Blockset™. Esta app facilita aún más a los equipos de ingeniería la configuración y construcción de vehículos virtuales para pruebas y análisis de rendimiento a través de una interfaz de usuario intuitiva. Al usar la app, los ingenieros comienzan seleccionando un tren motriz para el vehículo (por ejemplo, un tren motriz EV de dos motores), especificando un modelo exclusivamente longitudinal o uno que también incluya dinámica lateral y configurando parámetros clave, como la masa del vehículo, tamaño de los neumáticos, par motor máximo, etc. Luego pueden seleccionar qué casos de prueba ejecutar a partir de un conjunto de ciclos de conducción y maniobras, así como qué señales registrar durante las simulaciones. Una vez realizadas estas opciones de configuración, un solo clic generará un Simulink^® modelo que está listo para la simulación (Figura 2).

La app Virtual Vehicle Composer permite a los equipos configurar y generar modelos completos en cuestión de minutos. Sin embargo, lo más importante es que el modelo resultante es totalmente personalizable, por lo que los equipos pueden ampliarlo con nuevas características de planta, controlador o modelo de sensor, o con funciones adicionales escritas en C o MATLAB.^®.

Para ilustrar esta parte del flujo de trabajo, implementamos un caso práctico en el que personalizamos una versión de un modelo de vehículo eléctrico generado con la app Virtual Vehicle Composer y luego lo usamos para estudiar el rendimiento de un sistema autónomo de frenado de emergencia (AEB).

El modelo de vehículo eléctrico que generamos no incluía los sensores, los algoritmos de control ni los escenarios de prueba necesarios para ejecutar las pruebas AEB, por lo que incorporamos estos componentes desde una modelo de muestra de Automated Driving Toolbox™.  En ese momento, era cuestión de arrastrar y soltar los componentes del AEB que necesitábamos, conectar las señales necesarias para integrarlas en la estructura del modelo y copiar los parámetros del vehículo y los datos de calibración del controlador del modelo de muestra del AEB. El modelo de bucle cerrado resultante, que incluía tanto la planta de vehículos eléctricos como el controlador AEB, comprendía cerca de 33.000 bloques (Figura 3).

Simulaciones en escritorio

Una vez que se ensambla y configura un modelo de sistema completo, el siguiente paso en el flujo de trabajo es realizar simulaciones en el escritorio. En nuestro caso práctico de ejemplo, el objetivo era comprender qué tan bien funcionaba el algoritmo de control AEB para el vehículo eléctrico que habíamos modelado. Por ejemplo, queríamos saber si el controlador detuvo el automóvil de manera segura (sin colisiones) en una variedad de escenarios y una variedad de pesos de vehículos. También queríamos evaluar parámetros de control clave, como la aplicación inicial de la fuerza de frenado (o presión de frenado) y el momento específico en que los frenos se aplicaron por completo (Figura 4). Las simulaciones en escritorio brindan una manera de validar el modelo, evaluar la configuración de la prueba y verificar los scripts de automatización con un conjunto limitado de ejecuciones de prueba antes de escalar a un estudio más completo.

Para diseñar escenarios de conducción sintéticos para las pruebas, utilizamos la app interactiva Driving Scenario Designer de Automated Driving Toolbox, que también proporciona varios AEB y aplicaciones de ejemplo para evitar colisiones. Teníamos un criterio simple de aprobación/rechazo para cada escenario: Si el vehículo ego se detuvo antes de chocar con el vehículo, peatón u obstáculo en su trayectoria, entonces la prueba fue superada (Figura 5).

Queríamos ejecutar varios casos de prueba, por lo que decidimos automatizar la ejecución de la prueba, que se puede realizar mediante un script MATLAB o Simulink Test™. Para la ronda inicial de simulaciones en escritorio, decidimos ejecutar 16 pruebas diferentes, variando parámetros, como la velocidad del vehículo, tanto en la planta como en el algoritmo de control, así como en el escenario de prueba para ejercitar el sistema en una amplia gama de condiciones. En un único núcleo de procesamiento, este barrido de 16 ejecuciones tardó unos 23 minutos en completarse. Para acortar los tiempos de simulación, utilizamos Parallel Computing Toolbox™ para ejecutar las mismas pruebas en paralelo en cuatro núcleos. Esto redujo el tiempo de simulación a poco más de 7 minutos. Sin embargo, incluso a este ritmo más acelerado, nos llevaría días completar el estudio factorial completo que queríamos ejecutar, que implicó miles de simulaciones. Estos estudios a gran escala se adaptan bien a la nube. Realizar este barrido de parámetros a pequeña escala primero en el escritorio nos permitió confirmar que nuestros scripts de automatización para ejecutar las simulaciones y verificar el criterio de aprobación/rechazo funcionaron según lo previsto. Eso, a su vez, nos dio la confianza para ampliar el estudio a una combinación mucho mayor de condiciones de prueba en la nube.

Ejecución de estudios de simulación a gran escala en la nube

Hay muchas razones para ejecutar simulaciones en la nube. Escalar, para aprovechar mayores recursos de cálculo, es una motivación común. Es posible que los ingenieros también quieran simplemente descargar trabajos computacionales de su estación de trabajo principal, o que los equipos quieran acceso bajo demanda a hardware computacional especializado que solo se necesita ocasionalmente.

Cuando se trabaja en MATLAB, la transición del escritorio a la nube es sencilla; no es necesario reescribir scripts o algoritmos. MathWorks ofrece arquitecturas de referencia para ejecutar MATLAB y Simulink en máquinas virtuales (VM) en la nube, así como contenedores prediseñados que se pueden implementar en la nube.

Para nuestro estudio, utilizamos la arquitectura de referencia para ejecutar MATLAB Parallel Server™ en Amazon^® Web Services. Disponible en GitHub^®, esta arquitectura de referencia facilita el inicio de instancias de máquinas virtuales de Windows® o Linux® basadas en el último MathWorks® Amazon Machine Images (AMI) prediseñado, incluso para equipos con poca o ninguna experiencia en la nube. Una vez que se lanzó la instancia, nos conectamos a ella a través de un escritorio remoto, cargamos nuestros archivos de configuración de prueba y luego estuvimos listos para comenzar a ejecutar pruebas en un cluster de VM Linux con cuatro máquinas de 32 núcleos.

Realizamos un estudio factorial completo que incluyó 28 escenarios, 16 valores para un parámetro del modelo de planta y cinco valores cada uno para dos parámetros de control. Esto resultó en un conjunto de pruebas de 11.200 simulaciones. En la nube, las pruebas se completaron en unos 90 minutos, mientras que en una estación de trabajo de cuatro núcleos, el mismo estudio habría llevado unos dos días.

Al revisar los resultados de este estudio, confirmamos que el controlador AEB fue razonablemente sólido en todas las pruebas. Sí notamos algunos casos de falla, en los que el vehículo virtual no logró detenerse a tiempo (Figura 6). En un flujo de trabajo típico, estos casos se examinarían con más detalle en el escritorio, donde los ingenieros analizarían los resultados en MATLAB y Simulink para identificar la causa raíz del fallo y decidirían cómo solucionar el problema (por ejemplo, ajustando los parámetros del controlador) y, si es necesario, actualizar el modelo para una prueba de seguimiento en la nube. Los estudios de simulación a gran escala con modelos de vehículos virtuales facilitan la identificación de estos posibles casos de fallo y permiten a los equipos de ingeniería centrarse en problemas potencialmente críticos en las primeras etapas del proceso de diseño.

Conclusión

A medida que el desarrollo de vehículos virtuales se vuelve más central en el flujo de trabajo de automoción general, los equipos de ingeniería necesitarán formas de mantenerse al día con la demanda cada vez mayor de simulación. Virtual Vehicle Composer proporciona a los equipos una importante ventaja de productividad en esta área al permitirles configurar rápidamente modelos de vehículos adecuados. Debido a que estos modelos no son cajas negras, los ingenieros tienen la flexibilidad de mejorarlos y personalizarlos rápidamente en Simulink según las necesidades específicas de su proyecto. Además, los equipos pueden continuar usando MATLAB y Simulink junto con el cálculo en la nube para automatizar estudios de simulación a escala y analizar sus sistemas en una amplia gama de condiciones para identificar problemas potenciales, evaluar tradeoff de diseño y realizar optimizaciones.