ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ. Fakulta elektrotechnická BAKALÁŘSKÝ PROJEKT. Diagnostika automobilových řídicích jednotek

ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ Fakulta elektrotechnická

BAKALÁŘSKÝ PROJEKT Diagnostika automobilových řídicích jednotek

Martin Hinner 2006

Zadání BP

-2-

Anotace Cílem této práce je implementovat diagnostické protokoly používané na vozidlech skupiny Volkswagen. Řešení je založeno na hand-held testeru s vlastní klávesnicí a LCD displayem, s použitím procesoru ARM7TDMI řady AT91SAM7 od firmy Atmel Inc. Hlavní výhodou zvoleného řešení s vlastním HW bez použití PC je možnost implementovat všechny časově kritické operace při komunikaci dle požadavků jednotlivých protokolů. Díky velkému množství periferií zvoleného procesoru se zjednodušuje návrh plošného spoje i vlastní implementace.

Annotation The aim of this work is to implement diagnostics protocols used on Volkswagen group vehicles. The solution is based on a hand-held tester with keyboard and LCD display, utilizing Atmel AT91SAM7 series ARM7TDMI microcontroller. The most important advantage of proprietary non-PC based hardware is ability to implement time-critical communication as required by all used diagnostics protocols. Due to wide range of peripherials embedded in chosen microcontroller, printed circuit board design and firmware implementation were greatly simplified.

-3-

Prohlášení Prohlašuji, že jsem svou bakalářskou práci vypracoval samostatně a použil jsem pouze podklady (literaturu, projekty, SW atd.) uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu § 60 Zákona č.121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). Některé názvy a označení použitá v této práci mohou být registrovanými nebo obchodními značkami.

V Praze dne 22. května 2006

Martin Hinner

Poděkování Na tomto místě bych rád poděkoval vedoucímu mé práce Ing. Jiřímu Novákovi, PhD., Janu Svobodovi za trpělivé testováni vytvořeného kódu na vozidlech, a přítelkyni Mgr. Veronice Zachové za podporu při studiu i práci.

-4-

Obsah Zadání BP .......................................................................................................... 2 Anotace .............................................................................................................. 3 Annotation ......................................................................................................... 3 Prohlášení .......................................................................................................... 4 Poděkování......................................................................................................... 4 Obsah ................................................................................................................. 5 Seznam obrázků ................................................................................................. 7 Seznam tabulek .................................................................................................. 7 Seznam zkratek .................................................................................................. 8 1. Úvod .............................................................................................................. 9 2. Obecný popis automobilové diagnostiky ...................................................... 11 2.1 Fyzická vrstva ......................................................................................... 11 2.1.1 ISO 9141 (K-Line, L-Line) ............................................................... 11 2.1.2 General Motors J1850 VPW ............................................................. 12 2.1.2 Ford J1850 PWM.............................................................................. 14 2.1.4 CAN-BUS ........................................................................................ 16 2.2 Norma ISO 9141, inicializace komunikace ............................................. 17 2.3 Proprietární protokoly (BOSCH, Magneti-Marelli, …) ........................... 18 2.4 Protokoly výrobce automobilu ................................................................ 18 2.5 Norma OBD-II........................................................................................ 19 2.6 Protokol KWP2000.............................................................................. 19 2.7 Sběrnice CAN-BUS: ISO 15765, VW TP............................................ 20 3. Popis diagnostiky koncernu Volkswagen ..................................................... 21 3.1 Diagnostické zásuvky ............................................................................. 21 3.1.1 Konektor 2x2pin ............................................................................... 22 3.1.2 Konektor OBD-II (CARB)................................................................ 22 3.1.3 Konektor VW LT.............................................................................. 23 3.2 Popis diagnostických protokolů vozidel skupiny VW ............................. 24 3.2.1 Komunikační protokol KW-71.......................................................... 24 3.2.2 Komunikační protokol KW-1281...................................................... 26 3.2.3 Komunikační protokol VW KWP 2000 (ISO 14230)........................ 27 3.2.4 Komunikační protokoly VW TP 1.4 & 1.6........................................ 29 3.2.5 Komunikační protokol VW TP 2.0 ................................................... 30 3.2.6 Komunikační protokol normy OBD-II – ISO9141 ........................... 32 3.2.7 Komunikační protokol normy OBD-II – ISO 14230-4 ..................... 33 3.2.8 Komunikační protokol normy OBD2 via CAN (ISO 15765-4) ......... 34 4 Implementace testeru.................................................................................... 36 4.1 Hardwarové požadavky........................................................................... 36 4.2 Softwarové požadavky ............................................................................ 36

-5-

4.3 Návrh hardware....................................................................................... 38 4.3.1 Mechanické prvky ............................................................................ 38 4.3.2 Napájení ........................................................................................... 39 4.3.3 Mikroprocesor .................................................................................. 39 4.3.4 Display, klávesnice ........................................................................... 41 4.3.5 Rozhraní K-Line: ISO 9141 .............................................................. 42 4.3.6 Rozhraní CAN-BUS (High-speed).................................................... 43 4.4 Návrh software........................................................................................ 44 4.4.1 Implementace přepínače úloh ........................................................... 44 4.4.2 Implementace systému uživatelského rozhraní ................................. 45 4.4.3 Implementace komunikačního vlákna ............................................... 46 4.4.4 Inicializace K vedení, detekce komunikační rychlosti....................... 46 4.4.8 Doplňkové funkce............................................................................. 47 5 Řešení problémů s časováním, odchylky proti normám................................. 48 5.1 Časování komunikace – timing ............................................................... 48 5.2 Odchylky proti zvyklostem a normám..................................................... 48 6 Závěr............................................................................................................. 49 8 Seznam odborné literatury............................................................................. 51 9 Přílohy........................................................................................................... 52 9.1 Schéma testeru ........................................................................................ 53 9.2 Osazovací výkres plošného spoje ............................................................ 54 9.3 Osazený plošný spoj................................................................................ 55 9.4 Zkompletovaný tester.............................................................................. 56

-6-

Seznam obrázků Obrázek 1 Diagnostický nástroj VAG 1552 ..................................................... 10 Obrázek 2 Zjednodušené elektrické schéma sběrnice ISO9141......................... 11 Obrázek 3 Přenos dat na K vedení ................................................................... 12 Obrázek 4 Zjednodušené elektrické schéma VPW sběrnice .............................. 13 Obrázek 5 Struktura rámce VPW sběrnice ....................................................... 14 Obrázek 6 Připojení ECU na PWM sběrnici .................................................... 15 Obrázek 7 Zobrazeni "2x2" diagnostické zásuvky ............................................ 22 Obrázek 8 Zobrazení OBD-II diagnostické zásuvky.......................................... 22 Obrázek 9 Zobrazení VW LT diagnostické zásuvky.......................................... 23 Obrázek 10 Formát zprávy protokolu KWP2000.............................................. 27 Obrázek 11 Blokové schéma testeru ................................................................ 38 Obrázek 12 Blokové schéma MCU AT91SAM7A3 ............................................ 40 Obrázek 13 Schéma zapojení rozhraní ISO 9141 ............................................. 42 Obrázek 14 Schéma testeru .............................................................................. 53 Obrázek 15 Osazovací výkres plošného spoje................................................... 54 Obrázek 16 Osazený plošný spoj testeru........................................................... 55 Obrázek 17 Zkompletovaný ruční tester ........................................................... 56

Seznam tabulek Tab. 1 Časové konstanty pulsů VPW sběrnice .................................................. 13 Tab. 2 Časové konstanty pulsů PWM sběrnice ................................................. 16 Tab. 3 Příklad inicializace ISO9141 Slowinit .................................................. 17 Tab. 4 Příklady diagnostických protokolů jednotlivých automobilek ................ 18 Tab. 5 Skupiny příkazů definovaných v protokolu KWP2000............................ 19 Tab. 6 Zapojení „2x2“ diagnostické zásuvky.................................................... 22 Tab. 7 Zapojení OBD-II diagnostické zásuvky.................................................. 23 Tab. 8 Zapojení VW LT diagnostické zásuvky................................................... 24 Tab. 9 Příklad inicializace protokolu RB KW 71 .............................................. 24 Tab. 10 Struktura bloku protokolu RB KW 71 ................................................. 24 Tab. 11 Příklad komunikace protokolu RB KW 71 .......................................... 25 Tab. 12 Příkazy protokolu RB KW 71............................................................... 25 Tab. 13 Příkazy protokolu KW 1281 ................................................................ 26 Tab. 14 Příklad komunikace protokolem KW-1281 .......................................... 27 Tab. 15 Příkazy definované v protokolu KWP2000 .......................................... 29 Tab. 16 Příklad komunikace protokolu KWP2000 (Motor, EDC 16) ............... 29 Tab. 17 Formát inicializačního rámce protokolu VW TP 2.0............................ 30 Tab. 18 Formát rámců protokolu VW TP 2.0 ................................................... 31 Tab. 19 Příklad komunikace VW TP 2.0 ........................................................... 32 Tab. 20 Módy emisní diagnostiky .................................................................... 33 Tab. 21 Příklad komunikace OBD-II ISO9141 ................................................ 33 -7-

