AI Disclosure: A cikk elkészítéséhez generatív AI-eszközöket is használtam. A végső tartalomért és annak pontosságáért a szerző vállal felelősséget.
Van az a pillanat egy fejlesztő életében, amikor valami teljesen értelmetlennek tűnik a productionben, aztán a logok átnézése után lassan összeáll a kép. „Ezt ugyan mi a francért csinálja?” – hangzik el, majd néhány óra múlva kiderül, hogy három, egyenként teljesen logikus feltétel találkozott egy olyan kombinációban, amire senki nem gondolt.
Egy ideje nem követem már aktívan a Formula-1-es világbajnokságot, de a legutóbbi Bahrein Nagydíjon történt eset felkeltette az érdeklődésemet, de nem mint F1 rajongó, hanem mint fejlesztő. Ami ugyanis ott volt az szerintem egy baromi érdekes és tanulságos eset.
Jött az eső és elmosta a biteket
A 2026-os Bahrein Nagydíjának otthont adó Sepangban a rajt előtt hatalmas eső érkezett, ezért a mezőny Safety Car mögött indult volna a felvezető körre. Aztán az első autók elkezdtek gyanúsan lassulni. Max Verstappen autója elvesztette a hajtási teljesítményt, később Lewis Hamilton is megállt, majd egymás után több versenyző találta magát ugyanebben a helyzetben.
Egy ponton már nem az volt a kérdés, hogy ki milyen gumival indul, hanem az, hogy egyáltalán képesek-e eljutni a rajtrácsig. A rajtot természetesen megszakították.
És miközben a nézők azt próbálták megfejteni, hogy vajon mi romlott el a motorokban, az FIA-nál kiderült a kellemetlen igazság: szoftverhiba történt.
Aztán a verseny előtt kiadtak egy javítást. Igen, nagyjából úgy, mintha egy webalkalmazás production hibáját javítanád egy órával az éles indulás előtt, csak itt 20 Forma–1-es autó várta a release-t.
A hiba nem egyetlen rossz feltétel volt
A történet azért érdekes, mert elsőre könnyű lenne kinevetni a fejlesztőket azzal, hogy „hát, egy if-et csak le lehetett volna tesztelni”.
A valóság ennél sokkal érdekesebb.
A 2026-os F1-es erőforrások jelentősen nagyobb szerepet adnak az elektromos oldalnak, ezért az energia menedzsmentje is sokkal összetettebb. Normál körülmények között az MGU-K akár 350 kW teljesítménnyel is rásegíthet, bizonyos helyzetekben viszont a rendszer 250 kW-ra korlátozza az elektromos teljesítményt. A szabályozás ráadásul pályaszakaszokhoz és különböző üzemállapotokhoz is kötődik.
Esőben további korlátozások lépnek életbe.
A Sepangban történtekhez pedig kellett még valami: nagyon alacsony sebesség.
A mezőny ugyanis a Safety Car mögött szokatlanul lassan haladt. A mezőny eleje lassított, a mögöttük érkezőknek még jobban kellett fékezniük, így kialakult egy klasszikus „concertina effect”: az autók nem ugyanazt a sebességet tartották, és néhányan egészen extrém alacsony tempóra estek vissza.
És ekkor találkozott egymással több, önmagában teljesen ésszerű rendszer.
- Nedves pálya.
- Alacsony tapadás.
- Wet-weather energia-menedzsment.
- Pályaszakaszhoz kötött teljesítménykorlátozás.
- Nagyon alacsony motorfordulat.
- Safety Car mögötti araszolás.
A kombinációt az FIA saját megfogalmazása szerint korábban nem fedezték fel a tesztelés során.
A rendszer egyszerűen nem tudott újra gyorsítani
A pontos implementáció részleteit az FIA nem hozta nyilvánosságra, ezért érdemes óvatosan fogalmazni. A jelenleg ismert információk szerint a nagyon alacsony sebesség egy olyan állapotba lökte a vezérlést, amelyben az elektromos teljesítményt nem lehetett megfelelően újra az autó gyorsítására fordítani.
A probléma egyik különösen érdekes része, hogy nemcsak az MGU-K elektromos rásegítése tűnt el. A versenyzők számára úgy érződött, mintha maga a gázpedál sem működne: a belső égésű motor sem adott megfelelő teljesítményt.
A FIA kezdeti magyarázata szerint a rendszer valamilyen módon úgy kezelte a gázpedálból érkező kérést, hogy az energia az MGU-K töltésére ment, miközben a kerekekre nem jutott megfelelő hajtási teljesítmény. A teljes technikai okot a szervezet még vizsgálja.
A helyzetet tovább bonyolította egy korábban biztonsági célból beépített mechanizmus.
Az úgynevezett „continuous offset” mód eredetileg arra szolgál, hogy bizonyos problémás helyzetekben az MGU-K azonnal lekapcsolható legyen. Ennek aktiválása után azonban 60 másodperces zárolás következhet, amely alatt az elektromos rendszer nem használható normál módon. A funkció korábban már azért is érdekes lett, mert csapatok megpróbálták teljesítményelőnyre használni, ezért az FIA külön szabályozta a használatát.
Vagyis volt egy biztonsági mechanizmus, egy energia-menedzsment rendszer, egy nedves pályás üzemmód és egy nagyon ritka működési körülmény.
És ezek együtt valami olyasmit eredményeztek, amit a tervezők nem akartak látni:
az autó nem tudott újra elindulni.
Ha fejlesztőként kellene elképzelni
A valódi FIA-kódot természetesen nem ismerjük, ezért az alábbi csak szemléltető pszeudókód. A nyilvánosságra került működési leírás alapján azonban nagyjából ilyen jellegű logika vezethetett a problémához:
if wet_conditions:
max_mgu_k_power = 250
if restricted_sector:
max_mgu_k_power = 250
if very_low_speed:
enter_low_speed_energy_mode()
if mgu_k_shutdown_requested:
continuous_offset = 60_seconds
if continuous_offset:
disable_mgu_k_deployment()
if throttle_requested:
manage_engine_and_energy(throttle_requested)
A baj természetesen nem az, hogy bármelyik sor önmagában értelmetlen lenne.
A baj az, hogy mi történik akkor, amikor mindegyik igaz egyszerre.
A valódi implementáció ennél természetesen sokkal összetettebb, és nincs bizonyíték arra, hogy konkrétan ilyen kód létezett. Az FIA egyelőre nem publikált ilyen forráskódot vagy hivatalos pszeudókódot. A „continuous offset” működéséről és a 60 másodperces zárolásról viszont korábban már konkrét technikai információk is napvilágot láttak.
Ez pedig fejlesztőként azért fájdalmasan ismerős, mert pontosan ez az a fajta hiba, amit az egységtesztek könnyen elkerülnek.
- Teszteljük, hogy esőben működik. ✅
- Teszteljük, hogy alacsony sebességnél működik. ✅
- Teszteljük, hogy a teljesítménykorlátozás működik. ✅
- Teszteljük a Safety Cart. ✅
- Teszteljük az MGU-K lekapcsolását. ✅
- Minden zöld. 🤗
Csak éppen senki nem írta oda a tesztesethez:
„Mi történik, ha Safety Car mögött 35 km/h-val araszolunk, nedves pályán, egy olyan szektorban, ahol aktív a teljesítménykorlátozás, miközben a rendszer éppen egy speciális energiaállapotba kerül?”
És itt már nem száz tesztesetről beszélünk.
A kombinatorikus komplexitás kezd dolgozni.
A legkellemetlenebb mondat: „teszteltük”
Az FIA együléses versenyzésért felelős igazgatója, Nikolas Tombazis nem próbálta letagadni a hibát. Éppen ellenkezőleg: elmondta, hogy a szoftvert tesztelték, csak nem ezekben a konkrét körülményekben.
Ez a mondat egy fejlesztő számára sokkal érdekesebb, mint az, hogy „bug volt”.
Mert a legtöbb komoly szoftverhibánál nem arról van szó, hogy senki sem tesztelt semmit.
A kérdés inkább az, hogy mit tekintettünk lehetséges állapotnak.
A tesztelés során a nagyon alacsony sebességű Safety Car-os helyzet egyszerűen nem volt megfelelően lefedve. Ráadásul 2026-ban addig nem volt valódi vizes versenyhelyzet, így az új autók ilyen körülmények között sem tudtak érdemben bizonyítani.
És itt van a történet egyik legfontosabb tanulsága: a „happy path” tesztelése egy ilyen rendszerben már régen nem elég.
Nem azt kell csak tesztelni, hogy:
„wet mode → működik”
hanem azt is, hogy:
„wet mode + low speed + safety car + sector restriction + low RPM + energy recovery + previous shutdown state → mi történik?”
Ez már nem egy funkció tesztelése.
Ez állapottér-tesztelés.
És aztán jött a production hotfix
A történet második része legalább ennyire szürreális. Az FIA mérnökei viszonylag gyorsan felismerték, mi okozza a problémát, és elkészítették a módosított szoftvert, amely lényegében megszüntette az érintett pályaszakaszokon azt az energia-korlátozást, amely a hibás működéshez vezetett.
Normális esetben egy fejlesztőcsapat ilyenkor szépen végigmenne a megszokott folyamaton: fel a staging környezetbe, tesztek, validáció, aztán mehet a production deploy. Csakhogy ezúttal nem volt staging környezet, ahol nyugodtan lehetett volna próbálgatni a javítást. A staging maga a pálya volt, a production pedig húsz Forma–1-es autó, amelyeknek néhány percen belül rajthoz kellett volna állniuk.
Nikolas Tombazis később elmondta, hogy nem napok álltak rendelkezésükre a javítás elkészítéséhez, hanem mindössze néhány perc. A módosítást ezért a lehető leggyorsabban elkészítették és ellenőrizték, majd valamennyi csapatnak telepítenie kellett az új verziót, mielőtt folytathatták volna a rajt előkészítését.
Lewis Hamilton később már a helyzethez illő F1-es humorral kommentálta a történteket: a versenyzők lényegében megvárták, amíg mindenki befejezi a szoftverfrissítést. Max Verstappen pedig az egészet Lego-autókhoz hasonlította. Fejlesztői szemmel nézve ennél nehéz lenne tökéletesebb példát találni arra, amikor a production deploy valóban production deploy.
„Nálunk nincs ilyen bug”
A történetnek van még egy érdekes része.
Nem minden autó állt le.
Ez elsőre akár azt is sugallhatná, hogy valamelyik motor gyártója egyszerűen jobb szoftvert írt. Tombazis szerint azonban nem erről volt szó. A különbséget elsősorban az okozta, hogy az autók nem pontosan ugyanazokat a sebességeket érték el a felvezető kör adott pontjain. A mezőny elején bekövetkező lassulás hátrafelé egyre nagyobb sebességkülönbségeket okozott.
Ez megint egy nagyon szép szoftveres példa.
Ha egy bug csak bizonyos bemeneti tartományban jelentkezik, akkor az, hogy egy másik instance nem produkálja, még nem jelenti azt, hogy az instance jobb.
Lehet, hogy egyszerűen nem jött létre ugyanaz az állapot.
A „működik nálam” és a Formula–1 közötti különbség
A történetből könnyű lenne azt a következtetést levonni, hogy az F1-es mérnökök amatőrök. Valójában éppen az ellenkezője látszik. Ez elképesztően komplex rendszer.
A 2026-os szabályok már önmagukban rengeteg energia-menedzsment szabályt tartalmaznak, és a szezon közben is módosítottak rajtuk. Például külön szabályok vonatkoznak arra, mikor lehet 350 kW-tal, illetve 250 kW-tal használni az MGU-K-t, hogyan történik az energia-visszanyerés, és még külön „low power start detection” mechanizmust is bevezettek a gyenge rajtok biztonságos kezelésére.
Minél több ilyen szabályt rakunk egy rendszerbe, annál több lehetséges állapotot kapunk.
És egy ponton már nem az a kérdés, hogy:
„Működik-e a funkció?”
hanem az, hogy:
„Mi történik, ha a rendszer minden funkciója egyszerre próbálja tenni a dolgát?”
Ez pedig már ugyanaz a probléma, amivel egy nagy webalkalmazás, egy banki rendszer vagy akár egy játék fejlesztője is találkozik.
Nem az a veszélyes, hogy van egy bug
A történetből szerintem nem az a legérdekesebb tanulság, hogy az FIA-nál elrontottak valamit. Bugok mindenhol vannak, és egy ilyen összetett rendszerben elkerülhetetlen, hogy időnként olyan hibák kerüljenek elő, amelyekre a fejlesztők nem számítottak. Sokkal érdekesebb kérdés, hogy mit kezdünk azzal a problémával, amikor egy rendszer egyes részei külön-külön tökéletesen működnek, a valódi hibát viszont éppen az okozza, ahogy ezek a részek egymással kölcsönhatásba lépnek.
Egy játékban például lehet külön-külön jól működő morál-, élelmezési-, ostrom- és politikai rendszerünk. Aztán egyszer csak leesik a morál, közben elfogy a lőpor, megsérül egy falszakasz, az egyik frakció követeléssel áll elő, a játékos aktivál egy rendeletet, és valahol a háttérben lejár egy időzítő. Az egyes rendszerek továbbra is pontosan azt csinálják, amire tervezték őket, mégis létrejön egy olyan állapot, amellyel korábban egyikük sem találkozott együtt a többiekkel.
Pontosan ezért olyan nehéz a komplex rendszereket tesztelni. Nem elég azt ellenőrizni, hogy az egyes fogaskerekek külön-külön rendben működnek-e; azt is meg kell vizsgálni, mi történik akkor, amikor egyszerre kapcsolódnak össze, és egy olyan helyzetet hoznak létre, amelyet a fejlesztők a tervezéskor talán még elképzelni sem tudtak.
A Forma–1-ben ehhez most elég volt egy kis eső, egy Safety Car, néhány szokatlanul lassan haladó autó és egy olyan szoftver, amely papíron készen állt a versenyre. Egészen addig, amíg a valóság nem produkált egy olyan kombinációt, amelyre a tesztelés során senki sem számított.
Borítókép: Ferrari driver Lewis Hamilton of Britain steers his car during the formation lap prior to the delayed start of the Bahrain Grand Prix in Sepang, Malaysia, Sunday, Oct. 4, 2026. (AP Photo/Aijaz Rahi) – The Associated Press
AI Disclosure: A cikk elkészítéséhez generatív AI-eszközöket is használtam. A végső tartalomért és annak pontosságáért a szerző vállal felelősséget.