ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE. Fakulta elektrotechnická katedra měření. Bakalářská práce. AUTOSAR FlexRay Interface

Transkript

1 ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE Fakulta elektrotechnická katedra měření Bakalářská práce AUTOSAR FlexRay Interface Ondřej Hofierka 2011

2

3 Poděkování Tímto děkuji Ing. Denisu Warausovi za odborné vedení při zpracování této bakalářské práce a stejně tak bych chtěl poděkovat všem blízkým za podporu a pomoc během studií. Dále bych chtěl taktéž poděkovat firmě Ricardo Prague s.r.o., která mi umožnila provést testování na jejich hardwaru.

4 Čestné prohlášení Prohlašuji, že jsem zadanou bakalářskou práci zpracoval sám s přispěním vedoucího práce a používal jsem pouze literaturu v práci uvedenou. Dále prohlašuji, že nemám námitek proti půjčování nebo zveřejňování mé diplomové práce nebo její části se souhlasem katedry. V Praze dne podpis

5 Anotace: Tato práce se zabývá standardem AUTOSAR (AUTomotive Open System ARchitecture ve volném překladu znamená otevřený standard pro architekturu elektronických systémů v automobilech), jeho vznikem, vývojem a samotnou architekturou. Dále je hlavně zaměřena na implementaci modulu FlexRay Interface pro procesor TC1797 a na jeho testování. Klíčová slova: AUTOSAR, FlexRay Interface, TC1797, E-Ray Annotation: This work deals with the AUTomotive Open System ARchitecture (AUTOSAR) standard and its origin, development and the architecture. We also focused on the implementation of the FlexRay module for the TC1797 processor and its testing. Keywords: AUTOSAR, FlexRay Interface, TC1797, E-Ray

6 Obsah 1 Úvod 1 2 Autosar Architektura Historie Metodologie Virtual Functional Bus (VFB) Komponenty Interface Port Connector Runtime Environment (RTE) Basic Software (BSW) AUTOSAR komunikace Communication Service Communication Hardware Abstraction Communication Driver FlexRay Interface Indexační schéma Datová komunikace přes FlexRay Komunikační akce Stavy komunikace Přechody mezi stavy Mikrokontrolér TriCore TC E-Ray IP-modul Unit testování 32 6 Závěr 34 A Příloha Konfigurace FlexRay Interface 36 B Příloha Struktura přiloženého CD 47

7 Seznam obrázků 2.1 Vrstvy softwaru na daném ECU Rozložení členů do jednotlivých vrstev Časová osa standardu AUTOSAR Přidání state manageru Časová osa fáze III Základní metodologie návrhu AUTOSAR systému Systém z pohledu Virtual Function Bus Komunikace Client-server Komunikace Sender-receiver Výsledný návrh systému AUTOSAR Rozdělení VFB na RTE RTE Contract Phase RTE Generation Phase Basic Software Encapsulace SDU do PDU Communication Service Funkce AUTOSAR COM Funkce PDU Routeru Funkce I-PDU Multiplexeru Communication Hardware Abstraction Communication Driver Indexační schéma kontrolérů Indexační schéma transceiverů FlexRay Interface enkapsulace Stavovýstroj Blokové schéma E-Ray IP-modulu... 30

8 1 ÚVOD 1 Úvod V úvodních kapitolách se tato práce snaží objasnit systém pro řídící jednotky v automobilech - systém AUTOSAR. Jsou nastíněny důvody pro vznik tohoto systému, vytyčené cíle a historie systému. Dále se snaží vysvětlit postup návrhu tohoto systému a jeho fungování. Největší důraz je kladen na průběh komunikace aplikací systému probíhající pomocí komunikačních modulů systému. Jsou vysvětleny jednotlivé komunikační moduly a jejich interakce s ostatními moduly. Další kapitola je zaměřena na modul FlexRay Interface, který je součástí komunikačního stacku protokolu FlexRay verze 2.1. Je zde nastíněna problematika tohoto modulu a funkce vykonávané tímto modulem. Předposlední část této práce se zabývá mikrokontrolérem TC1797 od firmy Infineon a komunikačním modulem E-RAY IP implementujícím protokol FlexRay verze 2.1 od firmy Bosch, který je součástí mikrokontroléru. Na tomto mikrokontroléru probíhalo testování implementace FlexRay Interface. Poslední část práce pojednává o softwarovém testování (unit testy) modulu. 1

9 2 AUTOSAR 2 Autosar AUTOSAR je standardizovaná architektura pro elektrické a elektronické automobilové systémy. Vznikl po domluvě několika organizací podnikajících v automobilovém průmyslu. AUTOSAR stanovil architekturu a metodologii návrhu softwaru pro automobilové systémy. Hlavními důvody pro vznik specifikace AUTOSARu jsou: zvládnutí rostoucí složitosti E/E související se zvyšujícím se množstvím funkcí snadná modifikace, upgrade a aktualizace produktu škálovatelnost řešení napříč produktovou řadou zlepšení kvality a spolehlivosti E/E systémů. Cíle: splnění budoucích požadavků: dostupnost, bezpečnost, aktualizace větší využití komerčně běžných SW a HW komponent optimalizace nákladů snížení složitosti a rizik flexibilní začlenění a přenos funkcí škálovatelnost na různá vozidla a platformy. 2.1 Architektura Dosáhnout zadané cíle, lze jedině pokud navrhneme vysoce standardizovanou, vrstvenou a modulární architekturu softwaru. Pomocí vrstvení softwaru lze velmi jednoduše dosáhnout nezávislosti horních vrstev na hardwaru. Tím se splní požadavek na přenositelnost softwaru na jiný hardware. Modularitou získáme škálovatelnost softwaru. Stačí přidávat a odebírat jednotlivé moduly a tím ubírat či přidávat dané funkce. S tímto ovšem již souvisí i hardwarové požadavky. Spojením obou těchto vlastností splníme další požadavek, a to možnost snadných aktualizací, přičemž jen vyměníme daný modul bez toho, abychom museli měnit cokoli jiného. Tohle celé by nefungovalo, pokud by nebyly přesně standardizovány interface mezi jednotlivými vrstvami. Díky splnění tohoto požadavku není podstatné, jak daný modul plní svou funkci a kdo ji implementoval, stačí vědět, jak ji zavolat. Toto umožňuje zjednodušení a možnost spolupráce firem. 2

10 2 AUTOSAR 2.2 Historie Obr. 2.1: Vrstvy softwaru na daném ECU Historie Vzhledem ke stále se zvyšujícímu množství elektroniky v automobilech, její komplexnosti a provázanosti, v srpnu roku 2002 mezi společnostmi BMW, Bosch, Continental, DaimlerChrysler a Volkswagen proběhly prvotní diskuze o společných problémech a jejich řešeních.brzy poté se k těmto diskuzím připojila i společnost Siemens VDO. Společný technický tým byl vytvořen v listopadu roku Tento tým měl za úkol vymyslet technickou strategii. Partnerství mezi členy jádra bylo oficiálně podepsáno v červenci roku Ke členům jádra se dále připojil Ford Motor Company a to v listopadu roku Následně na to se v prosinci připojily i společnosti Peugeot Citroën Automobiles S. A. a Toyota Motor Corporation. V listopadu roku 2004 k nim přistoupila i společnost General Motors. Tyto společnosti jsou pouze jádrem, dále se na vývoji a implementace podílí mnoho další členů, jako prémiové členy jmenujme například: ARM, FreeScale, Fujitsu, Hitachi, Honda, Porsche, The MathWorks atd. Obr. 2.2: Rozložení členů do jednotlivých vrstev 12 3

11 2 AUTOSAR 2.2 Historie Po uzavření partnerství mezi společnostmi a vytvoření technického týmu přechází projekt koncem roku 2003 do Fáze I. Obr. 2.3: Časová osa standardu AUTOSAR 11 Hlavním cílem této fáze bylo vytvoření specifikace architektury, metodologie a šablon. Prvním výsledkem bylo vydání verze 1.0 (Release 1.0). Tato verze se soustředila hlavně na vrstvu Základního softwaru (Basic Software). Důvodem vydání bylo otestování konceptu AUTOSARu a zjištění nedostatků vzniklých při implementaci. Výsledky z testování byly pak využity při vývoji verze 2.0. Verze 2.0 byla zaměřena na dokončení vrstvy základního softwaru a zkompletování vrstvy Runtime Environment (RTE). Opět proběhlo testování, tentokrát již na sériově vyráběném hardwaru. Jak se dalo očekávat, znovu se objevily nedostatky, které záhy na to byly opraveny ve verzi 2.1. Tyto dvě verze byly jako první nasazeny několika členy do sériové výroby. Na začátku roku 2007 přechází projekt za současného testování verze 2.1 do fáze II. Pro druhou fázi bylo naplánováno vydání tří verzí. První verze, verze 3.0, vyšla začátkem roku Ve verzi 3.0 došlo k více než 500 změnám. Největší změny zaznamenala architektura komunikace. Bylo vylepšeno buzení a startování komunikace a byla přidána vrstva starající se o stav komunikace (state manager). V polovině roku 2008 vychází verze 3.1. Hlavní změnou v této verzi bylo přidání podpory On-Board-Diagnostics (OBD). Paralelně s verzí 3.0 respektive 3.1 se začíná vyvíjet verze 4.0. S verzí 4.0 byl uveden nový koncept architektury a metodologie. Navíc byly specifikovány testy shody pro BSW moduly a RTE, Obr. 2.4: Přidání state což umožňuje otestovat implementaci modulu, a pakliže se shoduje se standardem, tak lze udělit atest. Hlavní změnou v oblasti manageru 11 4

