Autóbusz távdiagnosztikai rendszer fejlesztése

Átírás

1 DIPLOMAMUNKA MISKOLCI EGYETEM Autóbusz távdiagnosztikai rendszer fejlesztése Készítette: Biró Zoltán Témavezető: Trohák Attila egyetemi adjunktus Automatizálási és Kommunikáció-technológiai Tanszék MISKOLC, 2013

2 Tartalomjegyzék 1. Bevezetés A vezeték nélküli kommunikációs hálózat kiválasztása A GSM hálózat felépítése GPRS kommunikáció Járművek kommunikációs rendszere A CAN buszrendszer Jármű csoportok összehasonlítása Tehergépjárművek, autóbuszok belső hálózata A CAN azonosító értelmezése Hálózat menedzsment Átviteli protokollok Diagnosztika Autóbuszok hálózatának vizsgálata és szimulációja Mérések végzése Az üzenetsűrűség meghatározása Azonosítók felmérése Diagnosztizálás folyamatának vizsgálata A távdiagnosztikai rendszer kialakítása CAN üzenetforgalom szimulációja Üzenetszűrés megvalósításai Első szűrőrendszer kialakítása Második szűrőrendszer megvalósítása Továbbfejlesztési lehetőségek Összefoglalás Summary Irodalomjegyzék Mellékletek sz. Melléklet sz. Melléklet I

3 1. Bevezetés Diplomamunkám témája az autóbuszok távdiagnosztizálása. A járművek diagnosztizálása fontos és egyre elterjedtebb, mert ezzel gyorsan megállapítható az egyes részegységek hibás működése. Ez felgyorsítja és hatékonyabbá teszi a karbantartási folyamatokat. Ide tartozik a hibakeresés és a hibaelhárítás mellett a járművek gondozására és javítására vonatkozó tanácsadás is. A távdiagnosztika a hagyományos diagnosztikai eljárások telekommunikációs eszközökkel való támogatása, azaz jelen esetben azt jelenti, hogy a jármű és a diagnosztikát végző személy távol van egymástól. Az autóbuszok távolról való karbantartása, monitorozása 2011-ben fogalmazódott meg a Borsod Volán Zrt.-nél, ekkor kötött együttműködést az egyetem és a társaság A felsőoktatás minőségének javítása kiválósági központok fejlesztésére alapozva a Miskolci Egyetem stratégiai kutatási területein című TÁMOP B-10/2/KONV pályázat keretében ábra: A Borsod Volán Zrt. telephelyei A társaság több telephellyel is rendelkezik, az autóbuszok nem mindig egy helyre érnek vissza, emellett csak egy szakember foglalkozik a diagnosztizálással és a diagnosztikai eszközből is csak egy van. Így a cél az eltérő telephelyeken lévő járművek távolról való diagnosztizálása. Ugyanis adódik olyan, hogy a jármű elektronikája letiltja a működést, és csak egy hibakód olvasást/törlést kell elvégezni, emiatt a diagnosztizálást végző szakembernek sokszor több száz kilométert kell megtennie egy rövid beavatkozás miatt. 1

4 Ezek alapján belátható, hogy a távdiagnosztizálással jelentős költség és időmegtakarítás érhető el. Elkészítettünk egy vezetékes távdiagnosztikai rendszert, mellyel egy központi irodából monitorozhatóak a távoli telephelyeken lévő járművek. Ez a rendszer P ügyszám alatt bejelentett szabadalom, melynek benyújtója a Miskolci Egyetem és feltalálója voltam többek között én is. Távdiagnosztikai rendszer járművek műszaki állapotának ellenőrzésére a találmány címe. A találmány mellett elkészítettünk egy prototípust is a vezetékes távdiagnosztizáláshoz, ez a következő ábrán látható ábra: Vezetékes távdiagnosztikai rendszer prototípusa Az egyik bőröndöt a jármű belső hálózatára kell csatlakoztatni, a másikat egy központi iroda épületben lehet elhelyezni és onnan tudjuk elvégezni a jármű műszaki állapotának felmérését. Az új rendszerű vezetékes távdiagnosztikai, távkarbantartási megoldás után felmerült az igény egy vezeték nélküli rendszerre is, ugyanis ezzel a járművek alrendszereit menetközben folyamatosan felügyelhetjük, On-Board (fedélzeti) diagnosztizálást alakíthatunk ki. A távdiagnosztizáláshoz használt vezeték nélküli kommunikációs hálózat kiválasztásánál fő szempont a teljes rendelkezésre állás és a lefedettség. A dolgozatom első fejezetében a vezeték nélküli hálózat kiválasztásának lehetőségeit ismertetem röviden. Mivel a feltételeknek ma Magyarországon csak a GSM alapú továbbítás tesz eleget, ezért ezt fejtem ki részletesebben. A járműveken a fő egységek közötti kommunikáció CAN buszrendszeren keresztül történik, a diagnosztikai eszközt is erre a buszrendszerre kell csatlakoztatni, így tud kommunikálni a jármű egységeivel, valamint így képes diagnosztizálni azokat. A 2

5 távdiagnosztika úgy alakítható ki, hogy a járművek CAN kommunikációs rendszerétől jövő adatokat átalakítjuk egy másik kommunikációs szabványra, továbbítjuk azt egy távoli helyre, majd ott visszaalakítjuk CAN adatokká, amiket a diagnosztikai eszköz már fel tud dolgozni. Az átalakításhoz mindenképpen ismernünk kell a CAN adatcsomagjait, ezért a dolgozatom második fejezetében a CAN kommunikációt mutatom be általánosan. A járművek belső hálózata különböző, két csoportba osztható, ezért egy összehasonlítást készítettem a diagnosztikai szabványok, a fizikai interfész és más egyéb szempontok alapján is. Az összehasonlítás után a tehergépjárművek és autóbuszok belső hálózata által használt SAE J1939-es szabványt részletezem, diplomamunkám további részében csak ebbe a csoportba tartozó járművekkel foglakozom. Az egyes vállalatoknak a flottaüzemeltetés, logisztika, személyszállítás területén ilyen járműből lehet sok, és a távdiagnosztizálásukkal növekedne a járművek megbízhatósága, a meghibásodott járművek gyorsan és egyszerűen diagnosztizálhatóvá válnak a telephelyről, ahonnan a szerelők a problémára felkészülten, a megfelelő felszerelések birtokában indulhatnak a jármű javítására, mentésére. Én az autóbuszok távdiagnosztizálásával foglalkozom, amik ugyancsak ebbe a csoportba tartoznak. A jármű belső CAN kommunikációs rendszerének a sebessége sokkal nagyobb, mint ami elérhető a GSM hálózaton keresztüli kommunikáció segítségével, ezért valamilyen adat redukálási módszert kell alkalmazni, hogy megoldható legyen a távolból való diagnosztizálás. A módszerek kidolgozása előtt mindenképpen fel kell mérni a jármű hálózatának tényleges kommunikációját. A negyedik fejezetben bemutatom az autóbuszokon elvégzett mérési eredményeimet és a CAN hálózat adatforgalmának részletes elemezését. Egy autóbusz beszerzése és üzemben tartása magas költségekkel jár, ezért szimuláció segítségével állítom elő a belső CAN hálózatának üzenetforgalmát. Ezáltal megvalósítható a kidolgozott szűrőalgoritmusok működésének vizsgálata és a használatukkal elért adatmennyiségek elemzése, összehasonlítása. A szimulációt a mérésekre alapozva készítettem el, ennek részletezése az 4.3. alfejezetben található. A mérések elvégzése és a laboratóriumi körülmények közötti tesztelés kialakítása után egy egyedi fejlesztésű szűrőrendszert terveztem. A távdiagnosztikai rendszer első tervét és az azáltal elért adatmennyiség csökkentést is bemutatom, majd a következtetések levonása után az újabb rendszer terve szerepel, valamint az érvek mellette. Az új rendszerbe választott ARM mikrovezérlő programjának bemutatása is itt olvasható. 3

6 2. A vezeték nélküli kommunikációs hálózat kiválasztása A távdiagnosztizáláshoz használt vezeték nélküli kommunikációs hálózattal szemben támasztott legfontosabb követelmény a teljes rendelkezésre állás és a lefedettség. Ez azt jelenti, hogy a járművet bárhol és bármikor el tudjuk érni. További elvárások még a megbízhatóság és a könnyen kezelhetőség. A dolgozatom elkészítése során, a Magyarországon használt vezeték nélküli kommunikációs hálózatokat vizsgáltam meg. Az első követelmény már nagyon leszűkíti a lehetséges megoldásokat, ugyanis nem használható semmilyen rádiós rövidhullámon keresztül biztosított hozzáférés. A szórt spektrumú rádiós hálózatok kis adóteljesítményük miatt nagy távolságokra nem alkalmasak. Mindenképpen olyan megoldás kell, amely teljes lefedettséget nyújt az adott területen, azaz a közlekedésben. Ilyen vezeték nélküli technológia például a műholdas adatátvitel, ami korlátlan távolságot és nagy sebességet biztosít. Ez azonban több szempontból sem alkalmazható távdiagnosztikai rendszerben, ugyanis a kiépítése költséges, jelentős eszköz- és szerelési igénnyel jár, például külső antenna felszerelését követeli meg. Hátránya még, hogy a kapcsolat minősége kevésbé kiszámítható, erősebben függ az időjárástól is. Napjainkban rohamosan fejlődnek az egyes szélessávú mobil internet szolgáltatások (EDGE, 3G/HSPA), ám ezek nem nyújtanak teljes lefedettséget, még csak a nagyvárosokban és azok környékén érhetőek el. Hazánk területén csak a GSM hálózat felel meg az elvárásoknak, ami közel 100 százalékos lefedettséget biztosít. A magyarországi három legnagyobb mobilszolgáltató GSM és mobil internet lefedettségét 1. sz. Melléklet tartalmazza A GSM hálózat felépítése A GSM (Global System for Mobile communications globális rendszer a mobilkommunikációhoz) a világ legelterjedtebb digitális mobil telekommunikációs rendszere. Körülbelül négy milliárd ember használja világszerte több mint 212 országban. Európában, Ázsiában és Ausztráliában a 900 és 1800, míg Észak- és Latin-Amerikában a 850 és 1900 MHz-es frekvenciákon használják. A mai GSM (2G) különbözik elődjétől, mivel a jel- és a beszédcsatornák is digitálisak. Ez lehetővé tette az adatátvitel egyszerű beépítését a rendszerbe. A GSM rendszer egy celluláris rádióhullám alapú hálózatot takar, ami azt jelenti, hogy az adott terület cellákra van osztva. Minden cella rendelkezik egy fix bázis átviteli állomással (BTS Base Transceiver Station), amely rádióinterfészen 4

