Combinando la ingeniería de sistemas basada en modelos y el diseño basado en modelos para acelerar el desarrollo de la transmisión eléctrica

En la industria de vehículos eléctricos (VE) y eMovilidad, los equipos de ingeniería responsables del desarrollo del tren motriz eléctrico se enfrentan a una serie de desafíos comunes. Estos no solo incluyen una mayor complejidad de los productos, sino también la necesidad de lanzar productos de alta calidad más rápido, manteniendo los costes bajo control y asegurando el grado de conformidad con ASPICE, ISO^® 26262 y otras normas.

Para abordar estos desafíos, tuvimos una oportunidad única en eMoveUs de combinar la amplia experiencia de nuestros empleados en eMovilidad con el inicio desde cero de una nueva empresa. Establecimos un proceso de desarrollo eficiente con una cadena de herramientas consistente que aborda los inconvenientes que habíamos visto en enfoques anteriores.

Luego de una exhaustiva evaluación de las opciones disponibles, adoptamos un flujo de trabajo que combina la ingeniería de sistemas basada en modelos (MBSE) y el diseño basado en modelos utilizando MATLAB^® y Simulink^® junto con el software de gestión del ciclo de vida de aplicaciones (ALM) Polarion™. El proceso de ingeniería de sistemas según ASPICE se puede observar en la Figura 1. Este flujo de trabajo ya tiene ventajas demostradas en varias áreas. Nos permite trabajar a partir de una única fuente de información veraz y obtener una reutilización sustancial de los productos de trabajo entre disciplinas y proyectos. Además, permite que nuestros ingenieros se centren en el desarrollo de funcionalidades en lugar del cumplimiento de procesos al tiempo que se establece la trazabilidad desde los requisitos hasta las arquitecturas, modelos, código y pruebas. Es importante destacar que también nos permite aplicar el paradigma “shift-left” a la ingeniería de sistemas, lo que hace posible analizar el comportamiento dinámico en nivel de sistema y, en particular, identificar errores de especificación en las primeras etapas del proceso general.

Modelado de arquitectura de sistemas con System Composer

En los procesos clásicos de desarrollo de productos, los errores de especificación del sistema a menudo se identifican por primera vez cuando los prototipos están disponibles y se prueban con la especificación del sistema. Esto suele ocasionar altos costes de corrección de errores y en parte provoca retrasos críticos en el proyecto. Para evitar estos costes adicionales e impredecibles debido a errores de especificación en nivel de sistema, nuestro objetivo es verificar la exactitud de la especificación lo antes posible en el proceso. En nuestro flujo de trabajo, utilizamos System Composer™ para definir arquitecturas de sistema simulables, lo que permite “adelantar” las actividades de prueba y validación, y automatizarlas con canalizaciones de CI, como se muestra en la Figura 1.

Además, mantenemos una correspondencia entre los componentes del sistema y sus correspondientes componentes de arquitectura de software en System Composer y Simulink, lo que permite analizar el comportamiento dinámico en nivel de sistema. De este modo, los ingenieros de software pueden utilizar los modelos de comportamiento en nivel de sistema como un borrador, reutilizando no solo las interfaces, sino también los propios modelos de comportamiento definidos en la arquitectura del sistema como punto de partida para el desarrollo de diseños detallados para la producción de software en Simulink. Además, existe una alta reutilización de modelos y entornos de simulación que se utilizan en todos los departamentos. Por ejemplo, el mismo modelo de planta para simulación y pruebas de bucle cerrado se utiliza en los departamentos de sistemas, hardware y software, y también es capaz de ejecutarse directamente en nuestro sistema Speedgoat^® HIL en tiempo real. La Figura 2 muestra un esquema que describe las dependencias.

Además, utilizamos Requirements Toolbox™ y Polarion Connector for Simulink para vincular los requisitos gestionados en Polarion con los elementos arquitectónicos definidos en los modelos de System Composer. También vinculamos los elementos de diseño detallados dentro de los modelos de Simulink de las implementaciones de software utilizando este conector. Esta configuración permite la trazabilidad bidireccional entre la especificación y la implementación sin sincronización manual, lo que facilita la colaboración entre equipos multidisciplinarios y ayuda a garantizar la coherencia durante todo el ciclo de desarrollo..

Modelado físico con Simscape