12 2 AUTOSAR 2.2 Historie šablon bylo přepracování šablony zdrojů ECU a sladění standardu Field Bus Exchange Format(FIBEX) s AUTOSARem. Dále verze 4.0 implementovala z pohledu architektury: podporu pro dlouhé datové typy, dynamickou délku signálu (verze 3.0 měla striktně danou délku signálu na 8 bytů což je forma používaná v CAN a LIN), podporu nových verzí komunikačních standardů (LIN z verze 2.0 na 2.1, FlexRay z verze 2.1 na verzi 3.0), přidání multi-jádrové podpory. Bylo také přidáno mnoho bezpečnostních funkcí jako např. dělení paměti s detekcí chyb, podpora pro duální architekturu mikrokontrolérů zajišťující detekci chyb hlavního mikrokontroléru druhým, atd. Verze 4.0 byla publikována koncem roku Vydáním této verze přechází projekt do fáze III ( ). Ve fázi III je plánováno vydání pouze jediné verze a údržba současných verzí. V plánu je například, dokončení podpory pro multi-jádrové mikrokontroléry, vylepšování bezpečnostních funkcí, podpora pro efektivní správu energie, usnadnění spolupráce s internetovými sítěmi, přidávání podporovaného hardwaru a další. Obr. 2.5: Časová osa fáze III 11 5

13 2 AUTOSAR 2.3 Metodologie 2.3 Metodologie Metodologie AUTOSARu popisuje, jak by měl probíhat návrh systému. Nestanovuje časový plán nebo kdo má být zodpovědný za danou činnost, pouze ukazuje jakým způsobem by se mělo postupovat. K tomu využívá Software Process Engineering meta-model, zkráceně SPEM. SPEM standardizuje terminologii užívanou pro popis procesu. Pro účely popisu metodologie AUTOSARu je využita jen malá část. Použitá terminologie: Element Popis Symbol Work- Product Activity Work-Product je vstupem nebo výsledkem činnosti. Může to být hlavičkový soubor, soubor XML, objektový kód. Activity je činnost prováděná nad nějakým Work-Productem. Guidance Guidance je pomocník pomáhající při provádění Activity. Může to být například generátor RTE. Flow Work- Products of Flow of Work-Product označuje průběh vykonávané činnosti. Spojuje vždy Work-Product s Activitou. Dependency Dependency označuje závislost jednoho Work-Product na jiném. Composition Composition označuje, že jeden Work- Product je součástí jiného. Tabulka 2.1: Metodologie Výsledná metodologie návrhu systému AUTOSAR, viz. obr

14 2 AUTOSAR 2.3 Metodologie Obr. 2.6: Základní metodologie návrhu AUTOSAR systému 9 Nejdříve je třeba vytvořit System Configuration Input. Je tedy třeba vybrat softwarové komponenty potřebné pro systém, vytvořit interakce mezi jednotlivými komponentami a vybrat hardware splňující požadavky. Všechny informace se shromáždí do souboru XML. Tento soubor poté obsahuje informace o poskytovaném a požadovaném API softwarovými komponentami, specifikace všech ECU např. periferie, senzory komunikační kontroléry a další. Po vytvoření tohoto Work-Productu je provedena Activita Configure System. Všechny softwarové komponenty se namapují na dané ECU v závislosti na hardwaru, časování komunikace, velikosti paměti atd. Vytvoří se topologie komunikační sítě. Všechny tyto informace jsou pak obsaženy v System Configuration Description. Následně se pro každé ECU vyberou relevantní informace. Activita ECU Extract of System Configuration vytvoří pro každé ECU soubor ECU Exctract of System Configuration. Tento soubor obsahuje jen informace relevantní pro dané ECU. Activita Configure ECU podle těchto informací vybere potřebné moduly základního softwaru, vytvoří jejich konfiguraci, nastaví časování atd. Tím vznikne ECU Configuration Description, v němž jsou obsažené všechny potřebné informace pro vytvoření spustitelného softwaru. Poslední Activita Generate Executable spojí všechny softwarové komponenty, základní software a vygeneruje potřebné RTE, toto zkompiluje a vytvoří spustitelný software pro dané ECU. Výše popsané je jen velmi letmý pohled do metodologie vývoje AUTOSAR systému. Ve skutečnosti se každý krok skládá ještě z mnoha dalších kroků. 7

15 2 AUTOSAR 2.4 Virtual Functional Bus (VFB) 2.4 Virtual Functional Bus (VFB) Základní částí návrhu softwaru pro automobil je Virtual Function Bus (dále jen VFB). V této části návrhu se systém AUTOSAR skládá z částí autonomního softwaru, kterým se říká komponenty, a VFB. Tento zprostředkovává komponentám komunikaci mezi sebou. Obr. 2.7: Systém z pohledu Virtual Function Bus Komponenty Komponenty, jak už bylo řečeno jsou autonomní části softwaru, které tvoří systém AUTOSAR. Daly by se rozdělit do dvou skupin. První skupinou jsou komponenty přímo spravující hardware a druhou skupinou jsou komponenty, které s hardwarem přímo nekomunikují a tyto budeme nazývat softwarové komponenty (SW-C). První skupina se dá přirovnat k operačnímu systému s ovladači na běžném PC, zatímco druhá skupina by se dala přirovnat k programům. SW-C jsou části AUTOSAR systému, které zajišťují určitou funkci. Například Light Controller SW- C zajišťuje zapínání, vypínání a případně další funkce světel. SW-C tedy nastavují nebo kontrolují činnost automobilu, jako například zapalování svíček, zdvih ventilů, dávkování paliva, atd. Každá softwarová komponenta musí být popsaná XML souborem, který obsahuje její porty a další informace. Tento XML soubor je později využit pro návrh AU- TOSAR systému. Vzájemnou interakci komponent zajišťuje Virtual Function Bus (VFB) pomocí portů (viz níže). Komponenty lze skládat do bloků, čímž vytvoří kompozitní komponentu. AUTOSAR podporuje celkem sedm druhů komponent (viz tab. 2.2) 8

16 2 AUTOSAR 2.4 Virtual Functional Bus (VFB) Typ Popis Symbol Application Tato softwarová komponenta implementuje aplikaci. Je zcela nezávislá na umístnění a hardwaru, na kterém běží. Může Software Component využívat všechny služby a komunikační mechanismy AUTOSAR systému. Může komunikovat se senzory a pohony pomocí komponenty senzor-actuator. Tato softwarová komponenta se stará o ovládání pohonů a získávání dat ze senzorů. Tato komponenta je částečně závislá Sensor-actuator na hardwaru a musí být vždy umístěna na Software Component ECU, ke kterému je daný senzor nebo pohonná jednotka připojena. Toto je znázorněno portem IO. Získaná data může odeslat kamkoli v systému AUTOSAR. Calibration Parameter Component Tato komponenta obsahuje kalibrační konstanty a zprostředkovává komponentám přístup k nim. Composition Tato komponenta je blok propojených softwarových komponent. Může využívat všechny služby a komunikační mechanismy AUTOSAR systému. ECUabstraction Component Tato komponenta je zcela závislá na hardwaru, zprostředkovává ostatním komponentám přístup k němu a také může k němu přistupovat přímo. Tyto komponenty jsou typicky využívány komponentami typu Sensor-actuator. 9

17 2 AUTOSAR 2.4 Virtual Functional Bus (VFB) Typ Popis Symbol Complex Device Tato komponenta je hardwarově závislá. Může využívat ke komunikaci portů, ale i přímo přistupovat k hardwaru. Touto komponentou je možné připojit do AU- TOSAR systému hardware, který jím není Driver Componenchod přímo podporován. Také usnadňuje přepsaný na AUTOSAR systém. Dříve na- software, který nebyl určený pro AUTOSAR, je možné znázornit touto komponentou a pouze upravit interface tak, aby odpovídal AUTOSARu. Tabulka 2.2: Typy softwarových komponent Interface Z pohledu VFB probíhá komunikace pomocí interface. Interface popisuje způsob komunikace komponent. Interface není ve skutečnosti implementován. Je to pouze popis, jak se má daný port chovat. Virtual Function Bus poskytuje tyto interface: Client-server Sender-receiver Calibration Client-server Obr. 2.8: Komunikace Client-server 10 10

