Porsche Battery System Solutions For Motor Racing And Series Production

Porsche Battery System Solutions For Motor Racing And Series Production

Porsche Engineering lleva más de 20 años desarrollando soluciones de sistemas de baterías de alto rendimiento para la competición automovilística y la producción en serie. El sistema de gestión de la batería (BMS) tiene la tarea de evaluar el estado de la batería, definir los límites de funcionamiento actuales y garantizar el funcionamiento dentro de esos límites.

En los vehículos eléctricos de batería (BEV), el sistema de gestión de baterías (BMS) desempeña un papel fundamental. Se compone del controlador de gestión de la batería (BMC) y de los controladores del módulo de celdas (CMC). Los CMC están integrados directamente en los módulos de la batería de alto voltaje y suministran al BMC valores medidos como el voltaje y la temperatura de las celdas. También se encargan del equilibrado de las células: Las baterías de alto voltaje se componen de un gran número de celdas individuales de batería de bajo voltaje. Sin embargo, las tolerancias hacen que las celdas tengan sus propias propiedades físicas individuales, lo que puede causar problemas al utilizar el sistema. Para evitarlo, las CMC equilibran el estado de carga de las celdas, ya sea pasivamente mediante resistencias conectadas en paralelo, o activamente transfiriendo carga de las celdas más débiles a las más potentes. La BMC es el elemento central del BMS y utiliza sus propios sensores de corriente, además de los valores medidos por las CMC. Una de sus funciones es garantizar que la batería funcione de forma segura. Después de todo, los sistemas de baterías contienen grandes cantidades de energía y son capaces de liberar esta energía muy rápidamente. Cualquier liberación incontrolada o involuntaria debe evitarse a toda costa. Además, el BMC debe encontrar un compromiso óptimo entre la duración y el rendimiento de la batería, ya que el funcionamiento fuera de los parámetros especificados puede causar daños en el sistema. Las causas típicas son corrientes excesivamente altas; temperaturas excesivamente altas o bajas, que dañan el electrolito o provocan una mayor sensibilidad a la corriente; y sobretensión o subtensión, que pueden dañar el electrolito o los materiales activos.

Para evitarlo, el BMS se utiliza para cambiar los límites de corriente, restringir los modos de funcionamiento o ajustar la refrigeración en función del estado de la batería. "A partir de los valores medidos por numerosos sensores de temperatura, corriente y tensión, el BMS obtiene tres parámetros cruciales de la batería: El estado de carga (SoC) y la capacidad, que determinan la autonomía restante, y la resistencia interna, que limita el rendimiento", explica Lukas Mäurer, Project Leader High-Voltage Battery Functions en Porsche Engineering. "También es responsable de las funciones de seguridad, como la desconexión por sobrecorriente y la detección de colisiones, así como de la comunicación con los demás controladores del vehículo".

Crédito de la imagen: Porsche Media

Más de 20 años de experiencia
Porsche Engineering ya ha desarrollado diversos BMS por encargo de clientes y puede encargarse de todas las tareas que surjan en relación con el modelo V, desde estudios de requisitos hasta pruebas de vehículos. "Como empresa, llevamos más de 20 años trabajando en este campo, y yo personalmente llevo seis años dedicado a los sistemas de gestión de baterías", afirma Mäurer. A pesar de toda la experiencia adquirida a lo largo de numerosos proyectos, desarrollar un BMS sigue siendo una tarea difícil incluso para desarrolladores experimentados: El software es excepcionalmente complejo, lo que plantea varios retos tanto para la ingeniería como para la gestión del proyecto. Por ello, Porsche Engineering concede gran importancia a un proceso riguroso y transparente. Comienza con la gestión de requisitos, algo a lo que los expertos prestan especial atención. "Y no se trata sólo de sentar las bases técnicas: aquí también se decide el curso ulterior del proyecto", subraya Achim Olpp, jefe de proyecto de Porsche Engineering.

Comprobación de las especificaciones
Los problemas potenciales deben detectarse y eliminarse comprobando un nuevo pliego de condiciones nada más redactarlo. Olpp se refiere a la "regla de los diez". Con cada etapa del desarrollo de software, los costes de rectificación de errores se multiplican por diez. El esfuerzo que supone aumenta con cada etapa del proceso, ya que hay que comprobar y rehacer el trabajo ya realizado desde el punto en que surgió el error. Los errores posteriores también deben "detectarse" de nuevo. Esto pone en peligro casi automáticamente lo que a menudo son calendarios ajustados, especialmente en el caso de software que existe en diferentes versiones personalizadas para múltiples clientes.

Para evitar este tipo de trabajo adicional, el autor de las especificaciones de requisitos del software, bajo la dirección del ingeniero de requisitos, convoca a todos los participantes en el proyecto para una "revisión" de las especificaciones proporcionadas por el cliente. "Todo el mundo se reúne alrededor de la mesa, incluidos los arquitectos y desarrolladores de software, así como los probadores y el cliente", explica Olpp. "Es una forma mucho mejor de entender los requisitos que surgen de las especificaciones y de definir las posibles soluciones para las especificaciones de forma más sistemática". Cuando hay varios clientes, la revisión brinda la oportunidad de armonizar los distintos intereses". Aunque esto aumenta un poco la carga de trabajo al principio, a la larga supone un importante ahorro de tiempo. La planificación de los ámbitos de trabajo se basa en esta sólida base. "Celebramos un taller de capacidad dos semanas antes de cada ciclo de lanzamiento de software para ajustar las necesidades del cliente a los recursos disponibles", informa Olpp. "Así sabemos exactamente qué se puede hacer en el tiempo disponible. Y el cliente puede priorizar los paquetes de trabajo cuando proceda."

