Autóbusz távdiagnosztikai rendszer fejlesztése

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

Tartalomjegyzék 1.

Bevezetés ............................................................................................................................ 1

2.

A vezeték nélküli kommunikációs hálózat kiválasztása ................................................ 4 2.1.

A GSM hálózat felépítése ............................................................................................ 4

2.2.

GPRS kommunikáció .................................................................................................. 6

Járművek kommunikációs rendszere ............................................................................. 8

3.

3.1.

A CAN buszrendszer ................................................................................................... 8

3.2.

Jármű csoportok összehasonlítása ............................................................................. 12

3.3.

Tehergépjárművek, autóbuszok belső hálózata ......................................................... 16

4.

3.3.1.

A CAN azonosító értelmezése ............................................................................. 18

3.3.2.

Hálózat menedzsment ......................................................................................... 25

3.3.3.

Átviteli protokollok ............................................................................................. 28

3.3.4.

Diagnosztika ....................................................................................................... 30

Autóbuszok hálózatának vizsgálata és szimulációja ................................................... 32 4.1.

Mérések végzése ........................................................................................................ 32

4.1.1.

Az üzenetsűrűség meghatározása ....................................................................... 34

4.1.2.

Azonosítók felmérése .......................................................................................... 36

4.1.3.

Diagnosztizálás folyamatának vizsgálata........................................................... 40

4.2.

A távdiagnosztikai rendszer kialakítása ..................................................................... 41

4.3.

CAN üzenetforgalom szimulációja ............................................................................ 44

Üzenetszűrés megvalósításai .......................................................................................... 49

5.

5.1.

Első szűrőrendszer kialakítása ................................................................................... 49

5.2.

Második szűrőrendszer megvalósítása ....................................................................... 51

5.3.

Továbbfejlesztési lehetőségek ................................................................................... 61

6.

Összefoglalás ................................................................................................................... 63

Summary ................................................................................................................................. 65 Irodalomjegyzék ..................................................................................................................... 67 Mellékletek .............................................................................................................................. 68 1.

sz. Melléklet ............................................................................................................... 68

2.

sz. Melléklet ............................................................................................................... 69

I

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-4.2.1.B-10/2/KONV-2010-0001 pályázat keretében.

1.1. á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

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 P1300057 ü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ó.

1.2. á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

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

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.

2.1.

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

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).

2.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 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

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 30 – 48 kbps között szokott mozogni és a maximális feltöltési sebesség 10 – 24 kbps lehet. 6

1. táblázat: Két magyarországi szolgáltató sebesség korlátja és lefedettsége [3] GLS

GFS

Beltéri országos

Kültéri országos

lakossági ellátottság (%)

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

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 11898-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

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 11898 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

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 11898 és a lassú ISO 11519-2. Ezek a fizikai szinteken térnek el egymástól, azaz vezetéken összekötve nem kompatibilisek. Mivel az ISO 11898-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 11898 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.

3.2. á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

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 11898 á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

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

S O F

CAN ID 11 bit

S I R D R E

Data Field 0...8 byte

CAN ID 19 bit

CRC Field 16 bit

R T R

Control Field 6 bit

A C K 2bit

End of Frame 7 bit

Data Field 0...8 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 536 870 912 különféle üzenet továbbítását biztosítja.

3.2.

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 15031-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 15031 nem tartalmaz mindent és összhangban van néhány másik SAE szabvánnyal is. A protokoll szinten az ISO 15031 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 15031-nek az egyedi kommunikáció Service ID12

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 15031 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 Személyautók kis

és J1930 – feltételek és definíciók

ISO ISO11898 (5 rész) – CAN

teljesítményű J1962 – csatlakozó

járművek

J1978 – vizsgáló eszköz

ISO15765

J1979 – diagnosztikai szolgáltatások

diagnosztika CAN-en

(4

rész)

–

J2012 – hibakódok J2186 – kapcsolat biztonság

ISO15031 (7 rész) – OBD

J2534 – pass-thru

CAN-en

J1699 – OBD megfelelők Közepes és nagy J1939 (összetett részek) teljesítményű

Nincs

J2403 – feltételek és definíciók

