22 let na trhu autoopravárenství

Diagnostika od A do Z (7. část)

Pokračování článku najdete v časopisu AutoEXPERT 10/2018.

 

<toto je pokracovani serialu z AE 11/2017 na str. 29.

prosim logo Secons+votvirak stejny >

 

<modra>

 

TECHNIKA

DIAGNOSTIKA

 

Text: Martin Hinner

Foto: archiv společnosti Secons

 

Diagnostika od A do Z – 7 <sedmicka je cislo dilu>

 

ISO14229: UDS protokol <podtitulek>

 

Vážení čtenáři, v této sérii článků vás spolu se specialisty ze společnosti Secons seznamujeme s vývojem diagnostiky vozidel od počátku až do současnosti a představujeme známé i méně známé postupy při zjišťování závad prostřednictvím aplikací nebo přístrojů pro komunikaci s řídicími jednotkami. V rámci seriálu nahlédneme rovněž do vývojové dílny společnosti Secons a přiblížíme náročný vývoj nejmodernějších diagnostických součástí – softwaru i hardwaru. V tomto pokračování navazujeme na předchozí díl z AE 11/2017 na str. 29.

 

Velkým milníkem u automobilek bylo zavedení UDS protokolu (přibližně od roku 2007). Každý diagnostik o něm ví, ale málokdo dokáže „vědění“ zhmotnit do konkrétnější představy. Jde o diagnostický protokol fungující na sběrnici CAN-BUS na podobném principu jako ISO15765, pouze s rozšířenými a změněnými komunikačními příkazy. Toto rozšíření si vyžádaly moderní systémy (obr. 1), které obvykle disponují daleko více funkcemi, než původní protokoly efektivně umožňovaly. Pro uživatele je často snadno pozorovatelnou změnou mnohem delší chybový kód (obr. 2).

 

Řídicí jednotky toho na sebe řeknou více

Identifikace řídicích jednotek na protokolu UDS obvykle přináší celou řadu informací, většinou řádově více, než tomu bylo kvůli omezením dříve. Např. automobilka BMW (obr. 3) zakomponovala do identifikačních dat identifikace jednotlivých komponent řídicích jednotek.

 

Konfigurace

Obvykle mají UDS jednotky mnohem více konfiguračních dat než jejich předchůdci. Příčinou není ani tak UDS protokol, ten jen poskytl možnost zpřístupnit konfigurační data ve strukturovanějším formátu. Ta dříve byla „schována“ kdesi v útrobách EEPROM, v podstatě bez možnosti přizpůsobení.  Konfigurovat je u nových aut možné nepředstavitelnou spoustu věcí (obr. 4), bohužel dealerské diagnostiky většinou umožňují pouze nahrát „tovární data“ a o nějakém přizpůsobení si uživatel může nechat jen zdát. Neznačkové diagnostiky často musí vycházet z neoficiálních informací a vlastního reverzního inženýrství, nebo se jednoduše metodou pokus omyl dopracovat k výsledku.

 

UDS není revoluce, ale evoluce

Ačkoliv to navenek tak nemusí vypadat, daleko „revolučnější“ byla standardizace protokolu KWP2000, zmiňovaného v předchozích dílech, nebo vznik standardu SAE J1979. Tehdy došlo k přechodu výrobců z mnoha různých proprietárních diagnostických protokolů na jeden standardní. Protokol UDS pouze vzal v potaz požadavky nových, mnohdy až přeelektronizovaných aut. Z pohledu vývojářů diagnostiky jde jen „o další protokol“, ovšem poměrně chytře vymyšlený a zjednodušující život všem, kdo se jakkoliv podílí na diagnostice vozidel.

 

<toto prosim třeba do ramecku nebo nejak podbarvit (oddelit od textu pred a textu za)>

Mýty o protokolu UDS

O protokolu UDS panuje celá řada „hospodských“ mýtů. Některé jsou pravdivé, některé jsou ovlivněny konkrétními problémy diagnostických nástrojů, část je zcela mylná. Podívejme se na čtyři nejzajímavější:

 

Mýtus č. 1: Neznačkové diagnostiky s ním mají problém

Mají ho úplně stejný jako předtím. Jedinou výjimkou jsou diagnostiky, které nemusely s sebou „nést“ detailní soupis významu dat, který vrací řídicí jednotky. Typickým představitelem takové diagnostiky byl Volkswagen, Audi, Škoda a Seat, kde diagnostika byla vždy schopna zobrazit „alespoň“ kanály měřených hodnot a adaptací bez popisu. Stejně tak chybové kódy byly sdíleny mezi řídicími jednotkami. To se s příchodem diagnostiky VAG na UDS zcela změnilo a „nově“ je nutné pro každou řídicí jednotku pracně definovat dekódování a význam každé jednotlivé měřené hodnoty, každý akční člen, chybové kódy pro každou řídicí jednotku apod. To samozřejmě přináší celou řadu problémů, „které dříve nebyly“. Ostatně, pro diagnostiku VAG existovalo zřejmě nejvíce nástrojů ve srovnání s jinými značkami, protože naprogramovat takový diagnostický nástroj nebylo „zase až tak složité“ (problém je v detailech, pro běžné užití to ale tak bylo). Většina konkurenčních značek neměla nikdy obdobný systém a definice pro jednotlivé řídicí jednotky bylo nutné vytvářet již od „diagnostického pravěku“.

 