Visión clara de las capacidades Una gestión precisa de las capacidades también puede ayudar a evitar la temida "ampliación del alcance". Esto ocurre cuando los requisitos de un producto cambian de forma continua y espontánea durante su desarrollo, lo que a menudo provoca retrasos. "Si se identifican claramente las capacidades, también se pueden comprender y coordinar mejor los efectos de este tipo de dinámica de requisitos", afirma Olpp. Sobre todo cuando se utilizan piezas de arrastre de software para varios modelos y marcas, hay que tener mucho cuidado en este paso. Los alcances mal integrados pueden poner en peligro simultáneamente varias series de vehículos debido a la programación modular. Los arquitectos de software también se enfrentan a varios retos durante el desarrollo de BMS. Entre otras cosas, deben tener en cuenta que la química celular y el diseño de las baterías evolucionan constantemente.

"Un sistema de refrigeración de baterías modificado influye, entre otras cosas, en la gestión térmica", explica Mäurer. "La temperatura de cada una de las celdas de la batería no puede determinarse completamente mediante sensores. Por ejemplo, si se utilizan 60 sensores para determinar la temperatura de 200 celdas, la arquitectura del software debe admitir diferentes posiciones de instalación de los sensores y diferentes conceptos de refrigeración, como placas de refrigeración de varios lados." Por eso, las funciones de los sistemas de gestión de edificios deben desarrollarse de modo que se adapten fácilmente a esos cambios, afirma. En lo que respecta a la arquitectura del software, el uso de piezas de arrastre de software también plantea retos adicionales. Hacen falta estructuras modulares que cumplan los requisitos de un vehículo concreto, pero que no supongan desventajas en otros modelos.

Adaptación a los recursos
La fase de desarrollo de software sigue a la definición de la arquitectura del software y tiene como objetivo hacer que las soluciones de predesarrollo sean adecuadas para la producción en serie. Una tarea típica, por ejemplo, es adaptar los algoritmos a los recursos limitados en términos de potencia de procesamiento y capacidad de memoria de las unidades de control de los vehículos, sin comprometer la calidad de los resultados. "En el predesarrollo, normalmente sólo se controla una célula con sensores; en el vehículo, hay varias docenas", dice Mäurer. "Pero no se puede simplemente ejecutar el algoritmo utilizado para un prototipo docenas de veces seguidas en la producción en serie, porque eso haría que la potencia de procesamiento necesaria fuera demasiado alta". Los BEV también utilizan muchas funciones innovadoras, por ejemplo para la carga rápida. A menudo funcionan al límite de lo técnicamente viable en la actualidad. Durante la transición de prototipo a producción, estas funciones deben ser lo suficientemente robustas como para funcionar sin problemas en todas las condiciones. "En el caso de la carga rápida, esto podría lograrse implementando algoritmos de control que limiten la corriente de carga en caso de sobrecalentamiento inminente o de sobretensión", afirma Mäurer.

Si el cliente también persigue una estrategia de transferencia de piezas de software, los desarrolladores también deben garantizar un alto grado de adaptabilidad de sus funciones, por ejemplo, para adaptarse a diferentes químicas celulares o conceptos de hardware. "El desarrollo de software para la producción en serie es un servicio de transferencia para el que Porsche Engineering, entre otros, está especialmente bien preparado", resume Mäurer. "Hemos adquirido mucha experiencia en el desarrollo de BMS, desde la competición automovilística hasta la producción a gran escala. Nuestras soluciones están presentes en todas las marcas del Grupo Volkswagen, pero también en el 919 Hybrid, el ganador de Porsche en Le Mans." Además, Porsche Engineering también tiene sus propios conocimientos sobre células y baterías, así como experiencia con nuevas tecnologías como las redes de 800 voltios en vehículos. Durante la prueba de módulos, los expertos evalúan por primera vez si el software desarrollado cumple los requisitos. En esta prueba, las unidades más pequeñas de los programas -por ejemplo, para calcular la capacidad residual- se alimentan con valores de entrada definidos. Si los resultados son los esperados, el algoritmo funciona correctamente. En caso contrario, los programadores tienen que modificar el código del programa. "Como primer paso de verificación, la prueba de módulos ofrece muchas posibilidades de ahorrar tiempo y dinero", afirma Mäurer. "Después de todo, cualquier cosa que se encontrara aquí requeriría un esfuerzo significativamente mayor para solucionarlo más adelante en el proyecto".

Principio de doble control durante las pruebas
En Porsche Engineering se aplica el principio de control dual para la comprobación de módulos: La programación y la comprobación corren a cargo de empleados diferentes. Al final, se incorpora un representante del control de calidad que, además del resultado, valida los procesos de desarrollo realizados con anterioridad. De este modo se garantiza que los siguientes pasos del modelo V -integración, software y pruebas de vehículos- se basen en una buena base. Al fin y al cabo, el consejo del jefe de proyecto Olpp se aplica a todo el proceso de desarrollo: "Sin procesos sólidos, un proyecto de BMS es como un rascacielos sin cimientos estables".

... notas de SP