járművek 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 15031 egyes részei leképezhető SAE szabványokra a következőképpen:  ISO 15031-2: J1930 feltételek és definíciók.  ISO 15031-3: J1962 diagnosztikai csatlakozó.  ISO 15031-4: J1978 diagnosztikai eszközzel szembeni elvárások.  ISO 15031-5: J1979 diagnosztikai szolgáltatások.  ISO 15031-6: J2012 hibakód definíciók.  ISO 15031-7: J2186 adatkapcsolat biztonság. Fizikai szinten a SAE J1939 11 és 15-ös része alkotja az egyik csoportot, a másikat az ISO 15031-3, ISO 11898-2 és ISO 15765-4. A második csoport busz sebessége kétszer akkora, azaz a J1939 250 Kbps, a másiknak 500 Kbps. A J1939/11-es szabványrész sodrott, 13

á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 15031-3-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.

3.5. ábra: Diagnosztikai csatlakozók (bal oldalon az ISO 15031-3, jobb oldalon a SAE J1939-13 által meghatározott) A CAN protokoll az alapja mindkét szabványnak, ezen belül az ISO 15031 a normál üzenetkeretet használja, azaz 11 bites azonosítót. Az ISO 15031-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

Diagnosztikai üzenetek struktúrájának összehasonlítása:

ISO 15031 [[Cél ID] [Kért szolgáltatás + kért adat]]

Tester

ECU

[[Forrás ID] [Kért szolgáltatás ID + kért adat]

J1939 [[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]

Tester

ECU

ÉS Ciklikus diagnosztikai üzenetek (pl. DM1)

3.6. ábra: Az ISO 15031 é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 Low Byte SPN MSB <------->

Byte2 Mid Byte SPN MSB <------->

Byte3 SPN 3 MSB + FMI

Byte4 Conversion Method +

C OC M 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 SPN

FMI

3.7. ábra: A J1939 által meghatározott hibakód felépítése Az ISO 15031 által meghatározott Diagnostic Trouble Code pedig a következő ábrán.

DTC Byte 1 Byte 2 Byte 3 SAE Code Number FTB 1. 2. 3. 4. 5. 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 3.8. ábra: Az ISO 15031-es szabványban definiált hibakód

15

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 3.

3.3.

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 11783 – 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

NMEA2000 - 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 11992 – Digitális információváltás a vontató és a vontatott jármű között (TruckTrailer) 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

J1939/7x

6. Megjelenítési réteg

J1939/6x

5. Viszonylati réteg

J1939/5x

4. Szállítási réteg

J1939/4x

3. Hálózati réteg

J1939/3x

2. Adatkapcsolati réteg

2. Adatkapcsolati réteg

J1939/2x

1. Fizikai réteg

1. Fizikai réteg

J1939/1x

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

7. Alkalmazási réteg

Magasabb szintű protokoll nélkül

7. Alkalmazási réteg

3.10. á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 J1939-71). 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. 3.3.1. 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 3.11. és 3.12. á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

 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.

3.11. ábra: A paramétercsoport száma a PDU1 szerint 19



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 240nél kisebb és az utolsó 8 bit értéke 0.

3.12. á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 240 + (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

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 15765-3 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 3.13. és 3.14. ábrákon egy-egy üzenet küldése és fogadása látható.

3.13. ábra: Példa az RPM adat küldésére

21

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 524287-ig terjedhet. A gyártói paramétereknek 520192-től 524287-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

65 262 (00FEEEhex)

22

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

110

2

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

176

7

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

-40 – 210 °C

Típus

Mért

Referencia

65 262 (00FEEEhex) 6. táblázat: PGN tartományok

DP

PGN tartomány (hex)

PGN-ek száma

SAE vagy gyártó

Kommunikáció

0

000000 – 00EE00

239

SAE

PDU1

0

00EF00

1

GY

PDU1

0

00F000 – 00FEFF

3840

SAE

PDU2

0

00FF00 – 00FFFF

256

GY

PDU2

1

010000 – 01EE00

239

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

3.15. ábra: Az SPN, PGN és a CAN üzenetkeret kapcsolata

Speciális paramétercsoportok A SAE J1939-21 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 00EA00hex) 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 00E800hex) 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 00FED8hex) 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 00EC00hex és TP-DT, PGN 00EB00hex) 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 00EF00hex és Proprietary B, PGN 00FF00-00FFFFhex) 24

3.3.2. Hálózat menedzsment Az Electronic Control Unit (ECU) szoftvere a Controller Application (CA). Egy ECU tartalmazhat egy vagy több CA-t is.

3.16. á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:  0..253

Érvényes forrás címek CA-knak.

 0..127 és 248..253

