Software Defined Vehicle přichází do dílny: proč bude diagnostika za pár let vypadat úplně jinak

Od auta s elektronikou k softwarové platformě

Ještě nedávno se dalo moderní auto z pohledu diagnostiky představit jako soubor mnoha samostatných řídicích jednotek. Motor měl svou jednotku, převodovka svou, komfortní systém svou, airbagy svou, ABS svou, infotainment svou. Každá jednotka měla vlastní úlohu, vlastní paměť závad a vlastní logiku komunikace. Technik se připojil, vybral systém, přečetl chyby, zkontroloval měřené hodnoty a podle výsledku postupoval dál.

Tento svět ale postupně končí. Ne ze dne na den, ne u všech značek najednou, ale směr je zřejmý. Vozidlo se mění z hardwarově rozděleného systému na softwarovou platformu. Funkce, které dříve žily v konkrétní řídicí jednotce, se přesouvají do centrálnějších výpočetních jednotek, do doménových řadičů nebo do zónové architektury. Zároveň přibývá komunikace s cloudem, vzdálených aktualizací a služeb, které se aktivují nebo mění během života vozidla.

Bosch popisuje Software Defined Vehicle jako vozidlo, jehož funkce lze průběžně optimalizovat a rozšiřovat pomocí konektivity a over-the-air aktualizací. Výrobce zároveň uvádí příklady funkcí aktivovaných individuálně podle potřeb řidiče, včetně dočasných služeb, aplikací nebo funkcí prodávaných jako služba.  

Pro zákazníka to zní jako komfort. Pro servis to znamená, že auto už nemusí být stejné dnes, jako bylo včera.

Když stejný model není technicky stejný

Mechanik je zvyklý pracovat s rokem výroby, motorizací, výbavou a kódem motoru. U softwarově definovaných vozidel bude muset stále častěji řešit také softwarovou verzi, aktivované funkce, stav aktualizací, regionální konfiguraci, předplatné služeb a historii zásahů.

Dvě auta stejného modelu a stejného ročníku proto nemusí být z diagnostického pohledu stejná. Jedno mohlo dostat novější OTA aktualizaci, druhé ne. Jedno může mít aktivovanou funkci, kterou druhé nemá. Jedno může mít upravené chování asistenčního systému po softwarové kampani výrobce, druhé může stále běžet na starší verzi.

To je zásadní rozdíl. U klasické poruchy hledáme vadný komponent, přerušený vodič, špatný snímač, problém s napájením nebo chybu komunikace. U softwarově definovaného vozidla ale může být příčina v nekompatibilní verzi softwaru, nedokončené aktualizaci, změně konfigurace, neaktivní online službě nebo v bezpečnostním omezení.

Zónová architektura: méně jednotek, ale složitější souvislosti

Jedním ze základních technických kroků směrem k SDV je změna elektrické a elektronické architektury vozidla. Tradiční model s velkým množstvím samostatných ECU je pro automobilky stále složitější, dražší a hůře aktualizovatelný. Proto se objevují centralizované a zónové architektury.

V tradičním autě se jednotky sdružují spíše podle funkce. V zónové architektuře se část logiky přesouvá do výkonnějších centrálních počítačů a zónové řadiče obsluhují fyzickou oblast vozidla. Jinými slovy: místo toho, aby každá funkce měla vlastní specializovanou jednotku, část funkcí běží jako software nad sdílenou výpočetní platformou.

Průmyslové analýzy z roku 2025 a 2026 popisují zónovou E/E architekturu jako způsob, jak snížit komplexitu kabeláže a zjednodušit komunikaci mezi řídicími jednotkami. S&P Global Mobility například uvádí, že zónová architektura snižuje složitost tím, že zefektivňuje komunikaci mezi ECU, zatímco aktuální technické přehledy k roku 2026 spojují centralizovanou a zónovou architekturu se software-defined vozidly, Ethernetem a virtualizací.

Pro dílnu to má jeden nepříjemný důsledek. Závada už nemusí být izolovaná v jedné jednotce. Pokud se problém objeví v centrální výpočetní platformě, v komunikační vrstvě nebo v softwarové službě, může se projevit ve více systémech najednou. Technik pak na diagnostice nevidí jednu krásně čitelnou chybu, ale shluk zdánlivě nesouvisejících příznaků.

