Pilotos de F1 impotentes frustrados por un fallo de software de la F1 en Baréin
Un fallo de software en la ECU estandarizada de Fórmula 1 hizo que los coches perdieran potencia durante el Gran Premio húmedo de Baréin celebrado en Sepang, obligando a los responsables a desplegar una actualización de firmware de emergencia entre las vueltas de formación. Los comentaristas usan el incidente para cuestionar cuánto control debería ejercer la FIA a través del software compartido de la ECU, lo seguro que es aplicar parches en caliente a sistemas críticos y si la F1 moderna se ha vuelto excesivamente dependiente de unidades de potencia híbridas complejas y de la electrónica a expensas de la habilidad del piloto, del espectáculo y de una innovación técnica genuina.
ECU estándar y control de la FIA
- Todos los coches usan una sola ECU homologada (TAG-700 de McLaren / Motion Applied) con módulos de software exigidos por la FIA.
- Los equipos pueden personalizar muchos parámetros y capas por encima del código de la FIA, pero están restringidos para impedir ayudas al piloto (control de tracción, ABS, etc.).
- El firmware compartido existe principalmente para hacer cumplir las reglas y garantizar una telemetría justa, no para estandarizarlo todo.
Control de tracción, ayudas al piloto y filosofía
- El control de tracción está prohibido para mantener la habilidad de conducción en el centro; permitirlo desplazaría la competición hacia algoritmos de control.
- Algunos sostienen que la FIA debería simplemente vigilar las ayudas ilegales en lugar de incrustar lógica de aplicación en la ECU.
- Hay una tensión constante entre la habilidad del piloto, la libertad de ingeniería, la seguridad y el entretenimiento.
Unidades de potencia híbridas y “demasiada tecnología”
- Muchos comentarios critican los híbridos actuales por ser demasiado complejos, depender en exceso del software y resultar insatisfactorios (por ejemplo, despliegue de par, clipping, modos lluvia).
- Algunos quieren volver a motores NA más sencillos y ruidosos; otros argumentan que la F1 debe seguir siendo una vitrina tecnológica con relevancia híbrida/elétrica.
- Debate sobre si las normas híbridas avanzan de forma significativa la tecnología de los coches de calle, dado que los vehículos de consumo se encaminan rápidamente hacia el EV completo.
Naturaleza del fallo y corrección rápida
- El bug se activó en condiciones húmedas y lentas de la vuelta de formación: los turbos bajaron de régimen, las ECUs detectaron estados anómalos y se cortó la potencia (“limp mode” / lógica anti‑tracción).
- La solución probablemente fue un cambio rápido de firmware o de configuración que desactivó o relajó ciertos límites de protección/anti‑engaño.
- A algunos les alarma que una actualización crítica para la seguridad pueda diseñarse y desplegarse en menos de una hora; otros señalan que los coches de F1 son prototipos permanentes y que los cambios durante un evento son normales.
Calidad de la ingeniería de software en el automovilismo
- Varios comentaristas describen la cultura del software en el automovilismo como poco orientada a procesos y ad hoc en comparación con el desarrollo de software de seguridad crítica para coches de calle o industria.
- Ejemplos: V&V formal mínima, dependencia de hojas de cálculo y correo electrónico para gestionar sistemas muy complejos, adopción tardía de herramientas modernas.
- Otros matizan esto, señalando que el software de los coches de calle también falla de formas mundanas; la perfección es irrealista.
Simulación, pruebas y límites de costes
- Los equipos usan simuladores sofisticados con ECU en el bucle y modelos empíricos, pero los casos extremos son difíciles de anticipar.
- Los límites de costes y las restricciones sobre CFD, túneles de viento y ciertos simuladores determinan dónde invierten los equipos el esfuerzo de pruebas.