18 2 AUTOSAR 2.4 Virtual Functional Bus (VFB) V interfacu typu Client-server, server poskytuje operaci a client může tuto operaci vyvolat. Komunikace je v praxi realizovaná pomocí funkce, kterou poskytuje server, přičemž client tuto funkci volá. Na obrázku 2.8 Light Controller SW-C požaduje po Light Actuator SW-C provedení funkce Turn on lights(). V tomto případě je Light Controller SW-C client, zatím co Light Actuator SW-C je server. Sender-receiver Obr. 2.9: Komunikace Sender-receiver 10 U interfacu typu Sender-receiver, sender poskytuje data jednomu či více receiverům. Tento typ je datově orientovaný. Je realizovaný proměnnou, do které sender zapisuje informace a receiver si tyto informace může přečíst. Na obrázku 2.9 Temperature sensor SW-C odesílá Temperature do Dashboard SW-C, přičemž neprobíhá žádné potvrzování přijetí. Calibration Calibration poskytuje přístup ke kalibračním konstantám. Kalibrační komponenta, na rozdíl od normální softwarové komponenty, nemá žádné vnitřní funkce, je to pouze kontejnerem poskytující kalibrační konstanty. Tyto jsou za běhu ECU pouze pro čtení, SW-C si tedy kalibrační konstanty může kdykoli přečíst Port Každý interface se skládá z portů. Port je bodem interakce komponenty. Komponenta může poskytovat informace či službu (PPort) nebo informace či službu vyžadovat (RPort). V prvním případě softwarová komponenta poskytuje data, respektive služby, definované v interface. Ve druhém případě komponenta vyžaduje data, respektive služby. Virtual Function Bus poskytuje deset typů portů (viz tab. 2.3). 11

19 2 AUTOSAR 2.4 Virtual Functional Bus (VFB) Typ portu Interface Symbol Popis PPort sender-receiver Komponenta poskytuje data. RPort sender-receiver Komponenta čte data. PPort client-server Komponenta poskytuje operaci. RPort client-server Komponenta vyžaduje operaci. PPort calibration Komponenta poskytuje kalibrační data. RPort calibration Komponenta vyžaduje kalibrační data. PPort sender-receiver Komponenta poskytuje data službám AUTOSARu. RPort sender-receiver Komponenta vyžaduje data od služeb AUTOSARu. PPort client-server Komponenta poskytuje operaci službám AUTOSARu. RPort client-server Komponenta vyžaduje operaci od služeb AUTOSARu. Tabulka 2.3: Druhy portů Connector Během návrhu systému AUTOSAR jsou softwarové komponenty, které potřebují komunikovat, propojeny pomocí connectorů. Connector vždy propojuje jeden port typu PPort s portem typu RPort. V případě komunikace typu sender-receiver connector znamená, že data poskytovaná komponentou s PPortem jsou odeslána na RPort komponenty. V případě komunikace typu client-server connector znamená, že funkce poskytovaná komponentou s PPortem je volána komponentou s RPortem. Výsledný návrh systému AU- TOSARu může vypadat například jako na obrázku

20 2 AUTOSAR 2.5 Runtime Environment (RTE) Obr. 2.10: Výsledný návrh systému AUTOSAR Runtime Environment (RTE) Runtime Environment implementuje funkci VFB pro dané ECU. Po první fázi návrhu systému AUTOSAR, což je vybrání softwarových komponent a vytvoření vzájemných propojení, je třeba rozdělit softwarové komponenty na jednotlivé ECU a implementovat VFB (viz obr. 2.11). Obr. 2.11: Rozdělení VFB na RTE Runtime Environment tedy implementuje interface mezi jednotlivými komponentami předepsané ve VFB. Zprostředkovává tedy komunikaci, jak s vrstvami základního softwaru ECU, tak i komunikaci s moduly nacházejícími se na jiném ECU a to přes daný 13

21 2 AUTOSAR 2.5 Runtime Environment (RTE) komunikační protokol. Každé ECU v AUTOSAR systému má svoje RTE, které zprostředkovává komunikaci modulů na daném ECU. Navíc RTE zprostředkovává spouštění Runnable Entities, což je funkce uvnitř SW-C, která je reakcí na určitou událost. Touto událostí může být přerušení časovače, přepnutí módu atd. Tyto události se nazývají RTE Events. AUTOSAR definuje sedm RTE Events: TimingEvent DataReceivedEvent (pouze komunikace typu sender-receiver) DataReceiveErrorEvent (pouze komunikace typu sender-receiver) DataSendCompletedEvent (pouze komunikace typu sender-receiver) OperationInvokedEvent (pouze komunikace typu client-server) AsynchronousServerCallReturnsEvent (pouze komunikace typu client-server) ModeSwitchEvent Generování RTE je rozděleno do dvou fází, RTE Contract Phase a RTE Generation Phase. RTE Contract Phase Obr. 2.12: RTE Contract Phase 6 V této fázi se, pro každou softwarovou komponentu, vytvoří hlavičkový soubor. Tento soubor definuje API, které dovoluje softwarové komponentě interagovat s RTE. Po vytvoření tohoto hlavičkového souboru lze komponentu zkompilovat a zjistit pro tuto potřebnou velikost RAM a ROM. Díky těmto informacím je možné zjistit, jestli je paměť daného ECU dostatečná. 14

22 2 AUTOSAR 2.6 Basic Software (BSW) RTE Generation Phase Obr. 2.13: RTE Generation Phase 6 Ve druhé fázi se informace v ECU configuration description použijí ke konečné kompilaci RTE pro dané ECU. Tento soubor obsahuje detailní informace o interfacech softwarových komponent namapovaných na ECU např. namapování portů na zprávy COM. 2.6 Basic Software (BSW) Basic Software stejně jako RTE je částí implementace VFB. Samotné RTE by nefungovalo bez BSW. BSW je hardwarově závislý, jelikož ovládá hardware daného ECU. BSW se skládá z mnoha modulů (viz obr. 2.14). Obr. 2.14: Basic Software 8 Základní dělení BSW je: Microcontroller Abstraction Layer Je nejnižší vrstvou AUTOSAR systému. Obsahuje moduly driverů, které přímo přistupují k hardwaru ECU. Cílem této vrstvy je poskytnout vyšším vrstvám standardizované API pro přístup k danému hardwaru. Díky této abstrakci vyšší vrstvy nemusí vědět, na kterém kontaktu je daný hardware připojený nebo do kterého registru se má jaká informace zapsat. Microcontroller Abstraction Layer je složena z driverů pro daný hardware. 15

23 2 AUTOSAR 2.7 AUTOSAR komunikace Poskytuje například přístup k: digitálním vstupům a výstupům A/D převodníkům PWM modulátorům Watchdog timerů CAN komunikačním kontrolerům ECU Abstraction Layer Je vrstvou dosahující dalšího stupně abstrakce hardwaru. Přímo přistupuje k API Microcontroller Abstraction Layer. Většina přístupů k hardwaru prochází skrz tuto vrstvu. Poskytuje přístup k hardwaru nezávisle na jeho umístění (interní, externí) a nezávisle na použitých driverech. Service Layer Je vrstva zprostředkovávající základní služby jak BSW, tak RTE, respektive SW- C. Mezi tyto služby patří například diagnostika, NVRAM, správa Flash paměti, funkce operačního systému a další. Ke své funkci využívá vrstvy ECU Abstraction Layer. Complex Drivers Layer Tato vrstva obsahuje implementaci Complex Device Driver Component. Jak již bylo řečeno, tato vrstva je určena pro podporu hardwaru, který AUTOSAR nepodporuje nebo pro implementaci operací, které by byly příliš pomalé při využití normálního vrstvení AUTOSARu. Také umožňuje přechod z softwaru na AUTOSAR systém. 2.7 AUTOSAR komunikace Komunikace AUTOSAR systému je založena na ISO/OSI modelu. ISO/OSI model vypracovala organizace ISO. Slouží k vypracování vrstveného komunikačního systému. Tento model nespecifikuje implementaci jednotlivých vrstev, ale pouze uvádí, o co by se měly jednotlivé vrstvy starat. AUTOSAR implementuje tento model takto: ISO/OSI Prefix vrstvy AUTOSAR modul Název PDU vrstva 6. vrstva: I COM, DCM I-PDU Prezentační I PDU router, PDU multiplexer I-PDU 16

24 2 AUTOSAR 2.7 AUTOSAR komunikace ISO/OSI vrstva 3. vrstva: Síťová 2. vrstva: Datová Prefix vrstvy AUTOSAR modul Název PDU N TP Layer N-PDU L Driver, Interface L-PDU Tabulka 2.4: Implementace ISO/OSI modelu Jednotlivé vrstvy si mezi sebou předávají PDU. PDU (Protocol Data Unit) je datový segment, který předává horní vrstva spodní vrstvě. Tento segment obsahuje PCI (Protocol Control Information), tedy řídící data dané horní vrstvy, a SDU (Service Data Unit) což jsou data, která buď daná vrstva vytvořila nebo dostala v podobě PDU od vrstvy nad ní. SDU je také datový segment, který nižší vrstva předává vyšší. Nižší vrstva tedy nejdříve odebere svá PCI a předá samotné SDU vyšší vrstvě. Obr. 2.15: Encapsulace SDU do PDU Communication Service Obr. 2.16: Communication Service 8 Vrstva Communication Service poskytuje vyšším vrstvám, tedy vrstvě RTE, respektive SW-C, jednotné rozhraní pro veškerou síťovou komunikaci, správu sítě a diagnostiku 17

