Czy pojazdy są teraz definiowane przez oprogramowanie? Architektura domenowa i transformacja SDV

Technologie samochodów elektrycznych
Utworzenie: 14 Październik 2026

Architektura redukująca ponad sto jednostek sterujących do kilku kontrolerów strefowych sprawia, że tożsamość samochodu powstaje dziś nie ze stali, lecz z kodu.

Udostępnij tę stronę

Tak: zachowanie, właściwości i charakterystyka wydajności współczesnego samochodu są dziś definiowane przede wszystkim przez oprogramowanie. Ta transformacja, nazywana pojazdem definiowanym oprogramowaniem (SDV), przenosi architekturę elektroniki pojazdu ze stosów ECU do kontrolerów domenowych i strefowych, oddzielając sprzęt od oprogramowania i przekształcając wszystko - od wagi okablowania po aktualizacje OTA.

Najważniejsze informacje

Współczesne pojazdy mogą zawierać 100 i więcej jednostek sterujących; nowe architektury dążą do zmniejszenia tej liczby o nawet 20%.
Architektura domenowa organizuje funkcje według ich przeznaczenia, a architektura strefowa według lokalizacji fizycznej.
W topologii strefowej wykorzystywane są szkielety o dużej przepustowości, takie jak CAN XL (do 20 Mb/s) i Ethernet gigabitowy.
Aktualizacja OTA to podstawowa zdolność SDV, możliwa dzięki rozdzieleniu sprzętu i oprogramowania.
Przejście jest stopniowe: pierwszym obszarem jest domena nadwozia (body); ADAS, napęd i podwozie mogą dłużej pozostać w istniejącej strukturze.

Czym dokładnie jest pojazd definiowany oprogramowaniem?

Definicja jest jasna: pojazd definiowany oprogramowaniem to pojazd, którego funkcjonalność i zachowanie są określane przede wszystkim przez oprogramowanie, a nie sprzęt. W tradycyjnym samochodzie funkcja była definiowana przez dedykowany element sprzętowy wykonany specjalnie dla tej funkcji; w SDV ten sam sprzęt może przybierać różne funkcje dzięki oprogramowaniu, które na nim działa. Nawet po sprzedaży pojazdu można dodawać nowe funkcje, kalibrować zachowanie i zdalnie naprawiać błędy.

Współczesne architektury E/E składają się ze 100 i więcej jednostek sterujących; struktury nowej generacji pozwalają zaoszczędzić do 20% liczby jednostek sterujących i do 10% materiałów i sprzętu.
Bosch Mobility, ocena architektury E/E

Liczby zawarte w tym zdaniu podsumowują skalę transformacji. Problem dotyczy nie tylko liczby jednostek sterujących: każdy ECU wnosi swoje własne okablowanie, własny stos oprogramowania i własne obciążenie walidacyjne. Wizja SDV polega na przekształceniu tej rozproszonej struktury w system, w którym oprogramowanie może zarządzać wszystkim jako jedną spójną warstwą. A do tego potrzebne jest całkowite przeprojektowanie architektury elektroniki.

Od ECU do architektury domenowej: Grupowanie według funkcji

Okres, w którym każda mała funkcja w samochodzie miała osobną jednostkę sterowania elektronicznego (ECU), sprawił, że wiązki okablowania stały się nie do opanowania. Architektura domenowa była pierwszym systematycznym odpowiedzią na ten problem: organizuje elektronikę pojazdu według dużych obszarów funkcjonalnych, takich jak ADAS, infotainment, układ napędowy (powertrain), elektronika nadwozia, podwozie i bezpieczeństwo. Każda domena zazwyczaj ma własny procesor, stos oprogramowania, interfejs komunikacyjny, czujniki i siłowniki oraz jest zarządzana przez kontroler domeny.

Ta struktura zapewniła znaczną konsolidację w porównaniu z chaosem ECU. Jednak w miarę wzrostu celów SDV pojawiły się ograniczenia architektury domenowej. W szczególności dane z czujników generowane przez funkcje autonomiczne doprowadziły przepustowość klasycznych sieci CAN do granic możliwości. Ponadto fakt, że każda domena miała własny zasób obliczeniowy, pozostawiał wiązkę przewodów w stanie skomplikowanym i utrudniał skalowanie oprogramowania w całym pojeździe.

Architektura Strefowa: Organizacja Przechodzi od Funkcji do Lokalizacji

Architektura strefowa odwraca tę logikę: grupuje elektronikę nie według funkcji, lecz według fizycznego położenia w pojeździe. Pojazd dzieli się na strefy, takie jak lewy przód, prawy przód, lewy tył, prawy tył i kabina; w każdej strefie kontroler strefowy zbiera czujniki, siłowniki i rozdział mocy, a następnie łączy je z centralnymi platformami obliczeniowymi o wysokiej wydajności.

