A Járművet Már Szoftver Határozza Meg? Domain Architektúra és az SDV-átalakulás

Elektromos autótechnológiák
Szerző: Deniz Erkan
Létrehozás: 14 október 2026

Több mint száz vezérlőegységet néhány zónavezérlőre redukáló architektúra már nem acélból, hanem kódból gyártja az autó identitását.

Az oldal megosztása

Igen: a modern autó viselkedését, tulajdonságait és teljesítménykarakterét ma már elsősorban a szoftver határozza meg. A szoftver által definiált járműnek (SDV) nevezett átalakulás a jármű elektronikus architektúráját az ECU-halmoktól a domain- és zónakontrollerekig viszi, elválasztva egymástól a hardvert és a szoftvert, és mindent átalakít a kábelezés súlyától az OTA-frissítésekig.

Kiemeltek

A mai járművek 100 vagy több vezérlőegységet is tartalmazhatnak; az új architektúrák ezt a számot akár 20%-kal csökkentésére törekszenek.
A domain-architektúra funkció, a zónaarchitektúra fizikai elhelyezkedés szerint szervezi az elemeket.
A zónatopológiában CAN XL (legfeljebb 20 Mbps) és gigabit Ethernethez hasonló nagy sávszélességű gerinceket használnak.
Az OTA-frissítés alapvető SDV-képesség, amelyet a hardver-szoftver szétválasztása tesz lehetővé.
Az átállás fokozatos: az első terület a karosszéria-domain; az ADAS, a hajtáslánc és a futómű tovább maradhat a meglévő struktúrában.

Mit jelent pontosan a szoftver által definiált jármű?

A definíció világos: a szoftver által definiált jármű olyan jármű, amelynek funkcionalitását és viselkedését elsősorban a szoftver határozza meg, nem a hardver. A hagyományos autóban egy funkciót arra a célra gyártott hardveralkatrész határozott meg; az SDV-ben ugyanaz a hardver a rajta futó szoftverrel eltérő funkciókat ölthet. Már a jármű eladása után is hozzáadhatók új funkciók, kalibrálható a viselkedés, távolról javíthatók a hibák.

A mai E/E-architektúrák 100 vagy több vezérlőegységből állnak; az új generációs struktúrák a vezérlőegységek számában akár 20%-ot, az anyagban és hardverben akár 10%-ot megtakarítanak.
Bosch Mobility, E/E-architektúra értékelés

Ez a mondatban szereplő számok az átalakulás mértékét foglalják össze. A probléma nem csupán a vezérlőegységek száma: minden ECU magával hozza a saját kábelezését, saját szoftverhalmozát és saját validációs terheit. Az SDV-vízió ezt a széttagolt struktúrát olyan rendszerré alakítja, amelyet a szoftver egyetlen egységes rétegben tud kezelni. Ehhez viszont az elektronikus architektúrát a nulláról kell újragondolni.

ECU-któl a domain-architektúráig: csoportosítás funkció szerint

Az az időszak, amikor egy autó minden apró funkciója külön elektronikus vezérlőegységgel (ECU) rendelkezett, kezelhetetlenné tette a kábelkötegeket. A domain-architektúra volt erre az első szisztematikus válasz: a jármű elektronikáját nagy funkcionális területek szerint szervezi, mint az ADAS, infotainment, hajtáslánc, karosszéria-elektronika, futómű és biztonság. Minden domain általában saját processzorral, szoftverhalommal, kommunikációs interfésszel, szenzorokkal és aktuátorokkal rendelkezik, és egy domain-vezérlő irányítja.

Ez a struktúra jelentős egyszerűsítést hozott az ECU-káoszhoz képest. Azonban ahogy az SDV-cél nőtt, a domain-architektúra korlátai is megmutatkoztak. Különösen az autonóm funkciók által termelt szenzoradatok a klasszikus CAN-hálózatok sávszélességét a határaiig igénybe vették. Emellett az, hogy minden domain a saját számítási erőforrását hordozza, bonyolulton hagyta a kábelköteget, és megnehezítette a szoftver skálázódását a jármű teljes területén.

Zonális architektúra: Az organizáció a funkcióról a helyre vált

A zonális architektúra megfordítja a logikát: az elektronikákat nem funkció szerint, hanem a járművön belüli fizikai hely szerint csoportosítja. A jármű zónákra oszlik, például elöl balra, elöl jobbra, hátul balra, hátul jobbra és utastér; minden zónában egy zonal vezérlő gyűjti össze az adott zóna szenzorait, aktuátorait és tápellátását, és kommunikál a központi, nagy teljesítményű számítási platformokkal.