25 2 AUTOSAR 2.7 AUTOSAR komunikace komunikace. Také skrývá vyšším vrstvám užívaný protokol a jeho vlastnosti. K tomuto účelu využívá vrstvu Communication Hardware Abstraction. Communication Service se skládá z těchto modulů: AUTOSAR COM Modul AUTOSAR COM poskytuje RTE signálově orientovanou datovou komunikaci. Signál reprezentuje primitivní datový typ, jako např. uint8, sint32, unit8[n] atd. RTE požádá AUTOSAR COM o přenos signálů. COM zabalí signály do I-PDU a toto předá PDU Routeru (viz níže). Hlavní funkce poskytované tímto modulem jsou: poskytování signálově orientovaný interface pro RTE, garantování minimální doby mezi požadavky na přenos, filtrování příchozích signálů, provádění konverze endienity a znamének, enkapsulace a dekapsulace signálů na/z I-PDU, monitorování přijatých signálů. Obr. 2.17: Funkce AUTOSAR COM 18

26 2 AUTOSAR 2.7 AUTOSAR komunikace Diagnostic Communication Manager (DCM) Diagnostic Communication Manager je mezilehlá vrstva mezi aplikacemi a komunikační sítí automobilu. Poskytuje API pro diagnostický software. Je nezávislý na komunikačním protokolu a za tímto účelem využívá PDU Router modul. Zajišťuje přenos diagnostických dat, správu diagnostických a bezpečnostních módů. Kontroluje, jestli je možné spustit požadovanou službu diagnostiky. DCM obsahuje tyto funkční bloky: Diagnostic Service Processing (DSP) - implementuje diagnostické služby, které jsou stejné pro všechny aplikace, Diagnostic Service Dispatcher (DSD) - zpracovává diagnostická data, odesílá a přijímá diagnostická data přes síť, Diagnostic Session Layer (DSL) - spravuje diagnostické stavy, zajišťuje časování diagnostického protokolu. PDU Router Modul PDU Router se stará o směrování I-PDU do správného modulu. Modul obsahuje směrovací tabulka IPDU a směrovací engine. Směrování probíhá na základě PDU ID. PDU Router neprovádí žádné změny v IPDU, pouze přijme IPDU a podle záznamu ve směrovací tabulce jej předá správnému modulu. Toto směrování probíhá mezi moduly IPDU Multiplexer, Transport Protocol, AUTOSAR COM, DCM a Interface příslušných protokolů. Obr. 2.18: Funkce PDU Routeru 19

27 2 AUTOSAR 2.7 AUTOSAR komunikace Provádí tři základní funkce: PDU Reception - přijme I-PDU od modulu nižší vrstvy a odešle jej modulu vyšší vrstvy, PDU Transmission - přijme I-PDU od modulu vyšší vrstvy a odešle jej modulu nižší vrstvy, PDU Gateway - přijme I-PDU od interface modulu nebo Transport Protocol modulu a odešle jej opět interface modulu nebo Transport Protocol modulu Network Management (NM) Modul Network Management je rozdělen na dva menší moduly. Nadřazený modul Generic Network Management poskytuje jednotné API pro přístup k specifickým Network Management modulům. ECU v automobilech rozlišují tři druhy stavů: normální, nízkého odběru a spánek. Network Management zajišťuje přepínání těchto stavů synchronně v celém clustru, přičemž cluster je seskupení počítačů propojených jednou komunikační sběrnicí. Přepínání stavů provádí pomocí NM-message posílaných po síti. Pomocí těchto PDU NM je schopen zjistit potřebu jiných ECU na komunikaci po síti. Každá komunikační stanice posílá NM-message po celou dobu potřeby komunikace. Pokud po určitou dobu žádná komunikační stanice nepřijme nebo neodešle NM-message přejde celý cluster do Bus-Sleep Mode. NM Management poskytuje tyto módy: Bus-Sleep Mode - kontroléry v clusteru jsou uspány, Prepare Bus-Sleep Mode - příprava na přechod do Bus-Sleep Mode, Network Mode - probíhá normální komunikace v clusteru. Network Mode má tři sub-módy: Repeat Message Mode - stav po přechodu do Network Mode, žádná data nejsou odesílána, odesílá se pouze NM-message, pro zajištění přechodu všech stanic v clusteru do Network Mode, Normal Operation - probíhá komunikace i odesílání NM-message, Ready Sleep Mode - stanice nepotřebuje komunikovat po síti, odesílání NMmessage je zastaveno a stanice čeká po dobu probíhající komunikace v clusteru. Transport protocol Hlavní funkcí modulů Transport Protocol je rozdělení a následné sestavení I-PDU. PDU Router rozhoduje, jestli je I-PDU možné poslat rovnou přes modul Interface nebo je nutno použít Transport Protocol. Každý protokol má vlastní Transport Protocol modul. 20

28 2 AUTOSAR 2.7 AUTOSAR komunikace Transport Protocol zajišťuje tyto funkce: segmentaci odesílaných dat, sestavení přijatých dat, kontrolu toku dat - zajišťuje ochranu před zahlcením přijímacího kontroléru, detekci chyb - zajišťuje detekci chyb přijatých segmentů a znovu odeslání segmentovaných dat. I-PDU Multiplexer (IPDUM) Tento modul zajišťuje multiplexování I-PDU ID vrstvy Communication Hardware Abstraction. Prostřednictvím něho je možné odesílat pod jedním I-PDU ID vrstvy Communication Hardware Abstraction různé I-PDU modulu COM. Multiplexované I-PDU se skládá ze dvou částí. A to, statického segmentu, ve kterém je vždy přenášeno stejné I-PDU modulu COM, a dynamického segmentu, ve kterém se mohou vyskytovat různá I-PDU modulu COM. IPDUM do multiplexovaného I-PDU přidá data, podle kterých pozná jaké I-PDU je v dynamickém segmentu obsaženo. Obr. 2.19: Funkce I-PDU Multiplexeru Communication Hardware Abstraction Vrstva Communication Hardware Abstraction poskytuje vrstvě Communication Service jednotné API pro přístup k hardwaru. Pro každý komunikační protokol je jiná vrstva Communication Hardware Abstraction, přičemž pro každý protokol tato vrstva obsahuje modul Interface, Transceiver Driver a External Controller Driver. Například vrstva Communication Hardware Abstraction pro FlexRay obsahuje moduly Driver for External FlexRay Controller, Driver for External FlexRay Transceiver, FlexRay Interface. 21

29 2 AUTOSAR 2.7 AUTOSAR komunikace Obr. 2.20: Communication Hardware Abstraction Communication Driver Vrstva Communication Driver přímo přistupuje k hardwaru mikrokontroléru. Obsahuje drivery komunikačních kontrolérů umístěných přímo v mikrokontroléru. Zajišťuje komunikaci s externím komunikačním kontrolérem či přímo přístup na komunikační sběrnici v případě umístnění komunikačního kontroléru přímo v mikrokontroléru. Obr. 2.21: Communication Driver 8 22

30 3 FLEXRAY INTERFACE 3 FlexRay Interface Základním úkolem modulu FlexRay Interface je poskytnout standardizované API pro přístup na sběrnici typu FlexRay. Toto standardizované API umožňuje vyšším vrstvám stejný přístup k různým typům sběrnic, například CAN, LIN. Samotný interface nepřistupuje přímo k hardwaru komunikačního kontroléru. Pro přístup ke komunikačnímu kontroléru modul FlexRay Interface využívá jeden či více hardwarově specifických FlexRay driverů. FlexRay Interface poskytuje vyšším vrstvám tyto funkce: inicializaci, přenos dat, nastartování/zastavení/přerušení komunikace, specifické funkce FlexRay, nastavení módu, funkce časovače. 3.1 Indexační schéma FlexRay Interface musí umět současně spravovat více FlexRay kontrolérů od různých výrobců najednou, k čemuž je třeba zvolit indexační schéma. Pomocí tohoto schématu je skryto horním vrstvám, který FlexRay Driver modul je třeba použít pro daný kontrolér, respektive dané PDU. Obr. 3.1: Indexační schéma kontrolérů 4 23