Tab. 22 Příklad komunikace OBD-II ISO 14320 ............................................ 34 Tab. 23 Ukázka komunikace ISO 15765-4 ........................................................ 35 Tab. 24 Zapojení JTAG IEEE 1149.1 konektoru pro ARM7 ............................. 41 Tab. 25 Zapojení konektoru displaye PG 12864 .............................................. 41 Tab. 26 Funkce přepínače úloh ........................................................................ 45 Tab. 27 Příklad testovaných vozidel ................................................................. 49

Seznam zkratek BRK CAN-BUS CRC DC DTC EOD EOF IFR IFS ISO KW MCU MIL N/A NB OBD SOF VW

Break Controller Area Network Bus Cyclic Redundancy Check Disconnect Diagnostics Trouble Code End of Data End of Frame In-Frame Response (Byte/Bytes) Inter-Frame Separation International Standards Organization Keyword Microcontroller unit Malfunction Indication Light Not Applicable Normalization Bit On-Board Diagnostics Start of Frame Volkswagen

-8-

1. Úvod S rozšířením digitálně pracujících řídicích jednotek (ECU, Electronic Control Unit) v automobilech koncem 80. let minulého století vznikla potřeba diagnostiky těchto systémů. Mezi základní funkce každé digitální automobilové diagnostiky ECU patří zejména: - Identifikační služby Zobrazení informací o ECU, zejména objednací číslo, výrobce, datum programování, apod. - Výpis paměti závad Seznam chyb, které od poslední diagnostiky systému byly přítomny s rozlišením druhu chybu (statická, sporadická, atd.). - Čtení měřených hodnot Zobrazení jednotlivých veličin měřených ECU, případně zobrazení dat přijatých od dalších systémů. - Test akčních členů Testování akčních členů připojených k ECU. - Nastavení parametrů ECU Reset servisních intervalů, provedení základního nastavení, přizpůsobení různých parametrů, korekce měřených hodnot. - Bezpečnostní funkce Odemčení přístupu do ECU (zadání PIN kódu, RSA autorizace). - Aktualizace firmware Výměna kalibračních dat nebo programového vybavení. Postupem času se vyvinula řada diagnostických protokolů. Z počátku byly tyto protokoly proprietární. V polovině 90. let došlo k vytvoření několika protokolů, ze kterých vznikly různé odnože. Tyto protokoly jsou využívány v různé podobě až do dnešní doby. Koncem 90. let minulého století byly dále standardizovány protokoly, které si kladly za cíl sjednotit formu diagnostiky a jednotlivých příkazů a tím snížit náklady na vývoj ECU. Cílem této práce je seznámit se obecně s diagnostikou moderních vozidel a implementovat diagnostické funkce automobilů skupiny Volkswagen. Jedná se zejména o vozidla Volkswagen, Audi, Seat, Škoda, ale částečně také Ford (např. model Galaxy), Porsche (např. model Cayenne), atd.

-9-

Výsledkem by měly být knihovny, které umožní plnohodnotnou komunikaci všemi protokoly využívanými ECU v těchto vozidlech, a následná implementace testeru, který plně nahradí originální servisní vybaveni VAG 1552, resp. VAS 5051 a VAS 5052.

Obrázek 1 Diagnostický nástroj VAG 1552

- 10 -

2. Obecný popis automobilové diagnostiky Diagnostika ECU probíhá po připojení diagnostického přístroje k vozidlu prostřednictvím diagnostické zásuvky. Tato zásuvka bývá umístěna většinou v blízkosti sedadla řidiče nebo v motorovém prostoru. Do roku 1996 používali jednotliví výrobci vlastní zásuvky, po roce 1996 došlo v USA a následně po celém světě ke sjednocení, a vozidla byla vybavována zásuvkou OBD-II (CARB). Pro diagnostiku (přenos dat) se používá několik typů fyzických vrstev. Zpočátku se jednalo o tzv. K-Line a L-Line, sběrnici VPW a PWM. Od roku 2000 dochází k postupnému nahrazování sběrnicí CAN (Controller Area Network). Bezdrátová komunikace není využita. V této kapitole popíši stručně jednotlivé sběrnice použité na diagnostiku a využívané komunikační protokoly. 2.1 Fyzická vrstva 2.1.1 ISO 9141 (K-Line, L-Line)

Norma ISO 9141 definuje fyzickou vrstvu pro komunikaci následujícím způsobem: Každá ECU musí mít jeden (K) nebo dva (K a L) komunikační kanály. Všechny napěťové úrovně jsou vztaženy k napětí na baterii (VB) a kostře vozidla (GND). Po připojení diagnostického testeru k ECU vypadá zjednodušené elektrické schéma takto:

Obrázek 2 Zjednodušené elektrické schéma sběrnice ISO9141

- 11 -

Význam jednotlivých hodnot součástek zjednodušeného schématu je popsán v [5]. Napěťová úroveň na komunikačním vedení K nebo L větší než 60% napětí baterie automobilu odpovídá stavu log. 1, napěťová úroveň méně než 30% napětí baterie odpovídá log. 0. K a L vedení používá asynchronní přenos informací. Každý přenesený bajt konstantní rychlostí je proto třeba synchronizovat. K synchronizaci se používá sestupná hrana tzv. start bitu. Dále následuje start bit, datové slovo, volitelně paritní bit a jeden nebo více stop bitů. Stop bit nastaví vždy komunikaci na původní úroveň, ve které zůstává až do následující sestupné hrany a dalším start bitem. Datové slovo se posílá vždy od nejméně významového bitu (LSB). Při komunikaci po K nebo L je v určitých případech využíváno zabezpečení dat paritou (sudá i lichá, dle protokolu). Jednoduché schéma komunikace je zobrazeno na následujícím obrázku.

Obrázek 3 Přenos dat na K vedení

Formát přenášených dat je tedy shodný s asynchronním přenosem dat na RS232 nebo RS422/485. Standard ISO9141 nedefinuje žádná další pravidla pro komunikaci (složení bloků dat, zabezpečení kontrolním součtem, synchronizace, apod). 2.1.2 General Motors J1850 VPW

Vozidla společnosti General Motors používají pro komunikaci sběrnici J1850 VPW (Variable Pulse Width). Jedná se o jednovodičovou sběrnici, která přenáší rámce (frames). Fyzická vrstva je definována ve standardu SAE J1850 tímto způsobem:

- 12 -

Každá ECU je vybavena jedním jednovodičovým komunikačním kanálem. Všechny napěťové úrovně jsou vztaženy absolutně ke kostře vozidla (GND).

Obrázek 4 Zjednodušené elektrické schéma VPW sběrnice

Sběrnice má definovány dva stavy: „low voltage“ – 0 až 3.5 V „high voltage“ – 6.25 až 8V V klidovém stavu je sběrnice na úrovni „low voltage“. Data jsou přenášena pomocí pulsů různé délky v napěťové úrovni „high voltage“. Délka pulsu určuje význam symbolu: Symbol Symbol „0“ Symbol „1“ SOF / EOD EOF BRK IFS

Tx,nom 64 128 200 280 300 300

Rx,min > 34 > 96 > 163 > 239 > 239 > 280

Rx,max ≤ 96 ≤ 163 ≤ 239 N/A ≤ 1.0 sec N/A

Tab. 1 Časové konstanty pulsů VPW sběrnice

Z jednotlivých symbolů je sestaven rámec, který vždy povinně začíná symbolem SOF a končí EOF. Sběrnice podporuje tzv. IFS (In-Frame Response), kdy po přijetí všech dat jednoho rámce začne oslovená ECU odesílat vlastní odpověď.

- 13 -

Obecně je struktura rámce VPW následující:

Obrázek 5 Struktura rámce VPW sběrnice

Dle časů jednotlivých symbolů je rychlost komunikace cca 10 kbps. Přenášená data jsou zabezpečena pomocí CRC (Cyclic Redundancy Check) s generujícím polynomem X8 + X4 + X3 + X2 + 1.

2.1.2 Ford J1850 PWM

Společnost Ford Motor používá sběrnici J1850 PWM (Pulse Width Modulation). Ta je obdobná sběrnici J1850 VPW, ale s následujícími změnami: -

sběrnice využívá dva vodiče stav sběrnice je určen rozdílem napětí na obou vodičích fyzická vrstva je velmi podobná sběrnici EIA-485 jednotlivé pulsy mají kratší délku na přenesení symbolu je přesně stanovený čas rychlost přenosu je cca 40 kbps

- 14 -

ECU je na sběrnici připojena následujícím způsobem:

Obrázek 6 Připojení ECU na PWM sběrnici

Díky diferenčnímu signálu je sběrnice velmi odolná proti vnějšímu rušení. Další informace o fyzické vrstvě je možné nalézt v normě SAE J1850 [9]. Formát rámce je stejný jako u sběrnice J1850 VPW. Symbol Symbol "1" Symbol "0" Čas přenosu 1 bitu SOF / EOD

Tx,nom 7 15 24 48

Rx,min ≥4 ≥ 12 ≥ 21 ≥ 42

- 15 -

Rx,max ≤ 10 ≤ 18 ≤ 27 ≤ 54

EOF IFS Aktivní SOF Aktivní BRK BRK to IFS

72 96 31 39 120

≥ 63 ≥ 84 ≥ 27 ≥ 35 ≥ 105

N/A N/A ≤ 34 ≤ 43 N/A

Tab. 2 Časové konstanty pulsů PWM sběrnice

Přenášená data jsou zabezpečena pomocí CRC s generujícím polynomem X8 + X4 + X3 + X2 + 1. 2.1.4 CAN-BUS

