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.

“A modified battery cooling system has an impact on thermal management, among other things,” explains Mäurer. “The temperature of the individual battery cells cannot be completely determined using sensors. For example, if 60 sensors are used to determine the temperature for 200 cells, the software architecture must support different sensor installation positions and different cooling concepts such as multi-sided cooling plates.” This is why BMS functions must be developed so that they are easy to adapt to such changes, he says. When it comes to software architecture, the use of software carry-over parts also leads to additional challenges. They necessitate modular structures that meet the requirements of a specific vehicle, but do not result in disadvantages in other models.

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.

If the customer is also pursuing a software carry-over part strategy, developers must also ensure a high degree of adaptability of their functions, for example to adapt to different cell chemistries or hardware concepts. “Software development for series production is a transfer service for which Porsche Engineering, among others, is particularly well suited,” as Mäurer sums up. “We have gained a lot of experience in BMS development, from motor racing to large-scale production. Our solutions are present in all brands within the Volkswagen Group, but also in the 919 Hybrid, Porsche’s Le Mans winner.” In addition, Porsche Engineering also has its own cell and battery expertise, as well as experience with new technologies such as 800-volt networks in vehicles. The experts evaluate how well the software that was developed meets the requirements for the first time during the module test. In this test, the smallest units of the programs—for example, for calculating residual capacity—are fed with defined input values. If they deliver the expected results, the algorithm is, basically, working correctly. Otherwise, the software developers have to edit the program code. “As the first verification step, the module test offers a lot of potential to save time and money,” says Mäurer. “After all, anything found here would require significantly more effort to fix later in the project.”

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".

… notes from SP