7 keresztül közvetlen kapcsolatban van a mobil készülékekkel és továbbítja a jelüket a megfelelő állomásokhoz. A cellákra épülő hálózatban a rendelkezésre álló frekvenciák többször is felhasználhatók. A GSM hálózat 4 alrendszerből áll alább[1]: mobil állomás (MS Mobile Station), bázisállomás alrendszer (BSS Base Station Subsystem), hálózati és kapcsoló alrendszer (NSS Network and Switching Subsystem), üzemeltetési alrendszer (OSS Operation SubSystem) ábra: GSM hálózat struktúrája A mobil állomás és az adótorony között időosztásos elven működő, többszörös hozzáférésű TDMA (Time Division Multiplexing Access) rádiócsatornán történik az információtovábbítás. Speciális titkosító algoritmus biztosítja a továbbított információnak a lehallgatás elleni védelmét, legyen az beszéd, SMS vagy adat. A rendszer funkcionális egységeit interfészek választják el. Ezek az interfészek: Um rádió interfész (MS BTS), A-bis interfész (BTS BSC) és A interfész (BSC MSC). 5

8 2.2. GPRS kommunikáció Az adatátvitelt a GSM hálózaton GPRS (General Packet Radio Service) technológia segítségével, vagy adathívással oldhatjuk meg. Az adathívás esetén modem modem kapcsolat létesül. A GSM beszédcsatornáit használja, ahol az adatok megszabott formátumban kerülnek továbbításra. Az adatátvitel 9600 bps sebességgel történik egy csatornán, befejeztével a kapcsolat bomlik. Az adathívásnál nagyobb átviteli sebességre képes a GPRS, ugyanis ez a csatornákat össze tudja kapcsolni, ezért ezt a protokollt mutatom be részletesebben. A GPRS csomagkapcsolt, IP-alapú mobil adatátvitelt biztosít. A GPRS hálózatot használó készülékek adatátviteli sebessége nagyban függ a szabad beszédcsatornák számától, hiszen a GPRS tulajdonképpen a GSM hálózat kihasználatlan TDMA csatornáit kapcsolja össze. [2] A GPRS a GSM hálózattal együttműködik, kiegészíti azt egy csomagkapcsolt hálózattal, az előfizető virtuálisan mindig a hálózathoz (GPRS részéhez) kapcsolt állapotban van. A szükséges járulékos csomópontok a GGSN (Gateway GPRS Support Node) és a SGSN (Serving GPRS Support Node). Az SGSN a szolgáltatási területen található összes felhasználó számára érkező és onnan induló csomagok irányításáért felelős. Nyomon követi a felhasználók mozgását, biztonsági feladatokat és hozzáférés vezérlést lát el. Az egyes csatornákhoz (adott esetben összevont időrésekkel) való hozzáférés megosztott. Az SGSN a bázisállomás alrendszerhez (BSS - Base Station Subsystem) kapcsolódik. A BSSen belül ezért egy új funkcionális csomópont, a Csomag Vezérlő Egység (PCU - Packet Control Unit) szükséges. Az elrendezés úgy is felfogható, mint két, párhuzamosan működő, egymásra ültetett (overlay) rádiórendszer, az egyik az áramkör kapcsolt (hagyományos GSM), a másik csomagkapcsolt (GPRS), melyeknek azonban rádiós erőforrásai közösek. A GGSN egyik oldalról az SGSN-hez kapcsolódik, másrészt átjárót valósít meg más csomagkapcsolt hálózatok felé. A GPRS alkalmazása azzal az előnnyel jár, hogy a szolgáltató számlázásának alapja az átvitt bitek száma, és ez független a hálózatra virtuális kapcsolódás időtartamától. A készülékeket ún. Multislot osztályokkal szokták jellemezni, mely megadja, hogy a készülék maximum hány beszédcsatornát tud összekapcsolni. Multislot osztályok 1-től 32-ig léteznek. Az első osztályú 2 csatornát, míg a 32-es osztályú 6 beszédcsatornát tud összefogni. Csatornánként a maximum sebesség 13,4 kbps, így elméletileg 80 kbps-os sebességet is el tudunk érni. Gyakorlatban a letöltési sebesség kbps között szokott mozogni és a maximális feltöltési sebesség kbps lehet. 6

9 1. táblázat: Két magyarországi szolgáltató sebesség korlátja és lefedettsége [3] GLS GFS Beltéri országos lakossági ellátottság (%) Kültéri országos földrajzi lefedettség (%) 1. szolgáltató 30 kbit/s 8 kbit/s 98,0 95,6 2. szolgáltató 30 kbit/s 8 kbit/s 99,1 99,6 GLS/GFS: Garantált letöltési sebesség / garantált feltöltési sebesség. Azon sebesség, melyet a 229/2008 (IX.12.) Korm. rendelet alapján, a szolgáltató az előfizetők számára az esetek 80 %-ban garantál. Kültéri országos földrajzi lefedettség: Mobilinternet tekintetében egységesen azon terület aránya az ország teljes területéhez viszonyítva, melyen belül szabadtéren, a garantált le- és feltöltési sebesség elérhető, és ez méréssel igazolható. Beltéri lakossági ellátottság: Az egyes települések belterületi határain belül a lakosság eloszlását egyenletesnek feltételezve, az adott település beltéri földrajzi lefedettségi aránya (ahol beltéren, a garantált le- és feltöltési sebesség elérhető, és ez méréssel igazolható), szorozva a KSH nyilvántartásában szereplő lakosok számával. Az így megállapított, ellátott lakosok számát viszonyítjuk az ország összes lakosának számához. [3] A GSM hálózatra egy GSM/GPRS modem segítségével lehet küldeni az adatokat. A forgalomban lévő modemek többsége valamilyen soros interfészen keresztül vezérelhető. Ez azt jelenti, hogy a GSM alapú továbbításhoz először soros kommunikációra kell átalakítani az adatokat, ez nem ront az átviteli sebességen, ugyanis a GSM-nek kisebb a sávszélessége. 7

10 3. Járművek kommunikációs rendszere A Robert Bosch GmbH 1983-ban kezdett el egy belső projektet, amely célja egy járműfedélzeti hálózat kifejlesztése volt. A CAN (Control Area Network) protokoll hivatalos bemutatója 1986-ban történt meg, a Society of Automotive Engineers (SAE) kongresszuson, Detroit-ban. Az első CAN vezérlő chipet 1987-ben adta ki az Intel és a Philips cég együttműködve. A Bosch által továbbfejlesztett változat 1991-ben debütált CAN 2.0 néven. Már ebben az évben bevezetett egy CAN alapú magasabb rétegű protokollt a Kvaser cég. Egy évvel később, 1992-ben az első CAN hálózatot használó autó gördült le a Mercedes-Benz gyártósoráról és még ebben az esztendőben jött létre a CAN in Automation (CiA), amely felhasználók és gyártók nemzetközi csoportja. A CAN alap szabványát, az ISO at 1993-ban tették közzé. A CAN teljesíti az amerikai OBD-II jármű diagnosztikai standard előírásait, mely 1996-tól érvényes az USA-ban, és az EOBD szabványt, mely az európai benzinüzemű járművekre 2001-től, dízelekre pedig 2004-től alkalmazandó. [4] 3.1. A CAN buszrendszer A CAN busz célja elsősorban az volt, hogy az autóipar decentralizációs törekvéseihez megbízható eszközként szolgáljon, amire azért volt szükség, hogy kiválthatóak legyenek a költséges, nagy tömegű, sok helyet foglaló kábelkötegek, ezért az alábbi célkitűzéseknek kellett megfelelnie: rendkívüli üzembiztosság, hibamentes átvitel, igen rövid ciklusidő, viszonylag magas átviteli sebesség mellett, adattartalom legyen optimális az autóipari érzékelők részére (0-8 bájt), busz kiépítése, állomások csatlakoztatása legyen egyszerű, broadcast támogatás. A CAN egy multi-master, üzenetszórásos soros busz, melynek elsődleges feladata az ECUk (Electronic Control Unit) összekapcsolása. Egy autóban jelenleg akár 70 ECU is lehet. A legnagyobb ezek közül a motor ECU-ja, de jellemzően a váltónak, fékeknek, műszereknek, világításnak, ajtóknak, és a riasztónak is saját ECU-ja van. 8

11 3.1. ábra: Járművek CAN hálózata 2. táblázat: A CAN busz műszaki adatai [5] Buszhozzáférési eljárás CSMA/CA Adatátviteli sebesség 5 kbps...1 Mbps Topológia busz Telegramszerkezet Azonosító, vezérlőkód, Data Unit, hibaellenőrző kód, végkód Buszhossz 40 m (átlagos, kábeltől és átviteli sebességtől függ) Buszrésztvevők száma 30 (a kiviteltől függ) Átviteli mód ISO szerinti (NRZ) Átviteli közeg árnyékolt vagy árnyékolatlan sodrott érpár Átviteli hibavédelem CRC Busz topológiájú, azaz a rácsatlakozó eszközök egyenrangúak, ezért mindenképpen biztosítani kell az arbitrációt. Ezt a CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance) buszhozzáférési eljárás alkalmazásával oldja meg. A buszrendszer 9

12 adatátviteli sebessége 5 kbps-tól 1 Mbps-ig változhat. A CAN-busznak több fizikai réteg definíciója is létezik. Például a gyors ISO és a lassú ISO Ezek a fizikai szinteken térnek el egymástól, azaz vezetéken összekötve nem kompatibilisek. Mivel az ISO at alkalmazzák szélesebb körben és a vizsgált járművek is ezt használják, ezért a továbbiakban csak ennek a tulajdonságait részletezem. A busz hossza átlagosan 40 méter, de a maximális hosszúság függ a kábeltől és az adatátviteli sebességtől is. A buszra csatlakoztatható eszközök száma a kiviteltől függ, de általában legfeljebb 30 résztvevő lehet. Több fizikai kialakítása is létezik, az ISO szerint NRZ (Non Return to Zero) kódolást használ átviteli módként, tehát az egymás után következő 1-es bitértékek között a feszültségszint nem esik vissza nullára. Ennek előnye, hogy egy bit átviteléhez egy bitidő szükséges, viszont a szinkronizáció nehézkesebb, mint a minden bit átvitelénél átmenetet biztosító kódok esetén. Az átviteli közeg, azaz a kábelezés árnyékolt, vagy árnyékolatlan sodrott érpár lehet. A CAN busz a jelátvitelhez két vezetéket alkalmaz, a CAN-H (High) és CAN-L (Low) vezetékeket (ellensodrott, esetleg árnyékolt). A zavarvédelem miatt az ezeken futó jelek ellenfázisúak, azonos jelekre ellenkező feszültségszint irányokba térnek ki ábra: A CAN jelszintek recesszív és domináns bit esetén A CAN-H és CAN-L buszvezetékek közötti feszültségkülönbségből állapítják meg, hogy domináns vagy recesszív bit érkezett. A recesszív bit a logikai 1-est szimbolizálja, ennek az átvitelekor 0 V a feszültségkülönbség, mivel mindkét vonalon 2,5 V feszültség van. 10