Las simulaciones de bucle cerrado en nivel de sistema, software o hardware requieren un modelo físico del sistema de propulsión de vehículos eléctricos. Creamos este modelo con Simscape™ y Simscape Electrical™. La Figura 3 muestra una visión general. Este modelo multidominio incluye componentes modulares para la batería del tren motriz, el cable de CC, el filtro de interferencias electromagnéticas (EMI), el inversor, la barra colectora de CA, los trenes motrices eléctricos, los modelos de carga y el sistema de refrigeración. Dentro de este modelo, también podemos incorporar modelos de orden reducido para efectos térmicos y electromagnéticos provenientes de herramientas CAE como Ansys Maxwell para preservar los tiempos de simulación previstos.

Para permitir que nuestros ingenieros seleccionen el nivel de fidelidad de cualquier componente del caso práctico de simulación actual, implementamos un sistema de gestión de variantes utilizando variantes de modelo. Por ejemplo, con Variant Manager for Simulink, un equipo podría optar por ejecutar simulaciones básicas con un bloque de variante que modela la batería como una fuente de voltaje constante simple. Luego, podrían optar por las variantes de circuito RC o RL de la batería para examinar comportamientos capacitivos de baja frecuencia o comportamientos inductivos de alta frecuencia, respectivamente. De manera similar, nuestros ingenieros podrían usar una variante de fuente de voltaje controlada simple para el inversor a fin de acelerar la simulación o seleccionar una variante de mayor fidelidad con un comportamiento de conmutación realista para evaluar los efectos de PWM. La Figura 4 muestra como manejar estas variantes en Variant Manager.

Simulación de bucle cerrado, generación de código y pruebas de HIL en tiempo real

Con la arquitectura del sistema descrita en System Composer y el modelo detallado de la planta listo, es posible ejecutar simulaciones de bucle cerrado en varios niveles utilizando modelos de comportamiento del sistema, modelos de arquitectura de software o modelos de diseño detallado en Simulink, como se muestra en la Figura 5.

Nos permite adelantar nuestras actividades de validación que ya están en nivel de sistema, minimizando así los errores de especificación de funciones complejas del sistema de accionamiento.

Dentro de este entorno, podemos analizar el comportamiento del producto en nivel de sistema utilizando MATLAB y el Data Inspector, para visualizar señales, métricas de rendimiento y relaciones temporales. Un ejemplo de los resultados de la simulación de bucle cerrado de nuestra arquitectura de sistema para analizar el comportamiento de control de corriente de un controlador de campo orientado puede verse en la Figura 6. Las pruebas automatizadas pueden ejecutarse en esta configuración de bucle cerrado en nivel de sistema o en componentes arquitectónicos dedicados utilizando Simulink Test™. Además, estos resultados de pruebas se sincronizan automáticamente con Polarion para permitir el seguimiento y la generación de informes actualizados del proyecto en relación con la especificación del caso de prueba.

Este enfoque de desarrollo coherente no se detiene en los límites del dominio sino que continúa más allá. El ciclo en V abarca distintas etapas, que comienzan con la especificación del sistema y continúan con la especificación del software, la arquitectura, el diseño basado en modelos y la implementación. Luego de completar estas fases, el flujo de trabajo prosigue con la generación de código y pruebas de MIL, PIL y HIL. En esta etapa, utilizamos Embedded Coder^® para generar código a partir de nuestros modelos de arquitectura de software o diseño detallado en Simulink, integrarlo en una pila AUTOSAR^® y desplegarlo en un microcontrolador Infineon^® AURIX™ TC3xx. El modelo de planta ya presentado se despliega en FPGA en una plataforma objetivo en tiempo real Speedgoat utilizando HDL Coder™ y Simulink Real-Time™. Esta configuración permite verificar el comportamiento correcto del software del producto final en un entorno de HIL. Además, con el fin de aprovechar sinergias y reducir los costes de equipos y desarrollo, se utiliza la misma plataforma HIL para realizar pruebas de integración y verificación del sistema antes de las pruebas finales en un banco de pruebas.

Beneficios obtenidos y mejoras continuas de integración

El enfoque basado en flujos de trabajo y cadenas de herramientas se validó durante el desarrollo de un inversor de carburo de silicio de 800 V, capaz de suministrar hasta 600 kilovatios de potencia máxima para aplicaciones de tracción en automoción. Participar en MathWorks Startup Program nos ayudó a acortar el tiempo de lanzamiento al mercado mientras manteníamos los costes bajos, lo cual es fundamental para prácticamente todas las startups.

Seguimos ampliando y mejorando nuestro flujo de trabajo. Por ejemplo, ya estamos usando CI con Jenkins^® y Bitbucket^® para realizar continuamente pruebas unitarias, de integración y de verificación de software. También estamos trabajando para ampliar este flujo de trabajo de automatización basado en CI hacia las etapas iniciales del ciclo V para permitir la verificación automatizada basada en CI de nuestras arquitecturas de sistema.