Jellemző	Domain architektúra	Zonális architektúra
Organizációs elv	Funkció szerint (hajtáslánc, ADAS, karosszéria...)	Fizikai hely szerint (elöl balra, hátul jobbra...)
Számítási erőforrások	Domain-specifikus feldolgozás	Konszolidált központi/elosztott számítástechnika
Kábelezés	Összetett, hosszú kábelfonat	Csökkentett kábelezés és tömeg
ECU-k száma	Sok ECU	Kevés zonal vezérlő + központi számítógép
Szoftver rugalmasság	Nehézkesen skálázható SDV-hez	Magas szoftver rugalmasság

Az előny kézzelfogható és mérhető: a kábelfonat tömege csökken, a pont-pont kapcsolatok száma kevesebb lesz, a járműarchitektúra és a rendszer Validáció erőfeszítése egyszerűsödik. Ami fontosabb, a szenzor- és aktuátortervek függetlenednek a központi számítási csomóponttól; így a hardver- és szoftverfrissítési ciklusok szétválnak, és egy szenzorterv több járműgeneráción keresztül is használható.

Mit végez a Zonal vezérlő? Feladatmegosztás és a hardverrel való kapcsolat

Zonal mimaride kablolar kısaldıkça araç hafifler, sigortalar yerini yarı iletken anahtarlara bırakır ve güç artık bölge bölge yönetilir.

A zonális architektúra kulcsa a zonal vezérlő, amely számos aktuátor és szenzor központi számítási ECU-hoz való csatlakoztatásáért felelős. Ez a vezérlő nem csupán adatgyűjtő doboz; valós idejű vezérlőhurkatokat futtathat saját magán, kezelheti a zónájában lévő eszközöket, és szűrt, priorizált forgalmat küld a gerincnak. Ti által készített mérnöki értékelés szerint a zonal modul MCU-jának magas valós idejű teljesítményt, nagy memóriát, virtualizációs támogatást különböző ASIL szintekhez, nagy sebességű kommunikációt a gerinccel, valamint CAN FD, LIN és hasonló alacsony költségű, nagyszámú periférikus interfészt kell biztosítania.

Hogyan decentralizálódik a tápellátás?

A domain architektúrában a teljesítmény központi tápellátási dobozokból oszlik el, amelyek olvadó biztosítékokat és reléket tartalmaznak. A zonális felépítésben az elosztás decentralizált: egyetlen tápköteg húzódik az akkumulátortól a zónáig, a zone modul pedig elosztja a teljesítményt az adott zóna moduljai között. A rövid tápkábelek közvetlenül tömeg- és költségmegtakarítást jelentenek. Ezenkívül az olvadó biztosítékok helyét félvezető alapú intelligens biztosítékok veszik át; az I²t karakterisztikájú magas oldali kapcsolók kevesebb biztosítékváltozatot és jobban optimalizált vezetékmetszeteket tesznek lehetővé. Az MCU-ból, magas oldali kapcsolókból és transceiverekből álló intelligens tápelosztó doboz olyan egységgé válik, amelynek konfigurációja szoftverrel történik: ugyanaz a doboz minden zónában használható, a terheléshez igazítva.

A fizikai és logikai I/O szétválasztása

A zónás modul több ECU logikai bemeneti/kimeneti funkcióit egyetlen pontban egyesíti, ezáltal csökkentve a kábelezés összetettségét, miközben az érzékelők és beavatkozók fizikai elhelyezkedése változatlan marad. Egy lépéssel tovább a végponti eszközök "okossá" válnak: a helyi áramkör megőrzi az állapotinformációt, és hibadiagnosztikát futtat. A CAN FD Light-hoz hasonló egyszerűsített protokollok egyes végponti csomópontoknál akár a külön MCU szükségletét is megszüntethetik. Ez a szétválasztás, amelyben a hardver állandó marad, a feladatot pedig szoftver határozza meg, az SDV mérnöki gerince.

Adatbusz a zónás járműben: sávszélesség, időzítés és kiberbiztonság

Az érzékelőfúzió és az AI munkaterhelései a zónás topológiát nagy sávszélességű gerinchálózatra építik: PCIe, 20 Mbps-ig terjedő adatsebességet elérő és a meglévő CAN-kompatibilitást megőrző CAN XL, valamint gigabites Ethernet. Az igazi kihívás a sávszélességnél is inkább az időzítés; a rövid vezérlőüzenetek, az ADAS érzékelőadatok és az infotainment forgalom nagyon eltérő késleltetési, jitter- és szinkronizációs követelményeket hordoznak. Duruma becslések: hang esetében milliszekundum szintű, az erőátvitel és a futóművezérlés esetében mikroszekundum szintű késleltetési célok érvényesek.