13 Domináns bit, azaz logikai 0 átvitelkor 2 V a feszültségkülönbség, mivel a CAN-H vonal 3,5 V-on, a CAN-L vonal pedig 1,5 V-on van. A megengedett feszültségkülönbségek recesszív bit esetén maximum 0,5 V, domináns bit esetén minimum 0,9 V. [5] Az ISO által meghatározott CAN buszrendszer technikai jellemzői közé tartozik még a busz késleltetési idő, ami 5 ns/m és a véglezáró ellenállás értéke, ami 120 Ω-os általában, de minimum 85, maximum 130 Ω lehet. Node 1 Node 2 Node n... CAN-High 120 Ω 120 Ω CAN-Low 3.3. ábra: A CAN buszrendszer topológiája A CAN üzenetorientáltan működik, vagyis ha egy résztvevő adatokat akar küldeni, összeállítja és azonosítóval látja el a telegramot. Az azonosító csak egyszer létezik, ezért ha egy résztvevő felismeri azt a buszon, egyértelműen tudja, hogy mely adatok következnek. Így a busz minden résztvevője az azonosító alapján el tudja dönteni, hogy akarja-e venni az üzenetet, függetlenül attól, hogy ki küldi. A CAN rendszerben tehát az adatok az azonosító révén, tartalom szerinti címzéssel jutnak el a megfelelő vevőhöz. Minden vevőnek kellő intelligenciával kell rendelkeznie az adatok azonosításához. Öt fajta üzenetkeretet támogat: normál üzenetkeret, kibővített üzenetkeret, kéréses üzenetkeret, hiba üzenetkeret, túlterheltség-üzenetkeret. A CAN 2.0-nak kétfajta szabványa létezik, amelyek csak az üzenetkeretben térnek el. A CAN 2.0A szabvány nem támogatja a kibővített keretformátumot, így alap üzeneteket csak normál kerettel küldhetünk. A CAN 2.0B támogatja a kibővített üzenetkeretet is. A két 11

14 keret közötti különbség, hogy a normál üzenetkeret 11 bites azonosítót használ, míg a kibővített 29 biteset. S O F CAN ID 11 bit R T R Control Field 6 bit Data Field byte CRC Field 16 bit A C K 2bit End of Frame 7 bit S O F CAN ID 11 bit S R R I D E CAN ID 19 bit R T R Control Field 6 bit Data Field byte CRC Field 16 bit A C K 2bit End of Frame 7 bit 3.4. ábra: CAN normál és kibővített üzenetkeret A kompatibilitás úgy teljesül, hogy a CAN 2.0B használhatja az összes üzenetkeretet. A CAN 2.0A nem ismeri a kibővített keretet, így az ilyen rendszerekben a normál üzenetkeret 11 bitje összesen 2048 azonosító kódot (ID - identifier) tesz lehetővé, de valójában csak 2032 féle realizálható. Nagyobb rendszer kialakítását teszi lehetővé a CAN 2.0B szabvány kibővített üzenetkerete, amelynél az azonosító bitek száma 29, ami elvileg különféle üzenet továbbítását biztosítja Jármű csoportok összehasonlítása A járművek belső hálózata két csoportba osztható. Első csoportba tartoznak a személygépjárművek és a kis teljesítményű járművek, amelyeken a diagnosztizálás az ISO es szabvány szerint definiált, a másik csoportba a közepes és nagy teljesítményű járművek, melyek szabványa a SAE J1939. Ezt a két szabványt hasonlítom össze a diagnosztikai szabványok, a fizikai interfész, a csatlakozók, a protokoll és a hibakódok alapján. A fő különbség, hogy míg a SAE J1939 egyes részeiben definiált az összes szabvány a közepes és nagy teljesítményű járművekhez, addig a másik csoportban az ISO nem tartalmaz mindent és összhangban van néhány másik SAE szabvánnyal is. A protokoll szinten az ISO a CAN 2.0A-t, a J1939 a 2.0B-t alkalmazza, azaz az első 11 bites, a második 29 bites azonosítókat használ. A J1939-et a jármű hálózatán normál kommunikációra és diagnosztizálásra is használják, viszont a másik szabványt csak diagnosztizálásra. Elsődleges funkcionalitása a J1939-nek a diagnosztikai üzenetek, amelyeket ciklikusan küldenek, az ISO nek az egyedi kommunikáció Service ID- 12

15 kkel. Hibakódokat mindkét szabvány használ, de a J1939 még esemény számlálását is tartalmaz e mellett. Az ISO egy figyelmeztető lámpát határoz meg, míg a J1939 négyet. [6] A következő táblázat szemlélteti a járművek két csoportját és a hozzájuk tartozó SAE és ISO diagnosztikai szabványokat. 3. táblázat: A SAE és ISO diagnosztikai szabványok SAE ISO Személyautók és J1930 feltételek és definíciók ISO11898 (5 rész) CAN kis teljesítményű J1962 csatlakozó járművek J1978 vizsgáló eszköz ISO15765 (4 rész) J1979 diagnosztikai szolgáltatások diagnosztika CAN-en J2012 hibakódok J2186 kapcsolat biztonság J2534 pass-thru ISO15031 (7 rész) OBD CAN-en J1699 OBD megfelelők Közepes és nagy teljesítményű járművek J1939 (összetett részek) J2403 feltételek és definíciók Nincs Egyes esetekben több szabvány keveredik ugyanazon a járművön. A közepes és nagy teljesítményű járműveknél ez sokkal egyszerűbb, mivel azok kommunikációját jól átfogja a SAE J1939. Az ISO egyes részei leképezhető SAE szabványokra a következőképpen: ISO : J1930 feltételek és definíciók. ISO : J1962 diagnosztikai csatlakozó. ISO : J1978 diagnosztikai eszközzel szembeni elvárások. ISO : J1979 diagnosztikai szolgáltatások. ISO : J2012 hibakód definíciók. ISO : J2186 adatkapcsolat biztonság. Fizikai szinten a SAE J és 15-ös része alkotja az egyik csoportot, a másikat az ISO , ISO és ISO A második csoport busz sebessége kétszer akkora, azaz a J Kbps, a másiknak 500 Kbps. A J1939/11-es szabványrész sodrott, 13

16 árnyékolt érpárt határoz meg, míg a többi árnyékolatlant. A SAE szabvány meghatározza a maximális ECU számot, a 11-esnél 30, a 15-ösnél pedig 10, ezzel szemben az ISO szabványoknál nincs meghatározva maximum. A diagnosztikai csatlakozók is eltérőek a szabványoknál. Az ISO ban 16 tűs a csatlakozó, amit a J1962 is definiál. A J1939/13 szabványrész 9 tűs csatlakozót használ diagnosztizálásra ábra: Diagnosztikai csatlakozók (bal oldalon az ISO , jobb oldalon a SAE J által meghatározott) A CAN protokoll az alapja mindkét szabványnak, ezen belül az ISO a normál üzenetkeretet használja, azaz 11 bites azonosítót. Az ISO ben az OBD kezeli az ECU-k azonosítását a következő funkciókra: OBD diagnosztikai kérésekhez funkcionális Request ID (forrás cím nem szükséges, mivel csak egy diagnosztikai teszter megengedett a buszon egy időben), forrás ECU azonosító a diagnosztikai válaszokhoz, a legtöbb OEM-nek (Original Equipment Manufacturer) van saját azonosító hozzárendelési szabványa. A J1939 a kiterjesztett CAN üzenetformátumot alkalmazza (29 bites azonosító). Három komponens, amit a szabvány definiál az azonosítóban: üzenet prioritás, Parameter Group Number (meghatározza az adatot a DATA területen SAE szabványosított és tulajdonosi PGN-ek lehetségesek), forrás cím. 14

