AUTOSAR Az autóipari beágyazott szoftverek bonyolultságának növekedésével egyre nagyobb problémát jelentett a szoftverek hatékony specifikálása, implementálása, tesztelése, és integrálása. Az autógyártók saját platform szoftver csomagokat (standard core) hoztak létre az általános funkciók (kommunikáció, diagnosztika, kalibrálás, szoftver letöltés) megvalósítására. Ez egyrészt az autógyártók részéről jelentős fejlesztési és támogatási erőforrásokat igényelt, másrészt a beszállítók oldalán szükségessé vált a megfelelő tudás felépítése minden partner autógyártó rendszerével kapcsolatban. Ezen plusz költségekért cserébe, viszont egy biztosan jól működő alapfunkcionalitást (kommunikáció, diagnosztika kalibrálás...) kapnak minden beszállítótól. A hatékonyság növelésére a szabványosítást tartották a legmegfelelőbb megoldásnak, ezért 2002-ben 7 európai autógyártó, illetve beszállító megalapította az AUTOSAR (AUTomotive Open Systems ARchitecture) konzorciumot. Az egyesülés célja a beágyazott szoftver architektúra, illetve a szoftver modellezési és integrációs technológia egységesítése volt. Jelenleg a konzorcium több száz taggal rendelkezik, melyek között megtalálhatóak a legfontosabb autógyártók, beszállítók, eszköz fejlesztők, és félvezetőgyártók is. A kezdeti egyértelmű európai dominancia máig megmaradt a szervezetben, de már az észak-amerikai cégek is élénken érdeklődnek az AUTOSAR eredményei iránt. Ázsiában az AUTOSAR mellett a japán JASPAR (Japan Automotive Software Platform and Architecture) kezdeményezést is használják.
Az AUTOSAR szabvány elemei Az AUTOSAR szabvány [7] három fő célt jelölt ki, melyekhez különböző specifikációkat dolgoztak ki: 1. Szabványos platform architektúra. a. Kidolgozták a platform (Basic Software – BSW) felosztását modulokra b. Specifikálták a modulok interfészeit c. Specifikálták a modulok által megvalósítandó funkciókat 2. Modell-alapú szoftverfejlesztés a. Kidolgoztak egy szabványos modellező nyelvet (és egy szabványos adatcsere-formátumot) a szoftver komponensek, hardver elemek, és konfigurációjuk modellezésére b. Specifikáltak egy automatikus kódgeneráló megoldást a szoftver komponensek integrálására (Runtime Environment – RTE) 3. Megfelelőségi vizsgálat a. Kidolgoztak egy tesztkészletet és teszt folyamatot az egyes szoftver elemek AUTOSAR szabványnak való megfelelőségének a vizsgálatára.
AUTOSAR Platform Az AUTOSAR szabvány egy rétegezett szoftver architektúrát határoz meg az egyes ECU-k számára. A három fő réteg (lásd 26. ábra) az alkalmazási réteg, ahol a funkció specifikus szoftver elemek találhatóak, a Runtime Environment (RTE), mely a szoftver komponensek közötti integrációt és kommunikációt valósítja meg, és a platform (Basic Software), mely az alapvető funkciókat (kommunikáció, I/O kezelés, stb.) valósítja meg. Utóbbi réteget további részekre oszthatjuk. A kontroller absztrakciós réteg (Microcontroller Abstraction Layer – MCAL) feladata az alkalmazott mikrokontroller
elfedése, alacsony szintű meghajtók segítségével. Ezáltal a felsőbb rétegek nem függenek a perifériák megvalósításától és hordozhatóvá válnak különböző kontroller platformok között. Az ECU absztrakciós réteg (ECU Abstraction Layer) feladata hasonló, de magasabb szinten. Ez a réteg elfedi az ECU specifikus I/O kezelést, ennek segítségével a felsőbb rétegek nem csak a mikrokontrollertől, hanem az ECU hardvertől is függetlenek lehetnek, a konkrét ECU konfiguráció csak ebben a rétegben tükröződik (például melyik I/O lábra van kötve egy külső alkatrész, melyik A/D csatornán kell mérni egy jelet, stb.). A szolgáltatási rétegben (Services Layer) találhatóak azon modulok, melyek magas szintű szolgáltatásokat nyújtanak az alkalmazás számára. Ilyenek például az operációs rendszer, a távoli diagnosztika, vagy a magas szintű kommunikációs szolgáltatások. Végül, a komplex eszközmeghajtók (complex device drivers) olyan speciális, általában alkalmazás-specifikus modulok, melyek közvetlenül elérik a hardvert, másrészről közvetlenül kapcsolódnak az alkalmazáshoz is. Ezek a modulok olyan időkritikus, egyedi funkcionalitást valósítanak meg, ami nem érhető el a szabványok meghajtókon keresztül, vagy az időzítések miatt nincs lehetőség a szabványos, rétegezett implementációra.
Application Layer
Runtime Environment Services Layer
ECU Abstraction Layer
Complex Drivers
Microcontroller Abstraction Layer
Microcontroller
26. ábra Az AUTOSAR szoftver architektúra A továbbiakban részletesebben megvizsgáljuk a platform által nyújtott funkciókat.
Mikrokontroller absztrakciós réteg Microcontroller Drivers
Memory Drivers
Communication Drivers
PORT Driver
DIO Driver
ADC Driver
PWM Driver
ICU Driver
Ethernet Drive
FlexRay Driver
CAN Driver
LIN Driver
SPI Handler Driver
DIO
ADC
PWM
CCU
CAN
SPI
LIN or SCI
internal EEPROM Driver
EEPRO M
FLASH
internal Flash Driver
RAM Test
Flash Test
Core Test
WDT
MCU Driver
Watchdog Driver
GPT
MCU Power & Clock Unit
GPT Driver
Microcontroller
I/O Drivers
27. ábra A Mikrokontroller Absztrakciós réteg Ebben a rétegben alacsony szintű, a mikrokontroller perifériáit kezelő eszközmeghajtókat találhatunk. A réteg fő célja az alacsony szintű perifériák kezelése, és egy hardver független interfész biztosítása a felsőbb szoftver rétegek számára.
I/O periféria meghajtók Az I/O driver csoportba soroljuk az egyszerű ki/bemeneti perifériákat kezelő modulokat. A Port modul felelős a kontroller portjainak (lábainak) beállításáért. A rendszer indulásakor felkonfigurálja a lábakat (funkció és irány választás, felhúzó/lehúzó ellenállások, stb.), és lehetőséget ad a futásidőbeli átkonfigurálásra is bizonyos megszorításokkal. A DIO modul segítségével érhetjük el az általános digitális ki- vagy bementként konfigurált lábakat (GPIO). Az ADC driver modul az analóg-digitális átalakítók konfigurációját támogatja, és segítségével lehet hozzáférni a konverzió eredményéhez is. A PWM driver impulzusszélesség-modulált kimeneti perifériákat kezel, melyeket általában különböző külső egységek (például villamos motorok) szabályozására használunk. Az ICU (Input Capture Unit) meghajtó modul biztosít hozzáférést a bemeneti mintavételező (input capture) perifériákhoz. Ezek segítségével különböző impulzusok, élek detektálhatóak, illetve ezek időtartama vagy periódusideje mérhető.
Kommunikációs vezérlő meghajtók A kommunikációs vezérlő meghajtók (communication drivers) csoportba soroljuk az összes, a mikrokontrollerben megvalósított kommunikációs periféria meghajtó modulját. Az Autosar szabvány a leggyakrabban használt autóipari protokollhoz specifikál meghajtókat: ilyen a CAN, LIN, FlexRay, SPI, és az Ethernet. Az első három protokollal már megismerkedtünk, az SPI pedig az általános szinkron soros interfészt jelöli. Az Ethernet meghajtó a szabvány újabb (4.0-ás) változatában jelent meg, mivel egyre jobban terjed ez a – más alkalmazási területeken már bizonyított – protokoll. Az Ethernet alapú kommunikáció jelenleg főleg a szerviz diagnosztikai interfészen jellemző, de várhatóan újabb és újabb alkalmazási területeket fog meghódítani a
jövőben, mivel sávszélessége (akár 1Gbps) messze felülmúlja a többi hálózati megoldásét. Az Autosar eszközmeghajtók alacsony szintű, de hardver független interfészt biztosítanak a felsőbb rétegek számára a kommunikációs egységek kezelésére.
Memória meghajtók Ebbe a csoportba soroljuk a belső memória egységek meghajtó programjait. Egy-egy külön modul valósítja meg a belső Flash és EEPROM memóriák alacsony szintű kezeléséhez szükséges funkcionalitást. Két modul (RamTest és FlashTest) pedig a RAM illetve Flash memóriák futásidejű teszteléséért felelős.
Mikrokontroller meghajtók Ebbe a csoportba tartoznak a mikrokontroller alapvető egységeit kezelő modulok. Az Mcu meghajtó felelős a kontroller órajelének, a perifériák energiaellátásának, a hardver megszakítások beállításáért, és az alacsony energia módok kezeléséért. A Watchdog meghajtó a kontroller belső felügyeleti egységét kezeli, melynek feladata a processzor vagy a szoftver hibája esetén a rendszer újraindítása. A GPT meghajtó (general purpose timers), a minden kontrollerben általános célú számlálók elérését támogatja. Ezek segítségével különböző időzítési feladatokat lehet megoldani. A Core test modul feladata a kontroller alapvető egységeinek futás idejű tesztelése.
Vezérlőegység absztrakciós réteg Ennek a rétegnek (ECU abstraction layer) a feladata a vezérlőegység specifikus hardver tulajdonságok elrejtése a felsőbb szoftver rétegek elől. Ilyen például a kommunikációs kontrollerek száma és típusa, a különböző I/O vonalak konkrét megvalósítása, illetve az egyes szenzorok és beavatkozók csatlakoztatási módja. Ezek a modulok felhasználás-specifikusak, ezért az Autosar szabvány nem definiálja őket. Kifejlesztésük az adott vezérlőegység fejlesztőinek a feladata.
I/O Hardver Absztrakció Ebbe a csoportba tartoznak azon szoftver modulok, melyek a ki-/bemeneti eszközök elhelyezkedését és konkrét megvalósítását rejtik el a felső rétegek elől. Ezen modulok vezérlőegység függőek, felső interfészük pedig AUTOSAR interfész (lásd később), amivel az alkalmazás szintű szoftver komponensekkel közvetlenül tudnak kommunikálni.
Kommunikációs Hardver Absztrakció Ebbe a csoportba tartoznak azok a modulok, melyek a különböző kommunikációs hardver elemek elhelyezkedését és típusát rejtik el a felsőbb rétegek elől. Például, ha a mikrokontrollerben két CAN csatorna van, és ezen kívül egy külső CAN kontrollert is beépítenek a vezérlőegységbe, ezekhez két különböző eszközmeghajtó tartozik. Ezeket a CAN Interface modul kezeli, és annak felhasználói már három egyforma, logikai CAN vezérlőt fognak látni. Minden eszköz-specifikus kommunikációt eltakarnak az alsó rétegek. Ebben a rétegben minden hálózati protokollhoz (CAN, LIN, Ethernet, FlexRay) található egy Interfész modul, mely a fenti példában is látható kontroller absztrakciót valósítja meg. Ezen kívül található még buszmeghajtó típusonként egy transceiver
meghajtó modul is, melyek az adott buszmeghajtó hardver kezelését végzik (pl. CanTrcv, FrTrcv). A felsőbb rétegek a buszmeghajtókat is az adott protokollhoz tartozó interfész modulon keresztül érik el.
Memória hardver absztrakció
28. ábra Memória hardver absztrakciós réteg A memória hardver absztrakciós réteg feladata a nem felejtő memória (Flash, EEPROM) elemek implementációs részleteinek (külső/belső, csatlakozás módja, technológia) elrejtése. A felsőbb réteg felé már absztrakt memória elemekként prezentálja a hardver elemeket. A felsőbb szintű API lehetőséget ad a memóriákban egy-egy blokk törlésére, írására, olvasására. Az külső EEPROM meghajtó (external EEPROM driver) modul feladata a külső EEPROM perifériák illesztése. Ebből a modulból EEPROM típusonként egy van. Az EEPROM absztrakciós modul a különböző EEPROM meghajtókat fogja össze, illetve a fizikai címtartományokat logikai tartományokra képezi le. A külső Flash meghajtó (external flash driver) modul a külső flash memóriákat illeszti a rendszerhez, míg a flash EEPROM emulációs modul feladata egy EEPROM eszköz emulálása a flash fizikai eszközökön. Ismeretes, hogy a Flash memóriák csak nagyobb egységekben (lapok) törölhetőek, és a törlés/írás ciklusok száma korlátozott. A korlátozás kikerülésére az Autosar flash EEPROM megoldása a Flash lapokra folytonosan írja fel a mentendő adatokat (tehát nem egy adott adatot egy adott címre), olvasáskor pedig a felírt adatrekordok közül keresi ki egy adatelem utolsó változatát. A lenti ábrán egy példa látható. Az 1. számú blokkot két változatban írtuk már ki (olvasáskor automatikusan a 2-es számút kapjuk vissza), a 2-es és 3-as blokkot pedig egy példányban.
29. ábra: Flash EEPROM emuláció Ha egy Flash szektor (több lap, tipikusan 4-16kB) megtelt, az utolsó érvényes adatokat egy új szektorba másolja, és az előzőt törli. A szektorok méretének és számának megfelelő megválasztásával elérhető, hogy a fizikai memória írási ciklus korlátját ne lépjük át. A memória absztrakció interfész feladata az EEPROM és Flash memóriák különbségeinek elrejtése, a felsőbb rétegek felé csak absztrakt memória eszközöket mutatva.
Belső eszköz absztrakció Ebbe a csoportba (onboard device abstraction) a mikrokontroller alapvető egységeinek absztrakciós moduljai tartoznak. Jelenleg a watchdog interfészt és a külső watchdog meghajtókat definiálja a szabvány. A külső meghajtó a processzoron kívüli watchdog áramkörökkel való kapcsolattartást valósítja meg, míg az interfész az összes (külső és belső) watchdog eszközhöz valósít megy egy általános interfészt.
Kommunikációs szolgáltatások
30. Kommunikációs szolgáltatások A kommunikációs szolgáltatások közé a hálózati kommunikációval kapcsolatos, magas szintű modulok tartoznak.
A PDU útválasztó (router) a réteg központi komponense. Feladata az alsóbb rétegből (a különböző hálózati interfész moduloktól) érkező adatelemek (PDU – protocol data unit) továbbítása. Ehhez egy belső útválasztó táblát (routing table) használ, mely statikus, tehát futási időben nem változik. Egy PDU-nak egy vagy több cél modulja lehet, akár arra is van lehetőség, hogy egy, a hálózaton keresztül érkezett PDU-t egy másik hálózat felé továbbítsunk (ez az úgynevezett gateway, vagy átjáró funkció). Természetesen a PDU útválasztó a felső szintű moduloktól érkező PDU-k továbbküldéséért is felelős. A PDU útválasztó és a hálózati interfész közé ékelődik a (szintén minden protokollhoz külön létező) átviteli protokoll (transport protocol) modul. Ezen modulok feladata a nagyobb – a hálózaton egyben nem továbbítható – PDU-k szétdarabolása, majd a cél egységen a darabok összeillesztése. Ezen modulok felső interfésze a PDU útválasztóhoz kapcsolódik. Az IPDU multiplexer segítségével a ritkán használt PDU-kat lehet multiplexálni, azaz az alsóbb szintek számára egyetlen PDU-ként küldeni és fogadni. A multiplexálás során a modul egy azonosítót illeszt az adattartalomhoz, mely a beágyazott PDU-t azonosítja a vevő számára. Vételkor az azonosító alapján csomagolja ki a PDU-t. A legfelsőbb szintű adatkommunikációs modul a Com. Feladata a konkrét adatértékek kicsomagolása a PDU-kból, és az értékek eljuttatása az alkalmazáshoz. Küldés irányban az értékekből (jelekből – signal) PDU-kat épít, majd ezeket adott ütemezéssel elküldi a hálózati réteg felé. A diagnosztikai kommunikáció menedzser (diagnostic communication manager) modul feladata a szabványos távdiagnosztikai protokollok (UDS, OBD, lásd később) megvalósítása. Ezen modulon keresztül lehet például a szoftver hibanaplóhoz hozzáférni, különböző teszteket lefuttatni, vagy szoftverfrissítést kezdeményezni. A nyomkövetés (debugging) modul egy fejlesztési időben használatos funkciót valósít meg: lehetőséget ad különböző szoftver események, illetve változó értékek naplózására, majd ezek kommunikációs hálózaton keresztüli kiolvasására. A protokoll specifikus állapot menedzsment (state manager) modulok felelősek az adott kommunikációs verem állapotának (kommunikációs, csendes kommunikáció, kikapcsolt állapot) nyilvántartásáért, illetve az állapot-átmenetek megvalósításért. A hálózat-menedzsment (network management) modulok két szinten kerültek megvalósításra. Minden protokollhoz létezik egy protokoll-specifikus modul (például Can network management), és ezeket egy absztrakt interfész fogja össze. Ezen modulok feladata a hálózatok energia-menedzsmentje. Olyan elosztott algoritmust valósítanak meg, mely lehetővé teszi a vezérlőegységek koordinált ki- és bekapcsolását, akár több hálózat együttműködésével is. Ezáltal megvalósítható a jármű különböző üzemmódjainak kezelése (például egy elektromos autó töltésekor a használaton kívüli vezérlőegységek alacsony energiájú állapotba kerülnek).
Memória szolgáltatások Ebbe a kategóriába egyetlen modul tartozik, az NvM (non-volatile memory manager). Ennek feladata - a memória interfész felhasználásával -, hogy az alkalmazás számára egy magas szintű API-t nyújtson a perzisztencia szolgáltatáshoz. A hozzáférés egysége a blokk, mely az alkalmazás egy változójának felel meg. Minden blokkhoz (konfigurációtól függően) elérhetőek a következő műveletek: a) írás a RAM-ból a perzisztens tárba b) visszaolvasás, c) törlés. Az alkalmazás komponensek közvetlenül az NvM modult használják a funkciók meghívásakor.
Rendszerszolgáltatások
31. ábra. Rendszerszolgáltatások A rendszerszolgáltatások (system services) csoportba a különböző, magas szinten is használt platform szolgáltatásokat nyújtó modulok tartoznak. Az Autosar operációs rendszer (Os) egy beágyazott, valós-idejű operációs rendszer, mely prioritás alapú több feladatos környezetet biztosít az alkalmazások és a BSW modulok futtatásához. Alapja az OSEK operációs rendszer szabványa, melyet az Autosar kiegészített néhány funkcióval, mint például a többmagos processzorok támogatása, illetve a statikus ütemező táblák megvalósítása. A vezérlőegység állapot menedzser (ECU state manager) modul feladata a rendszer indulásakor, kikapcsolásakor, és alvó állapotba kapcsolásakor a BSW modulok és az alkalmazás inicializálása, az operációs rendszer és az RTE elindítása. Ez a modul határozza meg azt is, hogy a processzor felébredése milyen esemény hatására történt, és ennek megfelelően reagál a különböző modulok értesítésén keresztül. A kommunikáció menedzser (Communication manager) feladata a vezérlőegység kommunikációs interfészeinek ki- és bekapcsolása, összhangban az alkalmazás igényeivel, illetve a vezérlőegység állapot-változásaival. A diagnosztikai esemény menedzser (Diagnostic Event Manager) fogadja a futási idejű hibajelentéseket az alkalmazástól és a platform moduloktól. Elvégzi ezek
szűrését, összegyűjti a különböző diagnosztikai adatokat, és megvalósítja az eseményinformációk perzisztens tárolását. Ezen információkat távdiagnosztikával lehet később kiolvasni. A funkció engedélyezés menedzser (function inhibition manager) feladata a diagnosztikai események figyelése, és bizonyos események, vagy esemény kombinációk észlelése esetén egyes alkalmazás funkciók letiltása. Például, ha egy ablakvezérlő szoftver hibát jelez a becsípődés-gátló szenzorban, az automatikus ablakemelő funkciót le kell tiltani, mivel nem lehet detektálni a tárgyak vagy élőlények becsípődését. A letiltás nem jár alkalmazás módosítással, vagy üzenetküldéssel, az alkalmazásnak a funkció végrehajtása előtt le kell lekérdezni a funkció engedélyezési állapotát. A fejlesztési hibakövető (development error tracer) modul egy hibanapló, mely a fejlesztési idejű hibákat gyűjti. Ilyen hibák következhetnek például nem-inicializált modulok használatából, helytelen azonosítók használatából, stb. Minden BSW modulban ki vagy be lehet kapcsolni az ilyen jellegű hibák kezelését, és bekapcsolt állapotban a hibakövető modulnak küldenek hibajelentéseket. Miután a rendszer kódja és konfigurációja elég éretté válik, a funkció kikapcsolható, amivel jelentős futási időt és memória használatot lehet nyerni. A diagnosztikai napló és követés (Diagnostic Log and Trace) modul általános diagnosztikai napló funkciót valósít meg. Felhasználói az alkalmazási komponensek, az RTE, a DEM és DET modulok lehetnek. A napló tartalmát a DCM modulon keresztül, egy külső diagnosztikai egységgel lehet kiolvasni. A szinkronizált időalap menedzser (synchronized time base manager) feladata a globális időhöz való hozzáférés biztosítása a többi modul számára. Az információ felhasználható bizonyos funkciók szinkron futtatására egy hálózatos rendszerben, vagy időbélyegzésre, illetve időtartam-mérésre. A globális idő forrása általában valamilyen kommunikációs alrendszer (például a korábban már tárgyalt FlexRay). A modul az idő értékén kívül azt is képes jelezni, ha a globális idő szinkronizálása valamiért nem lehetséges, illetve ha helyreáll. A platform szoftver üzemmód menedzser (BSW Mode manager) modul egy széleskörűen konfigurálható állapotgépet valósít meg. Számos bemenetén keresztül gyűjti a platform és az alkalmazás állapotára vonatkozó információt (például a vezérlőegység aktuális üzemmódja, a kommunikáció állapota), és az állapotokra vonatkozó (a rendszerintegrátor által meghatározott) logikai kifejezéseket értékel ki. A kifejezések értékének (igaz/hamis) vagy annak változásának függvényében pedig akció listákat – üzemmód váltásra, kommunikáció indításra vagy leállításra, stb vonatkozó parancsokat – hajt végre.
Szabványos függvénykönyvtárak A rendszerszolgáltatások csoportjához kapcsolódik néhány szabványos függvénykönyvtár. A könyvtáraknak nincs önálló állapotuk, használatuk egyszerű, és mind a platform mind az alkalmazás szintjéről elérhetőek. A következő könyvtárakat definiálja a jelenlegi szabvány: • Crc: Különböző ellenőrző-összeg számító rutinok gyűjteménye • E2ELibrary (End-to-end protection library): A kommunikációs csatornákon küldött adatokhoz lehet redundáns információt (ellenőrző kódot, üzenetszámlálót) csatolni a megvalósított függvények segítségével, illetve ellenőrizni lehet ezeket a fogadó oldalon • BFX: Különböző bitmanipulációs funkciókat valósít meg (bitek beállítása, törlése, tesztelése; bitmaszkok létrehozása)
CAL (Crypto Abstraction Library): Rejtjelezéssel és digitális aláírással kapcsolatos funkciókat valósít meg. • EFX: Egész számokon végzett komplex algoritmusokat valósít meg, mint a különböző szűrők, mozgóátlag számítás, és a különböző trigonometriai függvények • IFL: Lebegőpontos interpolációs függvényeket valósít meg. • IFX: Fixpontos interpolációs függvényeket valósít meg. • MFL: Lebegőpontos matematikai rutinok gyűjteménye (PI szabályzó, limitálás, logaritmus, stb.) • MFX: Fixpontos matematikai rutinok gyűjteménye A szabványos könyvtárak használatával lehetővé válik az egyes funkciók egyetlen helyen történő implementálása. Ez megkönnyíti ezek cseréjét, hogy mindig az adott cél kontrolleren legjobb implementációt választhassuk. Például a CRC vagy digitális aláírás funkcióhoz gyakran ad hardver támogatást a mikrokontroller, amit az arra optimalizált megvalósítással ki lehet használni. •
A kommunikációs verem részletei
32. ábra A FlexRay kommunikációs verem Példaképpen tekintsük át a FlexRay kommunikáció folyamatát. A fenti ábrán két kommunikációs vezérlő (egy belső, és egy külső), valamint két (egyforma) buszmeghajtó látható. Mindegyik eszközt ugyanaz a kontroller vezérli. A hálózaton érkező üzeneteket az Autosar kereteknek (frame), vagy L-PDU-nak (Data link layer PDU – adatkapcsolati rétegbeli PDU) nevezi. Ezek a hardver üzenet
pufferébe jutnak, amiből az eszközmeghajtón keresztül a FlexRay interfész modul olvassa ki. Az interfész feladata az L-PDU-ból az I-PDU-k (Interaction layer PDU) kicsomagolása. FlexRay és Ethernet protokollok esetén egy L-PDU több I-PDU-t tartalmazhat, egyébként 1:1 hozzárendelés érvényes. Az I-PDU-k elhelyezkedését az interfész statikus konfigurációja tartalmazza. A kicsomagolt I-PDU-kat az interfész a konfiguráció szerint vagy a Pdu útválasztó, vagy a szállítási protokoll, vagy pedig a hálózat-menedzsment modul felé továbbítja. A hálózat-menedzsment PDU-kat (ezeket megkülönböztetésül NM-PDU-knak nevezzük) közvetlenül a célmodul dolgozza fel, a másik két esetben további feldolgozás szükséges. A szállítási protokoll modul a kapott PDU-kból (melyeket N-PDU-knak nevezünk) összeállítja a teljes I-PDU-t, majd továbbadja a PDU útválasztónak. Az útválasztó a PDU forrás azonosítója, és a forrás modul alapján kikeresi a vonatkozó továbbítási szabályt, és elküldi a PDU-t a cél modul(ok)nak. Normál adatkommunikáció esetén a Com modul a cél, mely további feldolgozást végez a PDU-n. A Com a PDU-kból már az alkalmazási szintű adatelemeket – az úgynevezett jeleket (signal) – csomagolja ki. Ezeket az RTE segítségével juttatja el a fogadó alkalmazási komponensnek. Küldési irányban a folyamat hasonlóan, de fordított irányban megy végre, a jelektől a hálózati keretek elküldéséig. Az összes, a folyamatban részt vevő modul a statikus konfigurációja alapján képes a PDU-k, keretek, és jelek kezelésére, ahogy a konfiguráció határozza meg ezek feldolgozásának módját, és a rendeltetési helyét is.
Komponens alapú szoftverfejlesztés Az Autosar alapú alkalmazások komponensekből épülnek fel. A komponens egy önálló, független, jól meghatározott funkciót végző szoftver elem, mely a környezetével csak előre definiált interfészeken keresztül kommunikál. A komponensek fontos tulajdonsága a független fejlesztés, tesztelés lehetősége, valamint – a jól definiált funkcionalitásnak és interfészeknek köszönhetően – az egyszerű újrafelhasználás. A komponensek a felhasználó szempontjából fekete dobozok; nem szükséges megérteni a megvalósítás részleteit, mivel a leírásból minden lényeges tulajdonsága ki kell, hogy derüljön.
Adattípusok és interfészek Beágyazott rendszerekben az egyes változók és adatelem sokféle mennyiséget jelölhetnek, de ezek általában néhány elemi adattípusra képződnek le az implementációban. Annak érdekében, hogy már a szoftver modellezése során is megkülönböztethessük a különböző jelentésű adatelemeket, az Autosar bevezeti az alkalmazási adattípus (application data type) fogalmát. Ezek az adattípusok egy magasabb absztrakciós szinten írják le a hordozott információt. Az alkalmazási adattípusok lehetnek egyszerű, vagy összetett típusok. Az egyszerű típusok lehetnek fix- vagy lebegőpontos számok, logikai értékek, felsorolt típusok (enumeráció), karakter, vagy karakterfüzér (string) típusúak. Az összetett típusok között lehetőség van tömbök és struktúrák (record) megadására. A típusokhoz több kiegészítő információt is lehet csatolni. Az egyik ilyen a mértékegység (unit). Ezzel közvetlenül jelezhetjük, hogy az adott elem egy valós
fizikai mennyiséget jelképez. A mértékegységekhez hozzárendelhetjük azt is, hogy melyik fizikai tulajdonságot jelölik (physical unit). Sokszor előfordul, hogy az egyszerű kezelhetőség érdekében az egyes adatelemeknek nem a tényleges fizikai értéküket ábrázoljuk, hanem egy alkalmas belső reprezentációjukat. (például egy valós szám helyett az ezerrel szorzott értéket fixpontosan) Ezeknek a kódolásoknak a leírására lehet az adattípusokhoz úgynevezett számítási módszereket (compu methods) meghatározni. Ezekben a fizikai-belső, illetve belső-fizikai konverziós szabályokat lehet meghatározni. Ezáltal lehetővé válik például, hogy a hálózati kommunikáció naplózásakor a belső formátumban átvitt értékeket az eszközök már fizikai értékükkel ábrázolják. Az adattípusok felhasználásával építhetjük fel a komponensek interfészeinek a leírását. Az Autosar modellező nyelv többféle interfészt (és ezzel többféle komponensek közötti kommunikációs módot) definiál. Az úgynevezett üzenet alapú (sender-receiver) interfészek egyirányú, adatküldésen alapuló kommunikációt tesznek lehetővé. Az interfész leírása az azon keresztül átvihető adatelemek és ezek adattípusának megadásából áll. Az adatelemek lehetnek üzenetsorosak, vagy skalár elemek. Az üzenetsoros kommunikáció az eseményszemantikát támogatja, mivel minden átküldött érték egyenként hozzáférhető a fogadó üzenetsorából. A skalár üzenetek esetén egyetlen puffer van a fogadóban, ahonnan mindig az utolsó átküldött érték érhető el. A kliens-szerver (client-server) interfészek függvényhívás jellegű kommunikációt valósítanak meg. Az interfész műveleteket (operation) tartalmaz, melyeknek be- és kimenő, valamint kétirányú argumentumaik lehetnek. A kliens az előre definiált műveleteket hívhatja meg, melyeket a szerver valósít meg. A mód interfészek egy-egy speciális adatelemet tartalmaznak, mely egy üzemmód csoportot jelképez. Egy ilyen csoport véges számú üzemmódot tartalmaz, melyek között a mód menedzser (az a komponens, mely kimenetén az interfész található) képes váltani. Ezzel tulajdonképpen egy állapotgépet valósíthatunk meg. A mód felhasználói (a komponensek, melyek bemenetén a mód interfész megtalálható) olvashatják az aktuális üzemmódot, vagy az üzemmód-váltásokra különböző műveleteket triggerelhetnek. A trigger interfészek esemény küldésre alkalmasak. A küldő egy triggert (jelzést) küldhet a fogadónak, melyben ez az esemény valamilyen művelet végrehajtását eredményezi. Ezen interfészek segítségével sokféle kommunikációs mintát megvalósíthatunk az alkalmazásokban.
Komponensek és portok Az Autosar szabvány két fő komponens típust vezet be. Az atomi szoftver komponensek fekete dobozok, melyek belső struktúráját nem lehet tovább osztani. A kompozíciók (composite software component) több szoftver komponensre bonthatóak, melyek együttesen valósítják meg a kompozíció által kínált funkcionalitást. A komponensek közötti kommunikációt a korábban ismertetett interfészek írják le. A lehetséges interakciós pontokat portok jelölik. Minden portot egy-egy interfész karakterizál. Kétféle portot különböztetünk meg: az úgynevezett provided port azt szimbolizálja, hogy a komponens az interfész által meghatározott szolgáltatásokat képes nyújtani (adatot küld, műveletet valósít meg, stb.), míg a required port azt szimbolizálja, hogy a komponense az interfész által meghatározott szolgáltatásokat fel kívánja használni (olvasni az adatokat, meghívni a műveletet, stb.).
33. ábra Autosar szoftverkomponens A fenti ábrán látható egy komponens grafikus reprezentációja. A komponenst egy téglalap jelöli, míg a portokat a téglalap szélén lévő négyzetek. A négyzetekbe rajzolt ikonnal utalunk a port interfészének típusára. Az ábrán a port1 port egy fogadó port, a port3 port pedig egy küldő port(küldő-fogadó interfész), a port2 egy kliens, míg a port4 egy szerver portot mutat be (kliens-szerver interfész). A port5 szemlélteti a szolgáltatás portok (service port) jelölését. A szolgáltatás portok nem más komponensekhez, hanem valamelyik platform modulhoz (BSW modulhoz) kapcsolódnak. Ezeket inverz ikonnal jelöljük. Az Autosar alkalmazásokat a komponensek portjainak összekötésével hozzuk létre. Az összeköttetés nem feltételez semmit a komponensek egymáshoz képesti elhelyezkedéséről (azonos magon, processzoron, vagy vezérlőegységben), mivel az Autosar platform képes akár távoli (más vezérlőegységen levő) komponensek között is megvalósítani az összeköttetést. Funkcionálisan minden esetben egyezni fog a viselkedés, csak időbeli különbségek lehetnek (nyilvánvalóan egy hálózati kommunikációt is magában foglaló üzenetküldés lassabb, mint a processzoron belüli, lokális memórián keresztüli). Az absztrakt összeköttetésekkel megvalósított alkalmazást (vagy alkalmazás-halmazt) az Autosar virtuális funkció busznak (Virtual Functional Bus – VFB) nevezi. A VFB egy felső szintű kompozíció, melynek már nincsenek portjai (tehát nem vár külső szolgáltatásokat). Ebbe kerülnek a különböző komponens- és kompozíció példányok. Fontos látni, hogy a VFB-ben (illetve az alkalmazásban) a komponensek példányai (prototípusai) vesznek részt, azaz egy komponensnek, vagy típusnak akár több példánya is beilleszthető az alkalmazás architektúrába. Például ha az ablakemelők működését modellezzük, a négy ajtóhoz tartozhat egy közös komponens típus, melyből négy példányt hozunk létre az alkalmazásban, egyet-egyet minden ajtóhoz. A példányok lehetnek közös processzoron, de akár elosztva is. A példányok összeköttetései alkotják a szoftver architektúráját. Egy kompozícióban részt vevő példányok portjait összeköthetünk egymással (ezt hívjuk összeépítő vagy assembly kapcsolatnak), vagy a tartalmazó kompozíció portjaival (ezt hívjuk delegált vagy delegated kapcsolatnak). Utóbbi esetben a felsőbb szintű kompozíció szolgáltatását egy alacsonyabb szinten levő komponens valósítja meg. A kompozíciók tetszőleges mélységben egymásba ágyazhatóak, így lehetővé válik több absztrakciós szint bevezetése, ami megkönnyíti a komplex szoftver-rendszerek megértését is.
Mivel beágyazott rendszerekben általában korlátozott tár és számítási kapacitás áll rendelkezésre, fontos kérdés, hogy a többszintű komponens-hierarchiának milyen hatása van a rendszer erőforrás igényére. Szerencsére a válasz az, hogy szinte semmilyen, mivel az implementáció során a komponens hierarchiát kilapítják, azaz a futtatókörnyezet már csak egy szinten levő atomi komponenseket kezel.
Komponensek belső viselkedése Az előbbiekben láthattuk, hogy magas szinten az atomi szoftver komponensek fekete dobozként viselkednek, azaz a belső megvalósításukról a felhasználóik nem látnak részleteket. Ahhoz azonban, hogy egy ilyen komponenst meg tudjunk valósítani, további információk szükségesek. Az Autosar ezt a belső viselkedés (internal behavior) modellezésével oldja meg.
Végrehajtható elemek és események Egy komponens belső viselkedés leírásának legfontosabb eleme a végrehajtható elem (futtatható függvény, runnable entity – vagy röviden runnable). Ez az elem az a legkisebb egység, amit a futtatókörnyezet (az RTE) még kezelni tud. Megvalósítása egy függvény, melyet az RTE bizonyos események bekövetkeztekor meghív. A futtatható függvényeket többféle esemény aktiválhatja: • periodikus időzítés (timing event): Egy adott periódussal bekövetkező esemény ciklikus feladatok ütemezésére • adat fogadás (data received event):A komponens egy fogadó portjára új adat érkezett • adatfogadási hiba (data received error event): A komponens egy fogadó portján adat fogadás közben hiba történt. Ilyen lehet például egy érvénytelen adatérték, vagy az időzítési kényszerek megsértése • adat küldés vége (data sent event): A komponens egy küldő portjáról sikerült elküldeni egy adatelem értékét • művelet hívás (operation invocation event): A komponens egy szerver portján levő műveletet meghívott a kliens. Ilyenkor ez az esemény irányítja a hívást a műveletet megvalósító függvényhez. • Aszinkron művelet hívás vége (asynchronous server call returns event): Ha egy kliens porton keresztül egy műveletet aszinkron módon hív meg a kliens, akkor – a hagyományos függvényhívással ellentétben – tovább folytatódik a végrehajtása, mielőtt a művelet véget érne. Ebben az esetben ez az esemény lehetővé teszi, hogy értesüljön a művelet végrehajtásáról (és elérje például a visszaadott argumentum értékeket). • Üzemmód váltás (mode switch event): Egy bemenő mód porthoz tartozó üzemmód csoportban változott az aktuális mód • Üzemmód váltás visszaigazolása (mode switch acknowledge event): Egy kimenő mód porton kezdeményezett mód váltás véget ért. • Külső trigger (external trigger occured event): Egy bejövő trigger porton trigger érkezett • Belső trigger (internal trigger occured event): Egy futtatható függvény belső trigger eseményt generált Az eseményeket a belső viselkedési modell elkészítése során fel kell sorolni, és egyenként hozzá kell kötni a megfelelő porthoz és adatelemhez/művelethez/triggerhez, melyek az eseményt kiválthatják, illetve ahhoz a futtatható függvényhez, melyet az adott esemény aktivál.
Külső kommunikáció Ahhoz, hogy a futtatható függvények elérhessék a portokon található adatelemeket, mód csoportokat, műveleteket, és triggereket, össze kell ezeket rendelni velük. Minden függvény esetén meg kell adni, hogy mely port szolgáltatásokat érheti el. Az RTE generálásakor ez alapján készülnek el az API függvények, melyeken keresztül igénybe lehet venni a szolgáltatásokat. Van lehetőség néhány esetben a szolgáltatások további testre szabására is (például, ha üres sorból próbálunk adatot olvasni, az blokkoló hatású legyen-e) melyeket a szoftver komponens leírás szintjén még nem kezeltek.
Belső kommunikáció Gyakran szükség lehet arra is, hogy az egyes ütemezett függvények egymással is tudjanak kommunikálni, anélkül, hogy a komponens környezetét ebbe bevonnák. Az egyik ilyen lehetőség a megosztott változók használata az implementációban – ugyanakkor ez több szempontból sem szerencsés, ugyanis semmi sem garantálja például a konkurens hozzáférés elleni védelmet, illetve ha egy komponens több példányban található egy processzoron, akkor a példányoknak nem lesz saját példányuk a változóból. Az egyik belső kommunikációra szolgáló Autosar koncepció a példányonkénti változó (per instance memory). Ez egy olyan memóriaterület (változó), melyet a futtatórendszer minden komponens példányhoz külön-külön létrehoz, és mindegyik példány a saját területét éri csak el. Sajnos a konkurens hozzáférés ellen ez sem védett. A különböző kölcsönös kizárás problémák feloldására szolgál az exkluzív terület (exclusive area).Ez – az általános operációs rendszerekben szemaforként ismert – megoldás lehetővé teszi, hogy egyes kódrészleteket védjünk meg attól, hogy konkurensen végrehajtódjanak. Például, ha egy láncolt listát kezelünk, megoldható, hogy a listához való hozzáadás közben egy másik végrehajtási szál ne törölhessen a listából. Abban az esetben, ha olyan adatokat szeretnénk tárolni, melyekre a kölcsönös kizárást is biztosítani kell, akkor a futtatható függvények közötti változót (inter-runnable variable) kell használni. Ez az előző két koncepció kombinációja: egy egyedi adatterület, mely védett a konkurens hozzáférés ellen. Ha egy ütemezett függvényből egy másikat kell elindítani, akkor a belső trigger (internal trigger) megoldást kell alkalmazni. Ez az előbb tárgyalt belső trigger eseményen keresztül teszi lehetővé a másik függvény aktiválását. Mindezen részletek megadása után már implementálható a komponens, illetve a futtató környezet is megkap minden információt, ami a komponens végrehajtásához szükséges.
Komponens és rendszer integráció A szoftver integráció legfontosabb bemenete a komponensekből felépített szoftver architektúra. Az alábbi ábrán nyomon követhetjük, hogyan áll elő a vezérlőegység szoftvere ebből a modellből.
34. Ábra szoftver integráció és kódgenerálás A rendszer konfigurálás során létrehozzuk a rendszer topológia modellt, mely ábrázolja a rendszerben levő vezérlőegységeket (és a rajtuk található kommunikációs vezérlőket), és az egységek közötti hálózati kapcsolatokat. Ezek után megadjuk, hogy az egyes komponensek mely vezérlőegységre legyenek telepítve, illetve kiválasztjuk, hogy a komponensek mely implementációját kívánjuk használni. Egy-egy komponensnek ugyanis többféle implementációja is lehet (például lehet egy tárterület használatra optimalizált és egy futási időre optimalizált), melyeket a szoftver modell ír le. Miután a komponensek elhelyezkedéséről és implementációjáról döntöttünk, a rendszer konfigurálását a kommunikációs mátrix felépítésével folytatjuk. Itt meg kell adni, hogy az egymással kommunikáló, de külön vezérlőegységre telepített komponensek közötti üzenetek milyen hálózatokon, keretekben, PDU-kban, és jeleket keresztül fognak eljutni a rendeltetési helyükre. Ezen kívül meg kell határozni az egyes hálózatok és kommunikációs vezérlők beállításait (egy FlexRay hálózat esetén például a TDMA körök időtartamát, egy macrotick hosszát, stb.). A kommunikációs mátrixot általában a rendszer integrátora (azaz a jármű gyártója) határozza meg, ilyen esetben a beszállítók készen kapják ezt – a szintén Autosar XML-ben elérhető – információt, és külső kényszerként felhasználják a rendszerkonfiguráció kialakításánál. Az elkészült modellt az Autosar rendszer modellnek (system model) nevezi. A szoftvertervezés kezdetétől eddig a pontig egyetlen modell írja le a rendszert, akkor is, ha számtalan vezérlőegységet tartalmaz. Mivel a vezérlőegységek futtatható szoftverét egyenként kell összeállítani, egy ponton a modellt is szét kell választani. Ez a rendszer konfiguráció elkészítése utáni vezérlőegység kivonat (ECU extract)
készítésének fázisa. Ez egy automatikus művelet, melynek során egy alkalmas szoftver a globális modellből kimásolja a kiválasztott vezérlőegységhez kapcsolódó információkat. Ebbe beletartozik az összes, a vezérlőegységre telepített komponens, az ezekhez szükséges adattípusok, interfészek, belső viselkedési leírások, stb. Emellett a kommunikációs mátrix vonatkozó részét is hozzá kell tenni a kivonathoz. A kivonat alapján elkészül (ugyancsak egy Autosar szabványos modell formájában) a vezérlőegység konfigurációjának első változata. A konfiguráció-generátor eszköz a bemenő modell alapján próbálja meghatározni a konfiguráció minél több paraméterét. A további kiegészítés és finomítás már manuálisan történik, egy megfelelő konfiguráció szerkesztő eszköz segítségével. A korábban áttekintett összes BSW modulhoz és az RTE-hez is részletes konfiguráció készül. Az elkészült konfigurációból minden modulhoz legenerálható a konfiguráció (c és h fájlok formájában). Az ábra az RTE modul generálását szemlélteti. Miután az RTE-t, a többi modult (BSW) és a szoftver komponenseket is lefordítottuk, összeállítható a vezérlőegység futtatható szoftver képe. Természetesen a bemutatott folyamat iteratív, a gyakorlatban ritkán készül elsőre tökéletes kommunikációs mátrix, konfiguráció, vagy éppen szoftver implementáció. A folyamat minden termékét többször átdolgozva, finomítva, javítva kapjuk a végleges szoftvert.
Alkalmazási példa Ebben a szakaszban egy konkrét – egyszerű – példán keresztül mutatjuk be néhány Autosar komponens modellezését és implementációját. A célunk nem az, hogy egy tényleges, minden részletében kidolgozott követelményrendszernek megfelelő szoftver elkészítését mutassuk be (ez túlmutatna ennek az írásnak a korlátain), hanem az, hogy egy tipikus megvalósítási mintán keresztül mutassuk be az Autosar alapú fejlesztés néhány lépését. A minta alkalmazás egy egyszerű hűtés vezérlő. Egy analóg csatornán olvas egy hőmérséklet szenzor jelet, amit átszámít Celsius fokra, majd a hőmérséklettől függően be- vagy kikapcsol egy hűtőventilátort. A rendszert három szoftver komponens alkotja. A vezérlőegység I/O absztrakcióért az EcuHwAbstration nevű komponens felel. Ez csatolja az ADC eszközmeghajtón keresztül a szenzort, és a DIO meghajtón keresztül a hűtőventilátort a többi elemhez. A TemperatureSensor komponens az AD konverter értékét alakítja Celsius fokban megadott hőmérsékletté, a CoolerControl pedig egy egyszerű (ki/be) szabályozást valósít meg.
35. ábra A minta rendszer architektúrája Példaként ismerjük meg részletesebben a CoolerControl komponens felépítését. A lenti ábrán látható, hogy a komponensnek egy fogadó portja van (temperature), mely a TemperatureInterface küldő-fogadó interfészt valósítja meg. Ezen egyetlen adatelem található (boardTemp) aminek típusa TemperatureType. A komponensnek van egy kliens portja is (cooler), mely a CoolerCtrlInterface kliens-szerver interfészt valósítja meg. Ezen két művelet érhető el (coolerStart, coolerStop), melyek a hűtőventilátor vezérlését teszik lehetővé. Az ábrán nem látható, de a komponens egy periodikus ütemezett függvénnyel rendelkezik, mely 10ms-ként aktiválódik. A függvény hozzáfér a fogadó porthoz, és a kliens port műveleteihez, valamint egy coolerState nevű logikai változóhoz, amit futtatható függvények közötti változóként definiáltunk.
36. ábra a minta rendszer egy komponense Az RTE generátor a következő API függvényeket generálja a komponens számára: Std_ReturnType Rte_Read_temperature_boardTemp(TemperatureType * value) Ezzel a függvénnyel lehet a temperature nevű port boardTemp nevű adatelemét olvasni. A visszatérési érték Std_ReturnType típusú, melyet az Autosar függvények használnak a különféle hibák jelzésére. Std_ReturnType Rte_Call_cooler_coolerStart() Ezzel a függvénnyel lehet meghívni a cooler port coolerStart műveletét. Mivel a műveletnek nincsenek argumentumai, a függvénynek sem lesznek. Std_ReturnType Rte_Call_cooler_coolerStop() Ezzel a függvénnyel lehet meghívni a cooler port coolerStop műveletét. Mivel a műveletnek nincsenek argumentumai, a függvénynek sem lesznek. Boolean Rte_IrvRead_coolerState() Visszaadja a coolerState változó értékét void Rte_IrvWrite_coolerState(Boolean value) Írni lehet ezen keresztül a coolerState változó értékét. Az ütemezhető függvény megírása ezek után egyszerű. Az alábbiakban egy példát mutatunk be, hogy érzékeltessük az API használatát. /* * Hőmérséklet limit, efölött be kell kapcsolni a hűtőt */ #define TEMPERATURE_LIMIT 30.0f /*
* Hiszterézis, a ki/bekapcsoláshoz */ #define TEMPERATURE_HYST 2.0f void CoolerControl_ruRefresh() { TemperatureType temperature; Rte_Read_temperature_boardTemp(&temperature); érték olvasása
//
szenzor
/* Ha a hőmérséklet nagyobb, mint a limit, és a hűtés nem aktív */ if ((TEMPERATURE_LIMIT
Látható, hogy az RTE hívásokat egyszerűen be lehet ágyazni a kódba. Az egyes komponensek implementálása után beilleszthetőek a vezérlőegység szoftverébe.