31 3 FLEXRAY INTERFACE 3.2 Datová komunikace přes FlexRay Horní vrstvy používají pro přístup k danému kontroléru/clusteru indexy začínající od nuly. FlexRay Interface pak indexy kontroléru přeloží na dvojici FlexRay driver a index příslušného kontroléru ovládaného tímto driverem. I pro přístup k transceiverům je potřeba indexační schéma. Pomocí tohoto indexačního schématu mohou horní vrstvy znát pouze index kontroléru, ke kterému transceiver patří, a komunikační kanál, na který je připojen. FlexRay Interface tyto informace přeloží na dvojici FlexRay Transceiver Driver a příslušný index. Toto mapování musí být provedeno při návrhu komunikační sítě a je předáno FlexRay Interface v konfiguraci. Obr. 3.2: Indexační schéma transceiverů Datová komunikace přes FlexRay Časování FlexRay protokol používá časovou multiplexaci sběrnice (TDMA), přičemž tu není žádná spontánní komunikace, a proto veškerá komunikace přes FlexRay musí být FlexRay Interface známá před jejím spuštěním. Proto FlexRay Interface musí provádět některé operace synchronně s komunikačním cyklem. Aby tohoto bylo dosaženo, obsahuje FlexRay Interface Job List Execution Function. Tato funkce je zaregistrována na přerušení absolutního časovače. V zadaný okamžik je zavolána, provede danou akci a nastaví časovač na čas další komunikační akce. Všechny komunikační akce musí být nakonfigurovány před spuštěním komunikace. Balení PDU Délka AUTOSAR PDU je nastavena na 8 bytů, aby bylo AUTOSAR PDU nezávislé na přenášecím protokolu. FlexRay frame má pro data určeno 254 bytů, proto by bylo velmi 24

32 3 FLEXRAY INTERFACE 3.3 Komunikační akce neefektivní přenášet jedno PDU v jednom FlexRay framu. Pro snížení této neefektivity FlexRay Interface umožňuje zabalit více PDU do jednoho FlexRay framu (viz obr. 3.3). Do každého framu navíc přidá, pro každé PDU, Update Bit. Tento bit rozliší na přijímací straně, která PDU byla ve framu přenášena. Umístnění PDU a Update Bitu ve framu musí být nastaveno před startem komunikace. Pokud není Update Bit nastaven, je vždy dané PDU přenášeno. Obr. 3.3: FlexRay Interface enkapsulace 3.3 Komunikační akce Decouple Transmission FlexRay protokol používá TDMA, tedy není možné PDU přenášet kdykoli. Pokud potřebuje vyšší vrstva přenášet data, zavolá funkci FrIf Transmit(). FlexRay Interface si tudíž zapamatuje, že chce přenášet data. Při této akci pak zavolá funkci nadřazené vrstvy TriggerTransmit() a odešle data. Receive And Store Po přijetí PDU, jej FlexRay interface uloží do bufferu a nastaví update flag. Receive And Indicate Okamžitě po přijetí PDU, jej FlexRay Interface předá nadřazené vrstvě voláním funkce RxIndication(). 25

33 3 FLEXRAY INTERFACE 3.4 Stavy komunikace Rx Indication Pokud FlexRay Interface při akci Receive And Store přijme PDU a uloží ho do bufferu, pak při této akci předá data příslušné nadřazené vrstvě zavoláním funkce RxIndication(). Tx Confirmation Po úspěšném odeslání PDU, zavolá FlexRay Interface funkci TxConfirmation() příslušné nadřazené vrstvy. Zavoláním této funkce dá nadřazené vrstvě vědět o úspěšném odeslání PDU. 3.4 Stavy komunikace FlexRay Interface obsahuje stavový stroj, který je nezbytný pro startování, zastavení a ukončení komunikace. Tento stavový stroj zjednodušuje nadřezeným vrstvám stavový stroj sběrnice. Každý kontrolér má vlastní stavový stroj. Obr. 3.4: Stavový stroj Obsahuje tyto čtyři stavy: FRIF STATE HALT Tento stav je nastaven pro každý kontrolér po inicializaci FlexRay Interface (1), po zastavení komunikace z důvodu chyb nebo vyžádáním přechodu na tento stav. V tomto stavu neběží komunikace a kontrolér není synchronizován se sběrnicí. FRIF STATE OFFLINE V tomto stavu je kontrolér synchronizován se sběrnicí, ale komunikace neprobíhá. Do tohoto stavu kontrolér přechází po vyžádání. 26

34 3 FLEXRAY INTERFACE 3.5 Přechody mezi stavy FRIF STATE RXONLY V tomto stavu je kontrolér synchronizován se sběrnicí, ale může pouze přijímat příchozí PDU, nikoliv odesílat. Do tohoto stavu kontrolér přechází po vyžádání a nebo v případě chyb synchronizace. FRIF STATE ONLINE V tomto stavu běží plná komunikace. Kontrolér může přijímat i odesílat na sběrnici. Do tohoto stavu přechází kontrolér na vyžádání a jedině v případě, že je vše v pořádku. 3.5 Přechody mezi stavy Přechody mezi stavy jsou vyvolané, buď přechodem samotného kontroléru nebo vyšší vrstvou pomocí zavolaní funkce (např. FrIf AbortCommunication, FrIf RequestControllerTransition, FrIf RequestClusterTransition atd.). FlexRay Interface umožňuje pět druhů přechodů: FRIF GOTO OFFLINE Způsobí přechod kontroléru do stavu FRIF STATE OFFLINE. Pokud je tento přechod vyvolán v době, kdy je kontrolér ve stavu FRIF STATE HALT (viz obr ozn. 9), tak přechod nenastává okamžitě. K přechodu dojde asynchronně, pakliže kontrolér nastartuje komunikaci a synchronizuje se s clusterem. V ostatních případech dochází k přechodu okamžitě (viz obr ozn. 6, 13). FRIF GOTO RXONLY Jde o přechod kontroléru do stavu FRIF STATE RXONLY. Stejně jako v předcházejícím případě, pokud je tento přechod vyvolán v době, kdy je kontrolér ve stavu FRIF STATE HALT, dochází k přechodu asynchronně (viz obr ozn. 11). Také k tomuto přechodu dochází samovolně, pokud je kontrolér ve stavu FRIF STATE ONLINE a vyskytne se chyba synchronizace (viz obr ozn. 17). V ostatních případech je přechod okamžitý po vyvolání (viz obr ozn. 5, 7). FRIF GOTO ONLINE Kontroler přechází do stavu FRIF STATE ONLINE. Jako v předchozím případě, pokud je kontroler ve stavu FRIF STATE HALT, dojde k asynchronnímu přechodu v případě že se povede nastartovat komunikace (viz obr ozn. 2). K přechodu také dojde, pokud je kontrolér ve stavu FRIF STATE RXONLY a kontrolér se resynchronizuje (viz obr ozn. 21). V ostatních případech je přechod okamžitý (viz obr ozn. 4, 12). 27

35 3 FLEXRAY INTERFACE 3.5 Přechody mezi stavy FRIF GOTO HALT IMMEDIATELY Tento přechod způsobí převedí kontroléru do stavu FRIF STATE HALT. Přechod způsobí okamžité přerušení komunikace. Je vždy synchronní (viz obr ozn. 14, 15, 16). K přechodu může také dojít samovolně, v případě chyby (viz obr ozn. 18, 19, 20). FRIF GOTO HALT AT EOC NO COM Provede přechod kontroléru do stavu FRIF STATE HALT. Komunikace je ukončena na konci cyklu. Přechod je synchronní (viz obr ozn. 3, 8, 10). 28

36 4 MIKROKONTROLÉR TRICORE TC Mikrokontrolér TriCore TC1797 Mikrokontrolér TC1797 je kombinací tří technologií. Kombinuje architekturu RISC(Reduce Instruction Set Computing) procesorů, operace a adresaci signálových procesorů (DSP) a paměť s periferiemi na jednom čipu. DSP operace a adresace poskytuje efektivní zpracování signálů z měření. Architektura RISC poskytuje vysoký výpočetní výkon. Umístnění paměti s periferiemi na čip umožňuje vysokou rychlost komunikace potřebnou pro realtime řízení. Kombinací těchto tří technologií na jeden čip bylo dosaženo dostatečného výkonu pro real-time řízení při udržení dobrého poměru cena/výkon. Mikrokontrolér TC1797 obsahuje: vysoce výkonný 32-bitový superskalární TriCore V1.3.1 procesor s 4-stupňovým pipelinem a frekvencí 180 nebo 150 MHz, 32-bitový řadič periferií (PCP2), různé druhy pamětí (např. 4 nebo 31 Mbytovou programovou Flash paměť, 64Kbytovou datovou Flash paměť, 16Kbytovou BootROM atd.), 16-ti kanálový DMA řadič, sofistikovaný systém hardwarových přerušení, 44 kanálový A/D převodník s rozlišením 12 bitů a 4 kanálový rychlý A/D převodník s rozlišením 10 bitů, MultiCan modul se 4 CAN nody, FlexRay modul se 2 kanály (E-Ray IP-modul), 221 (GPIO) digital general purpose I/O, a další. 4.1 E-Ray IP-modul E-Ray IP-modul je komunikační kontrolér implementující specifikaci protokolu FlexRay verze 2.1 od firmy Bosch. Pro připojení na sběrnici potřebuje externí bus driver zajišťující zapisování a čtení dat na/ze sběrnice a nastartování wake up procedury při detekci wake up signálu. 29