17 Diagnosztikai üzenetek struktúrájának összehasonlítása: ISO Tester [[Cél ID] [Kért szolgáltatás + kért adat]] [[Forrás ID] [Kért szolgáltatás ID + kért adat] ECU J1939 Tester [[Prioritás + Request PGN + Cél és forrás cím] [Kért PGN] [[Prioritás + Kért PGN + Cél és forrás cím] [PGN adat] ÉS ECU Ciklikus diagnosztikai üzenetek (pl. DM1) 3.6. ábra: Az ISO és J1939 által definiált diagnosztikai folyamatok A hibakódokat a J1939/73-as szabványrész definiálja. A DTC (Diagnostic Trouble Code) felépítése a következő ábrán látható. DTC Byte1 Byte2 Byte3 Byte4 Low Byte SPN Mid Byte SPN Conversion MSB < > MSB < > SPN 3 MSB + FMI Method + SPN FMI C M OC ábra: A J1939 által meghatározott hibakód felépítése Az ISO által meghatározott Diagnostic Trouble Code pedig a következő ábrán. DTC Byte 1 Byte 2 Byte 3 SAE Code Number FTB ábra: Az ISO es szabványban definiált hibakód 15

18 Itt öt karakterből álló hibakódot határoz meg a szabvány. Az első és második karakter is két-két bit nagyságú, azaz 4 lehetőséget határoz meg, a harmadik, negyedik és ötödik karakterek 4 bit hosszúságúak, értékük 0-tól F-ig terjed. Az első karakter értéke P, C, B vagy U, a második karakter pedig 0, 1, 2, vagy Tehergépjárművek, autóbuszok belső hálózata A SAE J1939-et használják a haszongépjárművek területén az azokban zajló kommunikációra. A SAE J1939 a CAN-t (ISO 11998) használja, mint fizikai réteg. Ez határozza meg, hogy milyen adatokat, valamint hogy azokat hogyan kell közölni az elektronikus vezérlőegységek (Electronic Control Unit ECU) között a jármű hálózatán. Tipikus vezérlők a motor, fék, váltó, stb. Jármű belső hálózata Motor Váltó Fék rendszer Műszerfal 3.9. ábra: Tipikus J1939 jármű belső hálózat Léteznek más szabványok is, amelyek a SAE J1939-ből származnak. Ezek a szabványok a SAE J1939 alapvető jellemzőit használják más és más paraméter csoportokkal és módosított fizikai rétegekkel. Ezek a szabványok a következők [7]: ISO Mezőgazdasági és erdészeti traktorok, gépek Meghatározza a kommunikációt a traktor és a munkagépek között egy eszköz buszon. Részletez néhány szolgáltatást az alkalmazási rétegen, mint például virtuális terminál, traktor ECU, feladat vezérlő és fájl szerver. Hozzáfűz még egy kiterjesztett átviteli protokollt és munkakészlet kezelést. 16

19 NMEA Tengerészeti elektronikus eszközök soros adat hálózata (National Marine Electronics Association) Ez határozza meg a paraméter csoportokat a tengerészeti eszközök közötti kommunikációhoz. Specifikálja még a kiegészítő, gyors csomag alapú átviteli protokollt. ISO Digitális információváltás a vontató és a vontatott jármű között (Truck- Trailer) Meghatározza az információ cserét a közúti jármű és a vontatmány között. Ugyanazon paraméter csoportot használja, mint a J1939, csak eltérő fizikai rétegen 125 kbit/s átviteli sebességgel. FMS Flotta menedzsment rendszer Az FMS szabvány meghatároz egy átjárót a J1939 jármű hálózat és egy flotta menedzsment rendszer között. A SAE J1939-et teherautók, kamionok és autóbuszok belső hálózata mellett dízel erőátviteli gépekben is alkalmazzák. A J1939 kihasználja a CAN legfontosabb jellemzőit, mint például a maximális megbízhatóság, kiváló hibaészlelés és feltárás, ütközésmentes busz arbitráció. [8] A J1939 sajátos jellemzői: kiterjesztett CAN azonosító (29 bit), 250 kbit/s átviteli sebesség, peer-to-peer és broadcast kommunikáció, átviteli protokollok akár 1785 bájt adathoz, hálózat menedzsment, paraméter csoportok meghatározása haszongépjárművekhez és másokhoz, a gyártó specifikus paraméter csoportokat is támogatja, diagnosztikai funkciók, maximum 30 node (ECU) a hálózaton. A következő ábrán látható az ISO/OSI 7-rétegű modellen alapulva a SAE J1939 szabvány csoport. [9] 17

20 7. Alkalmazási réteg 7. Alkalmazási réteg J1939/7x Magasabb szintű protokoll nélkül 6. Megjelenítési réteg 5. Viszonylati réteg 4. Szállítási réteg 3. Hálózati réteg Magasabb szintű protokollal 6. Megjelenítési réteg 5. Viszonylati réteg 4. Szállítási réteg 3. Hálózati réteg J1939/6x J1939/5x J1939/4x J1939/3x 2. Adatkapcsolati réteg 2. Adatkapcsolati réteg J1939/2x 1. Fizikai réteg 1. Fizikai réteg J1939/1x ábra: Az ISO-OSI modell és a SAE J1939 kapcsolata Paramétercsoportok Egy paramétercsoport olyan paraméterek készlete, amelyek egyazon témához tartoznak és azonos az átviteli sebességük. A paramétercsoportok lényegesek az alkalmazások meghatározásához. A paramétereket megtalálhatjuk az alkalmazási réteg leírásában (SAE J ). A paramétercsoport hossza nem korlátozódik egy CAN keret hosszára. Általában egy paramétercsoport hossza 8 bájt, de akár maximum 1785 bájt is lehet. A több mint 8 bájtos paramétercsoportoknak szükségük van egy átviteli protokollra a továbbításhoz A CAN azonosító értelmezése A J1939 üzenetnek a CAN azonosítója tartalmazza a paramétercsoport számát (továbbiakban PGN Parameter Group Number), a forrás címet, a prioritást, két adatlap bitet (alap és kiterjesztett) és a cél címét (csak a peer-to-peer paraméter csoport esetén). Az azonosító összetétele a és ábrán látható és az alábbiakból áll: Az első 3 bit határozza meg a prioritást az arbitrációs folyamat közben. Ez 8 prioritási szintet határoz meg, a 0-s érték (000) a legmagasabb prioritású, míg a 8-as (111) a legalacsonyabb. Látható, hogy a 0-s érték a domináns ugyanúgy, mint ahogy fentebb bemutattam. A magas prioritású üzenetek az időkritikus adatoknak vannak fenntartva, mint például a forgatónyomaték vezérlő adat a váltótól a motorhoz. Az alacsony prioritásúak alkalmasak a nem időkritikus adatoknak, mint például a motor konfigurációs adatai. A PDU Format mező határozza meg, hogy az üzenet peer-to-peer vagy broadcast, a következőképpen: Ha a PDU Format kisebb 240-nél (< 0xF0), akkor peer-to-peer az üzenet és a PDU Specific-ben a célállomás címe (Destination Address) van. A Global (255) is felhasználható cél címnek, ekkor a paramétercsoport célja az összes eszköz. 18

21 Ha a PDU Format nagyobb vagy egyenlő 240-nél (>= 0xF0), akkor broadcast az üzenet és a PDU Specific a csoport kiterjesztése (Group Extension). Minden paramétercsoportot egy egyedi szám révén címeztek meg, ez az egyedi szám a PGN. A PGN-hez egy 24 bites értéket használnak, ami 6 nulla értékű bitből, a PDU Format-ból (8 bit), a PDU Specific-ből (8 bit), a Data Page-ből (1 bit) és az Extended Data Page-ből (1 bit) tevődik össze. Két típusa van a PGN számnak: Globális PGN-ek azonosítják azokat a paramétercsoportokat, amelyeket mindenkinek küldenek (broadcast). Itt a PDU Format, a PDU Specific, a Data Page és az Extended Data Page is használt a paramétercsoport megfelelő azonosításához. A globális PGN-eknél a PDU Format 240 vagy nagyobb és a PDU Specific mező a Group Extension ábra: A paramétercsoport száma a PDU1 szerint 19

22 Egyedi PGN-eket csak a meghatározott eszközökhöz küldött paramétercsoportok alkotják (peer-to-peer). Itt csak a PDU Format, a Data Page és az Extended Data Page használt a paramétercsoport megfelelő azonosításához. A PDU Format 240- nél kisebb és az utolsó 8 bit értéke ábra: A paramétercsoport száma a PDU2 szerint Ezt a két csoportot szokás PDU1 és PDU2-nek nevezni, a PDU1 a peer-to-peer üzenet, a PDU2 a broadcast. Ezzel a PGN felbontással (16 * 256) = 4336 különböző paramétercsoport lehetséges minden adatlapon belül. A Data Page bit és az Extended Data Page bit segítségével 4 különböző adatlapból lehet választani, ezt mutatja az alábbi táblázat. 20

23 4. táblázat: Az adatlapok és a hozzájuk tartozó bitek Extented Data Data Leírás Page bit Page bit 0 0 SAE J1939 Page 0 Parameter Groups 0 1 SAE J1939 Page 1 Parameter Groups (NMEA2000 ) 1 0 SAE J1939-nek fenntartott 1 1 ISO definiálja Az Extended Data Page a jelenlegi járművekben továbbított üzenetek esetén mindig 0, ezt a bitet későbbi célokra tartják fenn. Az azonosító utolsó 8 bitje a forrás cím, az adó ECU (node) címe. 254 cím lehetséges a hálózaton és minden címnek egyedinek kell lennie. Az ECU-k nem tudják megosztani a címüket. A PGN-ek függetlenek a forrás címtől. Minden ECU adhat üzenetet. Itt jegyzem meg, hogy a CAN szabvány önmagában nem támogatja a node (ECU) címeket, csak az üzenet azonosítókat. A és ábrákon egy-egy üzenet küldése és fogadása látható ábra: Példa az RPM adat küldésére 21

24 3.14. ábra: Példa az RPM adat fogadására Suspect Parameter Number (SPN) Egy paramétercsoportnak vagy összetevőnek minden egyes paraméteréhez hozzárendelnek egy SPN számot. Ezt diagnosztikai célból alkalmazzák egy vezérlő alkalmazás (CA Controller Application) rendellenes működésének azonosítására és jelentésére. Az SPN egy 19 bites szám, ami 0-tól ig terjedhet. A gyártói paramétereknek től ig terjedő tartomány van fenntartva. Egy paramétercsoport megadási példa [10]: Név Motor hőmérséklet (Engine Temperature 1- ET1) Átviteli periódusidő 1s Adat hossz 8 bájt Extended Data Page 0 Data Page 0 PDU Format 254 PDU Specific 238 Alap prioritás 6 PGN (00FEEE hex ) 22

25 5. táblázat: Az előző paraméterhez tartozó adat leírása Bájt Leírás SPN 1 Motor hűtőfolyadék hőmérséklet Motor üzemanyag hőmérséklet 174 3,4 Motor olaj hőmérséklet 175 5,6 Motor turbófeltöltő olaj hőmérséklet Motor intercooler hőmérséklet 52 8 Motor intercooler termosztát nyitva 1134 Egy SPN megadási példa: SPN 110 Motor hűtőfolyadék hőmérséklet Adat hossz 1 bájt Felbontás 1 C/bit Eltolás -40 C Adattartomány C Típus Mért Referencia (00FEEE hex ) 6. táblázat: PGN tartományok DP PGN tartomány (hex) PGN-ek száma SAE vagy gyártó Kommunikáció EE SAE PDU1 0 00EF00 1 GY PDU1 0 00F000 00FEFF 3840 SAE PDU2 0 00FF00 00FFFF 256 GY PDU EE SAE PDU1 1 01EF00 1 GY PDU1 1 01F000 01FEFF 3840 SAE PDU2 1 01FF00 01FFFF 256 GY PDU2 SAE SAE által kijelölt GY Gyártó specifikus, tulajdonosi üzenetek 23

26 3.15. ábra: Az SPN, PGN és a CAN üzenetkeret kapcsolata Speciális paramétercsoportok A SAE J meghatároz néhány paramétercsoportot az adatkapcsolati rétegen: a) Kérés paramétercsoport A kérés paramétercsoport (RQST, PGN 00EA00 hex ) elküldhető az összes vagy csak egy bizonyos CA-nak, hogy kérjen egy megadott paramétercsoportot. A RQST tartalmazza a kérni kívánt paramétercsoport PGN számát. Ha az adott kérelemnek a címzettje nem tud válaszolni, akkor küldenie kell egy negatív visszaigazolást. A RQST adat hossza 3 bájt és ez az egyetlen paramétercsoport 8 bájtnál kevesebb adathosszúsággal. b) Visszaigazolás paramétercsoport A visszaigazolás paramétercsoportot (ACKM, PGN 00E800 hex ) arra lehet használni, hogy küldjön egy negatív vagy pozitív visszaigazolást, azaz választ a kérelemre. c) Parancsolt cím paramétercsoport A parancsolt cím paramétercsoportot (CA, PGN 00FED8 hex ) a CA címének megváltoztatására lehet használni. Az adat mezőben meg kell adni az eszköz nevét és az új címét, ez összesen 9 bájt, amit egy üzenetben nem lehet elküldeni, ezért ez mindig átviteli protokollt használ. d) Átviteli protokoll paramétercsoport Az átviteli protokoll paramétercsoportot (TP-CM, PGN 00EC00 hex és TP-DT, PGN 00EB00 hex ) használják, ha 8-nál több adat bájtot kell átvinni a paramétercsoportoknak. Működését később részletezem. e) Gyártó specifikus paramétercsoportok PDU1-et vagy PDU2-t is használhatnak, azaz lehet peer-to-peer vagy broadcast üzenet is. (Proprietary A, PGN 00EF00 hex és Proprietary B, PGN 00FF00-00FFFF hex ) 24

27 Hálózat menedzsment Az Electronic Control Unit (ECU) szoftvere a Controller Application (CA). Egy ECU tartalmazhat egy vagy több CA-t is ábra: Az ECU-k és a CA-k kapcsolata Minden egyes CA-nak van egy egyedülálló címe és egy kapcsolódó eszköz neve. Valamennyi üzenet, amit a CA elküld, tartalmazza ezt a forrás címet. A lehetséges címek a következők: Érvényes forrás címek CA-knak és Használható CA-knak előnyben részesített címmel és definiált függvényekkel Elérhető minden CA-nak. 254 Null. 255 Globális. A legtöbb CA-nak, mint a motor, váltó, stb. van egy preferált címe. Mielőtt egy CA használhatna egy címet, be kell regisztrálnia magát a buszon. Ezt az eljárást nevezik address claiming-nek (cím igénylésnek). Eszerint az eszköz küld egy cím igénylő paramétercsoportot (ACL, PGN 00EE00 hex ) a kívánt forrás címmel. Ez a paramétercsoport tartalmaz egy 64 bites eszköz nevet is. Az eszköz név tartalmaz információkat a CA-ról és leírja a fő funkcióját. A gyártó kódot a SAE-től kell kérni. A mezők értékeit a SAE J határozza meg. 25