E különböző forgalmi osztályok egyetlen hálózaton történő szállítására az Ethernet-alapú Time-Sensitive Networking (TSN) kínál megoldást. Az olyan szabványok, mint az időszinkronizáció (IEEE 802.1AS), az időérzékeny forgalomalakítás (802.1Qbv), az express forgalom (802.3br), a keret-előzetes lefoglalás (802.1Qbu) és a redundancia (802.1CB), determinisztikus késleltetési garanciát biztosítanak a kritikus adatoknak. Biztonság oldalon az ISO 26262 támogatás, a redundáns kommunikációs útvonalak, a biztonsági particionálás és a hibafelismerés; kiberbiztonsági oldalon az ISO/SAE 21434 szabvány, az UNECE előírások, valamint olyan alacsony szintű titkosítási-hitelesítési mechanizmusok, mint a MACsec, a meghatározó tényezők. Mivel a zónás architektúra központosítja a hálózatokat, az Ethernet-alapú támadási módszerek is alkalmazhatóvá válnak; biztonsági sérülés esetén a bemenet/kimenet-feldolgozás szétválasztás koncepciójának összeomlása külön-külön értékelendő kockázat.

Hogyan teszi lehetővé a hardver-szoftver szétválasztás az OTA-frissítést?

Az OTA-frissítés a legtöbb SDV-vitában elsőként eszbe ötlő tulajdonság, de önmagában nem képesség, hanem egy architektúra következménye. Folyamatos frissítés nem biztosítható anélkül, hogy a szoftver a hardverabsztrakciós rétegen (HAL) keresztül el ne legyen választva az adott chipektől, és a járműfunkciók független, újrafelhasználható, lazán kapcsolt szolgáltatásokra ne legyenek bontva (szolgáltatásorientált architektúra, SOA). A szétválasztás a különböző biztonsági szintű szoftverek egymástól való elkülönítését is magában foglalja.

Konkrét jelentése a következő: a zone architektúra, az OTA/FOTA frissítések és a folyamatos felhőkapcsolat révén a csúcsminőségű szoftverkarbantartás irányítását a gyártó kezébe helyezi, miközben a valós idejű vezérlőciklusokat a zone modulokra tolhatja. Az olyan finomhangolások is egyszerűbbé válnak ebben a struktúrában, mint például az elektromos járművekben nem használt modulok áramtalanítása. Végső soron az elektromos jármű szoftvere egy frissítési csatorna lenni jóval többnél: ez az a definíciós réteg, amely meghatározza a jármű tulajdonságait, biztonsági rendszereit és teljesítménykarakterét. A jármű lassan egy kerekeken guruló elosztott adatközponthoz kezd hasonlítani; az értéklánc a szoftverre, a számítási teljesítményre és a rendszerarchitektúrára támaszkodik.

Milyen Gyors Lessz az Átállás, és Elég Lesz-E Egyedül a Zonális Architektúra?

Az átállás fokozatos lesz. A karosszéria (body) domain a nagyszámú elosztott aktuátor és szenzor ECU miatt lesz az első terület, amely zone architektúrára vált; az ADAS, a powertrain és a futómű-vezérlés átállása pedig biztonságkritikus jellege miatt több időt vehet igénybe. A 2017 óta az MCAL, a BSW és az alkalmazási rétegekben zajló fejlődés azt mutatja, hogy nem egy technikai projektről, hanem iparági léptékű szemléletváltásról van szó.

Mérlegelten olvasásra is szükség van. A zonális architektúra a járművet fizikailag szervezi újra; a logikai és szoftveroldalt (SOA, HAL, kiberbiztonság) külön kell megoldani - a kábelek átrendezése önmagában nem tesz szoftver által definiálttá egy járművet. A piacméret-becslések is jelentősen változnak a hatókör-definíciók szerint; az E/E architektúra piacára vonatkozó eltérő számok abból erednek, hogy a piacot másképp mérik attól függően, hogy mit számolnak bele (csak a számítási platformokat, vagy az összes elosztott elektronikát). Emellett nem szabad elfelejteni, hogy az átállás érintett felei, a félvezető- és megoldásszolgáltatók nyilvánvalóan érdekelt felei ennek az átalakulásnak.

Az eredmény egy világos mérnöki egyensúly: a jármű szoftverrel történő definiálása nem egyetlen szoftverprojekt, hanem csak úgy valósítható meg, ha a domain- és zonális vezérlőkre épülő új hardverszervezés, a szétválasztott szoftverrétegek, valamint egy determinisztikus, biztonságos adatgerinc egyszerre létezik. Az OTA-frissítés ennek az integrált struktúrának a leglátványosabb gyümölcse; a valódi forradalom abban rejlik, hogy a jármű hardvere átadja a feladatdefiníciót a szoftvernek.