Mýtus č. 2: UDS vše sjednocuje…

… a vyvíjet diagnostické nástroje je mnohem jednodušší (nezbývá než vzpomenout na Stellu Zázvorkovou ve filmu Pelíšky: skláři, pardon – výrobci diagnostik, nebudou mít co žrát). Ani to není pravda. Norma UDS definuje pouze základní principy diagnostiky s ohledem na požadavky doby. To, jak si definuje výrobce význam diagnostických dat, je na normě zcela nezávislé.

 

Mýtus č. 3: UDS umožní „jednu diagnostiku na všechno“

UDS protokol specifikuje, „jak“ komunikovat, ale ne „co“ komunikovat. Je to podobné, jako kdyby člověk tvrdil, že latinské písmo umožňuje domluvit se v celé Evropě. Latinka je pouze „normou“, jak zapsat slova, nikoliv jaký je jejich význam.

U tohoto mýtu možná dochází k záměně termínu UDS a ASAM-MCD2 (resp. ODX, Open Diagnostic Data Exchange Format). Druhý zmiňovaný standard totiž specifikuje popisný (interpretační) formát diagnostických dat a ten teoreticky lze použít napříč značkami. Zásadní problém však je, že ODX data jsou určena primárně k výměně informací mezi automobilkou a jejími výrobci, nikoliv k použití v diagnostických testerech třetích stran.

 

Mýtus č. 4: UDS je složitější než předchozí systémy

Ano i ne. Složitější jsou především nové systémy, které vyžadují nové, složitější funkce. UDS protokol tomu vychází vstříc, a tak se může jevit, že je „původcem“ složitosti. Opak je ale pravda, složité jsou primárně dnešní automobilové systémy.

<konec ramecku (podbarveni)>

 

Standardizované informace

Přestože jsem výše uvedl, že UDS nespecifikuje význam dat, není to tak úplně pravda. Určité oblasti specifikovány jsou. Standardizovanost jednak zjednodušuje vývoj diagnostických aplikací, ale také umožňuje diagnostikům používat alespoň omezeně nástroje, není-li konkrétní diagnostikovaný systém zcela podporován.

 

Chybové kódy

Dodržuje-li automobilka standardní zápis kódu ve tvaru Pxxxx-xx (resp. P/C/B/Uxxxx-xx, viz předchozí díly seriálu), část rozsahu kódů je definována normou a tyto by měly mít stejný význam napříč všemi automobilkami i modely. Pokud diagnostický nástroj nemá specifický kód pro jednotku (třeba s upřesňujícím významem), měl by dostačovat chybový kód z normy. Existují výjimky (způsobené zřejmě nedostatečnou erudovaností vývojářů v automobilkách a u jejich dodavatelů), avšak obvykle se lze na význam kódu spolehnout (obr. 5).

 

Chyby pohonu Chyby podvozku (ABS apod.) Chyby karoseriových (body) systémů (airbag, interiérová ŘJU apod.) Síťové chybové kódy (CAN-BUS, LIN, FlexRay, D2B, MOST)
P0xxx C0xxx B0xxx U0xxx (N0xxx)
P2xxx C3xxx B3xxx U3xxx (N3xxx)
P34xx-P39xx

Obr. 5: Obecné chybové kódy, na které by se v ideálním světě mělo dát spolehnout i v případě, že nejsou definovány na míru řídicí jednotce (obecné, definované normou).

 

Identifikační data

Norma UDS specifikuje též základní sadu identifikačních dat (občas se lze setkat s označením DIDy F1xx). Dodržuje-li jednotka normu, může diagnostika i u nepodporovaných řídicích jednotek vypsat smysluplné údaje.

 

OBD-II (emisní) měřené hodnoty

Obdobně norma UDS specifikuje základní měřené hodnoty kopírující emisní diagnostiku (jde o DIDy F4xx). Opět, dodržuje-li jednotka normu, diagnostika může i bez přímé podpory zobrazit alespoň pár měřených hodnot, případně je možné „snadno a rychle“ přidat podporu řídicí jednotky v diagnostickém testeru.

 

Příklad variability praxi