28 3.17. ábra: A cím igénylő paramétercsoport eszköz név adata Kétféle cím igénylő folyamat van: a) Cím igénylő üzenet küldése Gyakori helyzet, hogy a CA küld egy cím igénylő paramétercsoportot az induláskor és vár egy meghatározott ideig. Ha nem érzékel címütközést, akkor egy megadott idő után el tudja indítani a normális kommunikációt. Az ECU-k fogadják a cím igénylést és feljegyzik azt a belső cím táblájukba ábra: A cím igénylő üzenet küldésének folyamata Abban az esetben, ha egy másik CA már használja azt a címet, címütközés következik be. Amelyik CA-nak nagyobb prioritású az eszköz neve az kapja meg a címet. A másik CAnak kell küldenie egy Cannot Claim Address paramétercsoportot, nullás (254) forrás címmel. 26

29 3.19. ábra: Cím igénylő folyamat cím ütközéssel A CA képességétől függ, hogy hogyan jár el, ha egy cím nem szerezhető meg. b) Kérelem cím igényléshez Egy CA képes érzékelni más CA-kat a hálózaton a kérelmező ACL paramétercsoport által. Itt engedélyezett a Null cím (254) használata, mint forrás cím, mielőtt a CA elvégezné a cím igénylő folyamatot. Ha a kérelem címzettje a Global (255) cím, akkor a hálózaton minden CA-nak válaszolnia kell az ACL paramétercsoporttal (beleértve a saját CA-t is, ha egy címet igényelt már). Ez egy szükséges eljárás, ha egy ECU később kapcsolódik be (például diagnosztikai eszköz). Ezzel meghatározható, hogy mely címek szabadok és, hogy milyen ECU-k vannak jelenleg a hálózaton ábra: Kérelem cím igénylésre 27

30 Cím képesség A SAE J meghatározza a következő képesség típusokat egy cím megszerzéséhez: a) Önkényes címzésre képes CA Egy belső algoritmus által választ címet magának. Az ilyen CA-k képesek arra is, hogy új címet válasszanak egy cím ütközés során. Ezt a képességet az Arbitrary Address Capable mező jelzi az eszköz nevében. b) Egyszerű címzésre képes CA Ezek a típusú CA-k csak egy címet használhatnak. Cím ütközéseknél nem tudnak másik címet választani. Ezek támogathatják a parancsolt cím paramétercsoportot vagy tulajdonosi mechanizmusokat a cím megváltoztatására. Az Arbitrary Address Capable mező ezeknél a CA-knál nincs beállítva Átviteli protokollok Több mint 8 adat bájt továbbítása átviteli protokoll segítségével történik ábra: Átviteli protokoll A peer-to-peer és broadcast kommunikációhoz két különböző protokoll van. Az átviteli protokollok (Transport Protocol TP) felhasználnak két speciális paramétercsoportot, amelyek a kapcsolatmenedzsment (Connection Management TP.CM) és az adat továbbítás (Data Transmission TP.DT). 28

31 3.22. ábra: A több mint 8 bájt adat felbontása Broadcast továbbításhoz a BAM (Broadcast Announce Message) protokollt használják. Itt egy BAM paramétercsoport után, az adó küldi az összes adatot legalább 50 ms időközönként. A BAM üzenet a következő komponenseket tartalmazza: a multi-packet üzenet PGN száma, a multi-packet üzenet mérete, a csomagok száma. Az első üzenetet a kapcsolatmenedzsment paramétercsoport (TP.CM) szerint küldi, majd az aktuális adatokat az adat továbbítás (TP.DT) szerint ábra: BAM továbbítás 29

32 Peer-to-peer átvitelnél az adó kezdeményezi a kapcsolatot egy Request To Send üzenettel. Ezután a vevő vezérli az átviteli protokollt a Clear To Send üzenettel és végül visszaigazolja azt az End of Message Acknowledge üzenettel. Ezek az üzenetek a kapcsolatmenedzsment paramétercsoportba tartoznak ábra: RTS/CTS átvitel Diagnosztika A SAE J1939 diagnosztikai funkciója a következő szolgáltatásokat tartalmazza: A rendellenes működés jelentése és azonosítása. Memória hozzáférés. Felügyeleti tesztek. Fontos paramétercsoport a diagnosztikai üzenetek 1 (DM1, PGN FECA hex ). Ha ez támogatott, akkor minden egyes CA ciklikusan elküldi a saját állapotát. A paramétercsoport tartalmaz állapotokat a következő lámpákhoz: Üzemzavar jelző lámpa. Piros féklámpa. Sárga figyelmeztető lámpa. Védelmező lámpa. 30

33 A műszeregységek arra használhatják ezt az információt, hogy jelentsék a rendszer állapotát a vezető számára. Továbbá a paramétercsoport tartalmazza a diagnosztikai hibakódokat (DTC). Együtt a feladó címével a hibásan működő komponenseket is lehet azonosítani ábra: Diagnosztikai hibakód A DTC 4 bájtot tartalmaz, amely magában foglalja az SPN-t, a Failure Mode Identifier-t (FMI) és egy Occurrence Count-ot. Ha a DM1 egynél több hibakódot tartalmaz, akkor átviteli protokollt használ. A diagnosztikai csatlakozót a J1939/13 szabványrész határozza meg. Ez a 9 tűs, kerek csatlakozó az előző alfejezet 3.5. ábrájának jobb oldalán látható. A csatlakozó lábkiosztása [11]: A Akkumulátor negatív B Akkumulátor pozitív C J1939 CAN-H (+) D J1939 CAN-L (-) E CAN árnyékolás F J1587 high (+) G J1587 low (-) A paramétercsoportok leírása, a CAN azonosító séma és a hálózat menedzsment együtt a vezérlőegységek a gyártókra kiterjedő együttműködését biztosítja. A J1939 az itt bemutatott mechanizmusok mellett leírja a fizikai tulajdonságokat és a buszon lévő szegmensek használatát is. 31

34 4. Autóbuszok hálózatának vizsgálata és szimulációja 4.1. Mérések végzése Első feladatom volt meghatározni a jármű kommunikációs rendszerének a sebességét, ehhez méréseket végeztem egy autóbuszon. A CAN buszrendszerre egy digitális oszcilloszkópot csatlakoztattam és a bitidőket figyeltem ábra: Egy bit idő a CAN hálózaton A mérésből megállapítható, hogy egy névleges bit idő 4 μs, ebből kiszámolhatjuk, hogy a közepes és nagy teljesítményű járművek belső buszrendszere 250 kbit/s-os adatátviteli sebességet használ. Ez sokkal nagyobb sebesség, mint az második fejezetben tárgyalt vezeték nélküli átvitel (GSM/GPRS) sebessége. Ebből következik, hogy nem tudunk egyszerre valós időben minden adatot átküldeni GPRS-en keresztül, aminek a feltöltési sebessége mindössze 8 kbit/s. A megoldások kereséséhez először fel kellett térképezni egy jármű belső kommunikációs hálózatának a tényleges adatforgalmát, ehhez végeztem méréseket több autóbuszon is az alábbi elrendezésben. 32

35 RS232 µc CAN 4.2. ábra: Az elvégzett mérések elrendezése Mivel a jármű hálózatának sebessége nagyobb, mint amit az RS-232 segítségével el tudunk érni, ezért az a lehetőség nem megoldható, hogy minden adatot átküldünk a számítógépnek és csak ott dolgozzuk fel. Mindenképpen valamilyen programozható vezérlőt kell használni, amely képes a CAN adatokat kezelni. A mérésekhez egy olyan mikrokontrollert használtam, amely támogatja a CAN 2.0A-t és 2.0B-t is, valamint a CAN szabványos funkcióit, az újraküldést, a busz arbitrációt, illetve a hibafelismerést is. Továbbá az eszköz rendelkezik RS-232, RS-485 és Ethernet interfészekkel, így a programozhatóságának köszönhetően számos ipari kommunikációs probléma oldható meg a segítségével. Az eszközben található egy beépített 120 Ω-os lezáró ellenállás, melyet szükség esetén ki-be lehet kapcsolni egy jumper segítségével. Ennek a bekapcsolására például akkor volt szükség, amikor laboratóriumi körülmények között létrehozott CAN hálózaton teszteltem a megírt programot. Viszont amikor kint a terepen próbáltam ki az eszközt, akkor ott egy már létező CAN-buszra csatlakozott, amelyet már elláttak a szükséges lezáró ellenállásokkal. Ilyenkor értelemszerűen ki kell kapcsolni az ellenállást, ellenkező esetben nagy eséllyel hibás működés tapasztalható. Az általam választott eszközön egy beágyazott operációs rendszer fut, ennek egyik nagy előnye, hogy nem szükséges alacsony szinten programozni az eszközt, hanem a már hozzá elkészített függvénykönyvtárak használatával, magasabb szinten tehetjük meg azt. 33

36 A vezérlőt közvetlenül a busz belső hálózatára csatlakoztattam rá és ez továbbította a kívánt adatokat egy számítógép felé ábra: CAN és RS232 kommunikációra alkalmas mikroprocesszor Az üzenetsűrűség meghatározása A vezérlőbe írt programot C nyelven készítettem el. Az első mérések esetében annyi a vezérlő feladata, hogy fogadja a CAN üzeneteket, és amikor jön egy új üzenet, növeli az üzenet számlálót. Beállítható még, hogy mennyi ideig folytassa a mérést, az idő letelte után elküldi az üzenetszámot a számítógépnek. A méréseknél három állapotot különböztettem meg: a) gyújtással, állandósult állapotban, azaz amikor a járművön már körülbelül fél perce rajta van a gyújtás, akkor futtattam le a mérést, b) járó motorral, azaz amikor a motort be is indítjuk, c) gyújtás ráadása előtt elindított mérés. Ez azért fontos, mert ekkor láthatjuk a cím igénylő üzeneteket is. Hat darab egyperces mérést végeztem különböző állapotokban. Az első mérést úgy indítottam el, hogy még a gyújtás nem volt rajta a járművön, csak a mérés indítása után kapcsoltam rá. A következő két mérés gyújtás alatt lévő járművön történt, az utolsó három mérésnél a motor is be volt indítva. 34

37 4.4. ábra: Hat darab egy perces mérés eredményei A diagramokon látható első érték kilóg a sorból. Ezt a fentebb ismertetett c) állapotú mérésnél tapasztaltam. Az üzenetszám nem mérvadó ennél a mérésnél, ugyanis a mérés elindítása után adtam rá a gyújtást az autóbuszra, és a vezérlő egy ideig nem kapott üzeneteket. Egy időben ráadni a gyújtást és elindítani a mérést kézzel nem lehetséges, mert ezek az üzenetek ms-onként továbbítódnak. A mért értékekből látható, hogy az egyes állapotokban az üzenetek száma nem változik sokkal, körülbelül üzenet továbbítódik a hálózaton egy perc alatt. Az öt mérésnél 15 üzenet volt a legnagyobb különbség a percenkénti üzenetszámok között, ez a kis számú üzenetszám változás abból adódik, hogy az egyes üzenetek más-más időközönként továbbítódnak a jármű hálózatán és így nem lehetséges két ugyanolyan üzenetszámú mérést végezni. A fenti ábrán látható, hogy alap esetekben átlagosan üzenet érkezik egy perc alatt, emellett a 3.4. ábráról leolvasható, hogy a kibővített üzenetkeret összesen 138 bitet tartalmaz, ha az adat mezőben 8 bájt adatot küldünk el. Ezekből az adatokból kiszámolva az információ mennyiséget: Ebből látszik, hogy 65 kbit információt kellene átvinni 1 másodperc alatt GPRS adatátvitellel, ami nem megoldható a korábban már bemutatott, gyakorlatban elérhető 35