Használható CA-knak előnyben részesített címmel és definiált függvényekkel.

 128..247

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 00EE00hex) 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 J1939-81 határozza meg.

25

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.

3.18. á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

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.

3.20. ábra: Kérelem cím igénylésre

27

Cím képesség A SAE J1939-81 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. 3.3.3. Átviteli protokollok Több mint 8 adat bájt továbbítása átviteli protokoll segítségével történik.

3.21. á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

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.

3.23. ábra: BAM továbbítás 29

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.

3.24. ábra: RTS/CTS átvitel

3.3.4. 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 FECAhex). 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

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.

3.25. á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

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.

4.1. á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

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

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é.

4.3. ábra: CAN és RS232 kommunikációra alkalmas mikroprocesszor

4.1.1. 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

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 10 – 100 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 28300 ü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 28300 ü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

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.

4.5. á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. 4.1.2. 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

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.

4.6. á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

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

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 3.11. és 3.12. ábrák szerint végeztem el. Például egy üzenet azonosítója: 0CF00203.

7. táblázat: Egy azonosító felbontása 0C 011 Priority 3 bit 3

0 Extended Data Page 1 bit 0

0 Data Page 1 bit 0

F0 11110000

02 00000010

03 00000011

PDU Format 8 bit 240

PDU Specific 8 bit 2

Source Address 8 bit 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 é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

megvizsgálni, amelyek akkor keletkeznek, amikor a diagnosztikai eszköz is rácsatlakozott a jármű hálózatára. 4.1.3. 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

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%. Á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.

4.2.

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 CAN interfész

4.9. ábra: A diagnosztizálás folyamata 41

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 Diagnosztikai szoftver

Távoli helyszín Telekommunikációs hálózat

Diagnosztikai CAN interfész

CAN

4.10. á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

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 Diagnosztikai szoftver

Router Ethernet CAN/ Ethernet konverter

Távoli helyszín Mobil hálózat

GPRS modem RS232 CAN üzenet szűrő µC

Diagnosztikai CAN interfész

CAN

4.11. ábra: GSM hálózaton keresztüli távdiagnosztizálás A 4.11. á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

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

4.12. á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

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ó.

4.13. á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 115200 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

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()

4.14. á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

4.15. á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 4.15. ábrán is. 46

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

4.16. á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

RS232

USB CAN/USB konverter

CAN

CAN/ RS232 konverter CAN/ RS232 konverter

RS232 µC

CAN

4.17. ábra: Az elkészített CAN üzenetforgalom szimuláló rendszer Az előző ábrán látható az elkészített rendszer. Az 4.12. á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

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 00FF0000 00FE0000

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:  00EA00hex kérés paramétercsoport (RQST)  00EB00hex és 00EC00hex átviteli protokoll paramétercsoportok (TP-CM és TP-DT)  00EE00hex cím igénylő paramétercsoport  00EF00hex és 00FF00hex gyártó specifikus paraméter csoportok  00FE00hex diagnosztikai üzenetek 49

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.

5.1. á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) szűrés nélkül 3 ID szűrés 6 ID szűrés 11 ID szűrés maszkolás

82,107 93,262 116,83 69,948

üzenet szám üzenet/sec 472 10000 121,7911 10000 107,2242 10000 85,59211 5000 71,48157 50

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.

5.2.

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.

RS232

USB CAN/USB konverter

CAN

CAN/ RS232 konverter RS232 µC

µC

CAN

5.2. ábra: Az újratervezett rendszer 51

A 4.17. á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 2008ban 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

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

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 I2C, 1 USB, 2 LIN, 1 CAN, 1 I2S, 2 komparátor, 8 PWM, 8x12-bit ADC, RTC, EBI, ISP, ICP, IRC 22 MHz, 9 PDMA.  Tokozás: LQFP100. 54

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 11898-as szabvány fizikai rétegre vonatkozó követelményeit.

5.4. á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

5.5. ábra: Az azonosítók száma az egyes állapotokban

