Budapesti Műszaki Főiskola Intelligens Automatizált Rendszerek
ReD-CAN Remote Diagnostics on Controller Area Network
Távdiagnosztika CAN hálózatokon
TDK Dolgozat
Készítette: Kajtár Lehel Sziráczki Zsolt Konzulensek: Fejes Péter, fejlesztőmérnök (Cason Rt.) Vámossy Zoltán, docens (BMF-NIK)
2004. november 8.
ReD-CAN
Tartalom
Tartalom TARTALOM ................................................................................................................. 2 BEVEZETŐ .................................................................................................................. 4 IRODALOMKUTATÁS .................................................................................................. 6 FLOTTAKÖVETŐ RENDSZEREK........................................................................................... 6 Áttekintés ........................................................................................................... 6 Mobil egység ................................................................................................................. Bázis állomás ................................................................................................................ Szoftver ....................................................................................................................... Kommunikáció ..............................................................................................................
6 7 7 7
Flottakövető rendszerek alkalmazása ...................................................................... 7
NavSky Nova ................................................................................................................ 7 NavCenter .................................................................................................................... 8 Cason HiROT................................................................................................................. 9
FELHASZNÁLT TECHNOLÓGIÁK ........................................................................................ 12 GPS ................................................................................................................. 12 A A A A
műholdak .................................................................................................................12 földi rendszerek .........................................................................................................13 vevőkészülékek .........................................................................................................14 GPS Rendszer működése.............................................................................................15
GSM................................................................................................................. 18 GPRS ..........................................................................................................................18
CAN ................................................................................................................. 20 A fizikai szint................................................................................................................20 Adatcsere ....................................................................................................................21 A nem destruktív bitenkénti döntés..............................................................................22 Az üzenetek keretformátumai .....................................................................................23 Hibadetektálás és kijelzés...........................................................................................23 A CAN protokoll adatainak megbízhatósága...................................................................24 Kiterjesztett CAN üzenetformátum ..................................................................................25 FMS ........................................................................................................................26 A CAN protokoll megvalósításai.......................................................................................27 A CAN hálózat használata járművekben ........................................................................27 A CAN hálózat ipari alkalmazásai .................................................................................30 A CAN és a PC kapcsolata...........................................................................................31
Soros kommunikáció .......................................................................................... 32
Modem a soros porton ...................................................................................................32 Az aszinkron soros adatátvitel ........................................................................................32 Az átvitel jellemzői........................................................................................................33 Eszközök összekötése....................................................................................................34
RENDSZER CÉLJA ..................................................................................................... 35 A RENDSZER RÖVID BEMUTATÁSA.................................................................................... 35 A PROJEKT LÉPÉSEI .................................................................................................... 35 RENDSZER MEGVALÓSÍTÁSA.................................................................................... 36 ÁTTEKINTÉS ............................................................................................................ 36 HARDVERESZKÖZÖK BEMUTATÁSA ................................................................................... 37 MCU................................................................................................................. 37 I/O Portok ...................................................................................................................39 SPI interfész ................................................................................................................39 USART interfész............................................................................................................40 Külső megszakítások .....................................................................................................40
CAN Controller................................................................................................... 40 FEJLESZTŐESZKÖZÖK BEMUTATÁSA ................................................................................. 41 DEMO RENDSZER ...................................................................................................... 42 -2-
ReD-CAN FMS szimulátor .................................................................................................. 42 Fizikai szint..................................................................................................................42 Algoritmusok................................................................................................................42 Inicializáció ..............................................................................................................42 Portok inicializálása................................................................................................42 SPI interfész inicializálása .......................................................................................42 CAN vezérlő inicializálása........................................................................................43 Üzenetküldés............................................................................................................43 Az FMS üzenet felépítése, kiküldése .............................................................................44
FMS-SPY........................................................................................................... 46 Fizikai szint..................................................................................................................46 Algoritmusok................................................................................................................46
Megjelenítés...................................................................................................... 48 Soros fogadóprogram ....................................................................................................48 A program működése ................................................................................................48 SQL szerver .................................................................................................................49 Web szerver és a böngésző kliens ...................................................................................50
ÖSSZEKÖTTETÉS A HIROT-TAL ...................................................................................... 51
EREDMÉNYEK ÖSSZEGZÉSE ...................................................................................... 52 TESZTELÉS ............................................................................................................. 52 ÖSSZEFOGLALÁS....................................................................................................... 53 MELLÉKLETEK .......................................................................................................... 55 FMS SZABVÁNY ........................................................................................................ KAPCSOLÁSI RAJZOK .................................................................................................. FMS szimulátor .................................................................................................. FMS-spy ........................................................................................................... REGISZTEREK .......................................................................................................... ATMega128 .......................................................................................................
55 57 57 59 61 61
SPI .............................................................................................................................61 USART ........................................................................................................................64 Megszakítások..............................................................................................................69
MCP2515 .......................................................................................................... 70
IRODALOMJEGYZÉK ................................................................................................. 74
-3-
ReD-CAN
Bevezető
Bevezető Sokakban felmerülhet a kérdés, hogy mi szükség lehet távdiagnosztikára? Az élet nagyon sok területén hasznosítható a távdiagnosztika, melynek segítségével aktuális információkat szerezhetünk. Egyszerűen belátható, hogy mekkora előnyt jelenthet, ha például egy diszpécser állomás kezelőszemélyzete folyamatosan tisztában van a járműveik pozíciójával, legyenek azok akár tűzoltó autók, rendőr járőrkocsik, avagy akár a hegyimentő csapat hójáró járművei. Ettől nagyobb segítséget nyújt, ha a pozíción kívül még egyéb információkat is megkapunk, mint például sebesség, haladási irány, ha csak a legalapvetőbb lehetőségeket nézzük. A legnagyobb igény ilyen irányú fejlesztésekre, így az első megvalósítások is a logisztika területén jelentek meg. Ezek az első, kezdetleges eszközök a járművekbe építve rögzítették a jármű mozgásáról begyűjtött pillanatnyi információkat, és ezekhez a szakemberek később, a telephelyen juthattak hozzá (néhány esetben csak az egész szerkezet kiszerelésével, vagy valamilyen elektronikus csatlakozás segítségével). Ezek a rendszerek még nem teljesítették az összes elvárást, nem szolgáltatták folyamatosan a pillanatnyi állapotot jellemző információkat, csakis visszamenőleges elemzést tettek lehetővé, de ezzel is nagyban segítették a logisztikai cégek működését. Az ilyen flottakövető rendszerek által szolgáltatott információk hamarosan a vállalat irányítási rendszerek fontos részévé váltak. A következő lépés a flottakövető rendszerek evolúciójában az online rendszerek megjelenése, vagyis azon rendszereké, melyek információi már nem csak a telephelyen voltak hozzáférhetőek, hanem menet közben is elküldésre kerültek valamilyen GSM technológia segítségével. Legtöbbször vagy telefonhívás formájában, mint pl. egy fax üzenet, vagy SMS-en keresztül. Ezeknek a rendszereknek legnagyobb hátránya az információcsere költséges mivolta. Még mindig nem volt elérhető a folytonos információáramlás, csak bizonyos nagyobb időközönként került összeállításra egy-egy adatcsomag, majd ezt továbbította a rendszer a központ felé. Ezt a hibát orvosolja a GPRS rendszer használata, ahol akár folyamatos információáramlás is lehetséges, megfizethető költségek mellett. A pozíció meghatározás első, kezdetleges formája a GSM cellainformáció felhasználása volt, amely több tíz kilométeres pontossággal működött. A GPS rendszer üzembe helyezése után az átlagember számára is elérhetővé vált egy igen pontos helymeghatározási rendszer, így a flottakövető rendszerek már néhány száz méteres pontossággal szolgáltathatták a pozíció információkat. Mikor 2000ben az amerikai elnök megszüntette a GPS jelének szándékos zavarását, akkor ez a pontosság megközelítette a néhány méteres pontossági szintet, amely már maximálisan kielégíti a flottakövető rendszerek ilyen jellegű igényét. Ezek a rendszerek már folyamatos nyomkövetést tesznek lehetővé, megfelelő pontossággal, azonban a szolgáltatott információk a pozícióban ki is merülnek. Ezekből még számítások segítségével meghatározhatunk egyéb jellemzőket is, mint pl. sebesség, gyorsulás, megtett km. Ezektől sokkal több információ szolgáltatható egy, a járművekbe épített érzékelő hálózat segítségével, mely a Bosch által kifejlesztett CAN (Controller Area Network) szabvány szerint működik. Ez a hálózat a járműről begyűjthető összes elképzelhető információt folyamatosan szolgáltatja, kezdve a sebességtől, a gyorsuláson, fordulatszámon, fogyasztáson át egészen az egyes tengelyekre eső terhelésig. A rendszer maximálisan moduláris, könnyen bővíthető, így egyéb érzékelőket is kapcsolhatunk hozzá, mint például egy hőmérő a szállítmány figyelésére, vagy az ajtó kinyitását jelző érzékelő. A rendszer elterjedésével az egyes kamiongyártók külön-külön üzenetformátumokat, azonosítókat definiáltak a saját megoldásukhoz, így nehéz lenne egy gyártó független eszköz kifejlesztése, de szerencsére 2002-ben összefogtak a nagyobb tehergépjármű gyártók, és egy egyezményes rendszer kialakítását tűzték ki célul, ez lett az FMS szabvány. Ez a szabvány minden érzékelő által szolgáltatott adathoz egy azonosítót rendel, amely most már minden gyártó esetében ugyanazt a tartalmat fedi, ugyanolyan formátumban, így megvalósulhat az univerzális információ-gyűjtő modul. Célunk egy ilyen eszköz tervezése és kivitelezése, mely FMS szabvány szerint működő CAN hálózatok adatait gyűjti, értelmezi és adott formátumban egy flottakövető rendszer GPRS kommunikációjának közreműködésével egy szerverállomásra küldi. Az itt -4-
ReD-CAN
Bevezető
eltárolt adatok a későbbiekben a felhasználói igények szerint Interneten keresztül jeleníthetők meg. Ez a dolgozat a fejlesztéshez eddig összegyűjtött irodalmat, algoritmusok bemutatását és az ez idáig elért eredményeket mutatja be.
-5-
ReD-CAN
Irodalomkutatás
Irodalomkutatás Flottakövető rendszerek Áttekintés A flottakövető rendszer lényege röviden: mozgó objektumok adatainak távmenedzselése. A szállítmányozás területén hatalmas jelentősége van annak, hogy egy adott szállító jármű mozgásának körülményeit, illetve a szállított áru állapotát nyomon követhessük. A flottakövető rendszerek elterjedése szoros összefüggésben áll a mobilkommunikációs és a műholdas földrajzi helymeghatározó (GPS) technológiák fejlődésével. Ezen két technológiára épülő rendszerek, csak a szolgáltatás minőségben és árában különböznek, de elvi megvalósításuk nagyon hasonló. Mindkét megvalósítás a következő alrendszerekre bontható:
Ábra 1. Flottakövető rendszer modellje
Mobil egység A mobil egység nevéből következik, hogy a megfigyelt, mozgó objektum rendszeréhez kapcsolódik. További két részre bontható: egyik, amely a kívánt adatokat gyűjti, és egy másik, amely ezeket tovább küldi a bázis állomásra. Két fajta rendszert különböztetünk meg: online, illetve offline. Az előbbinél az adatok bármikor lekérdezhetőek a mobil egységtől, amely folyamatos távoli megfigyelést tesz lehetővé. Offline rendszer esetében az adatok a mobil egységen kerülnek tárolásra és azokat csak a bázis állomáson lehet letölteni, elemezni. Adatgyűjtés Az adatok gyűjtése több hardver eszköz segítségével történhet, attól függően, hogy az adott objektum mely paramétereit szeretnénk figyelemmel követni. Ilyenek lehetnek például: GPS modul, mely a földrajzi pozíciót határozza meg, továbbá különböző hőmérsékletérzékelők (élelmiszerszállítás), nyomásérzékelők, stb. Helymeghatározás A csak mobil technológiát használó rendszerek az objektumon elhelyezett mobil GSM modul cellainformációit használják fel arra is, hogy meghatározzák a földrajzi pozíciót. A módszer megvalósítása olcsóbb, egyszerűbb, viszont földrajzilag pontatlan. Így azok az alkalmazások, ahol kulcsfontosságú szerepe van annak, hogy egy adott objektum helyét milyen pontossággal tudjuk meghatározni, ott a GPS nyújtotta lehetőségeket használják, azaz az objektum földrajzi helyét egy GPS modul segítségével határozzák meg. Ilyen feladat lehet például, ha pontos digitális térképen szeretnénk követni objektumunkat.
-6-
ReD-CAN
Irodalomkutatás
További adatok Az esetek többségében az objektum elhelyezkedése alapvetően nem elegendő információ. A különféle alkalmazási területek mind más és más információkat igényelnek egy ilyen rendszertől. Mivel a szállítmányozás területén a legelterjedtebb a flottakövető rendszerek használata, ezért a leggyakoribb igény a járművek műszaki állapotának megfigyelése. A járművekben megtalálható elektronikus berendezések képesek egymással kommunikálni egy erre a célra kifejlesztett CAN (Controller Area Network) buszrendszer segítségével. A flottakövető rendszer is egy eszköz, mely a buszrendszerre kapcsolódik és az összes berendezés adatait tovább tudja küldeni a bázis állomásra. Ez nemcsak lehetővé teszi a műszaki meghibásodások miatti balesetek – és nem utolsó sorban anyagi károk – elkerülését, de jelentős költségmegtakarítást is jelent egy járműparkot üzemeltető cég részére.
Bázis állomás Bázis állomás alatt egy – a mobil egység által küldött – adatcsomagokat fogadni képes hardvert és ezen adatok eltárolására, további feldolgozására alkalmas, számítógépekből álló hálózatot értünk. A rendszer adatbázisra épül, ahol a felhasználóazonosításnak nagy szerepe van, hiszen előfordulhat, hogy egy–egy erre a célra kialakított szerver több különböző cég járműveinek adatait is tartalmazhatja, illetve egy cégen belül több különböző beosztású dolgozók használják a rendszert.
Szoftver A rendszer adatainak megjelenítését munkaállomáson, vagy akár internetes webszerveren futtatható program végzi. Abban az esetben, ha az adatbázis és a szoftver fizikailag egy hálózatban található, úgy használhatunk helyi kliens programot. Ha az adatokat szeretnénk bárhonnan elérhetővé tenni, úgy internetes megjelenítést, böngészők által olvasható natív HTML kódot kell generálni. Fontos, hogy az alkalmazott megjelenítéstől függetlenül biztonságos, felhasználószintű adathozzáférést tegyen lehetővé rendszerünk.
Kommunikáció Online rendszerek esetén biztosítani kell a mobil egység és a bázis állomás folyamatos kapcsolatát. A kapcsolat folyamatossága eltérő az egyes rendszerekben, attól függően, hogy milyen mobil átvitelt alkalmaznak. Egyes flottakövető rendszerek SMS-alapú adattovábbítást valósítanak meg, azaz a mobil egységben gyűjtik az adatokat, majd mikor szükség van rá, SMS-ben küldik azt tovább, legtöbbször nem bázis állomásra, hanem egy a rendszertől külön álló mobiltelefonra. Másik módja az adattovábbításnak GSM hálózaton a vonalkapcsolt adatküldés, mely költséges és lassú módszernek bizonyult, mióta megjelentek a csomagkapcsolt GPRS szolgáltatások. A GPRS alkalmazásának előnye, hogy olcsó és gyors adatátvitelt tesz lehetővé, továbbá mivel a késleltetés elhanyagolható, segítségével valós idejű objektumkövetést lehet megvalósítani a nap 24 órájában.
Flottakövető rendszerek alkalmazása NavSky Nova A Secret Control GPS Kft. flottakövető rendszere a saját gyártású mobil egységükre épül. A gépjárműbe telepített Navsky Nova GPS alapú logisztikai és gépjárművédelmi rendszer mobilegysége beállításainak megfelelően naplózza, és GSM hálózaton továbbküldi a keletkező adatokat a szerverszámítógépeknek. A szerverszámítógépek a beérkező elsődleges adatokat eltárolják és feldolgozzák másodlagos, az ügyfél igényeinek megfelelő információkká (elektronikus menetlevél, kilométer elszámolás, stb.).
-7-
ReD-CAN
Irodalomkutatás
Ábra 2. NavSkyNova felhasználói felülete [Forrás 8. NavSky Nova] Az ügyfél (felhasználó) a neki alkalmas időpontban Internet hozzáférésén keresztül megtekinti a számára fontos információkat. Az Internet felületen keresztül módosíthatja a mobil egység beállításait igényeinek megfelelően, amit a rendszer a mobil egység számára a GSM hálózaton keresztül küld el. A rendszer demo változata ingyenesen kipróbálható: www.webbase.hu címen. [Forrás 8. NavSky Nova]
NavCenter A műholdas járműkövető rendszer segítségével a vállalat járműparkjának mozgása a cég telephelyén lévő bázisállomásról követhető nyomon. A járművekben elhelyezett GPS készülékek meghatározzák a jármű földrajzi koordinátáit (kb. 15 méteres pontossággal), sebességét és haladási irányszögét. Ezeket az adatokat egy beépített GSM modem elküldi a bázisállomásra, ahol a járművek pozíciója digitalizált térképen jelenik meg. Ezzel lehetőség nyílik arra, hogy akár utca-szintű térképen követhessük nyomon a járműflottát. Az adatátviteli költségek minimalizálására való törekvés miatt lehetőség van arra is, hogy a járműben elhelyezett GPS adatai (tehát a jármű által megtett utat leíró pontos adatok) eltárolódjanak és naponta csak egyszer, adatátviteli üzemmódban, kedvezményes időszakban kerüljenek továbbításra a bázisállomásra. Az így beérkező adatokból a szoftver kiszámítja a jármű által az adott időszakban megtett út hosszát, elkészíti a menetlevelet, valamit egy digitalizált térképen megjeleníti az útvonalat. Az adatbázisban tárolt adatok más szoftverek (Excel, Word stb.) számára is hozzáférhetők. A járműbe épített egység képes elektromos berendezések (riasztó, raktér ajtónyitás érzékelő stb.) állapotának figyelésére, és a bekövetkezett változáskor SMS-t küld a diszpécser szoftvernek. Egy elektromos berendezés távirányítással vezérelhető akár a diszpécser központból, akár egy hagyományos mobiltelefonról a járműnek kiküldött SMS-sel (motor leállítása lopás esetén, hűtőkompresszor bekapcsolása, stb.). Analóg bemenetén üzemanyag szintet vagy hőmérsékletet (hűtőkamionoknál) is tud mérni, illetve továbbítani a diszpécser központba. [Forrás 9. NavCenter]
-8-
ReD-CAN
Irodalomkutatás
Ábra 3. NavCenter felhasználói felülete [Forrás 9. NavCenter]
Cason HiROT A Cason Rt. által megvalósított flottakövető rendszer célja mozgó objektumok nagy felbontású, valós idejű megfigyelése. Az online rendszer megbízhatóságát a GPRS kommunikáció biztosítja. A földrajzi elhelyezkedés pontossága a korrigált GPS adatoknak köszönhetően három méter alatti.
Ábra 4. HiROT 418 [Forrás 7. Cason Rt.] A rendszer saját gyártású mobil egységre épül. A HiROT elnevezésű eszköz egy GPS és egy GPRS modulból tevődik össze, mindkettőt külön mikrokontroller vezérli. Az OEM GPS készülékből a műholdakról vett adatok a GPRS modulon keresztül jutnak el a cég telephelyén lévő Windows 2000 szerverre majd SQL adatbázisba. Az adatokat azután egy IIS szerver teszi közzé a weben. Internetes kapcsolat révén a szolgáltatás a világ bármely részéről elérhető, akár személyi számítógépről, akár PDA-ról, de a WAP-képes mobiltelefonok kijelzőin is nyomon követhetjük objektumainkat. A kommunikáció a mobil egység és a bázis állomás között kétirányú folyamatos adatkapcsolat, melynek köszönhetően a megfigyelt járművek a vállalati számítógépes hálózat részévé vállnak. Kritikus alkalmazásoknál lehetőség van két egymástól független GSM hálózat használatára, a redundancia biztosítására.
-9-
ReD-CAN
Irodalomkutatás
Ábra 5. HiROT szerverek kapcsolata [Forrás 7. Cason Rt.] A bázisállomás komponensei: 9 9 9 9 9
Cason HIROT kommunikációs szerveralkalmazás, amely folyamatos kapcsolatot tart a mobil egységekkel központi SQL szerver a nyilvántartási és mérési adatoknak GIS szerveralkalmazás, amely a térképszolgáltatásokat segíti Internet Információs Szerver biztosítja az internetes elérhetőséget a szerveralkalmazásokhoz a négy szerver egy vagy két ipari számítógépen fut
A Cason HiROT további szolgáltatásai: 9 9 9 9
„Fekete doboz” Vezető azonosítás Biztonságos távoli megállítás Azonnali riasztás a központban
„Fekete doboz” A mobilegység körülbelül 100.000 adatot gyűjt minden másodpercben, és eldönti, hogy ez változás az előzőekhez képest és ez alapján dönt arról, hogy felküldi az adatot központ felé. Egy másodperces felbontású adathalmaz áll rendelkezésünkre a baleset analizálásához. Míg a kommunikáció él addig az egység adatait továbbítja a központba. Ha kommunikáció megszakadt a baleset után, akkor az adatok közvetlenül kikérdezhetők az egységből. Az adatok megőrzése feszültség eltűnésekor is biztosított. Vezető azonosítás: lehetőség nyílik a vezető beazonosítására egy azonosító kártya segítségével. A vezető minden indítás előtt saját kártyájával kell, hogy azonosítsa magát. Biztonságos távoli megállítás: az egység rendelkezik két digitális kimenettel, amelyből egyik távoli leállításra használható. A minimális kockázat véget a mobil egység csak 60 másodpercen belül állítja le az autót. Azonnali riasztás a központban: a rövid késleltetési idő és az esemény alapú vezérlés következtében, a riasztási jel azonnal megjelenik a követő központba. 9 9 9 9
Gyorsulás 30 km/h felett van (baleset) A jármű leállt és a riasztó bekapcsolódott (lopás) Ajtónyitás, riasztó bekapcsolódás Azonosítatlan vezető, stb.
- 10 -
ReD-CAN
Irodalomkutatás
Ábra 6. HiROT kliens felülete [Forrás 7. Cason Rt.]
- 11 -
ReD-CAN
Irodalomkutatás
Felhasznált technológiák GPS A GPS (Global Positioning System) egy az USA védelmi minisztériuma megbízására kifejlesztett, általa működtetett globális hálózat, melynek segítségével elméletileg a Föld bármely pontján bármikor meghatározhatjuk pozíciónkat, megközelítőleg 5-10 méteres pontossággal. Gyakorlatilag némi korlátai ennek a rendszernek is vannak, mivel mindig nyílt rálátásra van szüksége az égboltra, azaz zárt térben, magas épületek között, esetleg természeti akadályok miatt előfordulhat, hogy a pontos helymeghatározáshoz nem lát elegendő számú műholdat a vevőkészülék. A GPS rendszer három nagyobb egységre osztható: a műholdak, a földi rendszerek illetve a vevőkészülékek.
Ábra 7. Egy GPS műhold távlati képe [Forrás 5. Garmin]
A műholdak A GPS rendszer 24 NAVSTAR típusú műholdat egyesít, melyek hat, az Egyenlítő síkjával 55°-os szöget bezáró, 20 kilométerrel a Föld felszíne felett húzódó körpályán helyezkednek el.
- 12 -
ReD-CAN
Irodalomkutatás
Ábra 8. A műholdak pályáinak elhelyezkedése [Forrás 5. Garmin]
A földi rendszerek A földi rendszerek képezik a rendszer lelkét, ezeknek az állomásoknak a segítségével követik figyelemmel a műholdak mozgását, állapotát, egyeztetik a műholdakon található órákat, frissítik a pályaadataikat, valamint egyéb, a pontos helymeghatározáshoz elengedhetetlen információkat továbbítanak a műholdak felé. A földi rendszer 5 monitor állomásból, 3 adatátviteli állomásból és egy kontroll állomásból áll. A 9. ábrán az állomások elhelyezkedése látható. Master Control Station (kontroll állomás) A kontroll állomás feladata, hogy kiszámítja a pályakorrekciós, illetve időkorrekciós adatokat az összes műhold részére a monitorállomásoktól begyűjtött adatok alapján, és eljuttatja azokat az antenna állomásokhoz, melyek közlik ezeket a műholdakkal.
Ábra 9. A földi állomások elhelyezkedése [Forrás 5. Garmin]
- 13 -
ReD-CAN
Irodalomkutatás
Ábra 10. Monitor állomás – Hawaii [Forrás 5. Garmin] Monitor Station (monitor állomás) A monitor állomások feladata, hogy figyeljék a műholdak pontos magasságát, sebességét, fizikai állapotát. Ezeket az adatokat feldolgozásra elküldik a kontroll állomásra, majd a visszaérkező korrekciós adatokat a műholdra, hogy azok továbbíthassák a vevőkészülékek felé. Egy időben 11 műholdat vizsgálhatnak és ezeket a vizsgálatokat naponta kétszer végzik el az állomások, mikor elhaladnak felettük a műholdak. Ground Antennas (antenna állomások) Az antenna állomások feladata, hogy nyomon kövessék a műholdakat horizonttól horizontig, illetve, hogy továbbítsák a fent már említett korrekciós adatokat a műholdakra.
A vevőkészülékek A vevőkészülékeknek manapság már megszámlálhatatlanul sok fajtája van, tekintve az alkalmazási területek sokszínűségét. Léteznek külön turistáknak szánt GPS-ek, hajózást segítő, repülőgépeken alkalmazható, autóba szerelhető, nagypontosságú katonai, kézi illetve fix (pl. állványzattal szerelt) kiszerelésű GPS-ek. Egy vevőkészülék általános felépítése Léteznek úgynevezett OEM vevőkészülékek, ezek tokozás nélkül kaphatóak, nincs kijelzőjük, nem tartalmaznak semmilyen térképszoftvert, vagy hasonló programot, csak a helymeghatározáshoz szükséges szoftverek kaptak rajtuk helyet. Az ilyen vevők felépítése a következő:
Ábra 11. Garmin túra vevőkészülék [Forrás 5. Garmin]
- 14 -
ReD-CAN 9 9 9 9 9
Irodalomkutatás
antenna előerősítő rádiófrekvenciás egység jelkövető egység vezérlő- és logikai egység
Az ilyen OEM vevőkészülékek képességei kimerülnek az önmaguk koordinátáinak pontos meghatározásában, melyet egy gyártó-specifikus porton keresztül, legtöbbször a PC soros portjára továbbítanak, itt majd további elemzéseket végezhetünk ezek után, például térképre illeszthetjük az adott koordinátákat. A komolyabb vevőkészülékek már legtöbbször tartalmaznak valamilyen térképszoftvert, amelyet beépített LCD kijelzőjükön jelenítenek meg. Ezek a legtöbb esetben csak a földrajzi szélességi és hosszúsági fokoknak megfelelő rácshálózatot jelenítik meg, esetleg iránytűvel együtt, viszont a professzionális GPS vevőkben teljes értékű térképszoftverek kapnak helyet.
A GPS Rendszer működése A trilateráció Amint a 12. ábra is mutatja, a műholdaktól mért távolságok egy-egy gömbfelületet határoznak meg, ezeknek a gömbfelületeknek a metszéspontjában helyezkedik el a vevőkészülék. A vevő a pontos helyzetét négy műhold segítségével tudja meghatározni. Három műhold segítségével még két lehetséges pontot kap a rendszer, de ezek közül bizonyos tényezők, például a Föld felszínéhez képest vett elhelyezkedés figyelembe vételével (mivel a mért pont például nem lehet a Föld felszíne alatt) már meg lehet határozni a két mért pont közül a valós pozíciónkat, azonban minden kétséget kizáróan csak négy műhold segítségével határozhatjuk meg a helyzetet. A távolságmérés A műholdtól való távolság mérése a műholdról érkező rádiójelek segítségével történik. A vevőkészülék megállapítja, hogy az adott kódszakasz mikor hagyta el a műholdat, így az adás és a vétel időkülönbségéből, szorozva a fénysebességgel, megkapjuk a távolságot. Minden GPS műhold két frekvencián ad L1 1575,42 MHz és L2 1227,60 MHz-n. Az L1-es szignál két fajta kóddal modulált, P-kóddal és C/A kóddal. Az ún. P-kód (P, Precision) katonai alkalmazású kód. Az ún. C/A kód ezzel szemben szabad hozzáférésű. Az L2-es szignál csak P-kóddal modulált. Mivel minden GPS műhold azonos frekvencián ad, szükség van az egyedi kód felismerésére. Így minden műhold a saját ún. PRN (PRN, PseudoRandom Number) azonosító-kódja alapján azonosítható.
Ábra 12. Műholdak távolsága [Forrás 5. Garmin]
- 15 -
ReD-CAN
Irodalomkutatás
Ábra 13. A műholdak által sugárzott jel felépítése [Forrás 6. Mindentudás Egyeteme] Az időmérés A pontos időmérés érdekében nanosecundum-os pontosságú atomórák működnek a műholdakon. A földi vevők esetleges pontatlanságát negyedik műhold segítségével küszöbölik ki. A műhold helyzetének meghatározása A műholdak a saját helyzetükkel kapcsolatos korrekciós állomásoktól kapják, és ezeket továbbítják a vevőkészülékek felé.
adatokat
a
földi
Korrekciók elvégzése Időmérés hibája: ha a vevőkészülék órája nem pontosan szinkronban jár a műholdak órájával, akkor a mért időeltérés nem egyezik meg a jel futási idejével, tehát rossz pozíciót kapunk vissza. Ennek kiküszöbölésére egy egyszerű geometriai műveletet végez a vevőkészülék. A hibás pozícióadatok egy háromszög csúcspontjait adják, és ennek a háromszögnek a súlypontjában helyezkedik el a valódi pozíció, ezért ennek a pontnak a meghatározása után, a többi mérést is korrigálhatjuk ezzel az eltéréssel, és így a későbbiekben már pontos pozíciót kaphatunk. A légkör okozta hibák: a műhold által sugárzott jel áthalad az ionoszférán, majd a troposzférán mire a vevőkészülékhez ér. Mivel ezeknek a közegeknek különböznek a jellemzőik, ezért a jel nem egyenes úton halad a műholdtól a vevőig, hanem töréseken megy keresztül. Ezekkel viszont számolhatunk, ugyanis a légkör adatai ismertek. Ezekből az adatokból a kontroll állomás korrekciós adatokat számol, majd az antennaállomások segítségével ezek az információk eljutnak a műholdra, majd a vevőkészülékbe, így a légkör által okozott hibák is kiküszöbölhetőek. A visszaverődés okozta hiba: a jel legtöbbször nem csak egy úton ér el a vevőkészülékbe, hanem több úton is, visszaverődve a környező objektumokról. Ezt nevezik többutas terjedésnek. Ez a hiba egyszerűen orvosolható, mivel a vevőkészüléknek csak ki kell választania a leghamarabb beérkezett jelet, és az lesz a valós jel, ugyanis a visszavert jeleknek hosszabb utat kell megtenniük, így később érik el a vevőkészüléket.
- 16 -
ReD-CAN
Irodalomkutatás
Ábra 14. A jelterjedés hibái [Forrás 5. Garmin] A differenciális GPS-ek működése A differenciális GPS-ek a helymeghatározás sokkal pontosabb módját kínálják, ugyanis ennek a rendszernek a pontossága megközelítőleg centiméteres pontosságú. A differenciális GPS két GPS vevőkészülék mérésén alapszik. Az egyik a felhasználónál levő készülék, a másik egy bázis, vagy referencia műszer. Mindkét vevő egyszerre ugyanannak a műholdnak a jelét veszi, és ez alapján meghatározza a saját pozícióját. A referenciaállomás pontos koordinátái ismertek, ezáltal a mért és az ismert adatok különbsége meghatározza a mérés hibáját, ezzel a különbséggel korrigálva a vevőkészülék által adott értéket, megkapjuk a pontos koordinátáinkat.
Ábra 15. A differenciális GPS működése [Forrás 5. Garmin]
- 17 -
ReD-CAN
Irodalomkutatás
GSM A manapság legelterjedtebb telekommunikációs technológia a GSM (Global System for Mobile Communications). A GSM hálózatokban az adatátvitel lehetőségeinek abszolút korlátja az, hogy időosztással működnek. Egy bázisállomás körzetében bejelentkezett mobilkészülékek mindegyike megkapja az egyenlő – nyolc – részre osztott másodperc egyik, az első, a második és így tovább az utolsó, a nyolcadik időszeletét, és azon belül ad vagy vesz. Ma Magyarországon a szolgáltatók ebben a rendszerben fizikailag 9600 bitet tudnak másodpercenként átküldeni, ami legfeljebb drótlevelezésre jó, ott is inkább csak rövid levelekkel. Igaz ez akkor is, ha logikailag ennek többszöröse az adatátviteli sebesség, hiszen az adatokat átküldés előtt lehet tömöríteni, sűríteni, majd a célállomáson kicsomagolni. A szabványos tömörítő eljárást, az MNP5-öt használni lehet a mobilmodemeknél is. A kutatók, fejlesztők, gyártók nagyszabású látomásai azonban ennél többet követelnek. Kézenfekvő megoldás a korlát tágítására az időszeletek összevonása. A bázisállomás kezelheti rugalmasan a kiosztást, ha van üres időszelete - kevesebb a bejelentkezett készülékek száma, mint amennyi lehetne -, azt odaadhatja annak, amelyik adatot küld vagy fogad. Ezt valósítja meg a HSCSD, avagy High Speed Circuit Switched Data (nagy sebességű áramkörkapcsolt adatok), amelynek maximális fizikai teljesítménye 57 600 bit/másodperc. Igaz, ehhez már mind a nyolc időszeletet el kell hogy foglalja egyetlen kapcsolat. Egy másik lehetőség az adatkódolás megváltoztatása abban a jelsorozatban, ami a mobilkészüléknek jutó időszeletben eljut tőle a bázisállomásig vagy onnan hozzá. Ezzel egy időszeletben már 14 400 bit/másodperc adatátviteli sebesség érhető el. Hasonlóképpen a szokásos modemekhez, faxokhoz, ez az új kódolás is bevezethető úgy, hogy a bázisállomás előbb teszteli, vajon tudja-e a készülék szoftvere ezt a sebességet, és ha nem, akkor a ma is használatos 9600 bit/másodpercesre áll be. [Forrás 3. TeleComputer]
GPRS A sebesség növelésében – egyes kutatók szerint – egy következő generációs mobiltechnológia a GPRS (General Packet Radio Service) hozott forradalmi újítást. Szakítva a vonalkapcsolt átvitellel a csomagkapcsolás elvét használja. A csomagkapcsolás lényege, hogy a két pont között nem épül fel állandó kapcsolat, mint a vonalkapcsolás esetében, hanem az információ feladója kisméretű csomagokra darabolja fel az átküldendő adatot, minden csomagot ellát a címzettet tartalmazó fejléccel, majd a csomagokat útnak indítja. Az egyes csomagok a fejléc alapján jutnak el a címzetthez, nem feltétlenül azonos útvonalon. A módszert a hatvanas években dolgozták ki, és csomagkapcsolással működik az X. 25 adathálózat, de az Internet hálózat is. A GPRS lényege, hogy a meglévő hálózatot oly módon egészíti ki a szolgáltató, hogy a megfelelő (GPRS képes) készülék segítségével csomagkapcsolt módon is lehessen adatokat átvinni a beszédcsatornákon. A módszer előnye, hogy az információ továbbításához nem kell előzetesen felépíteni egy kapcsolatot a küldő és a címzett között, csak el kell indítani a csomagot a hálózatban. Ettől mondják joggal, hogy a felhasználó úgy érezheti, mindig fent van az Interneten (angolul: always on). A csomag ugyanazt a hálózatot használja, mint a vonalkapcsolt adatátvitel esetében, tehát önmagában a csomagkapcsolástól – a reklámok ellenére – nem lesz gyorsabb az adatátvitel. A GPRS attól képes nagyobb sebességgel adatokat átvinni, hogy több időrést is használhat egyszerre. Ez azonban nincs összefüggésben a csomagkapcsolással, erre kiváló példa a HSCSD. A GPRS adatátvitel nagyobb sávszélessége tehát abból adódik, hogy a készülék több szabad időrést párhuzamosan használ az éppen aktuális adatcsomag elküldéséhez vagy fogadásához. A helyzet azonban a részleteket tekintve összetettebb. A GSM rendszerben egy adott frekvenciájú rádiócsatorna nyolc időrésre oszlik, minden egyes időrés egy beszédcsatornához tartozik. Ennek megfelelően egy rádiócsatornán nyolc beszélgetés folyhat egy időben. A GPRS és persze a HSCSD is ezekből az időrésekből tud többet - 18 -
ReD-CAN
Irodalomkutatás
összekapcsolni. Ehhez azonban az szükséges, hogy legyenek szabad időrések a rádiócsatornán. Gyakran előfordul az is, hogy egy adott területen több rádiócsatorna is rendelkezésre áll, s ekkor – pl. három rádiócsatorna esetén – 24 időrés érhető el a készülékkel. Azonban hiába van mindegyik nyolcas csoportban két szabad időrés, ezt a hat időrést nem tudja összekapcsolni a rendszer, mert csak az egy rádiócsatornán belüli szabad időrések összekapcsolhatók. A GPRS elvileg nyolc időrés összekapcsolását teszi lehetővé. A rendszerben azonban lehet bizonyos korlátozásokat tenni, sőt a használt készülék is erősen csökkentheti ezt az elvi maximumot. Ha azonban mind a hálózat, mind a készülék megengedi a nyolc időrés összekapcsolását, akkor is erősen ingadozhat az adatátvitel sebessége a forgalom függvényében. A GPRS átvitelben ugyanis nincs lefoglalt időrés. Minden egyes csomag feladásakor akkora sávszélesség áll a rendelkezésre, amennyit a forgalom éppen szabadon hagy. Lehet tehát, hogy az adatátvitel 80 kbit/s-mal indul el, de néhány beszédkapcsolat felépülése miatt csak 20 kbit/s körüli sebességgel tud folytatódni. Szemben tehát a vonalkapcsolt adatátvitellel, ahol a lefoglalt sávszélesség a bontásig rendelkezésre áll (pl. a HSCSD esetén), a GPRS esetében az átviteli sebesség erősen ingadozhat. A most megjelenő GPRS készülékek esetében fontos jellemző, hogy a készülék melyik irányban hány időrést használ. A jellemző az egy időrés használata a szerver felé, három vagy négy időrés használata a készülék felé. Ez azt jelenti, hogy a készülékről küldött adataink 10 kbit/s körüli sebességgel tudnak eljutni az Internet szolgáltatóig, míg a letöltés 30–45 kbit/s-os sebességgel folyhat. A GPRS készülékek aszerint is különbözőek, hogy egyszerre tudnak-e GSM beszédet és GPRS adatforgalmat kezelni (A osztályú készülék), vagy csak felváltva (B osztályú készülék), illetve csak GPRS-t tudnak kezelni (C osztályú készülék). Jelenleg nincs olyan készülék a piacon, amelyik alkalmas lenne a két forgalom szimultán kezelésére. [Forrás 4. e-Times]
- 19 -
ReD-CAN
Irodalomkutatás
CAN A járműipari elektronika növekedése egyrészt a felhasználó biztonsági és kényelmi igényeinek, másrészt a környezetvédelmi megfontolásoknak (káros anyag kibocsátás és üzemanyag fogyasztás csökkentése) köszönhető. Ilyen vezérlőeszközök lehetnek például a vezérműben, a sebességváltóban, a karburátor fojtószelepénél, a blokkolásgátló rendszerben (ABS) és a gyorsítási csúszásgátlóban (ASC). Ezen rendszerek funkcióinak bonyolultsága elkerülhetetlenné teszi az adatcserét közöttük. A hagyományos rendszerekben az adatcsere dedikált adatvonalakon keresztül történik, de ezt a vezérlési funkciók bonyolultabbá válásával egyre nehezebb és drágább megvalósítani. A bonyolult vezérlőrendszerekben az összeköttetések száma tovább már nem növelhető. Egyre több olyan rendszert fejlesztenek ki, amelyek több vezérlőeszköz együttműködését igénylik. Ilyen például az ASC, ahol a motor időzítése és a karburátor vezérlése működik együtt, hogy a meghajtott kerék megcsúszásakor csökkentsék a forgatónyomatékot. Egy másik példa az elektronikus sebességváltó vezérlés, ahol a sebességváltás a gyújtás precíz beállításával könnyíthető. Ha figyelembe vesszük a járművek optimalizálására megcélzott további fejlesztéseket, szükségessé válik a vezérlőeszközök hagyományos összekötésének lecserélése. Ez csak a rendszer elemeinek egy soros buszrendszert használó hálózatával lehetséges. Ezért fejlesztette ki a Bosch a CAN-t (Controller Area Network), amit szabványosítottak (ISO 11898) és sok félvezető gyártó kínál hozzá eszközöket. A CAN használatakor az állomások (vezérlők, érzékelők és beavatkozók) soros buszon keresztül vannak összekapcsolva. A busz egy szimmetrikus vagy aszimmetrikus kétvezetékes áramkör, ami lehet árnyékolt vagy árnyékolatlan is. A fizikai átvitel elektromos paramétereit szintén az ISO 11898 szabvány specifikálja. A CAN protokoll, mely az ISO/OSI hivatkozási modell adatkapcsolati rétegének felel meg, továbbá eleget tesz a járműipari alkalmazások valósidejű követelményeinek. A hálózat detektálja és kijavítja az elektromágneses zajokból eredő átviteli hibákat. Az egyszerű konfigurálás és a központi hibaellenőrzés szintén a hálózat előnyös tulajdonságai. A CAN rendszerek járművekben való használatának célja, hogy az állomások központi vezérlő számítógép használata nélkül tudjanak kommunikálni. [Forrás 2. BME]
A fizikai szint Megvalósítása roppant egyszerű. A kétvezetékes, mindkét végén 120 Ohm-mal lezárt buszra párhuzamosan kapcsolódnak az eszközök. A CAN-ben minden eszköz olvas minden üzenetet. Az eszközök interfésze szimmetrikus, tehát nincs „föld” ill. „adat” vezeték. Az „1” jelnek a busz feszültség alatti állapota felel meg, „0” adásakor az eszköz szinte rövidre zárja a buszt. Így a „0” jel mindig felülírja az „1”-et. CAN szóhasználatban a „0” a domináns, „1” a receszív állapot. [Forrás 1. PID]
Ábra 16. CAN fizikai szint [Forrás 1. PID]
- 20 -
ReD-CAN
Irodalomkutatás
Ábra 17. CAN kapcsolat az ISO 11898 szabvány szerint [Forrás 2. BME]
Adatcsere Az adatátvitelkor nincs megcímzett állomás, ehelyett az üzenet tartalmát egy a hálózatban egyedi azonosító jellemzi. Az azonosító nemcsak a tartalmat definiálja, hanem az üzenet prioritását is. Erre a busz allokáció során van szükség, amikor több állomás verseng a hozzáférés jogáért. Ha egy adott állomás CPU-ja egy vagy több állomásnak üzenetet akar küldeni, az átviendő adatokat és azonosítókat a hozzárendelt CAN chipnek továbbítja („Make ready”). Ennyi a CPU összes feladata. Az üzenet összeállítása és elküldése a CAN chip feladata. Amint a CAN chip megszerzi a buszhozzáférés jogát („Send Message”), az összes többi állomás veszi az üzenetét („Receive Message”). A CAN hálózat minden állomása, mely helyesen vette az üzenetet, végrehajt egy elfogadási tesztet, hogy eldöntse, a vett adat neki szól-e („Select”). Ha igen, feldolgozza („Accept”), különben eldobja. A tartalomorientált címzési sémának köszönhetően a rendszer és a konfiguráció nagyfokú rugalmassága érhető el. Nagyon egyszerűen lehet új állomást felvenni a hálózatba a többi állomás szoftverének vagy hardverének módosítása nélkül, ha az új állomások csak vevők. Mivel az adatátviteli protokoll nem használ fizikai címeket, broadcast és multicast üzenetek is küldhetők, és elosztott folyamatok is szinkronizálhatók: a több vezérlő által is igényelt mérési információt át lehet küldeni a hálózaton, így nincs szükség arra, hogy minden vezérlőnek saját érzékelője legyen.
- 21 -
ReD-CAN
Irodalomkutatás
Ábra 18. Broadcast átvitel és az elfogadási szűrés a CAN állomásoknál [Forrás 2. BME] A nem destruktív bitenkénti döntés A valósidejű feldolgozás adatait nagyon gyorsan kell átvinni. Ez nemcsak egy 1Mbps adatátviteli sebességű fizikai kapcsolatot igényel, hanem gyors busz allokációt is, ha több állomás egyszerre szeretne üzenetet átvinni. A valósidejű feldolgozás adatainak sürgőssége nagyon különböző lehet: egy gyorsan változó mennyiséget (pl. a motor fogyasztása) sokkal gyakrabban kell átvinni, tehát kisebb késleltetéssel más lassan változó mennyiségekhez (pl. a motor hőmérséklete) képest. Az átviendő üzenet prioritását az azonosító határozza meg, melyhez az üzenet tartozik. A prioritási szinteket a rendszer tervezésekor bináris számokban kódolják, ez tehát nem változtatható dinamikusan. A legkisebb bináris szám jelenti a legmagasabb prioritást. A buszhozzáférési konfliktusok az azonosítókon alapuló bitenkénti döntés módszerével oldhatók fel, melyeket minden állomás figyel. A „huzalozott ÉS kapcsolatnak” megfelelően, amikor a domináns állítás (logikai 0) felülírja a receszívet (logikai 1), a buszhozzáférési versenyt is azok az állomások veszítik el, melyek átvitele receszív, megfigyelése, pedig domináns. Az összes „vesztes” a legmagasabb prioritású üzenet vevőjévé válik, és nem kísérli meg az átvitelt mindaddig, míg a busz ismét szabad nem lesz.
Ábra 19. A nem destruktív bitenkénti döntés alapelve [Forrás 2. BME]
- 22 -
ReD-CAN
Irodalomkutatás
Az üzenetek keretformátumai A CAN protokoll 2 keretformát támogat, melyek között az egyetlen lényeges különbség az azonosító (ID) hossza. A standard formájú üzenetben ez 11 bit, a kiterjesztett formátumban pedig 29 bit. A keretek 7 további mezőt tartalmaznak. A standard formátumú üzenet a „start of frame” bittel kezdődik, ezt követi az „arbitration field”, ami az azonosítót tartalmazza, és a „RTR” (remote transmission request) bit, ami azt jelzi, hogy az adott keret adat keret vagy adatot nem tartalmazó kérés keret-e. A „control field” az IDE (identifier extension) bitet tartalmazza, mely a standard és kiterjesztett formátum közül választ, egy későbbi felhasználásra fenntartott bitet és – az utolsó négy bitben – az adatmezőben levő adatbyte-ok számát. A „data field” 0–8 byte hosszú lehet és a „CRC field” követi, amit a keret a bithibák detektálására, biztonsági ellenőrzésre használ. Az „ACK field” része az ACK slot (1 bit) és az ACK delimiter (1 receszív bit). Az ACK slotban levő bit receszív bitként kerül elküldésre, és domináns bittel azok a vevők írják felül, akik helyesen vették az adatot (pozitív nyugta). A korrekt üzeneteket a vevők az elfogadási teszttől függetlenül nyugtázzák. Az üzenet végét az „end of frame” mező jelzi. Az „Intermission” az egymást követő üzenetek közti minimális bitidőt adja meg. Ha egyik állomás sem jelentkezik hozzáférési igénnyel, a busz idle állapotban marad („bus idle”).
Ábra 20. Az üzenet keret standard formátuma (2.0A CAN specifikáció) [Forrás 2. BME] Hibadetektálás és kijelzés Más buszrendszerektől eltérően a CAN protokoll nem használ nyugtázó üzeneteket, hanem jelzi az előforduló hibákat. A CAN protokoll három mechanizmust implementál hibadetektálásra az üzenetek szintjén: Cyclic Redundancy Check (CRC) A CRC a keretben levő információt biztosítja redundáns ellenőrző bitek hozzáadásával az átvitel végén. A vevő ezeket a biteket újra kiszámolja a vett adatok alapján, és ellenőrzi, hogy megegyeznek-e. Ha nem egyeznek: CRC hiba lép fel. Keret ellenőrzés Ez a mechanizmus az átvitt keret struktúráját ellenőrzi a mezők fix formátumának ismeretében. Az esetleges hibát „formátum hibának” nevezzük. ACK hibák A vett keretet minden résztvevő pozitív nyugtán keresztül nyugtázza. Ha az adó nem kap visszajelzést (ACK hiba), ez azt jelentheti, hogy olyan átviteli hiba lépett fel, amit csak a vevők detektálnak, az ACK mező meghibásodott, vagy nincsenek vevők. A CAN protokoll implementálja a bit szintű hibadetektálás két mechanizmusát is: Monitorozás Az adó fél hibadetektálási képességének alapja a busz jelzések monitorozása: minden adóállomás egyúttal monitorozza is a buszt, ezért érzékeli az elküldött és a vett bitek különbözőségét. Ez a globális és az adón belüli lokális hibák megbízható észlelését teszi lehetővé.
- 23 -
ReD-CAN
Irodalomkutatás
Bitbeszúrás A bitek kódolásának ellenőrzése bit szinten történik. Az NRZ (non-return-to-zero) kódolás használatával garantálható a bitek kódolásának hatékonysága. A szinkronizációs élek bitbeszúrással generálódnak, ami azt jelenti, hogy 5 azonos bit után az adó 6.-nak egy komplementer bitet szúr be, amit a vevő eltávolít. Az ellenőrzés a beszúrási szabálynak megfelelően történik. Ha legalább 1 állomás hibát detektál a fenti mechanizmusokkal, az aktuális átvitelt megszakítja egy „error flag” elküldésével. Ezzel elkerülhető, hogy más állomás esetleg elfogadja az üzenetet, és biztosítható az adatok konzisztenciája az egész hálózaton belül. Miután a hibás üzenet átvitele megszakadt, az adó automatikusan újra megkísérli az átvitelt (automatikus ismétléskérés). Ekkor ismét versengés támadhat a buszhozzáférés jogáért. Szabályként elfogadhatjuk, hogy az újraküldés a hiba detektálását követő max. 23 biten belül megkezdődik. Speciális esetekben a rendszer feléledési ideje 31 bitidő. Bármennyire is hatékony ez az eljárás, egy meghibásodott állomás az összes üzenet átvitelét megszakíthatja, blokkolva az egész rendszert, ha nincs önellenőrzés. A CAN protokoll ezért tartalmaz egy mechanizmust a szórványosan előforduló és az állandó hibák megkülönböztetésére, és a hibás állomások beazonosítására. Ez az állomások hibáinak statisztikai kimutatásából indul ki, kiegészítve az állomások saját hibáit felismerő mechanizmussal és egy olyan működési móddal, amikor a CAN hálózat többi részére nem gyakorol káros befolyást. Ezzel az állomás odáig is elmehet, hogy lekapcsolja magát a hálózatról. A CAN protokoll adatainak megbízhatósága A járműiparban használt automatizálási rendszerek igen nagy követelményeket támasztanak az adatátvitel megbízhatóságával szemben. A jármű teljes élettartama alatt nem kerülhet veszélybe a vezető az adatátvitel hibája miatt. A célt elérjük, ha az adatok megbízhatósága elég nagy, vagy a megmaradó hibavalószínűség elég kicsi. Buszrendszer esetén az adat megbízhatósága alatt az átviteli hibák felismerésének lehetőségét értjük. A megmaradó hibavalószínűség annak a valószínűsége, hogy az átviteli hiba detektálatlan marad. Ennek olyan kicsinek kell lennie, hogy a rendszer élettartama alatt várhatóan ne legyen ilyen esemény. A megmaradó hibavalószínűség kiszámításához fel kell mérni a potenciális hibalehetőségeket és az átviteli utat egy modellben kell leírni. Ha megállapítjuk a megmaradó hibavalószínűség bithiba valószínűségtől való függését 80-90 bit hosszú üzenetekre, akkor pl. egy 5-10 állomással rendelkező rendszer és 1/1000-es
Ábra 21. A megmaradó hibavalószínűség a bithiba valószínűség függvényében [Forrás 2. BME] - 24 -
ReD-CAN
Irodalomkutatás
hibavalószínűség (1 hiba jut 1000 üzenetre) esetén, a maximális bithiba valószínűség kb. 0.02, aminek 10-13 megmaradó hibavalószínűség felel meg. Erre alapozva adott CAN hálózat esetén kiszámíthatjuk a detektálhatatlan üzenetek maximális számát. Például ha egy CAN hálózat Mbps-os adatátviteli sebességgel működik a busz kapacitásának átlagosan 50%-os kihasználtsága mellett, 4000 órás teljes élettartamot és 80 bites átlagos üzenethosszt véve az összes üzenet száma 9*1010-re adódik. Ezért a detektálatlan átviteli hibák statisztikai száma legfeljebb 10-2. Másképpen fogalmazva: 8 órás napi működtetést alapul véve az év 365 napján működő rendszerben, ha a hibavalószínűség 0.7, minden ezer évben 1 detektálatlan hiba fordul elő (statisztikai átlag). [Forrás 2. BME]
Kiterjesztett CAN üzenetformátum A SAE „Truck and Bus” albizottsága szabványosította a jeleket, üzeneteket és a különböző adatátviteli sebességek melletti átviteli protokollokat. Nyilvánvalóvá vált, hogy az ilyen jellegű szabványosítást könnyebb megvalósítani, ha az azonosítási mező hosszabb. Ezért a CAN protokollt kiterjesztették a 29 bites azonosító mező bevezetésével. Ez egyrészt a már létező 11 bites azonosítót (alap ID), másrészt a 18 bites bővítményt tartalmazza. Így a CAN protokoll két üzenetformátumot támogat: a StandardCAN-t (2.0A verzió) és az ExtendedCAN-t (2.0B verzió). Mivel együttesen használják ugyanazt a buszt, meghatározták, hogy melyiknek magasabb a prioritása abban az esetben, amikor különböző formátumú, de azonos alap azonosítójú üzenetek ütköznek. A standard formátumú üzenet prioritása mindig nagyobb, mint a kiterjesztett formátumú üzeneté. A kiterjesztett formátumú üzeneteket támogató CAN vezérlők standard formátumú üzenetek forgalmazására is képesek. Ha olyan CAN vezérlőt is használunk, amelyik csak a standard formátumot támogatja (2.0A verzió), csak a standard üzenetet használhatjuk az egész hálózatban. A kiterjesztett formátumú üzenet ebben az esetben félreérthető lenne. Vannak azonban olyan CAN vezérlők is, melyek annak ellenére, hogy csak a standard formátumot támogatják, felismerik a kiterjesztett formátumú üzeneteket, és figyelmen kívül hagyják azokat (2.0B passzív verzió). A standard és kiterjesztett formátumú üzenetet az IDE bit (Identifier Extension Bit) különbözteti meg, mely standard formátumú üzenet esetén dominánsan, kiterjesztett formátum esetén, pedig receszíven kerül átvitelre. Az RTR bit attól függően domináns vagy receszív, hogy adat átvitelére vagy egy állomástól kért speciális üzenet beolvasására használjuk. A standard formátum RTR bitjének helyén az SRR (substitute remote request) bit kerül átvitelre a kiterjesztett formátumú keretek esetén. Az SRR bit mindig receszív, biztosítandó, hogy azonos alap azonosítók esetén a standard formátumú keretnek legyen magasabb a prioritása a busz allokációs folyamatban. A standard formátumtól eltérően a kiterjesztett formátumban az IDE bitet követi a 18 bites azonosító bővítmény, az RTR bit és a reserved bit (r1). Az összes többi mező azonos a standard formátuméval.
Ábra 22. Az üzenet keret kiterjesztett formátuma (2.0B CAN specifikáció)
- 25 -
ReD-CAN
Irodalomkutatás
FMS A CAN buszt elég széles körben alkalmazzák, legelterjedtebb felhasználása azonban az automatizálás és a gépjárműipar területén figyelhető meg. A járművekben való alkalmazása során bizonyos területeken (pl. szállítmányozás) felmerült az igény a szabványosításra, vagyis hogy az egyes gyártók ugyanolyan CAN implementációt valósítsanak meg járműveikben. A gyártók álláspontja szerint veszélyes lenne a CAN buszaikon áramló CAN üzenetek formátumának és jelentésének publikálása, hiszen akkor az általuk alkalmazott technikai megoldások egyszerűen monitorozhatóak lennének a CAN buszra való csatlakozással. Ez nem szerencsés abban a helyzetben, amikor a konkurens vállalatok fej-fej mellett újabb és újabb technológiákat dolgoznak ki, nem kevés befektetéssel. A szállítmányozás (teherforgalom) területén a gyártók mégis megegyezésre jutottak. Elhatározták, hogy bizonyos előre definiált szabvány szerint elérhetővé tesznek olyan adatokat, amelyek a logisztikai információs rendszerek számára igen hasznosak lehetnek. 2002-ben ebből születtet a Fleet Management Systems (FMS) szabvány, amely kamionokat gyártó világvállalatok által kidolgozott és elfogadott CAN adaptáció. A DaimlerChrysler, MAN, Scania, DAF Trucks, IVECO, Volvo Trucks and Renault Trucks gyártók megállapodtak abban, hogy bizonyos számú, meghatározott adatot ugyanabban a formátumban hordozzanak járműveik CAN busza. Ilyen adatok például a motor fordulatszáma, hőmérséklete, a jármű sebessége, üzemanyaggal kapcsolatos adatok, a vezető és vezetési szokásaira vonatkozó egyéb adatok (lásd az FMS mellékletben). A szabvány részletesen rögzíti az egyes adat üzenetének azonosítóját, az adatok az üzenet kereten belüli elhelyezkedését, a mértékegységet és az üzenet frissítésének gyakoriságát is. Az előírás szerint azok a gyártók, amelyek ezt aláírták, kötelesek megvalósítani a szabvány által rögzített adatokat, azonban jó néhányan ezen felül is publikálnak CAN üzenet formátumot. Az FMS létrejöttének jelentőségét leginkább egy olyan szállítmányozó cég érzékelheti, amely akár több száz járművel rendelkezik és ráadásul ezek típusa is eltér. Az ilyen vállalatok információs rendszerének tervezése egyszerűbbé, működése megbízhatóbbá válik, ha az egyes járműveken ugyanolyan formátumú CAN üzenetek hordozzák a rendszer számára értékes információkat.
Ábra 23. Példa CAN alkalmazásra [Forrás 14. SAE]
- 26 -
ReD-CAN
Irodalomkutatás
Ábra 24. Példa FMS szabványú CAN üzenetre [Forrás 19. FMS]
A CAN protokoll megvalósításai A CAN hálózat használata járművekben A járművekben használt soros kommunikációnak négy fő alkalmazási területe van. Hálózati vezérlők szolgálnak a motor időzítésénél, a sebességváltónál, az alváznál és a fékeknél. Az adatátviteli sebesség a valósidejű rendszerekben szokásosan 200kbps-tól 1Mbps-ig terjedhet. A motorvezérlésre láthatunk példát egy Skoda Fabia RS raliautónál, melynél az adatcserét – a sorozatban gyártott modellekhez hasonlóan – a CAN adatbusz biztosítja. Az öszkerékhajtás vezérlésének valamennyi működési adatát a versenyek közben rögzítik, és a karbantartási szünetekben értékelik ki, így a kiértékelés alapján el lehet hárítani az esetleges hibákat, illetve üzemzavarokat, vagy a pályaviszonyok megváltozása miatt a hajtásrendszer beállításain is lehet módosítani. A kapcsolási művelet koordinációjáról egy önálló elektronikus vezérlőegység gondoskodik, amely szintén a CAN adatbuszt használja a motorvezérlés felé irányuló adatcseréhez. [Forrás 10. Magyar Rádió Online]
Ábra 25. Példa CAN alkalmazásra [Forrás 15. CANOpen]
- 27 -
ReD-CAN
Irodalomkutatás
Ábra 26. CAN-re csatlakozó eszközök [Forrás 15. CANOpen] Az alváz elektronika és a kényelmet szolgáló elektronika is hálózatba kapcsolható. Erre példa a világítás, a légkondicionálás, a központi zár, a szék és a tükör beállítása. Itt a tipikus átviteli sebesség 50 kbps. Az adatbusz felhasználásával a lámpák is vezérelhetők (ezek akár külön buszra csatlakoztathatóak). A közeljövőben nem lesz szükség külön helyzetjelző és féklámpára: a CAN busz képes ugyanis arra, hogy ugyanarra a 21 wattos izzóra 5 wattos impulzusmodulált jelet juttasson (így lesz belőle helyzetjelző fény), amelyre a fékpedál lenyomásakor 21 wattos teljesítményt küld a rendszer (ilyen az új Audi A4-es). [Forrás 11. Totalcar] SDK-Tech Kft. –CANAlarm Egy újabb alkalmazási terület a riasztók. Az SDK-Tech Kft. CANAlarm terméke képes az autó CAN adatbusz adataiból felismerni a riasztó számára szükséges adatokat, majd a felismert adatokat teljes körű konfigurálhatóság után a hagyományos riasztó rendszerek felé közvetíteni. Előnyök: 9 9 9 9
A riasztó bekötésekor a kábelezési igény minimálisra csökkenthető Elkerülhető az autó szakszerűtlen szerelése Nő a megbízhatóság (a kábelezés és csatlakozások kiépítése mindig gyenge pont egy autóban (korrózió)) Csökken a beépítés költsége
Ábra 27. CANAlarm [Forrás 12. SDK-Tech Kft.]
- 28 -
ReD-CAN
Irodalomkutatás
A Vector – Cantech szoftverei A Vector-Cantech cég megvalósításában több szoftver is megjelent a CANBus járműdiagnosztikai felhasználásának segítségére. Ezek segítségével a CANBusról nyert információkat felhasználóbarát környezetben tekinthetjük meg, rendszerezhetjük, dokumentálhatjuk. A szoftverek: 9 CANdelaStudio 9 CANdesc 9 CANape 9 CANoe CANdelaStudio Ez a szoftver az adatok begyűjtését teszi egyszerűvé, valamint azok dokumentálását. A fejlesztők fő célkitűzése volt, hogy a szoftvert maximálisan felhasználóbarát formában készítsék el, így a felhasználónak nem kell információkkal rendelkeznie a buszrendszer, az adattípusok felépítéséről. A járműgyártók által használt különböző érzékelők miatt szükséges, hogy a szoftvert ellássák egy olyan funkcióval, melynek segítségével az érzékelőkhöz hozzá lehet rendelni a megfelelő jelentést, ezt pedig ún. Documentum Template-ek segítségével oldották meg, melyek tartalmazzák a gyártó specifikus leírásokat. Ezáltal a szoftver felhasználhatósági területe nagyban bővült. A szoftver egy RTF (Rich Text Format) típusú fájlba menti ki a diagnosztikai információkat, mely tartalomjegyzéket, és tárgymutatót is tartalmaz. CANdesc (Diagnostic embedded software component) Ennek a szoftvernek a segítségével C programkódot hozhatunk létre, mely képes kapcsolatot létesíteni a busz rendszerrel, így ez beépíthető egyéb szoftverekbe, sok fáradságos munkától megkímélve a fejlesztőket. CANape A CANape szoftver az úgynevezett ECU (Electronic Control Unit), azaz a jármű elektronikus vezérléséért felelős egység tervezésénél nyújt nagy segítséget. Ezzel a szoftverrel a fejlesztés fázisában pontosan konfigurálhatják, kalibrálhatják az ECU-t. A CANape szoftver lehetőségei: 9 9 9 9 9 9 9 9 9 9 9 9 9
ASAP2 editor az ASAP2 leíró fájlok létrehozásához Ablakos megjelenítés a mért adatok egyszerű áttekintéséhez Az ECUn belüli diagnózis funkciók is elérhetőek CANdelaStudio a leíró fájl áttekintéséhez A kommunikáció teljes nyomon követése az ECU felé Video ablak videofelvétel rögzítéséhez MATLAB/Simulink modellek is beépíthetőek A karakterisztikák módosítását nyújtó komponensek Felhasználó által konfigurálható panelek Script-elés lehetősége, hogy a sűrűn végzett feladatokat automatizálhassuk CDM Studio a paraméter beállítások kimentéséhez, összehasonlításához Program és adatbeírási lehetőség az ECUba A felhasználói interfész teljes mértékben átkonfigurálható
CANoe Ez a szoftver modern rendszerek hálózatainak fejlesztését teszi egyszerűbbé, a tervezéstől egészen a kivitelezésig. Nyílt architektúrájának köszönhetően a szoftver átkonfigurálható a legbonyolultabb feladatok végrehajtásához is. A közeljövőben a soros kommunikációt a mobil kommunikációban is alkalmazni fogják az autórádió, mobiltelefon, navigációs eszközök, stb. központi panelben történő összekapcsolására. A Prometheus projektben definiált olyan funkciók, mint a jármű–jármű ill. jármű–infrastruktúra kommunikáció, a soros kommunikáció további bővítését fogja igényelni. - 29 -
ReD-CAN
Irodalomkutatás
Ábra 28. A CANoe szoftver működés közben A CAN hálózat ipari alkalmazásai A járművek buszrendszereinek és az ipari terepbusz rendszereknek az összehasonlítása sok azonosságot mutat: alacsony költség, elektromágneses zajjal terhelt környezetben való működés, valósidejű működés, egyszerű használat. A CAN szabványos használata a Mercedes-Benz-nél, és az USA-beli járműgyártók nagysebességű adatátvitelre szolgáló CAN adoptációja (egészen 1 Mbps-ig) felkeltette az ipari felhasználók érdeklődését. Nemcsak a mezőgazdasági gépgyártók és hajógyárak választották a CAN-t, hanem pl. orvosi eszközökben, textilgyártásban és liftek vezérlésében is alkalmazzák. Jól használható a gépekben vagy gyárakban az „intelligens” I/O eszközök és az érzékelők/beavatkozók hálózatba kapcsolására is. Az adatátvitel megbízhatóságán túl az állomásokra eső alacsony kapcsolati költség is jelentős érv a CAN használata mellett. Az olyan alkalmazásokban, ahol a költség kritikus, felhasználhatjuk a sok gyártó által kínált CAN chipeket. A kompakt vezérlőchipek előnyösen használhatók fel például a kisfeszültségű kapcsoló-berendezésekben.
- 30 -
ReD-CAN
Irodalomkutatás
A CAN és a PC kapcsolata Gyakran közvetlen adatfeldolgozást valósítanak meg egy közvetlen PC-re kötött CAN hálózaton. Erre a legtöbb esetben valamilyen tesztelési fázisban van szükség. Több megoldás is létezik egy CAN hálózat és PC összekötésére. Asztali számítógép esetében ez tipikusan egy bővítőkártya formájában, míg hordozható gépekhez párhuzamos, illetve soros porton kapcsolhatók.
Ábra 29. CAN Card ISA, PCI [Forrás 12. SDK-Tech Kft.]
Ábra 30. CAN Plug printer porthoz [Forrás 12. SDK-Tech Kft.]
- 31 -
ReD-CAN
Irodalomkutatás
Soros kommunikáció A számítógépek kommunikációs portjain (COM portok) keresztül az RS232 szabvány szerinti kommunikációt tudnak megvalósítani. Az RS232 egy elterjedt és kipróbált szabvány az aszinkron kommunikációra, amelyet szinte minden számítógéphez kívülről csatlakozó eszköz (scanner, printer, terminál) kezelni képes. A PC-ben általában két kommunikációs port van COM1 és COM2. A BIOS, pedig csak négy független kommunikációs portot képes kezelni, de nincs akadálya további portok létesítésének sem, természetesen saját illesztőprogrammal. A soros porton való kommunikációt megvalósíthatjuk BIOS megszakításokkal, vagy közvetlen a soros vezérlő áramköreinek programozásával is.
Modem a soros porton A modem (modulátor-demodulátor) céljaira fejlesztették ki a soros kommunikációt. A modemekkel telefonvonalon keresztül számítógépek csatlakoznak egymáshoz. A modemek a terminálról érkező adatot modulálják, átalakítják, hogy egy más rendszerű kommunikációs rendszeren is továbbítható legyen, az érkező jeleket pedig visszaalakítják a gép számára. Ezért minden olyan eszközt, amely kétirányú jelátalakításra képes modemnek nevezhetünk. A számítógéphez kapcsolódó modemeknek speciális követelményeknek kell megfelelniük. A géppel az RS232 felületen kell kommunikálniuk, a jeleket frekvenciamodulált jellé kell alakítani és így továbbítani a telefonhálózaton keresztül, míg az onnan érkező jeleket szabványos RS232 jelekké alakítva a gépnek továbbítani. Ilyen módon két számítógép egy telefonvonalon összeköthető. Az adattovábbító egységeket (modem) adatátviteli DCE (Data Communication Equipment) eszközöknek, az adatokat szolgáltató egységeket (számítógép) terminál (Data Terminal Equipment) eszközöknek nevezzük. A kommunikáció megbízhatóságát különböző hibajavító eljárások biztosítják. Ebben az elrendezésben kétféle kommunikációs vonal van: DTE-DCE vonal: A terminált, és az adattovábbító eszközt köti össze. Ez a modemeknél egy RS232-es aszinkron kommunikációs vonal. Sebességét a szabvány rögzíti. DCE-DCE vonal: Két adattovábbító eszközt (modemet) köt össze. Ez itt telefonvonal, amelynek sebességét a telefonvonal minősége korlátozza.
Az aszinkron soros adatátvitel A soros kommunikációnak alapvetően két fajtája létezik, a szinkron és az aszinkron. A szinkron kommunikáció során az adó (transmitter), és a vevő (receiver) az egész adatblokk idején szinkronban vannak, közös szinkronjelet használnak. Az aszinkron kommunikáció esetében más a helyzet. Az adó és a vevő csupán egyetlen byte átvitelének idejéig marad szinkronban, külön szinkronjelet használnak, a karakter átküldése után a vonal határozatlan időre inaktív állapotba kerül. A kommunikáció során a bitek ütemezve egymás után átmennek a vevőhöz, a bitekhez tartozik egy bizonyos bitütem. A kommunikáció során ez már nem változhat, tehát az átvitel elején ezt előre definiálni kell. Ennek az időtartamnak a hossza határozza meg az átvitel sebességét: minél rövidebb az egy bit átvitelének ideje, annál gyorsabb a kommunikáció. A vevőnek és az adónak ugyanazt az időt kell hozzárendelnie a bitekhez, különben az átvitt információ hibás lesz. A kommunikációs vonal alapesetben inaktív állapotban van, ez az RS232 szabvány esetén magas szint. Amikor az adó adatot szeretne küldeni a vevőnek, ezt az ún. startbittel jeleznie kell. Ez nem része az információnak, csak kiegészítő információ. Az adatot kiegészítő (framing) bitek veszik körül. Az adás kezdetét a startbit jelzi, amely mindig alacsony szintű (0-1 átmenet). Ezt követik az adatbitek. Az adatok után az adó elhelyez egy stopbitet, amely a karakter átvitelének végét jelzi. A stopbitek száma állítható (1, 1,5, 2). A stopbit mérete itt természetesen a bit idejét jelenti (1,5 stopbit 1,5 bitütemig tart). Ha a vevő a stopbitet érzékelte, következhet egy újabb startbit, ami újabb karakter vételére szólítja fel a vevőt. Az átvitel során kérhetünk paritásos hibaellenőrzést is, ekkor a stopbitet a paritásbit előzi meg. A paritásos hibaellenőrzés lényege, hogy az átvitt adat egyes bitjeinek számát a paritástól függően a paritásbit páros vagy páratlan értéke egészíti - 32 -
ReD-CAN
Irodalomkutatás
ki. Ha az átvitel során egy bit megsérül, akkor a kiegészítés miatt nem fog egyezni az egyes bitek száma, azaz paritáshiba lép fel. Statisztikailag kimutatható, hogy annak hogy több bit úgy sérüljön, hogy nem lép fel paritáshiba nagyon kicsi az esélye. Az átvitelt négy jellemző adattal jellemezhetjük.
Az átvitel jellemzői Az átvitel sebessége Az időegység alatt átvitt bitek száma. Ezt bitütemezésnek (baud-rate) nevezzük, és bit/sec-ben (bps) mérjük. Az RS232 szabvány 9 megengedett értéket rögzít. A PC-n a soros időütemet egy 1.8432 MHZ-es órajelből osztással állítják elő, így a szabványban rögzítettektől eltérő sebességeket is be tudunk állítani. A legkisebb osztó a 16 lehet, így a legnagyobb bitütem 1843200/16=115200Hz, azaz az elérhető legnagyobb baud rate 115200 bps. Ezek a sebességek a DTE-DCE vonalra érvényesek. A DCE-DTE sebességet a telefonvonalakra vonatkozó jelenlegi sávkorlátozások miatt nemigen lehet 56.000 bps felé emelni. A DTE-DCE és a DCE-DCE sebességek közötti különbséget a modem korrigálni tudja. Ha a DTE-DCE kommunikáció gyorsabb, mint a DCE-DCE, akkor a modem az adatot először hardveresen tömöríti, csak azután továbbítja, ezért virtuálisan nagyobb sebességgel folyik az adatátvitel, mint amilyen a fizikai sebesség. Az átvitel során használt adatbitek száma Az átvitel során 5, 6, 7, 8 adatbitet használhatunk. Az átvitel során használt stopbitek száma A szabvány 1, 1.5 és 2 stopbitet enged meg, de a 1.5 stopbit csak az 5 bites adatbit-szám mellett használható. A paritás ellenőrzés típusa Az átvitel során használt paritásellenőrzés típusa. A paritásellenőrzést nem szükséges használnunk, de amennyiben ezt megtesszük, választhatunk páros, illetve páratlan paritás számot. Baud rate
Bitütem, egy bit időtartama
150 bps
6.66666
300 bps
3.33333
600 bps
1.66666
1200 bps
0.83333
2400 bps
0.04166
4800 bps
0.20833
9600 bps
0.04166
19200 bps
0.05208
38400 bps
0.01736
Táblázat 1. Baud rate értékeknek megfelelő bitütem
- 33 -
ReD-CAN
Irodalomkutatás
Eszközök összekötése Az adó és a vevő összekötésére elméletileg elegendő egyetlen érpár. A soros összeköttetés azonban számos kiegészítő jelet is tartalmaz. Tágabb értelemben nem is az adóról és a vevőről kell beszélnünk, hanem két olyan eszközről, amely egymástól függetlenül adni és venni is tud egyidőben. Az ilyen készülékeket duplex eszközöknek nevezzük. AZ RS232 szabvány kilenc vezetéket ír elő az összeköttetésre, ezekből csupán három (az RxD, a TxD és a GND vezeték) elengedhetetlen az egyszerű duplex kommunikációhoz, a többit csak abban az esetben szükséges használnunk, ha modemmel kommunikálunk, vagy ha a modemvezérlő egyéb funkciót (például kézfogásos, handshake vezérlési feladatokat) is szánunk. Az egyes jelek funkciója nevük és típusuk szerint:
TxD
(output)
Adási vezeték (transmit data) A DTE és DCE összeköttetése adáshoz.
RxD
(input)
Vételi vezetékek (receive data) A DTE és DCE összeköttetése vételhez.
RTS
(output)
Az adatterminál adási kérelme (request to send) A DTE adja ki a DCE felé, ha adni szeretne.
CTS
(output)
Az adattovábbító kész az adásra (clear to send A DCE adja ki a DTE felé, ha kész az adásra.
DTR
(output)
Az adatterminál üzemkész (data terminal ready) A DTE adja ki a DCE felé, ha üzemkész.
DSR
(input)
Az adattovábbító üzemkész (data set ready) A DCE adja ki a DTE felé ha üzemkész.
DCD
(input)
Az adatvivő jel érzékelhető (data carrier detect) A DCE adja ki a DTE felé, ha a vonalon az adatátvivő jelet érzékeli
RI
(input)
Csengetésérzékelő (ring indicator) A DCE adja ki a DTE felé, ha a vonalon csengetés érzékelhető.
GND
-
Földvezeték (ground) A DTE és a DCE összekötése.
Táblázat 2. Soros port jelei és funkciójuk [Forrás 13. Móra György]
- 34 -
ReD-CAN
Rendszer célja
Rendszer célja A rendszer rövid bemutatása A rendszer célja, hogy egy a flottakövető által megfigyelt járműről még bővebb körben nyerhessünk információkat, méghozzá a 2000-től minden új gépjárműbe beépített CAN busz rendszeren keresztül. A rendszer a begyűjtött információk sokaságából kiszűri a számunkra szükséges, figyelni kívánt információkat, majd ezeket a flottakövető rendszer moduljának a segítségével GPRS kapcsolaton keresztül továbbítja egy szerverre. Ezek után a szerveren lehetséges a beérkezett adatok további elemzése, ezután ezek felkerülnek egy weboldalra, ahol a szolgáltatásra előfizető felhasználó megtekintheti a már kiértékelt információkat a járművekről. Projektünk a Cason Rt. működő flottakövető rendszert veszi alapul, és a cég munkatársai, mint külső konzulensek segítik munkánkat. A Cason Rt. felajánlotta, hogy a megvalósítás során biztosít számunkra mindenfajta technikai hátteret.
A projekt lépései 9
9 9
CAN demo o FMS szimulátor o FMS-spy o Megjelenítés böngészőben Összeköttetés a HiROT-tal Tesztelés, hibajavítás
Ábra 31. A rendszer felépítése
- 35 -
ReD-CAN
Rendszer megvalósítása
TDK munkánk elsődleges célja egy demo rendszer kifejlesztése, amely egy FMS szabvány szerinti jármű modelljéből (szimulációjából) és egy CAN üzeneteket soros portra továbbító modulból áll. A jármű szimulátor minimális beavatkozás mellett egy mozgó autóhoz hasonló módon viselkedik a CAN üzenetek szempontjából. A teljesség igénye nélkül előre meghatározott számú és típusú üzeneteket generál az FMS szabvány implementációjaként. A fogadó berendezés CAN buszon keresztül összeköttetésben áll a szimulátorral, érzékeli az üzeneteket, és szűrésnek megfelelően továbbítja szabványos soros porton (RS-232) keresztül PC-re. A PC-n ezt egy arra alkalmas szoftver fogadja és az adatok egy Web-szerver segítségével megjelennek Internet böngésző alkalmazásban. Ezen eszközök kivitelezésére azért van szükség, hogy a későbbi fejlesztések tervezését és a tesztelést megkönnyítsük. Végső célunk egy önálló FMS modul létrehozása, mely szabványos FMS üzeneteket képes szűrni, értelmezni és továbbítani egy másik eszköznek. Jelen esetben ez a másik eszköz a HiROT flottakövető rendszer, mely segítségével megvalósulhat egyfajta távdiagnosztika egy FMS képes távoli CAN hálózaton.
Rendszer megvalósítása Áttekintés A projekt első állomása egy szimuláció kidolgozása, melynek segítségével megismerkedtünk a CAN specifikáció lényegével. Ez alatt az elméleti tudás gyakorlatban való alkalmazását értjük, azt a folyamatot, amikor szemtől-szembe találtuk magunkat a hardver-közeli rendszerek tervezési és kivitelezési nehézségeivel. A szimuláció elkészítésére egy általános hardver kombinációt használtunk, ami megfelelő háttérnek bizonyult az összes CAN busz nyújtotta lehetőségek tanulmányozására. Célunk az FMS szabvány implementációja és ezúton a CAN busz előnyeinek illetve hátrányainak bemutatása. Annak érdekében, hogy ne csak egy izolált, önmagában jól működő rendszert hozzunk létre, továbbá a végeredmény látványos és meggyőző legyen, a berendezés külvilággal való kapcsolatára és a megjelenítésre is nagy hangsúlyt fektettünk.
Ábra 32. A demo rendszer felépítése - 36 -
ReD-CAN
Rendszer megvalósítása
Hardvereszközök bemutatása A hardvereszközöket Fejes Péter a Cason Rt. fejlesztőmérnökének tervei alapján, cég által biztosított alkatrészekből saját kezűleg építettük meg és programoztuk fel. Ezek modulok, mind ugyanarra a hardver kombinációra épülnek, segítségével lehetőség nyílik CAN-nel kapcsolatos egységek szoftvereinek fejlesztésére és azok tesztjére. Az eszköz következő fő részegységekből áll:
a a a a
Ábra 33. Mikrokontrollerek kapcsolata A 33. ábrán látható, hogy a CAN vezérlő és a soros interfész az MCU-n keresztül kommunikálhat egymással. (Az egyes modulok más-más funkcionalitással rendelkeznek, ezért tartalmaznak olyan elemeket, amelyek itt nincsenek feltüntetve, ezek az egyes modulok leírásánál részletesen megtalálhatók)
MCU Az angol terminusból átvett elnevezés a Main Controller Unit rövidítése szószerinti fordításban Fő Vezérlő Egységet jelent. Az úgynevezett beágyazott rendszerekben (embedded system) ezek a processzorok végzik a többi mikrokontroller koordinációját és az esetleges részegységek vezérlését. A mi konfigurációnkban az MCU feladatait az Atmel ATMega128 mikrokontroller látja el. Ez az Atmel cég AVR családjának 8 bites, RISC maggal ellátott processzora, mely számos szabványos I/O csatoló támogatással van felvértezve. Fő jellemzői: 9
RISC architektúra o Egyetlen óraciklus végrehajtású utasításkészlet, 133 utasítás o 32x8 általános célú regiszter+ perifériavezérlő regiszterek o Statikus működés o 16 Mhz órajel mellett 16 MIPS teljesítmény
Ábra 34. A tesztpanel - 37 -
ReD-CAN 9
9 9
Rendszer megvalósítása
Memória o 128K újraprogramozható FLASH programmemória Élettartam: 10 000 Írás/Törlés ciklus o 4K EEPROM memória adattárolásra o 4K belső SRAM o 64K opcionális külső memória JTAG interfész: On-Chip Debug funkcióra és programozásra Perifériák o 2 db 8 bites számláló/időzítő o 2 db 16 bites számláló o TWI interfész o Serial USART interfész o SPI interfész o Watchdog timer
A processzor 64 lába hat PORT-ra osztható, melyek egyenként nyolc kivezetést tartalmaznak. Ezek lehetnek speciális funkcióval ellátva, (pl. USART, SPI, stb…) vagy használhatók általános digitális kimenet/bemenetként. Mindegyik csatlakozó láb szabadon beállítható kimenetként, és ebben az esetben az is beállítható, hogy kimenetén 0 vagy 1 szint legyen, illetve szintén mindegyik használható bemenetként is, ilyenkor be vagy ki kapcsolható egy belső felhúzó ellenállás használata, mely gyakorlatilag negálja a bemenetet. A mikrokontroller két fajtája létezik, az 5 és 3 Volt táppal működő kivitel. Eszközeinkben mindkettőt használjuk, részletes paramétereik az egyes eszközök leírásánál részletesen megtalálható. A processzor órajelét egy külső 8Mhz-es kvarc biztosítja.
Ábra 35. Az ATMega128 lábkiosztása [Forrás 16. Atmel]
- 38 -
ReD-CAN
Rendszer megvalósítása
I/O Portok Az egyes portokat használat előtt inicializálni kell, azaz be kell állítani, hogy kimenetként vagy bemenetként viselkedjen. Minden általunk írt program első függvényhívása a port inicializálás. Egy port adott lába három regiszterbitből áll: DDxn, PORTxn, PINxn (ahol x az adott portra száma, az n a porton belüli bit szám). A DDxn regiszterek meghatározzák az adott láb irányát. Ha a DDxn regisztert logikai 1-ra állítjuk, akkor az adott láb kimenetként, ha logikai 0-ra, akkor bemenetként van definiálva. Ha egy lábat kimenetre állítunk, akkor a PORTxn regiszter értékének módosításával lehet beállítani, hogy az adott láb kimenetén logikai 1 vagy 0 szint jelenjen meg. Ha ezt a lábat előzőleg bemenetként definiáltuk, akkor a PORTxn 1-re vagy 0-ra állításával a beépített felhúzó ellenállás használatát kapcsolhatjuk be, illetve ki. A DDxn láb bemenetre állításakor a PINxn regiszterből olvashatjuk ki az adott láb értékét.
SPI interfész Más mikrovezérlőkkel való kapcsolatot a szabványos SPI (Serial Peripheral Interface) busz támogatja. Az SPI kommunikációban résztvevő két eszköz közül az éppen adatot küldő a Master, az adatot fogadó a Slave állomás. A kettő között négy szál teremti meg a kapcsolatot, mely kétirányú kommunikációt tesz lehetővé egyidejűleg. Az SPI interfész lábkiosztása: 9
CS (Chip Select): felhúzott alapállapotú láb, a kommunikáció kezdetét ennek a 0 szintre állítása jelzi.
9
CLK (Clock): órajelet továbbító láb, amely a két eszköz szinkron adatátviteléért felelős.
9
MOSI (Master Out Slave In): a Master állomásról a Slave felé irányuló kommunikáció adatvezetéke, mely egyértelműen meghatározza a kommunikáció irányát.
9
MISO (Master In Slave Out): a MOSI fordítottja, tehát a Slave által a Master felé küldött adatok vezetéke.
A kommunikációt a Master kezdeményezi azzal, hogy a CS lábat lehúzza 0-ra. Ennek hatására a Master felkészül adatküldésre, a Slave pedig az adatok fogadására. Ezután a Mater órajelet generál és azt folyamatosan küldi, mely meghatározza a kommunikáció ciklusát. Az adatok bekerülnek a megfelelő regiszterekbe, és minden átvitt adatcsomag után a Master a CS láb visszaállításával szinkronizál, vagy jelzi az adatcsere végét. Hardvereszközeinkben az SPI buszon keresztül a CAN vezérlő irányítását és az ATMega128 számítógépről történő programozását végezzük egy letöltő adapter segítségével.
Ábra 36. SPI kommunikáció
- 39 -
ReD-CAN
Rendszer megvalósítása
USART interfész Az USART (Universal Synchronous and Asynchronous serial Receiver and Transmitter) interfész segítségével az ATMega128 képes RS232 szabvány szerint soros kommunikációt létesíteni egy vagy két másik terminállal. Ez azt jelenti, hogy a processzorban két egyenrangú USART csatolófelület található, melyek akár egyszerre is használhatók és minden létező és szabványos megoldást támogatnak. Az átvitel a Soros kommunikáció c. fejezetben leírtak szerint működik. Az ATMega128 a következő módon valósítja meg a soros kapcsolatot. Az USART inicializálása során be kell állítani a kapcsolat tulajdonságait, ügyelve arra, hogy mindkét eszköz ugyanazokat a beállításokat használja. Ezek a beállítások a Baud Rate, adatkeret formátum (adatbitek, stopbitek száma), és hogy az eszköz adó, vevő, vagy mindkettő egyszerre. Az inicializálás után megkezdődhet az adatok vétele, fogadása. A soros kommunikációt a CAN üzenetek soros portra küldésénél és a soros portról érkező üzenet formátumú adatok CAN buszra történő továbbítására használjuk.
Külső megszakítások Az ATMega128 alapvetően két fajta megszakítást különböztet meg a kiváltó esemény alapján. Az egyik típus egy jel változására (esés/emelkedés éle) reagál, melynek regisztere EICRA, míg a másik a logikai 1/0 értékre, regisztere EICRB. A két regiszter értékeinek kombinációja vált ki megszakítást. A megszakítások globális engedélyezését a Status Register (SREG) SPIF bitjének 1-re állításával lehet elérni. A regiszterek részletes leírását a Regiszterek melléklet tartalmazza.
CAN Controller CAN vezérlőként hardvereszközeinkben a Microchip MCP2515 chipje működik. Főbb jellemzői: 9 A CAN2.0B implementációja 1 Mb/s sebességen o 0-8 byte adatmező o standard és extended üzenetformátum támogatása 9 Üzenet fogadás: o 2 üzenet fogadó puffer o 6 29-bites filter o 2 29-bites maszk 9 Üzenetküldés: o 3 üzenetküldő puffer 9 Nagy sebességű SPI interfész (10 Mhz) 9 Megszakítás kimenet 9 Request-To-Send (kérésküldésre) bemenet 9 Low Power CMOS technológia: o 2,7V-5.5V feszültségforrás o 5mA áramfelvétel
Ábra 37. Az MCP2515 lábkiosztása - 40 -
ReD-CAN
Rendszer megvalósítása
Fejlesztőeszközök bemutatása A fejlesztés igen sokrétű munkát követelt, ami többfajta fejlesztési platform és eszköz használatát vonta maga után. A legnagyobb kihívást az alacsony szintű programozás jelentette. Az ATMega128 mikrokontrollerek programozását az IAR Embedded Workbench fejlesztőprogram segítségével végeztük. Ez egy komplett Windows-os fejlesztői környezet, mely támogatja az Atmel AVR technológiával készült processzorainak programozását. A program C fordítót is tartalmaz így elkerülhettük az Assembly programozás minden nehézségét. A C fordító által létrehozott bináris fájlt a PonyProg2000 nevű alkalmazással töltöttük a mikrokontroller flash memóriájába. Ez a program teljes körű támogatást nyújt több fajta Atmel és PIC mikroprocesszor-család programozására. A Windows .NET keretrendszer alatt futó, PC oldali további programjainkat Microsoft Visual Studio .NET 2003 fejlesztőkörnyezettel készítettük. Barátságos felülete, könnyű kezelhetősége, logikus felépítése, jó támogatottsága lehetővé tette a hatékony fejlesztést.
- 41 -
ReD-CAN
Rendszer megvalósítása
Demo rendszer FMS szimulátor Fizikai szint Ez az egység a tesztelés megkönnyítésére készült, e nélkül jelentősen nehezebb lenne a fejlesztés, mivel minden egyes alkalommal egy CAN rendszerrel rendelkező járműhöz kellene csatlakoztatnunk a tesztelendő egységet, ami igen körülményes lenne. Ez a nyomtatott áramkör az általunk leprogramozott FMS szabvány szerinti CAN üzeneteket küldi CAN csatlakozóján keresztül. Az eszköz modellezi egy jármű működése során generálódó FMS üzeneteket. A Hardvereszközök bemutatása című fejezetben már bemutatott hardver konfigurációt tartalmazza a következők szerint. Az egység 12 vagy 24 V tápfeszültségről is üzemeltethető, melyet egy kapcsoló üzemű táp megfelelő háromszor 5 Voltra alakít. A három tápfeszültség az MCU, a CAN controller és az LCD egység működéséhez szükséges. Az eszköz tartalmaz egy LCD modult, amely megjelenítéshez/hibakereséshez szükséges, négy gombot és ugyanennyi LED-et a felhasználói beavatkozáshoz.
Algoritmusok Inicializáció Portok inicializálása Az Atmel portjainak inicializálása azt jelenti, hogy elnevezzük a megfelelő regiszterek megfelelő bitjeit, így könnyebb lesz a portokra hivatkozni. Ezután beállítjuk a portokat, aszerint, hogy kimenetként, vagy bemenetként fognak funkcionálni. Legvégül még a felhúzóellenállásokat is beállítjuk. Az Atmel-MCP kommunikációjában résztvevő portok: 9 SPI_SCK : ( SPI Bus Serial Clock ) Az átvitel szinkronizációját szolgáló órajel 9 SPI_MOSI : ( SPI Bus Master Out - Slave In ) : A master egység adatkimenete, a slave bemenete 9 SPI_MISO : ( SPI Bus Master In – Slave Out ) : A master adatbemenete, a slave kimenete 9 SPI_SS : ( SPI Slave Select input) 9 CAN_CS 9 CAN_INT SPI_SCK_DIR = pinOUT; az órajel portját kimenetként definiáljuk SPI_SCK = 0; SPI_MOSI_DIR = pinOUT; a MOSI portot kimenetnek állítjuk, mivel az Atmel lesz a master a kommunikációban SPI_MOSI = 0; SPI_MISO_DIR = pinIN; mivel az Atmel a master, ezért a MISO bemenet lesz SPI_SS_DIR = pinOUT; CAN_CS_DIR = pinOUT; CAN_CS = 1; CAN_INT_DIR = pinIN;
SPI interfész inicializálása Beállítjuk az SPI interfész sebességét, üzemmódját. SPCR_Bit1 = SPCR_Bit0 = 0; - 42 -
ReD-CAN
Rendszer megvalósítása
az SPI órajelét állítja az Fosc negyedére SPCR_Bit3 = 0; az órajel polaritását állítja be, az órajel 1 értékre lesz aktív SPCR_Bit4 = 1; az SPI-t master módra állítja SPCR_Bit6 = 1; végül engedélyezzük az SPI működését SPSR_Bit0 = 0; az SPI master módban is az Fosc órajel negyedével fog működni, ha 1 értéket kapna, akkor működhetne dupla sebességen is CAN vezérlő inicializálása A CAN vezérlőt alaphelyzetbe állítjuk, majd megadjuk az átviteli sebességét: CAN_Reset(); CAN_CS = 0; a CS láb 0-ra húzásával jelezzük az átvitel kezdetét SPDR = CAN_RESET; betöltjük az adatregiszterbe a RESET utasítás értékét WaitSPI(); ez a procedúra vár, amíg az adatregiszterből kiolvasásra kerül az adat CAN_CS = 1; visszaengedjük a lábat 1-re, ezáltal jelezzük, hogy végeztünk az átvitellel CAN_SetConfig(); CAN_Write( CANCTRL, 0x80 ); konfigurációs módba visszük az MCP-t CAN_SetSpeed250(); CAN_Write( CNF1, 0x03 ); beállítjuk a bit timingot (lásd bit timing calculator táblázat) CAN_Write( CNF2, 0xd1 ); CAN_Write( CNF3, 0x01 ); CAN_SetNormal(); CAN_Write( CANCTRL, 0x00 ); visszaállítjuk az MCP-t normál üzemmódba Üzenetküldés Az üzenetküldés egy egyszerű folyamat, az MCP CS lábát lehúzzuk 0-ra, ezzel jelezzük, hogy adatot küldünk, majd az adatregiszterbe beírjuk az írást jelző kódot (CAN_WRITE 0x02), megvárjuk amíg ezt kiolvassa az MCP, ezután beírjuk a regisztercímet, majd az adatot. Mikor a CS láb ismét 1 értéket kap, az MCP kiküldi a CAN üzenetet. CAN_Write( unsigned char address, unsigned char data ) { CAN_CS = 0; az üzenetküldési folyamat jelzése SPDR = CAN_WRITE; az írás kódját betöltjük az adatregiszterbe WaitSPI(); megvárjuk, amíg kiolvasásra kerül a regiszter tartalma SPDR = address; betöltjük a célcímet WaitSPI(); SPDR = data; betöltjük az elküldendő adatot WaitSPI(); CAN_CS = 1; végül visszaengedjük a CS lábat 1-re, ezzel jelezzük az írási folyamat végét } - 43 -
ReD-CAN
Rendszer megvalósítása
Az FMS üzenet felépítése, kiküldése Az FMS szimulátor által küldött üzenetek FMS szabvány szerinti kiterjesztett azonosítóval rendelkező üzenetek.(Ábra 22. Az üzenet keret kiterjesztett formátuma (2.0B CAN specifikáció)) A standard azonosító (SID) 11 bitjét, valamint a kiterjesztett azonosító (EID) 18 bitjét négy, egy bájt hosszúságú regiszterben tároljuk. Az alábbi programkódok a négy regiszter feltöltésének folyamatát mutatják be. Az első regiszter, a TXBnSIDH tartalmazza a standard azonosító harmadiktól tizedik bitjeit, ezt egy shifteléssel oldjuk meg: unsigned char EncodeESIDH( unsigned long ID ) { return (unsigned char)(ID >> 21); } A TXBnSIDL tartalmazza a SID első három bitjét, az EXIDE-flaget, (amelynek 1 értéke azt jelzi, hogy az azonosító kiterjesztett formátumú) valamint az EID utolsó 2 bitjét. Először 13-mal léptetünk jobbra, így az első 3 bit a helyére kerül, majd hozzáadjuk a 16-tal jobbra shiftelt azonosítót is, ezáltal a két utolsó bit kerül a helyére. A 0xEB-vel történő éselés eredményeképp az EXIDE 1-es értéket kap. unsigned char EncodeESIDL( unsigned long ID) { return (unsigned char)((((ID>>13)&0xe0)|(0x08)|((ID>>16)&0x03))&0xEB); } A TXBnEID8 tartalmazza az EID nyolcadiktól tizenötödikig terjedő bitjeit 8-cal történő shiftelésre van szükség, mivel kiléptetjük az EID első 8 bitjét. unsigned char EncodeEID8( unsigned long ID ) { return (unsigned char)(ID >> 8); } A TXBnEID0 tartalmazza az EID első nyolc bitjét. Ebben az esetben egy egyszerű kasztolás segítségével megkapjuk a 32 bites ID legkisebb helyértékű bitjeit vagyis az EID első nyolc bitjét. unsigned char EncodeEID0( unsigned long ID ) { return (unsigned char)(ID); } Az üzenet kiküldésére szolgáló kód: void CAN_Send_Extended(unsigned long ID, unsigned char *DATA) { Létrehozunk egy 13 bájtos változót, amiben a regiszterekbe töltendő adatokat tároljuk: unsigned char packet[13]; unsigned char i = 10; SPCR_Bit1 SPCR_Bit3 SPCR_Bit4 SPCR_Bit6 SPCR_Bit7 SPSR_Bit0
= = = = = =
SPCR_Bit0 = 0; 0; 1; 1; 0; 0;
// // // // // //
SPR0, SPR1 CPOL SPI MSTR SPI Enable SPI Interrupt SPI2X - 44 -
ReD-CAN
Rendszer megvalósítása
A következő két sor funkciója, hogy megvizsgálja, hogy foglalt-e a busz, ha igen még kilencszer újra próbálkozik, ha még akkor sem sikerül kiküldeni az üzenetet, akkor törli a folyamatot: while((CAN_ReadStatus() & 0x54 ) && i) i--; if( !(i) ) CAN_Bitmodify( TXB2CTRL, 0x04, 0x00 ); Feltöltjük a változót az megfelelően formázott azonosítóval: packet[CANSIDH] = EncodeESIDH( ID ); packet[CANSIDL] = EncodeESIDL( ID ); packet[CANEID8] = EncodeEID8( ID ); packet[CANEID0] = EncodeEID0( ID ); A DLC mező az átvitt hasznos adat hosszát adja meg bájtban: packet[CANDLC] = 0x08; A hasznos adat 8 bájtját is betöltjük a változónkba: packet[CAND0] = DATA[0]; packet[CAND1] = DATA[1]; packet[CAND2] = DATA[2]; packet[CAND3] = DATA[3]; packet[CAND4] = DATA[4]; packet[CAND5] = DATA[5]; packet[CAND6] = DATA[6]; packet[CAND7] = DATA[7]; Végül a változó egyes bájtjait beírjuk a megfelelő regiszterbe: CAN_Write( TXB2SIDH, packet[CANSIDH] ); CAN_Write( TXB2SIDL, packet[CANSIDL] ); CAN_Write( TXB2EID8, packet[CANEID8] ); CAN_Write( TXB2EID0, packet[CANEID0] ); CAN_Write( TXB2DLC, packet[CANDLC] ); CAN_Write( TXB2D0, packet[CAND0] ); CAN_Write( TXB2D1, packet[CAND1] ); CAN_Write( TXB2D2, packet[CAND2] ); CAN_Write( TXB2D3, packet[CAND3] ); CAN_Write( TXB2D4, packet[CAND4] ); CAN_Write( TXB2D5, packet[CAND5] ); CAN_Write( TXB2D6, packet[CAND6] ); CAN_Write( TXB2D7, packet[CAND7] ); Az utolsó sor jelzi, hogy a kettes számú bufferben tárolt csomag készen áll a kiküldésre: CAN_Rts(RTS2); }
- 45 -
ReD-CAN
Rendszer megvalósítása
FMS-SPY Fizikai szint Az eszköz arra a célra készült, hogy egy CAN hálózatra csatlakozva, az ott zajló adatfolyam teljes egészét, vagy abból egy mintát véve továbbküldje soros portra az RS232 szabvány szerint. Ez egy üzenetmonitorozást tesz lehetővé, mely a fejlesztés fázisában vagy akár egy későbbi működő rendszer állapotának ellenőrzésére is igen hasznos lehet. A már jól ismert ATMega128-MCP2515 konfigurációra épül és ezen kívül csak egy soros illesztőt tartalmaz. Az eszköz tervezésénél fontos szempont volt a mobilitás, hiszen egy például egy jármű CAN hálózatának helyi monitorozását csak a gépkocsiban lehet elvégezni. Ezért a táplálást USB porton keresztül kapcsolja, mely minden mai notebook alap tartozéka. Fontos megjegyezni, hogy az eszköz egy univerzális CAN monitorállomásként képes üzemelni, azaz beépített intelligenciájának köszönhetően egy adott üzenetről el tudja dönteni, hogy az standard vagy extended formátumú és a továbbiakban ennek megfelelően kezeli.
Algoritmusok InitPorts A CAN_Spy esetében is az Atmel chip tölti be a master szerepét, az MCP pedig a slave szerepét. Tehát az Atmel fent leírt funkciójú SPI_SS, SPI_CS, SPI_SCK, SPI_MOSI portjait kimenetekként, az SPI_MISO portot és az SPI_INT portot, mely a megszakítás jelzés feladatát tölti be, bemenetként konfiguráljuk. Deklarálunk még portokat az adatküldési buffer, és az adat fogadási buffer részére, ezek a CAN_TXnRTS és CAN_RXnBF portok. 3 kiküldési buffert és 2 fogadási buffert hoztunk létre. InitParams Beállítjuk a beérkező adatok fogadását szolgáló RX buffer elejét, végét jelző pointereket, mindkettőt 0-ra, valamint a szabad bufferméretet jelző változót (RxBufferFree) a maximális bufferméret értékére. InitSPI Ugyanúgy mint az üzenetküldő egységnél, itt is beállítjuk az SPI órajelét az Fosc negyedére, beállítjuk az órajel polaritását, az SPI-t master módba és végül engedélyezzük az SPI működését. InitCAN A CAN vezérlő inicializálása nagyrészt megegyezik az üzenetküldő egységnél leírtakkal, azzal a különbséggel, hogy itt beállítjuk a maszkok és szűrők értékeit is. Jelen esetben a maszkok és a szűrők is olyan módon lettek konfigurálva, hogy minden beérkező üzenetet átengednek. A maszk és a szűrő beállítására példaként tekintsük azt az esetet, mikor a nullás buffer SIDH regiszterének maszkját és szűrőjét állítjuk be (a megfelelő nevű regiszterekbe beírjuk a kívánt maszk és szűrő értékeket): A maszk beállítása : CAN_Write( RXM0SIDH, 0x00); A szűrő beállítása: CAN_Write( RXF0SIDH, 0x00); (a 0x00 értékre állított maszk és szűrő minden üzenetre ráillik) InitUsart1 Az USART konfigurációja a következő lépésekből áll: - Beállítjuk a karakterméretet az UCSR1C, azaz a Control & Status Register egyes és kettes bitjének beállításával a Táblázat 11. UCSZn bitek beállításai szerint. - Baud rate érték beállítása a Táblázat 13. Leggyakrabban használt órajelek melletti baud rate értékek szerint, az UBRR1L és UBRR1H regiszterek segítségével. - Az UCSR1A összes bitjét 0 kezdőértékre állítjuk.
- 46 -
ReD-CAN
-
-
Rendszer megvalósítása Engedélyezzük az USART működését, az USART adó, USART vevő, és a megszakítások működését, az UCSR1B regiszter 3-as, 4-es és 7-es bitjének 1értékre emelésével. Utolsó lépésként az kiküldés és fogadás állapotjelzőibe (U1TxState U1RxState) betöltjük az USART_IDLE, azaz „USART üzemkész” értékeket, valamint a beérkező adatok számára a következő szabad tárhelyet jelző U1RxPtr pointer értékét 0-ra állítjuk.
InitMainTimer Ez a függvény az időzítés beállítását végzi. Az időzítés CTC (Clear Timer on Compare) üzemmódban történik, azaz egy számláló értékét hasonlítjuk össze egy előre megadott értékkel (OCR – Output Compare Register tartalmazza), és ha ezek megegyeznek, akkor kinullázuk a számlálót, és egyel léptetjük az időegység számlálót. A TCCR2 (Timer/Counter Control Register) regiszter tartalmazza az erre vonatkozó beállításokat, itt tudjuk beállítani a CTC üzemmódot, és az ú.n. prescaler értékét, amellyel az I/O órajelet leosztjuk. StartupMessage Ez a függvény egy egyszerű induló üzenetet küld az USART interfészen keresztül, melynek megérkezése jelzi, hogy a rendszer megfelelően működik. Az eszközt vezérlő program tehát a fent leírt függvényekből épül fel: void main(void) { InitPorts(); InitParams(); InitSPI(); InitCAN(); InitUsart1(); InitMainTimer(); StartupMessage(); SREG_Bit7 = 1; while ( YES ) { } } Az SREG_Bit7 = 1; sor engedélyezi a megszakítások működését, ezzel működésbe jön a rendszer.
- 47 -
ReD-CAN
Rendszer megvalósítása
Megjelenítés
Ábra 38. Szoftvermodulok rendszere A folyamat, melynek végén az FMS szimulátor által generált CAN üzenetek megfelelő formában megjelenítésre kerülnek, alapvetően két részfeladatra osztható. Az első lépés, hogy a soros portról érkező CAN üzeneteket fogadni képes program álljon rendelkezésre, mely az adatokat az FMS szabvány szerint értelmezi és tárolja egy erre a célra kialakított SQL adatbázisban. A másik része az adatok megjelenítése egy internet böngésző alkalmazásban.
Soros fogadóprogram Az FMS2SQL nevű fogadóprogram egy C# nyelven íródott, Microsoft .NET alkalmazás. A program soros kommunikációja John Hind, 2002 októberi MSDN Magazine című internetes magazinban publikált cikkére és az ott bemutatott forráskódra épül. Itt bemutatásra került egy .NET komponens, mely teljes körű RS-232 kommunikációt valósít meg Windows API hívások segítségével. A komponens CommBase elnevezésű absztrakt osztályát adoptáltuk. A program működése Az FMS2SQL program fő komponense a Cfms2sql nevű osztály, amely a program vezérléséért és az egyes osztályok közötti kapcsolatért felel. Induláskor az osztály létrehozza az egyes objektum példányokat, melyeket a futás során használunk, többek között a főablakot. A főablakban található gomb komponensek segítségével a következő ablakokat aktivizálhatjuk. Elérhető egy Settings ablak, melyben a soros kommunikáció beállításait végezhetjük el, és egy Status ablak, melyben az átvitel állapotát követhetjük nyomon. Szintén a főablakban található az Online feliratú gomb melynek hatására a CommBase osztály Open metódusa megnyitja a soros portot, továbbá az SqlConnection komponens Open metódushívása kapcsolatot épít fel a program és az SQL adatbázis között. A kapcsolat paramétereit az SqlConnection ConnectionString tulajdonságával lehet beállítani (szerver IP címe, felhasználó, jelszó, adatbázis, tábla, stb.). Mindezek hatására a program aktívvá válik és a bejövő adatokat továbbítja az SQL szerver felé.
- 48 -
ReD-CAN
Rendszer megvalósítása
Ábra 39. FMS2SQL program képernyője A soros porton érkező csomagok adatait – az FMS szabvány szerint – a DecodeFMS metódus dekódolja és tárolja el a megfelelő globális változókba. Ettől kezdve nincs más dolgunk, minthogy a rendelkezésre álló adatokat (sebesség, fordulatszám, üzemanyagszint, motorhőmérséklet, meg tett távolság) beírjuk az SQL szerver redcan nevű adatbázisának FMSspy táblájába. Ezt a feladatot egy időzítő komponens végzi, mely megadott időintervallumonként eseményt generál és meghívja a megfelelő metódust. Ez az eseménykezelő metódus beállítja az SqlCommand komponens CommandText tulajdonságát, majd meghívja az ExecuteNonQuery metódusát, mely az ily módon előállított SQL utasítást végrehajtja a szerveren. Az utasítás végrehajtásnak több formája is létezik. Ami itt mégis a „nem lekérdező végrehajtás” típusú utasítás használatát indokolja, az a tény, hogy az SQL parancs INSERT (beszúró) típusú, vagyis a végrehajtás eredménye nem egy lekérdezés, hanem egy rekord beszúrása a táblába.
SQL szerver SQL szervernek a Microsoft SQL Server 2000-et használjuk ServicePack 3-as kiegészítéssel. A kiszolgáló alapbeállításokkal üzemel, és jelenleg egy darab redcan nevű adatbázisból áll, amely a rendszer táblákon kívül egy FMSspy nevű táblát tartalmaz. A tábla a 40. ábrán látható oszlopokat foglalja magába. Az oszlopok típusai értelemszerűen a megfelelő CAN csomagok adatai szerint alakulnak. A fogadott adatok a stamp nevű oszloppal lettek kiegészítve, mely a beírt adatok időbélyegét tartalmazza. Az értékét az INSERT utasításban a GETDATE nevű függvény állítja elő. Erre azért van szükség, mert a megjelenítésnél a lekérdezés a legutóbb beírt adatokkal tér vissza, és ennek segítségével könnyedén megállapítható a legutolsó rekord.
Ábra 40. FMSspy tábla oszlopai - 49 -
ReD-CAN
Rendszer megvalósítása
Web szerver és a böngésző kliens A web szerver feladata, hogy a kliens böngészőket kiszolgálja. Erre a célra a Windows XP-be integrált Microsoft IIS-t használjuk. A megjelenítés során dinamikus tartalom követésre van szükségünk, amit az IIS-sel szorosan együttműködő ASP.NET rendszer végez. A szerveren futó web alkalmazás ASP.NET technológiát használva működik, programozását C# nyelven végeztük. A program két osztályból és ennek megfelelően két web lapból áll. A szerverre történő belépéskor a SpyForm.aspx lap és a mögötte álló kód aktivizálódik. Ez nem tartalmaz semmi mást csak egy <embed> HTML elem által meghatározott SVG beágyazást, továbbá egy hivatkozást a panel.js nevű JavaScript kódot tartalmazó fájlra. Ezt a script fájlt megosztva használja a web alkalmazás és az SVG komponens, feladata, pedig az SVG vezérlése. A másik lap a Data.aspx és a hozzá tartozó Data.aspx.cs osztály mely a lap mögötti kódot tartalmazza. Működésbe hozható egy sima http kéréssel, amire visszatér egy XML struktúrával, ami minden – a megjelenítéshez szükséges - adatot tartalmaz. A böngésző és a web szerver közötti kommunikáció tehát XML objektum segítségével valósul meg. A böngészőben megjelenő SVG komponens Online feliratú gombjára kattintva a SetTimer nevű JavaScript függvény aktivál egy időzítőt, amely két másodpercenként meghívja a Refresh függvényt, ami elvégzi a kérést a web szerver felé. Egy ilyen kérés során a Data osztályunk felépíti a kapcsolatot az SQL adatbázissal (a Soros fogadóprogram című fejezetben már megismert módon) és végrehajt egy SELECT lekérdezést az SqlCommand ExecuteXmlReader metódus meghívásával. Ennek a lekérdezésnek az eredménye egy XML struktúra, melyet az adatbázis motor állít elő, tartalma, pedig a legutóbb beírt rekord összes mezője. Ezután a meglévő XML objektum a http kérés válaszaként kiküldésre kerül, vagyis azt visszakapja JavaScript függvény, ami a kapott adatokat frissíti az SVG komponensben.
Ábra 41. Az SVG megjelenítés képernyője
- 50 -
ReD-CAN
Rendszer megvalósítása
Összeköttetés a HiROT-tal Az elkészített szimulációt csupán az előttünk álló fejlesztői munka megkönnyítése érdekében dolgoztuk ki. A demo rendszer részeként már bemutatott FMS-spy nevű eszközünk a fejlesztés első lépcsőfokán egy tetszőleges CAN adatbusz monitorozását ellátni képes berendezéssé vált. Ebben a formában történő felhasználását, azonban csak a fejlesztés korai szakaszában tehettük meg, ugyanis ekkor még az eszköz csak RS232 porton keresztül tudott monitorozni. A végső célunk az volt, hogy az általunk készített CAN/FMS monitorozó egység és a „Cason HiROT” című fejezetben részletesen bemutatott flottakövető rendszer közötti kapcsolatot megteremtsük. A tervezés első lépéseként az FMS-spy és a HiROT közötti kommunikáció típusát és működését kellett rögzíteni. Kézenfekvő megoldásnak bizonyult a CAN adatbusz kiterjesztése a HiROT irányába, a „CAN” fejezetben ismertetett előnyös tulajdonságok miatt. Természetesen felmerült a kérdés, hogy ha ebben az esetben egy CAN mikrovezérlő is helyet kap a HiROT panelen, miért ne végezhetné el maga a HiROT szoftvere CAN/FMS monitorozást? A Cason Rt. fejlesztőivel történt hosszas eszmecserék után arra az elhatározásra jutottunk, hogy az FMS monitorozás szoftverét nem integráljuk a HiROT-ba, inkább önálló modulként CAN busz segítségével csatlakoztatjuk hozzá. Döntésünket indokolja, hogy a már meglévő HiROT szoftver több mint 10.000 kódsora már amúgy is súrolja az ATMEGA128 mikrokontroller erőforrásainak határait, továbbá saját meglátásunk szerint, egy önálló modulok kapcsolataként felépített rendszer az esetek túlnyomó többségében jobb megoldásnak bizonyulhat. Gondoljunk a rendszer átláthatóságára és a továbbfejlesztésre, könnyen belátható, hogy ezek a szempontok igazolják elgondolásunkat. A már említett HiROT szoftver összetettsége miatt törekedtünk a CAN kommunikációs forgalom minimalizálására. Kidolgoztunk egy eljárást, melynek lényege, hogy a HiROT kezdeményezi az adatok lekérdezését az FMS-spy-tól. Erre azért volt szükség, mert a HiROT processzorideje szinte a végsőkig kimerül a GPS, GPRS modulok koordinálásában, illetve az egyes perifériák (digitális I/O) kiszolgálásában. Így tehát biztosan akkor fog kérést generálni, ha tényleg képes utána az adatok fogadására. Az algoritmus roppant egyszerű. Az FMS-spy a CAN buszon észlelt FMS formátumú üzeneteket megvizsgálja és elmenti mindegyik típus legutóbbi változatát. Minden csomagot összehasonlítja az előzőekben észlelt ugyanolyan ID-vel rendelkező üzenettel, és amelyik változott azt felülírja az újjal. Ily módon az FMS-spy bármely időpillanatban rendelkezni fog minden FMS üzenet legutóbbi példányával és kérésre azt továbbítani tudja a HiROT-nak. Fontos szempont lehet, hogy az adatlekérdezés paraméterei széles körben állíthatók legyenek, hiszen nem mindegy, hogy mekkora adatmennyiség megy át a rendszeren, ugyanis a GPRS kommunikáció díja az adatforgalom függvénye. Az FMS szabvány igen sokféle – legtöbb esetben fölösleges – adatot tartalmaz. Ezek közül mindig csak azt kell lekérdezni, amire tényleg szükség van a szerveren. Ezért a HiROT szoftver kialakításánál figyelni kellett, hogy az RTS (Request To Send) típusú kérés-kezdeményezés magában foglalja azt, hogy a kérés mely típusú üzenetekre vonatkozik.
- 51 -
ReD-CAN
Eredmények összegzése
Eredmények összegzése Tesztelés Eszközeink működésének első tesztjeit még a fejlesztés szakaszában végeztük, ekkor a funkcionális működést, az egymás közötti kapcsolat kialakítását és az elvégzett tevékenység eredményességét vizsgáltuk. Erre vonatkozóan leghatékonyabb eszközünk a Windows operációs rendszer beépített Hyperterminal nevű programja volt, melynek segítségével a számítógép soros portjára érkező adatcsomagokat figyelhettük. A másik, tesztelésre és egyben hibakeresésre is kiválóan használható eszköz az LCD kijelző, mely végül helyet is kapott a szimulátor panelen. Mikrokontroller programozása során szembetaláltuk magunkat azzal a problémával, hogy a programszintű hibakeresés sokkal bonyolultabb folyamat, mint egy egyszerű PC esetében. Így ebből a szempontból a legnagyobb segítséget az LCD kijelző jelentette, mellyel egy-egy regiszter aktuális értékét könnyedén megjeleníthettük, ciklusok vezérlését nyomon követhettük, illetve a végső működést ellenőrizhettük. Éles környezetben is sikeres teszteket végeztünk. A Cason Rt. megbízást kapott, hogy eszközét tesztelés céljából beépítse egy DAF kamionba. A teszt során az általunk készített rendszer első tesztverziója került beépítésre és az az elképzeléseink szerint eredményesen teljesített. Az alábbi táblázat és ábra, az erről a kamionról vett FMS üzeneteket és azok jelentését tartalmazza. Időpont 2004.12.09 7:36 2004.12.09 7:37 2004.12.09 7:37 2004.12.09 7:38 2004.12.09 8:17 2004.12.09 8:17 2004.12.09 8:18 2004.12.09 11:27 2004.12.09 11:28 2004.12.09 11:36 2004.12.09 11:37 2004-12-09 11:37 2004.12.09 11:38 2004.12.09 12:37 2004.12.09 12:38 2004.12.09 13:56 2004.12.09 13:57 2004.12.09 13:57 2004.12.09 13:57 2004.12.09 13:57 2004.12.09 13:58 2004.12.09 14:06 2004.12.09 14:07
ID 65217 65276 61444 65257 65217 65276 65257 61444 65257 65217 65276 61444 65257 61444 65257 65217 65276 61444 61444 61444 65257 65217 65276
Byte1 9 255 241 255 61 255 255 255 255 36 255 248 255 255 255 171 255 246 246 246 255 177 255
Byte2 4 45 142 255 10 45 255 255 255 14 43 220 255 255 255 15 45 125 125 125 255 15 45
Byte3 128 255 142 255 128 255 255 255 255 128 255 220 255 255 255 128 255 129 129 129 255 128 255
Byte4 1 255 72 255 1 255 255 255 255 1 255 96 255 255 255 1 255 48 48 48 255 1 255
Byte5 77 255 37 199 130 255 255 255 255 105 255 49 255 255 255 240 255 17 17 17 212 246 255
Byte6 40 255 255 94 46 255 255 255 255 50 255 255 255 255 255 51 255 255 255 255 94 51 255
Byte7 5 255 255 1 5 255 255 255 255 5 255 255 255 255 255 5 255 255 255 255 1 5 255
Byte8 0 255 255 0 0 255 255 255 255 0 255 255 255 255 255 0 255 255 255 255 0 0 255
Táblázat 3. DAF kamionnal készített teszt: adatbázisba került FMS üzenetek
- 52 -
ReD-CAN
Eredmények összegzése
Ábra 42. DAF kamionnal készített teszt: értelmezett FMS üzenetek
Összefoglalás A rendszerterv szerint megvalósított demo eszközök – hardver és szoftver elemek – a várakozásaink szerint működnek. Célunk az volt hogy megvalósítsunk egy olyan szoftver és hardver keretet, ami a végleges rendszer összes komponensét tartalmazza, melyek részleteikben nem teljesen kidolgozottak, viszont az elkészült elemek továbbfejlesztésével a kész, teljesen funkcionáló rendszert kapjuk. Az FMS szimulátor tervezésénél legfontosabb szempontnak azt tartottuk, hogy szabvány szerinti tartalmú és formátumú, időben változó üzeneteket generáljon a CAN hálózaton. Éppen ezért eltekintettünk egy kamion működésének tökéletes modellezésétől, vagyis csak egy egyszerűsített modellt implementáltunk. Az FMS-spy mind a standard, mind pedig az extended üzenetek kezelésére és feldolgozására is képes. Későbbi fejlesztési lehetőségei a maszkok és szűrők alkalmazása, ami lehetővé teszi a szükséges adatok kiválogatását. A beérkező adatok tárolása egyetlen SQL adatbázisban későbbiekben kiegészítendő a felhasználói igények szerint.
történik,
ami
a
A jelenlegi megjelenítés – igazodva a kitűzött célokhoz – SVG formátumban lett megvalósítva. A végleges, HiROT-tal összekapcsolt rendszer megjelenítése magában foglalja a HiROT eddigi funkcióit (digitális térkép) és az általunk fejlesztett új lehetőségeket.
Ábra 43. A megvalósult rendszer felépítése
- 53 -
ReD-CAN
Eredmények összegzése
Összefoglalva elkészítettünk egy FMS modult melyet CAN hálózat segítségével további eszközhöz/eszközökhöz illesztve távoli járműfelügyeletet valósíthatunk meg. A rendszerünk önállóan is kiválóan használható fejlesztési, tesztelési célokra. A HiROT flottakövető rendszerrel való kapcsolatot is kidolgoztuk, tesztjeink szerint a rendszer működőképes. A HiROT megjelenítő szoftverébe való integráció aktuális fejlesztési feladataink között szerepel. A Cason Rt. tervezi, hogy a dolgozatban bemutatott FMS modult integrálja flottakövető rendszerébe, így projektünk valódi üzleti alkalmazásban is megmérettetik a közeljövőben. Az ebbe az irányba mutató első eredményes lépéseket DAF kamionnal történő teszteléssel megkezdtük.
- 54 -
ReD-CAN
Mellékletek
Mellékletek [Forrás 19. FMS]
FMS szabvány
Ábra 44. FMS üzenetformátum (sebesség)
Ábra 45. FMS üzenetformátum (üzemanyagszint)
Ábra 46. FMS üzenetformátum (fordulatszám)
- 55 -
ReD-CAN
Mellékletek
Ábra 47. FMS üzenetformátum (megtett táv)
Ábra 48. FMS üzenetformátum (motor hőmérséklete)
- 56 -
ReD-CAN
Mellékletek
Kapcsolási rajzok FMS szimulátor
Ábra 49. CAN_RF_TEST modul kapcsolási rajza [Forrás 7. Cason Rt.]
- 57 -
ReD-CAN
Mellékletek
Ábra 50. CAN_RF_TEST panel felépítése [Forrás 7. Cason Rt.]
- 58 -
ReD-CAN
Mellékletek
FMS-spy
Ábra 51. FMS-spy panel kacsolási rajza [Forrás 7. Cason Rt.]
- 59 -
ReD-CAN
Mellékletek
Ábra 52. FMS-spy panel felépítése (felülről) [Forrás 7. Cason Rt.]
Ábra 53. FMS-spy panel felépítése (alulról) [Forrás 7. Cason Rt.]
- 60 -
ReD-CAN
Mellékletek
Regiszterek ATMega128 [Forrás 16. Atmel]
SPI SPCR – Controll Register
SPI
9
Bit 7 - SPIE (SPI Interrupt Enable): engedélyezi vagy tiltja a SPI által kiváltott megszakításokat. Csak akkor működik, ha az SPIF bit az SPSR regiszterben és a globális megszakítás engedélyezés is be van állítva.
9
Bit 6 - SPE (SPI Enable): engedélyezi vagy tiltja az SPI busz használatát.
9
Bit 5 - DORD (Data Order): adatátvitel sorrendjét határozza meg. o
Ha 1 akkor az LSB (Least Significant Bit), a legkisebb helyiérték kerül először átvitelre.
o
Ha 0, akkor az MSB (Most Significant Bit), legnagyobb helyiértéket viszi át először.
9
Bit 4 - MSTR (Master/Slave Select): ha egy Master mód, ha 0 Slave mód.
9
Bit 3 - CPOL (Clock Polarity): órajel polaritását határozza meg, ha 1 akkor az órajel magas értéken van, ha 0, akkor az órajel alacsony értéken üresjáraton.
Táblázat 4. CPOL funkcionalitása 9
Bit 2 - CPHA (Clock Phase)
Táblázat 5. CPHA funkcionalitása 9
Bit 1,0 - SPSR1, SPR0 (SPI Clock Rate Select 1, 0): a két bit kombinációja meghatározza a fő órajelciklusból, hogy mekkora legyen az SPI busz órajele.
- 61 -
ReD-CAN
Mellékletek
Táblázat 6. Az SPI busz és az ATMega128 órajelének összefüggése SPSR – SPI Status Register
9
9
9 9
Bit 7 – SPIF (SPI Interrupt Flag): ha az adatátvitel megtörtént az SPIF beállításra kerül és megszakítást generál, ha a megszakítás engedélyezve van. Bit 6 – WCOL (Write COLision flag): ha az SPDR regiszterbe írás történik, akkor a flag értéke 1, és törlődik ha az első olvasás történik az SPSR regiszterből. Bit 6-1: fenntartott. Bit 0 - SPI2x (Double SPI Speed Bit): ha 1 akkor az SPI órajel duplázódik.
SPDR – SPI Data Register
Írható/olvasható regiszter, melynek tartalma az továbbítandó/továbbítot adat. Ha írás történik az SPDR-be, akkor az átvitelt kezdeményez, ha olvasás az SPDR-ből, akkor kiolvassa a következő adatot a fogadó puffer shift regiszteréből.
Táblázat 7. A CPOL és a CPHA funkcionalitása
- 62 -
ReD-CAN
Mellékletek
Ábra 54. SPI átvitel formátuma ha a CPHA 0
Ábra 55. SPI átvitel formátuma ha a CPHA 1
- 63 -
ReD-CAN
Mellékletek
USART UDRn – USARTn I/O Data Register Az RXBn (Receive Data Buffer Register) és TXBn (Transmit Data Buffer Register) regiszterek ugyanazon az I/O címen osztoznak, amelyre az UDRn regiszter hivatkozik. Az RXBn regiszterből a fogadó adat puffer tartalmát lehet kiolvasni, a TXBn regiszterbe az adó adat pufferbe lehet írni. UCSRnA – USART Control&Status Register A 9
Bit 7 – RXCn (USART Receive Complete): 1-re állítódik, ha még nem olvasott adat van a vevő adat pufferben, 0-ra, ha a puffer kiürül.
9
Bit 6 – TXCn (USART Transmit Complete): 1, ha az adó puffer teljes tartalma elküldésre került és nincs új adat a pufferben. A TXCn flag képes Transmit Complete megszakítást kiváltani (lásd TXCIEn bit), ekkor automatikusan nullázódik, ha nem használunk megszakítást programból lehet törölni.
9
Bit 5 – UDREn (USART Data Register Empty): ha 1, az jelzi, hogy az adó puffer üres és az UDRn készen áll az adatok fogadására. Az UDREn flag képes megszakítást kiváltani (lásd UDRIEn bit).
9
Bit 4 – FEn (Frame Error): 1, ha a vevő pufferben lévő soron következő karakter keret hibás.
9
Bit 3 – DORn (Data OverRun): 1, ha túlcsordulás történik, azaz a vevő puffer tele van és új karakter várakozik a vevő shift regiszterben, melynek start bitje megállapításra került.
9
Bit 2 – UPEn (Parity Error): paritás hibánál 1-re állítódik, ha a paritás ellenőrzés be van kapcsolva (UPMn1=1)
9
Bit 1 – U2Xn (Double the USART Transmission Speed): az átviteli sebesség duplázása, mely csak aszinkron átvitelnél működik.
9
Bit 0 – MPCMn (Multi-Processor Communication Mode): bekapcsolja a multiprocesszoros kommunikációs módot, melynek segítségével az adat csomagok szűrését lehet beállítani.
UCSRnB – USART Control&Status Register B 9
Bit 7 - RXCIEn (RX Complete Interrupt Enable): engedélyezi a vevő által kiváltott megszakítást, melyet az RXCn bit vált ki.
9
Bit 6 – TXCIEn (TX Complete Interrupt Enable): engedélyezi az adó által kiváltott megszakítást, melyet a TXCn bit vált ki.
9
Bit 5 – UDRIEn (USART Data Register Empty Interrupt Enable): engedélyezi a megszakítást, melyet az adat regiszter kiürülése generál. - 64 -
ReD-CAN
Mellékletek 9
Bit 4 – RXENn (Receiver Enable): engedélyezi a USARTn vevőt.
9
Bit 3 – TXENn (Transmitter Enable): engedélyezi a USARTn adót.
9
Bit 2 – UCSZn2 (Character Size): a UCSZn1:0 bittekkel vett kombinációja beállítja a karakter méretét (bitek száma).
9
Bit 1 – RXB8n (Receive Data Bit 8): ha 9 bites adatcsomagokat fogadunk, akkor az RXB8n bitbe kerül a kilencedik vett bit.
9
Bit 0 – TXB8n (Receive Data Bit 8): ha 9 bites adatcsomagokat küldünk, akkor a TXB8n bitbe kerül a kilencedik adott bit.
UCSRnC – USART Control&Status Register C 9 Bit 7 – Fenntartott 9
Bit 6 – UMSELn (USART Mode Select): kiválasztja a kommunikáció típusát (szinkron/aszinkron).
Táblázat 8. UMSELn bit konfigurációja 9
Bit 5:4 – UPMn1:0 (Parity Mode): ennek a három bitnek a segítségével állítható a paritás.
Táblázat 9. UPMn bitek beállításai 9
Bit 3 – USBSn (Stop Bit Select): stop bit beállítása.
Táblázat 10. USBSn bit beállításai 9
Bit 2:1 – UCSZn1:0 (Character Size): kombinációjuk megadja a karakter méretet.
- 65 -
az
UCSZn2
bittel
vett
ReD-CAN
Mellékletek
Táblázat 11. UCSZn bitek beállításai 9
Bit 0 – UCPOLn (Clock Polarity): az órajel polaritásának beállítására, csak szinkron módban alkalmazható.
Táblázat 12. UCPOLn bit beállítása UBRRnL & UBRRnH – USART Baud Rate Registers
9
Bit 15:12 – Fenntartott
9
Bit 11:0 – UBRRn11:0 (USARTn Baud Rate Register): 12 bites regiszter, mely a baud rate beállítást tartalmazza. Az UBRRnH a négy legfelső helyiértékű bitet, az UBRRnL a nyolc legalsó bitet tartalmazza.
A következő táblázatok a leggyakrabban használt órajel generáló kvarcok alkalmazása melletti baud rate értékeket mutatja. A hibaszázalék a következő módon számítható:
- 66 -
ReD-CAN
Mellékletek
Táblázat 13. Leggyakrabban használt órajelek melletti baud rate értékek
Táblázat 14. Leggyakrabban használt órajelek melletti baud rate értékek
- 67 -
ReD-CAN
Mellékletek
Táblázat 15. Leggyakrabban használt órajelek melletti baud rate értékek
Táblázat 16. Leggyakrabban használt órajelek melletti baud rate értékek
- 68 -
ReD-CAN
Mellékletek
Megszakítások EICRA – External Interrupt Control Register A 9
Bit 7..0 – ISC31, ISC30 – ISC01, ISC00 (External Interrupt 3-0 Sense Control Bits)
9
Bit 7..0 – ISC71, ISC70 – ISC41, ISC00 (External Interrupt 7-4 Sense Control Bits)
9
Bit 7..0 – INT7 – INT0 (External Interrupt Request 7-0 Enable)
9
Bit 7..0 – INTF7 – INTF0 (External Interrupt Flags 7-0)
EICRB – External Interrupt Control Register B
EIMSK – External Interrupt Mask Register
EIFR – External Interrupt Flag Register
- 69 -
ReD-CAN
Mellékletek
MCP2515 [Forrás 17. Microchip]
TXBNCTRL
9 9
9
9 9 9 9 9
TXERR – Hiba történt az üzenet küldés folyamata közben TXREQ – Ennek a bitnek a beállításával jelezhetjük üzenet küldési szándékunkat. Ha a kiküldés sikeresen lezárul, akkor a bit 0 értéket kap. TXPn – Beállítja az átviteli buffer prioritását. Ha egyidejűleg több bufferből történne átvitel, akkor a magasabb prioritású buffer tartalma kerül először kiküldésre 11 = legmagasabb prioritás 10 = közepesen magas 01 = közepesen alacsony 00 = legalacsonyabb prioritás Ha több buffer is azonos prioritással bír, akkor a nagyobb sorszámú buffer magasabb prioritást élvez.
TXRTSCTRL
9
BnRTS – A hozzárendelt láb állapotát jelzi, amennyiben bemenetként van konfigurálva, egyébként 0-t ad vissza BnRTSM – a lábakat vagy bemenetként konfigurálja, vagy buffer kiküldési kérelem jelzőként. Az üzenetek kiküldése a megfelelő TXnRTS láb lefutó élére történik.
9
EXIDE – kiterjesztett átvitt üzenet esetén 1- értéket kap
9
RXMn – A maszkok és szűrők működési módjait állítják be a következőképpen: 11 = maszk és szűrő is kikapcsolva, minden üzenetet veszünk,
9
TXBnSIDL
RXBnCTRL
9
- 70 -
ReD-CAN
Mellékletek 9 9 9 9
9
10 = szűrjük a kiterjesztett üzeneteket, a standard üzeneteket eldobjuk, 01 = szűrjük a standard üzeneteket, a kiterjesztetteket eldobjuk, 00 = mindkét üzenettípust szűrjük. BUKT – 1 értéke esetén a 0-s bufferbe értkező üzeneteket átirányítja az 1-es bufferbe, amennyiben a 0-s tele van, az egyes pedig üres FILHITn – Jelzi, hogy melyik szűrő illeszkedett a legutóbbi üzenetre
BFPCTRL
9 9 9
BnBSF – beállítja a láb állapotát, amennyiben a láb engedélyezve van, és kimenetként van konfigurálva BnBFE – engedélyezi/letiltja a lábat BnBFM – a lábak kimenetként, vagy Rx buffer megszakításként definiálja
RXBnSIDL
9 9
SRR – jelez, ha egy standard típusú üzenet érkezett IDE – ha 1, akkor jelzi, hogy a fogadott üzenet extended típusú
9
RTR – jelzi, ha standard típusú üzenet érkezett
9
EXIDE – meghatározza, hogy a szűrő kiterjesztett, vagy standard típusú üzenetre érvényes
RXBnDLC
RXFnSIDL
CNF1, CNF2, CNF3
9
9
SJW<1:0> - beállítja az SJW (Synchronisation Jump Width) értékét. Az SJW azt határozza meg, hogy a TQ időintervallum hányszorosával növeljük meg a bit time- értékét üzenetfogadás közben az újraszinkronizáció miatt BRP<5:0> - a TQ időintervallum hosszát adja meg. 2-128*TOSC értéket vehet fel TQ=2*(BRP+1)* TOSC
- 71 -
ReD-CAN
Mellékletek
9
9 9 9
9
9
BTLMODE – meghatározza, hogy a PS2 (Phase Segment 2) be van-e állítva a CNF3-ban található bitekkel, avagy a PS1 értékét, vagy az IPT (Information Processing Time) értékét kapja. SAM – a mintavételek számát (1-3) adja meg minden egyes biten belül PHSEG1<2:0> - beállítja a PS1 értékét 1-8 TQ értékre PRSEG1<2:0> - beállítja a Propagation Segment értékét 1-8 TQ értékre
WAKFIL – engedélyezi/letiltja a feléledési zajszűrőt. Ha engedélyezve van, akkor az 50ns-nál hamarabb érkező jeleket kiszűri, ha előzőleg az MCP Sleep – módban volt PHSEG<2:0> - beállítja a PS2 értékét 1-8 TQ értékre
CANINTE, CANINTF
9 9 9 9 9
MERRE/F – üzenet hiba megszakítás/flag: 1 értéket kap, ha az MCP egy üzenetet lát a buszon, vagy hibát érzékel WAKIE/F – jelzi, hogy az MCP visszatért a Sleep – módból ERRIE/F – jelzi, hogy egy, az EFLG regiszterben található flag beállításra került TXnIE/F – az üzenet sikeres átvitelét jelzi RxnIE/F – üzenet érkezését jelzi. Le KELL nullázni, hogy új üzenetet fogadhassunk
CANCTRL
9 9 9 9
REQOP<2:0> - lekéri az MCP működési módját ABAT – az összes függő kiküldési folyamat megszüntetését idézi elő. Le KELL nullázni, hogy új üzenetet küldhessünk CLKEN – engedélyezi/letiltje a CLKOUT lábat CLKPRE<1:0> - beállítja a CLKOUT skálázását FOSC/1, FOSC/2, FOSC/4 vagy FOSC/8 értékre
CANSTAT
- 72 -
ReD-CAN
Mellékletek 9 9
OPMOD<2:0> - az aktuális működési módot mutatja meg. ICOD<2:0> - a megszakítás kód jelzi a legmagasabb prioritású függő utasítást
- 73 -
ReD-CAN
Irodalomjegyzék
Irodalomjegyzék Forrás 1. PID Kájel Endre, Füle Sándor: CAN buszról alapfokon http://www.pid.hu/oskola/cansuli1/index.html http://www.pid.hu/oskola/cansuli2/index.html http://www.pid.hu/oskola/cansuli3/index.html 2003. szeptember 4. Forrás 2. BME PROFIBUS http://www.fsz.bme.hu/traficc/can/can.html 2004. március 1. Forrás 3. TeleComputer TeleComputer http://www.net.hu/telecomputer/4_03/1_1.htm 1999 február 22. Forrás 4. e-Times Dr. Bartolits István: GPRS alapfogalmak http://www.modemido.hu/01apr./kisszot.htm 2004. március 1. Forrás 5. Garmin Garmin: What is GPS? http://www.garmin.com/aboutGPS/ 2004. március 7. Forrás 6. Mindentudás Egyeteme Pap László: A technika új csodája: a globális helymeghatározás http://www.origo.hu/mindentudasegyeteme/pap/20030623paplaszlo41.html 2003. június 24. Forrás 7. Cason Rt. Cason Rt.: HiROT http://www.cason.hu/hirot/index.htm 2004. március 1. Forrás 8. NavSky Nova New Duett Kft.: NavSky Nova – Internetes gépjármű logisztikai szolgáltatás http://www.gpslap.hu/flotta/navsky/flotta.html 2004. március 7. Forrás 9. NavCenter New Duett Kft.: NavCenter – Műholdas flottakövetés, http://www.gpslap.hu/flotta/navcenter/navcenter.html, - 74 -
ReD-CAN
Irodalomjegyzék
2004. március 7. Forrás 10. Magyar Rádió Online Magyar Rádió Online: Röpül a Fabia, http://www.radio.hu/index.php?cikk_id=52714&rid=MUlUTQ==, 2003. szeptember 8. Forrás 11. Totalcar Posztós János: Intelligens lámpák, http://totalcar.hu/szamitastech/lampak/, 2001. május 2. Forrás 12. SDK-Tech Kft. SDKTech Kft: Autó riasztó – CAN adat busz illesztő, http://www.sdktech.com/mernok/canalarm.html, 2004. március.14. Forrás 13. Móra György Móra György: Perifériák, http://www.ank.sulinet.hu/tantargy/szamtech/hardver/cikkek/periferi/periferi.htm, 2004. augusztus. 10. Forrás 14. SAE Peter Buechring (Philips Semiconductors): CAN Controller Architecture Optimized for SAE-J1939 Applications, 1994. március 3. Forrás 15. CANOpen A2V: CANOpen Protocole, http://www.a2v.fr/program/canopen.htm, 2004. április 4. Forrás 16. Atmel Atmel: ATMega 128 8-bit AVR Microcontroller with 128K Bytes In-System Programmable Flash http://www.atmel.com/dyn/resources/prod_documents/doc2467.pdf 2004. Forrás 17. Microchip Microchip: MCP2515 Stand-Alone CAN Controller With SPI™ Interface http://ww1.microchip.com/downloads/en/DeviceDoc/21801b.pdf 2003. Forrás 18. SVG J. David Eisenberg: SVG Kézikönyv (A méretezhető vektorgrafika készítése XML-lel) ISBN 963 09 4448 0 Kossuth Kiadó 2003. Forrás 19. FMS FMS-Standard Interface description Vers. 01.00 http://www.fms-standard.com/ Working Group FMS-Standard 2002.
- 75 -