38 maximális feltöltési sebesség miatt. Mindenképpen csökkentenem kell az átvinni kívánt adatmennyiséget. Az előzőek alátámasztásához több autóbuszon is méréseket végeztem az üzenetszám megállapítása céljából. Eltérő ideig tartóan mértem az egyes CAN hálózatok forgalmát, ezért az egyes autóbuszok összehasonlításához kiszámoltam az egy másodperc alatt érkező üzenetek számát ábra: Három különböző autóbuszon a másodpercenkénti üzenetszám Ez az üzenetszám eltérés is abból származik, hogy különböző azonosítókat használnak az egyes járművek. Vannak olyan azonosítót tartalmazó üzenetek, amelyek mindig a szabvány által meghatározott időközönként továbbítódnak, viszont vannak olyanok is, amelyeket az adott járműn található ECU határoz meg. Így az egyes üzenetek küldési gyakorisága eltérő, ezáltal változik a járműveken az üzenetszám értéke. A mérések alapján megállapítható, hogy körülbelül 500 üzenet érkezik, amely hozzávetőlegesen 69 kbit/s-nak felel meg. Az adatmennyiség lecsökkentéséhez tovább vizsgáltam az autóbuszok belső hálózatát Azonosítók felmérése A következő mérési funkció, amelyet elkészítettem az azonosító lista. Ez az érkező üzenetek azonosítóit vizsgálja meg. Minden egyes új üzenet beérkezésekor megvizsgálja, hogy az azonosító szerepel-e a listában, ha nem akkor beteszi azt és az azonosító darabszámát 1-re állítja. Ha az azonosító benne van a listában, akkor a darabszámát növeli 36

39 eggyel. A funkció elindulása előtt meg kell adni, hogy hány másodpercig fogadja az üzeneteket, így azonos idejű mérések végezhetők. Ez a funkció megadja, hogy milyen típusú üzenetek milyen gyakorisággal továbbítódnak a buszon, azaz hogy az egyes azonosítók hányszor jelennek meg egy megadott időn belül ábra: Azonosítók száma hat állapotban az első autóbuszon Már az első autóbuszon elvégzett mérések után észrevehető, hogy a fentebb említett a) és b) állapotok között nincs különbség, azaz a motor beindítása nem generál több üzenetet és másféle azonosítók sem keletkeznek. A továbbiakban ezt alap állapotnak nevezem, azaz alapból 58 féle azonosító van az általam vizsgált első autóbuszon. Ezek az üzenetek az ECU-k egymás közötti kommunikációjában játszanak szerepet. A gyújtás ráadása közben végzett mérésnél 16-tal több azonosító jelent meg a buszon, ezek a címigénylő üzenetek, amikor a hálózatra csatlakozó ECU-k a címeiket beállítják. Az alábbi diagramon három különböző autóbuszon végzett alap állapotú mérési eredmény látható. 37

40 4.7. ábra: Három különböző autóbuszon az azonosítók száma alap állapotban Az elvégzett mérések alapján megállapítható, hogy az egyes autóbuszok között azonos állapotban hasonló eredményeket értem el. Az autóbuszok közötti különbségek az eltérő paraméterekből és az esetleg eltérő ECU-kből adódik. Előfordulhat, hogy egy meghibásodott ECU-t kicseréltek egy újabbra és így az más paramétercsoportokat küld a hálózatra. Az általam vizsgált autóbuszok valamelyikén aktív hibakódok is voltak, így azok is eredményezhetik a változást. A diagramon látható, hogy az első és második autóbuszon egyaránt 58 féle azonosító fordult elő. Ez nem azt jelenti, hogy ezeken ugyanolyan kommunikáció van, mert az 58 azonosítóból csak 57 ugyanolyan, volt 1-1 azonosító, amelyek csak az egyiken fordultak elő. A továbbítandó adatmennyiség csökkentése érdekében az adatok szűrése egy lehetséges megoldás. A következő mérési funkció az adat szűrés, ekkor csak a megadott azonosítót tartalmazó üzeneteket küldi tovább az eszköz a számítógépnek. A monitorozni kívánt azonosítókat egymás után hexadecimális formátumban kell megadni, ezután elindul a mérés. Ez a funkció azért hasznos, mert menetközben tudjuk figyelni az egyes paraméterek változását. A vezérlőtől kapott adatokat a számítógépen egyszerűbben ki lehet értékelni. A legfontosabb adat a hibakód, ugyanis abból lehet következtetni a meghibásodás okára. A hibakódok nem csak akkor lesznek aktívak, ha egy részegység már meghibásodott, hanem a járművön az egyes mért értékeket figyeli, és ha azok egy megadott szint alá vagy felé esnek, akkor is aktív lesz. Ezek tudatában az lett a célom, hogy a hibakódokat tudjam lekérdezni, továbbítani és törölni. Ezeket a diagnosztikai üzenetekkel (DM Diagnostic 38

41 Messages) lehet megtenni a J1939-es szabvány 73-as része szerint. A szabvány 13 DM-et definiál, mindegyiket különböző PGN számmal, ebből az első az aktív hibakódokat küldi, míg a 11-essel lehet törölni. Tehát a szűréssel a diagnosztizáláshoz kapcsolatos üzeneteket akarom kizárólagosan átengedni. Az első diagnosztikai üzenet azonosítójára szűrtem rá úgy, hogy a járművön 3 hiba volt jelen, ezeket a diagnosztikai eszközzel előtte kiolvastam. Ekkor azt tapasztaltam, hogy a ciklikusan elküldött üzenetek nem tartalmazzák a hibakódokat, ezért csak más úton juthatunk el a megoldásig. Az egyes azonosítók felbontásával folytattam a munkám, ezt a korábbi és ábrák szerint végeztem el. Például egy üzenet azonosítója: 0CF táblázat: Egy azonosító felbontása 0C F Priority Extended Data Page Data Page PDU Format PDU Specific Source Address 3 bit 1 bit 1 bit 8 bit 8 bit 8 bit A PDU Format egyenlő 240-nel, ezért ez egy broadcast üzenet. Az adatokból a szabvány alapján meghatározható a PGN. A J1939/71-es szabványrészből kikeresve ezt a számot megtudjuk, hogy mihez tartozik az üzenet és hogy mit tartalmaz az adatrésze. PGN: (00F002 hex ) => => Elektronikus váltóvezérlő #1 (ETC - Electronic Transmission Controller) A szabványból megtudott további tulajdonságok: Átvitel ismétlés: 10 ms Adat hossz: 8 bájt Adatlap: 0 PDU Format: 240 PDU Specific: 2 Alap prioritás: 3 Minden üzenetet felbontani és értelmezni elég nehézkes és sok idő lenne, sőt még vannak gyártó specifikus üzenetek is, amelyek nincsenek benne a szabványban. Nekem a célom a hibakódok lekérdezése, továbbítása és törlése, ezért azokat az üzeneteket kell 39

42 megvizsgálni, amelyek akkor keletkeznek, amikor a diagnosztikai eszköz is rácsatlakozott a jármű hálózatára Diagnosztizálás folyamatának vizsgálata A következő méréseknél a CAN busz topológiáját kihasználva egyszerre csatlakoztattam a diagnosztikai interfészt és a méréshez használt eszközt az autóbusz CAN hálózatára. Diagnosztikai szoftver RS232 Diagnosztikai interfész µc CAN 4.8. ábra: A diagnosztikai eszköz és a mérőrendszer is csatlakozik az autóbusz hálózatára Ezeknél a méréseknél egyszerre láthattam a jármű hálózatának forgalmát és a diagnosztikai eszközzel való kommunikációját. Ekkor 20-szal több azonosító érkezett, ám ezeket felbontva megállapítható, hogy csak 4 féle PGN számú üzenet van köztük, a címek másak, ezért látunk több azonosítót. Elsőként küld egy kérést a buszra, hogy megtudja, milyen címek vannak lefoglalva, majd ezek alapján kiválaszt magának egy még nem létező címet és kiküldi a címbeállító üzenetét. A másik kétfajta PGN számú üzenet a Transport Protocol-hoz kapcsolódik, amit a J1939-es szabvány 21-es része definiál, és arra használják, hogy több mint 8 bájt adatot tudjanak küldeni a buszon. Még egy mérést végeztem, amikor egy diagnosztikai eszközzel éppen hibakódot töröltek a járművön. A hibakód törlés után a járműről le kellett kapcsolni a gyújtást majd újra visszakapcsolni, ezért az alap 58 azonosítón felüliekben benne vannak a gyújtás ráadásakor érkezőek is, ezek közül kellett meghatároznom azokat, amelyek a hibakód törlés miatt 40

43 kerültek a buszra. A megállapításom az, hogy csak Transport Protocol üzenetek játszottak szerepet a hibakód törlésben, ezért elég lenne őket kiszűrni és továbbítani. A diagnosztikai eszköz csatlakozásakor és azon értékek monitorozásakor az ilyen üzenetekből összesen 1852 darab jött egy perc alatt, hibakód törlésnél pedig 446 darab, ezek összege nem több 2300 üzenetnél, ami az eredeti üzenetnek kevesebb, mint 8,2%. Átviteli sebességben ez annyit jelent, hogy a korábban kiszámolt 65 kbit/s helyett csak 5,33 kbit/s sebességre van szükségünk. Ez az adatmennyiség már átküldhető lenne GPRS átvitellel A távdiagnosztikai rendszer kialakítása Először a diagnosztizálás folyamatával kell tisztában lenni, ezt már gyakorlott szakember mutatta meg nekem. A diagnosztizáláskor a jármű belső hálózatára csatlakozik egy diagnosztikai interfész. Az általam vizsgált autóbuszok esetében a sofőr ülése mellett helyezkedik el a diagnosztikai csatlakozó, egy lecsavarozható védőpanel mögött. A diagnosztikai interfész egy számítógéphez csatlakozik, régebbi eszközök a soros port-ra, de már vannak újabb USB-s eszközök is. A számítógépen egy diagnosztikai szoftver fut, amely fogadja az adatokat a diagnosztikai eszköztől a megfelelő port-on keresztül. Nem ritka, hogy az USB-n is virtuális soros port-ot hoznak létre, ugyanis ilyenkor a diagnosztikai szoftvert nem kell lecserélni. Diagnosztikai szoftver Diagnosztikai interfész CAN 4.9. ábra: A diagnosztizálás folyamata 41