Nejnovější a nejmodernější sběrnice využívaná v automobilové diagnostice je CAN-BUS (Controller Area Network). Jedná se o sériovou datovou sběrnice vyvinutou firmou Robert Bosch GmbH. Elektrické parametry fyzického přenosu jsou specifikované normou ISO 11898. Maximální rychlost přenosu na sběrnici je 1Mbit/sec. Síťový protokol detekuje a opravuje přenosové chyby vzniklé od okolních elektromagnetických polí. Data je možné odesílat v rámcích, každý rámec může obsahovat až 8 datových bajtů. Vysílaná data nemají žádnou adresu, obsah zprávy je dán identifikátorem (ID), který je v celé síti jedinečný. Tento identifikátor definuje obsah přenášené zprávy a zároveň i prioritu zprávy při pokusu o její odeslání na sběrnici. Vyšší prioritu mají zprávy s nižší hodnotou identifikátoru. Příjem zpráv může být mnohonásobný (jedna zpráva může být přijata několika zařízeními). Aby zpracování všech přenosových požadavků sítě CAN-BUS souhlasilo s reakční dobou omezenou nejnižší přípustnou přenosovou rychlostí, musí CAN protokol vždy umožnit připojení metodami garantujícími jednoznačný přístup na sběrnici z odlišných stanic. Metody bitové arbitráže použité k identifikaci zpráv jsou schopny jedinečně analyzovat jakékoli problémy mezi stanicemi čekajícími na přenos a přenášejícími v průběhu 13 (standardní formát) nebo 33 (přídavný formát) bitových period. Na rozdíl od standardně používané arbitráže (rozhodovací metody) pomocí CSMA/CD metod tyto nedestruktivní metody při konfliktech zajišťují, že sběrnicová kapacita nebude použita mimo přenos úplné informace.

- 16 -

2.2 Norma ISO 9141, inicializace komunikace Kromě fyzické vrstvy definuje norma ISO 9141 také to, jakým způsobem se na této sběrnici „oslovují“ ECU (vyzývají ke komunikaci). Běžnou praxí je, že na K vedení je připojeno více řídících jednotek. Diagnostický nástroj musí být schopen jednoznačně vyzvat konkrétní ECU ke komunikaci. ISO9141 pro tyto účely definuje tzv. slowinit (pomalá inicializace). Diagnostický nástroj po připojení ke K vedení vyšle na rychlosti 5 bps 7 bitovou adresu ECU ve formátu: 1 start bit, 7 datových bitů (LSB první), 1 paritní bitlichá parita, 1 stop bit. ECU musí v limitu stanoveném normou ISO9141 odpovědět vysláním synchronizačního znaku 0x55 (8bit). Tento znak slouží diagnostickému testeru na rozpoznání komunikační rychlosti, která se může pohybovat od 300 bps do 115.200 kbps. Po synchronizačním znaku je vyslán „keyword“ ve formátu dvě sedmibitová slova, nižší bajt první, lichá parita, 1 stop bit. Tento keyword slouží k rozpoznání komunikačního protokolu, případně k rozpoznání typu ECU. Z toho vyplývá požadavek na celosvětovou unikátnost keywordu. Každý keyword je registrovaný u Německé organizace FAKRA, která má pověření od ISO. Pokud je diagnostický tester po přijetí keywordu schopen dále komunikovat, vyšle jako potvrzení zpět komplement druhého bajt keywordu. Dále již následuje samotná komunikace dle příslušného protokolu. Příklad typické inicializace (ECU BMW DME 1.3, protokol RB KW 71): Tester -> ECU 10

7F

ECU -> Popis Tester 5 bps adresa ECU motoru 1start, 7data, lichá parita, 1stop 55 Synchrnonizační slovo (01010101) 1start, 8data, 1stop 01 Key word LSB 1start, 7data, lichá parita, 1stop 81 Key word MSB 1start, 7data, lichá parita, 1stop Binární doplněk Key word MSB Tab. 3 Příklad inicializace ISO9141 Slowinit

- 17 -

Některé automobilky se svojí strategií odchýlily od tohoto způsobu inicializace komunikace, např.: - Fiat nerozeznává keyword, ale tzv. ISO kód, který je tvořen ze čtyř osmibitových hodnot. - Skupina PSA (Peugeot/Citroen) a Renault u protokolu PSA2 (ISO8), resp. REN-ISO, nevyužívá potvrzení komplementem keywordu. Komunikace probíhá okamžitě po odeslání keywordu. Další rozbor problematiky je již nad rámec této práce. 2.3 Proprietární protokoly (BOSCH, Magneti-Marelli, …) První ECU na digitální řízení chodu motoru implementovaly pouze diagnostické protokoly výrobce příslušné ECU. Za „průkopníka“ v této oblasti lze považovat firmu Bosch, která implementovala protokol KW-71. Tento protokol je detailněji popsán dále v této práci. Mezi další významné protokoly patří Magneti-Marelli Free-running protocol. Výše zmíněné komunikační protokoly sloužily z počátku zejména k vnitřní diagnostice ECU. Servisní technici je nevyužívali, protože většina ECU podporovala také tzv. blikací kód (blink code). ECU po zkratování určitých vývodu v pojistkové skříňce začala blikat indikátorem poruchy motoru na přístrojové desce. Z délky pulsů a jejich počtu je možné dekódovat různé chybové stavy ECU. 2.4 Protokoly výrobce automobilu S nástupem dalších ECU (ABS, řízení převodovky, immobilizér) a jejich vývojem bylo nutné zavést komplexnější diagnostiku celého vozidla. Většina vyspělých automobilek definovala v určitém časovém období jeden nebo dva diagnostické protokoly, které využívaly všechny ECU montované do vozidla. Diagnostické funkce těchto ECU byly velmi podobné. Automobilka Volkswagen Mercedes-Benz BMW PSA Renault Opel, Vauxhall

Komunikační protokoly KW-71, KW-1281, KWP 2000, VW TP 2.0 MB-ISO, KW-FB, KWP 2000, ISO-15765 KW-71, DS-1, DS-2, KWP2000star, BMW Fast KW-71, PSA2, PSA2000 (KWP2000), ISO 15765 KW-71, REN-ISO, KWP2000, ISO 15765 KW-71,KW-81,KW-82, KWP2000, ISO 15765

Tab. 4 Příklady diagnostických protokolů jednotlivých automobilek

- 18 -

2.5 Norma OBD-II V roce 1996 v USA vyšly v platnost standardy označované souhrnně jako OBDII. Tyto normy definují požadavky na každé vyrobené vozidlo za účelem možnosti digitální diagnostiky systémů ovlivňujících emise vozidla (zejména motor a automatická převodovka). Standard SAE J1962 zavádí jednotnou 16 pinovou diagnostickou zásuvku, která musí být v každém vozidle umístěna z místa přístupného řidiči, nejdále však 50 cm od volantu. Dále standardy ISO 9141 a SAE J1850 definují povinnou fyzickou vrstvu pro komunikaci s emisními systémy. Každé vozidlo vyrobené po roce 1996 musí obsahovat alespoň jedno diagnostické vedení definované těmito standardy. V roce 2003 byly tyto normy rozšířeny o diagnostiku emisních systémů přes sběrnici CAN. Ta je definována ve standardu ISO 15765-1 a ISO 15765-4. 2.6 Protokol KWP2000

Snahou výrobců automobilů bylo po rozšíření digitální diagnostiky sjednotit komunikační protokoly. Za tímto účelem vznikl standard ISO 14230. Ten definuje fyzickou vrstvu kompatibilní s ISO 9141, redefinuje způsob inicializace komunikace (tzv. slowinit), zavádí novou metodu rychlé inicializace komunikace (tzv. fastinit), definuje formát přenášených dat a základní příkazy pro komunikaci. Protokol KWP2000 definuje tyto druhy příkazů: Příkazy na synchronizaci komunikace a nastavení parametrů Identifikační služby ECU Čtení paměti závad, mazání chyb, freeze frame Čtení měřených hodnot Spouštění testu akčních členů Spouštění doplňkových funkcí (nastavení parametrů ECU apod.) Aktualizace firmware ECU Tab. 5 Skupiny příkazů definovaných v protokolu KWP2000

Formát dat jednotlivých příkazů je ve většině případů ponechán volbě implementace. Více informací o konkrétní implementaci protokolu KWP2000 ve vozidlech skupiny Volkswagen je možné nalézt dále v této práci. - 19 -

2.7 Sběrnice CAN-BUS: ISO 15765, VW TP

S nástupem diagnostiky přes sběrnici CAN-BUS implementovaly automobilky protokoly fungující na této sběrnici. V drtivé většině případů se jedná o modifikace standardu ISO 15765-2 a ISO15765-3. V zásadě existují dva přístupy: 1. V OBD-II zásuvce je zapojena jedna nebo více sběrnic CAN. Diagnostika probíhá na předem definovaných ID spolu s normálním provozem CANu. 2. V OBD-II zásuvce je zapojena sběrnice CAN vedoucí do ECU často označované jako „centrální gateway“ nebo „CAN gateway“. Tato ECU předává diagnostické rámce na příslušné sběrnice vozidla, které nejsou přímo přístupné z OBD-II zásuvky. Tím je zvýšena bezpečnost komunikace (gateway slouží jako „firewall“ před odesláním nesmyslných dat nebo např. zkratu). Skupina Volkswagen implementovala vlastní protokol označený jako TP verze 2.0 (Transport Protocol). Tento protokol je následovníkem TP verze 1.4 a 1.6 a definuje přenos paketů protokolu KWP2000 na sběrnici CAN. V další části této práce je možné nalézt detailnější popis tohoto protokolu.

