České vysoké učení technické v Praze Fakulta elektrotechnická
Bakalářská práce
Diagnostika elektronických řídicích jednotek Jan Kravar
Vedoucí práce: Ing. Jiří Novák, PhD.
Studijní program: Elektronika a informatika strukturovaný bakalářský Obor: Výpočetní technika červen 2006
ii
Poděkování: Tímto bych chtěl poděkovat vedoucímu mé bakalářské práce Ing. Jiřímu Novákovi, PhD. za trpělivou spolupráci při jejím řešení. iii
iv
Prohlášení: Prohlašuji, že jsem svou bakalářskou práci vypracoval samostatně a použil jsem pouze podklady 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).
V Praze dne 30. 6. 2006
.............................................................................................. v
vi
Anotace Předmětem této práce je vytvoření knihovních modulů, které umožní přistupovat k diagnostickým funkcím vozidlových řídicích jednotek prostřednictvím sběrnice CAN, která se jeví s ohledem na budoucnost jako nejperspektivnější. Pomocí vytvořených modulů bude možné jednoduše naprogramovat libovolnou aplikaci na diagnostiku řídicích jednotek. Cílem práce není naimplementovat všechny diagnostické funkce, nýbrž přehledně implementovat jednotlivé komunikační vrstvy. V první fázi bylo nutné zmapovat příslušné protokoly a standardy a vybrat ty, které budu moci implementovat. V druhé fázi práce se zabývám rozborem těchto protokolů, a to zejména principem komunikace, tak abych mohl po té protokoly implementovat. Implementace byla ověřena v uživatelském režimu operačního systému Windows, z čehož vyplývají určitá omezení. V práci bych rád pokračoval v rámci diplomové práce během dalšího studia, kdy plánuji přesunout moduly přímo do ovladače jádra operačního systému a implementovat další používané protokoly.
Annotation The theme and subject of this work is the creation of library modules that enable to approach the diagnostic functions of control vehicle units by way of bus CAN, which seems to be, in the view of the future development, most perspective. It will be simple to program any control unit application with the support of the elaborated modules. The objective of this work is not to implement all diagnostic functions, but only to implement transparently individual communication layers. As the first stage I had to map all relevant protocols and standards and chose the appropriate to be implemented. In the second stage of the work I am dealing with the analysis of these protocols, and above all with the communication principles, in order to be able to implement the protocols thereafter. The implementation has been verified and checked in the OS Windows user mode, from which certain limitations emerge. I would like to continue to develop further on the subject of this work in my dissertation as I continue my studies. I plan to transfer the modules directly in to the operation system kernel driver and implement other protocols in use.
vii
viii
1. 2.
Seznam zkratek................................................................................................... 3 Úvod .................................................................................................................. 4 2.1. Definice diagnostiky ................................................................................... 4 2.2. Dostupné diagnostiky.................................................................................. 4 2.3. Cíl práce ..................................................................................................... 5 2.4. Princip komunikace .................................................................................... 5 2.4.1. Sériová linka (K-Line).......................................................................... 5 2.4.2. Sběrnice CAN ...................................................................................... 5 3. Rozbor problematiky .......................................................................................... 6 3.1. Komunikační protokoly .............................................................................. 6 Fyzická vrstva..................................................................................................... 6 3.1.1. Linková vrstva...................................................................................... 6 3.1.2. Transportní vrstva ................................................................................ 6 3.1.3. Aplikační vrstva ................................................................................... 6 3.2. Hierarchie komunikačních protokolů .......................................................... 7 Obr. 2 Struktura protokolů ...................................................................................... 8 3.3. Implementované protokoly......................................................................... 9 3.4. Controller Area Network (CAN) ................................................................. 9 3.4.1. Rozdělení do vrstev .............................................................................. 9 3.4.2. Arbitráž ................................................................................................ 9 3.4.3. Vládání bitu.......................................................................................... 9 3.4.4. Detekce chyb...................................................................................... 10 3.4.5. Chybové stavy uzlů ............................................................................ 10 3.4.6. Formáty rámců ................................................................................... 10 3.4.7. Typy rámců ........................................................................................ 10 3.4.8. Struktura standardního datového rámce .............................................. 10 3.4.9. Struktura rozšířeného datového rámce ................................................ 11 3.4.10. Rámec žádost o data ........................................................................... 11 3.4.11. Chybový rámec .................................................................................. 11 3.4.12. Rámec o přetížení............................................................................... 12 3.4.13. Filtrování zpráv: ................................................................................. 12 3.5. Volkswagen transport protocol VWTP 2.0 ................................................ 12 3.5.1. Vytvoření dynamického kanálu .......................................................... 12 3.5.2. Typy kanálových paketů..................................................................... 13 3.5.3. Parametry protokolu ........................................................................... 14 3.5.4. Udržování komunikace....................................................................... 15 3.5.5. Řešení chyb........................................................................................ 15 3.5.6. Příklad komunikace:........................................................................... 16 3.6. Volkswagen transport protocol VWTP 1.6 ................................................ 16 3.6.1. Vytvoření dynamického kanálu .......................................................... 16 3.6.2. Typy kanálových paketů..................................................................... 16 3.6.3. Parametry protokolu ........................................................................... 17 3.6.4. Udržování komunikace....................................................................... 18 3.6.5. Řešení chyb........................................................................................ 19 3.6.6. Příklad komunikace:........................................................................... 19 3.7. Keyword protocol 1281............................................................................. 19 3.7.1. Struktura bloku................................................................................... 19 3.7.2. Seznam příkazů .................................................................................. 19 3.7.3. Navázání komunikace......................................................................... 19 3.7.4. Udržení komunikace........................................................................... 20
1
3.7.5. Vyčítání dat....................................................................................... 20 3.7.6. Ukončení komunikace ........................................................................ 21 3.8. Keyword protocol 2000............................................................................. 21 3.8.1. Struktura zprávy – K-line ................................................................... 21 3.8.2. Struktura zprávy - CAN...................................................................... 22 3.8.3. Typy odpovědí na požadovanou službu .............................................. 22 3.8.4. Seznam identifikátorů služeb .............................................................. 22 3.8.5. Příklad komunikace............................................................................ 22 4. Řešení............................................................................................................... 23 4.1. Přehled implementačních souborů............................................................. 23 4.2. Fyzická vrstva........................................................................................... 23 4.3. Linková vrstva .......................................................................................... 24 4.4. Transportní vrstva ..................................................................................... 24 4.5. Aplikační vrstva........................................................................................ 27 4.5.1. KW 1281............................................................................................ 27 4.5.2. KWP 2000.......................................................................................... 27 4.6. Pomocné soubory...................................................................................... 27 4.7. Testování .................................................................................................. 27 5. Shrnutí a závěr.................................................................................................. 29 6. Seznam použité literatury.................................................................................. 30
2
1. Seznam zkratek Zkratka ACK AR BR BS CA CAN CS CT DC DLC DT ECU EOM K-line MNCT MNT MNTC OBD RS RTR RX SAE SN SOF T_CT T_E TN TX VWTP
Vysvětlení Potvrzovací paket Acknowledge request - vyžaduji potvrzení Break paket - přerušení spojení Block size - Velikost bloku Connection acknowledge paket - nastavení spojení (odpověď) Sériová sběrnice Connection setup paket - nastavení spojení Connection test paket - test spojení Disconnect paket - odpojení Délka dat Datový paket Electronic control unit - řídicí jednotka End of Message - konec zprávy Sériová linka k připojení diagnostiky Maximální hodnota během testování spojení Maximální hodnota během komunikace Maximální hodnota během spojování On Board Diagnostic - emisní diagnostika Receiver ready - přijímač je připraven na data Remote request - určuje ty CAN rámce Směr přijímání dat Society of Automotive Engineers - Společnost automobilových inženýrů Sequence number - Sekvenční číslo Start Of frame - začátek rámce Timeout při testování spojení Timeout při spojování Odezva sběrnice Směr odesílání dat Transportní protokol koncernu Volkswagen
3
2. Úvod S neustálým vylepšováním automobilů a klesající cenou elektroniky dochází stále k většímu uplatnění řídicích jednotek v automobilech. Řídicí jednotky se jako první začaly používat na řízení motoru, ve kterém byl karburátor nahrazen přímým vstřikováním. První řídicí jednotky pouze pomocí TTL logiky řídily podle údajů z čidel dobu vstřiku (dle [6]). Postupně pak začaly řídicí jednotky přebírat řízení nad dalšími částmi motoru (např. řízení předstihu). Dnešní automobil obsahuje celou řadu řídicích jednotek, které mezi sebou komunikují pomocí společné sběrnice. Jednotky v automobilu řídí například airbagy, klimatizaci, servořízení, ABS, ale i prosté elektrické stahovaní oken. Jednotky se dokáží přizpůsobit aktuálnímu stavu motoru a způsobu řízení vozidla, zachytávají do paměti závady i s aktuálními hodnotami měřených fyzikálních veličin v době výskytu chyby, lze v nich nastavovat parametry řízení (např. volnoběžné otáčky), obsahují v sobě identifikaci vozidla atd. Jako první diagnostika (definice pojmu viz kapitola 2.1), která se u řídicích jednotek začala používat, bylo tzn. „vyblikání“, kdy po připojení diod se na základě jejich blikání daly určit některé závady popř. hodnoty. Dnešní diagnostika probíhá mnohem sofistikovaněji, a to pomocí sériového rozhraní s použitím několika vrstev protokolů. Na základě vzrůstajícího počtu a komplexnějších funkcí řídicích jednotek lze konstatovat, že v dnešní době se bez diagnostiky řídicích jednotek neobejde žádný autoservis.
2.1.
Definice diagnostiky
Každá řídicí jednotka v automobilu má kromě své řídicí funkce, kdy se stará o chod dané části vozidla, také implementované diagnostické funkce. Tyto funkce se opakovaně volají v krátkých časových intervalech a monitorují jak vstupy a výstupy senzorů a akčních členů, tak i kontrolují virtuální komunikační kanály mezi jednotkami. Každá jednotka má definované přípustné meze hodnot, které sleduje, a v případě překročení některých z těchto mezí dojde k uložení příslušného chybového kódu a vybraných naměřených hodnot v okamžiku chyby (popřípadě k rozsvícení kontrolky na palubní desce automobilu). Pod pojmem diagnostika budu ve své práci rozumět nástroje, které komunikují s diagnostickým subsystémem řídicích jednotek. Dnes diagnostika umožňuje i některé další funkce, které s diagnostikování již tak úplně nesouvisí. Je to například zjištění identifikace jednotek, parametrizování jejich řídicích algoritmů nebo dokonce přímý přístup do paměti, který umožňuje kompletní přeprogramování jednotky.
2.2.
Dostupné diagnostiky
Existující diagnostické nástroje lze rozdělit na profesionální diagnostiku, která je vyvíjena přímo výrobcem vozu a na nástroje vyvíjené softwarovými firmami. Profesionální diagnostika poskytuje spolehlivé a komplexní řešení. Výrobce má k dispozici všechny potřebné popisy jednotek a protokolů. Problém tohoto řešení spočívá v jeho ceně, která se pohybuje kolem 500 000 Kč. Tyto diagnostiky si mohou dovolit pouze autorizované servisy, které mají ve většině případů přímo nařízeno tuto profesionální diagnostiku používat, jak je uvedeno v [8] (například pro značku Škoda se jedná na zařízení VAG 1552, VAS 5051 a VAS 5052). Řešení od softwarových firem jsou o něco levnější (v rozmezí 50 000 – 100 000 Kč) a tím i dostupnější pro menší neautorizované servisy. Tato diagnostika je složená z programu, který běží na standardním počítači s běžným operačním systémem. Automobil se pak k počítači připojuje pomocí speciálního kabelu, který na straně počítače používá standardní sériové rozhranní. Díky tomu, že si výrobce automobilů většinu dokumentace k řídicím
4
jednotkám přísně chrání, nelze od těchto programů čekat, že budou umět bez problému diagnostikovat každou jednotku.
2.3.
Cíl práce
Cílem mé práce je vytvořit sadu knihoven, které umožní provádět diagnostiku. Použitím těchto knihoven bude možné poměrně jednoduše vytvořit diagnostický nástroj. Cílem práce není naimplementovat všechny diagnostické funkce, nýbrž přehledně implementovat jednotlivé komunikační vrstvy s tím, že další diagnostické funkce bude možné na úrovni aplikační vrstvy jednoduše doimplementovat.
2.4.
Princip komunikace
Komunikace je rozdělená do protokolových vrstev. Počet vrstev se liší na základě toho, co je použito jako fyzická vrstva.
2.4.1. Sériová linka (K-Line) Při použití sériové linky je komunikace rozdělena mezi fyzickou, linkovou a aplikační vrstvu.
2.4.2. Sběrnice CAN Při použití sériové sběrnice CAN je komunikace rozdělena mezi fyzickou, linkovou, transportní a aplikační vrstvu. Komunikace vychází z modelu přenosu po sériové lince s tím, že je přidána transportní vrstva, která upravuje data z aplikační vrstvy tak, aby je bylo možné přenášet po sběrnici CAN. Aplikační vrstvě se pak komunikace jeví totožně, jako by komunikovala rovnou pomocí linkové vrstvy K-Line. Příslušná transportní vrstva vytváří na CAN sběrnici spolehlivé virtuální dvoubodové spojení, které je v případě K-Line definované již linkovou vrstvou.
Aplikační vrstva
Transportní vrstva Linková vrstva - CAN
Linková vrstva – K-Line
Fyzická vrstva - CAN
Fyzická vrstva – K-Line
Obr. 1. Struktura diagnostických protokolů
5
3. Rozbor problematiky 3.1.
Komunikační protokoly
Komunikační protokoly lze rozdělit do tři skupin a to dle standardizace. První skupinou jsou protokoly definované ISO. Dále protokoly definované SAE (Society of Automotive Engineers [4]), která v mnoha případech přebírá standarty od ISO ([5]). Poslední skupinu tvoří protokoly, které jsou specifické pro danou automobilovou společnost a které jsou ve většině případů klasifikované jako tajné. V následujícím přehledu se snažím zmapovat některé z nejvíce rozšířených a používaných protokolů. Vzhledem velkému počtu nejrůznějších standardů (obsáhlý přehled uveden na [10]) je jejich kompletní přehled nad rámec této práce. Také bych rád podotknul, že rozdělení do vrstev dle OSI modelu je u některých standardů poměrně problematické, protože při jejich návrhu nebyl na OSI model brán zřetel.
Fyzická vrstva Na fyzické vrstvě existují hned čtyři standardy. Jedná se o protokol ISO 9141 resp. ISO14230-1, který používají všechny evropské, drtivá většina asijských a některé americké vozy (zejm. DaimlerChrysler), dále protokol SAE-J1850-VPW (Variable Pulse Width, zkráceně "VPW") používaný koncernem General Motors a DaimlerChrysler pro některé americké modely a do třetice protokol SAE-J1850-PWM (Pulse Width Modulation, zkráceně "PWM" ) ve vozidlech Ford, a to i u některých evropských modelů. Čtvrtou variantou je rozhraní typu "CAN" (Controller Area Network), kterým jsou postupně vybavována nová vozidla, častokráte pak dokonce ještě současně se "starým" rozhraním ISO. Fyzická vrstva CAN je definována ve standardu ISO 11898-1 pro vysokorychlostní přenos a ISO 11898-3 pro nízkorychlostní přenos. Americké automobily mají být povinně vybavovány rozhraním CAN od roku 2008.
3.1.1. Linková vrstva Linková vrstva je definována pomocí standardů ISO 9141 (definuje jak fyzickou tak i linkovou vrstvu) a ISO 14230-2, které definují linkovou vrstvu pro sériovou linku K-line. Protokol CAN 2.0 respektive standard ISO 11898-1 a ISO 11898-3, které vedle fyzické vrstvy definují také linkovou vrstvu, jež je ze standartu CAN 2.0 převzatá, definuje linkovou vrstvu pro sběrnici CAN. Dále protokol SEA-J2171 definuje linkovou vrstvu pro SEA-J1850.
3.1.2. Transportní vrstva Transportní vrstva se využívá pouze při přenosu dat přes sběrnici CAN. Data, která vrstva obdrží od nadřazené vrstvy (aplikační vrstva), jsou rozložena do CAN rámců a naopak příchozí rámce z podřazené vrstvy (linková vrstva) jsou pro nadřazenou vrstvu složeny. Transportní vrstva zajišťuje přenos dat, tzn. definuje potvrzování, timeouty a popřípadě znovu odeslání dat po uplynutí timeoutu. Transportní vrstva je definována v protokolech VWTP 1.0, VWTP 1.4, VWTP 1.6 VWTP 2.0, které jsou specifické pro koncern Volkswagen. Dále ve standardu ISO 15765-2.
3.1.3. Aplikační vrstva Aplikační vrstva definuje význam dat, které se jednotce odesílají (příkazy) a která jednotka odesílá (odpověď). Je definována ve standardech KW-1281, KWP 2000 (ISO 142303), které se používají buď přímo s sériovou linkou K-Line a nebo s využitím transportního 6
protokolu se sběrnicí CAN. Protokol ISO 15765-3 je přímo navrhnut pro diagnostiku pomocí sběrnice CAN (využívá linkový protokol ISO 15765-2). Dále ISO 14230-4, ISO 15765-4 a OBD II, což jsou standardy sloužící k získávání emisních dat z automobilů.
3.2.
Hierarchie komunikačních protokolů
Hierarchie komunikačních protokolů je znázorněna na obrázku 2. Pro jednoduchost jsou v diagramu znázorněny pouze protokoly, které se používají v evropských automobilech. Červeně jsou pak zvýrazněny protokoly, které jsem ve své práci implementoval.
7
OBD II
ISO 14230-4
ISO 15765-4
KW-1281
VWTP 1.0
ISO 14230-2
K-Line ISO 9141
K-Line ISO 14230-1
VWTP 1.6
KWP 2000 ISO 14230-3
VWTP 2.0
CAN 2.0 A
CAN HS ISO 11898-2
Aplikační vrstva
Transportní vrstva
Linková vrstva
CAN LS ISO 11898-3
Fyzická vrstva
Obr. 2 Struktura protokolů
8
3.3.
Implementované protokoly
V mé práci jsem se zabýval implementováním protokolů, které se používají u vozů koncernu Volkswagen (Volkswagen, Seat, Škoda, Audi, Bentley, Bugatti, Lamborghini) a to při použití připojení řídicích jednotek pomocí sběrnice CAN. Sběrnice CAN je použita u nejnovějších vozů (např. Škoda Octavia II, VW Golf-5, VW Touran, Audi A6 atd.) a postupně by měla zcela nahradit starší technologii připojení řídicích jednotek K-Line. Použití elektroniky se sběrnicí CAN znamená, že dochází k redukci počtu kabelů a spojů, což velice snižuje možnost poruch elektroinstalace a také že v případě poruchy bude mnohem rychlejší a snazší ji lokalizovat a opravit.
3.4.
Controller Area Network (CAN)
CAN je sériový komunikační protokol, který byl původně vyvinut firmou Bosch pro nasazení v automobilech. Dnes se rozšířil i do řady dalších průmyslových aplikací. Důvodem je především nízká cena, snadné nasazení, spolehlivost, vysoká přenosová rychlost, snadná rozšiřitelnost a dostupnost potřebné součástkové základny. Protokol CAN je definován normou ISO 11898-1. Ta popisuje fyzickou vrstvu protokolu a specifikaci CAN 2.0A ([1]). Později byla ještě vytvořena specifikace CAN 2.0B, která zavádí dva pojmy - standardní a rozšířený formát zprávy (lišící se v délce identifikátoru zprávy – jsou ale mezi sebou plně kompatibilní). Tyto dokumenty definují fyzickou a linkovou vrstvu protokolu podle referenčního modelu ISO/OSI.
3.4.1. Rozdělení do vrstev •
•
Objektová vrstva: o Logical Link Control: Vrstva zajišťuje filtrování přijatých zpráv. Dále definuje způsoby zotavení a hlášení o přetížení. o Medium Access Control: Zajišťuje řízení a kontrolu rámců, arbitráž a signalizuje případné chyby. Dále řídí, kdy je možné na sběrnici vysílat (volná sběrnice) a definuje časování. Fyzická vrstva: Jejím úkolem je vlastní přenos jednotlivých bitů mezi jednotlivými uzly s respektováním všech elektrických vlastností. Uvnitř jedné sítě má fyzická vrstva stejné parametry pro všechny uzly, nicméně je možné zvolit si její parametry tak, aby co nejlépe vyhovovaly dané aplikaci.
Všechny uzly přijímají všechny zprávy, které pak na základě identifikátoru filtrují (zpráva může projít filtrem libovolnému počtu uzlů). Je garantováno, že zprávu přijmou buď všechny uzly nebo žádný uzel. Bitová rychlost v daném systému je pevná.
3.4.2. Arbitráž Pokud je volná sběrnice, může začít vysílat libovolná jednotka. Pokud začnou vysílat dvě jednotky najednou rozhodne se na základě priority, která je definována v identifikátoru – každá jednotka srovnává stav sběrnice s daty, která na sběrnici vyšle. Pokud zachytí místo recesivního bitu dominantní bit, ukončí vysílání (má nižší prioritu). Datový rámec má přednost před rámcem žádosti o data se stejnou prioritou.
3.4.3. Vládání bitu Vysílá-li se na sběrnici pět po sobě jdoucích bitu stejné úrovně, je do zprávy navíc vložen bit opačné úrovně. Toto opatření slouží jednak k detekci chyb, ale také ke správnému časovému synchronizování přijímačů jednotlivých uzlů.
9
3.4.4. Detekce chyb Chyby lze detekovat na základě sledování sběrnice (co pošlu, co je na sběrnici), CRC, vkládání bitů a kontroly struktury rámce. Poškozené zprávy jsou označeny libovolným uzlem (každý uzel kontroluje konzistenci zpráv) a budou znovu poslány. Maximální doba zotavení je 31 bitů. Uzel, který permanentně vysílá chybné rámce, bude od sběrnice odpojen.
3.4.5. Chybové stavy uzlů Každý uzel se může nacházet v aktivním chybovém stavu, pasivním chybovém stavu nebo ve stavu bus-off. Chybový stav je definován hodnotami dvojice chybových čítačů, čítače chyb při odesílání a čítače chyb při příjmu. Pokud hodnoty čítačů překročí definované meze, je uzel přepnut do pasivního resp. bus-off stavu.
3.4.6. Formáty rámců Protokol CAN 2.0 A definuje standardní rámec. Protokol CAN 2.0 B ke standardnímu rámci přidává rozšířený rámec.
3.4.7. Typy rámců • • • •
Datový rámec: tvoří základ komunikace, umožňuje zařízení vyslat zprávu dlouhou až 8 B. Žádost o data: požadavek na vyslání datového rámce se stejným identifikátorem, který je obsazen v žádosti. Zpráva o chybě: je vyslána při detekci chyby. Zpráva o přetížení: slouží k oddálení vyslání dalšího datového rámce nebo žádosti o data.
3.4.8. Struktura standardního datového rámce
Obr. 3 Struktura standardního rámce (převzato z [9])
SOF (Start Of Frame): Indikace začátku rámce – jeden dominantní bit. Identifikátor zprávy: identifikuje danou zprávu a zároveň určuje prioritu RTR(Remote Request): slouží k rozlišení zda jde o datový rámec (dominantní -datový rámec má větší prioritu) nebo o žádost o data (recesivní). R1(IDE): určuje zda se jedná o standardní (dominantní) nebo rozšířený (recesivní) rámec. Délka dat (DLC): Kóduje délku datových bytů. Nabývá hodnot 0-8 s tím, že dominantní bit je 0, recesivní 1. Data: 0-8 bytů přenášených dat. MSB je první. CRC: sekvence CRC zabezpečovacího kódu oddělená recesivním bitem ERC. 10
ACK: u vysílané zprávy je vždy recesivní. Každý uzel,který zprávu se správným CRC zachytí, nastaví bit na dominantní. ACD: Odděluje ACK – je vždy recesivní. (ACK je vždy obklopen dvěma recesivními bity) Konec rámce (End Of Frame): Odděluje rámce – 7 recesivních bitů.
3.4.9. Struktura rozšířeného datového rámce Rozšířený datový rámec se liší pouze delším identifikátorem (29 bit), který je kvůli kompatibilitě se standardním rámcem rozdělen na dvě části. První část je dlouhá 11 bitů a je shodná s formátem standardního rámce. Druhá část je dlouhá 18 bitů. Standardní/Rozšířený rámec se odliší pomocí IDE respektive R1 bitu (standardní – dominantní, rozšířený – recesivní). Plná podpora rozšířených rámců není vyžadována tzn. na sběrnici mohou být připojeny jak uzly, které mají definován pouze standardní rámec, tak i uzly, které umí pracovat s rozšířeným rámcem. Avšak uzel, který neumí s rozšířeným rámcem pracovat, nesmí rozšířené rámce detekovat jako chybu (může je pouze ignorovat).
Obr. 4 Struktura rozšířeného rámce (převzato z [9])
SRR: Nahrazuje RTR, který je přesunut za druhou část identifikátoru. Vždy je nastaven jako recesivní což způsobuje, že standardní rámec se stejným identifikátorem (respektive se stejnými 11b identifikátoru) bude mít vždy větší prioritu než rozšířený rámec.
3.4.10.
Rámec žádost o data
Slouží k žádosti o určitá data. Na rozdíl od datového rámce je RTR bit recesivní, rámec neobsahuje datové pole a délka dat určuje délku dat, která jsou žádána. RTR v recesivní úrovni zajišťuje, že data mají vyšší prioritu než rámec, který by o ně žádal.
3.4.11.
Chybový rámec
Chybový rámec je složen z příznaku chyby a z oddělovače chyby. Příznak chyby je buď složen ze 6 dominantních bitů (pokud je uzel, který chybu detekoval, v aktivním chybovém stavu) nebo 6 recesivních bitů (pokud je uzel v pasivním chybovém stavu). Pokud uzel detekuje na sběrnici v přenášené zprávě chybu (na sběrnici je jiný bit než ten co byl vyslán, chyba CRC, porušení vkládání bitů, chyba rámce nebo není potvrzeno přijetí zprávy), vygeneruje ihned na sběrnici chybový rámec. Při generování aktivního příznaku chyby je přenášená zpráva poškozena (vzhledem k porušení pravidla vkládání bitů), a tedy i ostatní uzly začnou vysílat chybové zprávy. Hlášení chyb je pak indikováno superpozicí všech chybových příznaků, které vysílají jednotlivé uzly. Délka
11
tohoto úseku může být minimálně 6 a maximálně 12 bitů. Po vyslání chybového příznaku vysílá každý uzel na sběrnici recesivní bity. Zároveň detekuje stav sběrnice a jakmile najde na sběrnici první recesivní bit, vysílá se dalších sedm recesivních bitů, které plní funkci oddělovače chyb (ukončení chybového rámce). Pokud uzel, který se nachází v pasivním signalizačním módu, detekuje chybu, pokusí se na sběrnici vyslat 6 recesivních bitu, které ale neovlivní stav sběrnice. Pokud žádný jiný uzel chybu nezachytí, tak nedochází k poškození právě posílaného rámce. Pasivní signalizační mód zajišťuje, aby nedošlo k přetížení sběrnice v situaci kdy, bude mít jeden uzel permanentní problémy s příjmem zpráv.
3.4.12.
Rámec o přetížení
Zpráva o přetížení je složena z příznaku přetížení (šest dominantních bitů) a případné superpozice všech příznaků přetížení, pokud jsou generovány více uzly současně. Za příznaky přetížení následuje dalších sedm recesivních bitů, které tvoří oddělovač zprávy o přetížení. Zpráva o přetížení muže být vyslána pouze po konci předcházejícího rámce (tím se odlišuje od chybového rámce). Zpravidla tento rámec využívají zařízení, která nejsou schopna kvůli svému vytížení přijímat a zpracovávat další data.
3.4.13.
Filtrování zpráv:
Filtrování zpráv se provádí na základě identifikátoru v rámci a to nejčastěji pomocí maskovacích registrů.
3.5.
Volkswagen transport protocol VWTP 2.0
Jedná se o protokol transportní vrstvy, který zajišťuje přenos dat po CAN sběrnici. Protokol definuje dynamické vytváření obousměrného přenosového kanálu mezi dvěma CAN jednotkami. Aby mohl být mezi dvěma jednotkami vytvořen dynamický kanál, má každá jednotka pevně přiřazenu jedinečnou adresu. Seznam těchto adres lze nalézt v příloze A. Po vytvoření příslušného dynamického kanálu komunikují jednotky mezi sebou pouze pomocí tohoto kanálu. Dále protokol definuje kontrolu spojeni pomocí potvrzování každého paketu respektive bloku paketů včetně opravy případných chyb, které se při přenosu dat vyskytnou.
3.5.1. Vytvoření dynamického kanálu Dynamický kanál je vytvořen odesláním Channel Setup paketu na sběrnici. Příslušná jednotka na paket odpoví paketem Channel Acknowledge. Formát obou paketů je následující: Id 10-0
1. Byte 7–0
2.Byte 7–0
3.Byte 7–0
Cíl
Operační kód
TX–ID Dolní bity
4.Byte 7-3 2-0 Info TX
TX-ID Horní bity
5.Byte 7–0 RX–ID Dolní bity
6.Byte 7-3 2-0
7.Byte 7–0
Info RX
Apl. Typ
RX-ID Horní bity
Tabulka 3-1 Formát paketů vytvářející spojení VWTP 2.0
Id: Adresa jednotky, která paket vyšle. Adresy jednotek nalezneme v příloze A. K adrese je nutné přičíst hodnotu 0x200. Odpovídá identifikátoru CAN rámce tzn. je obsažena v hlavičce CAN rámce nikoliv v datech.
12
Cíl: Adresa jednotky v automobilu, se kterou chceme navázat komunikaci. Adresu nalezneme v příloze A. Operační kód: Definice operačních kódů je uvedena v příloze I.
TX-ID
Požadavek Odpověď bit 3 bit 4
Info-TX
bit 7-5 Požadavek
RX-ID
Odpověď bit 3 bit 4 bit 7-5
Info-RX
Aplikační typ
0 Identifikátor jednotky, která komunikaci zahájila Rezervován Požadavek: 1 = není specifikován TX-ID Odpověď: 0 – TX-ID musí být nastaveno 0 Identifikátor, pomocí kterého se bude komunikovat s jednotkou, která komunikaci zahájila. Identifikátor, pomocí kterého se bude komunikovat s jednotkou, která odpověděla na zahájení komunikace. Rezervován 0 0 Typ aplikačního protokolu, který se bude používat.
Tabulka 3-2 Popis paketu vytvářející spojení VWTP 2.0
Detailnější popis nalezneme v příloze J. Po přijetí Channel Acknowledge paketu je nutné odeslat Connection Setup paket, na který příslušná jednotka odpoví Connection Acknowledge paketem. Formát těchto paketů je definován níže.
3.5.2. Typy kanálových paketů Typ DT ACK CS CA CT BR DC
0 TP 1 TP 1 TP 1 TP 1 TP 1 TP 1 TP 1
1 D/TP 2 TP 2 -
2 D/T1 T1 -
Byte paketu 3 4 D/D/T2 T3 T2 T3 -
5 D/T4 T4 -
6 D/-
7 D/-
Tabulka 3-3 Typy kanálových paketů VWTP 2.0
DT: Datový paket sloužící k přenosu dat z nadřazené aplikační vrstvy (KWP 2000). ACK: Potvrzení datových paketů. Počet paketu, po kterých musí dojít k potvrzení, je získán dynamicky při nastavování parametrů kanálu (v CA paketu viz. níže). Potvrzení obsahuje sekvenční číslo, které je rovno sekvenčnímu číslu dalšího paketu respektive sekvenčnímu číslu paketu, který požadujeme zaslat. CS: Connection setup paket, který nastavuje dynamické parametrů spojení. Je posílán jednotkou, která komunikaci zahájila - v našem případě tester. 13
CA: Connection Acknowledge odpověď na CS, která nastavuje dynamické parametry spojení. Je posílán jednotkou, se kterou spojení navazujeme – jednotka v automobilu. CT: Test spojení, který se používá k udržení komunikace, pokud nemáme co vysílat. Jednotka, která tento paket obdrží, na něj odpoví pomocí CA. BR: Žádost o přerušení posílání právě posílaných dat. Odesílatel pošle co nejdříve datový paket s příznakem konec zprávy (EOM) a přeruší odesílání dat. DC: Paket ukončující spojení. Spojení je nutné řádně ukončit posláním DC paketu, jinak nemusí jednotka zrušit kanál, kterých má jednotka omezený počet. Po vyčerpání kanálů přestane jednotka komunikovat. TP 1 byte slouží rozlišení typu paketu a k řízení přenosu dat. Jeho popis nalezneme v příloze K. AR: Pokud je roven 0, pak odesílatel vyžaduje potvrzení posílaného paketu pomocí ACK paketu. EOM: Hodnota 1 značí konec zprávy. Pokud daný datový paket vyžaduje zároveň potvrzení zprávy (ACK), potom je očekáván ACK paket a pak dochází k výměně práva na vysílání. Případě, že ACK není vyžadováno, dochází k výměně rovnou. Pomocí ACK s RS rovno 0 lze předaní práva na vysílání o čas T1 oddálit (ACK paket s RS rovno 0 lze posílat opakovaně tzn. že lze předání oddálit o libovolnou dobu). RS: Pokud jednotka nestačí zpracovávat přijímaná data, vyšle ACK paket s RS rovno 0. Do uplynutí času T1 musí jednotka odeslat další ACK paket s RS nastaveným dle situace. Sekvenční číslo: Slouží ke kontrole přenášených dat. V každém dalším paketu dochází k jeho inkrementování. Po inkrementaci z hodnoty 0xF je rovno 0. Počítá se zvlášť pro příchozí a odchozí pakety. TP 2 byte slouží k nastavení velikosti bloku. Jeho popis nalezneme v příloze L. Velikost bloku: Určuje, po kolika paketech je nutné vyžádat potvrzení (ACK). Po výměně hodnot velikostí bloků, která probíhá při nastavování spojení, se použije menší z obou hodnot.
3.5.3. Parametry protokolu Při sestavování spojení musí dojít k vynulování všech parametrů protokolu tzn. sekvenčních čísel, čítačů příslušných parametrů a časovačů. Statické parametry jsou pevně dány definicí protokolu (detailnější popis nalezneme v příloze M): Popis parametru Maximální doba mezi spojovacími pakety Odezva sběrnice Maximální počet pokusů o spojení Maximální doba mezi CT a CA pakety Maximální doba mezi CA a CT pakety Maximální počet přijatých požadavků na paket v jednom bloku. Požadavek nastává v situaci, kdy žádáme daný paket znovu, kvůli špatnému sekvenčnímu číslu. Maximální počet opakování požadavku o potvrzení. Nastává v situaci,
Zkratka T_E TN MNTC T_CTaktiv T_CTpassive MNTB MNT 14
kdy je odeslán DT paket s AR rovno 0 a do uplynutí příslušného timeoutu nepřijde požadovaný ACK. Maximální počet opakování testu spojení. Nastává v situaci kdy, na CT MNCT paket nepřijde do uplynutí příslušného timeoutu odpověď pomocí CA paketu. Tabulka 3-4 Statické parametry VWTP 2.0
Dynamické parametry jsou nastaveny na základě hodnot, které si jednotky vymění při sestavování spojení (pakety CS a CA): Zkratka BS T1,T1* T2,T2* T3,T3* T4,T4*
Popis Určuje, po kolika paketech je nutné vyžádat potvrzení (ACK). Maximální doba pro přijetí potvrzovacího paketu (ACK). Nepoužito – vždy 0xFF. Minimální interval mezi dvěma pakety. Nepoužito – vždy 0xFF. Tabulka 3-5 Dynamické parametry VWTP 2.0
Výpočet času T1/T1* a T3/T3* z odpovídajícího bytu: Bit 7
Bit 6
Bit 5
Bit 4
Základ
Bit 3
Bit 2
Bit 1
Bit 0
Čas Tabulka 3-6 Formát bytu T VWTP 2.0
Příslušný timeout T vypočítáme ze vztahu T = Základ x Čas. Definice základu je uvedena v příloze Q. Interní časovače jednotky (timeout) musí být nastaveny na vyšší hodnotu, než bylo odesláno druhé jednotce, protože je nutné brát v úvahu latenci sběrnice TN. Dále musí být při nastavování timeoutů splněna podmínka T1/T1* > 4 x T3/T3* . Dále Timeouty mohou nabývat speciálních hodnot, jejich definice je uvedena v příloze R.
3.5.4. Udržování komunikace Komunikace se udržuje pomocí paketu typu CT, na který daná jednotka odpoví paketem typu CA. Paket typu CT lze odesílat opakovaně a tím je možné komunikaci udržovat po libovolnou dobu.
3.5.5. Řešení chyb Pokud se během komunikace vyskytne chyba jako je například obdržení paketu se špatným sekvenčním číslem nebo dojde-li k vypršení některého z timeout, definuje protokol postupy, které se z případné chyby zotavit. Přesná definice těchto postupů je uvedena v příloze T.
15
3.5.6. Příklad komunikace: V příloze B je uveden záznam komunikace mezi testerem a řídicí jednotkou motoru automobilu.
3.6.
Volkswagen transport protocol VWTP 1.6
Jedná se o protokol transportní vrstvy, který zajišťuje přenos dat po CAN sběrnici. Protokol definuje dynamické vytváření obousměrného přenosového kanálu mezi dvěma CAN jednotkami. Aby mohl být mezi dvěma jednotkami vytvořen dynamický kanál, má každá jednotka pevně přiřazenu jedinečnou adresu. Seznam těchto adres lze nalézt v příloze C. Po vytvoření příslušného dynamického kanálu komunikují jednotky mezi sebou pouze pomocí tohoto kanálu. Dále protokol definuje kontrolu spojeni pomocí potvrzování každého paketu respektive bloku paketů včetně opravy případných chyb, které se při přenosu dat vyskytnou.
3.6.1. Vytvoření dynamického kanálu Dynamický kanál je vytvořen odesláním Channel Setup paketu na sběrnici. Příslušná jednotka na paket odpoví paketem Channel Acknowledge. Formát obou paketů je následující: Id 10-0
1. Byte 7–0
2.Byte 7–0
3.Byte 7–0
Cíl
Operační kód
Identifikátor kanálu
Tabulka 3-7 Formát paketů vytvářející spojení VWTP 1.6
Id: Adresa jednotky, která paket vyšle. Adresy jednotek nalezneme v příloze C. Odpovídá identifikátoru CAN rámce, tzn. je obsažena v hlavičce CAN rámce nikoliv v datech. Cíl: Adresa jednotky v automobilu, se kterou chceme navázat komunikaci. Adresu nalezneme v příloze C. Od adresy musíme odečíst hodnotu 0x200. Operační kód: Definice operačních kódů je uvedena v příloze N. Identifikátor kanálu: Odpovídá identifikátoru, který se bude jednotka používat po nastavení kanálu. Adresy kanálů jsou definovány v příloze D. Po přijetí Channel Acknowledge paketu je nutné odeslat Connection Setup paket, na který příslušná jednotka odpoví Connection Acknowledge paketem. Formát těchto paketů je definován níže.
3.6.2. Typy kanálových paketů Typ DT ACK CS CA DC
0 TP 1 TP 1 TP 1 TP 1 TP 1
1 D/TP 2 TP 2 -
2 D/T1 T1 -
Byte paketu 3 4 D/D/T2 T3 T2 T3 -
5 D/T4 T4 -
6 D/-
7 D/-
Tabulka 3-8 Typy kanálových paketů VWTP 1.6
16
DT: Datový paket sloužící k přenosu dat z nadřazené aplikační vrstvy (KW 1281). ACK: Potvrzení datových paketů. Počet paketu, po kterých musí dojít k potvrzení, je získán dynamicky při nastavování parametrů kanálu (v CA paketu viz. níže). Potvrzení obsahuje sekvenční číslo, které je rovno sekvenčnímu číslu dalšího paketu respektive sekvenčnímu číslu paketu, který požadujeme zaslat. CS: Connection Setup paket, který nastavuje dynamické parametrů spojení. Je posílán jednotkou, která komunikaci zahájila - v našem případě tester. CA: Connection Acknowledge odpověď na CS, která nastavuje dynamické parametry spojení. Je posílán jednotkou, se kterou spojení navazujeme – jednotka v automobilu. DC: Paket ukončující spojení. Spojení je nutné řádně ukončit posláním DC paketu, jinak nemusí jednotka zrušit kanál, kterých má jednotka omezený počet. Po vyčerpání kanálů přestane jednotka komunikovat. TP 1 byte slouží rozlišení typu paketu a k řízení přenosu dat. Jeho popis nalezneme v příloze O. AR: Pokud je roven 0, pak odesílatel vyžaduje potvrzení posílaného paketu pomocí ACK paketu. EOM: Hodnota 1 značí konec zprávy. Pokud daný datový paket vyžaduje zároveň potvrzení zprávy (ACK), potom je očekáván ACK paket a pak dochází k výměně práva na vysílání. Případě, že ACK není vyžadováno, dochází k výměně rovnou. Pomocí ACK s RS rovno 0 lze předaní práva na vysílání o čas T1 oddálit (ACK paket s RS rovno 0 lze posílat opakovaně tzn. že lze předání oddálit o libovolnou dobu). RS: Pokud jednotka nestačí zpracovávat přijímaná data, vyšle ACK paket s RS rovno 0. Do uplynutí času T1 musí jednotka odeslat další ACK paket s RS nastaveným dle situace. Sekvenční číslo: Slouží ke kontrole přenášených dat. V každém dalším paketu dochází k jeho inkrementování. Po každém odeslání příkazu a načtení odpovědi (myšleno příkaz z aplikační vrstvy) dochází k jeho vynulování. Po inkrementaci z hodnoty 0xF je rovno 0. Počítá se zvlášť pro příchozí a odchozí pakety. TP 2 byte slouží k nastavení velikosti bloku. Jeho popis nalezneme v příloze L. Velikost bloku: Určuje, po kolika paketech je nutné vyžádat potvrzení (ACK). Po výměně hodnot velikostí bloků, která probíhá při nastavování spojení, se použije menší z obou hodnot.
3.6.3. Parametry protokolu Při sestavování spojení musí dojít k vynulovaní všech parametrů protokolu tzn. sekvenčních čísel, čítačů příslušných parametrů a časovačů.
17
Statické parametry jsou pevně dány definicí protokolu (detailnější popis nalezneme v příloze P): Popis parametru Zkratka Maximální doba mezi spojovacími pakety T_E Maximální počet pokusů o spojení MNTC Maximální počet opakování požadavku o potvrzení. Nastává v situaci, kdy MNT je odeslán DT paket s AR rovno 0 a do uplynutí příslušného timeoutu nepřijde požadovaný ACK. A zároveň maximální počet přijatých požadavků na paket v jednom bloku. Požadavek nastává v situaci, kdy žádáme daný paket znovu, kvůli špatnému sekvenčnímu číslu. Tabulka 3-9 Statické parametry VWTP 1.6
Dynamické parametry jsou nastaveny na základě hodnot, které si jednotky vymění při sestavování spojení (pakety CS a CA): Zkratka BS T1,T1* T2,T2* T3,T3* T4,T4*
Popis Určuje, po kolika paketech je nutné vyžádat potvrzení (ACK). Maximální doba pro přijetí potvrzovacího paketu (ACK). Maximální doba mezi dvěma pakety. Minimální interval mezi dvěma pakety. Maximální doba během které příjemce očekává po změně směru posílání dat první paket. Tabulka 3-10 Dynamické parametry VWTP 1.6
Výpočet času T1/T1*, T2/T2*, T3/T3*, T4/T4* z odpovídajícího bytu: Bit 7
Bit 6
Bit 5
Bit 4
Základ
Bit 3
Bit 2
Bit 1
Bit 0
Čas Tabulka 3-11 Formát bytu T VWTP 1.6
Příslušný timeout T vypočítáme ze vztahu T = Základ x Čas. Definice základu je uvedena v příloze Q. Interní časovače jednotky (timeout) musí být nastaveny na vyšší hodnotu, než bylo odesláno druhé jednotce, protože je nutné brát v úvahu latenci sběrnice TN. Dále musí být při nastavování timeoutů splněna podmínka T1/T1* > 4 x T3/T3* . Dále Timeouty mohou nabývat speciálních hodnot, jejich definice je uvedena v příloze R.
3.6.4. Udržování komunikace Protokol nepodporuje udržování komunikace, proto se komunikace udržuje pomocí nadřazené aplikační vrstvy (KW 1281).
18
3.6.5. Řešení chyb Pokud se během komunikace vyskytne chyba jako je například obdržení paketu se špatným sekvenčním číslem nebo dojde-li k vypršení některého z timeout, definuje protokol postupy, které se z případné chyby zotavit. Přesná definice těchto postupů je uvedena v příloze U.
3.6.6. Příklad komunikace: V příloze E je uveden záznam komunikace mezi testerem a motorem automobilu.
3.7.
Keyword protocol 1281
Jedná se o protokol na aplikační vrstvě, který vychází z protokolu Robert Bosch KW 71 a je sním zpětně kompatibilní. Komunikace probíhá v tzv. blocích, pravidelně se ve vysílání střídá tester, jednotka, tester, jednotka, atd.. První po navázání komunikace vysílá ECU. Protokol lze použít buď přímo s fyzickou vrstvou a linkovou vrstvou definovanou v protokolu ISO 9141 (K - Line) nebo s transportním protokolem VW TP 1.6, linkovou a fyzickou vrstvou, která je definována v protokolu CAN 2.0A respektive ISO 11898. Při použití CAN sběrnice protokol ne zcela důsledně odděluje aplikační vrstvu a linkovou vrstvu, protože při navazování komunikace je nutné navázat komunikaci jak na úrovni transportní vrstvy, tak posléze i na úrovni KW 1281. Dále jsou během komunikace odesílána sekvenční čísla KW 1281 paketů, které slouží ke kontrole komunikace. Na druhé straně odpadá potvrzování jednotlivých bytů. Následující popis protokolu se zaměřuje na komunikaci s využitím sběrnice CAN. Vycházel jsem z příkladu komunikace [7], přičemž rozdíly mezi komunikací přes CAN a K-Line jsem vyzkoumal experimentálně.
3.7.1. Struktura bloku Bajt 1. 2. 3. 4. – n n+1
Popis Délka bloku (n) Sekvenční číslo Příkaz Data bloku Konec bloku (hodnota 0x03)
Tabulka 3-12 Struktura bloku protokolu KW 1281
3.7.2. Seznam příkazů Seznam příkazů je uveden v příloze F.
3.7.3. Navázání komunikace Po navázání komunikace na úrovni transportní vrstvy je potřeba navázat komunikaci i na úrovni KW 1281 následujícím způsobem:
19
Zdroj TESTER 15 55 01 8A ECU
Data
Popis
KW1 Synchronizační byte, Keywords (KW1281) TESTER 75 KW2 0F 01 F6 36 51 30 39 30 39 36 30 35 1. blok identifikace ECU 20 48 20 03 Tabulka 3-13 Příklad navázání komunikace KW 1281
3.7.4. Udržení komunikace Po prvním bloku identifikace, který je poslán testovanou jednotkou po zahájení komunikace, použijeme k udržení komunikace příkaz 9 (ACK). Nejdříve pokračujeme ve vyčítání jednotlivých bloků identifikace (příkaz F6). Po vyčtení identifikace začne diagnostikovaná jednotka odpovídat zaslaný příkaz 9 (ACK) příkazem 9 (ACK). Příkaz 9 (ACK) lze odesílat opakovaně a tím udržovat spojení s jednotkou po libovolnou dobu. Zdroj ECU
0F 01 20 48 TESTER 03 02 0F 03 ECU 20 56 TESTER 03 04 03 05 ECU TESTER 03 06 ………… ECU
F6 20 09 F6 57 09 09 09
Data Popis 36 51 30 39 30 39 36 30 35 1. blok identifikace 03 03 ACK 30 32 20 41 49 52 42 41 47 n. blok identifikace 03 03 ACK 03 ACK 03 ACK
Tabulka 3-14 Příklad udržování komunikace KW 1281
3.7.5. Vyčítání dat Přerušíme udržování komunikace pomocí příkazu 9 (ACK) a pošleme požadovaný příkaz. Testovaná jednotka nám posléze začne posílat požadovaná data. Po každém bloku dat je nutné poslat příkaz 9 (ACK). Testovaná jednotka pak pokračuje v odesílání dat nebo odpoví příkazem 9 (ACK) a tím nás uvědomí, že posílání dat je ukončeno a tester přechází do stavu kdy udržuje komunikaci. Zdroj TESTER ECU TESTER ECU TESTER ECU TESTER ECU
03 03 03 43 20 03 0F 41 03 03
Data 40 09 41 09 42 00 F6 36 48 20 42 09 43 F6 47 20 44 09 45 09
Popis 03 ACK 03 ACK 03 Vyčtení identifikace 51 30 39 39 36 30 35 1. blok identifikace 03 03 ACK 30 32 20 41 49 52 42 n. blok identifikace 56 57 03 03 ACK 03 ACK – konec posílání dat, následuje udržování komunikace Tabulka 3-15 Příklad vyčítání dat KW 1281
20
3.7.6. Ukončení komunikace Komunikaci ukončíme pomocí příkazu 6 (ukončení komunikace). Testovaná jednotka nic na úrovní aplikační vrstvy neodpoví, pouze vyvolá ukončení komunikace na úrovni transportní vrstvy.
3.8.
Keyword protocol 2000
Jedná se o protokol na aplikační vrstvě, který je standardizován v protokolu ISO 14230-3. Komunikace probíhá pomocí zpráv, pravidelně se ve vysílání střídá tester, jednotka, tester, jednotka, atd.. První po navázání komunikace vysílá tester. Protokol lze použít buď přímo s fyzickou vrstvou a linkovou vrstvou definovanou v protokolu ISO 14230-1 (K - Line) respektive ISO 14230-2 nebo s transportním protokolem VW TP 2.0, linkovou a fyzickou vrstvou, která je definována v protokolu CAN 2.0A respektive ISO 11898. KWP 2000 definuje čistě aplikační vrstvu. Veškeré navazování, udržování, ukončování, kontrola a řízení komunikace je ponecháno nižším vrstvám (i při komunikaci přes CAN sběrnici). Následující popis protokolu se zaměřuje na komunikaci s využitím sběrnice CAN.
3.8.1. Struktura zprávy – K-line Dle popisu, který je uveden v [3]. Bajt 1. 2. 3. 4. 5. 6. – n n+1
Popis Formát Cílová adresa Zdrojová adresa Délka dat Identifikátor služby (příkaz) Data zprávy Kontrolní součet Tabulka 3-16 Struktura zprávy KWP 2000 K-line
Formát: Určuje formát zprávy.Tento byte je povinný a jeho struktura je následující: Bit 7 A1
Bit 6 A0
Bit 5
Bit 4
Bit 3 Bit 2 Délka dat
Bit 1
Bit 0
Tabulka 3-17 Struktura bytu formát KWP 2000
A1 0 0 1 1
A0 0 1 0 1
Mód Bez adresové informace Výjimkový mód Fyzické adresování (používá se u VW) Funkční adresování Tabulka 3-18 Přehled módů KWP 2000
21
Cílová adresa: Určuje cílovou adresu zprávy. Byte je nepovinný, ale musí být vždy použit se zdrojovou adresou. Zdrojová adresa: Zdrojová adresa jednotky, která zprávu vysílá. Délka dat: Tento byte je nepovinný. Určuje délku datové části paketu a to v případě, kdy je délka dat v bytu formát rovna 0. Umožňuje odesílat pakety s délkou datové části až 255 bytu. Pokud je datová část kratší než 64 bytů lze použít oba způsoby určení délky (záleží na jednotce, co podporuje resp. vyžaduje). Jinak je nutné použít tento byte. Identifikátor služby: Určuje příkaz, která má jednotka vykonat (v dalších bytech datové části paketu většinou následují další parametry služby). Kontrolní součet: Zbytek po dělení 256 (oříznutí na jeden byte) ze součtu hodnot všech bytů paketu kromě samotného CS.
3.8.2. Struktura zprávy - CAN Bajt 1. 2. 3. 4. – n
Popis Formát (vždy 0 – bez adresy a neobsahuje délku) Délka dat Identifikátor služby (příkaz) Data zprávy Tabulka 3-19 Struktura zprávy KWP 2000 CAN
Data zprávy mohou obsahovat další parametry dané služby. Kompletní definice těchto parametrů je k nalezení ve standartu ISO 14230-3 ([2]). Jejich bližší popis je nad rámec této práce.
3.8.3. Typy odpovědí na požadovanou službu Pozitivní odpověď má nastaven specifický identifikátor služby v závislosti na požadované službě v příkazu. Negativní odpověď má nastaven identifikátor služby na hodnotu 0x7F. 4. byte obsahuje identifikátor žádané služby. 5. byte obsahuje identifikátor chyby, kvůli které nemohl být příkaz proveden.
3.8.4. Seznam identifikátorů služeb Seznam identifikátorů služeb je uveden v příloze G.
3.8.5. Příklad komunikace Příklad komunikace je uveden v příloze H.
22
4. Řešení Vývoj knihovních modulů probíhal na operačním systému Microsoft Windows XP Professional a to pomocí vývojového prostředí Microsoft Visual Studio 2005 Professional Edition. K vývoji byl použit jazyk C. V bakalářské práci jsem pro zjednodušení moduly implementoval v uživatelském režimu operačního systému. Z toho vyplývají některá omezení. V uživatelském režimu nelze zajistit kvůli přepínání kontextu přesné dodržení časovačů. Pokud je některý z timeoutů menší než 20 ms, mohou vznikat problémy i na nevytíženém operačním systému. Dále jsem byl nucen využít ke komunikaci více vláken, což si vynutilo použití některých funkcí z MFC, které jsou implementovány pomocí jazyka C++. Tyto omezení chci odstranit tím, že jednotlivé komunikační vrstvy budu implementovat přímo do jádra ovladače. S prací hodlám pokračovat v rámci diplomové práce. Aplikace využívá ke komunikaci více vláken, a to z důvodu nutnosti udržování komunikace, kdy modul musí s jednotkou autonomně komunikovat. Případná aplikace, která bude knihovní moduly používat, se žádným způsobem nemusí o udržování komunikace starat. O přepínání mezi udržováním komunikace a aplikací, která moduly využívá, se pak stará operační systém na úrovni přepínání procesů. Aplikace a komunikační vlákna mají zvýšenou prioritu (REALTIME_PRIORITY_CLASS resp. THREAD_PRIORITY_TIME_CRITICAL pro proces resp. vlákno), čímž je zajištěno přesnější dodržování časovačů, ovšem pouze za předpokladu, že na systému neběží nějaká další aplikace, která má nastavenu vyšší prioritu procesu.
4.1.
Přehled implementačních souborů
Na obr. 5 je uvedena struktura implementovaných protokolů s tím, že je bráno v úvahu rozdělení do zdrojových souborů. Aplikační vrstva KW1281Layer.cpp
Aplikační vrstva KWP2000Layer.cpp
Transportní vrstva (VWTP 1.6/2.0) – TPLayer.cpp
Linková vrstva – CanLayer.cpp, pcican.h Obr. 5 Přehled implementačních souborů
4.2.
Fyzická vrstva
Fyzická vrstva, která je definována v ISO – 11898-2, je implementována pomocí PCI CAN karty, která mi byla dodána vedoucím práce.
23
4.3.
Linková vrstva
Linková vrstva je implementována v souboru CanLayer.cpp, který využívá ovladače dané PCI CAN karty, který mi byl taktéž dodán vedoucím práce. K ovladači karty v knihovních modulech přistupuji pomocí knihovny PCICanDl.lib respektive PCICan.h, kde jsou definovány základní funkce na inicializaci karty, posílání a přijímaní CAN rámců. CanLayer.cpp tyto funkce využívá k tomu, aby vytvořil vhodné rozhranní pro nadřazenou transportní vrstvu. Canlayer.cpp obsahuje hlavní komunikační smyčku (funkce MainComThreadLoop), která je spouštěna v separátním vlákně a která umožňuje přijímat a odesílat data. Přijímání i odesílání dat je blokující, k čemuž využívám funkce WaitForReceive respektive WaitForSend. Tyto funkce se volají před čtením (funkce ReceiveData) nebo po zápisu (funkce SendData) z vyrovnávací paměti použité CAN PCI karty. Další problém, kterým jsem musel při čtení dat z CAN sběrnice řešit, bylo filtrování příchozích zpráv. Funkce ReceiveData načítá data tak dlouho, dokud neobdrží rámec s identifikátorem, který odpovídá používanému virtuálnímu kanálu. Tento způsob filtrování do jisté míry zhoršuje dodržování timeoutu pro příchozí rámce, proto v dalším vývoji knihoven plánuji zprávy filtrovat na úrovni CAN PCI karty. Canlayer.cpp dále obsahuje funkce na řízení MainComThreadLoop smyčky, její synchronizaci a na spouštění příslušných časovačů, které pak využívá nadřazená transportní vrstva. Canlayer.cpp také slouží k udržování komunikace při použití VWTP 2.0 jako nadřazeného transportního protokolu. Přesunutím udržování komunikace do co nejnižší vrstvy přineslo značné zjednodušení implementace nadřazených vrstev, které se tím pádem o udržování komunikace nemusejí již starat a mohou běžet ve stejném vláknu jako hlavní aplikace.
4.4.
Transportní vrstva
Transportní vrstva je implementována v souboru TPLayer.cpp a TPLayerCom.cpp. V každém souboru je implementován deterministický konečný automat, který je realizován způsobem, kdy je stav automatu reprezentován proměnou, což umožňuje jednoduší případnou změnu chování automatu. Při jeho návrhu jsem vycházel z obecného popisu implementace konečných automatů, která je uvedena ve skriptech [11]. V souboru TPLayer.cpp je implementován automat, který vytváří spojení s příslušnou jednotkou. Popis automatu je graficky vyjádřen na obr. 6. Po zavolání funkce ConnectMachine projde automat příslušnými stavy a dle podmínek skončí buď ve stavu IDLES, kdy proběhlo spojení úspěšně a dojde ke spuštění udržování komunikace nebo skončí ve stavu DISCONNECTED, když se připojení nezdaří. Funkce pak ukončí komunikační vlákno a informuje o tomto stavu nadřazenou vrstvu pomocí návratové hodnoty. TPLayer.cpp definuje funkci InitTPLayer, která nastavuje příslušné komunikační parametry, typ transportního protokolu a vytváří komunikační vlákno, definované v CanLayer.cpp. Dále TPLayer.cpp obsahuje funkce SetTPData a GetTPData, které vytvářejí rozhranní pro nadřazenou aplikační vrstvu tzn. předávají se pomocí nich data, která chceme odeslat, a získávají se pomocí nich data, která nám příslušná jednotka poslala.
24
Obsazená sběrnice/-
Odpojeno
Volná sběrnice/Pošli ChS Vypršelo T_E && MNTC=0/-
Vytvoření kanálu
Vypršelo T_E && MNTC>0/ Pošli ChS, MNTC--
Vypršelo T_E && MNTC=0/-
Obdržen Cha && nevypršel T_E/ Pošli CS
Vytvoření spojení
Vypršelo T_E && MNTC>0/ Pošli CS, MNTC--
Obdržen CA && nevypršel T_E/-
Posílání dat
Obr. 6 Automat realizující spojení TP
V souboru TPLayerCom.cpp je pomocí funkce CommMachine implementován automat, který realizuje odeslání příkazu a následné načtení odpovědi. Grafické vyjádření implementovaného automatu nalezneme na obr. 7. Automat nejdříve ukončí udržování komunikace (v případě typu protokolu VWTP 2.0), pak odešle zadaná data, načte odpověď a spustí udržování komunikace po přechodu do stavu IDLESCOM (v případě typu protokolu VWTP 2.0). Pokud během odesílání respektive načítání dat dojde k přerušení komunikace přechází automat do stavu DISCONCOM, kdy ukončí vytvořené komunikační vlákno a oznámí tuto skutečnost pomocí návratové hodnoty vyšší vrstvě. Dále je v souboru definována funkce na řádné ukončení komunikace.
25
Obr. 7 Automat realizující komunikaci TP
TPLayer.cpp a TPLayerCom.cpp implementují oba protokoly VWTP 1.6 a VWTP 2.0 s tím, že příslušný protokol se nastavuje při inicializaci. Tento postup se ukázal jako nejvýhodnější, protože oba protokoly jsou velice podobné. Přechody a stavy automatu jsou totožné a případné rozdíly v akcích automatu jsou řešeny pomocí podmínek. Jediný podstatný rozdíl mezi oběma protokoly je ve způsobu udržování komunikace, kdy v případě VWTP 1.6 26
je nutné udržovat komunikaci pomocí nadřazené aplikační vrstvy. Proto automat v případě protokolu VWTP 1.6 pouze komunikační vlákno zastaví a nepřepíná ho do stavu udržování komunikace, to se pak děje na úrovni aplikační vrstvy, která k udržování komunikace využívá všech funkcí protokolu transportní vrstvy.
4.5.
Aplikační vrstva
Aplikační vrstva využívá služeb transportní vrstvy a po zavolání příslušné inicializace této vrstvy neřeší už žádnou komunikaci, ale pouze sémantiku odeslaných a přijatých dat.
4.5.1. KW 1281 Protokol je implementován v souboru KW1281Layer.cpp. Jak bylo již výše zmíněno, protokol důsledně neodpovídá aplikační vrstvě, proto kromě inicializace příslušné transportní vrstvy (VWTP 1.6) musí provést připojení a odpojení i na své úrovni aplikační vrstvy. Toto je realizováno pomocí funkcí KW1281Connect respektive KW1281Disconnect, které musí být volány před a po ukončení komunikace. Dále protokol implementuje funkci KW1281Idle, která zajišťuje udržení komunikace. Tato funkce je spouštěna v separátním vlákně, což umožňuje autonomní činnost smyčky při udržování komunikace. Pokud dojde k přerušení komunikace během činnosti této smyčky, je vlákno ukončeno. Při dalším pokusu o odeslání vybraného příkazu je pak znovu navázána komunikace. Dále je implementována funkce KW1281GetLastError, která umožňuje aplikaci, která moduly používá, zjistit identifikátor případné chyby. KW1281Layer.cpp implementuje funkci na vyčtení identifikace připojené jednotky. Doimplementování dalších funkcí je díky funkci SendAndGetDataKW1281, která definuje odeslání a načtení obecných dat, pouze otázkou rutinní práce, kdy je nutné pouze nadefinovat obsah dat, které jednotce posíláme.
4.5.2. KWP 2000 Protokol je implementován v souboru KWP2000Layer.cpp. Po inicializaci, kterou provedeme funkcí KWP2000SelectUnit, provedeme připojení pomocí funkce KWP2000Connect. Komunikaci ukončíme pomocí funkce KWP2000Disconnect. V souboru jsou implementovány funkce na vyčtení identifikace připojené jednotky. Další funkce lze díky funkci SendAndGetDataKWP2000 jednoduše doimplementovat. Pomocí funkce KWP2000GetLastError lze zjistit identifikátor případné chyby spojení respektive identifikátor negativní odpovědi, pokud nemohl být námi volaný příkaz jednotkou vykonán. Na rozdíl od protokolu KW 1281 je KWP 2000 čistě aplikační protokol, proto nebylo nutné implementovat další spojování a udržování komunikace na aplikační vrstvě, což celkovou implementaci velice zjednodušilo.
4.6.
Pomocné soubory
V souboru TPECUtables.h je definována struktura, která obsahuje adresy příslušných jednotek. Struktura je navržena tak, aby bylo možné jednoduše přidat ke každé jednotce další položku, což můžeme využít k další specifikaci chování modulů vůči určité jednotce.
4.7.
Testování
Testování probíhalo na řídicích jednotkách airbagů, a to jak na jednotce s podporou VWTP 1.6 (Airbag VW51 1C0 909 601 a Airbag VW5 6Q0 909 605 H), tak i na jednotce s podporou VWTP 2.0 (Airbag VW52 6Q0 909 605 P). Testovací aplikace v cyklu odesílala příkazy s tím, že mezi nimi byly pomocí funkce Sleep, vytvářeny náhodné prodlevy, tak aby docházelo ke střídavému odesílání příkazů a přepínáním do módu udržování komunikace.
27
Během testu jsem zkoušel vytěžovat operační systém, což díky nedodržování timeoutů způsobovalo chyby při komunikaci. Následně jsem pak analyzoval ladicí výpisy za účelem kontroly, zda se implementace chová dle protokolu. Při nevytíženém operačním systému byla komunikace s řídicí jednotkou pomocí testovací aplikace stabilní.
28
5. Shrnutí a závěr Výsledkem mé práce je jednak rešerše příslušných protokolů a standardu. Tato rešerše byla ověřena a opravena dle poznatků, které jsem nabyl v druhé části práce, kdy jsem příslušné protokoly implementoval. Jako hlavní přínos této rešerše bych viděl to, že na rozdíl od standardů popisuje dané protokoly co nejstručněji a s ohledem na fakt, že se na jejím základě bude provádět implementace. Hlavním přínosem programové implementace daných protokolů je to, že není vytvořena koncová aplikace, nýbrž knihovní moduly, které mohou být dle potřeby použity na vývoj diagnostických aplikací. Na rozdíl od koncových aplikací nikdo takovéto knihovní moduly nenabízí. Jako hlavní možná vylepší bych navrhoval přesunutí knihovních modulů přímo do ovladače jádra operačního systému, čímž se vyřeší problémy s časování, o kterých jsem se v práci zmiňoval. Dále bych implementoval další diagnostické funkce. V poslední řadě bych provedl důkladné testování, protože dle zkušeností, které jsem nabyl během práce, nejsou vždy u každé jednotky standardy úplně přesně dodržovány. Lze očekávat, že bude nutné do modulů přidávat specifické informace o určitých typech jednotek. V práci hodlám pokračovat v rámci diplomové práce během dalšího studia na ČVUT.
29
6. Seznam použité literatury [1] Robert Bosch GmbH. CAN Specification Version 2.0. Postfach 30 02 40, D-70442 Stuttgart, 1991. [2] TC 22/SC 3. Keyword Protocol 2000 - Part 3 – Application Layer. ISO Standards, 1999. [3] TC 22/SC 3. Keyword Protocol 2000 - Part 2 - Data link layer. ISO Standards, 2000. [4] Společnost automobilových inženýrů, která provádí standardizaci. www.sae.org/ . [5] Mezinárodní organizace pro vydávání standardů. http://www.iso.org . [6] Úvod do problematiky diagnostiky řídicích jednotek. . http://auto-diagnostika.com/diag.htm [7] Příklad komunikace pomocí protokolu KW 1281. . http://www.hex.co.za/vaginfo/index.html [8] Úvod do problematiky existujících nástrojů k diagnostice. http://www.pc-autodiagnostika.cz/co_je_to_diagnostika.php . [9] Popis funkce sběrnice CAN od Ing. Karla Poláka, Ústav telekomunikací, VUT FEKT Brno. . http://www.elektrorevue.cz/clanky/03021/ [10] Seznam protokolů používající se ke diagnostice. . http://www.carsoft.cz/eobd.html [11] Karel Műller. Programovací jazyky. Česká nakladatelství ČVUT, ISBN 80-02-022458, 2001
technika
–
30
