A 2026-os korszakváltást sokan úgy fogják fel, mint aerodinamikai és motorformula-resetet. Ez igaz – de informatikai szemmel nézve ez inkább egy platformváltás: új energiaáramlás, új vezérlési filozófia, új “üzemmódok”, új ellenőrzési pontok, új adatfolyamok. Ráadásul mindez egyszerre történik a kasztnin és a hajtásláncon, amit az F1 hivatalos kommunikációja is a sport történetének egyik legnagyobb szabálycsomagjaként keretez. 1

A tézisem: 2026-tól a győzelem kulcsa nem pusztán az, hogy “kinek erősebb a motorja” vagy “kinek jobb a padlólemeze”, hanem az, hogy kinek jobb a szoftveres- és adat-ökoszisztémája – és hogy ezt mennyire tudja megbízhatóan, auditálhatóan, szabálytisztán működtetni.

1) A FIA gyakorlatilag “szoftverhatóság” (software governance) irányba tolja a sportot

A 2026-os technikai szabályokban nagyon látványos, hogy a FIA nem csak azt mondja meg, milyen legyen az autó, hanem egyre konkrétabban azt is, hogyan lehet szoftvert futtatni.

Néhány (informatikai szempontból) sokatmondó elem a 2026-os Technikai Szabályzatból (FIA, 2026. február 27-i kiadás):

• az autó teljes elektromos/elektronikus rendszerét és az összes fedélzeti + kommunikációs hardvert/szoftvert szezon elején vizsgálhatja a FIA; 2
• minden újraprogramozható eszköznél kell olyan mechanizmus, amivel a FIA pontosan azonosítja a szoftververziót; 2
• az on-car szoftververziókat regisztrálni kell a FIA-nál használat előtt; 2
• a csapatok csak FIA által homologizált custom szoftvert futtathatnak a kontrollalkalmazásokhoz; 2
• és (ami DevOps szemmel külön pikáns) korlátozzák az egy szezonban használt verziók számát ECU / PU / ERS alkalmazásokra, miközben a “bug fix / reliability” jellegű változások nem feltétlen növelik a verziószámlálót. 2

Vélemény: ez egyértelmű jelzés, hogy az F1-ben a szoftver immár nem “csak egy belső mérnöki eszköz”, hanem versenyreleváns, szabályozott termék. Aki 2026-ban gyors akar lenni, annak nem csak jó mérnökei lesznek, hanem jó release menedzsmentje, konfiguráció-kezelése, traceability-je és olyan tesztelési fegyelme, amit más iparágakban safety-critical szoftvereknél látunk.

2) Energia-alapú korlátozások: a szabály betűje most már egyenesen algoritmusban él

A 2026-os power unit szabályok egyik legfontosabb, IT-szempontból alulértékelt fordulata: a FIA nagyon részletesen definiálja az energiaáramlást, és annak mérését/ellenőrzését. Például a tüzelőanyag oldalán a “fuel energy flow” limit explicit megjelenik (pl. 3000 MJ/h), és az is, hogy a megfelelőség-ellenőrzéshez a mért tömegáramot a SECU-ban (Standard ECU) alakítják át energiaárammá a FIA által mért energiasűrűség/LHV alapján. 3

Ugyanez igaz az elektromos oldalra is: a 2026-os PU szabályok konkrétan rögzítik a 350 kW ERS-K DC teljesítményplafont, és még olyan részleteket is, mint az “override mode” sebességfüggő teljesítménygörbéje (és hogy ennek részleteit a Sporting Regulations írja le). 3

Sőt: “ERS policing” jelleggel előírják, hogy az autóban DC szenzorokkal kell mérni az energiatároló és az ERS-K irányába/irányából menő villamos energiát, és a kialakításnak ezt konstrukcióból fakadóan garantálnia kell, ellenőrizhető módon. 3

Vélemény: ez azt jelenti, hogy 2026-ban a teljesítmény nem csak fizika, hanem mérhetőség + szoftveres megfelelés. Az a csapat lesz stabilan erős, amelyik:

• precízen kezeli a mérőláncot (szenzor → ECU → log → FIA hozzáférés),
• minimalizálja a “szürke zónás” viselkedéseket,
• és képes a stratégiát úgy optimalizálni, hogy közben az autó mindig audit-állapotban marad.

3) 50/50 és 350 kW: az energia-menedzsment valós idejű optimalizálási feladattá válik

A 2026-os PU-váltás hivatalos céljai között ott van, hogy a villamos részarány jelentősen nőjön (kb. 50%), az MGU-H kikerül, miközben az MGU-K teljesítménye 350 kW-ra ugrik. 4