37 4 MIKROKONTROLÉR TRICORE TC E-Ray IP-modul Vlastnosti použitého E-Ray IP-module: bit-rate až 10 MBit/sec pro každý kanál, až 128 bufferů pro zprávy, 8 Kbyte RAM pro uložení 128 bufferů zpráv s maximálně 48 byty dat nebo 30 bufferů s 254 byty dat, jedno konfigurovatelné přijímací FIFO, každý z bufferů pro zprávy je konfigurovatelný jako přijímací, vysílací nebo jako část přijímacího FIFO, konfigurovatelné filtrování zpráv podle rámce, kanálu a čísla cyklu, přístup k bufferům zpráv přes vstupní/výstupní buffer, 4 vstupní buffery, maskovatelné přerušení. Popis modulu Obr. 4.1: Blokové schéma E-Ray IP-modulu 14 Generic Interface - rozhraní pro připojení modulu k procesoru. Input/Output Buffer - buffer pro uložení zprávy směřující z/do Message RAM. Message RAM - paměť pro uložení zpráv. 30

38 4 MIKROKONTROLÉR TRICORE TC E-Ray IP-modul Protocol Unit A/B (PRT A/B) - obsahuje shift registr pro příjem/odesílání dat a stavový stroj FlexRay protokolu, který provádí časování bitů, kontrolu CRC a další. Transient Buffer RAM (TBF A/B) - buffer ukládající zprávu směřující do/z Protocol Unit A/B. Message Handler - kontroluje přesuny zpráv mezi Input/Output Buffery a Message RAM, mezi Message RAM a Protocol Unit A/B, respektive Transient Buffer RAM. System Universal Control (SUC) - kontroluje konfiguraci, start up, wake up a reintegraci do komunikace. Frame and Symbol Processing (FSP) - kontroluje správnost přijatých rámců a časování rámců a symbolů. Network Management (NEM) - spravuje NM-vector. Interrupt Control (INT) - kontroluje generování přerušení. Global Time Unit (GTU) - generuje mikrotiky/makrotiky, synchronizuje hodiny, poskytuje čítač cyklu a kontroluje časování statického a dynamického segmentu. 31

39 5 UNIT TESTOVÁNÍ 5 Unit testování Pro ověření funkčnosti implementace FlexRay Interface byly vytvořeny unit testy. Unit testování probíhalo postupným voláním všech funkcí s různými argumenty. Argumenty se volily tak, aby se otestovaly veškeré možné reakce funkcí na vstup. Po zavolání funkce byly prověřeny vrácené hodnoty a správné volání všech příslušných funkcí s příslušnými argumenty. Výstupy i vstupy všech funkcí jsou vypisovány na konzoli, aby je bylo možné zkontrolovat. Tento výstup navíc ukazuje, jak se dané funkce chovají. Testování je rozdělono do dvou bloků. První blok testuje volání funkcí před inicializací FlexRay Interface, tedy před zavoláním funkce FrIf Init(). Výstup pro funkci FrIf AbortCommunication() vypadá takto: ********************************************************************* Not initialized test ********************************************************************* Call FrIf_AbortCommunication Calling function Det_ReportError: Det_ReportError(60, 0, bh, 8h) Module ID: 60 Instance ID: 0 Api ID: FRIF_ABORTCOMMUNICATION_API_ID Error ID: FRIF_E_NOT_INITIALIZED Output: E_OK returned: E_NOT_OK Druhý blok již testuje reakci funkce po inicializaci. Testování probíhá na různé vstupy a různé návratové hodnoty volaných funkcí. ********************************************************************* Call FrIf_AbortCommunication ********************************************************************* Call with invalid controller index (FrIf_AbortCommunication(5)) Calling function Det_ReportError: Det_ReportError(60, 0, bh, 2h) Module ID: 60 Instance ID: 0 Api ID: FRIF_ABORTCOMMUNICATION_API_ID Error ID: FRIF_E_INV_CTRL_IDX Output: E_OK returned: E_NOT_OK 32

40 5 UNIT TESTOVÁNÍ Right call (FrIf_AbortCommunication(0)), Fr_AbortCommunication return: E_NOT_OK Calling function Fr_1_ERAY_AbortCommunication: Fr_1_ERAY_AbortCommunication(0) Controller index: 0 Output: E_NOT_OK returned: E_NOT_OK Right call (FrIf_AbortCommunication(0)), Fr_AbortCommunication return: E_OK Calling function Fr_1_ERAY_AbortCommunication: Fr_1_ERAY_AbortCommunication(0) Controller index: 0 Output: E_OK returned: E_OK Kompletní výpis unit testů je možné nalézt na přiloženém CD. 33

41 6 ZÁVĚR 6 Závěr Cílem této práce bylo vystvětlit principy systému AUTOSAR a implementovat FlexRay Interface verze 2.1. Samotný FlexRay Interface byl implementován i pro novější verze AU- TOSARu. Verze 2.1 dle mého názoru trpěla několika nedostatky. Jelikož state manager byl umístněn přímo ve FlexRay Interface, chyběly ve specifikaci některé vlastnosti zahrnuté do state manageru v novějších verzích, jako například časovače pro ověření asynchronních přechodů. Pokud se za určitou dobu nepodařilo nastartovat komunikaci, pak komunikační kontrolér zůstal ve stavu start up a dále se již nepokoušel nastartovat komunikaci. Tento problém se objevil při testování na hardwaru. Následně byl tedy v implementaci vyřešen pomocí periodického volání funkce MainFunction(), ve které je umístněn čítač a pokud tento překročí určitou hodnotu, je kontrolér restartován. Po zjištění těchto nedostatků a pro umožnění využití v novějších verzích AUTOSAR systému, byl interface implementován také pro verzi 3.1, která byla implementována plně a otestována pomocí unit testů. Navíc byla částečně implementována i verze 4.0, přičemž v této chybí volitelné funkce. Testování na hardwaru proběhlo pouze pro verzi 2.1, neboť pouze pro tuto verzi byly dostupné drivery a ostatní moduly systému AUTOSAR. Dále se při tomto testování objevily některé problémy s ostatními moduly, přičemž největší problém byl se zastavováním absolutního časovače. Toto bylo způsobeno chybným přepínáním registru povolujícím přerušení časovače. Po vyřešení těchto problémů se povedlo ověřit fungování implentace a jeho spolupráce s ostaními moduly. Také byly zjištěny chyby při unit testování. Jednalo se převážně o chyby písemné, které vznikly při tvorbě kódu. 34

42 REFERENCE REFERENCE Reference [1] AUTOSAR. Specification of Diagnostic Communication Manager R2.1. [2] AUTOSAR. Specification of FlexRay Transport Layer R2.1. [3] AUTOSAR. Specification of I-PDU Multiplexer R2.1. [4] AUTOSAR. Specification of Module FlexRay Interface R2.1. [5] AUTOSAR. Specification of PDU Router R2.1. [6] AUTOSAR. Specification of RTE R2.1. [7] AUTOSAR. Specification of the Virtual Functional Bus. [8] AUTOSAR GbR. Layered Software Architecture. [9] AUTOSAR GbR. Methodology R2.1. [10] Gareth Leppla B.Sc. Mapping Requirements to AUTOSAR Software Components. Waterford Institute of Technology, [11] Simon Fürst. AUTOSAR A Worldwide Standard is on the Road. BMW Group. [12] Simon Fürst. AUTOSAR An open standardized software architecture for the automotive industry. BMW, October [13] Infineon Technologies AG. TC1797 Data Sheet R2.1. [14] Robert Bosch GmbH. E-Ray FlexRay IP-Module, User s Manual. 35

43 A PŘÍLOHA KONFIGURACE FLEXRAY INTERFACE A Příloha Konfigurace FlexRay Interface Konfigurace FlexRay Interface není přesně specifikována, je závislá na implementaci. Hlavní konfigurační typ je FrIf ConfigType a obsahuje tyto proměnné: uint8 FrIfNumClusters - v této proměnné je uloženo kolik clusterů Interface ovládá, tedy velikost pole FrIfClustersConfigArray uint8 FrIfNumControllers - v této proměnné je uloženo kolik kontrolérů Interface ovládá, tedy velikost pole FrIfCtrlConfigArray uint16 FrIfNumLPdu - v této proměnné je uloženo kolik LPDU Interface přijímá a odesílá, tedy velikost pole FrIfLPduConfigArray uint16 FrIfNumTxPdu - v této proměnné je uloženo kolik PDU Interface odesílá, tedy velikost pole FrIfTxPduConfigArray uint16 FrIfNumRxPdu - v této proměnné je uloženo kolik PDU Interface přijímá, tedy velikost pole FrIfRxPduConfigArray uint8 FrIfNumDrivers - v této proměnné je uloženo kolik driveru interface ovládá, tedy velikost pole FrIfRxPduConfigArray const FrIf DriverCallbacksType* FrIfDriversArray - ukazatel na pole konfigurace driverů const FrIf ClusterConfigType* FrIfClustersConfigArray - ukazatel na pole konfigurace clusterů const FrIf CtrlConfigType* FrIfCtrlConfigArray - ukazatel na pole konfigurace kontrolérů const FrIf LPduConfigType* FrIfLPduConfigArray - ukazatel na pole konfigurace LPDU const FrIf TxPduType* FrIfTxPduConfigArray - ukazatel na pole konfigurace příchozích PDU const FrIf RxPduType* FrIfRxPduConfigArray - ukazatel na pole konfigurace odchozích PDU uint8 FrIfNumTrcv - v této proměnné je uloženo kolik PDU Interface přijímá, tedy velikost pole FrIfTrcvArray 36