- 20 -

3. Popis diagnostiky koncernu Volkswagen Vozidla skupiny Volkswagen používají pouze několik komunikačních protokolů. Ve srovnání s ostatními automobilkami se jedná o velmi „jednotnou“ diagnostiku. V počátcích byl používán protokol BOSCH KW71 (Motor, ABS). Tento protokol byl následně automobilkou přijat jako standard na diagnostiku a rozšířen. Toto rozšíření bylo dle přiděleného keywordu označeno jako KW1281. Protokol KW-1281 je až do roku 1998 používán všemi ECU. Od roku 1998 se začíná používat protokol KWP2000. Od roku 2000 po postupném přechodu na diagnostiku přes sběrnici CAN je využit protokol VW TP 2.0 (interní protokol automobilky). Tento protokol přenáší pakety až na výjimky shodné s protokolem KWP2000. V současnosti je VW TP 2.0 používáno na všech nových modelech. Zajímavostí diagnostiky VW je strategie implementovat drtivou většinu informací o diagnostice přímo v ECU. Diagnostický tester tak nemusí mít detailní informace o každé ECU, ale musí jen interpretovat „standardizované“ formáty dat. Například při čtení měřených hodnot posílá ECU s měřenou veličinou i informaci, jak zadaný údaj interpretovat. Ostatní automobilky tuto cestu nezvolily a pro zpracování přijatých dat je nutné mít detailní informace o jejich formátu. Tato data se samozřejmě liší podle druhu ECU. Implementace diagnostického testeru se tak stává velmi netriviální záležitostí. 3.1 Diagnostické zásuvky Vozidla skupiny Volkswagen používají celkem 3 typy diagnostických zásuvek.

- 21 -

3.1.1 Konektor 2x2pin

Starší vozidla skupiny Volkswagen (do roku výroby 1995) používala tzv. 2x2 pin zásuvku. Tato zásuvka je umístěna vždy v motorovém prostoru.

Obrázek 7 Zobrazeni "2x2" diagnostické zásuvky

PIN 2 3 4 5

Využití GND VB L-Line K-Line

Popis Kostra vozidla Baterie vozidla Komunikační vedení L Komunikační vedení K Tab. 6 Zapojení „2x2“ diagnostické zásuvky

3.1.2 Konektor OBD-II (CARB)

Obrázek 8 Zobrazení OBD-II diagnostické zásuvky

- 22 -

PIN 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Využití Rezervováno SAE J1850+ Rezervováno Kostra vozidla Signálová zem CAN-H K-line Rezervováno Rezervováno SAE J1850Rezervováno Rezervováno Rezervováno CAN-L L-line VB

Popis Rezervováno SAE J1850 + (Ford PWM, GM VPW)

Referenční zem pro komunikaci High-Speed CAN-BUS signál HIGH Komunikační vedení K

Rezervováno SAE J1850 - (Ford PWM)

High-Speed CAN-BUS signál LOW Komunikační vedení L Napájecí napětí z baterie vozidla

Tab. 7 Zapojení OBD-II diagnostické zásuvky

3.1.3 Konektor VW LT

U vozidel vyrobených ve spolupráci s automobilkou Mercedes-Benz je použit tzv. VW LT konektor. Jedná se konektor se 14 piny od společnosti Tyco Electronics – Amp. Tento konektor je umístěn v prostoru pod volantem.

Obrázek 9 Zobrazení VW LT diagnostické zásuvky

- 23 -

PIN 1 2 3 14

Využití GND VB Term.30 K-Engine

Popis Kostra vozidla Napájecí napětí z baterie vozidla Napájecí napětí z baterie vozidla Komunikační vedení K – ECU Motoru Tab. 8 Zapojení VW LT diagnostické zásuvky

3.2 Popis diagnostických protokolů vozidel skupiny VW 3.2.1 Komunikační protokol KW-71

Protokol KW-71 využívá k inicializaci slowinit ve formátu, který byl popsán dříve v této práci. Komunikační rychlost je většinou 9600 bps, existují ovšem výjimky. Zabezpečení komunikace paritou u vozidel VW není využíváno. Příklad inicializace protokolu KW-71: Tester -> ECU 01

7F

ECU -> Popis Tester 5 bps adresa ECU motoru 1start, 7data, lichá parita, 1stop 55 Synchrnonizační slovo (01010101) 1start, 8data, 1stop 01 Key word LSB 1start, 7data, lichá parita, 1stop 81 Key word MSB 1start, 7data, lichá parita, 1stop Binární doplněk Key word MSB Tab. 9 Příklad inicializace protokolu RB KW 71

Komunikace probíhá v tzv. blocích, pravidelně se ve vysílání střídá tester, ECU, tester, ECU, atd.. První po slowinitu vysílá ECU. Každý blok má následující strukturu: Bajt 1. 2. 3. – n n+1

Popis Délka bloku (n) Sekvenční číslo Data bloku ETX (hodnota 0x03) Tab. 10 Struktura bloku protokolu RB KW 71

Sekvenční číslo je na začátku komunikace rovno hodnotě 0x01, u každého dalšího bloku je inkrementováno o 1. Po přetečení (0xFF) je použita hodnota 0x00.

- 24 -

Blok je vysílán tak, že vysílající strana odešle první bajt bloku a čeká na potvrzení přijímající stranou. Potvrzení je provedeno odesláním komplementu přijatého bajtu. Takto jsou odeslány postupně i ostatní bajty bloku. Poslední bajt o hodnotě 0x03 (ETX) značí konec bloku, tento již není přijímací stranou potvrzován. První bajt datové části bloku (3. bajt celkově) je identifikace požadavku, resp. odpovědi ECU. Příklad komunikace, přenesení jednoho bloku: Tester -> ECU ECU -> Tester Popis Délka bloku FC Komplement předchozího bajtu 02 Sekvenční číslo FD Komplement předchozího bajtu 09 Data bloku – požadavek 09 (ACK) F6 Komplement předchozího bajtu 03 ETX 03

Tab. 11 Příklad komunikace protokolu RB KW 71

Protokol KW-71 definuje následující příkazy (požadavky): Příkaz 00 01 02 03 04 05 06 07 08 09 0A

Popis Identifikace ECU Čtení RAM paměti Čtení ROM paměti Zápis RAM paměti Test akčních členů Smazání DTC kódů Ukončení komunikace Čtení DTC kódů Čtení jedné hodnoty ADC ACK NON-ACK Tab. 12 Příkazy protokolu RB KW 71

Pro udržení komunikace v době, kdy tester neprovádí žádnou činnost je nutné posílat ECU příkaz 09 (ACK).

- 25 -

3.2.2 Komunikační protokol KW-1281

Protokol KW-1281 je zpětně kompatibilní s Robert Bosch KW 71, definuje ovšem některé nové požadavky a mění strukturu parametrů a odpovědí požadavků použitých v KW71. Příkaz 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 10 11 12 13 18 1C 21 22 23 28 29 2B 80-9F

Popis Identifikace ECU Čtení RAM paměti Čtení ROM paměti Zápis RAM paměti Test akčních členů Smazání DTC kódů Ukončení komunikace Čtení DTC kódů Čtení jedné hodnoty ADC ACK NON-ACK Čtení adresy Čtení EEPROM Čtení chybové paměti Vymazání adaptačních hodnot Kódování ECU Základní nastavení Čtení měřených hodnot Výpočet kontrolního součtu Login request Čtení paměti RAM Čtení adaptačních hodnot Test adaptace Abgleich programm.? Vymazání základního nastavení Vymazání adaptačních hodnot Login Příkazy specifické pro výrobce ECU Tab. 13 Příkazy protokolu KW 1281

Příklad reálné komunikace s ECU (komplementy hodnot jednotlivých bajtů bloku a počáteční délky jsou vynechány pro lepší čitelnost):

- 26 -

Zdroj Data ECU 55 ECU 01 8A Tester 75 ECU 01 F6 Tester 02 09 ECU 03 F6 Tester 04 09 ECU 05 F6 Tester 06 09 ECU 07 F6 Tester 08 09 ECU 09 09 … …

DD 49 5F 49 41 4A 43 4A 45 4A 47 20 4B 4F 4D 42 49 2B 57 45 47 46 41 48 52 53 50 20 56 44 4F 20 4B 4A 4D 00 1F 40 00 00

Popis Synchr. bajt Keywords (KW1281) Komplement KW2 1. blok identifikace potvrzení 2. blok identifikace potvrzení 3. blok identifikace potvrzení 4. blok identifikace Potvrzení Potvrzení od ECU …

Tab. 14 Příklad komunikace protokolem KW-1281

3.2.3 Komunikační protokol VW KWP 2000 (ISO 14230)

Komunikace probíhá po K-Line s využitím slow-init, obdobně jako u protokolů KW-71 a KW-1281 s následujícími odlišnostmi: - komunikační rychlost je vždy definovaná jako 10400 bps - řídící jednotka musí odpovědět keywordem 2000 .. 2099 (obvykle se užívá dvojice EF 8F) - po odeslání komplementu druhého bajt keywordu čeká tester na přijetí komplementu adresy řídící jednotky. Dále již probíhá standardní komunikace KWP2000. Ta spočívá ve výměně zpráv mezi ECU a testerem formou požadavek – odpověď. Požadavky posílá pouze diagnostický tester. Zpráva má následující formát:

Obrázek 10 Formát zprávy protokolu KWP2000

Hlavička (Header) obsahuje vždy povinně bajt Fmt, který popisuje další strukturu zprávy. Pokud jsou data zprávy kratší než 63 znaků, obsahuje dolních 6 bitů délku dat zprávy, v opačném případě jsou bity nulové. Horní bit určuje, - 27 -

zda jsou ve zprávě zahrnuty informace o zdrojové a cílové adrese. Pokud je tento bit roven 1, další dva bajty obsahují adresu příjemce zprávy (adresa ECU) a adresu odesílatele (adresa testeru, obvykle 0xF1). Dále následuje bajt s délkou vlastních dat zprávy, je-li tato větší než 63 bajtů (tzn. bajt Fmt neobsahuje informaci o délce). Hlavička je následována vlastními daty, přičemž první bajt dat je definovaný jako SID (Service Identification). Za daty následuje kontrolní součet, který je tvořen jako prostý 8 bitový součet všech bajtů zprávy. Odpovědi ECU mají vždy SID nastaven na hodnotu SID požadavku + 0x40, nebo v případě chybového stavu je přítomna hodnota 0x7F. Není-li schopna ECU vrátit odpověď okamžitě, odesílá po takovou dobu neustále zprávu 0x7F s chybovým kódem 0x78. Pro udržení komunikace je požadováno, aby v okamžiku nečinnosti posílal tester periodicky požadavek testerPresent s kódem 0x3F. Protokol KWP2000 definuje následující příkazy: Příkaz 81* 82* 83* 3E* 10* 20 27* 11 1A* 21* 22 23 2C 3B* 2E 3D 26 25 13*

Význam startCommunication stopCommunication (ukončení komunikace) accessTimingParameters testerPresent startDiagnosticSession stopDiagnosticSession securityAccess ecuReset readEcuIdentification (čtení identifikace ECU) readDataByLocalIdentifier (čtení měřených hodnot) readDataByCommonIdentifier readMemoryByAddress dynamicallyDefineLocalIdentifier writeDataByLocalIdentifier writeDataByCommonIdentifier writeMemoryByAddress setDataRates stopRepeatedDataTransmission readDiagnosticTroubleCodes (čtení chybových kódů)

- 28 -

18 17 12* 14* 30* 2F 31* 38 32* 39 33 3A* 34

readDiagnosticTroubleCodesByStatus readStatusOfDiagnosticTroubleCodes readFreezeFrameData clearDiagnosticInformation (vymazání chybových kódů) inputOutputControlByLocalIdentifier inputOutputControlByCommonIdentifier startRoutineByLocalIdentifier startRoutineByAddress stopRoutineByLocalIdentifier stopRoutineByAddress requestRoutineResultsByLocalIdentifier requestRoutineResultsByAddress requestDownload Tab. 15 Příkazy definované v protokolu KWP2000

Diagnostika vozidel Volkswagen ovšem používá pro standardní operace pouze omezenou množinu příkazů. Ve výše uvedené tabulce jsou vyznačeny hvězdičkou u čísla příkazu. V následující tabulce je příklad komunikace s řídící jednotkou motoru implementující KWP 2000 s inicializací formou slow-init. Tester->ECU

ECU->Tester

Popis Adresa ECU Synchronizační bajt Keyword I Keyword II Komplement Keywordu II

10 55 EF 8F 70 FE 82 10 F1 10 89 1C 83 F1 10 7F 10 12 25 82 10 F1 10 81 14 82 F1 10 50 85 58 …

Požadavek testeru (příkaz 10 89) Negativní odpověď ECU Požadavek testeru (příkaz 10 81) Pozitivní odpověď (50 85) …

Tab. 16 Příklad komunikace protokolu KWP2000 (Motor, EDC 16)

Více informací o protokolu KWP2000 lze nalézt ve standardu ISO 14320 [4].

3.2.4 Komunikační protokoly VW TP 1.4 & 1.6

- 29 -

Komunikační protokol VW TP 1.6 je použit pouze pro účely komunikace mezi řídícími jednotkami ve vozidle (K<->CAN gateway vs. řídící jednotka). Diagnostický tester s tímto protokolem nemusí vůbec pracovat, protože K<>CAN gateway převádí všechny požadavky mezi K-Line (KW-1281) a sběrnicí CAN-BUS (VW TP 1.6). Protokol VW TP 1.6 je velmi podobný VW TP 2.0, který je popsán v následujícím oddílu, s těmito odlišnostmi: - inicializace komunikace je zjednodušena - protokol zapouzdřuje přímo data posílaná po K-Line, v praxi jen protokol KW-1281 - v případě tzv. idle módu jsou odesílány příkazy KW-1281 jako standardní komunikace - protokol neobsahuje některé stavy - protokol nepoužívá některé příkazy - hodnoty časování jsou nastaveny „napevno“ v kódu ECU 3.2.5 Komunikační protokol VW TP 2.0

Komunikace protokolu VW TP 2.0 probíhá po high-speed sběrnici CAN (např. s budičem PCA82C250) na rychlosti 0.5 Mbps s použitím 11 bitových identifikátorů. Protokol VW TP 2.0 přenáší požadavky shodné s protokolem KWP2000, jedná se tedy pouze o transportní vrstvu. Při zahájení komunikace diagnostický tester vyšle CAN frame „initconn“ s ID 0x200 s následujícím formátem: Data CAN ID 1. 2. 3. 4. 5. 6. 7.

Položka ID DEST OPCODE TX ID Low TX ID High RX ID Low RX ID High ConnType

Popis Identifikátor rámce: hodnota 0x200 nebo 0x2xx Adresa ECU 0xC0 – požadavek testeru, 0xD0 – odpověď ECU CAN ID pro odesílání testerem CAN ID pro odesílání testerem CAN ID pro příjem dat testerem CAN ID pro příjem dat testerem Typ spojení

Tab. 17 Formát inicializačního rámce protokolu VW TP 2.0

Tester nevyplňuje položky TX ID, pouze RX ID. Do těchto položek je dosazena hodnota identifikátoru, na kterém bude v průběhu další komunikace tester odesílat data. Používají se pouze hodnoty 0x300 – 0x310.

- 30 -

Je-li vyzvaná ECU v systému přítomna, odpoví s ID 0x200+ rámcem se stejným formátem, ale vyplněnými hodnotami identifikátoru TX ID. Po přijetí tohoto rámce probíhá veškerá komunikace s novými identifikátory, které si vyměnil tester s ECU. Rámce vlastní komunikace mají tento formát: Zkratka

Typ rámce

DT AK CS CA GS CT BR DC

7.bit 6.bit Data 0 0 Acknowledge 1 0 ConnSetup 1 0 ConnAck 1 0 Get Send 1 0 ConnTest 1 0 Break 1 0 Disconnect 1 0

1. bajt CAN rámce 5.bit 4.bit 3.bit 2.bit 1.bit 0.bit AR EOM SN RS 1 SN 1 0 0 0 0 0 1 0 0 0 0 1 1 0 0 0 1 0 1 0 0 0 1 1 1 0 0 1 0 0 1 0 1 0 0 0

Tab. 18 Formát rámců protokolu VW TP 2.0

Význam jednotlivých bitů nebo jejich skupin je následující: AR - Acknowledge Request EOM - konec zprávy RS - Receive status SN - sekvenční číslo, obdobně jako u KW 71 inkrementováno První požadavek testeru by měl být ConnSetup - CS, při kterém se s ECU „dohodne“ na časování. V případě, že neprobíhá žádna aktivní komunikace, musí tester pravidelně posílat požadavek ConnTest – CT. Výměna diagnostických požadavků je realizována rámcem Data – DT. Odesílající strana může v kterémkoliv rámci nastavit požadavek na potvrzení příjemcem, v takovém případě je před odesláním dalšího rámce požadováno potvrzení rámcem Acknowledge – AK. První datový rámec obsahuje ve druhém bajtu celkovou délku požadavku, následující datové rámce tuto informaci nenesou. Délka je následována daty diagnostického požadavku. Je-li požadavek delší než 6 bajtů, jsou odeslány další datové rámce vždy s vyšším sekvenčním číslem až do úplného odeslání dat.

- 31 -

Komunikace je ukončena požadavkem Disconnect – DC. Tento požadavek je potvrzen zpět shodným typem rámce. Příklad komunikace s ECU – čtení identifikace a ukončení komunikace: Zdroj ID Tester 0200 ECU 021F Tester 032E ECU 032E Tester 032E ECU 032E ECU 032E Tester 032E Tester 032E ECU 032E ECU 032E ECU 032E ECU 032E ECU 032E ECU 032E ECU 032E ECU 032E ECU 032E Tester 032E Tester 032E ECU 032E

Data 1F C0 00 10 00 03 01 00 D0 00 03 2E 03 01 A0 0F 8A FF 32 FF A1 0F 8A FF 4A FF 10 00 02 10 89 B1 10 00 02 50 89 B1 11 00 02 1A 9B B2 21 00 30 5A 9B 31 4B 30 22 39 30 37 35 33 30 43 23 20 20 30 30 38 30 10 24 00 00 00 00 06 46 22 25 05 70 47 61 74 65 77 26 61 79 20 20 20 20 20 27 20 20 20 20 48 30 38 18 20 B9 A8 A8