Ez alapján döntöttem úgy, hogy kidolgozom egy olyan algoritmust, melynek segítségével az azonosítókat egy-egy rövidebb kódszóvá alakítanám. Mivel maximum 80-100 azonosítóról van szó, ezeket akár 7 bites kódszavakra át lehet alakítani. A küldő eszköz egy előzetes teszt alapján készít egy listát arról, hogy milyen ID-khez milyen kódszavakat rendel, majd ezeket továbbítaná a fogadó számára. A vevő oldalon lévő mikrovezérlő a fogadott lista alapján egyértelműen vissza tudja alakítani az eredeti CAN üzeneteket. Tehát elég a megadott kódot elküldeni és a vevőoldalon kikeresni a listából, hogy milyen azonosító volt az eredeti üzenetben. Ezzel a technikával jelentős üzenetforgalom takarítható meg, ugyanis a 29 bites azonosítóból 7 bites képezhető. Az eredeti CAN/RS232 átalakításnál a CAN üzenet hexadecimális számokkal volt kódolva. Ezek már karakterenként, ASCII kódolással jött ki az RS232 oldalból, tehát az eredetileg 1 bájtos 2 hexadecimális karakterből álló adatot 2 bájton küldi el. (Az ASCII szabvány egy karaktert 8 biten kódol).

9. táblázat: A megkapott CAN üzenet részei és adattartományai ID DLC 29 bit 4 bit 0000 0000 0 ~ ~ 1FFF FFFF 8

D1 8 bit 00 ~ FF

D2 8 bit 00 ~ FF

D3 8 bit 00 ~ FF

D4 8 bit 00 ~ FF

D5 8 bit 00 ~ FF

D6 8 bit 00 ~ FF

D7 8 bit 00 ~ FF

D8 8 bit 00 ~ FF

A táblázatban szereplő adatokat küldi át a soros átalakításkor egy sima konverter eszköz, az egyes hexadecimális értékeket karakterenként. Ez összesen 25 bájtot jelent, közben 56

nekünk a hasznos információ csak 97 bit, azaz 12 bájt. Sőt a mérésekből megállapítottam, hogy minden üzenet 8 bájtos adatrésszel dolgozik, így a DLC (Data Length Code) átvitele nem is szükséges. Az ASCII kódolás helyett az adatokat az értéküknek megfelelően 8 biten viszem át és a fentebb leírt módszerrel az azonosítókat kicserélem egy 1 bájtos kódszóra, ezzel a 25 bájt helyett csak 9 bájtos lesz egy üzenet. Ez az átlag másodpercenkénti 500 üzenetnél 64 kbit/s-os adatforgalom megtakarítást eredményez.

5.6. ábra: Az újfajta szűrési eljárással elérhető adatforgalom csökkenés

Ezzel a megoldással harmadára le tudtam csökkenteni a GSM hálózaton keresztül továbbítandó adatmennyiséget. A program működése: Sikerült a korábban említett megoldásnál egy jobbat készítenem, ugyanis nem kell a küldő eszköznek megvizsgálnia a CAN hálózatot egy bizonyos ideig, hanem valós időben működik az átalakítás. A mikrovezérlős program megszakításokkal kezeli mind a CAN port-on, mind az UART-on érkező üzeneteket. Külön kezelem a mindkét kommunikációs interfésztől kapott üzeneteket, ugyanis tudom, hogy egy CAN azonosító csak egy oldalról érkezhet, vagy a jármű vagy pedig a diagnosztikai szoftver felől. Az algoritmus viszont hasonló, de először a CAN üzenet fogadását részletezem ki.

57

CAN megszakítás érkezett Az üzenet felbontása, azonosítóra, adatrészre

Az azonosító benne van a listában? IGEN Az azonosítóhoz tartozó kódszó megkeresése

UART küldés: 1 bájt (kódszó+100)

NEM

NEM Kódszó generálás

Az azonosító és az adat elmentése

UART küldés: 12 bájt (ID, adat)

Változott az adatrész?

IGEN Az új adat elmentése

UART küldés: 9 bájt (kódszó, adat)

5.7. ábra: Folyamatábra a CAN üzenet fogadás és UART küldés működéséről Minden beérkező üzenet azonosítóját megvizsgálja, hogy benne van-e a listájában. Ha nincs benne, akkor beilleszti a listába, hozzárendel egy kódszót és az üzenet adatrészében található információkat is elmenti. Ezután kiküldi az azonosítót és az adatot. Nyilván az első üzenetet automatikusan beteszi a lista elejére. Ha az azonosító benne van a listában, akkor nem is nézi tovább a listát, mert két ugyanolyan azonosító nem lehet benne. Ekkor 58