44 A PŘÍLOHA KONFIGURACE FLEXRAY INTERFACE const FrIf TrcvType* FrIfTrcvArray - ukazatel na pole konfigurace transceiverů příklad: CONST(FrIf_ConfigType, FRIF_CONST) FrIf_RunConfig = { 1, /* FrIfNumClusters */ 1, /* FrIfNumControllers */ 2, /* FrIfNumLPdu */ 1, /* FrIfNumTxPdu */ 1, /* FrIfNumRxPdu */ 1, /* FrIfNumDrivers */ FrIf_FrDriverCallback, /* FrIfDriversArray */ RunClst, /* FrIfClustersConfigArray */ FrIf_RunCtrl, /* FrIfCtrlConfigArray */ FrIf_RunLPduConfig, /* FrIfLPduConfigArray */ FrIf_RunTxPduConfig, /* FrIfTxPduConfigArray */ FrIf_RunRxPduConfig, /* FrIfRxPduConfigArray */ 1, /* FrIfNumTrcv */ FrIf_RunTrcv /* FrIfTrcvArray */ }; Dále se budeme zabývat jednotlivými konfiguračními typy. Začneme s FrIf Driver- CallbacksType. Tento typ obsahuje ukazatele na funkce poskytované driverem a na konci je umístěn ukazatel na konfiguraci driveru. Dále je zde datový typ FrIf TrcvType. Tento typ obsahuje pouze ukazatele na funkce transceiver driveru. CONST(FrIf_DriverCallbacksType, FRIF_CONST) FrIf_FrDriverCallback[] = { { Fr_1_ERAY_Init, Fr_1_ERAY_ControllerInit, Fr_1_ERAY_SendMTS, Fr_1_ERAY_StopMTS, Fr_1_ERAY_CheckMTS, Fr_1_ERAY_StartCommunication, Fr_1_ERAY_HaltCommunication, Fr_1_ERAY_AbortCommunication, Fr_1_ERAY_SendWUP, Fr_1_ERAY_SetWakeupChannel, Fr_1_ERAY_SetExtSync, Fr_1_ERAY_GetSyncState, Fr_1_ERAY_GetPOCStatus, Fr_1_ERAY_TransmitTxLPdu, Fr_1_ERAY_ReceiveRxLPdu, Fr_1_ERAY_CheckTxLPduStatus, Fr_1_ERAY_PrepareLPdu, Fr_1_ERAY_GetGlobalTime, 37

45 A PŘÍLOHA KONFIGURACE FLEXRAY INTERFACE } }; Fr_1_ERAY_SetAbsoluteTimer, Fr_1_ERAY_SetRelativeTimer, Fr_1_ERAY_CancelAbsoluteTimer, Fr_1_ERAY_CancelRelativeTimer, Fr_1_ERAY_EnableAbsoluteTimerIRQ, Fr_1_ERAY_EnableRelativeTimerIRQ, Fr_1_ERAY_AckAbsoluteTimerIRQ, Fr_1_ERAY_AckRelativeTimerIRQ, Fr_1_ERAY_DisableAbsoluteTimerIRQ, Fr_1_ERAY_DisableRelativeTimerIRQ, Fr_1_ERAY_GetAbsoluteTimerIRQStatus, Fr_1_ERAY_GetRelativeTimerIRQStatus, (void *) &Fr_1_ERAY_ConfigLayout CONST(FrIf_TrcvCallbacksType, FRIF_CONST) FrIf_FrTrcvDriverCallback[] = { { FrTrcv_1_ERAY_Init, FrTrcv_1_ERAY_SetTransceiverMode, FrTrcv_1_ERAY_GetTransceiverMode, FrTrcv_1_ERAY_GetTransceiverWUReason, FrTrcv_1_ERAY_DisableTransceiverWakeup, FrTrcv_1_ERAY_EnableTransceiverWakeup, FrTrcv_1_ERAY_ClearTransceiverWakeup } }; Dalšími datovými typy jsou: FrIf ClusterConfigType - obsahuje nastavení clusteru uint32 FrIfMaxIsrDelay - udává maximální možné zpoždění přerušení absolute timeru, po překročení dojde k vypnutí přerušení do doby než dojde k resynchronizaci funkcí MainFunction() uint16 FrIfGMacroPerCycle - počet makrotiků v komunikačním cyklu uint32 FrIfGdMacrotick - doba trvání makrotiku v nanosekundách uint8 FrIfCtrl - počet kontrolérů patřících do clusteru const uint8* FrIfCtrl - pole indexů na konfiguraci kontrolérů patřících do clusteru z pole FrIfCtrlConfigArray const FrIf JobListType* FrIfJobList - ukazatel na pole obsahující joby 38

46 A PŘÍLOHA KONFIGURACE FLEXRAY INTERFACE uint32 FrIfSafetyMargin - mezera v makroticích potřebná při resynchronizaci ukazatele na joblist funkcí FrIf MainFunction() zajištující dostatečně dlouhou dobu umožňující nastavení absolute timeru atd. Přičte se k aktuálnímu času a vybere se job se stejným nebo pozdějším časem CONST(FrIf_ClusterConfigType, FRIF_CONST) RunClst[] = { { 20, /* FrIfMaxIsrDelay */ 5000, /* FrIfGMacroPerCycle */ 1540, /* FrIfGdMacrotick */ 1, /* FrIfCtrl */ (uint8[]){0}, /* FrIfCtrl */ &RunJobLists[0], /* FrIfJobList */ 10 /* FrIfSafetyMargin */ } }; FrIf CtrlConfigType - obsahuje konfiguraci kontrolérů uint8 FrIfFrCtrlIdx - v této proměnné je uložen index kontroléru, který je předáván driveru uint8 FrIfNumTrcv - obsahuje počet transceiverů používaných kontrolérem, obsahuje tedy velikost pole FrIfTrcv uint8 FrIfClst - obsahuje index konfigurace clusteru v poli FrIfClustersConfigArray, do kterého kontrolér patří uint8 FrIfStartUpTimeOut - obsahuje dobu, po kterou může kontrolér zůstat ve start up či wake up stavu, tato je udána v počtu volání MainFunction Fr ChannelType FrIfChnlIdx - obsahuje informaci o kanálech, na kterých kontrolér komunikuje uint8 FrIfTrcv - pole indexů na konfiguraci transceiverů v poli FrIfTrcvArray, pomocí kterých kontrolér komunikuje FrIf DriverCallbacksType FrIfCtrlDriver - ukazatel na konfiguraci driveru, tedy na prvek z pole FrIfDriversArray uint16 FrIfNumLPdu - obsahuje množství LPDU, které kontrolér přijímá či odesílá uint8 FrIfNumRelTimer - obsahuje počet relativních timerů, které kontrolér ovládá uint8 FrIfNumAbsTimer - obsahuje počet absolutních timerů, které kontrolér ovládá 39

47 A PŘÍLOHA KONFIGURACE FLEXRAY INTERFACE uint16 FrIfLPdu - obsahuje pole indexů na konfiguraci LPDU z pole FrIfLPduConfigArray CONST(FrIf_CtrlConfigType, FRIF_CONST) FrIf_RunCtrl[] = { { 0, /* FrIfFrCtrlIdx */ 1, /* FrIfNumTrcv */ 0, /* FrIfClst */ 2, /* FrIfStartUpTimeOut */ FR_CHANNEL_A, /* FrIfChnlIdx */ FrIf_RunTrcv, /* FrIfTrcv */ &FrIf_FrDriverCallback[0], /* FrIfCtrlDriver */ 1, /* FrIfNumLPdu */ 0, /* FrIfNumRelTimer */ 1, /* FrIfNumAbsTimer */ (uint16[]){0} /* FrIfLPdu */ } }; FrIf TrcvType - obsahuje nastavení transceiveru uint8 FrIfFrTrcvIdx - index trasceiveru předávaný ovladači transceiveru FrIf TrcvChannelType FrIfChnlIdx - index kanálu, na který je transceiver připojen const FrIf TrcvCallbacksType* FrIfFrTrcvDriver - ukazatel na nastavení driveru transceiveru CONST(FrIf_TrcvType, FRIF_CONST) FrIf_RunTrcv[] = { { 1, /* FrIfFrTrcvIdx */ FR_TRCV_CHANNEL_A, /* FrIfChnlIdx */ FrIf_FrTrcvDriverCallback, /* FrIfFrTrcvDriver */ } } FrIf TxPduType - obsahuje konfiguraci jednotlivých odesílaných Pdu PduIdType PduId - identifikátor Pdu předávaný nadřazenými vrstvami interfacu boolean FrIfConfirm - označuje, zda je třeba potvrzovat odeslání uint8 FrIfCounterLimit- maximální možný počet požadavků na přenos/potvrzení přenosu boolean FrIfImmediate - označuje, zda se má ihned zavolat Fr Transmit() 40