Popis Výzva na ECU Odpověď ECU ConnSetup ConnAck Data Acknowledge Data Acknowledge Data Acknowledge Data Data Data Data Data Data Data Data Acknowledge Disconnect Potvrzení Disconnect

Tab. 19 Příklad komunikace VW TP 2.0

3.2.6 Komunikační protokol normy OBD-II – ISO9141

Pro účely diagnostiky emisních systémů je použit protokol definovaný normou ISO9141, OBD-II. Vzhledem k tomu, že tento protokol obsahuje funkčně pouze podmnožinu diagnostiky protokolů KW-71, KW-1281, KWP 2000 a VW TP 2.0, jeho implementací se v testeru nezabývám. Následující informace o emisní diagnostice jsou uvedeny jen pro úplnost. Inicializace probíhá formou slowinitu s použitím adresy 0x33, zcela identicky jako u protokolu KWP2000. Vlastní datová komunikace je obdobná jako u protokolu KWP 2000. Formát požadavků je stejný. Odlišností je, že na požadavek může odpovědět více ECU

- 32 -

(např. motor, následovaný automatickou převodovkou). Pokud pošleme neznámý požadavek, žádná ECU neposílá zpět odpověď. Při implementaci protokolu je vhodné čekat na odpovědi do uplynutí určité doby. Nepřijme-li tester žádnou odpověď, jedná se o chybový stav. Přijme-li více odpovědí, jsou adresou odesílatele rozlišeny dle druhu ECU. Pro udržení komunikace v době nečinnosti je možné posílat libovolný požadavek, na který nám odpoví alespoň jedna ECU. Dle standardu ISO9141 se používá pro příkaz/požadavek termín „Mód“. V následující tabulce jsou popsány všechny základní módy emisní diagnostiky: Mód 01 02 03 04 05 06 07 08 09

Popis Podporované módy a PIDy, informace o systému Freeze frame Čtení chybových kódu (statické chyby) Vymazání diagnostických informací Test lambda sond Výsledky nekontinuálně monitorovaných parametrů Výsledky kontinuálně monitorovaných parametrů Test akčních členů Informace o vozidle Tab. 20 Módy emisní diagnostiky

Příklad komunikace OBD-II ISO9141: Zdroj ECU ECU Tester ECU Tester ECU Tester ECU Tester ECU

Data 55 08 08 F7 CC 68 6A F1 01 00 C4 48 6B 10 41 00 BE 1F E8 11 DA 68 6A F1 01 20 E4 48 6B 10 41 20 90 00 00 00 B4 68 6A F1 01 01 C5 48 6B 10 41 01 00 07 ED ED E6

Popis Synchronizační bajt Keyword Komplement KW 2 Potvrzení Adresy Požadavek 01 00 Odpověď Požadavek 01 20 Odpověď Požadavek 01 01 Odpověď

Tab. 21 Příklad komunikace OBD-II ISO9141

3.2.7 Komunikační protokol normy OBD-II – ISO 14230-4

- 33 -

Další používaný protokol na emisní diagnostiku vychází opět z KWP 2000. Proti ISO9141-4 používá jiný formát hlaviček a implementuje další příkazy (např. testerPresent). Jednotlivé módy jsou shodné s ISO9141. Detailnější popis je nad rámec této práce, avšak uvádím alespoň příklad komunikace: Zdroj ECU ECU Tester ECU Tester ECU Tester ECU Tester ECU

Data 55 E9 8F 70 CC C1 33 F1 3E 23 81 F1 10 7E 00 C2 33 F1 01 00 E7 86 F1 10 41 00 98 3B 80 11 2C C2 33 F1 01 20 07 86 F1 10 41 20 80 00 00 01 69

Popis Synchronizační bajt Keyword Komplement KW 2 Potvrzení Adresy Požadavek 3E Odpověď Požadavek 01 00 Odpověď Požadavek 01 20 Odpověď

Tab. 22 Příklad komunikace OBD-II ISO 14320

3.2.8 Komunikační protokol normy OBD2 via CAN (ISO 15765-4)

Pro emisní diagnostiku s použitím sběrnice CAN-BUS definuje standard ISO 15765-4 další komunikační protokol. Komunikace probíhá po high-speed sběrnici CAN (např. s budičem PCA82C250) na rychlosti 0.5 Mbps s použitím 11 bitových identifikátorů. Tester odesílá data s ID 0x7DF, ECU odpovídají s ID 0x7E8 až 0x7EF. Na řízení toku dat se používá ID 0x7E0. Každý rámec obsahuje v prvním bajtu informaci o jeho typu a případně délku dat, které následují. Detailní popis je možné najít v [2]. Jednotlivé módy a formát dat jsou shodné s protokolem ISO9141-4. Synchronizace u tohoto protokolu neexistuje, ECU odesílají odpovědi v libovolném pořadí. Tester musí být schopen všechny přijaté rámce přiřadit konkrétním ECU. Detailnější popis je nad rámec této práce, avšak uvádím alespoň příklad komunikace: Zdroj Tester ECU-Motor ECU-Převodovka

ID Data 7df 02 01 7e8 06 41 7e9 06 41

00 00 00 00 00 00 00 be 1f e8 13 00 00 98 1c 80 10 00

- 34 -

Popis Požadavek Odpověď #1 Odpověď #2

Tester ECU-Motor ECU-Převodovka Tester ECU-Motor ECU-Převodovka Tester ECU-Motor ECU-Převodovka Tester ECU-Motor Tester ECU-Motor ECU-Převodovka

7df 7e8 7e9 7df 7e8 7e9 7df 7e8 7e9 7e0 7e8 7df 7e8 7e9

02 01 00 00 00 00 00 00 06 41 00 be 1f e8 13 00 06 41 00 98 1c 80 10 00 02 01 01 00 00 00 00 00 06 41 01 84 07 6d 00 00 06 41 01 81 04 00 00 00 01 03 00 00 00 00 00 00 10 0a 43 04 c0 73 04 20 04 43 01 c1 00 00 00 00 30 00 00 00 00 00 00 00 21 c1 01 c1 55 00 00 00 02 01 01 00 00 00 00 00 06 41 01 84 07 6d 00 00 06 41 01 81 04 00 00 00

Požadavek Odpověď #1 Odpověď #2 Požadavek Odpověď #1 Odpověď #2 Požadavek Odpověď #1 Odpověď #2 Řízení toku Odpověď #1 – pokrač. Požadavek Odpověď #1 Odpověď #2

Tab. 23 Ukázka komunikace ISO 15765-4

- 35 -

4 Implementace testeru Před vlastním návrhem řešení a jeho implementací jsem shrnul požadavky na hardware i software a následně zvolil nejvhodnější postup. Implementace komunikačních protokolů může používat stavový automat, v takovém případě není nutné mít v testeru přepínač úloh (task switcher). Tato varianta je náročnější na hledání chyb a případné úpravy kódu po jeho odladění. Druhou možností je kód implementovat pomocí funkcí, které jsou volány v multi-threadovém prostředí pomocí meziprocesové komunikace (IPC, Inter process communication). Tato varianta vyžaduje vhodný přepínač úloh s velmi nízkou latencí při přepnutí úlohy nebo vyvolání IPC. Její obrovskou výhodou je velmi přehledný kód, který je možné snadno udržovat. Nevýhodou je nutnost použít dostatečně výkonný jednočipový mikropočítač. V tomto projektu jsem se rozhodl vzhledem k dostupnosti velmi levných a výkonných mikroprocesorů pro druhou variantu. 4.1 Hardwarové požadavky Tester musí filtrovat napájecí napětí, nízké a vysoké napětí na sběrnici ISO9141 a CAN-BUS. K vedení musí splňovat požadavky normy ISO9141, musí být odolné proti zkratu na kostru, připojení záporného napětí, zkratu na baterii vozidla, a připojení vyššího napětí než je napájecí napětí. Firmware musí podporovat detekci baudrate při komunikaci s řídící jednotkou v rozmezí 300 bps – 115 200 bps. Rozhraní High-Speed CAN-BUS musí splňovat požadavky normy ISO 11898, přijmout nesprávný signál na CANH/CANL. V době nečinnosti musí být sběrnice CAN-BUS pomocí relé odpojena od vozidla. Display i klávesnice musí fungovat v teplotních rozmezích od –10 ‘C do +60 ‘C. 4.2 Softwarové požadavky Výkon zvoleného jednočipového mikroprocesoru musí být dostatečný pro běh přepínače úloh.

- 36 -

Flash paměť mikroprocesoru musí být dostatečně velká na uložení nekomprimovaného kódu a datových tabulek v komprimované podobě (chybové kódy, hlášení, apod.). Paměť RAM mikroprocesoru musí být dostatečná na uložení aktuálně zpracovávaného požadavku, provoz přepínače úloh a dekompresi dat uložených ve flash paměti. Přepínač úloh musí zajistit přepnutí na komunikační vlákno v případě přijetí dat nebo uplynutí stanovené doby ve velmi krátkém časovém úseku (max. 1ms). Přepínač úloh musí podporovat události, nebo jinou formu meziprocesové komunikace. Dále musí implementovat vhodný plánovač úloh s možností nastavení priorit pro jednotlivá vlákna. Rovněž musí být zaručena podpora přepnutí úlohy z obsluhy přerušení.