Například po aktualizaci může zákazník přijet s tím, že se změnilo chování asistentu jízdy v pruhu, infotainment se chová jinak a vozidlo hlásí problém s online službou. U staršího auta by servis hledal tři oddělené závady. U SDV může jít o jeden softwarový nebo konfigurační problém.

OTA aktualizace: oprava bez servisu, ale i závada bez mechanického zásahu

Over-the-air aktualizace jsou jedním z nejviditelnějších prvků softwarově definovaného vozidla. Z pohledu výrobce dávají obrovský smysl. Není nutné svolávat vozidlo do servisu kvůli každé softwarové úpravě. Funkci lze zlepšit, opravit nebo doplnit vzdáleně. Elektrobit popisuje OTA řešení jako kompletní řetězec zahrnující backendové služby, OTA klienta a palubní komponenty pro software a firmware aktualizace.  

Jenže pro servis to přináší novou realitu. Auto se může změnit bez toho, aby fyzicky navštívilo dílnu. Zákazník přijede a řekne: „Od včerejška se to chová jinak.“ Mechanik otevře kapotu a nic nevidí. Kabeláž je v pořádku, konektory drží, snímač dává rozumné hodnoty. Přesto se vozidlo chová jinak, protože se změnil software.

To neznamená, že OTA je špatně. Naopak, z hlediska bezpečnosti a opravitelnosti může být velmi přínosné. Výzkumné práce k bezpečným OTA aktualizacím upozorňují, že vzdálené aktualizace jsou důležité pro snižování dopadů softwarových chyb a zranitelností v moderních E/E architekturách.  

Bez této informace může technik vyměnit díl, který není vadný.

Diagnostika už nebude jen čtení DTC

U klasického auta měla paměť závad centrální význam. DTC nebyl vždy úplnou odpovědí, ale byl dobrým začátkem. Ukázal směr. U SDV zůstane čtení závad důležité, ale nebude stačit.

Moderní diagnostika bude muset víc pracovat s kontextem. Nebude se ptát jen „která jednotka hlásí chybu“, ale také „v jaké softwarové verzi je systém“, „jaká služba měla běžet“, „která funkce je aktivovaná“, „jestli proběhla synchronizace“, „zda není funkce uzamčená autorizací“ a „jestli není problém mimo vozidlo“.

To je pro mnoho servisů nepříjemná změna. Mechanik je zvyklý, že když je auto na dílně, problém je v autě. U SDV to tak být nemusí. Příčina může být v backendu výrobce, v účtu zákazníka, v digitálním klíči, v licenci, v regionálním nastavení, v nekompatibilní aktualizaci nebo v bezpečnostní politice vozidla.

Typický příklad: zákazník si stěžuje, že nefunguje určitá komfortní nebo online funkce. Auto po hardwarové stránce komunikuje správně. Diagnostika neukazuje klasickou závadu. Problém je ale v tom, že služba není aktivní, účet není synchronizovaný nebo vozidlo čeká na dokončení aktualizace. To není práce pro kladivo ani pro výměnu jednotky. To je práce pro diagnostickou logiku, technickou podporu a znalost ekosystému výrobce.

Souvislost se SGW, SFD a kyberbezpečností

Software-defined vehicle nejde oddělit od tématu bezpečnosti. Čím více funkcí je softwarových, vzdáleně aktualizovatelných a propojených s cloudem, tím důležitější je kontrolovat, kdo smí co měnit. Proto zároveň přibývají bezpečnostní brány, autorizace, certifikáty, chráněné diagnostické funkce a přístupové systémy typu SGW/SFD.

U staršího auta bylo riziko neoprávněného zásahu omezenější. U softwarově definovaného vozidla může změna konfigurace ovlivnit nejen jednu jednotku, ale chování celého systému. To je důvod, proč výrobci zpřísňují diagnostický přístup. Není to jen obchodní boj o servisní trh, i když ekonomický rozměr tam samozřejmě také je. Je to také reakce na reálné riziko, že neověřený zásah do softwarového systému může mít bezpečnostní dopad.

Přehledová studie publikovaná v květnu 2026 popisuje SDV jako zásadní posun od hardwarově orientovaných systémů k softwarovým platformám s OTA aktualizacemi, automatizací, propojenými službami, cloudovou infrastrukturou, middlewarem a novými výzvami v oblasti kyberbezpečnosti, interoperability a správy dat.  