még megvizsgálja az adatrészt. Ha az adat nem változott, akkor csak a kódszót küldi egy megadott mennyiséggel megnövelve. Így a vevő tudni fogja, hogy az adott kódszójú elmentett üzenetet kell elküldeni. Ezt a funkciót azért építettem bele, mert a mérések során megállapítottam, hogy több azonosító mindig ugyanazokat az adatokat küldi, ilyenek a nem vagy csak nagyon lassan változó értékek, státusz információk. Ezeknél az adat többszöri elküldése teljesen felesleges, így még üzenetenként 8 bájt takarítható meg. A kódszó hozzárendelésnél sokat gondolkodtam egy olyan kódoláson, amely a gyakori üzenetekhez kisebb kódszavakat rendel (például Huffman kód), viszont az én esetemben megadott nagyságú lehet egy soros üzenet, amit ki kell töltenünk mindenképpen. A bitek eltolása nem megoldás, ugyanis akkor az üzenet végén keletkeznek üres helyek, amelyeket szintén fel kell tölteni. Egy CAN üzenet érkezésekor eltérő mennyiségű információt küld ki UART-on:  Ha benne van a listában és az adat nem változott → csak a kódszó, egy meghatározott értékkel megnövelve (1 bájt)  Ha benne van a listában és az adat változott → kódszó + adat (9 bájt)  Ha nincs benne a listában → azonosító + adat (12 bájt) Így az UART-on érkező üzenet első bájtjából kell megállapítani, hogy melyik eset áll fent. Ezt a következőképpen oldottam meg: Egy CAN azonosító 29 bites, azaz nem használ ki 4 bájtot, a felső 3 bit így mindig nulla. Ennek értelmében az első bájt 00hex és 1Fhex közötti értéket vehet fel, amely decimálisan 0-tól 31-ig terjedhet. Mint köztudott 1 bájton 0 és 255 közötti számot tudunk leírni (00hex – FFhex), ezáltal 224 féle értéket tudok még másra felhasználni. Ez teljes mértékben elegendő a kódszavak tárolására, sőt még külön információt hordozó kódszavakat is képezhetek. Új CAN azonosító érkezésekor az adott eszköz beteszi a listájába azt és kiküldi az eredeti azonosítóval. Ilyenkor a vevő oldal tudja, hogy az egy CAN azonosító és ő is beteszi a listájába. Ezzel a megoldással, ugyanazok a kódszavak lesznek mind a vevő, mind az adó oldalon, így nem szükséges elküldeni a kódszót az azonosítóval együtt, majd pedig elég a kódszót küldeni.

59

UART megszakítás érkezett

IGEN 1.bájt < 32 ?

Azonosító meghatározása

NEM

Még 8 bájt beolvasása UART-ról Azonosító meghatározása Az új adat elmentése

Még 11 bájt beolvasása UART-ról

IGEN ID és adat elmentése

1.bájt < 132 ?

NEM

CAN üzenet küldés

IGEN 1.bájt < 232 ?

Azonosító és a hozzá tartozó adat megkeresése

CAN üzenet küldés NEM CAN üzenet küldés Hibakezelésre fenntartott rész

5.8. ábra: Folyamatábra az UART üzenet fogadás és CAN küldés működéséről

A fentebb leírt átalakításokkal elértem azt, hogy az UART-on kapott üzeneteket nem kell megkeresni egy listában, mert az első bájtból megállapítható, hogy az üzenet volt már vagy nem. Sőt az UART-on beolvasandó bájtok számát is az első bájt értéke határozza meg. Első esetben, ha a kapott bájt kisebb, mint 32, akkor az üzenet egy CAN azonosítóval kezdődik, azaz még nem szerepel a listában. Ilyenkor az első bájton kívül még 11-et kell beolvasni és megkapjuk az üzenet adatrészét is. Ennek a beolvasása után, az azonosítót kell összerakni a megfelelő formátumban és az üzenet már küldhető is a CAN hálózatra. Természetesen ilyenkor a meghatározott azonosítót és az adat részt is eltárolom egy tömbbe. 60

Második esetben, amikor az első bájt értéke 31 és 132 közé esik, akkor egy kódszót kapunk. A fentebb leírtak értelmében ilyenkor változott az adat, azaz az egy bájtos kódszó után még 8 bájtot kell beolvasni és megkapjuk a megváltozott adatrészét a CAN üzenetnek. Ha az első bájt 132 vagy annál nagyobb, akkor egy előre megadott értékkel megnövelt kódszót kapunk. Ilyenkor az adat rész sem változott, csak a kódszóhoz tartozó letárolt üzenetet kell kiküldeni CAN-en keresztül.

5.3.

Továbbfejlesztési lehetőségek