- 37 -

4.3 Návrh hardware Základní blokové schéma navrženého hardware vypadá takto: Napájecí obvody Rozhraní K-Line (ISO9141)

Rozhraní CAN-BUS

Měření napětí K-Line & Bat

MCU ARM7 TDMI AT91SAM7A3-EU

Grafický display PG 12864

Cryptochip

Maticová klávesnice

Obrázek 11 Blokové schéma testeru

4.3.1 Mechanické prvky

Tester je umístěn v krabičce společnosti BOPLA (www.bopla.de) s označením BOS-900 v barvě černé. Tato krabička splňuje všechny mechanické předpoklady pro použití v prašném a znečištěném prostředí. Navíc je již od výrobce připraven na osazení standardizované klávesnice a displaye. Jako zobrazovací jednotka je použit grafický display od firmy Powertip PG 12864-I-KN s řadičem KS0107 a KS0108. Více informací viz [12]. Klávesnice je použita od firmy Tesla Jihlava a.s. Tato klávesnice funguje na principu spínání kontaktů v matici. Grafický návrh klávesnice je v příloze na CD-ROM.

- 38 -

Konektor na připojení testeru k vozidlu (OBD2, CARB) je připojen pevně k testeru pomocí osmižilového kabelu. Připojení k ostatním konektorům používaným ve starších typech vozidel je řešeno pomocí redukce konektorOBD2. 4.3.2 Napájení

Tester je díky malému odběru napájen přímo z vozidla. Vnitřní napájení testeru je realizováno step-down měničem LM 2575T na úroveň 5V (napájení displaye, CAN transceiveru) a poté pomocí LM317 na 3.3V (napájení procesoru). Dále je použito napájeni 1.8V pro jádro procesoru. Toto napétí je generováno interním stabilizátorem v procesoru z 3.3V Tester je automaticky zapnut po připojení k vozidlu, funkce power-on/off není řešena. Display je za vždy podsvícen. 4.3.3 Mikroprocesor

Veškeré softwareové funkce jsou implementovány v mikroprocesoru Atmel AT91SAM7A3, což je ARM7TDMI procesor s 256 kB FLASH paměti, 64kB SRAM,. Více informací o tomto procesoru lze nalézt v [7]. Tento mikroprocesor obsahuje mnoho periferií, pro tento projekt jsou důležité zejména: -

ARM7 TDMI jádro s výkonem 60 MIPS 256 kB FLASH paměti 32 kB SRAM paměti Resetovací obvod Generátor hodinového signálu (s PLL) Řadič přerušení Řadič sběrnice CAN A/D převodník USART Periodický časovač IO porty s podporou 5V TTL logiky

- 39 -

Obrázek 12 Blokové schéma MCU AT91SAM7A3

- 40 -

Na desce je vyveden programovací a testovací JTAG konektor. Rozhraní JTAG je použito pouze při prvotním programování testeru. Na další aktualizace se využívá bootloader implementovaný v prvním sektoru flash paměti v procesoru, který komunikuje po K vedení s aktualizační utilitou.

Popis VREF – napětí 3.3V nTRST – TRST signál JTAG TDI – JTAG Test Data IN TMS – JTAG Test Mode Sel. TCK – JTAG Clock RTCK – JTAG Clock return TDO – JTAG Test Data OUT nRST – MCU Reset# POWER – 5V napájení

Pin 1 3 5 7 9 11 13 15 17 19

Pin 2 4 6 8 10 12 14 16 18 20

Popis VTARGET – napětí 3.3V GND GND GND GND GND GND GND GND GND

Tab. 24 Zapojení JTAG IEEE 1149.1 konektoru pro ARM7

4.3.4 Display, klávesnice

Procesor je pomocí IO pinů připojen přímo ke grafickému displeji i klávesnici. Zapojení konektoru displaye je následující: Pin 1 2 3 4 5 6 7-14 15 16 17 18

Signál VSS VDD Vo RS R/W# E DB0-DB7 CS1 CS2 RST# VOUT

Popis Power supply (GND) Power supply (+ 5V) Contrast adjust Command / Data select Data read / write Chip enable Data bus line Chip select 1 Chip select 2 Reset Negative voltage output Tab. 25 Zapojení konektoru displaye PG 12864

Zvolený procesor umožňuje připojit 5Volt TTL logiku bez oddělovače (IO porty jsou 5V TTL kompatibilní). - 41 -

4.3.5 Rozhraní K-Line: ISO 9141

Rozhraní ISO 9141 je připojeno přímo k modulu mikroprocesoru UART0 na piny TX a RX. Zjednodušené elektrické schéma vypadá takto:

Obrázek 13 Schéma zapojení rozhraní ISO 9141

Zvolený návrh nesplňuje zcela požadavky standardu ISO 9141, protože nedetekuje zkrat sběrnice na kostru vozidla ani baterii. Navíc při zkratu na baterii dojde k poškození koncového tranzistoru. Proto jsem doplnil návrh o další obvod, který měří před vlastní diagnostikou napětí na K-Line a umožní pomocí tranzistoru sepnout K-Line na úroveň ½ napětí baterie pomocí odporu. Tím nedojde k poškození žádné ze součástek, ale přitom je možné detekovat softwarově některou z poruch na vozidle. Uživatel je přitom informován a diagnostika není dále povolena.

- 42 -

Zvolený způsob řešení není opět ideální, protože dojde-li v průběhu komunikace ke zkratu, nebude detekován. Tento stav by šel řešit jedině pomocí několika operačních zesilovačů nebo využitím specializovaného obvodu např. od společnosti Vishay. Po úvaze o velmi malé pravděpodobnosti takového stavu a analýze zapojení rozhraní ISO9141 některých řídících jednotek jsem dospěl k závěru, že tento „nedostatek“ je při reálném použití testeru zanedbatelný. Mnoho ECU trpí obdobným problémem, navíc starší revize originálního testeru VAG1552 mají toto rozhraní vyřešeno se stejným nedostatkem. 4.3.6 Rozhraní CAN-BUS (High-speed)

Fyzická vrstva sběrnice CAN-BUS je implementována pomocí obvodu Philips PCA 82C250, který splňuje veškeré požadavky normy ISO 11989. Tento obvod je připojen přímo k procesoru Atmel na I/O piny CAN modulu. Sběrnice je v testeru terminována odporem 120 Ω dle doporučení ISO 11898, více informací viz [10].

- 43 -

4.4 Návrh software Firmware testeru je napsán v jazyce C s použitím překladače GNU CC a binutils pro platformu ARM7. Veškerý kód je překládán pod OS UNIX pomocí programu GNU make. Funkce na nejnižší úrovni (inicializace mikroprocesoru, přepínání úloh, prvotní zpracování přerušení) jsou implementovány v assembleru. Při běhu testeru jsou využity následující vlákna: - main o hlavní vlákno, které řídí činnost testeru, - CommTask o implementuje komunikační protokoly, má nejvyšší prioritu, - CommIdleTask o implementuje odesílání požadavků na udržení komunikace s ECU v okamžiku, kdy hlavní vlákno zpracovává požadavky uživatelského rozhraní, - KeyboardTask o vlákno na obsluhu klávesnice. Přepínač úloh navíc definuje systémové vlákno „idle“, které má nejnižší prioritu a provádí činnost pouze v okamžiku, kdy jsou všechna ostatní vlákna zablokovaná. 4.4.1 Implementace přepínače úloh

Pro tento projekt jsem implementoval jednoduchý přepínač úloh. Koncepce je inspirovaná standardem OSEX/VDX. Více informací viz [13]. Přepínač podporuje: -

plánování úloh metodou round-robin s využitím priorit, alarmy aktivované časovačem, meziprocesovou komunikaci formou událostí (eventů), volání funkcí z obsluhy přerušení.

Informace o každém vlákně jsou uloženy ve struktuře „taskstruct“, která má následující položky: - registers – uložené registry procesoru,

- 44 -

-

cpsr –registr CPSR, stack – ukazatel na zásobník threadu, stacksize – velikost zásobníku, eventmask – bitová maska událostí, na které vlákno čeká, events – aktuální stav událostí, priority – priorita vlákna, state – stav vlákna (RUNNING, READY, WAITING, SUSPEND), qnext, qprev – systémové ukazatele na další vlákno ve frontě.

Přepínač úloh obsahuje tyto základní funkce: Funkce CreateAlarm CancelAlarm SetRelAlarm SetEvent SetEventIRQ WaitEvent GetEvent ClearEvent TickCount CreateTask InitializeOS

Popis Vytvoření alarmu Předčasné zrušení alarmu Nastavení rel. Času alarmu Odeslání události vláknu Odeslání události vláknu z obsluhy přerušení Zastavení vlákna do doby příjmu událost Zjištění aktuálního stavu událostí Vymazání aktivní události Zjištění počtu „ticků“ od startu přepínače úloh Vytvoření vlákna Inicializace přepínače úloh – start plánovače Tab. 26 Funkce přepínače úloh

4.4.2 Implementace systému uživatelského rozhraní