48 A PŘÍLOHA KONFIGURACE FLEXRAY INTERFACE boolean FrIfNoneMode - označuje, zda volat funkci TriggerTransmit, i když není požadavek na přenos FrIf UserULType FrIfUserTxUL - obsahuje majitele Pdu const FrIf UpperLayerTxCallbacksType* FrIfULTxCallbacks - ukazatel na majitele Pdu (pokud není majitel standardní modul Pdu), tedy je v předchozí proměnné hodnota CDD uint8 FrIfPayload - velikost Pdu v bytech uint8 FrIfLPdu - index nastavení LPdu z pole FrIfLPduConfigArray, do kterého Pdu patří CONST(FrIf_TxPduType, FRIF_CONST)FrIf_RunTxPduConfig[] = { { 1, /* PduId */ TRUE, /* FrIfConfirm */ 3, /* FrIfCounterLimit */ FALSE, /* FrIfImmediate */ TRUE, /* FrIfNoneMode */ FR_TP, /* FrIfUserTxUL */ NULL_PTR, /* FrIfULTxCallbacks */ 8, /* FrIfPayload */ 1 /* FrIfLPdu */ } }; FrIf RxPduType - obsahuje konfiguraci jednotlivých přijímaných Pdu PduIdType PduId - identifikátor Pdu předávaný nadřazeným vrstvám FrIf UserULType FrIfUserRxIndicationUL - obsahuje majitele Pdu FrIf UpperLayerRxCallbacksType FrIfULRxCallbacks - ukazatel na majitele Pdu (pokud není majitel standardní modul Pdu), tedy je v předchozí proměnné hodnota CDD uint8 FrIfPayload - velikost Pdu v bytech CONST(FrIf_RxPduType, FRIF_CONST)FrIf_RunRxPduConfig[] = { { 6, /* PduId */ FR_NM, /* FrIfUserRxIndicationUL */ NULL_PTR, /* FrIfULRxCallbacks */ 8 /* FrIfPayload */ } } 41

49 A PŘÍLOHA KONFIGURACE FLEXRAY INTERFACE FrIf PduType - sjednocuje odesílaná a přijímaná Pdu do jednoho typu boolean FrIfTxPdu - označuje, zda je Pdu odchozí (TRUE) či příchozí (FALSE) uint16 FrIfPduIdx - index Pdu z pole FrIfTxPduConfigArray, pokud je předchozí proměnná TRUE nebo z pole FrIfRxPduConfigArray, pokud je FALSE CONST(FrIf_PduType, FRIF_CONST)FrIf_RunPduConfig[] = { { FALSE, /* FrIfTxPdu */ 0 /* FrIfPduIdx */ }, { TRUE, /* FrIfTxPdu */ 0 /* FrIfPduIdx */ } }; FrIf PdusInFrameType - obsahuje nastavení pozice Pdu uvnitř LPdu: uint8 FrIfPduOffset - obsahuje offset Pdu uvnitř LPdu v bytech const uint16* FrIfPduUpdateBitOffset - offset UpdateBitu v bitech const FrIf PduType* Pdu - ukazatel na nastavení Pdu FrIf FrameStructureType - spojuje dohromady všechna Pdu obsažená v LPdu do jednoho kontejneru uint8 FrIfNumPduInFrame - udává počet Pdu uložených v LPdu, tedy velikost pole FrIfPdusInFrame const FrIf PdusInFrameType* FrIfPdusInFrame - ukazatel na pole konfigurací Pdu CONST(FrIf_FrameStructureType, FRIF_CONST)FrIf_RunFrameStructureConfig[] = { { 1, /* FrIfNumPduInFrame */ (FrIf_PdusInFrameType[]) /* FrIfPdusInFrame */ { { 1, /* FrIfPduOffset */ (uint16[]){0}, /* FrIfPduUpdateBitOffset */ &FrIf_RunPduConfig[0] /* Pdu */ } } }, 42

50 A PŘÍLOHA KONFIGURACE FLEXRAY INTERFACE }; { } 1, /* FrIfNumPduInFrame */ (FrIf_PdusInFrameType[]) /* FrIfPdusInFrame */ { { 1, /* FrIfPduOffset */ (uint16[]){0}, /* FrIfPduUpdateBitOffset */ &FrIf_RunPduConfig[1] /* Pdu */ } } FrIf FrameTriggType - obsahuje informace o vlastnostech LPdu boolean FrIfAllowDynamicLSduLength - povoluje dynamické zkracování LPdu boolean FrIfAlwaysTransmit - zda se má LPdu odeslat, i když není žádný požadavek na přenos uint8 FrIfLSduLength - délka LPdu v bytech const FrIf FrameStructureType FrIfFrameStructure - ukazatel na rozložení Pdu v LPdu CONST(FrIf_FrameTriggType, FRIF_CONST)FrIf_RunFrameTriggConfig[] = { { FALSE, /* FrIfAllowDynamicLSduLength */ FALSE, /* FrIfAlwaysTransmit */ 16, /* FrIfLSduLength */ &FrIf_RunFrameStructureConfig[0] /* FrIfFrameStructure */ }, { FALSE, /* FrIfAllowDynamicLSduLength */ FALSE, /* FrIfAlwaysTransmit */ 16, /* FrIfLSduLength */ &FrIf_RunFrameStructureConfig[1] /* FrIfFrameStructure */ } }; FrIf LPduConfigType - obsahuje odesílací respektive přijímací informace o LPdu uint16 FrIfFrLpduIdx - identifikátor LPdu (virtual bufferu) předávaný driveru uint8 FrIfCtrl - index konfigurace kontroléru z pole FrIfCtrlConfigArray, přes který je LPdu odesíláno či přijímáno 43

51 A PŘÍLOHA KONFIGURACE FLEXRAY INTERFACE const FrIf FrameTriggType* FrIfVBTriggering - ukazatel na konfiguraci spouštění LPdu CONST(FrIf_LPduConfigType, FRIF_CONST)FrIf_RunLPduConfig[] = { { 0, /* FrIfFrLpduIdx */ 0, /* FrIfCtrl */ &FrIf_RunFrameTriggConfig[0] /* FrIfVBTriggering */ }, { 1, /* FrIfFrLpduIdx */ 0, /* FrIfCtrl */ &FrIf_RunFrameTriggConfig[1] /* FrIfVBTriggering */ } }; FrIf CommunicationOperationType - obsahuje nastavení komunikační akce FrIf CommActionType FrIfCommunicationAction - komunikační akce uint16 LPdu - index konfigurace LPdu z pole FrIfLPduConfigArray FrIf JobType - obsahuje informace o jednotlivých jobech uint8 FrIfCycle - komunikační cyklus, ve kterém se má akce provést uint32 FrIfOffsetMacrotick - makrotik, ve kterém se má akce spustit uint8 FrIfNumComOperation - počet operací, které se mají v daný čas spustit, tedy počet operací v poli FrIfCommOperation const FrIf CommunicationOperationType* FrIfCommOperation - pole komunikačních akcí spouštěných v daný okamžik CONST(FrIf_JobType, FRIF_CONST) RunJobsClst[] = { { 0, /* FrIfCycle */ 3750, /* FrIfOffsetMacrotick */ 1, /* FrIfNumComOperation */ (FrIf_CommunicationOperationType[]) /* FrIfCommOperation */ { { RECEIVE_AND_INDICATE, /* FrIfCommunicationAction */ 0 /* LPdu */ } } 44

52 A PŘÍLOHA KONFIGURACE FLEXRAY INTERFACE } }, { } 0, /* FrIfCycle */ 4750, /* FrIfOffsetMacrotick */ 2, /* FrIfNumComOperation */ (FrIf_CommunicationOperationType[]) /* FrIfCommOperation */ { { TX_CONFIRMATION, /* FrIfCommunicationAction */ 1 /* LPdu */ }, { DECOUPLED_TRANSMISSION, /* FrIfCommunicationAction */ 1 /* LPdu */ } } FrIf JobListType - spojuje dohromady všechny joby jednoho clusteru uint8 FrIfCtrlAbsTimerIdx - index konfigurace kontroléru z pole FrIfCtrlConfigArray ovládající absolute timer uint8 FrIfAbsTimerIdx - index absolute timeru, který se stará o spouštění komunikačních akcí uint16 FrIfNumJobs - počet jobů v joblistu, tedy velikost pole FrIfJob const FrIf JobType* FrIfJob - ukazatel na pole jobů CONST(FrIf_JobListType, FRIF_CONST) RunJobLists [] = { { 0, /* FrIfCtrlAbsTimerIdx */ 0, /* FrIfAbsTimerIdx */ 2, /* FrIfNumJobs */ RunJobsClst /* FrIfJob */ } }; 45

53 A PŘÍLOHA KONFIGURACE FLEXRAY INTERFACE 46