Dvě stejná auta už nemusí být diagnosticky stejná
Pro mechanika je přirozené přemýšlet o vozidle podle značky, modelu, roku výroby, motoru a výbavy. Pokud vedle sebe postavíme dvě stejně vybavené Octavie nebo dva Mercedesy stejného modelového roku, očekáváme, že jejich řídicí jednotky budou z pohledu diagnostiky fungovat prakticky stejně. U moderních vozidel to ale nemusí platit!
Automobilky dnes software vozidel aktualizují během jejich provozního života. Aktualizace může proběhnout při návštěvě autorizovaného servisu, během servisní kampaně nebo vzdáleně pomocí OTA. Volkswagen například u vozidel platformy MEB popisuje OTA architekturu schopnou aktualizovat software až několika desítek řídicích jednotek. BMW uvádí vzdálené aktualizace napříč oblastmi infotainmentu, ADAS, řízení i komfortních funkcí.
Hardware přitom může zůstat stejný. Na štítku řídicí jednotky může být stejné číslo dílu. Konektor je stejný. Jednotka komunikuje po stejné sběrnici. Vozidlo na pohled funguje stejně. Uvnitř ale běží jiná verze softwaru.
A právě software určuje značnou část toho, jaké diagnostické funkce jednotka podporuje a jak mají být její odpovědi interpretovány.
Co je vlastně „varianta ECU“
Profesionální diagnostika nepracuje pouze s jednoduchým seznamem typu „motorová jednotka Bosch XYZ – ano/ne“. Potřebuje znát konkrétní implementaci diagnostiky uvnitř jednotky.
Standard ODX, tedy Open Diagnostic Data Exchange podle ISO 22901-1, který se používá v automobilovém průmyslu k popisu diagnostických dat, přímo počítá s různými „ECU variants“. ODX dokáže popsat diagnostické služby, jejich požadavky a odpovědi, DTC, měřené hodnoty, flashování, variant coding i další diagnostické funkce.
A ještě důležitější je druhá část: standard počítá také s tím, že diagnostický tester musí umět konkrétní variantu jednotky identifikovat.
ASAM popisuje mechanismus, při kterém tester načte identifikační informace z ECU běžnými diagnostickými příkazy a následně je porovná s identifikačními vzory jednotlivých variant. Teprve když najde shodu, ví, kterou diagnostickou definici má použít.
To je přesně technický problém, který se v běžné dílně skrývá za jednoduchou hláškou „řídicí jednotka nebyla rozpoznána“.
Proč nestačí říct: vždyť je to pořád stejná ECU!?
Protože diagnostika není jen komunikace. Přijmout z jednotky několik bajtů je relativně jednoduché. Mnohem složitější je vědět, co ty bajty znamenají.
Představme si, že se diagnostika zeptá ECU na určitý měřený parametr. Jednotka odpoví například dvěma bajty. Bez správného diagnostického popisu nevíme, jestli číslo znamená tlak v barech, teplotu, otáčky, procenta, napětí nebo například stavový příznak. Diagnostická databáze obsahuje informace o tom, jak odpověď dekódovat, jakou použít matematickou transformaci, jednotku a jak hodnotu zobrazit.
Softing (Softing Automotive) popisuje ODX právě jako mechanismus, který převádí hexadecimální diagnostickou komunikaci do fyzikálních a lidsky čitelných hodnot. Databáze přitom obsahuje jednotlivé varianty řídicích jednotek a informace pro jejich diagnostické služby.
Pokud se tedy použije nesprávná varianta, není nejhorším výsledkem vždy chybové hlášení. Horší je situace, kdy odpověď technicky přijde a software ji dokáže nějak interpretovat – ale podle pravidel jiné varianty. Na obrazovce potom může vzniknout údaj, který vypadá realisticky, ale technik z něj vyvodí chybný závěr.
U závad může být problém podobný. Samotný DTC může být přečten správně, ale jeho textové vysvětlení, subtyp, freeze-frame data nebo rozšířené informace mohou záviset na konkrétní implementaci.
A co servisní funkce?
Tam je problém ještě viditelnější. Test akčního členu, kalibrace, adaptace, základní nastavení nebo kódování nejsou univerzální příkazy typu „zapni ventil“. Za funkcí se často skrývá přesná sekvence diagnostických služeb, přepnutí do správné diagnostické session, bezpečnostní přístup, parametrizace požadavku, kontrola podmínek a vyhodnocení odpovědi.
Pokud nová softwarová varianta ECU používá jinou rutinu, jiný identifikátor, jiné parametry nebo jiné podmínky spuštění, starší diagnostický popis může přestat fungovat. Výsledkem může být hláška „funkce není podporována“, negativní odpověď ECU nebo prostě situace, kdy tlačítko, které před aktualizací fungovalo, najednou nevede k očekávanému výsledku.
A přitom není vadný ani automobil, ani diagnostický interface. Diagnostický software pouze ještě nezná novou variantu.
Aktualizace automobilky tedy může „rozbít diagnostiku“?
Přesnější formulace je: aktualizace automobilky může vytvořit stav, kdy stávající diagnostická databáze novou variantu ECU ještě nezná nebo ji neumí jednoznačně identifikovat.
Ne každá aktualizace diagnostiku změní. Řada aktualizací opravuje pouze interní chybu nebo mění algoritmus, aniž by se diagnostické rozhraní výrazně změnilo. Ale změnit se může. Softing například upozorňuje, že diagnostické databáze moderních vozidel během jejich životnosti narůstají právě kvůli novým variantám, servisním opatřením a rozšiřování funkcí.
Mercedes-Benz současně veřejně popisuje, že kvalita dat poskytovaných jeho telematickou jednotkou může záviset na aktuální SW verzi a že starší software může vést k odlišnému či nekonzistentnímu chování při přenosu dat. Není to přímo příklad servisní diagnostiky, ale dobře to ilustruje základní princip: změna ECU softwaru může změnit její komunikační chování, aniž by se změnil hardware.
Co znamená autodetekce varianty SW ECU u DevCom
Právě tento problém se DevCom snaží řešit funkcí označovanou jako autodetekce varianty SW ECU. Smyslem není pouze zjistit, že se ve vozidle nachází například motorová řídicí jednotka.
Diagnostika se snaží pomocí identifikačních údajů určit její konkrétní softwarovou variantu a následně k ní přiřadit odpovídající diagnostická data. To je důležité zejména tam, kde jedna hardwarová rodina ECU existuje v mnoha softwarových verzích.
Aktualizace diagnostik DevCom rozšiřují identifikátory stávajících řídicích jednotek a funkce jejich rozpoznávání. U některých značek zároveň přímo uvádíme autodetekci řídicích jednotek jako součást diagnostiky.
Cílem je určit variantu pokud možno jednoznačně. Pokud ji diagnostika nedokáže spolehlivě určit, musí někdy nabídnout více známých variant k ručnímu výběru.
A právě zde je nutná opatrnost. Náhodně vybrat „něco, co funguje“, není správný diagnostický postup.
Autodetekci variant jednotek najdete na všech diagnostikách DevCom.
Proč může být špatná volba horší než žádná volba?
Pokud diagnostika jednotku vůbec nezná, problém je alespoň zřejmý. Technik vidí, že něco není v pořádku. Pokud ale ručně vybere velmi podobnou variantu, diagnostika může začít částečně fungovat. Některé hodnoty se zobrazí. Některé DTC se přeloží. Některá funkce dokonce může reagovat.
Právě tehdy vzniká riziko falešné jistoty. Záměna variant může vést ke špatnému dekódování parametrů nebo k použití diagnostické procedury, která byla vytvořena pro jinou verzi softwaru. U čistě čtecích funkcí výsledkem může být chybná diagnóza. U zápisových funkcí, kódování nebo parametrizace už je proto na místě výrazně větší opatrnost.
Co dělat když diagnostika najednou nefunguje?
První krok by neměl být „tahle diagnostika je špatná“. Stejně tak ale není správné automaticky prohlásit, že automobilka určitě provedla update. Příčinou ztráty komunikace může být také problém s napájením ECU, CAN/DoIP sítí, gateway, SGW/SFD autorizací, výměnou jednotky, změnou kódování nebo samotným diagnostickým interface.
Pokud ale jde o vozidlo, které bylo dříve se stejnou diagnostikou bez problému obsluhované, a zvlášť pokud mezitím navštívilo autorizovaný servis nebo dostalo OTA update, nová softwarová varianta patří mezi první věci, které má smysl ověřit.
Prakticky je užitečné uložit kompletní identifikaci jednotky: číslo HW, číslo SW, verzi softwaru, případné kalibrační identifikátory a VIN. Následně porovnat informace s předchozím záznamem, pokud existuje. Pokud diagnostika novou variantu nezná, právě tyto informace jsou pro vývojáře nejcennější.
Kvalitní technická podpora je vždy důležitá
Tento příklad dobře ukazuje, proč u moderní diagnostiky není technická podpora jen služba pro zákazníka, který „neví, kam kliknout“. Mechanik může narazit na úplně novou softwarovou variantu ECU, kterou výrobce vozidla vydal před několika týdny.
To je problém databáze a vývoje, nikoliv mechanikových schopností.
DevCom se dlouhodobě věnuje vývoji vlastní dignostické databáze, jejím pravidelným aktualizacím a technickou podporu pro TSPro a Troodon. Na podpoře zároveň přímo vyzývá zákazníky, aby při konkrétním problému poskytli co nejpodrobnější popis.
V podobné situaci tedy dává smysl kontaktovat podporu a dodat VIN, identifikaci ECU, HW/SW čísla, screenshot problému a informaci, zda vozidlo v poslední době prošlo aktualizací nebo návštěvou autorizovaného servisu. Pro vývojáře je to přesně ten typ dat, podle kterého může být nová varianta identifikována a následně doplněna do diagnostiky.
Zkušenosti z praxe
Na odborných fórech lze dohledat případy, kdy změna nebo neobvyklá kombinace ECU softwaru vedla k tomu, že profesionální diagnostika nedokázala variantu jednotky správně určit.
Například na fóru MHH Auto je popsán případ Mercedesu W205, kde po aktualizaci softwaru motorové ECU přestaly XENTRY i aftermarketová diagnostika variantu správně rozpoznávat. Jde o zkušenost jednoho uživatele, nikoliv o oficiální technický bulletin, takže z ní nelze dělat obecné pravidlo, nicméně dobře ilustruje přesně ten druh problému, o kterém je řeč.
Na dalších fórech jsou zase dokumentovány případy, kdy bylo potřeba doplnit nebo aktualizovat diagnostická data, aby určitá ECU varianta měla správné popisy a funkce. I zde jde o konkrétní případy, nikoliv důkaz, že každá OEM aktualizace způsobí problém.
Moderní diagnostika je živá databáze
Možná nejdůležitější pointa celého tématu je právě tato. Diagnostický přístroj není hotový výrobek ve smyslu klasického multimetru. Hardware může být stejný mnoho let, ale diagnostická datová základna musí žít společně s vozidly.
Automobilka vydá nový model, přibude ECU. Vznikne nový modelový rok, přibude varianta. Přijde servisní update, může vzniknout další verze. A právě proto jsou aktualizace profesionální diagnostiky tak důležité. Nejde jen o přidávání nových aut do menu.
Část vývojové práce se odehrává hluboko pod ním: v identifikaci řídicích jednotek, mapování jednotlivých softwarových variant a v ověřování, že DTC, měřené hodnoty a servisní procedury odpovídají přesně tomu softwaru, který ve vozidle skutečně běží.