A kommunikációban mindig történhet valamilyen hiba, ezért hibakezelő funkciók létrehozása a jövőbeli célom. Ezek akkor aktiválódhatnak, ha egy üzenet elveszik és a vevő nem tudja értelmezni a kapott adatokat. Belátható, hogy ez csak az UART-ról érkező üzenetek esetében áll fent. Ugyanis a CAN hálózatról közvetlenül kapja a mikrovezérlő az adatokat, míg az UART üzenetek lesznek vezeték nélküli kommunikációs hálózaton keresztül továbbítva. Az egyik ilyen funkció, amely éppen implementálás és tesztelés alatt van, akkor aktiválódik, ha egy új CAN azonosítót tartalmazó üzenet elveszik, azaz nem jut el a másik egységhez UART-on keresztül. Egy kódszót tartalmazó üzenet kimaradásánál ez sokkal több gondot okozhat, ugyanis ekkor a küldő oldal már rendelt kódszót az adott azonosítóhoz, viszont a fogadó oldal még nem. Ha újra ezt az azonosítót kapja meg a küldő eszköz, akkor ő már csak kódszót küld ki. Ilyenkor a vevő oldalon található eszköz egy olyan kódszót kap, amelyhez még nem rendelt azonosítót és így nem tudja kiküldeni a CAN üzenetet. Ekkor visszajelez a küldő oldalnak, hogy ő nem ismeri az adott kódszót, erre a küldő oldal megadja a kódszóhoz tartozó azonosítót és a kommunikáció folytatódhat. A következőkben egy példa alapján mutatom be az adatcsökkentési eljárásom hatékonyságát. Tegyük fel, hogy egy autóbusz diagnosztizálásánál 70 különböző azonosítójú üzenetet tapasztalunk és a diagnosztizálási folyamatot egy percig végezzük. A következő diagramon látható a szűrés nélküli, valamint az általam készített szűrési eljárással elérhető adatátviteli sebességek alakulása az üzenetek adatrészének megváltozása függvényében.

61

5.9. ábra: Az adatátviteli sebesség alakulása szűréssel és szűrés nélkül

Az ábrán látható, hogy ha az üzenetek adatrésze nem változik, akkor nagyon alacsony adatátviteli sebességet érhetünk el, persze ez nem valóságos. Autóbuszok tekintetében a méréseim elvégzése után az a megállapításom, hogy körülbelül az üzenetek felének az adatrésze nem, vagy csak nagyon lassan változik. A leírtak alapján ezzel a szűrési eljárással elérhető adatátviteli sebesség 20 kbit/s alá vihető. Ez az érték kielégíti a rendszer fejlesztésénél támasztott elvárásokat, ugyanis nagy mennyiségű adatcsökkentést tudtam elérni úgy, hogy minden egyes üzenetet átküld a kifejlesztett rendszer. Az elért adatátviteli sebesség csökkenés biztató a rendszer továbbfejleszthetőségében. Több irányban is lehet indulni, az egyik hogy még tovább csökkentjük az adatmennyiséget valamilyen olyan szűrőalgoritmussal, amely részarányosan ritkítja meg az üzeneteket, azaz minden azonosítót átenged, csak a nagyon gyakoriakból minden ötvenediket vagy századikat. Ehhez mindenképpen egy autóbuszra és egy diagnosztikai szoftverre van szükség, ugyanis itt a diagnosztizálás folyamatának stabilitását kellene vizsgálni és az alapján behangolni a rendszert. A másik továbbfejleszthetőség a napjainkban rohamosan fejlődő szélessávú 3G mobilhálózatok vizsgálata. Egyes szolgáltatók már 90%-os lefedettséget ígérnek. Ilyen rendszer fejlesztésénél nagy hangsúly van a lefedettségen, ugyanis ebben az esetben vizsgálatokat kell végezni arra vonatkozóan, hogy mi történik nem lefedett területen, vagy hogyan jelezze a rendszer, hogy elérhető hálózatot talált.

62