Papíron az MGU-H eltörlése “egyszerűsítésnek” hangzik. Informatikai szemmel viszont a kép kettős:

• kevesebb komponens, kevesebb bonyolult alrendszer (jó hír),
• de sokkal agresszívebb villamos energiahasználat (350 kW), ami meredeken növeli a vezérlési és stratégiai komplexitást (kihívás). 4

És ez nem csak “versenystratégia”: ez real-time control. Olyan problémák kerülnek fókuszba, mint:

• előrejelző energia-tervezés körön belül (hol tölts, hol égesd el),
• hő- és teljesítménykorlátozások összehangolása,
• fékenergia-visszanyerés és stabilitás kompromisszumai,
• valamint az “override/boost” jellegű helyzetek szoftveres kezelése úgy, hogy a szabályok sebességfüggő limitjei mellett is maximális legyen a haszon. 3

Vélemény: 2026-ban a csapatoknak az autót egyre kevésbé “motor + aero” kombinációként, és egyre inkább energiarendszerként kell kezelniük, ahol a gyors köridő az energiaáramlás optimális koreográfiája. Ez az a pont, ahol a control engineering és a szoftverarchitektúra versenyképességi kérdés.

4) Aktív aerodinamika: DRS helyett szoftveresen konfigurált autó

Az egyik legjobban kommunikált változás, hogy a DRS korszakát az F1 2026-tól aktív aeróval váltja: mozgatható első/hátsó szárnyelemek, magas/alacsony leszorító konfigurációk, és új – a közönségnek is szánt – terminológia (pl. “Active Aero”, “Overtake Mode”, “Boost Mode”). 1

Ami IT-szempontból igazán fontos: a 2026-os FIA technikai szabályzat kimondja, hogy az állítható karosszériaelemeket és a hozzájuk tartozó aktuátorokat a FIA Standard ECU-nak kell vezérelnie, FIA által jóváhagyott szoftverrel, FIA által meghatározott kapcsolódási módon. 2

Vélemény: az aktív aeróval az aerodinamika egy része átköltözik a szoftver világába. Innentől a kérdés nem csak az, hogy “mekkora a leszorítóerő”, hanem az is, hogy:

• milyen gyorsan és mennyire stabilan tudsz váltani üzemmódok között,
• mennyire “simán” viselkedik az autó a váltás pillanatában (vezethetőség),
• hogyan zárod ki a hibás állapotokat (fail-safe),
• és mennyire jól illeszkedik mindez az energia-menedzsmenthez.

Az aeró tehát részben mechatronikai + szoftver-integrációs fegyelemmé válik.

5) A CFD/HPC már nem csak eszköz – szabályozott erőforrás (és ez nagyon IT)

Ha valaki kételkedik abban, hogy a Forma–1 mennyire lett “informatika-vezérelt”, elég megnézni a FIA Sporting Regulations aerodinamikai tesztkorlátozásait (ATR). Ezek nem csak szélcsatorna-időt korlátoznak, hanem konkrétan beszélnek RCFD (Restricted CFD) limitekről, riportálásról, auditálásról. 5

Két, IT-szempontból döbbenetesen érdekes részlet:

1. A szabály szerint az RCFD “solver” számításokat csak előre deklarált compute erőforráson lehet futtatni; a csapatnak a FIA felé le kell adnia az erőforrás azonosítóját, típusát, helyét, processzoregységek adatait stb. 5
2. A szabály azt is rögzíti, hogy 2028-tól engedik majd be a GPU-magok használatát a solver számításokra (ebből visszafelé következik: addig CPU-centrikus korlátolás van). 5

És van olyan átmeneti megkötés is, ami kifejezetten a 2026-os autók fejlesztésének időzítését célozta: 2023.12.01–2025.01.01 között az RCFD csak a 2021–2025-ös geometriai megfelelésű formákra mehetett. 5

Vélemény: ez a sport egyik legérdekesebb “meta-szintje”. Nem csak az autót szabályozzák, hanem a számítási kapacitás felhasználásának módját is. 2026-tól (és a 2026-os reset miatt különösen) felértékelődik:

• a szimulációs pipeline-ok hatékonysága (ugyanannyi kvótából több hasznos tudás),
• a modellvalidáció és adatmenedzsment,
• és a compute stratégia (milyen klaszter, milyen ütemezés, milyen reproducibility).

6) Telemetria és FIA-hozzáférés: a “data plane” maga is pálya

A 2026-os technikai szabályok szerint a FIA “korlátlan hozzáférést” kérhet a Standard ECU konfigurációihoz, logolt eseményeihez és valós idejű telemetriájához; a logmemóriát és esemény buffert pedig csak FIA mérnök törölheti a versenyhétvégén. 2

