La solución de software que salvó la victoria de Porsche en Daytona

Una sorprendente acción de retaguardia entre las filas de ingeniería de Porsche Penske Motorsport, y por supuesto sus ágiles pilotos, salvaron la victoria de la marca alemana y del equipo de Roger Penske en las 24 Horas de Daytona 2024, en lo que podría haber sido un caso de derrota a las puertas de la gloria.

Después del decepcionante debut del 963 en el mismo circuito en 2023, plagado de problemas con la batería híbrida y la caja de cambios, el inicio de la temporada 2024 de la IMSA estuvo relativamente libre de problemas, más allá de que su coche #6, que quedó cuarto, fue penalizado por "no adherirse a los parámetros controlados del tren de potencia".

Otros Porsche, incluidos los coches cliente, recibieron advertencias por el mismo problema, pero no se vieron obligados a asumir penalizaciones después de que se identificaran las "correcciones" de software y se distribuyeran entre las cuatro unidades en pista para evitar que volviera a ocurrir.

Una vez terminadas las 24 Horas, el director de la fábrica LMDh de Porsche, Urs Kuratle, fue preguntado por el problema que provocó la penalización del coche #6, y explicó: "Fue potencia hecha básicamente cuando el coche se estaba cargando, especialmente hacia la chicane del Bus Stop. Tuvimos picos y fueron demasiado para el sistema, por decirlo de alguna manera. Se hicieron correcciones, y eso fue todo".

Eso permitió a Felipe Nasr hacer su trabajo en pista, para batir al favorito antes de la carrera, Cadillac, por apenas dos segundos tras una jornada de duras batallas entre ambas marcas. También significó que Michael Steiner, miembro de la junta ejecutiva de desarrollo de Porsche AG, recibiera el trofeo de los equipos en el podio mientras la marca registraba su récord de 19 victorias generales en Daytona.

En los días posteriores a la carrera, en Motorsport.com pudimos hablar con Jonathan Diuguid, director general de Porsche Penske para el programa LMDh, y a Raúl Prados, el ingeniero jefe de carrera del victorioso coche #7.

"Por la razón que sea, el #6 fue el primero en experimentar los problemas, así que se resintió mientras que el otro no, para que no repitiéramos el mismo error dos veces", explicó Diuguid. Y Prados añadió: "No experimentamos los problemas nosotros mismos, pero éramos conscientes de que estaban ocurriendo en el #6, y los dos coches son exactamente iguales. Tomamos precauciones, así que aplicamos la solución antes de experimentar el problema".

A la pregunta de por qué le ocurrió a uno y no al otro, Prados respondió: "No estoy seguro, ¿probablemente una cuestión de sincronización? Realmente no puedo explicarlo porque las mismas condiciones podrían haberse aplicado en nuestro coche. No puedo explicar por qué sucedió".

Diuguid se explayó sobre la complejidad de los sistemas, que se utilizan para limitar la cantidad de energía regenerada y desplegada a través de los MGU-K con el que corren todos los coches de la categoría GTP.

"Todos estos controladores y demás son extremadamente complejos, por lo que es necesario que se produzcan determinados casos. Ya sea un bloqueo de frenos o cómo uno de los pilotos se lleva por delante un piano, son cosas como esas las que pueden violar el controlador", detalló.

"Así que, una vez que sucedió en el #6 tratamos de analizar lo que era, y luego Raúl y los otros ingenieros de carrera hablan con la sala de operaciones para tomar medidas y asegurarse de que los pilotos están preparados. Estoy seguro de que Raúl tuvo muchas conversaciones con Matt Campbell y Dane Cameron antes de que subieran al coche, diciendo 'hey, eviten esto y asegúrense de que los ajustes son de esta manera', y ese tipo de cosas".

"Obviamente, no entramos en la carrera planeando tener problemas, y tres paradas y penalizaciones en el coche #6, porque no habíamos experimentado estos escenarios antes. Por lo tanto, se trataba sólo de la reacción, después de entender por qué había sucedido, y asegurarse de que teníamos medidas tan pronto como sea posible", continuó.

"Uno de los puntos principales era que esas contramedidas que estábamos poniendo en marcha estaban restando rendimiento, porque teníamos que dar márgenes más grandes a los límites de control, así que es algo que todavía estamos intentando analizar".

Mientras que en la vida cotidiana estamos acostumbrados a tomarnos tiempo para aplicar las actualizaciones de software en nuestros smartphones y ordenadores portátiles, no hubo necesidad de parar los 963 ni de reiniciar sus sistemas. Todo el software necesario ya estaba programado en el cerebro electrónico del coche, pero los pilotos tenían que seleccionar los ajustes correctos en la cabina a través de los mandos del volante.

"Una vez que comprendimos dónde se originaba el problema, lo primero que hicimos fue intentar ayudar a los pilotos en todo lo posible", dijo Prados. "No tuvimos que actualizar ningún software. Teníamos diferentes parámetros que se pueden seleccionar con el multifunción y los interruptores que lo proporcionan, así que ya estaba instalado en el coche".

"Obviamente, en nuestro coche tenemos ajustes más y menos agresivos para asegurarnos de que siempre cumplíamos las normas y de que nuestro margen de seguridad era lo suficientemente grande", finalizó.