Cecha	Architektura domenowa	Architektura strefowa
Zasada organizacji	Według funkcji (napęd, ADAS, nadwozie...)	Według położenia fizycznego (lewy przód, prawy tył...)
Zasoby obliczeniowe	Przetwarzanie specyficzne dla domeny	Skonsolidowane przetwarzanie centralne/rozproszone
Okablowanie	Skomplikowana, długa wiązka przewodów	Zredukowane okablowanie i masa
Liczba ECU	Duża liczba ECU	Niewielka liczba kontrolerów strefowych + komputer centralny
Elastyczność oprogramowania	Trudna do przeskalowania dla SDV	Wysoka elastyczność oprogramowania

Korzyści są konkretne i mierzalne: masa wiązki przewodów spada, połączenia punkt-punkt się zmniejszają, a wysiłek związany z walidacją architektury pojazdu i systemów się upraszcza. Co ważniejsze, projekty czujników i siłowników stają się niezależne od centralnego węzła obliczeniowego; dzięki temu cykle aktualizacji sprzętu i oprogramowania się rozdzielają, a jeden projekt czujnika może być wykorzystywany przez wiele generacji pojazdów.

Do Czego Służy Kontroler Strefowy? Podział Zadań i Relacja ze Sprzętem

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.

Kluczem do architektury strefowej jest kontroler strefowy, odpowiedzialny za łączenie wielu siłowników i czujników z centralnym ECU obliczeniowym. Ten kontroler nie jest jedynie skrzynką do zbierania danych; może uruchamiać pętle sterowania w czasie rzeczywistym na własnym sprzęcie, zarządzać urządzeniami w swojej strefie i wysyłać do magistrali backbone przefiltrowany, uszeregowany według priorytetów ruch. Według oceny inżynieryjnej firmy Ti procesor MCU modułu strefowego musi oferować wysoką wydajność w czasie rzeczywistym, dużą pamięć, obsługę wirtualizacji dla różnych poziomów ASIL, szybką komunikację z magistralą backbone oraz wiele tanich interfejsów końcowych, takich jak CAN FD i LIN.

Jak rozdział mocy ulega decentralizacji?

W architekturze domenowej moc jest rozdzielana przez centralny rozdział mocy zawierający bezpieczniki i przekaźniki. W strukturze strefowej rozdział ulega decentralizacji: jedna wiązka zasilania jest pobierana z akumulatora do strefy, a moduł strefowy dzieli moc między moduły w danej strefie. Krótkie kable zasilające oznaczają bezpośrednio mniejszą masę i koszt. Ponadto miejsce bezpieczników zajmują półprzewodnikowe inteligentne bezpieczniki; klucze górnej strony o charakterystyce I²t zapewniają mniejszą zmienność bezpieczników i lepiej zoptymalizowane przekroje przewodów. Inteligentna skrzynka rozdzielacza mocy, składająca się z procesora MCU, kluczy górnej strony i transceiverów, staje się jednostką konfigurowaną programowo: ta sama skrzynka może być używana w każdej strefie, dostosowana do obciążenia.

Rozdzielenie fizycznych i logicznych wejść/wyjść (I/O)

Moduł zonalny łączy funkcje logicznego wejścia/wyjścia wielu ECU w jednym punkcie, redukując złożoność okablowania; przy zachowaniu fizycznych lokalizacji czujników i aktuatorów. O krok dalej - urządzenia końcowe stają się "inteligentne": lokalny obwód przechowuje informacje o stanie i przeprowadza diagnostykę usterek. Uproszczone protokoły, takie jak CAN FD Light, mogą wręcz wyeliminować potrzebę stosowania osobnego MCU w niektórych węzłach końcowych. Ta separacja, w której sprzęt pozostaje niezmienny, a zadanie definiowane jest oprogramowaniem, stanowi inżynierski kręgosłup SDV.

Magistrala danych w pojazdzie zonalnym: Przepustowość, synchronizacja i cyberbezpieczeństwo

Fuzja czujników i obciążenia AI wymuszają oparcie topologii zonalnej na wysoko przepustowych kręgosłupach: PCIe, CAN XL osiągający prędkości danych do 20 Mbps i zachowujący kompatybilność z istniejącym CAN, oraz Ethernet gigabitowy. Prawdziwe wyzwanie wykracza jednak poza przepustowość - to synchronizacja; krótkie komunikaty sterujące, dane czujników ADAS i ruch infotainment mają bardzo różne wymagania dotyczące opóźnień, jitteru i synchronizacji. Przybliżone wartości są następujące: dla audio cele opóźnień na poziomie milisekund, a dla przenoszenia mocy i kontroli podwozia - na poziomie mikrosekund.

