Diagnostika elektronických řídicích jednotek

Transkript

1 Č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

2 ii

3 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

4 iv

5 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 v

6 vi

7 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

8 viii

9 1. Seznam zkratek Úvod Definice diagnostiky Dostupné diagnostiky Cíl práce Princip komunikace Sériová linka (K-Line) Sběrnice CAN Rozbor problematiky Komunikační protokoly... 6 Fyzická vrstva Linková vrstva Transportní vrstva Aplikační vrstva Hierarchie komunikačních protokolů... 7 Obr. 2 Struktura protokolů Implementované protokoly Controller Area Network (CAN) Rozdělení do vrstev Arbitráž Vládání bitu Detekce chyb Chybové stavy uzlů Formáty rámců Typy rámců Struktura standardního datového rámce Struktura rozšířeného datového rámce Rámec žádost o data Chybový rámec Rámec o přetížení Filtrování zpráv: Volkswagen transport protocol VWTP Vytvoření dynamického kanálu Typy kanálových paketů Parametry protokolu Udržování komunikace Řešení chyb Příklad komunikace: Volkswagen transport protocol VWTP Vytvoření dynamického kanálu Typy kanálových paketů Parametry protokolu Udržování komunikace Řešení chyb Příklad komunikace: Keyword protocol Struktura bloku Seznam příkazů Navázání komunikace Udržení komunikace

10 Vyčítání dat Ukončení komunikace Keyword protocol Struktura zprávy K-line Struktura zprávy - CAN Typy odpovědí na požadovanou službu Seznam identifikátorů služeb Příklad komunikace Řešení Přehled implementačních souborů Fyzická vrstva Linková vrstva Transportní vrstva Aplikační vrstva KW KWP Pomocné soubory Testování Shrnutí a závěr Seznam použité literatury

11 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

12 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 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 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 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í 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

13 jednotkám přísně chrání, nelze od těchto programů čekat, že budou umět bez problému diagnostikovat každou jednotku 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 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 Sériová linka (K-Line) Při použití sériové linky je komunikace rozdělena mezi fyzickou, linkovou a aplikační vrstvu 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

14 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. ISO , 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 pro vysokorychlostní přenos a ISO pro nízkorychlostní přenos. Americké automobily mají být povinně vybavovány rozhraním CAN od roku Linková vrstva Linková vrstva je definována pomocí standardů ISO 9141 (definuje jak fyzickou tak i linkovou vrstvu) a ISO , které definují linkovou vrstvu pro sériovou linku K-line. Protokol CAN 2.0 respektive standard ISO a ISO , 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-J 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 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 ), které se používají buď přímo s sériovou linkou K-Line a nebo s využitím transportního 6

15 protokolu se sběrnicí CAN. Protokol ISO je přímo navrhnut pro diagnostiku pomocí sběrnice CAN (využívá linkový protokol ISO ). Dále ISO , ISO a OBD II, což jsou standardy sloužící k získávání emisních dat z automobilů 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

16 OBD II ISO ISO KW-1281 KWP 2000 ISO Aplikační vrstva VWTP 1.0 VWTP 1.6 VWTP 2.0 Transportní vrstva ISO CAN 2.0 A Linková vrstva K-Line ISO 9141 K-Line ISO CAN HS ISO CAN LS ISO Fyzická vrstva Obr. 2 Struktura protokolů 8

17 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 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 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 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á 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 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

18 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 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 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 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 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

19 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ů 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 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 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

20 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 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 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ů 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 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 1. Byte 2.Byte 3.Byte 4.Byte 5.Byte 6.Byte 7.Byte Cíl Operační kód TX ID Dolní bity Info TX TX-ID Horní bity RX ID Dolní bity Info RX RX-ID Horní bity Apl. Typ 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

21 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 0 Odpověď Identifikátor jednotky, která komunikaci zahájila Info-TX bit 3 Rezervován bit 4 Požadavek: 1 = není specifikován TX-ID Odpověď: 0 TX-ID musí být nastaveno bit RX-ID Požadavek Identifikátor, pomocí kterého se bude komunikovat s jednotkou, která komunikaci zahájila. Odpověď Identifikátor, pomocí kterého se bude komunikovat s jednotkou, která odpověděla na zahájení komunikace. Info-RX bit 3 Rezervován bit 4 0 bit Aplikační typ 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 Typy kanálových paketů Typ Byte paketu DT TP 1 D/- D/- D/- D/- D/- D/- D/- ACK TP CS TP 1 TP 2 T1 T2 T3 T4 - - CA TP 1 TP 2 T1 T2 T3 T4 - - CT TP BR TP DC TP 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

22 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 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 Zkratka Maximální doba mezi spojovacími pakety T_E Odezva sběrnice TN Maximální počet pokusů o spojení MNTC Maximální doba mezi CT a CA pakety T_CT aktiv Maximální doba mezi CA a CT pakety T_CT passive Maximální počet přijatých požadavků na paket v jednom bloku. MNTB 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, MNT 14