6. Összefoglalás Diplomamunkám elkészítésének célja autóbuszok távdiagnosztikai lehetőségeinek kutatása. A járművek hibás működése a közlekedésben késéshez vagy akár leálláshoz vezet, amelynek költségvonzata nem elhanyagolható. Ennek elkerülése érdekében a járművek folyamatos felügyelete szükséges, lehetővé téve a zavarok megelőzését vagy időben elhárítását. A távdiagnosztika feladata a szükséges diagnosztikai információk továbbítása egy felügyeleti központ felé, ahol szakértő azonosítja a működési paramétereket, felméri az eltéréseket és előrejelzést ad. Járművek távdiagnosztizálásához mindenképpen vezeték nélküli kommunikációs hálózatot kell használni, először ennek a kiválasztásával foglalkoztam, amely során a megállapításom, hogy ma hazánkban 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 volt a kutatásom során a szűk keresztmetszet. A vezeték nélküli hálózat kiválasztása után ismertettem a járművekben használt CAN buszrendszert általánosan, majd még ebben a fejezetben kitértem a járművek két csoportjára és azok összehasonlítására a diagnosztikai szabványok tekintetében. Ez az összehasonlítás fontos, hogy tisztában legyünk a járművek közötti különbségekkel. Én a közepes é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. Ezek a járművek a SAE J1939-es szabványt alkalmazzák, így ennek a részletesebb bemutatása is megtalálható a dolgozatomban. Méréseket végeztem több autóbuszon is, hogy feltérképezzem a tényleges adatforgalmat. Ezekből a mérésekből látszott, hogy az összes információt nem lehet továbbítani GSM hálózaton. Mindenképpen csökkenteni kellett az átvinni kívánt adatmennyiséget, ezért egy egyedi fejlesztésű szűrőrendszert terveztem. A mérési eredményeket a negyedik fejezetben értékeltem ki. A szűrőalgoritmusok implementálása előtt elkészítettem egy olyan programot, amellyel az autóbuszok CAN üzenetforgalma szimulálható. Az elkészített rendszer segítségével 63

teszteltem a korábbi szűrőalgoritmusokat. A tesztek sikeresek voltak, ugyanis rájöttem az egyes szűrőalgoritmusok hiányaira. A jövőbeli célom még a program univerzálissá tétele, azaz hogy ne csak az autóbuszok CAN üzenetforgalmát tudja szimulálni, hanem bármilyen CAN üzenetet tudjunk vele küldeni, akár 2.0A vagy 2.0B szabványnak megfelelőt. Ezáltal a program alkalmas lenne az oktatásba történő bevonásra, az Ipari kommunikáció tantárgy gyakorlatain be lehetne mutatni, így a hallgatók könnyebben megismerkednének a CAN buszrendszerrel. Az új szűrőrendszer tervezése és az adat redukálási módszerek bemutatása az ötödik fejezetben található. Itt tartom fontosnak megemlíteni, hogy a dolgozatomban részletezett SAE J1939-es szabvány ismerete nélkül nem sikerülhetett volna létrehoznom egy ilyen rendszert és a szűrőalgoritmusok fejlesztéséhez is elengedhetetlen a szabvány megismerése. Diplomamunkám elkészítése során az autóbuszok távdiagnosztizálásával foglalkoztam, amik a közepes és nagy teljesítményű járművek csoportjába tartoznak, a teherautók, kamionok és egyéb közúton használt szállítójárművek mellett, így az általam elkészített rendszer alkalmas ezen járművek távdiagnosztizálására is. Az egész rendszer elkészítése nagyon sok munkát és időt vett igénybe, a távdiagnosztika megvalósíthatóságának feltárásától, a számítógépes és mikrovezérlős alkalmazások implementálásán át, a kész rendszer megalkotásáig. Mindent egyedül nem is tehettem volna meg, így itt ragadnám meg az alkalmat, hogy köszönetet mondjak Kolozsi-Tóth Máténak, Méhes Lászlónak és Trohák Attilának, akik mindig segítőkészek voltak, ha egyegy dologban elakadtam és hasznos tanácsokkal láttak el. „A kutató munka a Miskolci Egyetem stratégiai kutatási területén működő Mechatronikai és Logisztikai Kiválósági Központ keretében valósult meg.”

64