Aby przenosić te różne klasy ruchu w jednej sieci, rozwiązaniem staje się oparty na Ethernecie Time-Sensitive Networking (TSN). Standardy takie jak synchronizacja czasu (IEEE 802.1AS), kształtowanie ruchu wrażliwego na czas (802.1Qbv), ruch express (802.3br), wywłaszczanie ramek (802.1Qbu) i redundancja (802.1CB) gwarantują dane krytycznym deterministyczne opóźnienia. Po stronie bezpieczeństwa funkcjonalnego: wsparcie ISO 26262, nadmiarowe ścieżki komunikacji, partycjonowanie bezpieczeństwa i wykrywanie usterek; po stronie cyberbezpieczeństwa decydujące są norma ISO/SAE 21434, regulacje UNECE oraz niskopoziomowe mechanizmy szyfrowania i uwierzytelniania, takie jak MACsec. Ponieważ architektura zonalna centralizuje sieci, możliwe stają się również metody ataków oparte na Ethernecie; załamanie koncepcji separacji wejście/wyjście-przetwarzanie w przypadku naruszenia bezpieczeństwa stanowi ryzyko wymagające indywidualnej oceny.

Jak separacja sprzętu i oprogramowania umożliwia aktualizacje OTA?

Aktualizacja OTA to w większości dyskusji o SDV pierwsza rzecz, która przychodzi na myśl, ale sama w sobie nie jest zdolnością; jest skutkiem architektury. Bez podziału oprogramowania na niezależne, wielokrotnego użytku usługi, oddzielone od konkretnych chipów poprzez warstwę abstrakcji sprzętu (HAL) i podzielone na małe usługi (architektura zorientowana na usługi, SOA), ciągłe aktualizacje nie są możliwe. Separacja obejmuje również izolację oprogramowania o różnych poziomach bezpieczeństwa od siebie nawzajem.

Konkretnie oznacza to: architektura zonalna, dzięki aktualizacjom OTA/FOTA i stałemu połączeniu z chmurą, przekazuje producentowi kontrolę nad zaawansowaną konserwacją oprogramowania, jednocześnie przenosząc pętle sterowania w czasie rzeczywistym do modułów zonalnych. W pojazdach elektrycznych łatwiejsze stają się też subtelne regulacje, takie jak odcinanie zasilania nieużywanych modułów. Ostatecznie oprogramowanie pojazdu elektrycznego to, ponad bycie kanałem aktualizacji, warstwa definicji określająca funkcje pojazdu, systemy bezpieczeństwa i charakterystykę osiągów. Pojazd zaczyna przypominać rozproszyone centrum danych na kołach; łańcuch wartości opiera się na oprogramowaniu, mocy obliczeniowej i architekturze systemu.

Jak szybko potrwa transformacja i czy sama architektura strefowa wystarczy?

Przejście będzie stopniowe. Domena nadwozia (body), ponieważ zawiera wiele rozproszonych aktuatorów i ECU czujników, będzie pierwszym obszarem przejścia na architekturę strefową; przejście sterowania ADAS, napędu i podwozia może zająć więcej czasu ze względu na ich krytyczny dla bezpieczeństwa charakter. Ewolucja warstw MCAL, BSW i aplikacji, zachodząca od 2017 roku, pokazuje, że nie jest to techniczny projekt, lecz zmiana mentalności w skali całej branży.

Trzeba to jednak czytać z rozwagą. Architektura strefowa reorganizuje pojazd w sposób fizyczny; strona logiczna i oprogramowanie (SOA, HAL, cyberbezpieczeństwo) muszą zostać dodatkowo rozwiązane - samo przearanżowanie okablowania nie czyni pojazdu zdefiniowanym programowo. Prognozy wielkości rynku również znacznie się różnią w zależności od definicji zakresu; różne liczby dotyczące rynku architektury E/E wynikają z różnego mierzenia rynku w zależności od tego, co się wlicza (tylko platformy obliczeniowe czy cały rozproszony elektronika). Należy też pamiętać, że producenci półprzewodników i dostawcy rozwiązań, będący stronami tej transformacji, naturalnie mają w niej interes.

Wynikiem jest wyraźna inżynierska równowaga: zdefiniowanie pojazdu za pomocą oprogramowania jest możliwe tylko wtedy, gdy jednocześnie istnieją nowa organizacja sprzętu oparta na kontrolerach domenowych i strefowych, rozdzielone warstwy oprogramowania oraz deterministyczna, bezpieczna kręgosłup danych. Aktualizacja OTA to najbardziej widoczny owoc tej zintegrowanej struktury; prawdziwa rewolucja polega na tym, że sprzęt pojazdu przekazuje oprogramowaniu definicję swojego zadania.