Pro mechanika to znamená jednoduchou věc: když se z auta stává softwarová platforma, diagnostický zásah se více podobá zásahu do IT systému. A u IT systému nikdy neřešíte jen „kabel a krabičku“. Řešíte oprávnění, verze, protokoly, závislosti a bezpečnostní politiku.

Co bude muset umět mechanik budoucnosti

Mechanik budoucnosti nebude programátor v montérkách. To by bylo přehnané a pro běžný servis nesmyslné. Ale bude muset rozumět základní logice softwarových systémů.

Bude muset vědět, že aktualizace může změnit chování vozidla. Bude muset umět poznat, kdy chyba vypadá jako hardwarová, ale ve skutečnosti souvisí s konfigurací. Bude muset chápat, proč bez správné autorizace nejde provést funkce, které dříve šly. Bude muset pracovat s protokoly, reporty, verzemi a online postupy.

To neznamená, že klasická mechanická práce zmizí. Brzdy, podvozek, motor, klimatizace, karoserie a elektroinstalace tu budou pořád. Rozdíl je v tom, že jejich oprava bude stále častěji končit softwarovým krokem. Výměna dílu bez adaptace nebude hotová práce. Oprava po nehodě bez kalibrace ADAS nebude hotová práce. Výměna jednotky bez online autorizace nebude hotová práce. A diagnostika bez pochopení architektury vozidla bude stále častěji slepá.

Co to znamená pro zákazníky diagnostik

Pro zákazníka diagnostiky už nebude nejdůležitější jen otázka, kolik značek přístroj podporuje. Důležité bude, jak dobře mu pomůže v reálné servisní situaci. U softwarově definovaných vozidel nestačí načíst co nejdelší seznam jednotek. Technik potřebuje vědět, co s informacemi udělat.

Tady DevCom vstupuje jako praktický partner pro servis. Nejen jako dodavatel diagnostického nástroje, ale jako firma, která pomáhá servisům orientovat se v nové elektronické realitě vozidel. U SGW/SFD to znamená vysvětlit, kdy je problém v autorizaci. U SDV to znamená pomoci technikovi rozlišit, zda řeší hardware, software, konfiguraci, online službu nebo omezení výrobce.

To je v praxi velmi cenné. Technik, který ví, že problém může být v softwarové vrstvě, zbytečně nevymění díl. Servis, který chápe význam aktualizací a autorizací, dokáže zákazníkovi lépe vysvětlit cenu i délku opravy. A prodejce diagnostiky, který tuto změnu umí vysvětlit, se nestaví do role prodejce zařízení, ale do role odborného průvodce.

Co by měl servis začít dělat už dnes

Nezávislý servis nemusí čekat, až bude každý vůz plně softwarově definovaný. Změna už začala. Už dnes je dobré zavést několik návyků.

U novějších vozidel by měl servis ukládat diagnostické reporty před a po opravě. Měl by si zapisovat softwarové verze tam, kde to diagnostika umožňuje. Měl by sledovat, jestli se problém objevil po aktualizaci, po výměně dílu, po nehodě nebo po zásahu jiného servisu. Měl by mít stabilní internetové připojení, stabilizovaný zdroj napětí a jasný proces pro online autorizované funkce.

Stejně důležité je školení techniků. Ne ve smyslu, že každý mechanik musí rozumět detailům middleware architektury. Ale měl by chápat, že moderní auto má softwarové závislosti. Měl by vědět, že chyba v jedné části se může projevit jinde. A měl by vědět, kdy má smysl volat technickou podporu dřív, než začne měnit díly.

Auto se mění, servis se musí změnit s ním

Software Defined Vehicle není marketingové heslo pro vývojáře. Je to trend, který se postupně objeví v každodenní servisní práci. Nejprve u prémiových a elektrických vozidel, pak u běžných modelů. Stejně jako se kdysi z diagnostiky stal standard, stane se standardem i práce se softwarem, verzemi, autorizacemi a online ekosystémem vozidla.

Pro mechaniky to není důvod k panice. Je to ale důvod změnit přemýšlení. Moderní závada nemusí mít podobu vadného snímače. Může mít podobu nedokončené aktualizace, neaktivní služby, změněné konfigurace nebo blokované funkce.