PANNON EGYETEM Mérnöki Kar JÁRMŰRENDSZERTECHNIKAI LABORATÓRIUM Autóipari kommunikációs protokollok a CAN dr. Fodor Dénes Veszprém, 2012.
Köszönetnyilvánítás TÁMOP-4.2.1/B-09/1/KONV-2010-0003 Mobilitás és környezet: Járműipari, energetikai és környezeti kutatások a Közép- és Nyugat-Dunántúli Régióban. A projekt a Magyar Állam és az Európai Unió támogatásával, az Európai Szociális Alap társfinanszírozásával valósul meg.
Tartalomjegyzék 1 Bevezetés... 1 1.1 Központosított szabályozó rendszer... 2 1.2 Elosztott szabályozó rendszer... 3 1.3 CAN kialakulását közvetlenül motiváló tényezők... 4 2 A CAN (Controller Area Network) protokoll... 6 2.1 A CAN általános jellemzői... 6 2.2 A CAN alkalmazási területei... 10 2.3 Szabványosítás... 10 2.4 A CAN protokoll felépítése az OSI modell szerint... 11 2.4.1 A CAN adatkapcsolati rétege... 12 2.4.2 A CAN fizikai rétege... 13 2.5 CAN Architektúra... 13 2.5.1 Puffer stratégiák... 13 2.5.2 Azonosító mező hossza... 15 2.5.3 Az integráltság foka... 16 2.6 Adatátvitel a CAN buszon - A fizikai réteg... 16 2.6.1 A fizikai réteg megvalósítása... 16 2.6.2 Bit reprezentáció... 20 2.6.3 Bitidőzítés... 21 2.7 CAN üzenet válaszideje... 23 2.7.1 Adott m üzenet legrosszabb eseti válaszidejének analízise... 23 2.7.2 Válaszidőt befolyásoló tényezők... 25 2.7.3 CAN válaszidő jitterének minimalizálása... 25 2.7.4 Arbitráció... 31 2.8 CAN Architektúra... 34 2.8.1 Puffer stratégiák... 34 2.8.2 Szinkronizáció... 36 2.8.3 Az él szinkronhibája (Phase Error of an edge)... 37 2.8.4 A szinkronizáció típusai... 37 2.8.5 Szinkronizálás szabályai... 40 2.8.6 Üzenetek késleltetése... 40 2.9 Adatátvitel a CAN buszon Az adatkapcsolati réteg... 41 2.9.1 CAN üzenetkeretek... 41 2.9.2 Adathordozó üzenet... 41
2.9.3 Adatkérő üzenet... 43 2.9.4 Hibaüzenet... 45 2.9.5 Túlcsordulás üzenet... 47 2.9.6 Üzenetek közötti mező... 47 2.10 Hibakezelés... 49 2.10.1 Üzenet jóváhagyás... 49 2.10.2 Hibafelismerés, hibakezelés... 50 2.10.3 Hiba felismerési képesség... 51 2.10.4 Hibaforrás megszüntetése... 52 3 Hardvereszközök bemutatása... 54 3.1 Softing CANcard2... 54 3.1.1 FIFO mód... 55 3.1.2 Dinamikus objektum-puffer mód... 56 3.1.3 Statikus objektum-puffer mód... 57 3.1.4 A FIFO és az objektum-puffer mód összehasonlítása... 58 3.2 SysTec USB-CAN modul [12]... 59 3.3 National Instruments PCI-CAN/XS2... 61 3.4 Philips SJA1000 CAN kontroller... 64
1 Bevezetés Az utóbbi években az ipari kommunikációs- és vezérlő hálózatok terén paradigmaváltás figyelhető meg. Napjainkra a mikrokontrollerek egyre hatékonyabbá és egyre olcsóbbá váltak, amely lehetővé tette, hogy a gyártók távoli I/O eszközökbe, nyomógombokba, szenzorokba és egyéb komponensekbe ágyazzák őket, olyan intelligens eszközöket létrehozva, amelyek önállóan is képesek a szabályozási feladatuk ellátására. Így a 70-es 80-as években domináló központosított szabályozó rendszerek (centralized control systems) helyett egyre inkább elterjedhettek az úgynevezett elosztott rendszerek (distributed control systems). A mai járművek többsége nagyszámú elektronikus vezérlő rendszert tartalmaz. A járműiparban az 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 anyagkibocsátás és üzemanyag fogyasztás csökkentése) köszönhető. Ilyen vezérlőeszközök lehetnek például a motorban, a sebességváltóban, a kormánynál valamint a blokkolásgátló 1 és menet-stabilizátor 2 rendszerben. A kényelmet szolgáló eszközöknél pedig a klímánál és az audiorendszernél. Ezen rendszerek funkcióinak bonyolultsága elkerülhetetlenné teszi a rendszerek elemei közötti adatcserét. 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 volt növelhető. Egyre több olyan rendszert is kifejlesztettek a gépjárművek számára, amelyek több vezérlőeszköz együttműködését igényelték. (Motor vezérlése, menetstabilizátor, automata sebességváltó, műszerfal-gombok.) Ezért szükségessé vált a hagyományos pont-pont összekötésének lecserélése, amit úgy oldottak meg, hogy a rendszer elemeit egy soros buszrendszerre kötötték rá 3. Az addig használt soros buszrendszereknek viszont túl kicsi volt az átviteli sebességük vagy a kommunikációs hibákat nem kezelték megfelelően. Mivel az autóipar számára nem volt megfelelő buszrendszer, ezért fejlesztette ki a Bosch a Controller Area Network -öt, amit szabványosítottak 1991-ben 4. A korszerű gépkocsikba egyre nagyobb mennyiségű elektronikát építenek be és az eszközök száma folyamatosan növekszik. Már kaphatók olyan gépjárművek, melyekben a kormánykerék áttétele a sebesség függvényében változik, vagy amelyben a kézifék elektronikusan működik. Már létezik olyan egység is szériaautókba, melynek segítségével az autó saját maga be tud parkolni egy adott parkolóhelyre. Jelenleg a CAN busz terheltsége néhány autótípusnál akkora, hogy szükséges lett 2 CAN buszt alkalmazni a gépjárművön belül! A kocsikba kerülő új eszközök kifejlesztése és javítása egyaránt bonyolult feladat, mivel a berendezések egymással logikai kapcsolatban vannak, és felhasználják egymás adatait. Ahhoz, hogy egy új terméket ki lehessen fejleszteni, 1 ABS 2 ESP 3 Így minden eszköz megkapja azt az információt, amit valamelyik eszköz elküld. 4 ISO 11898 1
egy olyan tesztrendszerre is szükség van, amely képes arra, hogy a kifejlesztendő termék számára a bemeneti adatokat biztosítsa valamint képes az érkező adatok feldolgozására és ellenőrzésére. Ez az igény a CAN busz analizátorok területén is óriási fejlesztéseket generált az elmúlt években. 1.1 Központosított szabályozó rendszer 1-1. ábra: Centralizált szabályozási rendszer A rendszert alkotó egységek hagyományos módon egy központi vezérlő egységhez csatlakoznak, amelynek feladata az egész rendszer koordinálása (1-1. ábra). A központi vezérlő (master) ciklikusan lekérdezi a többi eszköz (slave-ek) üzeneteit. Így bár determinisztikus, hogy egy eszköznek maximum mennyit kell várnia a buszra, az ilyen modell több jelentős hátránnyal is bír. A különböző egységek más-más típusú csatlakozókkal rendelkeznek, így nagyszámú vezeték szükséges a központhoz kapcsolásukhoz. Ez azért is hátrányos, mert a rendszer komplexitásának növekedésével a huzalok száma és a csatlakozók mérete is növekszik. Az ilyen master-slave rendszerben keletkező hibák felderítése bonyolult és a központi egység leállásával a teljes rendszer működésképtelenné válik. Új eszközök hozzáadásakor újabb problémák merülhetnek fel, például egy speciális csatlakozóval rendelkező egység integrálása egy már létező rendszerbe költség és munkaigényes feladat. 2
1.2 Elosztott szabályozó rendszer Az említett hátrányos tulajdonságok leküzdésére egyre szélesebb körben alkalmazzák az iparban az úgynevezett terepbuszokat (fieldbus). Ezek olyan soros adatkommunikációs rendszerek, amelyek a tereptartományban (field domain) történő adatcserére szolgálnak. Ez a tartomány az automatizált rendszer eszközszintjének reprezentálása, amely azoknak az eszközöknek és berendezéseknek, valamint összeköttetéseiknek leírásából áll, amelyek térben közel vannak, vagy közvetlenül összeköttetésben állnak az aktuális monitorizálni vagy irányítani kívánt technológiai folyamattal. 1-2. ábra: Elosztott szabályozási rendszer Az ilyen rendszerek alapelve, hogy egy közös kommunikációs vonalra (buszra) kötik az összes egységet. Az ily módon egy hálózatba kapcsolt egységek immár önállóan kommunikálnak egymással. A hálózat használata új szabályozási koncepciót eredményezett, az úgynevezett elosztott szabályozást (Hiba! A ivatkozási forrás nem található.). Elosztott rendszereknél mindössze egy vezeték kötegre van szükség, amely gyakran már az energia ellátását is biztosítja a részegységeknek, ezzel is csökkentve a fizikai csatlakozók számát. A kevesebb vezeték nemcsak megbízhatóbbá teszi a rendszert, de egyszerűbbé és főként olcsóbbá is. Ezzel a megoldással lehetővé válik a rendszer folyamatos bővítése, mivel csupán egyfajta, szabványosított csatlakozóra van szükség, így lehetséges akár különböző gyártók eszközeinek közös rendszerbe integrálása is. 3
1.3 CAN kialakulását közvetlenül motiváló tényezők Az autóiparban történő biztonsági rendszerek valamint kényelmi berendezések fejlesztésére, gazdaságosabb üzemanyag-felhasználásra és a károsanyagkibocsátás csökkentésére irányuló folyamatos kutatások, fejlesztések következtében a járművekbe egyre több elektronikai eszközt építenek. A vezérlőeszközök számának növekedésével összhangban egyre nő a köztük történő információcsere intenzitása. A SAE 5 ajánlására az autóipari alkalmazásokat a következő osztályokba sorolták: A osztályú alkalmazások: a karosszéria-elektronika olyan kevésbé intelligens eszközeinek kommunikációja, mint pl. kapcsolók, fényszórók, tükörbeállítás, ülés pozicionálás, elektromos ablakemelő, központi zár stb. Az átviendő üzenetek ebben az esetben általában igen rövidek, a ciklusidejük pedig hosszú, így az ilyen információk sávszélesség-igénye alacsony, általában 10 kbit/s alatti. A vezetékezés is egyszerű: pl. egy szál a jelnek, egy a földelésnek, így a csomópontok összekötésének költsége kicsiny. B osztályú alkalmazások: magasabb szintű információk cseréjére szolgálnak, pl. információátvitel a műszerfal, vagy a légkondicionáló vezérlése felé. 40 kbit/s-os átviteli sebesség a felső határ. C osztályú alkalmazások: valós idejű (real time critical) információátvitel, 1-10 ms-os ciklusidővel, és 1 ms-nál rövidebb késleltetéssel. Az üzenetek általában 1 vagy néhány Byte-osak. A sávszélesség-igény 1 Mbit/s. Alkalmazási területek lehetnek pl. a motorvezérlés, váltómű, menetstabilizáló rendszer kommunikációja. D osztályú alkalmazások: ebben az esetben nagyobb mennyiségű adat továbbítására van szükség, az adatblokkok mérete elérheti a néhány kbyte-ot is, mint pl. az audio rendszer, telefon vagy GPS 6 kommunikációja során. Ez esetben általában csak néhány csomópont van összeköttetésben egymással, és információcserére csak viszonylag ritkán van szükség. Az igényelt sávszélesség 1 Mbit/s és 10 Mbit/s között mozog. Az ISO 7 ennél egyszerűbb és gyakorlatiasabb osztályozása: Alacsony sebességű kommunikáció: 125 kbit/s alatt. Nagysebességű kommunikáció: 125 kbit/s felett. A 80-as évek elején a Bosch mérnökei megvizsgálták a létező soros buszrendszereket a személyautókban történő felhasználhatóságuk szempontjából. Mivel az akkor használatos hálózati protokollok közül egyet sem találtak megfelelőnek erre a célra, 1983-ban új soros buszrendszer fejlesztésébe fogtak. Elsődleges céljuk a vezetékezési problémák megoldása mellett új 5 Society of Automotive Engineers 6 Global Positioning System, globális helymeghatározó rendszer 7 International Standardisation Organisation, Nemzetközi Szabványügyi Hivatal 4
funkcionalitások bevezetése volt. 1986-ra megszületett a CAN (Controller Area Network) 8. Zsoké = felhasználói alkalmazás Nyereg = átviteli protokoll Ló = CAN busz Út = átviteli közeg, buszvezetékek 1-3. ábra: CAN (Controller Area Network) szemléltetése 8 1986-ban a detroiti SAE kongresszuson Automotive Serial Controller Area Network (CAN) néven mutatták be először. 5
2 A CAN (Controller Area Network) protokoll 2.1 A CAN általános jellemzői A CAN olyan ún. multi-master protokoll, amelyben a csomópontok (node) üzenetkeretek (message frame) segítségével kommunikálnak egymással. Az üzenetkeret tartalmazza többek között az üzenet azonosítóját (message identifier) és az adatmezőket (data field). A protokoll főbb tulajdonságai: Multimaster Nincs kiválasztott busz-vezérlő (bus master), minden csomópont teljesen egyenrangú, képes az üzeneteit önállóan, bármely másik csomópont segítsége nélkül továbbítani az adatbuszon (data bus), ha az felszabadult. Egy csomópont leállása esetén az egész rendszer nem válik működésképtelenné, csak a teljesítőképessége csökken. Üzenetközpontú Az üzenetek azonosítása nem a küldő vagy a fogadó csomópont címe alapján történik (mint általában a többi buszrendszernél), hanem egyedi azonosító (identifier) alapján, amit a hordozott információ fontossága szerint kapnak. Az üzenetazonosító határozza meg tehát az adott üzenet prioritását, valamint közvetlenül szerepet játszik a buszért való versengés eldöntésében is. Nem-destruktív arbitrációs mechanizmus (non-destructive arbitration) A CAN ún. prioritásos CSMA/CD+CR 9 médiaelérési technikát használ. Az adatbuszt elérni kívánó csomópontok várnak a busz felszabadulásáig, majd megkezdik a kommunikációt a kezdő bit (start bit) átvitelével, amely szinkronizálja az összes kommunikációs partnert. Ezután történik az üzenetazonosító továbbítása. Több partner egyidejű adási szándéka esetén ebben a szakaszban történik az ütközés feloldása, bitszintű arbitrációval. Ezt a technikát nem-destruktív arbitrációs mechanizmusnak (non-destructive arbitration) nevezzük, mivel a vesztes csomópont úgy mond le buszigényéról, hogy amiatt az átvitt magasabb prioritású üzenet nem sérül. Ez annyit jelent, hogy mindennemű késleltetés nélkül a legmagasabb prioritású üzenet továbbítódik a buszon. Broadcast A buszon továbbított üzeneteket mindig minden csomópont megkapja (broadcast), és ellenőrzi. A csomópontok az üzenetek azonosítója alapján döntik el, hogy pufferelik-e azt későbbi kiértékelés céljából vagy figyelmen kívül hagyják. Az üzenetszűrőt (message filtering) a felhasználói alkalmazás állítja be. 9 Vivőjel érzékeléses többszörös hozzáférés ütközésérzékeléssel, (Carrier Sense, Multiple Access/Collision Detection + Collision Resolution) 6
Eseményvezérelt A kommunikáció adott esemény bekövetkezésének (új információ generálódott egy csomópontban) hatására kezdődik el. Az új üzenettel rendelkező csomópont maga kezdi meg az átvitelt. Így jelentős kommunikációs időt takarít meg pl. azokhoz a rendszerekhez képest, amelyekben a csomópontok minden ciklusban adott időszelettel rendelkeznek, amelyben az új információjukat elküldhetik. Ugyanis ez esetben, ha nincs új információja egy csomópontnak, akkor ez az időszelet kárba vész, míg esetlegesen egy másik, új információval rendelkező eszköznek várnia kell, amíg sorra kerül. Lehetőség van ciklikus információcserére is, ekkor belső óra vagy egy másik (master) csomópont kezdeményezi a kommunikációt. Távoli válaszkérés Az eseményvezérelt kommunikációt kiegészítve a CAN lehetőséget biztosít ún. távoli válaszkérő üzenetek küldésére. Ezek segítségével egy fogadó csomópont kérheti a számára szükséges információ elküldését a megfelelő küldő csomóponttól. A kérés és a válasz külön üzenetet képez. Főleg a csomópontok állapotának (aktív/inaktív) lekérdezésére használják ezt a technikát. Flexibilis A csomópontokat dinamikusan rákapcsolhatjuk, illetve leválaszthatjuk a buszról anélkül, hogy a többi csomópont kommunikációját zavarnánk, így a rendszer rugalmasan alakítható. A rendszertervezésben is nagy szabadsági fokot nyújt: Csomópontok száma egy rendszeren belül: 32 csomópont lehet egy rendszerben szabványos buszmeghajtók esetén, 64-128 darab lehet alkalmazás-specifikus meghajtók esetén. Üzenetek száma a rendszerben: standard üzenetformátum esetén 2 11 (=2 048), kiterjesztett üzenetformátum esetén 2 29 (=536 870 912) darab különböző üzenet lehetséges. Adatmennyiség üzenetenként: 0-8 Byte. Ezek a rövid üzenetek elegendőek a járművekben valamint beágyazott illetve automatizált gyártó rendszerekben történő kommunikációra, és egyben garantálják a lehető legrövidebb buszelérési időt a nagy prioritású üzenetek számára, valamint erős zavarású közegben történő kommunikáció esetén a zavaró jellel való összeütközés kisebb valószínűségét. Maximális üzenethossz: beszúrt bitekkel együtt 117 bit standard üzenetformátum esetén, 136 bit kiterjesztett üzenetformátum esetén. Bitráta: 5 kbit/s és 1 Mbit/s között programozható (a buszhossztól függően). Gyors Az adattovábbítás maximális sebessége 1000kbit/s (40m-es buszhossznál), az üzenetek rövidek, a késleltetési idő maximálva van, az arbitráció (2.7.4. fejezet) pedig gyors. Az utóbbi tulajdonságok alkalmassá teszik a CAN rendszert a valós idejű események (pl.: ABS, motorvezérlés) irányítására. 7
Olcsó A protokoll alacsony költséggel implementálható. A kivitelezéshez szükséges eszközökre nagy igény van az ipar különböző területein, ezért a sorozatgyártás alacsony árat és kedvező teljesítmény-ár viszonyt eredményez. A csavart érpár, amelyet a CAN rendszereknél a leggyakrabban használnak, szintén olcsó, mert ez az egyik leggyakoribb buszfajta. A rendszer üzemeltetési költségének csökkentése érdekében a csomópontok átállhatnak ún. alvó üzemmódba (sleep mode), amely azt jelenti, hogy belső aktivitásuk megszűnik és lekapcsolják a buszmeghajtókat, ezáltal csökkentve a rendszer áramfogyasztását. Az alvó üzemmódot követi az ún. ébredési fázis (wake-up), aminek következtében a belső aktivitás újraindul. A rendszernek lehetősége van arra, hogy egy speciális azonosítóval rendelkező üzenet elküldésével aktiváljon egy csomópontot. Robusztus Kifinomult hibadetektáló és hibakezelő mechanizmusokkal rendelkezik, mint például a 15 bites, 6-os Hamming-távolságú CRC (cyclic redundancy check), amely 5 hibás bit felismerését teszi lehetővé üzenetenként; a nem rendszeres hibák helyreállítása a hibás üzenetek automatikus újraküldésével; az ismétlődő hibák kiküszöbölése a hibás csomópont kikapcsolásával, ami determinisztikussá teszi a rendszer esetleges hibák utáni helyreállásának idejét. Az elektromágneses interferenciákra alacsony az érzékenysége. A rendszer garantálja, hogy a küldő-csomópont által elküldött adatok megegyeznek a fogadó-csomópontok által fogadott adatokkal. Átlagos terhelés mellett statisztikailag 1000 év alatt egy olyan hiba fordul elő, amelyet a rendszer nem észlel. Hiba detektálás a kommunikációs médium szintjén A CAN vezérlők sok fajta vezetékhibát ismernek, és definiálnak: szakadás, testzárlat, egyéb zárlatok. A protokoll nem írja le, hogy mi a teendő a fenti hibák esetén, de az újabb CAN vezérlőkben legalább a fenti esetek egyikének kezelése implementálva van. Nyugtázás Az üzenetek globális nyugtázó mezővel (2.9.2. fejezet) rendelkeznek, amely jelzi a küldő csomópontnak, hogy legalább egy kommunikációs partnerhez hibátlanul megérkezett az üzenet. Így a küldő információt kap arról, hogy még a buszhoz van-e csatlakoztatva, vagy sem. A broadcast-jellegű üzenettovábbítás következtében minden csomópont nyugtázó jellel válaszol, ha nem észleltek hibát. Teljes rendszerre nézve konzisztens üzenetátvitel A rendszer garantálja, hogy minden egyes elküldött üzenetet vagy minden csomópont elfogad, vagy minden csomópont elutasít. Ha legalább egy vevő hibát észlel a fogadás során, akkor egy speciális hibajelző üzenettel (error frame) (2.9.4 fejezet) rögtön megszakítja az átvitelt, és jelzi a többi fogadó állomásnak, hogy hagyják figyelmen kívül az üzenetet, a küldőnek pedig, hogy küldje el ismét azt. Ez eredményezi a teljes üzenet-konzisztenciát a 8
rendszerben, azaz vagy minden egyes csomópont megkapja ugyanazt az információt ugyanabban az időpillanatban, vagy egyik sem. Ez az elosztott rendszerekben igen fontos tulajdonság, mivel így garantálható, hogy a különböző mikrokontrollerek ne dolgozzanak ugyanahhoz a változóhoz tartozó eltérő adatokon egy időben. Bitkódolás A bitfolyam kódolása a nullára vissza nem térő (Non-Return-to-Zero) elv szerint történik: a teljes bit idő alatt a generált bitszint vagy domináns, vagy recesszív lehet (2.6.2 fejezet). Ez tömörebb adatátvitelt tesz lehetővé, mint más kódolási technikák, viszont állandó újraszinkronizálásra van szükség, mivel a bitfolyamból nem vezethető vissza szinkronizációs információ. Ezért is vezették be a bitbeszúrás módszerét. Bit szinkronizáció A kommunikáló csomópontok szinkronizálásához a bitbeszúrás módszerét használja a CAN (2-11. ábra). Az üzenet keretekben az üzenet vége és az üzenetek közötti mező kivételével öt egymást követő azonos értékű bit után egy ellentéteset szúr be a küldő. Így létrehoz egy le- vagy felfutó élet a bitidő generátor újraszinkronizálásához. A bitfolyam értelmezéséhez a fogadónak természetesen ki kell szedni a beszúrt biteket. Csomópontok közötti szinkronizáció Üzenetek sikeres küldése és fogadása után az összes résztvevő csomópontban egy megszakítás generálódik, amit fel lehet használni az elosztott vezérlőrendszer óráinak beállításához. Az órák szinkronizáltsága elengedhetetlen feltétele az elosztott valós idejű alkalmazások működésének. Ezt a szinkronizációs módszert a CAN a kommunikációs technikáján keresztül biztosítja. Bitráta/busz-hossz viszony A kommunikációs vonalakon terjedő jelek sebességére vonatkozó fizikai korlátok miatt (réz vezetékben az elektromos hullám terjedési ideje megközelítőleg 20 cm/ns), valamint a CAN bitszintű arbitrációja miatt ahogy a busz hossza nő, úgy csökken a megengedett maximális átviteli sebesség. Az idő, amíg egy csomópont által elküldött bit eljut a legtávolabbi csomóponthoz, majd vissza, nem lehet hosszabb, mint a küldő csomópont bitidejének 2/3 része. A maradék 1/3-nyi bitidő elegendő arra, hogy minden csomópont eldöntse, hogy elveszítette-e a busz használatának jogát, vagy folytathatja-e a küldést. Az arányok [1] alapján a következők: 40 m-es buszhossz esetén 1Mbit/s, 400 m-es buszhossz esetén 100 kbit/s, 1000m-es buszhossz esetén 40 kbit/s [1] Buszmeghajtó áramkörök jellemzői A CAN különböző módszereket biztosít a busz meghajtására: 9
Differenciális mód (NRZ-vel). Két jel- és egy földvezeték (illetve referencia vezeték) szükséges. A logikai bitszintet a két vezetéken lévő jelek különbségéből határozza meg. Elektromos zavarások ellen védett. Kiegyensúlyozatlan mód (NRZ-vel). Egy föld- és egy jelvezeték. Nagyon érzékeny a zajokra, csak erősen költségérzékeny alkalmazásokban alkalmazzák alacsony sebességen, vagy a már említett vezetékhibák ideiglenes áthidalására. Közvetlen kapcsolat nélküli kommunikáció csatolt transzformátorokkal megvalósított kommunikáció esetén Széles eszközválaszték Manapság a legtöbb mikrokontroller gyártó (a legnevesebbek pl. Intel, Motorola, Siemens, Philips) kínálatában megtalálhatók CAN chipek is, amelyek a nagy választék és az árverseny miatt meglehetősen olcsón beszerezhetők, és így gyorsan elterjednek. 2.2 A CAN alkalmazási területei A fentieket összefoglalva tehát megállapíthatjuk, hogy a CAN olcsó, megbízható, valós idejű rendszerekben is alkalmazható, flexibilis protokoll. Ezen igen előnyös tulajdonságokat figyelembe véve érthető, hogyan válhatott az autóipari és az ipari automatizálási alkalmazások területén napjaink vezető protokolljává, amely egyre újabb és újabb területeket hódít meg, mint például orvosi elektronika, háztartási eszközök, épületautomatizálás, vasúti rendszerek, hajózás, mezőgazdasági gépek, repülőgép-elektronika, PLC 10, robotvezérlés, intelligens motorvezérlés, valamint űrtechnológia. 1999-ban 50 millió új CAN csomópontot helyeztek üzembe világszerte, a 2002-es évben ez a szám meghaladta a 200 milliót. A globális elterjedéshez és használhatósághoz, a kompatibilitási problémák elkerüléséhez azonban szükség volt a protokoll szabványosítására. 2.3 Szabványosítás Három évvel az első CAN vezérlő chip-ek megjelenése 11 után, 1990-ben, a Bosch féle CAN specifikációt nemzetközi szabványosításra nyújtották be. A különböző megoldások egységesítéséhez, valamint a CAN további technikai fejlődésének biztosításához szükség volt egy felhasználókból és gyártókból álló semleges platformra. 1992 márciusában hivatalosan is megalakult a CAN in Automation (CiA) nemzetközi felhasználói és gyártói csoport. A CiA munkája során leszűkítette a legalsó OSI réteg specifikációját vezeték, csatlakozó és transceiver ajánlásra, kidolgozta a CAL 12 -t, amely az OSI modellhez képest a CAN-ből addig hiányzó alkalmazási réteget pótolja. Később olyan további CAN alkalmazási rétegek kidolgozásával foglalkoztak, mint a SDS 13, DeviceNet stb. 10 Programozható logikai vezérlők (Programmable Logic Controllers) 11 1987: Intel 82526, nem sokkal később: Philips 82C200 12 CAN Application Layer (CAN alkalmazási réteg) 13 Smart Distributed System 10
1993-ra megjelent az ISO 14 11898-as CAN szabvány, amely a protokoll 11 bites azonosítójú, standard formátumú üzenetein túl a fizikai réteget is definiálja, 1 Mbit/s-os átviteli sebességig. Az üzenetek fajtáinak növekedésével szükségessé vált a 29 bites azonosítójú, kiterjesztett formátumú üzenetek (2.9. fejezet) specifikálása, amelyet az ISO 11898 kiegészítéseként rögzítettek 1995-ben. Így a 2.0-ás specifikáció az alábbi két fő fejezetből és egy függelékből áll: CAN 2.0 A fejezet (Part A): a standard formátumú üzeneteket definiálja (CAN Specification 1.2 alapján) CAN 2.0 B fejezet (Part B): a standard és a kiterjesztett formátumú üzeneteket specifikálja CAN 2.0 Függelék: útmutatást ad arra vonatkozóan, hogyan valósítsuk meg a CAN protokollt, hogy megfeleljen a szabvány A vagy B fejezetében leírtaknak. Átdolgozott CAN specifikációk szabványosítása napjainkban is folyik: ISO 11898-1: a CAN adatkapcsolati rétegét írja le, ISO 11898-2: a CAN nagysebességű fizikai réteget definiálja, ISO 11898-3: a CAN alacsony sebességű, hibatűrő fizikai rétegét rögzíti. 2.4 A CAN protokoll felépítése az OSI modell szerint Napjaink protokolljai leggyakrabban az ISO/OSI 15 kommunikációs modell alapján épülnek fel. Ezt a modellt az ISO dolgozta ki a nyílt kommunikációs protokollok kifejlesztésének támogatására. Erre hagyatkozva azóta több nemzetközi szabványt is elfogadtak, amelyek megalapozzák a nyílt kommunikációt irodai és ipari területeken egyaránt. Az adatcserét az OSI referencia modell alapján egymásra épülő rétegek (layer) valósítják meg. Minden réteg a lejjebb elhelyezkedő réteg szolgálatait felhasználva szolgáltatásokat nyújt a felette lévő rétegnek. A valóságban a kommunikáció függőlegesen, logikailag viszont vízszintesen történik. Minden réteg a társ entitásával kommunikál, azaz a távoli rendszer azonos magasságban elhelyezkedő rétegével. Ezt az elküldeni kívánt adat megfelelő becsomagolásával (megfelelő kerettel látja el azt) és lejjebb küldésével teszi meg, egészen a fizikai rétegig. A fogadó rétegek felfelé továbbítják az adatot, minden szinten kicsomagolva azt. Ezzel az elgondolással a rétegek tisztán elkülöníthetőek egymástól feladataik alapján. Minden réteg csak a közvetlen alsó és felső szomszédait ismeri és továbbítja azok üzeneteit módosítás és feldolgozás nélkül. Az OSI referencia modell hét réteget definiál: 1. Alkalmazói 2. Megjelenítési 3. Viszony (együttműködési) 4. Szállítási (átviteli) 5. Hálózati 6. Adatkapcsolati 14 Nemzetközi Szabványügyi Hivatal (International Standardisation Organisation) 15 Open Systems Interconnections 11
7. Fizikai A cél egy általánosan használható referencia megteremtése volt, így természetesen nincs szükség minden rétegre bizonyos rendszerekben. Például kapcsolat felépítésre, és forgalom-irányításra az ipari automatizálásban, vagy az autóiparban. A CAN az ISO/OSI modell szerint 3 különböző rétegre osztható fel, a tervezés átláthatósága valamint a megvalósítás hatékonysága és rugalmassága érdekében (Hiba! A hivatkozási forrás nem található.). Alkalmazási réteg /Application layer/ Adat objektumok Alkalmazási réteg /Application layer/ Adatkapcsolati réteg /Data link layer/ Logikai kapcsolatvezérlés /Logical Link Control/ Azonosító+Adat Adatkapcsolati réteg /Data link layer/ Logikai kapcsolatvezérlés /Logical Link Control/ Közeghozzáférés vezérlés /Medium Access Control/ Közeghozzáférés vezérlés /Medium Access Control/ Fizikai réteg /Physical layer/ Recesszív Domináns CAN busz Fizikai réteg /Physical layer/ 2-1. ábra: A CAN protokoll felépítése A CAN protokoll a fizikai (2.4.2. fejezet) és az adatkapcsolati réteget (2.4.1. fejezet) definiálja, amelyet kiegészíthetnek magasabb szintű protokollok. Ezeket az alkalmazási réteg írja le, amelyhez az adatkapcsolati réteg jelenti az interfészt. Ilyen magasabb rendű protokollok: CANOpen Device Net Smart Distributed Systems (SDS) J1939 CAN Application Layer (CAL) CANKingdom OSEK/VDX 2.4.1 A CAN adatkapcsolati rétege A CAN adatkapcsolati rétege (Hiba! A hivatkozási forrás nem található.) a 2.0- s specifikáció B része alapján két alrétegre bontható: Logikai kapcsolatvezérlés (Logical Link Control) Közeghozzáférés vezérlés (Medium Access Control) 12
A logikai kapcsolatvezérlés (más néven objektum alréteg) feladata a busz felől kapott üzenetek szűrése (message filtering), azaz definiált feltételek alapján eldönti, melyeket fogadja el, és melyeket kell elvetnie. Ez a réteg jelzi a túlcsordulást (overload notification) és kezeli a hibaállapotok felismerését, valamint a helyes működés visszaállítását A közeg hozzáférési (más néven átviteli) alréteg alkotja a CAN protokoll magját. Ez a réteg végzi el a megfelelő keretek alkotását, vezérli az arbitrációt, felismeri és jelzi a hibákat. Az ún. hiba elszigetelő entitás (Fault Confinement) felügyeli az átviteli alréteg működését, ennek segítségével lehetséges az állandó meghibásodások megkülönböztetése az egyedi, ritkán fellépő hibáktól. 2.4.2 A CAN fizikai rétege A fizikai réteg felelős a csomópontok közötti tényleges jeltovábbításért. A digitális jelek analóggá (és vissza) alakításán kívül ez a réteg végzi a busz paramétereinek megfelelő bitidőzítést és szinkronizálást. A CAN szabvány nem tesz kikötést a fizikai médium típusára, de jelenleg a csavart érpáron történő adatátvitel a legelterjedtebb, amit az ISO 11898 definiál. A maximális bitráta 1 Mbit/s (megfelelően hosszú vezeték esetén). A fizikai rétegnek az egész hálózaton belül azonosnak kell lennie. 2.5 CAN Architektúra Amint már említettük, sokféle gyártó sokféleképpen implementálja a CAN protokollt. A különböző protokollvezérlő megvalósításokat a következő szempontok szerint lehet osztályozni: az alkalmazott puffer stratégia alapján: BasicCAN, FullCAN az üzenetazonosítók hossza alapján: Standard CAN, Extended CAN a CAN integráltsága alapján: Stand Alone CAN, Integrated CAN A BasicCAN és a FullCAN között a különbséget az üzenetek pufferbe írás előtti szűrése jelenti. A szűrés kizárólag az üzenetek azonosító mezője alapján történik. A puffer interfészként szolgál a fogadott üzenetet elérni kívánó folyamat számára. Ezen megfontolások alapján a mai implementációk az üzenet pufferek számában különböznek, habár az újabb FullCAN megvalósítások egyben képesek BasicCAN módban is működni. 2.5.1 Puffer stratégiák A BasicCAN architektúra A BasicCAN felépítésű interfész egyfajta asszociatív memória-szűrőként működik. Egy elfogadási mintából és egy elfogadási maszkból áll (Hiba! A ivatkozási forrás nem található.). A felhasználó állítja be ezeket a BasicCAN interfész konfigurálása során. Ezek után az összes üzenet azonosítóját összehasonlítja a CAN vezérlő a mintával, és figyelmen kívül hagyja a maszk által kiszűrt biteket.(hiba! A hivatkozási forrás nem található.). A eállításoknak megfelelő üzeneteket a fogadó puffer ún. fogadási azonosító/adat regiszterébe rakja, ahol a mikrokontroller azonnal elérheti. A BasicCAN 13
leggyakoribb implementációja a FIFO 16 szervezés, mivel több üzenet is megfelelhet a maszknak és várhat köztes tárolásra a feldolgozás előtt. Elfogadási minta 1 0 0 1 1 0 0 0 1 1 1 0 0 1 Elfogadási maszk 0 0 0 0 1 1 1 0 0 0 1 1 1 1 Üzenet 1 1 0 0 1 x x x 0 1 1 x x x x elfogadva Üzenet 2 1 0 0 0 x x x 0 1 1 x x x x Üzenet3 1 1 0 1 x x x 1 1 1 x x x x kiszűrve kiszűrve X lehet 0 vagy 1 Összehasonlított bitek Nem összehasonlított bitek Összehasonlított bitek Nem összehasonlított bitek 2-2. ábra: Az üzenetek szűrése Minden üzenet elfogadásakor a puffer-vezérlő egy megszakítással figyelmezteti a mikrokontrollert az új információ feldolgozására. Ha a mikrokontroller túl lassú, túlcsordulás következhet be a fogadó pufferben, ez figyelmeztető jelzést generál. A BasicCAN sajátossága, hogy a fogadó puffer tartalmán a kiolvasás után a mikrokontroller még utólagos szűrést végez, hiszen a maszk-minta páros nem határozza meg egyértelműen az elfogadandó üzeneteket. Ezt megteheti, mert a pufferben az adatok az azonosítójukkal együtt tárolódnak, így egy hardverszűrővel és az utólagos szűréssel tetszőleges számú virtuális fogadó puffer valósítható meg. Ez minimalizálja a hardver komplexitását. Küldéskor csak egy puffert használ a BasicCAN. Ebbe írja bele az elküldendő adatokat, mielőtt ténylegesen elindítaná a küldési folyamatot. Az adatkérő üzenetre történő adathordozó üzenet elküldését is a központi egységnek kell kezelnie, így magas bitsebesség esetén nagyon leterhelt, ezért a BasicCAN vezérlő használata csak korlátozott számú üzenettípus kezelése esetén, alacsony bitsebesség mellett ajánlott. A FullCAN architektúra Ha elképzelünk egy olyan BasicCAN megvalósítást, ahol a fogadott üzenetazonosító maszk teljesen áttetsző, akkor beláthatjuk, hogy ebben az esetben nincs szükség a maszkot megvalósító regiszterre. Tehát minden egyes elfogadási mintának csak egy üzenet felel meg, így nincs szükség utólagos szűrésre. Azonban több puffer regisztert kell implementálni a hardverben, ezeket üzenetobjektumoknak nevezzük. Mindegyik objektum egy meghatározott 16 First-In-First-Out = a kiolvasás a beírás sorrendjében történik, az előbb beírt adatok előbb kerülnek feldolgozásra 14
azonosítójú üzenetet tárol, és fel lehet programozni fogadónak vagy küldőnek is, ez biztosítja a rendszer flexibilitását. Sok FullCAN vezérlő rendelkezik egy olyan üzenetobjektummal, amely úgy viselkedik, mint a BasicCAN vezérlő egy fogadó puffere. Ez az üzenetobjektum úgy programozható, hogyha a beérkezett üzenet egyik üzenetobjektumban sem fogadja, akkor ez az üzenet itt tárolódik. Erre az üzenetobjektumra üzenetszűrés alkalmazható. Ez a tulajdonság különösen hasznos akkor, ha az üzenetobjektumok száma kevésnek bizonyul. Az adatkérő üzeneteket a FullCAN vezérlő automatikusan lekezeli, ezzel is tehermentesítve a központi mikrokontrollert. 2.5.2 Azonosító mező hossza Amint azt később látni fogjuk a CAN buszon két különböző formátumú üzenet küldhető. Az üzenet formátumát az azonosító mező hossza dönti el. Ha az azonosító mező 11 bites, akkor az üzenetet Standard formátumú (standard) üzenetnek (2-3. ábra) (a CAN Specifikáció 2.0 A részében definiált), ha viszont 29 bites, akkor Kiterjesztett formátumú (extended) üzenetnek (2-4. ábra) (a CAN Specifikáció 2.0 B részében definiált) nevezzük. 2-3. ábra: Standard üzenet felépítése 2-4. ábra: Kiterjesztett üzenet felépítése A 2.0B szerint implementált eszközök visszafelé teljesen kompatibilisek a 2.0A-s eszközökkel, azaz tudnak standard üzeneteket fogadni és küldeni is. A 2.0A-s protokollvezérlőknek viszont két típusuk van: 15
az első csak standard formátumú üzeneteket tud küldeni és fogadni, és minden kiterjesztett formátumú üzenet észlelése esetén hibajelzést ad a második csak standard formátumú üzeneteket tud küldeni és fogadni, de felismeri és nyugtázza a kiterjesztett formátumú üzeneteket (ezt hívják 2.0B passzív eszköznek) 2.5.3 Az integráltság foka A CAN protokollvezérlők kezdetben ún. külön álló (Stand Alone) egységek voltak. Mind a busztól, mind a központi egységtől jól el voltak különítve, így a felhasználó szabadon kombinálhatta a neki tetsző mikrokontrollert és CAN vezérlőt. Néhány évvel később megjelentek a mikrokontrollerbe integrált CAN vezérlők, amelyeknek számos előnyük van: a központi vezérlő könnyebben elérheti a puffereket kisebb szilícium méret nagyobb megbízhatóság kisebb költség És ma már az integrált vezérlőknek is olyan széles választéka áll rendelkezésre, hogy minden felhasználó megtalálhatja az alkalmazásnak megfelelő kombinációt. 2.6 Adatátvitel a CAN buszon - A fizikai réteg 2.6.1 A fizikai réteg megvalósítása A CAN csomópontok összeköttetésére általában használt fizikai médium a csavart érpár. A két vezetéken átvitt jelek különbségei határozzák meg a busz logikai állapotát. Az egyiket CAN_magas (CAN_H), a másikat CAN_alacsony (CAN_L) vezetéknek nevezzük, a különbségi jel előjelének megfelelően. A busz mindkét végét ellenállással kell lezárni, hogy a jelek vezetékek végéről történő visszaverődését elkerüljük. A lezáró ellenállás ajánlott nagysága 120. Ennek a megvalósításnak köszönhetően a rendszer érzéketlen az elektromágneses zavarásokra, valamint egyes zárlatok illetve szakadás okozta hibák esetén egyvezetékes módban továbbra is működőképes marad. Huzalozott-ÉS A CAN busz és a csomópontok a logikai jelszinteket tekintve gyakorlatilag a 2-5. ábra szerinti huzalozott-és (wired-and) konfigurációnak megfelelően viselkednek. 16
2-5. ábra: Logikai szintek huzalozott-és szerkezetű megvalósítása A csomópontok logikai 1-est továbbíthatnak a tranzisztor kikapcsolásával (U 0 feszültség mérhető buszvezetéken), illetve logikai 0-t a tranzisztor bekapcsolásával (0V a buszvezetéken). Ezt az elrendezést azért nevezzük huzalozott-és konfigurációnak, mert ahhoz, hogy logikai 1-es jelenjen meg a buszon, minden egyes csomópontnak logikai 1-est kell továbbítania. Más megfogalmazásban: ha akár csak egyetlen csomópont logikai 0-t tesz a buszra, akkor a busz logikai 0 állapotba kerül. Ez az oka, hogy a CAN rendszerben a 0-s bitet nevezzük dominánsnak (dominant), és az 1-est recesszívnek (recessive). Bitszint meghatározása A bitszint meghatározása a CAN_magas és a CAN_alacsony vezetékek feszültségszint-különbségei alapján történik (Hiba! A hivatkozási forrás nem alálható.). 17
Feszültség Recesszív Domináns Recesszív 3.5V 2.5V 0.5V 0.9V 0.5V 1.5V min. 1µs Idő 2-6. ábra: Bitszint meghatározása High Speed CAN esetén a CAN_magas és a CAN_alacsony vezeték feszültségszintjei között a különbség 1,5V és 3V közötti, akkor a bitszint domináns, ha -0,5V és 0,5V közötti, akkor a bitszint recesszív lesz. Abban az esetben, ha Low Speed CAN hálózatunk van, a CAN_magas és a CAN_alacsony vezeték feszültségszintjei között a különbség nagyobb, mint 0,3, akkor a bitszint domináns, ha kisebb, mint -0,3, akkor a bitszint recesszív lesz. Mivel a bitszint a feszültségkülönbségből határozódik meg, ezért elektromágneses interferencia ellen - amely mind a két feszültségszintre egyformán hat - védve van a rendszer. A vezeték árnyékolásával a külső zavarások hatása tovább csökkenthető. CAN csomópont felépítése Mint az a CAN architektúrák bemutatásakor (2.5. fejezet) már említésre került, a CAN vezérlő lehet a mikrokontrollerbe ágyazott illetve attól különálló. A CAN protokollvezérlő (CAN protocol controller) és a busz között a kapcsolatot az ún. CAN adó-vevő terminál (CAN transceiver) teremti meg.(2-7. ábra) V cc Gnd Lezáró ellenállás mikrokontroller CAN vezérlő Küldés TxD Fogadás RxD CAN Adó-vevő terminál CAN_A CAN_M CAN_alacsony +5V 100 nf CAN_magas Lezáró ellenállás 2-7. ábra: CAN csomópont felépítése A TxR és TxD jelek sorosan továbbítódnak, a CAN kontroller ezeket használva továbbítja az információit. Az adó-vevő a TxD jeleket alakítja át a busz 18
differenciális jeleivé illetve a busz-jeleket fordítja le a vezérlő számára értelmezhető soros jelfolyammá (RxD) (2-8. ábra). Bizonyos vezérlőkben ezeket a jeleket nem a földpotenciálhoz, hanem egy adott referencia-feszültséghez hasonlítják. Ez esetben 4 vonalra van szükség, Tx0, Rx0 (az adó-vevő illetve a kontroller oldali referencia-feszültségre kötve), valamint Tx1 és Rx1 (jelvezetékek). Az ilyen közvetlen elektromos csatolás helyett lehetőség van optikai csatolás használatára is, így a vezérlő elektromosan elszigetelhető a kommunikációs hálózattól, ezáltal megóvható a buszon esetlegesen keletkező túlfeszültségektől és kialakuló potenciálkülönbségektől. V cc Gnd CAN vezérlő Küldés TxD Fogadás RxD CAN Adó-vevő terminál CAN_A CAN_M Optikai csatoló +5V 100 nf 2-8 ábra: Optikai csatolóval megvalósított összeköttetés CAN csatlakozó A szabvány nem tesz megkötést a használandó csatlakozó típusára nézve, de a CiA DS102 definíciója szerint ajánlott DIN41652 szabványnak megfelelő 9-tűs D-Sub csatlakozó alkalmazása. A DS102 tartalmazza a csatlakozó tűkiosztását (2-9. ábra) is. 3: Föld (0V) 2: CAN_alacsony 4: Foglalt 5: Foglalt Tápfeszültség 9V 5 9 4 8 3 7 2 6 1 1: Foglalt 8: Foglalt 7: CAN_magas 6: Föld (0V) 2-9. ábra: DS102 szerinti csatlakozótű-hozzárendelés 19
A 2-es és 7-es számú csatlakozótűk a csavart érpár vezetékeinek felelnek meg; a 3-as és 6-os számú tűk (utóbbi opcionális) a földpotenciálok; 1,4,5,8-as számúak foglaltak; a 9-es pedig opcionálisan a rendszer áramellátását biztosítja. 2.6.2 Bit reprezentáció A különböző bitreprezentációs technikák (Manchester, NRZ, impulzushossz kódolás stb.) közötti fő eltérést az adja, hogy hány időszelet szükséges egy bit reprezentálásához. A CAN nullára vissza nem térő (NRZ=non-return-to-zero) kódolást használ, mivel ez nyújtja a legnagyobb hatékonyságot. Ebben a megközelítésben teljes bitidő alatt változatlan vagy domináns vagy recesszív a jelszint, szemben pl. a Manchester-kódolással, ahol az egy biten belüli jelszint váltás miatt két időegység szükséges egyetlen bit ábrázolásához (2-10. ábra). 2-10. ábra: Bitreprezentációs technikák Azonban míg Manchester-kódolás esetén a minden egyes bit átvitele a jelszint váltás miatt egyben szinkronizáció is, addig NRZ esetén a jelszint az átvitt információtól függően hosszabb időre változatlanul domináns illetve recesszív maradhat. Ebben az esetben is szükség van a szinkronizáció fenntartására. Ezt a feladatot oldja meg a bitbeszúrás módszere (2-11. ábra), amely annyit jelent, hogy a küldő csomópont öt egymást követő azonos értékű küldendő bit után automatikusan beszúr egy ellentétes értékű bitet, amelyet a fogadó csomópontok az üzenet feldolgozása előtt automatikusan kivesznek. 20
Kódolatlan bitsorozat a küldő oldalon 5 azonos szintű bit r r r r r r r r r Recesszív d d d d d d d Domináns Kódolt bitsorozat 5 azonos szintű bit r r r r r r r r r r Recesszív d d d d d d d d Domináns Dekódolt bitsorozat a vevő oldalon r r r r r r r r r Recesszív d d d d d d d Domináns 2-11. ábra: A CAN bitbeszúrási módszere a) 2-12. ábra: A CAN bitbeszúrási módszere b) A bitbeszúrás módszere érvényes az üzenet kezdete (SOF=Start-of-Frame), az arbitrációs, a vezérlő- és az adatmezőkre, valamint a CRC mezőre. A fennmaradó mezők (CRC-határoló, nyugtázó, üzenet vége (EOF=End-of- Frame)), valamint a hiba- és túlcsordulás keretek továbbítása bitbeszúrás nélkül történik. 2.6.3 Bitidőzítés Egy CAN csomópont megfelelő bitrátán való kommunikációjának beállításához fontos ismerni a CAN specifikációban definiált alábbi három paraméter jelentését: Névleges bitráta (NBR) (Nominal Bit Rate): az egy másodperc alatt átvitt bitek száma, amely megfelel a kívánt átviteli bitrátának. Névleges bitidő (NBI) (Nominal Bit Time): f NBI 1 t NBR (2.1) A CAN implementációk bitidőzítése a névleges bitidő paraméter értelmében adandó meg. Időkvantum: rögzített időegység, amely az oszcillátor-periódusból származik. Az implementációkban előre beállítható egy érték 1 és 32 21
között, amely azt adja meg, hogy az időkvantum hányszorosa a minimális időkvantumnak, amely megegyezik a CAN rendszer órajelének periódusidejével. Egy adott bitráta beállításához szükség van az időkvantumnak, valamint ennek alapján a névleges bitidőnek a meghatározására. A NBI négy darab nem átlapolódó időszegmenssel adható meg: Szinkronizációs szegmens (Synchronization segment) Szink_szeg Terjedési idő szegmens (Propagation delay segment) Terj_szeg 1. szinkron puffer szegmens (Phase buffer segment 1) Szink_puff1 2. szinkron puffer szegmens (Phase buffer segment 2) Szink_puff2 A csomópont Lassabb oszcillátor frekvenciájú CAN csomópont B csomópont Gyorsabb oszcillátor frekvenciájú CAN csomópont A csomópont bitsebesség előosztója B csomópont bitsebesség előosztója CAN rendszer órajele t E......... t Szinkronizáló szegmens Terjedési időszegmens 1. szinkron puffer szegmens 2. szinkron puffer szegmens 1. időszegmens 2. időszegmens Mintavételezési pont(ok) Egy CAN bit Információfeldolgozási idő 2-13. ábra: A CAN bitstruktúrája A névleges bitidő tehát a következő egyenlet alapján számítható (2.2): t NBI t Szink_szeg t Terj_szeg t Szink_puff1 t Szink_puff2 (2.2) Minden időszegmens felosztható időkvantumok egész számú többszörösére. Az időszegmensek hosszának programozásával a NBI beállítható a kívánt értékre, azonban a Specifikáció tesz bizonyos megkötéseket a szegmensek hosszára. 22
2.7 CAN üzenet válaszideje Sok próbálkozás volt a valós idejű rendszerek analízisére. 1995-ben jelent K. Tindell, A. Burns és A. J. Wellings (University of York) cikke [13], amiben leírják az általuk fejlesztett analízist olyan rendszerekre, melyekben a különböző aktivitások és küldési egyeztetések prioritáson alapszanak. Az analízis bemutatása előtt definiálni kell pár változót: Üzenet: egyedülálló azonosítóval, és 1 és 8 bájt közötti adatot tartalmazó CAN üzenet. Feltesszük, hogy az adott üzenet ciklikusan érkezik, ugyanazzal a mérettel, ugyanazzal az azonosítóval. Sorban állási ablak (queueing window): Az adott üzenet, amit küldeni akar egy forrás, egy sorban állási ablakba kerül, amíg el nem tudja küldeni. T m : Az m üzenet periódusa. J m : m üzenet számára a sorban állási ablak szélessége, azaz az üzenet sorban állási késési ingadozás (jitter) b m : az üzenet adatbájtjainak a száma. C m : a legrosszabb esete az üzenet fizikai terjedési idejének. A buszért való versengés miatt ez nem tartalmazza az esetleges késéseket. Tartalmazza az időt, ami az azonosító, más üzenet részek (pl. CRC ellenőrzés) és az adatmező átküldéséhez szükséges. C m a b m függvénye. B: A CAN hálózaton a blokkolási idő, az a leghosszabb idő, amíg az üzenet fizikailag a buszon tartózkodik. Ez 8 bájtos üzenetnél egyenlő C- vel, és 1 Mbit/sec átviteli sebességnél 130 usec. R m : Adott m üzenetnek a legrosszabb eseti válasz ideje (worst-case response time) a leghosszabb idő az üzenet sorban állása és a célállomáshoz való megérkezése között D m : Az m üzenet határidejét (deadline) jelöljük. bit : A buszon egy bit átvitelét jelentő idő. Egy üzenetet akkor és csak akkor ütemezhető, ha Rm Dm (2.3) Van egy korlát a legrosszabb válaszidőre: a sorban álló üzenetet az üzenet újra sorba állítása előtt el kell küldeni (ezzel megakadályozzuk az üzenet felülírását). Tehát: R m Tm Jm (2.4) Ebből látható, hogy az üzenetek sorban állási ablakának kisebbnek kell lennie, mint az üzenet küldési periódusának. 2.7.1 Adott m üzenet legrosszabb eseti válaszidejének analízise A legrosszabb eseti válaszidő két késésből áll: 23
sorban állási késés: a leghosszabb idő, amíg egy üzenet sorban áll egy adóban, és késik, mert magasabb és alacsonyabb prioritású üzenetek továbbítására vár. jelöljük t m -mel. átviteli késés: az a késés, amíg az üzenet a buszon van. Jele: C m. Tehát a legrosszabb eseti válaszidő (2.5): R m tm Cm (2.5) A sorban állási késés, t m két idő összege: a busz foglalási ideje pár alacsonyabb, és az összes magasabb prioritású üzenetnek még mielőtt végleg el lettek volna küldve. Korábban meghatároztuk a blokkolási időt, B. Egy korábbi ütemező elméletből [14], egy t intervallumon a magasabb prioritású üzenetek által okozott késés (2.6): j hp( m) t Jj Tj bit Cj (2.6) hp(m) egy olyan halmaz, ami tartalmazza az összes olyan üzenetet, ami magasabb prioritású m-nél (prioritási sorrendben). A bit változó a buszon egy bit átviteli idejét jelenti. A prioritás rendezés deadline monotonic [15] elv alapján működik: a legrövidebb határidejű (deadline) keret (frame) lesz a legnagyobb prioritású. Ez esetben, a jitter megjelenésével a prioritás optimális rendezését a határidő és a jitter különbsége adja (2.7): Dm Jm (2.7) Az eddigi leírás alapján a sorban állási késleltetés (2.8): t tm B j hp( m) m Jj Tj bit Cj (2.8) Ennek az egyenletnek eleget tesz t m legkisebb értéke. Más t m -ekre a fenn említett egyenletet nem tudjuk átrendezni. De egy rekurzív összefüggést tudunk adni (2.9): n tm Jj bit tm n 1 B Tj j hp( m) Cj (2.9) Mivel a rekurzív összefüggés t m -et tekintve monoton növekvő, az iterációt t m =0-val kell kezdeni. Ez kisebb, mint t m legkisebb értéke, ami kielégíti az egyenletet. A nulla érték alkalmas, de jobb, ha egy olyan t i értéket választunk, ahol az i üzenetnek magasabb a prioritása m-nél (lerövidíti az iterációt). 24
2.7.2 Válaszidőt befolyásoló tényezők Baudrate (bitráta): A CAN protokoll lehetővé teszi az adatátviteli sebesség módosítását, maximálisan 1 MBaud=1millióbit/sec. A keret (frame) arbitrációs száma: Ha az arbitrációs számot alacsonyra választjuk a hálózat tervezésénél, akkor megnyeri a buszért való versengést, gyorsan, pontosan átjut. Ezeknek az üzeneteknek csak a busz fizikai foglaltságát kell kivárniuk. Tehát egy CAN hálózaton a legnagyobb prioritású üzenet az 1-es arbitrációs számú. Busz telítettsége: Magas buszforgalom esetén hosszabb a sorban állás. Több keret verseng a busz használatáért, ezzel felértékelődik az arbitrációs szám szerepe is. Egy CAN keret válaszideje fordítottan arányos az arbitrációs számmal, a baudrate-tel, és egyenesen arányos a busz telítettségével. Az üzenetek hossza: Az előző fejezetben ismertettük a CAN bitbeszúrásos módszerét. A bitbeszúrás következtében egy CAN keret tartalmazhat akár 24 nem hasznos bitet a 111 hasznos mellett (standard keret esetén). 2.7.3 CAN válaszidő jitterének minimalizálása A CAN üzenetek késleltetésének (jitter) változása valós idejű alkalmazásokban hátrányos hatásokkal járhat. Jittert több tényező is okozhat, ilyenek például a buszterheltség, számítási idő, keret hosszának változása, végrehajtási idő változás. A CAN keretekben a beszúrt bitek hatását vizsgáljuk, illetve keresünk módszereket hatásuk csökkentésére [16]. CAN keretnek most standard formátumú kereteket tekintünk, de állításaink kiterjeszthetők kiterjesztett üzenetformátumú keretekre is, melyek annyiban különböznek a standard formátumú keretektől, hogy 29 bites arbitrációs mezőjük van. Egy CAN keret bitjeinek száma bitbeszúrás előtt (2.10): 8s 47 (2.10) Ahol s az adatmező bájtjainak száma.(s=[0,8]). Egy CAN keretben 47 vezérlő bit található, viszont csak 34 bitre érvényes a bitbeszúrás mechanizmusa. Ezért a bitek maximális száma a bitbeszúrás után (2.11): 34 8s 1 8s 47 4 (2.11) A fenti formula teljesüléséhez a következő bitmintázat lenne szükséges (2-14. ábra): 25
2-14. ábra: A legrosszabb esete a bitbeszúrásnak Legyen τ bit a bitidő. A legrosszabb esetben ekkor egy keret (α) átvitele a buszon C α 34 8s 1 8s 47 α τ α 4 bit (2.12) s =8 értéket választva és 1Mbit/sec buszsebességet (τ bit =1μs) feltételezve C α =135μs-t kapunk (2.12). A beszúrt bitek számának csökkentésében a következő mezők játszhatnak szerepet. Ezek a mezők az: arbitrációs mező adat mező 2.7.3.1 Bitbeszúrás minimalizálása az arbitrációs mezőben A használható arbitrációs ID-k számának kis csökkentésével csökkenthetjük a keretben előforduló beszúrt bitek maximális számát. Egy CAN keret arbitrációs mezője (2-15. ábra), amely egyben a keret prioritását is meghatározza 11 bitből áll, és érvényes rá a bitbeszúrás is. 2-15. ábra: Arbitrációs mező Megfelelően megválasztott azonosítók használatával minimalizálhatjuk a beszúrt bitek hatását a keret fejrészében. A hátránya ennek a módszernek, hogy nem használhatjuk a 11 bit által lehetővé tett 2048-féle különböző azonosítót. A megfelelő azonosítók kizárása után két eset lehetséges: A CAN keret fejrészében nem lesz beszúrt bit A beszúrt bitek számát 1-re csökkentjük a CAN keret fejrészében 26
Az alábbi táblázatban (2-1. táblázat) megfigyelhetjük, hogy a 2048 prioritásból hányat használhatunk, ha a CAN headerben adott számú beszúrt bitet szeretnénk. Érdemes megfigyelni, hogy a beszúrt bitek száma függ a keret DLC (Data Length Code) mezőjétől is. 2-1. táblázat: adatmező hosszától és a beszúrt bitek számától függően a választható azonosítók száma A táblázatban látható adatok értelmezése: 1. 0-3 byte adatunk van: Ekkor lehetetlen úgy megválasztani az azonosítót, hogy ne legyen a keret fejrészében beszúrt bit, viszont biztosak lehetünk benne, hogy maximum 1 beszúrt bitünk lesz. Hogy ezt elérjük, 0byte-os adatmezőnél 1585, 1byte-os adatmezőnél 1703, 2 vagy 3byte-os adatmezőnél 1763 különböző prioritást használhatunk. 2. A második esetben 4-7byte adatunk legyen. Ekkor elérhetjük, hogy a keret fejrészében ne legyen beszúrt bit. Hogy ezt elérjük, 897-féle azonosítót használhatunk. 3. A harmadik esetben 8byte van az adatmezőben. Itt is elkerülhetjük a beszúrt biteket, a felhasználható prioritások száma 1585. A 2-16. ábra megmutatja, hogy adott adatmező hossznál hány százalékát használhatjuk az azonosítóknak a beszúrt bitek függvényében. 27
2-16. ábra: CAN keret fejrészében a előforduló prioritások valószínűsége (adott számú beszúrt bittel) a keretben lévő adatbájtok függvényében 2.7.3.2 Bitbeszúrás minimalizálása az adatmezőben A CAN keret adatmezőjében is, az arbitrációs mezőhöz hasonlóan megjelennek a beszúrt bitek. Ahhoz, hogy ezeknek a biteknek a számát csökkentsük, a rendszer adatforgalmának alapos vizsgálata válhat szükségessé. Érdekesség, hogy a valós kommunikáció során az 1-esek és 0-k valószínűsége nem lesz azonos. Ezért a beszúrt bitek száma a keretekben átlagosan elég nagy, kb. 2-13 közt van. A beszúrt bitek számát csökkentő módszer lehet, hogy küldés előtt az egész kereten XOR műveletet hajtunk végre egy 101010...10 bitmintázattal, mely az összefüggő bitsorozatokból váltakozó sorozatokat készít. Fogadás után szintén ugyanezzel a mintával kell XOR műveletet végrehajtanunk a kereten, hogy az eredeti keretet visszakapjuk (2-17. ábra). 2-17. ábra: Kódolás és dekódolás 28
Ezzel a módszerrel a beszúrt bitek valószínűségi eloszlása az alábbi módon változik (2-18. ábra): 2-18. ábra: A beszúrt bitek valószínűségi eloszlásfüggvénye 1. ha 50/50 az aránya az 1-es és 0-s biteknek. 2. valódi adatforgalomnál. 3. manipulált valódi CAN forgalom. Tehát a kész keret XOR művelettel való kódolásával elérhető, hogy a beszúrt bitek száma az üzenetkeretek 80%-ánál 0 legyen. Ami busz telítettségénél akár jelentős, 13%-ot is jelenthet. Szinkronizációs szegmens A szinkronizációs szegmens hossza nem programozható, hanem mindig fixen egy időkvantum, a CAN bit első szegmense, amely a CAN buszon lévő csomópontok közötti szinkronizálásra szolgál. A küldő-csomópontnak a következő továbbítandó bit értékének küldését a szinkronizáló szegmensen belül kell megkezdenie, tehát ha az előző bit és az elküldendő bit között szintváltás van (recesszív szintből domináns szintbe vagy fordítva), akkor a szintváltás élének a szinkronizáló szegmensbe kell esnie. Az elküldött bit fogadását a fogadócsomópontok a szinkronizáló szegmens alatt kezdik meg. A küldési-idő késleltetés következtében a fogadó csomópontok szinkronizációs szegmense a küldő csomópont szinkronizációs szegmenséhez képest késik. (2-19. ábra) Terjedési idő szegmens A terjedési szegmens hossza programozható, 1-8 db időegységből állhat, és arra szolgál, hogy kompenzálja a rendszerből adódó fizikai késleltetést. Mivel a CAN protokoll üzenetrombolás nélküli arbitrációt használ, és a nyugtázás az üzeneten belül történik, ezért minden csomópont miután elküldte a soron következő bitet, monitorozza az elküldött bitek logikai szuperpozícióját. A terjedési szegmens azt biztosítja, hogy a csomópontok legkorábbi lehetséges mintavételezési pontját addig késleltesse, hogy az összes elküldött bit, amelyet a 29
küldő-csomópontok küldtek, elérjenek mindegyik csomóponthoz. Hogy ez megvalósulhasson, ennek a szegmensnek kétszer olyan hosszúnak kell lennie, mint a buszon lévő két legtávolabbi csomópont közötti jelterjedési idő valamint a küldő és fogadó csomópontok belső késleltetéseinek összege. A (2-19. ábra) két csomópont között lévő terjedési-idő késleltetést mutatja. Az A csomópont által küldött bitértéket a B csomópont t terjedés(a,b) idő múlva kapja meg, a B által küldött bitértéket az A pedig t terjedés(b,a) idő múlva kapja meg, az A csomópont terjedési időszegmensének vége előtt. Így az A csomópont is helyesen mintavételezi a bitértékét. A B csomópont még akkor is helyesen fogja mintavételezni a bitértékét, ha a B csomópont mintavételezési pontja az A csomópont által küldött bit után van, a két csomópont közötti terjedési-idő késleltetés miatt. A csomópont Szink_szeg Terjedési időszegmens 1. szinkron puffer szegmens 2. szinkron puffer szegmens t terjedés(a,b) t terjedés(b,a) Szink_szeg Terjedési időszegmens 1. szinkron puffer szegmens 2. szinkron puffer szegmens B csomópont 2-19. ábra: Terjedési-idő késleltetés két csomópont között t A t terjedés(a,b) és hasonlóképpen a t terjedés(b,a) három részből tevődik össze: Küldési idő késleltetés t K(A) Busz késleltetési idő a két csomópont között t Busz(A,B) Fogadási idő késleltetés t F(B) t terjedés A, B tfb tbusz A,B tka (2.13) Ahhoz hogy biztosítani tudjuk a helyes mintavételezést, a terjedési időszegmens minimum értékét a következőképpen kell megválasztani (2.14): t Terj_szeg t t, terjedés A,B terjedés B,A (2.14) ahol az A és a B csomópont a hálózat két egymástól legtávolabb lévő csomópontja azért, hogy a köztük lévő késleltetés maximális legyen. A 2.15-ből adódik: 30
t Terj_szeg 2 tf tbusz t K, (2.15) ahol t Busz a legnagyobb buszkésleltetési idő két csomópont között, t F a fogadócsomópont késleltetése a fizikai interfész miatt, és t K a küldő-csomópont késleltetése a fizikai interfész miatt. Ha a t K és a t F nem egységes, akkor a CAN rendszeren belüli legnagyobb értékkel kell számolni. Tehát hogy minimum hány darab időegységet kell hozzárendelni a terjedési időszegmenshez, azt a következő képlettel lehet kiszámolni (2.16): Terjedési idődőszegmens t Terj_szeg t E (2.16) Első és második szinkron puffer szegmens Ez a két szegmens kompenzálja a szinkron hibákat. Az 1. szinkron puffer szegmens hossza programozható. 1-8 időegységből állhat, ha egy, 2-8 időegységből állhat, ha 3 mintavételezési pont van kijelölve bitenként. A 2. szinkron puffer szegmens hosszának meg kell egyeznie az 1. szinkron puffer hosszával, viszont ha az 1. szinkron szegmens hossza kisebb, mint a CAN implementáció információfeldolgozási ideje, akkor a 2. szinkron szegmens hosszának+ egyenlőnek kell lennie az információfeldolgozási idővel. Ez azt is jelenti, hogy a két szegmens együttesen nem lehet hosszabb időtartamú, mint az információfeldolgozási idő kétszerese. Mintavételezési pont A mintavételezési pont a CAN bitnek az a pontja, ahol a jelszint leolvasása megtörténik, és amelyből a bit értéke fog generálódni. Egy biten belül lehet 1 vagy 3 mintavételezési pont. Ha 3 mintavételezési pontot adunk meg, akkor a bit értéke a leggyakrabban mintavételezett érték lesz. Ez a pont a 1. szinkron puffer szegmens és a 2. szinkron puffer szegmens illetve az 1. és a 2. időszegmens határánál található. A mintavételezési ponttal kezdődik az információfeldolgozási idő (Information processing time), és addig tart, amíg az aktuális bitszint kiértékelése történik. 2.7.4 Arbitráció Mint az az előző fejezetekben bevezetésre került, a CAN buszon telefonkonferencia szerűen broadcast kommunikáció zajlik. Ahogy a telefonkonferencia bármely résztvevője szabadon elmondhatja a mondanivalóját, amelyet minden más résztvevő hall, éppúgy bármelyik csomópont elküldheti az üzenetét a buszon, és azt minden egyes, ugyanarra a buszra csatlakozó csomópont megkapja. Azonban a bemondott információ csak akkor értelmezhető, ha egy időben csak egy résztvevő beszél. Hogy éppen melyik konferenciatagé ez a 31
kiváltság, azaz melyik CAN csomópont használhatja a buszt üzenetei elküldésére, azt az arbitráció folyamata hivatott eldönteni. Buszért való versengés, arbitráció (Arbitration) Az adatok valós idejű feldolgozásához elengedhetetlen, hogy nagyon gyorsan továbbítsuk az üzeneteket. Ehhez nem csak egy nagysebességű fizikai adatút szükséges, hanem gyors buszallokálás is, főleg amikor több csomópont akarja egyszerre megszerezni a buszt (2-20. ábra). 2-20. ábra: Az arbitáció folyamata 3 csomópont esetén. A CAN protokoll a buszhozzáféréskor az ütközéseket bitenkénti arbitrációval küszöböli ki. Azaz minden csomópont bitről bitre figyeli a buszt. A huzalozott ÉS 17 logika mechanizmusának megfelelően a domináns szint a logikai 0-nak a recesszív szint a logikai 1-nek felel meg. A domináns bit felülírja a recesszív bitet, de ez fordítva nem teljesül. Az arbitráció folyamata, akkor indul el, ha a busz szabad lesz (Szabad busz mező). Minden olyan csomópont, amely recesszív bitet küld, és domináns bitet vesz a buszról, elveszti az arbitrációt. Azok a csomópontok, amelyek elvesztik az arbitrációt, megszakítják a saját üzenetük küldését, és automatikusan fogadóivá válnak annak az üzenetnek, amelynek a legnagyobb a prioritása a buszért való versenyben. A megszakított üzenetek újraküldését addig nem kezdhetik meg a csomópontok, amíg a busz szabad nem lesz. A prioritásokat már a rendszer tervezésekor meg kell határozni, mivel ezután már nem lehet dinamikusan változtatni. A prioritást az üzenet azonosítója 17 wired AND (Huzalozott ÉS ) 32
határozza meg, oly módon, hogy az minél kisebb bináris szám, annál nagyobb az üzenet prioritása. A CAN protokoll a vivőérzékelő időosztásos hozzáférés (CSMA 18 ) alapelveit használja, ütközésfigyeléssel (CD 19 ), nullára vissza nem térő 20 kódolással, azonosító szerinti prioritással és üzenetrombolás nélküli arbitrációval (NDA 21 ). Hibatípusok A CAN protokollnál 5 féle típusú hibát különböztetünk meg: Bithiba A csomópontok miközben kiküldik a buszra a biteket, monitorozzák is azokat. Bithiba akkor történik, ha az elküldött bit és a monitorozott bit eltér egymástól. Kivétel, ha a csomópont recesszív bitet küld az arbitrációs mezőben vagy a nyugtázó mezőben. Ezen kívül, ha a küldőcsomópont egy passzív hibaüzenetet küld (6+8 recesszív bit), és a monitorozott bitek közül valamelyik is domináns, akkor ezt nem értelmezi bithibának. Kitöltési hiba 22 Ha az üzenet kezdete bit és a CRC határoló között 6 egymást követő bit értéke azonos, akkor kitöltési hibáról beszélünk. A hatodik egyforma bitet kitöltési bitnek nevezzük. CRC hiba A CRC szekvencia tartalmazza a küldő-csomópont által kiszámolt CRC eredményét, amelyet a fogadó-csomópont(ok) hasonló módon generálnak. Ha a két eredmény nem egyezik meg, akkor CRC hiba történt. Formai hiba Az üzeneteken belül vannak fixen domináns (pl.: foglalt bit 1) és recesszív (pl.: CRC határoló) bitek. Ha ezek megváltoznak, akkor beszélhetünk formai hibáról. Nyugtázási hiba Ha a küldő-csomópont nem észlel domináns bitet a nyugtázó mezőben, akkor nyugtázási hiba történt, ezért az üzenet küldését meg kell ismételnie a küldő-csomópontnak. Hibajelzés Amikor egy csomópont hibát észlel, akkor hibaüzenetet küld. A hiba aktív csomópontok aktív, a hiba passzív csomópontok passzív hibaüzenetet küldenek. Bithiba, kitöltési hiba, formai hiba nyugtázási hiba esetén a hibát érzékelő csomópont a következő bittől megkezdi a hibaüzenet küldését. CRC hiba esetén a 18 Carrier Sense Multiple Access (vivőjel-érzékelés többszörös hozzáféréssel) 19 Collision Detection (ütközés detektálás) 20 non-return-to-zero (NRZ) 21 Non Destructive Arbitration (Nem destruktív arbitráció) 22 Stuff error 33
hibaüzenet küldése a nyugtázó bitet határoló bit után kezdődik kivéve, ha nem előzte meg más hiba. 2.8 CAN Architektúra Amint már említettük, sokféle gyártó sokféleképpen implementálja a CAN protokollt. A különböző protokollvezérlő megvalósításokat a következő szempontok szerint lehet osztályozni: az alkalmazott puffer stratégia alapján: BasicCAN, FullCAN az üzenetazonosítók hossza alapján: Standard CAN, Extended CAN a CAN integráltsága alapján: Stand Alone CAN, Integrated CAN A BasicCAN és a FullCAN között a különbséget az üzenetek pufferbe írás előtti szűrése jelenti. A szűrés általában az üzenetek azonosító mezője alapján történik, de egyes CAN vezérlőknél lehetőség van az adatbájtok szerinti kiválasztásra is. A puffer interfészként szolgál a fogadott üzenetet elérni kívánó folyamat számára. Ezen megfontolások alapján a mai implementációk az üzenet pufferek számában különböznek, habár az újabb FullCAN megvalósítások egyben képesek BasicCAN módban is működni. 2.8.1 Puffer stratégiák 2.8.1.1 A BasicCAN architektúra A BasicCAN felépítésű interfész egyfajta asszociatív memória-szűrőként működik (2-21.ábra). Egy elfogadási mintából és egy elfogadási maszkból áll. A felhasználó állítja be ezeket a BasicCAN interfész konfigurálása során. Ezek után az összes üzenet azonosítóját összehasonlítja a CAN vezérlő a mintával, és figyelmen kívül hagyja a maszk által kiszűrt biteket. A beállításoknak megfelelő üzeneteket a fogadó puffer ún. fogadási azonosító/adat regiszterébe rakja, ahol a mikrokontroller azonnal elérheti. A BasicCAN leggyakoribb implementációja a FIFO 23 szervezés, mivel több üzenet is megfelelhet a maszknak, és várhat köztes tárolásra a feldolgozás előtt. 23 First-In-First-Out = a kiolvasás a beírás sorrendjében történik, az előbb beírt adatok előbb kerülnek feldolgozásra 34
2-21. ábra: Az üzenetek szűrése Minden üzenet elfogadásakor a puffer-vezérlő egy megszakítással figyelmezteti a mikrokontrollert az új információ feldolgozására. Ha a mikrokontroller túl lassú, túlcsordulás következhet be a fogadó pufferben, ez figyelmeztető jelzést generál. A BasicCAN sajátossága, hogy a fogadó puffer tartalmán a kiolvasás után a mikrokontroller még utólagos szűrést végez, hiszen a maszk-minta páros nem határozza meg egyértelműen az elfogadandó üzeneteket. Ezt megteheti, mert a pufferben az adatok az azonosítójukkal együtt tárolódnak. Így egy hardverszűrővel és az utólagos szűréssel tetszőleges számú virtuális fogadó puffer valósítható meg. Ez minimalizálja a hardver komplexitását. Küldéskor csak egy puffert használ a BasicCAN. Ebbe írja bele az elküldendő adatokat, mielőtt ténylegesen elindítaná a küldési folyamatot. 2-22. ábra: BasicCAN architektúra Az adatkérő üzenetre történő adathordozó üzenet elküldését is a központi egységnek kell kezelnie, így magas bitsebesség esetén nagyon leterhelt, ezért a BasicCAN vezérlő használata csak korlátozott számú üzenettípus kezelése esetén, alacsony bitsebesség mellett ajánlott (2-22. ábra). 2.8.1.2 A FullCAN architektúra Ha elképzelünk egy olyan BasicCAN megvalósítást, ahol a fogadott üzenetazonosító maszk teljesen áttetsző, akkor beláthatjuk, hogy ebben az esetben 35
nincs szükség a maszkot megvalósító regiszterre. Tehát minden egyes elfogadási mintának csak egy üzenet felel meg, így nincs szükség utólagos szűrésre. Azonban több puffer regisztert kell implementálni a hardverben, ezeket üzenetobjektumoknak nevezzük. Mindegyik objektum egy meghatározott azonosítójú üzenetet tárol, és fel lehet programozni fogadónak vagy küldőnek is, ez biztosítja a rendszer flexibilitását. 2-23. ábra: FullCAN architektúra Sok FullCAN vezérlő (Hiba! A hivatkozási forrás nem található.) endelkezik egy olyan üzenetobjektummal, amely úgy viselkedik, mint a BasicCAN vezérlő egy fogadó puffere. Ez az üzenet objektum úgy programozható, hogy abban az esetben, ha a beérkezett üzenet egyik üzenetobjektumba sem illeszthető, akkor ez az üzenet itt tárolódik. Erre az üzenetobjektumra üzenetszűrés alkalmazható. Ez a tulajdonság különösen hasznos akkor, ha az üzenetobjektumok száma kevésnek bizonyul. Az adatkérő üzeneteket a FullCAN vezérlő automatikusan lekezeli, automatikus válasszal, vagy különböző megszakítások generálásával, ily módon is tehermentesítve a központi egységet. 2.8.2 Szinkronizáció Soros buszrendszereken történő adatátvitel során a küldő oldalon az adatok párhuzamos-soros, míg vevő oldalon soros-párhuzamos átalakítása történik. A vevőnek megfelelő időpillanatokban kell mintát venni a buszról ahhoz, hogy a helyes jelet alakítsa vissza párhuzamos formába. A helytelen mintavételezés következtében a vevő oldalon nem ugyanaz az üzenet áll elő, mint amit a küldő továbbított (2-24. ábra). 36
2-24. ábra: Mintavételezési hibák Az ilyen, ún. szinkronhibák oka lehet az, hogy az egyes csomópontok oszcillátor frekvenciája kissé eltér egymástól, vagy az, hogy a különböző csomópontok t k küldési idő késleltetése eltérő, ami a terjedési idő megváltozását okozza. A CAN aszinkron mintavételezést használ, vagyis minden csomópontnak saját órajel generátora van (szemben a szinkron esettel, amikor egy közös órajel hatására történik a mintavételezés), a szinkronhibák elkerülése érdekében tehát különösen fontos, hogy a küldő és fogadó csomópontok órái valamilyen módon szinkronizáltak legyenek. Ehhez az információt a jelszint váltások adják. A bitbeszúrás módszere (2-11. ábra) biztosítja, hogy megfelelő időközönként mindenképpen történjen bitszint változás. 2.8.3 Az él szinkronhibája (Phase Error of an edge) Élek detektálása úgy történik, hogy a csomópont folyamatosan, minden időkvantumban mintavételezi a buszt és az aktuális jelszintet összehasonlítja az előző időkvantumban mért értékkel. Szinkronizáció csak recesszívből dominánsba való jelszint változáskor történik. Az él szinkronhibája azt a pozíciót adja meg a szinkronizáló szegmenshez képest, hogy az él melyik időegységbe esik. A szinkronhiba értékei a következőket jelentik (időkvantumban kifejezve): szinkronhiba = 0, ha az él a szinkronizáló szegmensbe esik szinkronhiba > 0, ha az él a szinkronizáló szegmens előtt helyezkedik el szinkronhiba < 0, ha az él a szinkronizáló szegmens után helyezkedik el 2.8.4 A szinkronizáció típusai A CAN protokoll kétféle szinkronizálási módot alkalmaz: Fixszinkronizálás (Hard synchronization) A fixszinkronizálás csak az üzenetkeretek első bitjén történik, amikor minden csomópont az aktuális bitidőt újraindítja a szinkronizáló szegmenssel úgy, hogy az elküldött üzenet kezdete bit recesszívből dominánsba ugró éle ebbe a szegmensbe essen. 37
Újraszinkronizálás (Resynchronization) Újraszinkronizálás az üzenet további részében történik, ha a bitérték recesszívről dominánsra változik. Az újraszinkronizálás a szinkronhiba értéke alapján, a szinkron puffer szegmensek hosszának változtatásával történik. A szinkron puffer szegmensek növelésének és csökkentésének mértéke az újraszinkronizálási szélesség (Resynchronization jump width), amelynek az értéke legalább 1, és legfeljebb az 1. szinkron puffer szegmens hossza, de nem lehet nagyobb 4-nél (azaz 1 és min(4,szink_puff1) között programozható). A következő esetek fordulhatnak elő: Ha a szinkronhiba = 0, akkor a bit szinkronban van. Ez az optimális eset, ekkor az él hatására a vevőben elkezdődik az 1. szinkron puffer szegmens, majd ennek a szegmensnek a végén mintavételezi a bitet. Ezután kezdődik a 2. szinkron puffer szegmens, amelynek lefutása után várható a következő bit megjelenése. Ha a szinkronhiba < 0 (fogadó csomópont órája gyorsabb, mint a küldőé), akkor az aktuális bithez tartozó 1. szinkron puffer szegmens hosszát növeli a szinkronhiba értékének megfelelően, és így később vesz mintát a bitből. o Ha a szinkronhiba az 1. újraszinkronizálási szélességnél kisebb vagy egyenlő, akkor az él hatására újraindul az 1. időszegmens. (2-25. ábra) o Ha a szinkronhiba az 1. újraszinkronizálási szélességnél nagyobb, akkor az 1. időszegmens (terjedési idő szegmens + 1. szinkron puffer szegmens) végét hosszabbítja meg 1. újraszinkronizálási szélességnyi idővel. (2-26. ábra) Terjedési időszegmens 1. szinkron puffer szegmens 2. szinkron puffer szegmens Helyes mintavételezési pont Küldõ-csomópont n. bit n+1. bit Szink_szeg 1. időszegmens 2. időszegmens Szink_szeg él n. bit n+1. bit Szink_szeg 1. ÚSzSz 1. idõszegmens 2. időszegmens 2. ÚSzSz Szink_szeg Fogadó-csomópont Szinkronhiba Elcsúszott mintavételezési pont n. bit n+1. bit Szink_szeg 1. ÚSzSz Újraindított 1. ÚSzSz 1. idõszegmens 2. időszegmens 2. ÚSzSz Szink_szeg Módosított mintavételezési pont 2-25. ábra: Újraszinkronizálás, ha Szinkronhiba < 0, és Szinkronhiba < 1.Újraszinkronizálási Szélesség 38
Terjedési időszegmens 1. szinkron puffer szegmens 2. szinkron puffer szegmens Helyes mintavételezési pont Küldõ-csomópont n. bit n+1. bit Szink_szeg 1. időszegmens 2. időszegmens Szink_szeg él Fogadó-csomópont Szink_szeg n. bit n+1. bit 1. ÚSzSz 1. idõszegmens 2. időszegmens 2. ÚSzSz Szink_szeg Szinkronhiba Elcsúszott mintavételezési pont n. bit n+1. bit Szink_szeg 1. ÚSzSz 1. idõszegmens 1. ÚSzSz 2. időszegmens 2. ÚSzSz Szink_szeg Módosított mintavételezési pont Szinkronhiba - 1.ÚSzSz 2-26. ábra: Újraszinkronizálás, ha Szinkronhiba < 0, és Szinkronhiba > 1.Újraszinkronizálási Szélesség Ha a szinkronhiba > 0 (fogadó csomópont órája lassabb, mint a küldőé), akkor az aktuális bithez tartozó 2. szinkron puffer szegmens hosszát csökkenti a szinkronhiba értékének megfelelően, és így előbb vesz mintát a bitből. Az él hatására rögtön elkezdődik a következő bit, mégpedig a szinkronizációs szegmenset elhagyva rögtön az 1. időszegmenssel. (2-27. ábra). Ha a szinkronhiba nagyobb, mint a 2. újraszinkronizálási szélesség hossza, akkor is maximum 2. újraszinkronizálási szélességnyi idővel csökken a 2. szinkron puffer szegmens hossza. él n-1. bit 2. időszegmens 2. ÚSzSz Szink_szeg n. bit 2. időszegmens 1. ÚSzSz 1. idõszegmens 2. ÚSzSz n+1. bit Szink_szeg Fogadó-csomópont n-1. bit 2. időszegmens Szinkronhiba Szink_szeg 1. ÚSzSz 1. idõszegmens 2. időszegmens Elcsúszott mintavételezési pont n. bit n+1. bit 2. ÚSzSz Szink_szeg 2.ÚjraSzinkronizálási Szélesség Módosított mintavételezési pont 2-27. ábra: Újraszinkronizálás Szinkronhiba > 0 esetén 39
2.8.5 Szinkronizálás szabályai A fixszinkronizálásnak és az újraszinkronizálásnak a következő szabályokat kell teljesítenie: Egy bitidőn belül csak egy szinkronizálás megengedett. Az él csak akkor használható újraszinkronizáláshoz, ha az előző mintavételezési pontban vett értéke eltér a közvetlenül az él után következő buszszint értékétől Fixszinkronizálás csak akkor történhet, ha a szabad busz mező alatt a bitérték recesszívből dominánsba vált. 2.8.6 Üzenetek késleltetése Mint az a 2.9. fejezetben olvasható lesz, két fajta CAN üzenetformátum létezik, a Standard és a Kiterjesztett. Mindkettőben az adatbájtok száma 0 és 8 között lehet. Az adatátviteli sebesség és a késleltetések az üzenet hosszától - ennek megfelelően az üzenet típusától és az adatbájtok számától függenek. Egy üzenet maximális késleltetése csak a legnagyobb prioritású üzenetre nézve határozható meg, a többi üzenetre ez a paraméter a CAN arbitrációs mechanizmusa következtében statisztikai módszerekkel becsülhető. Standard üzenetformátumot tekintve a leghosszabb üzenet 130 bit hosszú, kiterjesztett formátum esetén 154 bit hosszú (2-2. táblázat): Mezők: Standard Kiterjesztett formátum: formátum: Üzenet kezdete bit 1 1 Alapazonosító mező 11 11 Üzenetküldés kérés bit hely. - 1 Azonosító kiterjesztés bit 1 1 Kiterjesztett azonosító mező - 18 Üzenetküldés kérés bit 1 1 Foglalt bit 1 2 Adathossz kód 4 4 Adatmező 64 64 CRC mező 15 15 CRC határoló bit 1 1 Nyugtázó bit 1 1 Nyugtázó bitet határoló bit 1 1 Üzenet vége mező 7 7 Üzenet utáni szünet mező 3 3 Beszúrt bitek max. száma 19 23 Összesen 130 154 2-2. táblázat: Standard és kiterjesztett CAN üzenet felépítése 40
Tehát Standard formátum esetén a legnagyobb prioritású üzenetnek maximum 130 bitidőnyit kell várnia, amíg megkapja a busz használatának jogát (ez 130 snyi várakozást jelent a maximális, 1 Mbit/s-os átviteli sebesség mellett), Kiterjesztett formátum esetén ez az idő 154 bitidő hosszú (azaz a CAN legnagyobb átviteli sebessége mellett 154 s). Ugyancsak az üzenetek hosszától és a bitrátától függ az is, hogy mennyi idő alatt kell a mikrokontrollernek feldolgoznia az érkező üzeneteket. A legrosszabb esetet tekintve (100%-os buszhasználat mellett 0 bájt adat minden üzenetben, így beszúrt bitekre sincs szükség). Standard esetben 47 s-onként érkezik új üzenet, kiterjesztett formátumú üzenetkeretek esetén ez az idő 67 s. Ennek különösen BasicCAN architektúra használata esetén van jelentősége, hiszen ekkor minden egyes beérkezett üzenet szűrése a felhasználói alkalmazásra hárul, ami több mint 21000 (illetve kiterjesztett esetben majdnem 15000) megszakítást jelent másodpercenként legrosszabb esetben. 2.9 Adatátvitel a CAN buszon Az adatkapcsolati réteg 2.9.1 CAN üzenetkeretek A CAN hálózatokon az adatforgalom üzenetkeretek használatával történik. Kétféle formátumú üzenetkeret (a továbbiakban: üzenet) létezik, amelyek az üzenetazonosító mező hosszában különböznek. Ha az azonosító mező 11 bites, akkor az üzenetet Standard formátumú (standard) üzenetnek (a CAN Specifikáció 2.0 A részében definiált), ha viszont 29 bites, akkor K iterjesztett formátumú (extended) üzenetnek (a CAN Specifikáció 2.0 B részében definiált) nevezzük. A CAN buszon a következő üzenet típusokat különböztethetjük meg: Adathordozó üzenet (Data frame) Adatkérő üzenet (Remote frame) Hiba üzenet (Error frame) Túlcsordulás üzenet (Overload frame) 2.9.2 Adathordozó üzenet Egy küldőtől egy vagy több fogadóhoz továbbít adatokat a küldő fél kezdeményezésére. Az adathordozó üzenet (Hiba! A hivatkozási forrás nem található.) a következő mezőkből áll: üzenet kezdete, arbitrációs mező, vezérlési mező, adat mező, CRC mező, nyugtázás mező és üzenet vége mező. Az adatmező nem kötelező, akár nulla bit hosszúságú is lehet. Üzenet kezdete bit Ez jelzi az adathordozó vagy adatkérő üzenet kezdetét egy darab domináns bittel (SOF 24 ). Egy csomópont csak akkor kezdheti az arbitrációs szakaszt, ha a busz szabaddá válik. Ezt általában 11 egymást követő recesszív bit (nyugtázás határoló bit + üzenet vége mező + üzenet utáni szünet) jelzi. 24 Start of Frame (Üzenet kezdete) 41
Az üzenet kezdete bit segítségével minden csomópontnak szinkronizálnia kell magát az arbitrációt elsőként kezdő csomóponthoz. Arbitrációs mező Az arbitrációs mező (Arbitration field) az üzenetazonosító mezőből (Identifier field) és az üzenetküldés kérő bitből (RTR 25 ) áll. Az azonosító határozza meg az üzenet prioritását az arbitráció során. Standard formátumú üzenetkeretek esetén ez 11 bitet jelent, ami 2048 (2 11 ) fajta üzenet megkülönböztetését teszi lehetővé. Kiterjesztett formátum esetén ez a szám 2 29 (=536 870 912) db (2-3. ábra). A standard formátumú azonosítót az RTR bit követi közvetlenül, ez a bit adathordozó üzenetek esetén domináns szintre van állítva, jelezve, hogy nem adatkérő üzenetről van szó. A bit domináns volta biztosítja, hogy azonos azonosítójú adathordozó és adatkérő üzenetek közül mindig az adathordozónak van nagyobb prioritása (2-28. ábra). Kiterjesztett formátum esetén a 11 bites azonosító mezőt két recesszív bit, az üzenetkérés helyettesítő bit (SRR 26 ) és az azonosító kiterjesztés (IDE 27 ) bit követi. Ezután jön csak a kiterjesztett azonosító fennmaradó 18 bitje, és az RTR bit (2-4. ábra). IDE bit Az azonosító kiterjesztés bit a kiterjesztett formátumú üzeneteknél recesszív, és az arbitrációs mezőhöz tartozik, míg a standard formátumúaknál domináns, és a vezérlési mező része. Vezérlési mező A vezérlési mező (Control field) hat bitet tartalmaz. Az első két bit mindenképpen domináns. Standard esetben ezek az IDE és az r0-nak nevezett foglalt bit, kiterjesztett üzeneteknél r1, és r0 foglalt bitek. A foglalt bitek esetleges későbbi felhasználásra vannak specifikálva. A következő négy bit az adathossz kódja, ami az adatmezőben található adat bájtjainak a számát adja meg. A 0-8-ig terjedő kódok érvényesek, nyolcnál nagyobb adathossz kódot nem engedélyez a CAN specifikáció, hiába adna rá lehetőséget a négy bit. A legális kódok tehát alábbi táblázat szerint (d: domináns, r: recesszív) (2-3. táblázat): Adatbájtok száma Adathossz-kód 3. bit 2. bit 1. bit 0. bit 0 D D d D 1 D D d R 2 D D r d 3 D D r r 4 D R d d 5 D R d r 6 D R r d 7 D R r r 25 Remote Transfer Request 26 Substitute Remote Request 27 Identifier Extension Bit 42
Adatmező 8 R D d d 2-3. táblázat: Legális adathossz-kódok Az adatmező (Data field) tartalmazza az üzenetben elküldendő adatokat. Maximum nyolc bájtból áll, minden bájt első bitje a legnagyobb helyi értékű bit. CRC mező A 15 bites CRC sorozatból és a CRC határoló bitből áll. A CRC mező (CRC field) segítségével ellenőrzi a fogadó fél a kapott bitfolyam hibátlanságát. Ezt a bitbeszúrásoktól mentes SOF, arbitrációs mező, vezérlési mező és adatmező alapján számolja ki mind a küldő, mind a fogadó fél. A CAN-ben alkalmazott CRC kód Hamming-távolsága 6 bit, ami 6 bit egyszeres hibát tud jelezni, vagy 15 bitnyi löketszerű hibát. Nyugtázás mező A nyugtázás bitből (ACK Slot) és a nyugtázás határoló bitből (ACK Delimiter) áll a 2 bites nyugtázás mező (Acknowledgement field). A nyugtázás bitet a küldő mindig recesszíven küldi, majd minden állomás, amelyik sikeresen 28 fogadta az üzenetet egy domináns bittel felülírja. A nyugtázás bitet egy recesszív határoló bit követi, hogy egyértelműen elkülönítse a pozitív (domináns) nyugtát egy esetlegesen párhuzamosan kezdődő hiba üzenettől. Így a nyugtázás bit mindig két recesszív bit közé van beágyazva. Üzenet vége mező Minden adathordozó és adatkérő üzenetet hét recesszív bitből álló sorozat zár le. A nyugtázás határoló bittel együtt így nyolc recesszív bit jelzi az ilyen üzenetek végét. Azért van szükség ennyi bitre az üzenet vége mezőben, hogy a hibás üzeneteket megfelelően lehessen jelezni. 2.9.3 Adatkérő üzenet Minden csomópont kezdeményezheti a számára szükséges információ elküldését az adatot szolgáltató csomóponttól. Ehhez az igényelt adathordozó üzenettel egyező azonosítójú adatkérő üzenetet kell küldenie. 28 Egyező CRC kód a fogadó és a küldő oldalán 43
2-28. ábra: Standard adatkérő üzenet Az adatkérő üzenet felépítése hasonló az adathordozóéhoz, ugyancsak standard és kiterjesztett formátumokat különböztetünk meg (2-28. ábra, 2-29. ábra). Annyi az eltérés, hogy itt az RTR bit recesszíven kerül küldésre, ezzel biztosítva, hogy az arbitrációt a hordozó üzenet nyerje meg a kérővel szemben. Az adathossz-kód a kért üzenet adatmezejére vonatkozik, az adatkérő üzenet adatmezeje üres. 2-29. ábra: Kiterjesztett adatkérő üzenet Az adatkérési ciklus lefolyásának elvét a 2-30. ábra szemlélteti. Az A csomópont adatkérő üzenetére a B csomópont a megfelelő adathordozó üzenettel válaszol, amit természetesen nem csak az A, hanem az összes érdekelt csomópont megkap. 44