Cuando un bug detiene la Fórmula 1: lo que el GP de Bahréin enseña sobre probar el software
Un error en el software común a todas las unidades de potencia dejó sin aceleración a varios monoplazas en la vuelta de formación del Gran Premio de Bahréin, disputado este domingo, 4 de octubre, en el circuito malasio de Sepang. La propia FIA reconoció que no había podido probarlo en las condiciones en que falló. Aprovechamos la ocasión para resaltar la importancia de la verificación y validación de software, y destacar 5 posibles lecciones aprendidas.
Está en todos los periódicos. La lluvia ya había retrasado cuarenta minutos la salida del Gran Premio de Bahréin, trasladado este año al circuito de Sepang (Malasia). Cuando por fin los 22 coches iniciaron la vuelta de formación detrás del coche de seguridad, sobre una pista empapada, empezaron los problemas. Max Verstappen fue el primero en notar que su monoplaza no respondía al acelerador. Poco después, Lewis Hamilton tuvo que detenerse en la recta, apagar el motor y reiniciarlo, y otros pilotos como Esteban Ocon u Oliver Bearman se quedaron parados en pista.
Con varios coches inmovilizados en condiciones de baja adherencia, Dirección de Carrera mostró la bandera roja y abortó el procedimiento de salida. La carrera se retrasó cerca de una hora.
La causa: un caso que nadie había probado
El origen no estaba en ningún equipo concreto, sino en un software de la FIA instalado en todas las unidades de potencia de la nueva generación de motores de 2026. Ese software incluye una configuración específica para lluvia que, por seguridad, limita la entrega de potencia para evitar picos que hagan perder el control del coche.
Según explicó Nikolas Tombazis, director de monoplazas de la FIA, el problema apareció cuando algunos coches circularon a una velocidad tan baja que casi llegaron a detenerse (un efecto acordeón habitual tras el coche de seguridad). En esa situación, el sistema entró en un estado del que no sabía salir y que impedía volver a entregar potencia al motor. Tombazis reconoció que el software se había probado, pero no en esas condiciones: esta temporada apenas ha habido sesiones en mojado y, en las pruebas en las que se validó, nunca se alcanzaron velocidades tan bajas. Admitió también que, con más pruebas, probablemente se habría detectado a tiempo.
El caso es que el fallo siempre ha estado ahí, presente desde el inicio del campeonato, pero no se ha manifestado hasta la decimosexta carrera de la temporada. De esta situación se pueden extraer varias lecciones, que son más comunes de lo que se puede pensar:
Lección 1. Haber probado no es haberlo probado todo
El software funcionaba correctamente en todas las situaciones que se habían contemplado. Falló en un valor extremo (velocidad prácticamente nula) que quedaba fuera de lo previsto. En ingeniería del software, el análisis de valores frontera parte precisamente de esta observación: los errores tienden a concentrarse en los límites de los rangos de entrada, y son esos límites los que deben ocupar una parte importante del diseño de pruebas.
Paradojas de la ingeniería: el software estaba preparado para circular a más de 300 km/h, pero no para ir casi parado.
Lección 2. Los fallos nacen de combinaciones
La FIA describió el detonante como una combinación sin precedentes de cuatro factores: i) bajo régimen de motor, ii) poco agarre, iii) ajustes de gestión de energía para mojado y iv) la configuración por sectores del circuito. Cada uno, por separado, es una condición normal de funcionamiento. Juntos, activaron el error. Cuando un sistema depende de muchos parámetros, el número de combinaciones posibles crece de forma exponencial, y probarlas todas es inviable. Por eso existen técnicas de pruebas combinatorias que permiten seleccionar subconjuntos representativos con garantías de cobertura.
Lección 3. Un estado del que no se puede salir
Tombazis habló de un bucle que impedía volver a acelerar. En sistemas empotrados y de tiempo real, el comportamiento suele modelarse como una máquina de estados, y una de las propiedades que se deben verificar es que el sistema no pueda quedar atrapado en un estado sin salida. En sistemas críticos (y un vehículo en movimiento lo es), esta comprobación se apoya en métodos formales y en normativas de seguridad funcional que exigen demostrar que el sistema responde correctamente también ante condiciones no habituales.
Lección 4. Las pruebas deben parecerse al mundo real
La escasez de sesiones en mojado dejó sin datos una región completa del espacio de operación del sistema. Cuando las condiciones reales son difíciles de reproducir, la simulación y las pruebas hardware-in-the-loop (el software real ejecutándose sobre el hardware real, pero alimentado por un entorno simulado) permiten explorar escenarios que en pista quizá nunca se den hasta el día de la carrera.
Lección 5. El parche también es software
Una vez identificado el problema, el equipo de la FIA desarrolló una corrección bajo una fuerte presión de tiempo, la distribuyó a los equipos y estos la instalaron en sus coches antes de reanudar la carrera. Diagnosticar, corregir, desplegar y verificar en menos de una hora es un ejercicio de gestión de configuración y despliegue con un riesgo añadido: un cambio hecho con prisas puede introducir errores nuevos. Por eso las pruebas de regresión y los procesos de despliegue controlado son tan importantes como el desarrollo inicial.
El clásico «en mi máquina funciona» ya tiene su versión en la Fórmula 1: «en seco funcionaba».
El software está donde no se ve
La Fórmula 1 suele asociarse con mecánica, aerodinámica y neumáticos. Este domingo, sin embargo, lo que detuvo la carrera fue una condición no contemplada en unas líneas de código. Los propios pilotos lo resumieron tras la carrera al señalar la complejidad de los nuevos motores y la cantidad de software que los gobierna.
La verificación y validación de software, el diseño de sistemas empotrados y de tiempo real o la ingeniería de sistemas críticos forman parte de la formación que reciben los estudiantes del Grado en Ingeniería Informática de la ESI. Casos como el de Sepang muestran por qué estas competencias son hoy necesarias en sectores tan distintos como la automoción, la aviación, la salud o la energía, y por qué probar bien el software es tan importante como escribirlo.