Jak bylo uvedeno výše, protokol UDS přináší jistou variabilitu. Typickým příkladem je možnost specifikovat formát hodnoty, která se posílá řídicí jednotce, např. adresy nebo délky pro přímé čtení paměti (příkaz 23, Read memory by address). Budeme-li číst u protokolu KWP2000 paměť, formát příkazu je vždy 23 AA AA AA LL (kde AA je adresa, LL je délka). Tedy např. vyčtení 5 bajtů z adresy 1234 se provádí příkazem 23 00 12 34 05. Z formátu příkazu je patrné, že adresa může teoreticky nabývat maximálně hodnot 000000–FFFFFF (24 bitů) a délky 01–FF (tj., 1–255 bajtů; v realitě je to ale méně, nejen omezením řídicích jednotek, ale i samotného protokolu KWP2000). Co s jednotkami, které mají 32bitovou sběrnici, tedy adresy až do FFFFFFFF? Co když chcete načíst více než 255 bajtů najednou? U KWP2000 se první problém řešil tzv. mapováním paměti, tedy do 24bitového prostoru se namapovaly výseky z 32bitového prostoru. Opravdové řešení přináší protokol UDS, který specifikuje velikost (délku) adresy i požadované velikosti dat. Formát příkazu potom vypadá tak, že část adresy (AA) i délky (LL) může dosahovat 1–4 bajtů a před tyto údaje je předřazena informace o délkách. Všechny tyto příkazy jsou identické s prvně uváděným, tj. čtení 5 bajtů z adresy 1234: 23 24 00 00 12 34 00 05 / 23 12 12 34 05 / 23 44 00 00 12 34 00 00 00 05

 

Návaznost na jiné normy

Protokol UDS je úzce provázán zejména s normou ISO15765: Diagnostic communication over Controller Area Network, která specifikuje transportní vrstvu po sběrnici CAN-BUS, a samozřejmě vlastní normou specifikující sběrnici CAN-BUS, tedy ISO 11898. Formát příkazů vychází z norem ISO14320 (Protokol KWP2000), ISO15765 (diagnostika na CAN-BUS), SAE J1979 – Emisní diagnostické příkazy, a samozřejmě i navazující emisní diagnostiky (ISO9141-4 a ISO 15031).

 

Neobvyklé formáty chybových kódů

Další zajímavostí je, že např. automobilky BMW a Volkswagen (a s ním i Porsche) nepoužívají standardizovaný formát chybových kódů ve tvaru Pxxxx-xx (viz obr. 2), ale jejich přímé číselné vyjádření v decimální (obr. 6) či hexadecimální podobě (obr. 7). Volkswagen/Audi/Porsche mají dvě zajímavosti: u většiny řídicích jednotek, převedou-li se kódy z desítkové do šestnáctkové soustavy, začnou jednotlivé pozice v nich mít jednotný význam (např. poslední číslice/znak značí pro určitou skupinu symptom, nebo jiná pozice odlišuje pravý/levý prvek nebo číslo válce apod.). Ještě zajímavější je, že kódy u Volkswagenu nejsou převoditelné přímo na Pxxx-kódy, ale dealerská diagnostika ODIS musí obsahovat tabulky individuálně pro každý kód. Podobný systém dříve používala automobilka Renault.

 

<toto prosim do ramecku nebo nejak zvýraznit>

Perlička z vývoje diagnostiky Porsche

Porsche používá v nových vozech často řídicí jednotky koncernu Volkswagen, ovšem s drobnými změnami. Často jde o velmi nenápadné změny, kdy se drobně liší příkaz pro čtení chybových kódů. Standardní „Volkswagen-varianta“ vrací jen podmnožinu chybových kódů nebo „vozidlo bez chyb“. Porsche-varianta potom vrátí reálné chyby. Tento stav komplikuje nejen vývoj diagnostického nástroje, ale i případné použití diagnostického nástroje Volkswagen na vozech Porsche (oblíbené tvrzení „Cayenne je jen převlečený Touareg“ proto v diagnostice rozhodně neplatí).

<konec ramecku >

 

Pokračování příště.

 

V článku bylo použito materiálů společnosti SECONS s. r. o., info@secons.com.

 

<Popisky obrazku:>

Obr. 1: Moderní řídicí jednotky s protokolem UDS běžně podporují řádově stovky měřených hodnot i na „tuctových“ motorech. V diagnostickém testeru je pro přehlednost pouze nejobvyklejší podmnožina. Zobrazeny jsou počty měřených hodnot vozu Fiat Ducato 2011+.

 

Obr. 2: Rozšířený chybový kód UDS protokolu. Před jeho nástupem byly obvyklé pětimístné chybové kódy např. ve tvaru P0101, UDS zavedlo další hodnotu definující rozšiřující stav chyby (zde kód 22), tj., chybový kód je nově sedmimístný (P0101-22).

 

Obr. 3: Identifikace jednotlivých softwarových a hardwarových součástí řídicí jednotky vč. individuálních verzí (revizí). Dealerská diagnostika přes tyto údaje zjišťuje, které části je nutné aktualizovat.

 

Obr. 4: Ukázka konfigurace panelu přístrojů VDO Porsche Cayenne typ 958. Nastavit lze dokonce i to, která chybová hlášení se budou zobrazovat na displeji, či povolovat funkce palubního počítače. Velikost posuvníku odpovídá rozsahu – asi 400 zobrazeným konfigurovatelným parametrům.

 

Obr. 6: Decimální kódy UDS řídicí jednotky Porsche.

 

Obr. 7: Hexadecimální kódy UDS jednotky BMW Bosch EDC17CP09.