44 Az ábrán szemléltetem a hagyományos diagnosztizálást. Ezt telekommunikációs eszközökkel támogatva kapjuk a távdiagnosztizálást. A menet közbeni diagnosztizálási lehetőség mellett erre azért van szükség, mert az autóbuszok nem mindig egy telephelyre érkeznek vissza és nincs minden telephelyen diagnosztikai eszköz. A távdiagnosztizálással egy központi telephelyről monitorozható lenne az összes jármű, ezzel a karbantartási lehetőségek növekednének, és a hibás működés megelőzhető lenne. Az esetleges meghibásodást is egyből érzékelni tudná a rendszer, így a legközelebbi szervizközpontot értesítve gyorsabb lenne a javítási művelet. Központi telephely Távoli helyszín Diagnosztikai szoftver Telekommunikációs hálózat Diagnosztikai interfész CAN CAN ábra: Távdiagnosztika Az előző ábrán is látható, hogy az eredeti diagnosztikai interfész és szoftver használatával szeretném megoldani a távdiagnosztizálást, ugyanis ezek az eszközök és szoftverek elég drágák. A távdiagnosztizáláshoz használt kommunikációt jelölik az ábrán látható fekete téglalapok. A telekommunikációs hálózatnak mindenképpen vezeték nélkülinek kell lennie. A legfontosabb követelmény a lefedettség biztosítása a közlekedésben, ennek már számos hálózat nem tesz eleget. Hazánkban csak a GSM hálózat felel meg az elvárásoknak, ami 99 százalékos lefedettséget biztosít. GSM hálózaton adatátvitelt adathívással és GPRS technológiával lehet megoldani. Az adathívás alacsony átviteli sebessége miatt nem alkalmazható. A GPRS már magasabb sebességet biztosít, de ez még mindig jóval kisebb, mint amire a jármű CAN hálózata képes. Ez alapján belátható, hogy nem minden adat vihető át, mindenképpen valahogy csökkenteni kell az adatmennyiséget. 42

45 Napjainkban rohamosan fejlődnek a szélessávú mobilinternet szolgáltatások (HSPA, LTE), ám ezek még csak a nagyvárosokban és azok környékén érhetőek el. Ezen hálózatok teljes kiépítése után lehetséges, hogy minden CAN adatot át tudnánk küldeni rajtuk, de mivel ezeken a hálózatokon adatkorlát van, így ekkor is célszerű lenne csökkenteni a nagy adatmennyiséget. A három legnagyobb magyarországi mobil szolgáltató GPRS és 3G-s lefedettség térképe a 1. sz. Mellékletben található. Központi telephely Távoli helyszín Diagnosztikai szoftver Router Mobil hálózat GPRS modem Ethernet CAN/ Ethernet konverter RS232 CAN üzenet szűrő µc Diagnosztikai interfész CAN CAN ábra: GSM hálózaton keresztüli távdiagnosztizálás A ábrán szemléltetem az általam tervezett első távdiagnosztikai rendszert. Látható, hogy GPRS modem segítségével kommunikál a jármű és a diagnosztikai eszköz az Interneten keresztül éri el azt. Ez azt jelenti, hogy az adatok transzparensen átvihetők a két pont között. A további vizsgálatok során nem veszem bele a GPRS kapcsolatot, ugyanis ha RS-232-n keresztül működik a diagnosztizálás, akkor már csak a GPRS modemet kell felkonfigurálni és a fogadó szerver alkalmazást elkészíteni. Szintén észrevehető az ábrán, hogy a központi telephely oldalán, azaz ahol a diagnosztikai eszköz van, ott egy CAN/Ethernet konverter alakítja át az Ethernet-es adatokat CAN adatokká és visszafelé. A diagnosztikai eszköz nem küld olyan sok adatot (ezt a megállapítást már a mérések elvégzése után jelenthetem ki), hogy azt csökkenteni kellene, ezért itt elég egy átalakító. A jármű oldalán található mikrokontrollernek kell elvégeznie az adatok szűrését és úgy kiküldeni azokat, hogy a CAN-es átalakító azt tudja értelmezni és továbbítani. Belátható, hogy ha ismerném a diagnosztikai interfész pontos működését, akkor nem kellene visszaalakítani az adatokat CAN kommunikációra, hanem egyből küldhető lenne a diagnosztizálást végző számítógépnek. 43

46 4.3. CAN üzenetforgalom szimulációja Az előző fejezetekben bemutatott mérésekre és SAE J1939 szabványra alapozva készítettem el többféle szűrési eljárást, ezeknek a bemutatása egy korábbi cikkben is megtalálható, amelyben szerzőtársként vettem részt [12]. A szűrőalgoritmusokat kipróbálva valós körülmények között volt, amelyikkel működött a diagnosztizálás. Működés közben megállapítottam, hogy instabil volt a kapcsolat a diagnosztikai szoftver és a jármű hálózata között, így mindenképpen fontosnak tartottam a szűrési eljárások laboratóriumi körülmények melletti tesztelését és fejlesztését. Diagnosztikai szoftver Diagnosztikai interfész CAN CAN/ RS232 konverter RS232 µc CAN ábra: A szűrőalgoritmusok tesztelése éles körülmények között A fenti ábrán látható elrendezésben teszteltem a szűrő eljárásokat, ennek a szimulációját kellett megvalósítanom laboratóriumi körülmények között. Az ötletem, hogy egy számítógép a soros port-ján (ha nincs, akkor USB-n egy virtuális soros port-on) keresztül küldi az adatokat. Ezek az adatok a jármű hálózatán lévő azonosítókat szimbolizálják. Úgy kell kialakítani a küldést, hogy az adatmennyiség tükrözze a mérésnél tapasztaltakat. Ezeket az adatokat egy CAN/RS-232-es átalakítás után a mikrokontroller kapja meg és szűri. A kontroller által küldött adatok elemezhetőek, ezekből tudhatjuk meg, hogy mit kapna meg az adott szűrés után a diagnosztikai eszköz. Az eddig általam készített szűrési eljárások úgy működtek, hogy egyes azonosítókat nem engedtek át, így csökkentve a 44

47 továbbítandó adatmennyiséget, de ezek az eljárások nem vezettek célra, ezért mindenképpen olyan szűrő algoritmusra van szükség, amely minden azonosítót átenged. A CAN üzenetforgalom-szimuláló programot Java nyelven készítettem, a felhasználói felülete a következő ábrán látható ábra: Az elkészített program felhasználói felülete A program elindításakor megvizsgálja a soros port-okat a számítógépen, ezután ki lehet választani azt a Ports feliratú lenyíló menüből. Az RS-232 paramétereit a mellette található menükből lehet kiválasztani. Ezek a paraméterek attól függenek, hogy milyen eszközhöz csatlakozunk. A Baud rate alatt a soros kommunikáció átviteli sebességét lehet kiválasztani 600-tól bps-ig terjedő tartományból (csak a szabványos és leggyakoribb értékeket tartalmazza). A következő menüből lehet meghatározni, hogy 5, 6, 7 vagy 8 adatbitet (Data bits) használunk-e egy keretben. A negyedik lenyíló menü a paritás ellenőrzés módját tartalmazza, ez lehet páros (even), páratlan (odd), mark, space vagy none, amikor nem használunk paritásbitet. A stopbitek számát az utolsó menüből lehet kiválasztani. A megfelelő értékek kiválasztása után lehet kapcsolódni a Connect gombbal. 45

48 Soros -port : CommPortIdentifier -sport : SerialPort -ports : Vector +Soros() +connect(bemeneti portname : string, bemeneti baud : int, bemeneti bits : int, bemeneti stop : int, bemeneti parity : int) : void +output() : PrintStream +input() : DataInputStream +disconnect() : void +listports() : void +getports() : Vector +getporttypename(bemeneti porttype : int) : string +awegwaeg() ábra: Az RS-232-es kapcsolatot kezelő osztály struktúrája A program elindulásakor még betölt egy Excel fájlt, amely tartalmazza azokat az azonosítókat, amelyeket küldeni szeretnénk. Azért döntöttem xls fájlformátum mellett, mert ilyen fájlokban tárolom a mérési eredményeket, és Excelben létrehoztam egy automatikus kiértékelőt is, amely a beadott azonosítókat felbontja. Az ID oszlopban az azonosítók szerepelnek, mellettük a ms oszlopban pedig a sebességük, például ha ez az érték 50, akkor a program 50 milliszekundumonként küld egy üzenetet az adott azonosítóval. A program folyamatábrája a 2. sz. Mellékletben látható. Runnable +run() : void SendThread -out : PrintStream -id : string -ms : int -run : bool +SendThread(bemeneti s : Soros, bemeneti id : string, bemeneti ms : int) +run() : void ábra: Az üzenetküldő osztály Minden azonosító küldéséhez egy új szálat hozok létre a programban, hogy az időzítés megfelelő legyen, így egy adott szál csak egyfajta üzenetet küld és várakozik a megadott ideig. Az üzenetküldő osztály implementálja a java.lang.runnable interfészt és felülírja annak a run metódusát, ez látható az ábrán is. 46

49 A program main osztályának az adattagjai és metódusai a követező ábrán láthatók. Ablak -s : Soros -ms : int = 0 -n : int = 0 -in : DataInputStream -out : PrintStream -id : string -st : Thread -tmodel : DefaultTableModel -table : JTable -scrollpane : JScrollPane -boxbaud : JComboBox -boxbits : JComboBox -boxparity : JComboBox -boxport : JComboBox -boxstop : JComboBox -buttonconnect : JButton -buttonstart : JButton -baudrate : JLabel -databits : JLabel -parity : JLabel -ports : JLabel -stopbits : JLabel -panel : JPanel +Ablak() -initcomponents() : void -buttonconnectactionperformed(bemeneti evt : ActionEvent) : void -buttonstartactionperformed(bemeneti evt : ActionEvent) : void +main() : void ábra: A főosztály adattagjai és metódusai A felhasználói felület elkészítéséhez a javax.swing csomagjában található elemeket használtam fel, a gombok eseménykezeléséhez pedig a java.awt.event-ben található ActionEvent típust. 47

50 USB RS232 CAN/USB konverter CAN/ RS232 konverter CAN CAN/ RS232 konverter RS232 µc CAN ábra: Az elkészített CAN üzenetforgalom szimuláló rendszer Az előző ábrán látható az elkészített rendszer. Az ábrával szemben itt a jármű oldalán található számítógép szimulálja annak a CAN üzenetforgalmát az általam készített szoftverrel. Ezeket a CAN üzeneteket fogadja a mikrokontroller, majd szűrés után továbbítja azt az RS-232-es port-on. Az RS-232/CAN átalakítás után azokat az adatokat kell kapnunk, amelyeket a diagnosztikai eszköznek szeretnénk küldeni, ezt CAN/USB konvertálás után ellenőriztem egy számítógépen. Az ábrán látható két számítógép lehet ugyanaz is, ilyenkor az egyik programmal szimuláljuk az üzeneteket, a másikkal pedig monitorozhatjuk a szűrési eljárás hatékonyságát. 48