23 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 paket nepřijde do uplynutí příslušného timeoutu odpověď pomocí CA paketu. Tabulka 3-4 Statické parametry VWTP 2.0 MNCT Dynamické parametry jsou nastaveny na základě hodnot, které si jednotky vymění při sestavování spojení (pakety CS a CA): Zkratka Popis BS Určuje, po kolika paketech je nutné vyžádat potvrzení (ACK). T1,T1* Maximální doba pro přijetí potvrzovacího paketu (ACK). T2,T2* Nepoužito vždy 0xFF. T3,T3* Minimální interval mezi dvěma pakety. T4,T4* 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 Bit 3 Bit 2 Bit 1 Bit 0 Základ Č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*. R. Dále Timeouty mohou nabývat speciálních hodnot, jejich definice je uvedena v příloze 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 Ř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

24 Příklad komunikace: V příloze B je uveden záznam komunikace mezi testerem a řídicí jednotkou motoru automobilu 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 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 1. Byte 2.Byte 3.Byte 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 Typy kanálových paketů Typ Byte paketu DT TP 1 D/- D/- D/- D/- D/- D/- D/- ACK TP CS TP 1 TP 2 T1 T2 T3 T4 - - CA TP 1 TP 2 T1 T2 T3 T4 - - DC TP Tabulka 3-8 Typy kanálových paketů VWTP

25 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 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

26 Statické parametry jsou pevně dány definicí protokolu (detailnější popis nalezneme v příloze P): Popis parametru Maximální doba mezi spojovacími pakety Maximální počet pokusů o spojení Maximální počet opakování požadavku o potvrzení. Nastává v situaci, kdy 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 Zkratka T_E MNTC MNT Dynamické parametry jsou nastaveny na základě hodnot, které si jednotky vymění při sestavování spojení (pakety CS a CA): Zkratka Popis BS Určuje, po kolika paketech je nutné vyžádat potvrzení (ACK). T1,T1* Maximální doba pro přijetí potvrzovacího paketu (ACK). T2,T2* Maximální doba mezi dvěma pakety. T3,T3* Minimální interval mezi dvěma pakety. T4,T4* 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 Bit 3 Bit 2 Bit 1 Bit 0 Základ Č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*. R. Dále Timeouty mohou nabývat speciálních hodnot, jejich definice je uvedena v příloze Udržování komunikace Protokol nepodporuje udržování komunikace, proto se komunikace udržuje pomocí nadřazené aplikační vrstvy (KW 1281). 18

27 Ř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 Příklad komunikace: V příloze E je uveden záznam komunikace mezi testerem a motorem automobilu 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 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 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ě Struktura bloku Bajt Popis 1. Délka bloku (n) 2. Sekvenční číslo 3. Příkaz 4. n Data bloku n+1 Konec bloku (hodnota 0x03) Tabulka 3-12 Struktura bloku protokolu KW Seznam příkazů Seznam příkazů je uveden v příloze F 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

28 Zdroj Data Popis TESTER 15 KW1 ECU A Synchronizační byte, Keywords (KW1281) TESTER 75 KW2 ECU 0F 01 F blok identifikace Tabulka 3-13 Příklad navázání komunikace KW 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 Data Popis ECU 0F 01 F blok identifikace TESTER ACK ECU 0F 03 F n. blok identifikace TESTER ACK ECU ACK TESTER ACK ECU Tabulka 3-14 Příklad udržování komunikace KW 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 Data Popis TESTER ACK ECU ACK TESTER Vyčtení identifikace ECU 43 F blok identifikace TESTER ACK ECU 0F 43 F n. blok identifikace TESTER ACK ECU ACK konec posílání dat, následuje udržování komunikace Tabulka 3-15 Příklad vyčítání dat KW

29 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 Keyword protocol 2000 Jedná se o protokol na aplikační vrstvě, který je standardizován v protokolu ISO 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 (K - Line) respektive ISO nebo s transportním protokolem VW TP 2.0, linkovou a fyzickou vrstvou, která je definována v protokolu CAN 2.0A respektive ISO 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 Struktura zprávy K-line Dle popisu, který je uveden v [3]. Bajt Popis 1. Formát 2. Cílová adresa 3. Zdrojová adresa 4. Délka dat 5. Identifikátor služby (příkaz) 6. n Data zprávy n + 1 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 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 A1 A0 Délka dat Tabulka 3-17 Struktura bytu formát KWP 2000 A1 A0 Mód 0 0 Bez adresové informace 0 1 Výjimkový mód 1 0 Fyzické adresování (používá se u VW) 1 1 Funkční adresování Tabulka 3-18 Přehled módů KWP

30 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 Struktura zprávy - CAN Bajt Popis 1. Formát (vždy 0 bez adresy a neobsahuje délku) 2. Délka dat 3. Identifikátor služby (příkaz) 4. n 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 ([2]). Jejich bližší popis je nad rámec této práce 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 Seznam identifikátorů služeb Seznam identifikátorů služeb je uveden v příloze G Příklad komunikace Příklad komunikace je uveden v příloze H. 22

31 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 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 , je implementována pomocí PCI CAN karty, která mi byla dodána vedoucím práce. 23

32 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 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

33 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