A csapatoknak ráadásul a valós idejű telemetria-adatokat a FIA hálózatán is továbbítaniuk kell a FIA kérésének és formátumának megfelelően. 2

Vélemény: ez informatikailag azt jelenti, hogy a csapatnak nem elég egy belső adatarchitektúra. Olyan kettős (csapat + FIA) megfelelési adatút kell, ami:

• stabil,
• késleltetésre és megbízhatóságra optimalizált,
• és közben nem enged adatminőségi/azonosítási hibákat.

Ez közelebb áll egy pénzügyi kereskedési rendszer “audit trail” világához, mint egy klasszikus autóverseny romantikájához.

7) Kiberbiztonság: a versenyképesség része, nem IT-higiénia

A Forma–1-ben óriási értékű mérnöki és stratégiai adatok mozognak, és a modern narratívákban egyre hangsúlyosabb, hogy ezeket gyorsan, megbízhatóan, titkosítva kell mozgatni – mert egy kompromittált adatfolyam nem csak kellemetlen, hanem teljesítménykiesés is. 6

Vélemény: 2026-tól ez a kockázat nő, mert nő a vezérelt rendszerek és üzemmódok komplexitása (energia + aktív aeró + szigorúbb policing). Minél több a szabályozott és mért digitális jel, annál nagyobb:

• az attack surface a beszállítói láncban,
• a konfigurációs hibák esélye,
• és az adatlopás “sportszakmai” kára.

A győztes csapatoknak ezért a cybersecurity-t nem “szponzori matricaként”, hanem race engineering-ként kell kezelniük.

8) Új belépők és gyártók: integrációs terhelés és szoftverkultúra-harc

2026-ra a mezőny is átalakul: a Cadillac F1 Team hivatalosan megkapta a végső jóváhagyást, és 11. csapatként csatlakozik. 7

A motorgyártói oldalon a FIA 2026–2030-as ciklusra több beszállítót erősített meg (pl. Audi is), ami önmagában is új fejlesztői kultúrákat hoz a sportba. 8
A Cadillac projektnél pedig az is érdekes, hogy a kommunikáció szerint 2026-tól Ferrari motorokkal kezdenek, miközben a GM Performance Power Units későbbi saját PU-szállítóként (2029-től) kapott jóváhagyást. 9

Vélemény: ezek a változások IT-szempontból integrációs stressztesztek. Új csapat = új ERP/PLM, új adatarchitektúra, új szimulációs stack, új trackside ops, új biztonsági baseline. Új gyártó = új toolchain, új kalibrációs filozófia, új “hogyan dokumentálunk és verifikálunk” kultúra. 2026-ban emiatt nem csak autók, hanem szoftverfolyamatok is versenyeznek egymással.

Mit fog ebből érezni a néző (és miért lesz más a “verseny sztorija”)?

Az F1 hivatalos terminológiafrissítése már előre jelzi, hogy 2026-tól a közvetítésekben is hangsúlyosabb lesz az, ami valójában eddig is a háttérben futott: üzemmódok, energiahasználat, regen, taktikai gombok. 1

Informatikai olvasatban ez jó hír: végre látszani fog, hogy a Forma–1 egy élő, valós idejű, szabályozott adat- és vezérlőrendszer. A rossz hír: a komplexitás miatt nő az esélye annak is, hogy egy hétvége “nem a tempóról szól”, hanem egy váratlan szoftveres/vezérlési jelenség megfejtéséről.

Záró vélemény: 2026 a “racing DevOps” korszaka

A 2026-os váltás lényege nem az, hogy több lesz-e az előzés (az majd kiderül). Informatikai szemmel a lényeg az, hogy az F1 még nyíltabban kimondja:

• a teljesítmény egy része szoftver,
• a szoftver szabályozott és auditált,
• a fejlesztési erőforrás (CFD compute) szintén szabályozott,
• és a versenyhétvége adatútjai (telemetria, logok, FIA hozzáférés) a sport infrastruktúrájának részei. 2

Aki 2026-tól dominálni akar, annak nem elég gyorsnak lennie. Megbízhatónak, reprodukálhatónak, ellenőrizhetőnek is kell lennie – és ez az informatika nyelve.

Forrásjegyzet: a fenti állításokhoz elsősorban FIA-szabálydokumentumokat (2026 Technical Regulations; 2026 PU Technical Regulations; 2025 Sporting Regulations – ATR/RCFD), valamint a Formula1.com hivatalos magyarázó anyagait és híreit használtam.