51 5. Üzenetszűrés megvalósításai 5.1. Első szűrőrendszer kialakítása A mérések elvégzése és az üzenetforgalom szimuláló program elkészítése után kezdtem el kidolgozni szűrési eljárásokat. Az elképzelésem az volt, hogy ha a fentebb említett cím igénylő és Transport Protocol üzeneteket át tudom küldeni, akkor a távolról történő diagnosztizálás működni fog. Kétfajta szűrési eljárást készítettem el, ezeket mutatom be a következőkben. Az első a leggyakoribb azonosítók szűrése. Ezek az azonosítók az online paramétereket közvetítik, olyanokat, mint a 4. fejezetben említett Elektronikus váltóvezérlő paraméter csoport, amely 10 milliszekundum időközönként továbbítódik a jármű belső hálózatán és a tengely fordulatszámát adja meg. A hibakódok feltárásához ezen paraméterek nem szükségesek, így a kiszűrésükkel csökkenthető az adatmennyiség. A szűrést megvalósító kód minden egyes új üzenet beérkezésekor fut le, megvizsgálja, hogy az üzenet azonosítója benne van-e a nem kívánatos azonosítók között. Ha igen, akkor nem továbbítja. Ha nincs benne, azaz az azonosítót át akarjuk engedni, akkor az üzenetet továbbítja. A második szűrési eljárás a maszkolás. A korábbi mérésekre alapozva a diagnosztikai eszközzel való kommunikációért felelős üzenetek azonosítóját vizsgáltam meg. Az ilyen üzenetek kiszűréséhez maszkolást használtam, azaz az üzenet azonosítójának csak egy részét vizsgálom meg, és ha az benne van a megadott listában, akkor továbbítom azt. A maszkolással a 3.3. fejezetben tárgyaltak szerint egy azonosítóból meghatároztam a paraméter csoport számát. 18FE4A03 & 00FF FE0000 Ezzel az eljárással nem kell ismernünk az egyes ECU-k címét és az üzenet prioritása is kiküszöbölhető, csak a paraméter csoportokat kell megadnunk. A következő értékeket állítottam be a szűrésnél: 00EA00 hex kérés paramétercsoport (RQST) 00EB00 hex és 00EC00 hex átviteli protokoll paramétercsoportok (TP-CM és TP-DT) 00EE00 hex cím igénylő paramétercsoport 00EF00 hex és 00FF00 hex gyártó specifikus paraméter csoportok 00FE00 hex diagnosztikai üzenetek 49

52 Mint fentebb is említettem a programnak úgy kell kiküldenie soros port-on az adatokat, hogy azt egy CAN/RS232 konverter egyből át tudja alakítani CAN adatokká. A diagnosztikai eszköz által küldött üzeneteket megkapja a CAN/RS232 átalakító, majd tovább is küldi a mikrovezérlő felé. A mikrovezérlő a soros port-on keresztül ASCII stringet olvas be, amelyeket továbbítani kell, de a CAN port-ra hexadecimálisan küldhetjük az üzeneteket. Ehhez egy karaktert hexadecimálisra kódoló függvényt hoztam létre. A két szűrési eljárás laboratóriumi tesztelése sikeres volt, így tényleges autóbuszon is kipróbáltam ábra: A szűrési eljárásokkal elért adatcsökkentés A 3, 6 és 11 leggyakoribb azonosító kiszűrése és maszkolása közben is megpróbáltam csatlakozni egy diagnosztikai eszközzel a jármű hálózatára. A csatlakozás nehézkes volt, több időt vett igénybe, mint normál esetben, azaz amikor a diagnosztikai eszköz közvetlenül csatlakozik a jármű belső hálózatára. A csatlakozás után a hibakód olvasást egy esetben el tudtam végezni, de a kapcsolat instabillá vált, többször megszakadt. 8. táblázat: Az üzenetszám csökkenése idő (sec) üzenet szám üzenet/sec szűrés nélkül ID szűrés 82, , ID szűrés 93, , ID szűrés 116, ,59211 maszkolás 69, ,

53 További mérésekből arra a következtetésre jutottam, hogy a diagnosztikai eszköz minden paramétercsoportot figyel, így ha nem kap meg minden paramétercsoportot, akkor hibás működés léphet fel a program futásában. Ennek a problémának egy lehetséges megoldása, hogy minden azonosítót átengedünk, csak részarányosam megritkítjuk. Az előző két szűrési eljárás kizárólag a hibakódok kiolvasására alkalmas. Ez a módszer viszont minden egyes azonosítót átengedne, azonban a gyakoriakat, amikből több ezer is jön percenként, ritkítaná, és csak másodpercenként engedne át egyet-egyet. Ezzel a maximális adatátviteli sebesség alatt lehetne maradni, viszont minden adatot megkapna a diagnosztikai eszköz a járműtől. A módszer egy lehetséges megoldás az adatkapcsolat stabilizálására, illetve a távmonitorozás létrejöttére, azonban nekem újabb elképzelésem alakult ki és másik rendszer tervezésébe fogtam bele Második szűrőrendszer megvalósítása A másik rendszerbe nem ugyanezt a mikrovezérlőt terveztem, ugyanis ez az eszköz, amit megkap soros port-on, azt egyből vissza is küldi. Ez nekünk csak plusz adatmennyiséget jelent. Az új rendszer eszközigénye csak egy mikrovezérlővel több, mert ennél a diagnosztikai oldalra is egy mikrovezérlőt helyeztem el. USB RS232 CAN/USB konverter CAN/ RS232 konverter CAN µc RS232 µc CAN 5.2. ábra: Az újratervezett rendszer 51

54 A ábrával összehasonlítva látható, hogy csak az RS232/CAN konvertert cseréltem le egy programozható mikorvezérlőre. Ha az eredeti feltevésnél maradunk, azaz egy központi irodából szeretnénk a járműveket monitorozni, akkor tényleg csak egy plusz mikrovezérlővel több ez a rendszer, viszont sokkal nagyobb a szabadságfoka. A jármű oldalon lévő vezérlőnek nem kell előre meghatározott módon kiküldeni az üzenetet, hanem feldolgozhatja és átalakíthatja. Ennek a rendszernek a tervezése során nagy hangsúlyt fektettem a mikrovezérlő kiválasztására, ugyanis ez határozza meg az alapműködést. Az előzőekben bemutatott beágyazott operációs rendszert tartalmazó eszköz helyett egy ARM mikrovezérlőt választottam. A döntés során az eszköz ára nem elhanyagolható, mert egy tömegközlekedési vállalat nagyon sok járművel rendelkezhet és minden egyes járműbe beszerelt egységnek ez lesz a központja. Az általam választott mikrovezérlőt a tajvani székhelyű Nuvoton cég gyártja, amely ban vált ki a Winbond félvezető gyárából, annak mikrovezérlő és távközlési célra gyártott alkatrészeinek fejlesztésére és gyártására szakosodva. Az ARM magos mikrokontrollereit hosszú ideje széleskörűen használják a kínai és tajvani szórakoztató elektronikát gyártó cégek. A Nuvoton ipari felhasználásra szánt 32 bites mikrokontrollereit foglalja magában a NuMicro termékcsalád, melyek ARM Cortex-M0 magra épülnek, és rendkívül gazdag perifériakészlettel rendelkeznek. Érdemes még megemlíteni, hogy a NuMicro mikrokontrollerek ára a konkurens gyártók 8 bites eszközeivel vetekszik, mely lehetővé teszi ennek a nagyszerű 32 bites mikrokontroller családnak az elterjedését, az általam előzőleg használt eszköztől pedig nagyságrenddel kisebb az ára. Az ARM Cortex-M mikrokontroller előnyei [13]: Nagy teljesítményű nyílt architektúra. High- és low-end processzor mag (M0, M3, M4). Ugyanaz az architektúra, több gyártó és számos fejlesztő. A legjobb ökoszisztéma: Több gyártós és egyszerűen használható fejlesztő környezet. Könnyen kap szoftveres IP támogatást. Csökkenti a fejlesztési költséget, különösen a szoftver beruházásoknál. Fő mikrokontroller architektúra az elkövetkező 20 évben. 52

55 Az NuMicro családból az NUC140-es szériát választottam, ugyanis ez támogatja a CAN kommunikációt. Legfontosabb jellemzői [14]: ARM Cortex -M0 mag: 50 MHz-ig fut fel. Egy-ciklusú 32 bites hardver multiplikátor. 32 megszakítás bemenet, mindegyik 4 szintű prioritással. Flash EPROM memória: Akár 128k bájt Flash EPROM programkódnak. Akár 16k bájt SRAM. 4kB flash ISP loader-nek. Analóg periféria: 8 csatornás 12 bites ADC. Kommunikációs perifériák: Nagy sebességű UART. SPI 32 MHz-ig. I2C 1 MHz-ig. Csatlakoztathatóság perifériák: USB FS 2.0 CAN 2.0B LIN busz. Funkciókban gazdag perifériák (pl. IrDA, PWM, RTC, GPIO ). Tápellátás kezelő egység: készenléti mód, kikapcsolási mód. Alkalmazások: Autó hálózati vezérlő. Jármű elektronikus diagnosztika. Beágyazott hálózati alkalmazás. Lift hálózati vezérlő rendszer. Ipari és automatikus vezérlés. 53

56 5.3. ábra: ARM mikrovezérlő belső felépítése és perifériái [14] CAN funkciók: Támogatja a 2.0B verziójú CAN protokollt. Bit sebesség akár 1Mbit/s. 32 üzenet objektum. Programozható FIFO mód (az üzenet objektumokkal összefűzve). Maszkolható megszakítás. Kikapcsolható az automatikus újra küldés mód az idő kritikus alkalmazásokhoz. Programozható loop-back mód önteszt végrehajtásához. Támogatja az ébresztési funkciót. Az általam használt eszköz pontos jellemzői (NUC140VE3CN): Memória: Flash 128k, SRAM 16k. I/O: akár 76. Időzítő: 4x32-bit. Csatlakozások: 3 UART, 4 SPI, 2 I 2 C, 1 USB, 2 LIN, 1 CAN, 1 I 2 S, 2 komparátor, 8 PWM, 8x12-bit ADC, RTC, EBI, ISP, ICP, IRC 22 MHz, 9 PDMA. Tokozás: LQFP

57 A mikrovezérlő fel tudja dolgozni a CAN üzeneteket, ismeri a protokollt, csak a fizikai szint illesztését a buszrendszerre kell megoldani. Ehhez a Microchip cég által gyártott MCP2551-es nagy sebességű CAN transzívert használtam, ugyanis ez megvalósítja az ISO as szabvány fizikai rétegre vonatkozó követelményeit ábra: A CAN interfész nyomtatott áramköri terve A nyomtatott áramkör tervezésében és elkészítésében nyújtott segítséget itt szeretném megköszönni Méhes László kollégámnak. Az új rendszerkialakítással, azaz hogy mind a jármű, illetve mind a diagnosztikai szoftver oldalon egy-egy programozható eszközt helyeznék el, több lehetőségem adódik az adatcsökkentésre. Ennél a rendszernél kidolgozásra került egy újfajta szűrési algoritmus: A 4. fejezetben bemutatott mérésekre alapozva tehetem azt a megállapítást, hogy 100 féle azonosítónál több nem fordul elő a jármű kommunikációs hálózatán. Maximálisan eddig 80 azonosítót tapasztaltam a méréseim során. 55