Summary The theme of my dissertation is the development of remote diagnostics system for vehicles. A vehicle’s diagnostic is a significant capability. It can give access to the actual values of health information of the different sub-systems to the vehicle’s owner or to the repair technician. Performing a vehicle diagnostic test with a scan tool we can save a lot of time and money when troubleshooting a problem, because the mechanics can arrive well equipped to repair the vehicle. Remote diagnostics means the substitution of regular in-place diagnostic processes with methods based on telecommunication networks. This includes online monitoring of the vehicles' On-Board systems. If we would like to diagnose a vehicle on route, we have to use a wireless communication network. The most important requirements regarding to the network are the full availability and coverage. When I started this project the broadband wireless Internet coverage was not good enough in Hungary, today only the GSM network meets these requirements, which ensure 99 percent coverage. The data transmission via GSM network is provided by the GPRS protocol. Internal networks of vehicles are different, split into two groups. I deal with medium and heavy duty vehicles, because there are many firms especially logistics-, public transportation-, and fleet management companies which have a lot of from these vehicles. If they would use remote diagnostics of vehicles, then these devices would provide increased reliability and decreased down-time. For a company it is useful, and necessary as well, because they can easily diagnose their vehicles on remote sites or on route and they can reduce costs by making good decisions when a vehicle goes wrong. The vehicle’s internal network is much faster than it could be achieved with GPRS, so it is necessary to reduce the amount of data to be transmitted for remote diagnostics through GSM network. Among the medium and heavy duty vehicles I researched the remote diagnostic capability of buses used for public transportation. For a transportation company the remote diagnostics is useful, because they can easily diagnose their vehicles on remote sites or on route and they can reduce costs by making good decisions when a vehicle goes wrong. This system also can be useful for transportation companies for advanced fleet management. As I can not have an access to a bus, I produce the data traffic of the internal CAN network with simulation. I prepared the simulation based on measurements with 65

more buses. Therefore the implemented filter algorithms and the reduced amount of data transmitted can be compared. Finally I introduce my research results on how to make possible remote diagnostics of vehicles through a GSM system. I explain my implemented filter algorithms developed into a programmable controller for the reduction of communication load. This could be a possible solution to balance the data link and the remote diagnostic fool proof execution. „This research was (partially) carried out in the framework of the Center of Excellence of Mechatronics and Logistics at the University of Miskolc.”

66

Irodalomjegyzék [1] Ajtonyi István: Automatizálási és kommunikációs rendszerek. Miskolci Egyetemi Kiadó, Miskolc 2006. [2] Ajtonyi István: Ipari Kommunikációs Rendszerek IV. AUT-INFO Kft., Miskolc 2011. [3] Nemzeti Média- és Hírközlési Hatóság hivatalos honlapja (www.nmhh.hu) [4] Dominique Paret: Multiplexed Networks for Embedded Systems: CAN, LIN, FlexRay, Safe-by-Wire..., John Wiley & Sons, 2007. [5] Ajtonyi István: Ipari Kommunikációs Rendszerek I. AUT-INFO Kft., Miskolc 2008. [6] Jeffrey Craig (Vector CANtech, Inc.): A Comparison of J1939 and ISO15031, SAE On-Board Diagnostics Symposium, 2009. [7] Markus Junger: Introduction to J1939, Vector Informatik GmBH, 2010. [8] Wilfred Voss: SAE J1939 – Serial Control and Communications Vehicle Network, esd electronics, Inc., 2012. [9] Marco Di Natale, Haibo Zeng, Paolo Giusto, Arkadeb Ghosal: Understanding and Using the Controller Area Network Communication Protocol, 2012. [10] Powertrain Control Solutions: J1939 Communication Document, 2006. [11] Sean Bennett: Heavy Duty Truck Systems, Cengage Learning, 2010. [12] Attila Trohák, Béla Illés, Zoltán Biró: CAN Message Filter Algorithms for Remote Diagnostics of Vehicles, Applied Mechanics and Materials (Volume 309): III Central European Conference on Logistics, 2012. [13] Joseph Yiu: The Definitive Guide to the ARM Cortex-M0, Newnes/Elsevier 2011. [14] Nuvoton Technology Corp. honlapja (www.nuvoton.com)

67

Mellékletek 1. sz. Melléklet A három legnagyobb magyarországi mobil szolgáltató GPRS és 3G-s lefedettség térképe (balra a GPRS, jobbra a 3G, piros színnel a beltéri, sárga színnel pedig a kültéri lefedettség)

Forrás: Nemzeti Média- és Hírközlési Hatóság (www.nmhh.hu) Az adat 2012.06.30-ai, a legfrissebb, ami a honlapjukon található.

68

2. sz. Melléklet Az elkészített CAN üzenetforgalom szimuláló program folyamatábrája. A program indítása

Excel fájlból adatok beolvasása

Portok vizsgálata

RS-232 paraméterek beállítása

Kapcsolódás SIKERTELEN SIKERES Ha szükséges, változtatás az ID listán START CAN üzenetek küldése STOP

69