“La combinación de este modelado con las herramientas de NI dan lugar a un sistema “estado del arte” para el desarrollo, validación de controladores en el sector de la automoción.”
El Reto
En el sector de la automoción es clave la validación de los sistemas de control antes de ser instalados en el vehículo. Una de las etapas previas a esta instalación consiste en la integración de la ECU implementada con las demás ECUs con las que debe intercambiar datos para su correcto funcionamiento. El reto es implementar modelos que emulen a las ECUs no disponibles, tanto en funcionalidad como en comunicaciones.
La Solución
Utilizar LabVIEW como entorno de desarrollo para el modelado en tiempo real de las ECUs virtuales necesarias para el testeo de sistemas de control.
La integración de estas ECUs virtuales permite simular el funcionamiento de los sistemas electrónicos instalados en un vehículo. Estos sistemas se pueden activar/desactivar a demanda según los sistemas reales estén disponibles, ampliando así su tiempo de utilización.
Caso de Estudio
Tecnalia tiene una amplia experiencia en el sector de la automoción y en el desarrollo de controladores embebidos en ECUs del powertrain. La tendencia de esta industria y la reciente normativa ISO26262 provoca que los sistemas sean probados en diferentes fases de la V.
Inicialmente se pueden hacer validaciones parciales de los componentes, ya que cada compañía involucrada en el proyecto puede ser autónoma hasta que el software de control se ha embebido en el microcontrolador, generándose una ECU.
El problema surge cuando comienza la integración (etapa previa a la instalación en el vehículo) debido a que todas las ECUs con las que se intercambian datos pueden no estar disponibles en todo momento.
La idea del proyecto surgió para dar cobertura a esta problemática, generándose diferentes ECUs virtuales que modelasen los sistemas de control presentes en el powertrain de un vehículo para:
Validar la ECU implementada sin necesidad de las ECUS reales.
Comprobar las comunicaciones.
Inyectar fallos en sensores, en comunicaciones y en funcionalidad de las ECUs de donde nuestro sistema lee datos para comprobar el funcionamiento de la ECU en pruebas.
Hacer ensayos automáticos y repetitivos para verificar la robustez de la ECU en diferentes escenarios.
En este proyecto el objetivo era testear la ECU de tracción de un vehículo eléctrico con caja de cambios. Esta ECU se encarga de calcular la consigna de par al inversor que gobierna el motor que propulsa el vehículo en función de:
Las demandas del conductor (acelerador, freno, cambio).
El estado del vehículo (ABS, ESP, TCS).
El estado del sistema de tracción (carga de la batería, estado del motor y del inversor).
Para cumplir la funcionalidad requerida por la ECU era necesario construir un modelo completo de powertrain de forma que se generase toda la información requerida para las pruebas.
Dependiendo de la ECU a virtualizar muchas tendrán dos partes bien diferenciadas en el código. Una de ellas se encargará del modelo físico del sistema a controlar y la otra parte del control del sistema y la generación de las comunicaciones. En este caso y dado el sistema a testear se virtualizaron las siguientes ECUs:
ECU del sistema de almacenamiento de energía.
Al tratarse de un vehículo eléctrico se modeló el funcionamiento de una batería, calculándose los valores más típicos necesarios para el correcto funcionamiento, tales como valor instantáneo de corriente en las fases de carga y descarga, estado de carga, voltaje de la batería dependiendo de la corriente actual y del estado de carga y potencia en la red eléctrica del coche en función de la demanda del motor y de los equipos auxiliares conectados a ella.
ECU de inversor
En este caso se modeló tanto el comportamiento eléctrico del equipo de potencia (inversor) como el de un motor de imanes permanentes. Los datos accesibles del modelo son el valor actual del par del motor dependiendo de la consigna de par, la eficiencia del motor y la imagen térmica, el valor de la velocidad en función de la velocidad del vehículo y de la marcha actual, así como el valor de la corriente en función del par del motor y del punto de funcionamiento (zona de potencia constante o zona de par constante).
ECU de acelerador
Esta ECU se encarga de recibir la información del acelerador y enviarla por la red de comunicaciones.
ECU de freno (ABS, ESP)
Esta ECU lee la demanda de frenado del conductor y calcula el reparto de frenada entre el freno mecánico y el eléctrico. Adicionalmente lee los sensores de las ruedas y realiza las funciones de ABS y ESP, demandando valores de par al equipo en función del estado del vehículo.
ECU general del vehículo (ECU central)
Esta ECU se encarga de mostrar en pantalla al conductor los datos más relevantes del sistema de propulsión, tales como velocidad del motor, estado de carga de las baterías, par en el motor, etc. Todas las ECUs virtuales necesitaban ser integradas en una plataforma de tiempo real, con lo que surgió la necesidad de utilización de algún software con los siguientes requisitos:
Capacidad de integrar las diferentes ECUs para generar el modelo completo de la planta y que generase el código final para descargarlo en el sistema de tiempo real.
Que las ECUs pudiesen estar implementadas en lenguajes de programación que no necesariamente fuesen LabVIEW.
Facilidad de intercambio de modelos y de uso del sistema.
Capacidad de “conectar/desconectar” las ECUs dependiendo de las que estén disponibles en cada etapa del proyecto.
Posibilidad de generación de informes, registros.
Capacidad de conectarse con un HMI para visualizar los datos de funcionamiento.
Estas necesidades fueron satisfechas por el software VeriStand. Gracias a él se han disminuido los tiempos de programación y customización de la herramienta para cada cliente, con lo que se han podido dedicar los esfuerzos al testeo y mejora del modelo. Es por ello que las ECUs virtuales han sido programadas en LabVIEW y se han compilado posteriormente para VeriStand y se ejecutan en una PXI dedicada. Dado que varias de ellas tienen modelos físicos del sistema se ejecutan a un tiempo básico de 1 milisegundo. Internamente en el código se hacen subtareas para emular el software de control y las comunicaciones.
Todo el proyecto se descargó en una PXI-8110 dedicada en la que la información necesaria del coche provenía de otra PXI-8110 donde estaba instalado Dynacar, un modelo de vehículo de dinámica longitudinal y lateral. Los sensores virtuales que generaba Dynacar se enviaban a la PXI de las ECUs virtuales de la misma forma que se leen en el coche, bien por señales analógicas o por bus de campo.
Adicionalmente y al utilizar PXI la programación del bus de comunicaciones (en este caso CAN) fue extremadamente sencilla utilizando el módulo NI-XNET donde se definen los mensajes con los datos a intercambiar.
Muchos de los controladores diseñados tienen que ser robustos y estables ante cambios en los sistemas a controlar. En este caso cada ECU virtual puede generar datos erróneos, tanto en funcionamiento como en comunicaciones para testear la respuesta de los controles diseñados. Adicionalmente la ECU bajo testeo posee parámetros que son modificables por el usuario y que hay que comprobar en todo su rango.
Ante estas dos necesidades se utilizó el software TestStand de forma que se pudieron realizar multitud de ensayos automatizados, tanto cambiando parámetros de los modelos como parámetros de la ECU bajo testeo.
Estos últimos se modificaron utilizando el protocolo CCP, estándar en la automoción para la parametrización de sistemas.
Resultados
Mediante este modelado de los componentes electrónicos y comunicaciones de un sistema de propulsión de un vehículo eléctrico/híbrido se han conseguido reducir los tiempos de integración de las ECUs de desarrollo al ser testeadas previamente con modelos virtuales de ECUS no disponibles así como validar los algoritmos de control. Al ser un sistema versátil donde se pueden ir conectando y desconectando las ECUs según están disponibles se puede utilizar en diferentes fases del proyecto.
Todo esto reduce el tiempo de integración y testeo, provocando un importante ahorro de costes en el desarrollo de sistemas de control en automoción. La combinación de este modelado con las herramientas de NI dan lugar a un sistema “estado del arte” para el desarrollo, validación de controladores en el sector de la automoción.