Tester využívá proporcionální font s výškou 8 bodů pro zobrazení všech textů na grafickém displeji. Pro zobrazení měřených hodnot je k dispozici omezená znaková sada fontu s výškou 16 bodů pro lepší čitelnost. Na vytvoření tabulek s definicí jednotlivých znaků byla napsána aplikace, která konvertuje font z Windows True Type do bitmapy a uloží jej přímo ve struktuře používané programem. Vlákno na obsluhu klávesnice periodicky provádí „scanování“ matice a zjišťuje, zda byla stisknuta klávesa. Pokud je tento stav detekován, kód klávesy je přidán do kruhového zásobníku a hlavnímu vláknu je zaslána zpráva. Uživatelské rozhraní uživatelského rozhraní:

pracuje

s několika

- 45 -

základními

typy

„objektů“

- Obecná obrazovka, do které je možné vykreslit libovolné informace (např. zobrazení měřených hodnot). - Zobrazení obrázku 128x64 bodů (např. úvodní obrazovka). - Zobrazení a práce s menu, které je definované jednotlivými položkami - Zobrazení chybové zprávy (obdoba Win32 API funkce MessageBox) - Zobrazení dialogu s uživatelským vstupem (např. zadání pin kódu). - Zobrazení chybových kódů a jejich procházení. 4.4.3 Implementace komunikačního vlákna

Komunikační vlákno zpracovává pouze požadavky, které přijme od jiných vláken, samo aktivně neprovádí žádné operace. Nenese ani informaci o aktuálním stavu komunikace. Základními operacemi komunikačního vlákna jsou: -

Inicializace protokolu (slowinit, CAN-BUS init, …) Odeslání požadavku Čekání na odpověď Ukončení komunikace

O udržování komunikace při nečinnosti se stará samostatné vlákno. Veškerá komunikace mezi vlákny probíhá pomocí událostí a sdílené paměti. Dojde-li k přerušení komunikace, komunikační vlákno odešle hlavnímu vláknu událost. Hlavní vlákno přeruší prováděnou činnost a informuje uživatele. Pro ilustraci zvolené metody uvádím postup vyčtení identifikace ECU: -

Požadavek na zastavení udržovacího vlákna Čekání na zastavení udržovacího vlákna Sestavení požadavku do zásobníku Odeslání požadavku Čekání na odpověď Požadavek na spuštění vlákna udržujícího komunikaci Zobrazení identifikace na displeji Čekání na událost uživatelského rozhraní (stisk klávesy)

4.4.4 Inicializace K vedení, detekce komunikační rychlosti

Před komunikací přes ISO9141 sběrnici je změřeno napětí na K vedení. Pokud není detekován zkrat na kostru, ale napětí od výše 80% napětí baterie, je K vedení přepnuto na poloviční napětí baterie. Opět je provedeno měření. Příliš

- 46 -

vysoká hodnota detekuje zkrat na vedení na kladný pól baterie. Na závěr je na K vedení vytvořen krátký puls sepnutím na úroveň země a napětí je opět změřeno. V případě úspěšných testů je komunikace povolena. Měření komunikační rychlosti probíhá před aktivací modulu USART0. V tomto stavu je pin RX brán jako obecný vstup. Při detekci sestupné hrany na vstupu RX (start bit) je vynulován časovač, který měří délku jednotlivých bitů přijatého synchronizačního slova. Po přijetí všech osmi bitů je spočítána průměrná délka a po úpravě hodnoty je výsledek použit pro generátor hodin modulu USART0. Ten je následně aktivován a čeká na příjem keywordů. 4.4.8 Doplňkové funkce

V testeru jsou navíc implementovány funkce vnitřní diagnostiky, test klávesnice a displeje, bootloader pro aktualizaci firmware přes rozhraní ISO9141, a podobně.

- 47 -

5 Řešení problémů s časováním, odchylky proti normám Při implementaci a testování tohoto projektu jsem narazil na mnoho problémů. Mezi nejzávažnější řadím zvolení vhodného časování u komunikačních protokolů a nestandardní nebo neočekávané odpovědi některých ECU na požadavky. 5.1 Časování komunikace – timing Každý komunikační protokol vyžaduje pro stabilní komunikaci přesné časování. Při testování byl firmware doplněn o funkce, které umožňují snadno změnit jednotlivé hodnoty timeoutů a čekání. S takto upraveným testerem bylo provedeno měření dolních a horních mezních hodnot jednotlivých parametrů pro různé ECU. Ve finálním programu jsou použity střední hodnoty maxima minimálních hodnot a minima maximálních hodnot. Měřeny byly tyto parametry: -

Čekání před navázáním komunikace [min]. Timeout odezvy ECU (synchronizační slovo) [min]. Čekání před odesláním komplementu KW2 [min, max]. Čekání mezi jednotlivými bloky [min, max]. Čekání mezi vysílanými znaky [min, max]. Timeout pro příjem odpovědi ECU – blok [min]. Timeout pro příjem dalšího znaku/rámce [min].

5.2 Odchylky proti zvyklostem a normám Některé typy ECU vrací nestandardní odpovědi proti definici ve standardech, nebo reagují neočekávaně. Pro ilustraci uvádím několik takových projevů: - Panel přístrojů Motometer – VW Punto 1998 používá nestandardní keyword, očekává začátek komunikace s nestandardní paritou. - BOSCH EDC16 vrací některé měřené hodnoty v nestandardním formátu, který je ale možné rozpoznat. - Není-li podporována funkce „čtení jednotlivé hodnoty“, některé ECU odpovídají proti očekávání nesmyslnými daty. - Při provádění některých operací (zejména adaptace) dochází k velmi dlouhým časovým prodlevám před odesláním odpovědi. Případy, které je možno detekovat, byly softwarově ošetřeny. - 48 -

6 Závěr V průběhu přípravy k práci jsem se seznámil s diagnostikou automobilových systémů obecně, a následně jsem se zaměřil na diagnostiku vozidel koncernu VW. Provedl jsem důkladnou analýzu všech protokolů, zdokumentoval jednotlivé příkazy a možné odpovědi od mnoha desítek ECU. Z výsledků přípravy jsem navrhnul vhodný hardware, na kterém jsem implementoval všechny diagnostické protokoly používané v koncernu Volkswagen. Využil jsem při práci vlastní jednoduchý plánovač úloh v reálném čase, který umožnil implementovat všechny komunikační procedury bez využití stavového automatu. Na vytvořené komunikační knihovně jsem postavil kompletní diagnostický tester, který implementuje naprostou většinu funkcí originálního diagnostického nástroje koncernu Volkswagen – VAG 1552, včetně některých funkcí jeho nástupce VAS 5051 a VAS 5052. Vytvořený diagnostický nástroj byl otestován na cca 50 vozidlech různých modelových řad i automobilek. Při testování byla provedena korekce parametrů časování komunikace, čímž bylo dosaženo obdobné spolehlivosti komunikace jako u originální koncernové diagnostiky. Příklady testovaných vozidel: Volkswagen Passat B5 1999 Passat B5 2002 Passat B6 2005 Golf IV 1999 Golf V 2004 Bora 1999 Touareg 2003 Touran 2004

Audi A2 2003 A3 2000 A4 2001 A4 2002 S4 1999 A6 1999 A6 2001 A8 2002 A8 1999

Škoda Favorit SPI Felcia 1996 Felicia 1998 Fabia 2000 Fabia 2002 Fabia 2005 Octavia 1997 Octavia 1999 Octavia II (A5) 2004 Superb 2001

Tab. 27 Příklad testovaných vozidel

- 49 -

Seat Ibiza 2001 Toledo 2000 Cordoba 1999 Leon 2000

Výsledek mé práce zcela splnil zadání. Vytvořený tester je možné použít na plnohodnotnou diagnostiku vozidel koncernu Volkswagen. Jeho hlavními výhodami proti originální diagnostice jsou: 1. 2. 3. 4.

nízká cena snadná dostupnost snadná obsluha (ve srovnání s VAG 1552) nízká hmotnost, snadná manipulovatelnost (ve srovnání s VAS 5051).

- 50 -

8 Seznam odborné literatury [1] CAN Specification v. 2.0, Robert Bosch, 1991 [2] Specifikace protokolu ISO 15765, ISO 15765, International Organization for Standardization, 2000 [3] Specifikace protokolu KW-71, Robert Bosch, 1988 [4] Specifikace protokolu KWP2000, ISO 14320, International Organization for Standardization, 1999 [5] Specifikace protokolu ISO 9141, International Organization for Standardization, 1989 [6] ARM7TDMI TRM, ARM Ltd., www.arm.com, 2005 [7] Atmel AT91SAM7A3 datasheet, Atmel Inc, www.atmel.com, 2005 [8] Datasheet 82C250, Philip Inc., 1998 [9] Standard SAE J1850, The Engineering Society For Advancing Mobility Land Sea Air and Space, 1988 [10] Specifikace sběrnice CAN-BUS, ISO 11898, International Organization for Standardization, 1993 [11] www.wikipedia.org [12] www.powertip.com.tw [13] OSEK OS Specification, Version 2.2.3, OSEK VDX Organisation, 2003

- 51 -

9 Přílohy Na přiloženém CD-ROM jsou obsaženy: -

zdrojové kódy schéma plošného spoje osazovací výkres grafický návrh klávesnice

- 52 -

-

9.1 Schéma testeru

Obrázek 14 Schéma testeru

- 53 -

9.2 Osazovací výkres plošného spoje

Obrázek 15 Osazovací výkres plošného spoje

- 54 -

9.3 Osazený plošný spoj

Obrázek 16 Osazený plošný spoj testeru

- 55 -

9.4 Zkompletovaný tester

Obrázek 17 Zkompletovaný ruční tester

- 56 -