Diagnosztika és nyomkövetés Beágyazott rendszerek esetén legtöbbször külön megfontolást igényel a diagnosztizálhatóság, nyomkövetés, és hibakeresés támogatása. Egy asztali számítógépre tervezett szoftverrel szemben kevesebb erőforrás áll rendelkezésre, illetve a szükséges fejlesztőprogramok se magán a célrendszeren, hanem egy másik eszközön futnak. Az autóiparban – a vezérlőegységek számának növekedésével – fokozott igény mutatkozott ezen funkciók támogatására, ami több szabvány kidolgozásához vezetett.
UDS és OBD Az UDS (Unified Diagnostic Services) egy nemzetközi szabvány (ISO 14229:1) [10], melynek célja a járműfedélzeti vezérlőegységek diagnosztikai interfészének szabványosítása. A szabvány fő alkalmazási területe az úgynevezett szerviz diagnosztika (garage diagnostics), melynek során egy diagnosztikai eszközt (a szabványban kliens) csatlakoztatnak a jármű egyik terepbuszához, és az ezen keresztül éri el a különböző vezérlőegységeket (szerverek). Amennyiben több busz található a járműben, lehetőség van a kommunikáció átjátszására kijelölt átjárók segítségével. Néhány lehetséges elrendezést mutat be az alábbi ábra.
39. ábra Diagnosztikai kommunikáció a járműben Az UDS kommunikáció többféle protokoll felett működhet. Jelenleg a legelterjedtebb a CAN alapú megoldás, de természetesen a FlexRay hálózatokon is van lehetőség UDS kommunikációra, csakúgy, mint Ethernet felett (ez a DoIP vagy Diagnostics over IP, mivel a kommunikáció IP protokoll felett működik).
Üzenetformátum A következő táblázat a kliens kéréseinek formátumát mutatja be. Paraméter Megjegyzés Méret (byte)
SA
Forrás cím
1
TA
Cél cím
1
TA_type
Címzés típus funkcionális)
RA
Távoli cím (csak átjárón 1 keresztüli kommunikáció esetén)
SI
Szolgáltatás azonosító
Paraméter1 / SubFunction
A szolgáltatás első 1 paramétere, vagy az alfunkció azonosítója
Paraméter2..n
További paraméterek
(fizikai/ 1
1
n-1
7. táblázat UDS kérés felépítése A forrás és célcímek a küldőt és a fogadót azonosítják. Ezeket előre kiosztják, minden vezérlőegységnek saját címe van (és a diagnosztikai kliensnek is). A célcím kétféle lehet: fizikai címzés esetén adott vezérlőegységet címez a küldő, míg funkcionális címzés esetén pedig egy adott funkciót akar elérni a kliens, anélkül, hogy egy specifikus vezérlőegységet címezne meg. A szolgáltatás azonosító választja ki az aktiválandó szolgáltatást. Ezt bizonyos esetekben egy al-funkció azonosító is kiegészíti. Az üzenet további részében a szolgáltatás paraméterei, bemenő adatai találhatóak. A válasz üzenet felépítése nagyon hasonló: Paraméter
Megjegyzés
Méret (byte)
SA
Forrás cím
1
TA
Cél cím
1
TA_type
Címzés típus funkcionális)
RA
Távoli cím (csak átjárón 1 keresztüli kommunikáció esetén)
SI
Szolgáltatás azonosító
1
Paraméter1 / SubFunction
A szolgáltatás paramétere, vagy alfunkció azonosítója
első 1 az
Paraméter2..n
További paraméterek
(fizikai/ 1
n-1
8. táblázat UDS válasz felépítése Az SA, TA, TA_type, RA elemek jelentése ugyanaz, mint a kérésben. Az SI a hívott szolgáltatást azonosítja (opcionálisan kiegészítve az al-funkció azonosítóval). A paraméterek itt a szerver által a kliensnek küldött adatokat hordozzák.
Amennyiben hibajelzésre van szükség, az SI mezőben 0x7f értéket küld a szerver, az SI azonosítót az első, a negatív válasz kódot (negative response code) pedig a második paraméter helyén küldi vissza a szerver. A következőkben a legfontosabb UDS szolgáltatásokat mutatjuk be röviden.
Munkafolyam vezérlés A munkafolyam vezérlés (session control) szolgáltatás segítségével a kliens többféle munkafolyamatot indíthat el a szerveren, valamint beállíthatja az aktuális munkafolyam időzítési paramétereit. Mindig pontosan egy aktív munkafolyam van szerverenként, ezért a szerver az indulásakor automatikusan elindítja az alapértelmezettet, és – ha más kérés nem érkezik – a kikapcsolásig aktív állapotban is tartja azt. A szervernek képesnek kell lennie diagnosztikai szolgáltatások nyújtására a normál üzemállapotban, és esetleg további állapotokban (pl. degradált üzemmód), ha a jármű integrátora ezt megköveteli. A nem alapértelmezett munkafolyamokban általában több diagnosztikai szolgáltatás érhető el, ezért lehet szükség arra, hogy a kliens átváltson ezek egyikére. Természetesen a szerver konfigurációjában megadhatunk bizonyos korlátozásokat a kérésekre. Például lehet, hogy csak egy adott azonosítóval (diagnosztikai címmel) rendelkező kliens kezdeményezhet egy adott munkafolyamot. Ha egy már aktív folyamot kíván elindítani a kliens, erre pozitív választ fog kapni, és a szerveren nem történik állapot-változás. Ha azonban tényleges változás történik, akkor a pozitív választ még az új időzítési és kommunikációs paraméterek beállítása előtt küldi a szerver. Néhány munkafolyam típust előre definiál a szabvány, és ezen kívül a gyártó számára is hagy fenntartott folyam azonosítókat. A legfontosabb szabványos munkafolyamok a következők: • alapértelmezett (defaultSession): a kezdeti állapot • programozás (programmingSession): a szerver programozására (új szoftver vagy paraméterek letöltésére) használható. Ha az úgynevezett bootloader kód fut a szerveren, akkor ebből a munkafolyamból csak az ECU reset szolgáltatással lehet kilépni. • Kiterjesztett diagnosztika (extendedDiagnosticsSession): Ebben a módban minden diagnosztikai szolgáltatást engedélyeznek. • Biztonsági diagnosztika (safetySystemDiagnosticSession): Minden, a biztonságossággal kapcsolatos diagnosztika engedélyezésre kerül.
Vezérlőegység újraindítás Ez a szolgáltatás (ECU Reset) lehetővé teszi a vezérlőegység (a szerver) újraindítását. A pozitív visszaigazolást természetesen még az újraindítás előtt el kell küldenie a szervernek. Az újraindítási szolgáltatás több al-funkciót is támogat, melyek különböző viselkedést váltanak ki: • hardReset: teljes hardver újraindítás, a tápelvétel-visszaállítás szimulációjával • keyOffOnReset: egy gyújtási ciklus szimulációja (kulcs kivétele, behelyezése) • softReset: tisztán szoftveres alaphelyzet-visszaállítás A pozitív válaszban a szerver jelzi azt is, hogy mennyi ideig nem lesz elérhető (0254s), így a kliens ezt figyelembe veheti a kapcsolat újbóli felvételekor. Biztonsági hozzáférés Ez a szolgáltatás (Security Access) lehetővé teszi a kliens azonosítását, mielőtt érzékeny funkciókat (például szoftverfrissítés, stb.) elérhetne. A működése egyszerű:
1. a kliens küld egy „seed request” üzenetet – ezzel jelzi, hogy kér egy véletlenszámot 2. a szerver küld egy seed-et 3. a kliens rejtjelezi ezt a saját kulcsával, majd visszaküldi a szervernek 4. a szerver ellenőrzi a választ, és ha helyes, engedélyezi a hozzáférést A titkosítás lehet szimmetrikus vagy aszimmetrikus, az implementációtól függően. Lehetséges, hogy többféle azonosítási szintet támogat egy vezérlőegység, ekkor a kliens meghatározza, hogy melyiket kívánja elérni, és ennek megfelelő kulcsot fog használni. Ebben az esetben a különböző szintekhez más-más jogosultságok tartoznak.
Hibatároló elérés A hibatároló feladata a különböző futás idejű hibák megfelelő naplózása (az Autosar architektúrában ez a Dem modul feladata). Az ehhez kapcsolódó funkciók lehetőséget adnak a tárolt hibák kiolvasására, törlésére. A hibatároló kiolvasás (ReadDTCInformation) az információk kiolvasására szolgál. A naplózott elemeket DTC-nek (diagnostic trouble code) nevezzük. Egy-egy hibához tartozó elem több állapotban lehet (például nem definiált/aktív – hiba tortént / inaktív – nincs hiba, stb.) A szolgáltatás segítségével többféle lekérdezést hajthatunk végre, melyek közül a legfontosabbak: • Adott státuszú DTC-k számának lekérése. (pl. hány aktív hiba van?) • Minden, adott státuszú DTC lekérése • Adott hibához tárolt adatok lekérése. A rendszer minden DTC-hez képes tárolni különböző változók értékeit (például hőmérséklet, sebesség, stb.), melyek segítik a hibakeresést. • A DTC-hez tartozó kiegészítő adatok lekérése, például: hibaszámláló (hányszor következett be), utolsó esemény ideje, stb. • A legutolsó aktív hiba • A legutolsó inaktívra jelentett hiba A hibatároló törlés szolgáltatás (ClearDiagnosticInformation) segítségével kitörölhetjük az aktív DTC-ket egyenként, vagy csoportosan. Vannak olyan (permanens) DTC-k, melyeket nem lehet törölni, de a többi hibajelzésre ez a parancs alkalmazható.
Egyéb szolgáltatások A fent leírt szolgáltatásokon kívül az UDS szabvány sok egyéb szolgáltatást is definiál. Ezek között találhatunk adat le- és feltöltést megvalósító elemeket (különböző adatok lekérdezése, szoftverfrissítés, stb.), valamint úgynevezett rutin vezérlő szolgáltatást, melynek segítségével belső diagnosztikai rutinokat futtathatunk távolról a szerveren. A megvalósított szolgáltatások köre természetesen vezérlőegység-specifikus.
OBD-II Az OBD (On-Board Diagnostics) protokollcsalád története az 1990-es évekre nyúlik vissza. A Kalifornia államban működő Air Resources Board tette kötelezővé 1991ben, hogy minden eladott jármű rendelkezzen fedélzeti diagnosztikai rendszerrel, amin keresztül a károsanyag-kibocsátással kapcsolatos funkciók ellenőrizhetőek, illetve az esetleges hibák kiolvashatóak. Ez volt az OBD-I szabvány kezdete. Jelenleg az OBD-II szabvány használatos, és bár az UDS több tekintetben szélesebb
alkalmazási területet fog át, az USA-beli törvényi szabályozások miatt továbbra is támogatni kell. Az OBD-II többféle protokollt definiál a tesztelő eszközzel való kommunikációra, ezek közül ma a legkorszerűbbnek a CAN felület tekinthető. Ezt a felületet az ISO 15675 [11] szabványban írják le. Gyakorlatilag az UDS CAN alapú implementációjára alapuló protokollról van szó, mely a károsanyag-kibocsátással kapcsolatos diagnosztikákra ad plusz megkötéseket. Ezen kívül ajánlást ad a motorés hajtás vezérlő egységek címének kiosztására is, valamint szabványosítja az erre használható címtartományt. Ennek célja az, hogy a hatósági vizsgáló berendezések (például környezetvédelmi vizsgálóállomás) típus függetlenül ugyanúgy megvalósítható legyen. A protokollcsalád magasabb szintjén szintén szabványosításra kerültek a kibocsátással kapcsolatos DTC-k is (ISO 15031 [12]). Ezáltal a legfontosabb hibakódok gyártó függetlenül értelmezhetővé váltak.
CCP és XCP A vezérlőegységek szoftverének fejlesztésekor, és különösen a szoftver kalibrálásakor szükség van arra, hogy a normál működési környezetben is nyomon tudjuk követni bizonyos belső változók értékének változását, illetve át tudjunk írni bizonyos értékeket. Kalibrálásnak nevezzük általában a szoftverben található különböző paraméterek (szűrők, szabályzók paraméterei, határértékek, stb.) beállítását a rendszer-integráció (a szoftver, hardver, és mechanikus komponensek összehangolása) során. Általában ezen paramétereket analitikusan csak közelítőleg lehet meghatározni, ezért szükséges a tapasztalati úton történő finomhangolásuk. Az értékek megfigyelésére és beállítására szolgálnak az úgynevezett kalibrációs protokollok. Ezek lehetővé teszik, hogy a jármű terepbuszán keresztül elérhessük a vezérlőegység memóriáját, ezzel feleslegessé téve az egység megbontását, megváltoztatását. Ez különösen olyan egységes esetén fontos, melyek a környezeti hatásoknak fokozottan ki vannak téve (például a motortérben elhelyezkedő vezérlőegységek), hiszen ezeket megbontott állapotban általában nem lehet a tesztjárműbe szerelni. Az első, elterjedt protokoll a CCP (CAN Calibration Protocol) [13] volt, melyet az ASAM (Association for Standardization of Automation and Measuring Systems) szervezet dolgozott ki. Ez – a nevéből adódóan – CAN hálózatok felett definiált egy kalibrációs protokollt, ami egyszerű kérdés-válasz alapon működött. A buszrendszerek fejlődésével igény mutatkozott a CCP más protokollok feletti megvalósítására is. Ebből alakult ki az XCP (Universal Measurement and Calibration Protocol) [14], mely CAN, FlexRay, TCP, UDP, USB, UART, és SPI protokollok felett is működőképes. A CCP alapjait megtartották, de flexibilisebbé tették, hogy az egyes protokollok sajátosságaihoz alkalmazkodni tudjon. A következőkben az XCP protokoll legfontosabb elemeit ismertetjük.
Kommunikációs architektúra
40. ábra Az XCP Kommunikáció áttekintése Az XCP kommunikáció a mester/szolga (master/slave) elrendezésre épül. A mester a fejlesztőeszköz, mellyel hozzá kívánunk férni a vezérlőegységhez (ami a szolga). A kommunikáció bármely, az előbb említett protokollon nagyon hasonlóan történik. A küldött üzeneteknek két fajtája van. Az első a CTO (Command Transfer Object), melynek segítségével parancsokat (CMD) küldhet a mester, illetve ezekre választ (RES) a szolga. Ezen kívül a szolga küldhet hibaüzeneteket (ERR), esemény értesítéseket (EV), és kiszolgálási kéréseket (SERV). A DTO (Data Transfer Object) csomagok szinkron adatgyűjtés (DAQ), illetve stimuláció (STIM) során használatosak. Egy parancsot (CMD), a szolga mindig meg kell, hogy válaszoljon vagy egy válasszal (RES), vagy – hiba esetén – egy hiba csomaggal (ERR). Az esemény, kiszolgáláskérés, és DAQ csomagokat a szolga aszinkron módon küldheti, és a mester nem nyugtázza őket.
41. ábra Az XCP csomag formátum Egy XCP keret három fő részből áll. A fejléc és a farok rész hordozó protokoll specifikusak, és bizonyos esetekben hiányozhatnak is. Maga az XCP csomag ezek között helyezkedik el, és ez már protokoll-független.
Az azonosító mező (Identification Field) szintén három részből áll. A PID (Packet Identifier) a csomag azonosítására szolgál. CTO-k esetén a másik két elem elmarad, és a Pid azonosítja a csomag típusát (CMD, ERR, RES, …). DTO-k esetén a PID és DAQ mezőknek azonosítani kell a mintavételi (DAQ) listát, és azon belül az objektumot (ODT), melynek értékét a csomag hordozza. Így az azonosító állhat csak a PID-ből, ekkor ez egy abszolút objektum index, vagy a PID és DAQ elemekből, ebben az esetben utóbbi a listát, előbbi pedig a listán belül az objektumot azonosítja. A FILL elem csak arra szolgál, hogy szükség esetén a mező méretét processzor szó hosszúságúra egészítse ki. A PID értéke CTO csomag esetén az alábbi lehet: • 0xc0..0xff: parancs (CMD) • 0xff: válasz (RES) • 0xfe: hiba (ERR) • 0xfd: esemény (EVT) – a következő byte az eseménykód • 0xfc: kiszolgálás-kérés (SERV) – a következő byte a szolgáltatás kérés kódja Az TIMESTAMP (időbélyeg) mező csak DTO-kban lehet, de használata konfigurálható. A mért értékhez tartozó időbélyeget tartalmazza, az előre meghatározott felbontásban. Az adatmező (DATA) CTO-k esetén az adott típusú csomagnak megfelelő paramétereket tartalmazza, DTO esetén pedig a mérési, illetve stimulációs adatokat.
Mintavételezés és Stimuláció Az XCP egyik legfontosabb szolgáltatása a szinkron mintavételezés, illetve stimuláció. A mintavételezés során egy memóriaterületről készül pillanatfelvétel, míg stimuláció esetén egy memóriaterület értékét írjuk felül új értékkel.
42. ábra ODT listák szervezése A memória és a DTO-k közötti leképzésért az ODT elemek felelnek. Ezek egy címhossz párt tartalmaznak, ami kijelöli a memóriaterületet. Az ODT elemeket ODT listákba szervezhetjük. Küldéskor a PID azonosítja az ODT-t. Az ODT listákat tovább csoportosíthatjuk, úgynevezett DAQ (data aqusition adatgyűjtés) listákba. Minden DAQ lista mintavételezését és az adatok továbbítását külön események indítják. A listákat vagy statikusan (fordítási időben), vagy dinamikusan (futási időben) lehet konfigurálni. Előbbi esetben előre meghatározzuk a mérendő adatokat, míg utóbbi esetben – nagyobb futásidejű erőforrás használat mellett – lehetséges a kliensről dinamikusan meghatározni a mérésre kerülő adatokat. A mintavételezést indító eseményeket szintén a konfiguráció során lehet meghatározni. Egy-egy esemény több DAQ listát is triggerelhet. Az eseményekhez prioritást lehet rendelni, ebben az esetben a nagyobb prioritású események kiszolgálása előnyt élvez.
XCP parancsok A következőkben bemutatjuk a protokoll alapvető szolgáltatásait, és az ezekhez tartozó parancsokat. Az XCP szabvány a parancsokat kategóriákba rendezi, és minden kategóriában meghatározza a kötelező és opcionális parancsok halmazát. A kötelező parancsokat minden XCP megvalósításnak támogatnia kell.
Alapvető parancsok Az alapvető (vagy standard) parancsok a legegyszerűbb funkciók elérésére szolgálnak. Az XCP munkamenet indítása a kapcsolódás (connect), befejezése pedig a szétkapcsolás (disconnect) parancs segítségével történik.
A munkamenet státusz lekérdezés (get current session status) parancs segítségével lehet megállapítani, hogy milyen erőforrások (DAQ és STIM listák) állnak rendelkezésre. Az opcionális parancsok között ebben a csoportban megtalálhatjuk a különböző biztonsági szolgáltatások eléréséhez szükséges elemeket, melyek segítségével autentikálható a mester, mielőtt védett műveletet (például memória írás) végezhetnek. Az opcionális csoportba tartozik a feltöltés parancs is (upload és upload short), melynek segítségével a mesterre lehet a szolgáról feltölteni adatokat (adott hosszban egy memóriacímtől). Ehhez a kezdő memóriacímet az átviteli cím beállítása (set memory transfer address) paranccsal lehet beállítani.
Kalibrációs parancsok Ebbe a csoportba a letöltés (download) parancs különböző változatai tartoznak. Ezek segítségével a mesterről lehet a szolgára adatokat letölteni. Fontos megjegyezni, hogy a DAQ és STIM módszerekkel ellentétben a le- és feltöltés parancsok aszinkron módon hajtódnak végre, azaz a parancs értelmezése közben történik a memória írása vagy olvasása, nem egy előre meghatározott időpontban. Ennek megfelelően nehezebb lehet az adat konzisztencia biztosítása (a konkurens hozzáférés ellen nincs védelem).
Lapváltási parancsok A lapváltási (page switching) segítségével a kalibrációs paramétereket tartalmazó lapok között lehet váltani (ha a vezérlőegység támogatja ezt a funkciót). A lapok használata azért előnyös, mert a kalibrációs paramétereket az éppen inaktív lapon a mester egyenként átírhatja, és csak lapváltáskor – egyszerre – jutnak érvényre. Ezzel elkerülhető például, hogy egy félig frissített paraméterkészlettel futtassunk egy szabályozót. A két fő parancs a kalibrációs lap hozzáférés beállítása és lekérdezése. Ezekkel beállítható, illetve lekérdezhető, hogy egy adott laphoz a vezérlőegységen futó alkalmazás, vagy az XCP mester férhet-e hozzá. A további – opcionális – parancsok között különböző információ lekérdező lehetőségeket találunk.
Mintavételező és stimulációs parancsok Ezek a parancsok (Data Acquisition and Stimulation commands) a mintavételezéssel kapcsolatos adminisztrációt, illetve a folyamat indítását és leállítását támogatják. Találunk az ODT bejegyzések lekérdezésére (Read element from ODT entry) és beállítására (Write element to ODT entry) szolgáló parancsokat. Ezekkel lekérdezhető és beállítható, hogy az adott elem milyen memóriacímet és hosszt tartalmaz. Hasonlóan, a DAQ listák üzemmódját (irány, időbélyeg használata) is be lehet állítani, illetve le lehet kérdezni a vonatkozó parancsokkal: set/get mode from DAQ list. Az egyes DAQ listák feldolgozását el lehet indítani, és le lehet állítani: start-stop DAQ list. Az opcionális parancsok között találhatjuk a dinamikus – futás idejű – DAQ lista konfiguráláshoz szükséges parancsokat. Ezekkel új listákat hozhatunk létre, azokban pedig új ODT listákat, és ODT elemeket.
Programozási parancsok A programozási parancsokkal (Non-volatile Memory Programming) lehet a vezérlőegység nem-felejtő memóriájának bizonyos területeit törölni, illetve írni.
Igazodva a szokásos memória elemek (pl. Flash) kezeléséhez, külön parancs vonatkozik a törlése (Clear part of non-volatile memory), illetve az írásra (program a non-volatile memory segment). A programozás megkezdését és lezárását is jelezni kell egy-egy vonatkozó parancs kiadásával. Az opcionális parancsok segítségével lehetőség van rejtjelezett tartalom letöltésére (melyet a szolga dekódol írás előtt), illetve a programozott terület ellenőrzésére is.
Összegzés Az XCP protokoll fontosságát jelzi, hogy az Autosar 4.0 szabványban már része a BSW specifikációnak. Széles körben elterjedt, több cég is kínál implementációt beágyazott környezethez. A fejlesztőeszközök területén is több olyan szoftvert találunk, mely támogatja az XCP alapú kommunikációt, és hatékonyan lehet a különböző mérési és kalibrációs feladatokat megoldani a segítségével.
