MISKOLCI EGYETEM GÉPÉSZMÉRNÖKI ÉS INFORMATIKAI KAR TUDOMÁNYOS DIÁKKÖRI DOLGOZAT Járművek vezeték nélküli távdiagnosztikai lehetőségeinek kutatása Biró Zoltán I. éves mérnök informatikus MSc hallgató Konzulens: Prof. Dr. Ajtonyi István egyetemi tanár Trohák Attila egyetemi tanársegéd Automatizálási és Kommunikáció-technológiai Tanszék Miskolc, 2011
TARTALOMJEGYZÉK 1. Bevezetés... 3 2. Vezeték nélküli kommunikációs hálózat kiválasztása... 5 3. Járművek kommunikációs rendszere... 9 4. Az adatforgalom feltérképezése... 14 5. Üzenetszűrés... 18 Összefoglalás... 25 Irodalomjegyzék... 26 Mellékletek... 27 2
1. BEVEZETÉS A járműveket ma már elektronikusan irányított, azaz mechatronikai rendszereknek tekinthetjük. Diagnosztizálásuk fontos dolog és egyre elterjedtebb, mert ezzel gyorsan megállapítható az egyes részegységek hibás működése. A járműdiagnosztizálás felgyorsítja és hatékonyabbá teszi a karbantartási folyamatokat. Egyre fontosabb az on-board (fedélzeti) diagnosztika szerepe, amellyel menetközben folyamatosan felügyelhetjük a járművek alrendszereit. A járművekbe épített egyes irányított rendszerek különböző cégektől származhatnak, de már szinte minden gyártó kínál a saját berendezéseihez diagnosztikai eszközöket. Ezekkel az eszközökkel közvetlenül rá kell csatlakozni a jármű belső kommunikációs hálózatára a diagnosztizáláshoz. Egy vállalat sok járművel rendelkezhet és több telephelye is lehet, így a járművek nem mindig egy helyre térnek vissza, emellett menetközben is meghibásodhatnak. Ha a jármű és a diagnosztikát végző személy távol van egymástól, akkor beszélünk távdiagnosztikáról. Ennek a vezeték nélküli kommunikációval történő megvalósítási lehetőségeit feltáró kutatásaink eredményeit mutatom be a dolgozatomban. 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 figyelembe kell venni, hogy a járművek városok közti utakon is közlekednek. 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 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 3
ismernünk kell a CAN adatcsomagjait, ezért a dolgozatom második fejezetében a CAN kommunikációt mutatom be. A CAN sokkal nagyobb sebességre képes, mint a GSM alapú kommunikáció, ezért egy járművön méréseket végeztünk, hogy a CAN hálózat adatforgalmát részletesen tudjuk elemezni. Ezeket a méréseket a dolgozatom harmadik fejezetében ismertetem. A mérések során az tapasztaltuk, hogy az összes adatot nem tudjuk továbbítani, a megoldást az adatok szűrésével érhetjük el, amire egy egyedi fejlesztésű szűrőrendszert terveztünk, ezt a dolgozatom negyedik fejezetében mutatom be. A további méréseket is a kifejlesztett rendszer segítségével végeztük el, ezen mérések kiértékelését is itt részletezem. 4
2. 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 99 százalékos lefedettséget biztosít. A magyarországi három legnagyobb mobilszolgáltató GSM és mobil internet lefedettségét 1. számú Melléklet tartalmazza. 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 5
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 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 [2]: 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). 1. á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 6
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). 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. 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ózat (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 BSS-en 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 7
á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 30 48 kbps között szokott mozogni és a maximális feltöltési sebesség 10 24 kbps lehet. 1. táblázat Egy magyarországi szolgáltató által vállalt sebesség korlátok A szolgáltató által vállalt célérték: A szolgáltatás nyújtása során legalább teljesítendő minimálérték: GPRS letöltés 30 kbit/s 8 kbit/s GPRS feltöltés 8 kbit/s 4 kbit/s 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. 8
3. JÁRMŰVEK KOMMUNIKÁCIÓS RENDSZERE A járművek egyes alrendszerei CAN buszrendszeren keresztül kommunikálnak egymással. A CAN buszt eredetileg a Robert Bosch GmbH feljesztette ki Zuffenhausenben, 1983-ban. A protokoll hivatalos bemutatója 1986-ban történt meg, a Society of Automotive Engineers (SAE) kongresszuson, Detroit-ban (Michigan). Az első CAN vezérlő chipet 1987-ben adta ki az Intel és a Philips cégek együttműködve. A Bosch által továbbfejlesztett változat 1991-ben debütált CAN 2.0 néven. 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 standard-ot, mely az európai benzinüzemű járművekre 2001-től, dízelekre pedig 2004-től alkalmazható.[4] A CAN busz célja elsősorban az volt, hogy az autóipar rendszer-decentralizációs törekvéseihez megbízható eszközként szolgáljon, 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 ECU-k (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. 9
2. ábra Járművek CAN hálózata 2. táblázat A CAN busz műszaki adatai [1] 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 11898 szerinti (NRZ) Átviteli közeg árnyékolt vagy árnyékolatlan sodrott érpár Átviteli hibavédelem CRC 10
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 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. 3. ábra CAN normál és kibővített üzenetkeret 11
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 536 870 912 különféle üzenet továbbítását biztosítja. A járművek belső hálózata különböző, két csoportba oszthatóak. Első csoportba tartoznak a személygépjárművek és a kis teljesítményű járművek, a másik csoportba a teherautók, a közepes és nagy teljesítményű járművek. A dolgozatom további részében a második csoportba tartozó járművekkel foglalkozom, ugyanis 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 távdiagnosztizálásukkal növekedne a megbízhatóságuk. Például egy közlekedési vállalatnak nagyon hasznos, mert az útközben meghibásodott járművei gyorsan és egyszerűen diagnosztizálhatóvá válnak a telephelyekrő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. Ugyanakkor léteznek olyan hibák, melyek miatt a vezérlőelektronika letiltja a jármű működését, viszont ezek távolról történő inaktiválásával a jármű még képes eljutni a legközelebbi telephelyig. Ezzel jelentős költség- és időmegtakarítás érhető el. A közepes és nagy teljesítményű járművek belső hálózatának kommunikációja a SAE J1939 szabvány által meghatározott. Ez egy CAN alapú magasabb szintű protokoll. A J1939 öt szintet határoz meg a 7-szintű ISO-OSI hálózati modellben és magába foglalja a CAN 2.0B specifikációt a fizikai és adatkapcsolati rétegeken, azaz a kibővített keretformátumot használja. A 29 bites azonosítót még további részekre osztja, ezekből a részekből lehet megtudni az üzenet prioritását, a feladó címét, és hogy az üzenet adat mezőjében milyen információt hordoz [3]. 12
4. ábra CAN azonosító felbontása Az első 3 bit határozza meg a prioritást, az utolsó 8 bit pedig a forrás címet. A középső 18 bit együttesen adja meg a PGN-t (Parameter Group Number). A PGN fontos paraméter, ez határozza meg, hogy az adat mezőben milyen információ van. A J1939/71-es részben vannak felsorolva a szabvány által definiált PGN-ek. 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. 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). Az Extented Data Page bittel és a Data Page bittel 4 különböző adatlapot lehet kiválasztani, az alábbi táblázat szerint. 3. táblázat Adatlapok Extented Data Leírás Data 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 15765-3 definiálja 13
4. AZ ADATFORGALOM FELTÉRKÉPEZÉSE Első feladatunk volt meghatározni a jármű kommunikációs rendszerének a sebességét, ehhez méréseket végeztünk egy autóbuszon. A CAN buszrendszerre egy digitális oszcilloszkóppal csatlakoztunk és a bitidőket figyeltük. 5. ábra Egy bit idő a CAN hálózaton A mérésből megállí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 első 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égeztünk méréseket egy autóbuszon. A méréshez egy olyan programozható vezérlőt használtunk, amely CAN interfésszel rendelkezik és képes CAN üzeneteket fogadni, feldolgozni. A vezérlőt 14
közvetlenül a busz belső hálózatára csatlakoztattuk rá és ez továbbította a kívánt adatokat egy számítógép felé. 6. ábra CAN és RS232 kommunikációra alkalmas mikroprocesszor A vezérlőbe írt programot C nyelven készítettem el. Ebben az esetben csak annyi volt a feladata a vezérlőnek, hogy fogadta a CAN üzeneteket, és amikor jött egy új üzenet növelte az üzenet számlálót. Be lehetett még állítani, hogy mennyi ideig folytassa a mérést, az idő letelte után elküldte az üzenetszámot a számítógépre. Hét darab egyperces mérést végeztünk, különböző állapotokban. Az első két mérés gyújtás alatt lévő járművön történt, a következő három mérésnél a motor is be volt indítva, a hatodik mérést úgy végeztük, hogy közben egy diagnosztikai eszközzel is rácsatlakoztunk a jármű buszrendszerére. Az utolsó mérést úgy indítottuk el, hogy még a gyújtás sem volt rajta a járművön, csak a mérés indítása után kapcsoltam rá a gyújtást. 15
7. ábra Egyes állapotokban az üzenetszám egy perc alatt Az utolsó mérésnél az üzenetszám szemmel láthatóan kevesebb, mint az azt megelőző állapotokban, ez azért van, mert a mérés már futott, amikor ráadtuk a gyújtást. A mért értékekből látható, hogy az egyes állapotokban az üzenetek száma nem változik sokkal, körülbelül 28300 üzenet továbbítódik a hálózaton egy perc alatt. A kis eltérés abból adódik, hogy eltérő ciklusban indítottuk el a mérést és a járművek alrendszerei más-más időközönként küldenek üzenetet. 8. ábra Másodpercenkénti üzenetszám 16
Az fenti ábrán látható, hogy alap esetekben átlagosan 472 üzenet érkezik egy másodperc alatt, emellett a 3. á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 átvinnünk 1 másodperc alatt GPRS adatátvitellel, ami nem megoldható a korábban már bemutatott, gyakorlatban elérhető maximális feltöltési sebesség miatt. Mindenképpen csökkentenünk kell az átvinni kívánt adatmennyiséget. 17
5. ÜZENETSZŰRÉS A továbbítandó adatmennyiség csökkentése érdekében az adatok szűrése egy lehetséges megoldás. 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 célunk az lett, hogy a hibakódokat tudjuk lekérdezni, továbbítani és törölni. Ezeket a diagnosztikai üzenetekkel (DM Diagnostic 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 akarjuk kizárólagosan átengedni. 9. ábra A kifejlesztett szűrőrendszer 18
A szűrés megvalósítása érdekében további méréseket végeztünk. A mérésekhez használt eszközök ugyanazok, mint az előzőnél, azaz egy programozható vezérlő csatlakozik a CAN buszra, fogadja az adatokat, feldolgozza, majd továbbítja soros porton keresztül egy számítógép felé. A vezérlőbe írt program most összetettebb. Két funkciót lát el, az első funkció egy azonosító listát (ID list) állít elő, ez a lista azért fontos, hogy tudjuk, hányféle üzenet továbbítódik a buszon és, hogy az egyes azonosítók hányszor jelennek meg egy megadott időn belül. Minden új üzenetnél megvizsgálja, hogy az azonosítója benne van-e már a listában, ha igen akkor hozzáad egyet a darabszámához, ha nincs, akkor beteszi az azonosítót a listába. A funkció kiválasztása után meg kell adni, hogy hány másodpercig fogadja az üzeneteket, így azonos idejű mérések végezhetők. A következő meghatározandó mennyiség a frissítési idő, ezt milliszekundumban adhatjuk meg. A beállított időközönként küldi el a vezérlő az aktuális ID listát a számítógépre. Abban az esetben, ha minden egyes új üzenet után elküldené a listát, az nagyon sok adatmennyiséget jelentene, amit nem bírna követni a soros kommunikáció, így a mérési eredmény valótlan lenne. Az idők megadása után elindul a mérés, ami elkezdi küldeni az adatokat, majd ha lejárt az idő, akkor visszalép a menübe, ahol ismét választhatunk a két funkció közül. A második funkció a szűrés, amikor csak megadott azonosítójú üzeneteket küldünk át a számítógépnek. Az azonosítókat egymás után hexadecimális formátumba kell megadni, ezután elindul a szűrés. Ez a funkció azért hasznos, mert online tudjuk monitorozni az adatok változását. Ebből a funkcióból egy billentyű megnyomásával lehet kilépni és visszatérni a menübe. A vezérlőtől kapott adatokat a számítógépen egyszerűen és gyorsan ki lehet értékelni. A vezérlőbe írt program algoritmusát a következő folyamatábra szemlélteti: 19
10. ábra A vezérlő programjának folyamatábrája Az első mérésnél a vezérlőtől a számítógép soros portján kapott adatokat egy terminálban néztük és azt írtuk le. Ennél a mérésnél nagyon nehézkes lett volna terminálból vezérelni és kimásolni az eredményeket, ezért egy kollégám készített egy olyan programot, amely megkönnyíti az adatok feldolgozását. A program Java nyelven íródott és a programozható vezérlővel kommunikál RS232-n keresztül. Az azonosító listát a program egyből táblázatba rendezi, ezzel növelve az átláthatóságot. Kiemelkedő funkciója még, hogy nem csak hexadecimálisan tudjuk 20
nézni az adatokat, hanem decimálisra, vagy akár ASCII-re is át tudja konvertálni, emellett a táblázatot ki lehet menteni Excel formátumba is. 11. ábra A számítógépes program Az előző mérésnél látszódott, hogy az ugyanolyan állapotban végzett mérések nem térnek el egymástól, ezért most az egyes állapotokat csak egyszer vizsgáltam. Így 4 darab 60 másodperces azonosító lista funkcióval végeztünk mérést. Először csak a mérés indítása után adtuk rá a gyújtást, másodszor gyújtással állandósult állapotban, harmadszor járó motorral és utoljára pedig egy diagnosztikai eszközt csatlakoztattunk mérés közben a jármű hálózatára. 21
12. ábra Az azonosítók száma az egyes állapotokban A mostani és az előző mérésből megállapítható, hogy a gyújtással állandósult állapotban és járó motor közben nem térnek el az adatok, ugyanolyan üzenetek továbbítódnak a buszon mindkét esetben, ezért ezt tekintem alap esetnek, azaz alapból 58 féle azonosító van. 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, ezeknek az üzeneteknek a nagy része címigénylő üzenet, amikor a hálózatra csatlakozó ECU-k a címeiket beállítják. Az utolsó mérés közben a diagnosztikai eszköz és az ECU-k kommunikációja növeli meg az azonosító számot, ugyanis a diagnosztikai eszköz először címet igényel, hogy fel tudjon csatlakozni a CAN hálózatra, majd lekérdezi az ECU-k állapotait. Ezek után az első diagnosztikai üzenet azonosítójára szűrtünk 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 fenti 4. ábra szerint végeztem el. Például egy üzenet azonosítója: 0CF00203. 22
4. táblázat Egy azonosító felbontása 0C F0 02 03 011 0 0 11110000 00000010 00000011 Priority Extended Data Page Data Page PDU Format PDU Specific Source Address 3 bit 1 bit 1 bit 8 bit 8 bit 8 bit 3 0 0 240 2 3 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: 61442 (00F002hex) => => 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 értelmezi elég nehézkes és sok idő lenne, sőt még vannak gyártóspecifikus üzenetek is, amelyek nincsenek benne a szabványban. Nekünk a célunk a hibakódok lekérdezése, továbbítása és törlése volt, ezért azokat az üzeneteket kell megvizsgálni, amelyek akkor keletkeznek, amikor a diagnosztikai eszköz is rácsatlakozott a jármű hálózatára. Ekkor 20-szal több azonosító érkezett, ám ezeket felbontva megállapítható, hogy csak 4 féle PGN számú üzenet érkezett, csak 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 23
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égeztünk, 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üli azonosítókban 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 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 28300 üzenetnek kevesebb, mint 8,2%. Ezt az adatmennyiséget már át tudnánk vinni GPRS átvitellel. 24
ÖSSZEFOGLALÁS Dolgozatom elkészítésének célja a járművek vezeték nélküli távdiagnosztikai lehetőségeinek kutatása. Először a vezeték nélküli kommunikációs hálózat kiválasztásával foglalkoztam, amely során a megállapításom, hogy csak a GSM hálózat felel meg a távdiagnosztizálás követelményeinek. A GSM hálózaton történő adat továbbítást legoptimálisabban GPRS technológia segítségével oldhatjuk meg, ám ennek az átviteli sebessége sem túl nagy, így ez a sebesség a kutatásom során a szűk keresztmetszet. Ezek után a járművek kommunikációs rendszerét elemeztem, amely CAN alapú, de magasabb szinten különböző lehet. Én a közép és nagy teljesítményű járművek vizsgálatát tűztem ki célul, ugyanis ide tartoznak a teherautók, autóbuszok, kamionok és egyéb közúton használt szállító járművek. Sok ilyen járművel rendelkezhetnek a flottaüzemeltetéssel, logisztikával, vagy személyszállítással foglalkozó vállalatok. A járműveik távdiagnosztizálása hasznos lehet, mert így könnyen és gyorsan felismerhetik egy távoli telephelyen vagy akár útközben felmerülő hibákat. Az irodalomkutatás után kollégáimmal méréseket végeztünk egy autóbuszon, hogy feltérképezzük a tényleges adatforgalmat. Ezekből a mérésekből látszott, hogy az összes információt nem tudjuk átvinni GSM hálózaton. Mindenképpen csökkentenünk kellett az átvinni kívánt adatmennyiséget, ezért egy egyedi fejlesztésű szűrőrendszert terveztünk. A szűrőrendszerrel további méréseket végeztünk, amelyekből levonható az a következtetés, hogy a jármű belső hálózatán a legnagyobb adatmennyiség az egyes alegységek egymással való kommunikációja miatt van, így ha azokat nem szeretnénk online monitorozni, akkor a többi átvitele megoldható GPRS protokoll segítségével. A bemutatott kutató munka a TÁMOP-4.2.1.B-10/2/KONV-2010-0001 jelű projekt részeként az Európai Unió támogatásával, az Európai Szociális Alap társfinanszírozásával valósult meg. 25
IRODALOMJEGYZÉK [1] Ajtonyi I.: Ipari Kommunikációs Rendszerek I. AUT-INFO Kft., Miskolc 2008. [2] Ajtonyi I.: Automatizálási és kommunikációs rendszerek. Miskolci Egyetemi Kiadó, Miskolc 2006. [3] SAE J1939 szabvány [4] http://en.wikipedia.org/wiki/controller_area_network 26
MELLÉKLETEK 1. sz. Melléklet: Magyarországi mobilszolgáltatók szélessávú mobil internet (3G/HSPA) és GSM lefedettsége 3G/HSPA GSM Forrás: http://www.t-mobile.hu/lakossagi/mobil_szelessav/hasznos/lefedettseg Forrás: http://www.telenor.hu/szolgaltatas/technikai-segitseg/lefedettseg/umtsmagyarorszag/ Forrás: https://www.vodafone.hu/lefedettsegi-terkep 27