Autóipari kommunikációs protokollok a CAN

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

2

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

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

3

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

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átor2 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-ben4. 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 ESP 3 Így minden eszköz megkapja azt az információt, amit valamelyik eszköz elküld. 4 ISO 11898 2

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 SAE5 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 GPS6 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 ISO7 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 Global Positioning System, globális helymeghatározó rendszer 7 International Standardisation Organisation, Nemzetközi Szabványügyi Hivatal 6

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+CR9 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 211 (=2 048), kiterjesztett üzenetformátum esetén 229 (=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, PLC10, 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ése11 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 CAL12-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 SDS13, DeviceNet stb.

10

Programozható logikai vezérlők (Programmable Logic Controllers) 1987: Intel 82526, nem sokkal később: Philips 82C200 12 CAN Application Layer (CAN alkalmazási réteg) 13 Smart Distributed System 11

10

1993-ra megjelent az ISO14 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/OSI15 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 15

Nemzetközi Szabványügyi Hivatal (International Standardisation Organisation) 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

Adatkapcsolati réteg

/Data link layer/

/Data link layer/

Logikai kapcsolatvezérlés /Logical Link Control/

Azonosító+Adat

Közeghozzáférés vezérlés /Medium Access Control/

Fizikai réteg /Physical layer/

Logikai kapcsolatvezérlés /Logical Link Control/ Közeghozzáférés vezérlés /Medium Access Control/

Recesszív Domináns

Fizikai réteg /Physical layer/

CAN busz

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.0s 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 FIFO16 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

Üzenet 2

1 0 0 0 x x x 0 1 1 x x x x

Üzenet3

X lehet 0 vagy 1

1 1 0 1 x x x 1 1 1 x x x x

Összehasonlított bitek

Nem összehasonlított bitek

Összehasonlított bitek

elfogadva

kiszűrve

kiszűrve

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

3.5V

Recesszív

 0.9V  0.5V

2.5V

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)

Vcc

Gnd

Lezáró ellenállás

Küldés TxD

mikrokontroller

CAN vezérlő

Fogadás RxD

CAN Adó-vevő terminál

CAN_A

100 nF

+5V

CAN_alacsony

CAN_M

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

Gnd

Küldés TxD

CAN vezérlő

CAN Adó-vevő terminál

Fogadás RxD

+5V

CAN_A CAN_M

100 nF

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

2: CAN_alacsony 3: Föld (0V) 4: Foglalt

5: Foglalt

5 4 9 8

Tápfeszültség 9V

3 2

1

7 6 1: Foglalt

8: Foglalt 6: Föld (0V) 7: CAN_magas

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

d

r

d

d

d

r

r

r

d

d

Domináns

d

5 azonos szintű bit

Kódolt bitsorozat

r

Recesszív

r

r

r

d

r

d

r

r

d

d

d

d

d

r

Recesszív Domináns

d

Dekódolt bitsorozat a vevő oldalon

r

r

d

r

r

r

r

r

r

r

d

d

d

d

d

d

Recesszív 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-ofFrame)), 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

tE ...

...

...

Terjedési időszegmens

1. szinkron puffer szegmens

2. szinkron puffer szegmens

t

Szinkronizáló 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.  Tm: Az m üzenet periódusa.  Jm: 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)  bm: az üzenet adatbájtjainak a száma.  Cm: 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. Cm a bm 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ő Cvel, és 1 Mbit/sec átviteli sebességnél 130 usec.  Rm: 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  Dm: 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:

Rm  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 tm-mel. átviteli késés: az a késés, amíg az üzenet a buszon van. Jele: Cm.

Tehát a legrosszabb eseti válaszidő (2.5):

Rm  tm  Cm

(2.5)

A sorban állási késés, tm 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  bit  Cj Tj 

(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): tm  B 



   j  hp(m) 

tm  Jj  bit  Cj  Tj

(2.8)

Ennek az egyenletnek eleget tesz tm legkisebb értéke. Más tm-ekre a fenn említett egyenletet nem tudjuk átrendezni. De egy rekurzív összefüggést tudunk adni (2.9): tm n1  B 

 n  m

   j  hp(m) 

t

 Jj  bit  Cj  Tj 

(2.9)

Mivel a rekurzív összefüggés tm-et tekintve monoton növekvő, az iterációt tm=0-val kell kezdeni. Ez kisebb, mint tm legkisebb értéke, ami kielégíti az egyenletet. A nulla érték alkalmas, de jobb, ha egy olyan ti é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

  34  8sα  1   C   8s  47     τbit α  α 4    

(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 tterjedés(A,B) idő múlva kapja meg, a „B” által küldött bitértéket az „A” pedig tterjedé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

Terjedési időszegmens

Szink_szeg

1. szinkron puffer szegmens

2. szinkron puffer szegmens

tterjedés(B,A) tterjedés(A,B) Szink_szeg

Terjedési időszegmens

1. szinkron puffer szegmens

2. szinkron puffer szegmens

B csomópont

t

2-19. ábra: Terjedési-idő késleltetés két csomópont között

A tterjedés(A,B) és hasonlóképpen a tterjedés(B,A) három részből tevődik össze:  Küldési idő késleltetés tK(A)  Busz késleltetési idő a két csomópont között tBusz(A,B)  Fogadási idő késleltetés tF(B) tterjedés A, B  tFB  tBuszA,B  tK A 

(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): tTerj_szeg  tterjedésA,B  tterjedé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

tTerj_szeg  2  t F  t Busz  t K  ,

(2.15)

ahol tBusz a legnagyobb buszkésleltetési idő két csomópont között, tF a fogadócsomópont késleltetése a fizikai interfész miatt, és tK a küldő-csomópont késleltetése a fizikai interfész miatt. Ha a tK és a tF 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):

 t Terj_szeg  Terjedési idődőszegmens     tE 

(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 (CSMA18) alapelveit használja, ütközésfigyeléssel (CD19), nullára vissza nem térő20 kódolással, azonosító szerinti prioritással és üzenetrombolás nélküli arbitrációval (NDA21).

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 hiba22 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) 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 19

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 FIFO23 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 tk 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

n. bit

n+1. bit

Küldõ-csomópont 1. időszegmens

Szink_szeg

2. időszegmens

Szink_szeg

él n. bit Szink_szeg

n+1. bit

1. idõszegmens

1. ÚSzSz

2. időszegmens

2. ÚSzSz

Szink_szeg

Fogadó-csomópont Elcsúszott mintavételezési pont Szinkronhiba

Szink_szeg

1. ÚSzSz

n. bit Újraindított 1. ÚSzSz

n+1. bit 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

n. bit

n+1. bit

Küldõ-csomópont 1. időszegmens

Szink_szeg

2. időszegmens

Szink_szeg

él

n. bit Szink_szeg

n+1. bit

1. idõszegmens

1. ÚSzSz

2. időszegmens

2. ÚSzSz

Szink_szeg

Fogadó-csomópont Elcsúszott mintavételezési pont Szinkronhiba

Szink_szeg

n. bit

n+1. bit

1. idõszegmens

1. ÚSzSz

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

n. bit

2. időszegmens

2. ÚSzSz

Szink_szeg

n+1. bit

1. idõszegmens

1. ÚSzSz

Fogadó-csomópont

2. időszegmens

2. ÚSzSz

Szink_szeg

Elcsúszott mintavételezési pont

Szinkronhiba n. bit

n+1. bit

n-1. bit 2. időszegmens

Szink_szeg

1. ÚSzSz

1. idõszegmens

2.ÚjraSzinkronizálási Szélesség

2. időszegmens

2. ÚSzSz

Szink_szeg

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 Alapazonosító mező Üzenetküldés kérés bit hely. Azonosító kiterjesztés bit Kiterjesztett azonosító mező Üzenetküldés kérés bit Foglalt bit Adathossz kód Adatmező CRC mező CRC határoló bit Nyugtázó bit Nyugtázó bitet határoló bit Üzenet vége mező Üzenet utáni szünet mező Beszúrt bitek max. száma Összesen

1 11 1 1 1 4 64 15 1 1 1 7 3 19 130

1 11 1 1 18 1 2 4 64 15 1 1 1 7 3 23 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 (SOF24). 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 (RTR25) á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 (211) fajta üzenet megkülönböztetését teszi lehetővé. Kiterjesztett formátum esetén ez a szám 229(=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 (SRR26) és az azonosító kiterjesztés (IDE27) 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áma0 1 2 3 4 5 6 7

Adathossz-kód 3. bit D D D D D D D D

2. bit D D D D R R R R

25

Remote Transfer Request Substitute Remote Request 27 Identifier Extension Bit 26

42

1. bit d d r r d d r r

0. bit D R d r d r d r

8

R

D

d

d

2-3. táblázat: Legális adathossz-kódok

Adatmező 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 sikeresen28 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

„A” csomópont

„B” csomópont

Azono sító: X XX, R TR

s Azono

=1

R=0 X, RT ító: XX

2-30. ábra: Az adatkérési ciklus

2.9.4 Hibaüzenet Bármilyen küldés, vagy fogadás (adathordozó, adatkérő, hiba-, túlcsordulás üzenet) során fellépő hiba egy hibaüzenetet generál, ami szándékosan megsérti a bitbeszúrás szabályait, ezzel kényszerítve az adó csomópontot az újraküldésre. Két formája létezik, az aktív és a passzív hibaüzenet (2-31. ábra, 2-32. ábra). A 2.10.4 fejezet szerint kétféle állapotban képes hibát jelezni egy csomópont:  „Hiba aktív”: a hibaszámláló meghatározott értéke alatt aktív hibaüzeneteket küldhet a csomópont. Ekkor a csomópont biztos benne, hogy hiba történt, és azt nem ő okozta.  „Hiba passzív”: a csomópont átlépte a kijelölt határt, valószínűleg helyi meghibásodása van, de még nem olyan súlyos a helyzet, hogy le kelljen válnia a buszról. Ekkor passzív hibaüzeneteket küldhet. A hibaüzenet két tagból áll, az egyik a hibajelző mező, amely hibajelzők (Error Flag) szuperpozíciójából áll, a másik a hibahatároló (Error Delimiter). Hibajelző mező Minimum 6, maximum 12 bitből áll. „Hiba aktív” állapot esetén a hibát elsőként észlelő csomópont azonnal (kivéve CRC hiba esetén29) 6 domináns bitet küld el, ami megsérti a bitbeszúrás szabályát („elsődleges hiba jelzés”). Ennek hatására a többi csomópont is hibát észlel, és elkezdi a saját hibajelzését forgalmazni. Így maximum 6 bit hosszan átlapolódnak az aktív hibajelző csomópontok hibajelei. Attól függően, hogy a többi csomópont mikor észleli a hibát, 6-12 bit hosszú domináns bitsorozat jelenik meg a buszon. Az aktív hibajelzések megsemmisítik az éppen küldés alatt lévő üzenetet, így vigyázni kell, mert a tévedésből elküldött aktív hibaüzenetek akár blokkolhatják is a buszforgalmat.

29

Ebben az esetben csak a nyugtázás mező után kezdi, hogy ne zavarja a nyugtázást.

45

Üzenet

Üzenetek közötti mező

Aktív hibaüzenet

Recesszív szint 6 bit

Domináns szint

8 bit

0 - 6 bit

H ib

ba

ár at

hi

ah

ők lz a je iój ba íc hi oz tív erp Ak p u ő lz je sz

tív Ak

ol ó

Hibajelző mező

2-31. ábra: Aktív hibaüzenet

„Hiba passzív” esetben egy küldő (buszbirtokló) csomópont 6 recesszív bittel próbálja jelezni az észlelt hibát. Ennek csak akkor van hatása, ha a megfelelő helyen kezdi el a küldést. Ugyanis az arbitrációs mezőben, illetve kevesebb, mint hat bittel a CRC sorozat vége előtt adni kezdett30 passzív hibajelzőt nem érzékel a többi csomópont. Üzenet

Passzív hibaüzenet

Üzenetek közötti mező Recesszív szint

6 bit

Domináns szint

8 bit

H

s Pa

ib

ív

ah

sz

ár at

hi ő

lz

ó

je

ol

ba

Hibajelző mező

2-32. ábra Passzív hibaüzenet

Ha egy nem buszbirtokló csomópont próbál passzív hibajelzést adni, akkor annak nem lesz hatása a hálózat többi csomópontjára. „Hiba passzív” állapotú csomópontoknak mindig ki kell várni a 6 azonos értékű bitet a hiba detektálása után, hogy befejezettnek tekinthessék a hibajelzésüket. Hibahatároló A hibaüzenetet mindig 8 recesszív bit zárja le. A saját hibajelzés befejezése után minden csomópont recesszív biteket kezd forgalmazni, egészen addig, amíg recesszív bitet nem olvas a buszról. Ekkor még hét recesszívet küld el. Ezzel a módszerrel lehetségessé válik egy csomópont számára, hogy érzékelje, vajon ő volt-e az első, aki hibajelzést küldött, azaz elsőként észlelte a hibát. A hibás csomópontok elszigetelésénél fontos ez a mechanizmus.

30

És a CRC sorozat vége történetesen csupa recesszív bitből áll.

46

2.9.5 Túlcsordulás üzenet A túlcsordulás üzenetnek (2-33. ábra) ugyanolyan formátuma van, mint az aktív hibaüzenetnek. Egy csomópont három esetben küld túlcsordulás üzenetet:  ha a fogadó csomópont késleltetni akarja a következő üzenet fogadását,  ha a fogadó csomópont az üzenet közötti mező első két bitjén domináns bitet érzékel,  ha a hiba-, vagy túlcsordulás-határoló mező utolsó bitjén domináns bitet érzékel (2-35. ábra). Üzenet utáni szünet

Üzenetek közötti mező

Túlcsordulás üzenet

Recesszív szint 6 bit

Domináns szint

8 bit

0 - 6 bit

cs

or

ők lz je ja ás ió ul zíc rd o so r p lc pe Tú zu ő s lz je s lá

l Tú

Tú l

cs

or

du

du

lá

s

ha

tá r

ol

ó

Túlcsordulás mező

2-33. ábra Túlcsordulás üzenet

Túlcsordulás üzenetből egymás után maximum kettőt lehet elküldeni, csakis az üzenet utáni szünetben. A hibaüzenettel ellentétben nem kényszeríti ki az előző üzenet újraküldését. Túlcsordulás mező A túlcsordulás jelzővel (Overload Flag) kezdődik, amely 6 domináns bitből áll. Ezt követi a 6 domináns bitből álló túlcsordulás jelzők szuperpozíciója, amely a többi csomópont által generált túlcsordulás üzenetek, átlapolódásából adódik össze, hasonlóan az aktív hibaüzenetekhez. Túlcsordulás-határoló: Ez a tag (Overload Delimiter) 8 recesszív bitből áll, és a túlcsordulás üzenetet zárja le. Ugyanúgy generálódik, mint a hibahatároló, azaz a túlcsordulás jelző befejezésekor recesszív biteket forgalmaz a csomópont, majd, ha azt is érzékel a buszon, akkor még hetet küld, ezzel zárja le a túlcsordulás üzenetet. 2.9.6 Üzenetek közötti mező Az üzenetek közötti mező (Interframe Space) arra szolgál, hogy az adathordozó és az adatkérő üzeneteket elkülönítse az őket megelőző üzenetektől. Ezzel szemben a hiba- és a túlcsordulás üzenetek folyamatosan továbbítódnak, azaz nincs előttük ez a mező.

47

Kötelezően az „Üzenetek utáni szünet”-tel (Intermission field) kezdődik, amit változó hosszúságú recesszív bitsorozat követ, a „Szabad busz” (Bus Idle) mező (2-34. ábra). „Hiba passzív” állapotú csomópontok esetén a kettő között található még a 8 bites „Küldés felfüggesztés”(Suspend transmission) mező (2-35. ábra).

Üzenet

Üzenetek közötti mező

Üzenet Receszív szint Domináns szint

0,1,… bit

3 bit

ze

a Sz

Ü

d

tu

ba

ne

bu

n tá

sz

is

m

zü

ez

t

ő

ne

2-34. ábra Üzenetek közötti mező „hiba aktív” csomópontoknál

Üzenet utáni szünet Három recesszív bitből áll. Csak túlcsordulás üzenetet lehet küldeni közben, adathordozó és adatkérő üzenetek küldését nem lehet kezdeményezni. A 7 bites hibahatárolóval és a nyugtázást határoló bittel együtt így legalább 11 bites recesszív bitsorozat áll össze két adathordozó, vagy adatkérő üzenet között. Ezek után a busz szabaddá válik, és az első domináns bitet SOF bitként értelmezik a csomópontok. Egy küldésre várakozó csomópont az üzenet utáni szünetet követő első bit megjelenésekor férhet hozzá a buszhoz. Ha az üzenet utáni szünet utolsó bitjén domináns bitet észlel egy küldésre várakozó csomópont, akkor azt egy másik csomópont SOF bitjének veszi31, és a saját üzenetének azonosítóját kezdi el küldeni a következő biten, anélkül, hogy SOF-et küldene, így belép a buszért való versengésbe. Szabad busz mező Tetszőleges hosszú lehet. Ha a busz szabaddá válik és valamelyik csomópont küldeni akar egy üzenetet, akkor hozzáférhet a buszhoz. Az üzenet utáni szünetet követő első biten lehet megkezdeni azoknak az üzeneteknek az elküldését, amelyeknek az átvitele függőben maradt egy másik nagyobb prioritású üzenet elküldése miatt. Küldés felfüggesztés mező A „hiba passzív” állapotú csomópontok esetén a két előbb említett mező között helyezkedik el. Ez a 8 bites mező biztosítja, hogy a hibásan működő csomópontok ne hátráltassák túlságosan a többieket. Miután egy „hiba passzív” állapotban lévő csomópont elküldött egy üzenetet, köteles kivárni a küldés felfüggesztés mezőt, ezalatt a „hiba aktív” csomópontok elkezdhetik a forgalmazást. 31

Az oszcillátor tolerancia miatt lehetséges

48

Üzenet

Üzenetek közötti mező

3 bit

Üzenet Receszív szint Domináns szint

0,1… bit

8 bit

ba d

tu is

sz

n tá

bu ez

t

õ

ne

s té

zü

m

z es gg lfü ő fe ez m

ne

és

ze

ld

a Sz

Kü

Ü

2-35. ábra Üzenetek közötti mező „hiba passzív” csomópontoknál

2.10 Hibakezelés 2.10.1 Üzenet jóváhagyás A CAN protokollban a küldő és a fogadó csomópontok különböző időpontban tekintik érvényesnek az aktuális üzenetkeretet. A küldő szempontjából érvényes az üzenet, ha nem történik hibajelzés az üzenet vége jelzés (EOF Flag) utolsó bitjéig. A fogadó akkor hagyja jóvá, ha nem észleli más csomópontok hibajelzését az üzenet vége jelzés hatodik bitjéig. Ha a hatodik bitet egy lokális hiba miatt mégis dominánsnak észleli, akkor elveti az üzenetet. Az ekkor fellépő adat inkonzisztencia feloldása végett (más csomópontok elfogadhatták már az üzenetet) az üzenet vége mező 7 bit hosszú, így az utolsó biten a lokális hibával rendelkező csomópont hiba üzenetet generálhat, ezzel újraküldésre kényszerítve az üzenet forrását. Ez a mechanizmus magában foglalja annak a lehetőségét, hogy egyes csomópontok újra megkapják az általuk előzőleg már elfogadott üzenetet. Bizonyos alkalmazásokban kitüntetett figyelmet kell fordítani a duplikált üzenetek felismerésére. Ezzel a magasabb rendű CAN protokollok foglalkoznak. Tehát, ha a fogadó nem észlel hibát az üzenet vége mező utolsó előtti bitjéig, akkor jóváhagyja az üzenetet. Így ebből a szempontból az utolsó bit már nem számít, „dont-care” bit. Ha az utolsó biten domináns szintet észlel a fogadó, akkor ezt nem tekinti formai hibának, és csak egy túlcsordulás üzenetet generál, ami nem kényszeríti újraküldésre a küldő csomópontot, de segíthet újraszinkronizálni egy esetlegesen rosszul szinkronizált csomópontot. Ha mind a küldő, mind a fogadó domináns bitet észlel az üzenet vége mező utolsó bitjén, akkor az üzenet érvényes a fogadó, de nem érvényes a küldő szempontjából. Ebben az esetben az újraküldés miatt a fogadó kétszer kapja meg ezt az üzenetet.

49

2.10.2 Hibafelismerés, hibakezelés A CAN protokoll, elsősorban a megalkotásakor megcélzott autóipari felhasználás magas adatbiztonsági igényei miatt ötfajta hibaellenőrzési módszerrel rendelkezik:  Bit ellenőrzés  Üzenetkeret ellenőrzés  CRC ellenőrzés  Nyugtázás ellenőrzés  Bitbeszúrás ellenőrzés Bit ellenőrzés Az éppen küldő csomópont folyamatosan figyeli a buszt, hogy az elküldött és a vett bitszint megegyezik-e. Ha a kettő különbözik, bithibáról beszélhetünk. Ez a módszer egyaránt hatásos a globális és a lokális hibák felderítésére. Ha az arbitrációs mezőben történik egy elküldött recesszív bit felülírása dominánssal, az nem számít bit hibának, ugyanez a helyzet a nyugtázás bittel és a passzív hibajelzővel. Üzenetkeret ellenőrzés A CAN üzeneteknek vannak rögzített értékű bitmezői (pl. a recesszív határoló bitek), amelyek helyességét minden csomópont ellenőrzi. Ha ezek nem stimmelnek, akkor formai hibáról beszélhetünk. Nem tekinthető formai hibának egy fogadó csomópont által az üzenet vége mező utolsó bitjén fogadott domináns bit, hiszen ez lehet egy másik csomópont üzenet kezdete bitje. Ugyanígy nem okoz formai hibát, ha bármely csomópont domináns bitet fogad a túlcsordulás üzenet utolsó bitjén. CRC ellenőrzés A fogadó csomópontok a CRC ellenőrzést használják a fogadott adat integritásának ellenőrzésére. Ez egy ún. polinom-kódon alapuló módszer, nevét a ciklikus redundancia kód (cyclic redundancy code) angol rövidítéséből kapta. Széles körben alkalmazott hibajelző kód, elsősorban magas hatásfoka és alacsony maradék hiba aránya miatt. Az elv szerint az üzenetek meghatározott részeit egy polinommal reprezentálják és ezt egy előre definiált ún. generátor polinommal osztják. Ennek a modulo 2 osztásnak a maradéka alkotja a CRC szekvenciát. Ezt a keret részeként továbbítja a küldő csomópont a buszon. A fogadók ugyanúgy kiszámítják a CRC szekvenciát a kapott üzeneten és hibátlan kommunikáció esetén a kettő megegyezik. Az üzenetet reprezentáló polinom együtthatóit a még bitbeszúrás előtti üzenet kezdete, arbitrációs, vezérlési, és adatmező bitértékei alkotják, kiegészítve 15 darab nullával a 15 legkisebb helyi értéken. A generátor polinomban a felek előre megegyeznek, ez a CAN-ben (2.17): x15  x14  x10  x 8  x 7  x 4  x 3  1

(2.17)

Az ellenőrző összeg kiszámítása szoftveresen bonyolult, azonban Peterson és Brown(1961) megmutatta, hogy shift regiszterekből egyszerű áramkörrel

50

megvalósítható az alábbi algoritmus szerint, a gyakorlatban szinte mindig ilyet használnak. CRC_RG = 0; // a shift regiszter inicializálása repeat CRCNXT = NXTBIT exor CRC_RG(14); CRC_RG(14:1) = CRC_RG(13:0); // 1 bitnyi balra tolás CRC_RG(0) = 0; if CRCNXT then CRC_RG(14:0) = CRC_RG(14:0) exor (0x4599); endif until (CRC mező első bitje, vagy hiba történt) Az utolsó adatbit feldolgozása után a CRC_RG shift regiszter tartalmazza a CRC ellenőrző összeget. Nyugtázás ellenőrzés A küldő figyeli, hogy legalább egy csomópont nyugtát küldjön az üzenet hibamentes megérkezéséről, azaz domináns bitszint megjelenése a nyugtázás biten. Ennek elmaradása esetén a küldő csomópont nyugtázási hibát észlel. Bitbeszúrás ellenőrzés Bármely csomópont hibaüzenet generálásával jelezheti, ha bitbeszúrási hibát észlel. Ez akkor következik be, ha 6 egymást követő azonos jelszintet vesz buszon, egy olyan mezőben, amelyet a bitbeszúrás szabályai alapján kellene kódolni. 2.10.3 Hiba felismerési képesség A hibafelismerő módszerekre azért van szükség, hogy az üzeneteket fogadók ellenőrizni tudják az érkező adat helyességét. A protokollok hiba-felismerési képessége elég változatos, függ az alkalmazott módszerektől. Az adatátviteli rendszerek adatintegritását erősen befolyásolják a rendszer működési körülményei (elektromágneses zavarások) és a rendszer hibafelismerő képessége. Az adatintegritás statisztikai mérőszáma az ún. maradó-hiba valószínűség, ami a felderítetlen hibás üzenetek valószínűségét adja meg. Ahhoz, hogy mérni tudjuk, hogy egy rendszer mennyire „hajlamos” a hibákra szükségünk van a bithiba valószínűség és az üzenetkeret-hiba arány fogalmainak tisztázására. A keretek hibaaránya megadja a hibás üzenetek arányát az összes elküldött üzenethez képest. Ezzel egy megfelelően hosszú megfigyelési periódust tudunk jellemezni. A valószínűsége, hogy egy átvitt üzenet egy bitje hibás a bithiba valószínűség. Természetesen a hibák (zavarások) nem feltétlenül érintik a hálózat összes csomópontját. A CAN-ben a lokálisan detektált hibákat globálisan jelzik a csomópontok a hibaüzenetek elküldésével. A megismert hibaellenőrzési módszerek kombinálásával a CAN protokoll meglehetősen kifinomult megoldást nyújt a hibák felismerésére. Minden a vezetékezéssel kapcsolatos, tehát globális hiba felismerhető a küldő csomópont bitellenőrző módszerével. A lokális, vevőkben előforduló hibákat a CRC 51

ellenőrzés szűri ki. Akár öt véletlenszerű hibát, vagy egy maximum 15 bites löketszerű hibát képes jelezni egy kereten belül. Ezek alapján a CAN kódolásának 6 a Hamming távolsága32, míg más terepbuszoknál ez általában 4, vagy kevesebb. Kimerítő elemzésekkel után megállapítható, hogy a CAN maradó-hiba valószínűsége a következő szabállyal közelíthető (2.18): Maradó-hiba valószínűség < 4,7 *10 11 * Üzenetkeret-hiba arány (2.18) Ezen összefüggés alapján kiszámolható egy CAN-es rendszer élettartama alatt előforduló fel nem derített hibák száma. Példa1: Bit ráta: 100 kBit/s Átlagos busz forgalom: 30% Átlagos üzenethossz: 85 bit Éves működési idő: 2200 óra 3

Átlagos hiba arány: 10 3,1 *10 9 db üzenet évente 3

maradó hiba valószínűség < 4,7 *10 11 *10 = 4,7 *10 14 A példában szereplő hálózatra vonatkozóan ez azt jelenti, hogy megközelítőleg 6800 évente marad 1 felderítetlen hiba. 2.10.4 Hibaforrás megszüntetése A hagyományos pont-pont vezetékezés helyetti buszstruktúra alkalmazása új problémákat vet fel. Az egyik, hogy egy hibás működésű csomópont akár az egész rendszert blokkolhatja aktív hibaüzenetek (2-31. ábra: Aktív hibaüzenet) küldésével. Ennek elkerülésére vezettek be a CAN protokollban egy hibaelszigetelési algoritmust. Ez alapján a rendszer automatikusan szabályozza a csomópontok „jogait”, akár le is kell kapcsolódniuk a hálózatról. Az algoritmus alapja két számláló, a küldési hibaszámláló (Transmit Error Counter = TEC) és a fogadási hibaszámláló (Recieve Error Counter = REC). Ezek értéke minden sikeres küldés/fogadás után meghatározott értékkel csökken, és minden sikertelen művelet után növekszik. A számlálók aktuális értéke szerint a csomópontoknak 3 féle állapotuk lehetséges:  „hiba aktív” A „hiba aktív” állapotban lévő csomópont részt vehet a kommunikációban, és aktív hibaüzenetet küldhet, ha hibát észlel.  „hiba passzív” A csomópont számlálóinak egyike már átlépte a kritikus határt, még aktívan részt vehet a kommunikációban, de tilos aktív hibaüzenetet küldenie. Ha hibát észlel, akkor csak passzív hibaüzenetet küldhet, és csak a küldés felfüggesztés mező után kezdheti meg egy másik üzenet küldését.  „busz off” A „busz off” állapotban lévő csomópontnak semmiféle hatása sincs a buszon történő kommunikációra, a csomópont kimeneti meghajtója pedig 32

bizonyos nagyon ritka esetekben, bitbeszúrási hibáknál ez csak 2

52

ki van kapcsolva. Az, hogy fogadhat-e üzeneteket, az implementációtól függ. A 2-36. ábraán egy csomópont állapot diagramja látható. Elinduláskor a számlálók értéke 0, a csomópont „hiba aktív” állapotban van. Ha valamelyik számláló értéke átlépi a 127-et, „hiba passzív” állapotba kerül a csomópont. Ha újra 128 alatt van mind a két számláló, a csomópont visszatérhet a kiindulási állapotba. 255-ös TEC érték esetén a csomópont lekapcsol, „bus off” állapotba kerül. Innen csak újraindítás, újrakonfigurálás esetén térhet vissza „hiba aktív”-ba, de akkor is csak azután, hogy 128-szor érzékel 11 egymást követő recesszív bitet a buszon. Ez az utóbbi számolási szabály biztosítja, hogy egy hibás csomópont téves felébresztése se okozzon fennakadást még legalább 128 keret elküldéséig. A hibaszámlálók szabályainak megalkotásakor szempont volt, hogy egy hibát elsőként detektáló csomópont súlyozottan nagyobb „büntetést” kapjon, mint a többiek. A másik fontos tényező volt, hogy az algoritmus képes legyen csökkenteni a számlálókat is, hogy az ideiglenes magasabb hiba előfordulási arányt túlélő csomópontok visszatérhessenek aktív állapotukba. A hibaszámlálók a következő szabályok szerint változhatnak (2-38. ábra): 1. Ha a fogadó-csomópont hibát érzékel, akkor a fogadási hibaszámláló értéke eggyel nő kivéve, ha ez a hiba egy aktív hibajelző vagy egy túlcsordulás jelző küldése alatt bekövetkező bithiba. 2. Ha a fogadó-csomópont a saját maga által elküldött hibaüzenet utáni első bitet domináns bitként érzékeli, akkor a fogadási hibaszámláló értéke 8-cal nő. 3. Ha a küldő-csomópont küld egy hibaüzenetet, akkor a küldési hibaszámláló értéke 8-cal nő. A következő kivételek esetén a küldési hibaszámláló értéke nem változik:  1-es kivétel: Ha „hiba passzív” állapotban lévő küldő-csomópont nyugtázási hibát érzékel, és nem detektál domináns bitet a hibához tartozó passzív hibaüzenetet elküldése alatt.  2-es kivétel: Ha az arbitrációs mezőben történt bitbeszúrási hiba miatt a fogadócsomópont hibaüzenetet küld. 4. Ha a küldő-csomópont bithibát érzékel, mialatt aktív hibaüzenetet vagy túlcsordulás üzenetet küld, akkor a küldési hibaszámláló értéke 8-cal nő. 5. Ha a fogadó-csomópont bithibát érzékel, mialatt aktív hibaüzenetet vagy túlcsordulás üzenetet küld, akkor a fogadási hibaszámláló értéke 8-cal nő. 6. Minden csomópont 7 egymást követő domináns bitet tolerál aktív hibaüzenet, passzív hibaüzenet és túlcsordulás üzenet küldése után. Minden küldő-csomópont a küldési hibaszámlálójának értékét és minden fogadócsomópont a fogadási hibaszámlálójának értékét 8-cal növeli a következő esetekben: aktív hibaüzenet vagy túlcsordulás üzenet után 14 egymást követő domináns bit következik; passzív hibaüzenet után 8 egymást követő domináns bit következik; valamint minden egyes 8 egymást követő domináns bit szekvencia után. 7. Minden helyesen elküldött, nyugtázott üzenet a küldési hibaszámláló értékét eggyel csökkenti, ha nem nulla.

53

8. Minden helyesen fogadott, nyugtázott üzenet a fogadási hibaszámláló értékét eggyel csökkenti, ha a számláló értéke 1 és 127 között van. Ha nulla, akkor nem változik az értéke. Ha nagyobb, mint 127, akkor a számláló értékét 119 és 127 közé állítja be.

„Fogadási hibaszámláló” > 127 vagy 127 < „Küldési hibaszámláló”

„hiba passzív” állapot

„hiba aktiv” állapot

Küldési hibaszámláló > 255

„busz off”

Küldési és fogadási hibaszámláló <= 127

Újrainicializálás és 128-szor 11 egymást követő receszív bit érzékelése a buszon

2-36. ábra CAN csomópontok állapotdiagramja

3 Hardvereszközök bemutatása 3.1

Softing CANcard2

Ahhoz, hogy különböző eszközöket, komponenseket kapcsoljunk a CAN hálózatra, nagyteljesítményű szoftver és hardver interfészekre van szükség. A CAN adatforgalomnak PC-vel történő valósidejű feldolgozásához az adatfolyamot az interfésznek már előzetesen fel kell dolgoznia és pufferelnie kell. A német Softing AG. CANcard2 kártyája egyike az ezt elvégezni képes, intelligens eszközöknek. A kártya a számítógép PCMCIA csatlakozójára illeszthető, saját mikrokontrollerrel rendelkezik (Siemens SAB C165). A Philips SJA1000 CAN kontrollerei segítségével egyidejűleg két független CAN hálózathoz szolgálhat csatlakozófelületként. A fizikai interfész két nagysebességű, ISO 11898-nak megfelelő CAN interfész, amely az adapter kábelen lévő két 9 tűs, szabványos (CIA) kiosztású D_SUB csatlakozón keresztül köthető a hálózatba. A fogadott és küldött üzenetek pufferelése és szűrése tehermentesíti a számítógépen futó alkalmazást, megkönnyítve így a valósidejű adatfeldolgozást. Lehetőség van az alkalmazás bizonyos részeinek a kártya saját processzorán történő futtatására. A PC-vel való adatcsere DPRAM-on keresztül történik. Az eszköz C meghajtókönyvtára segítségével a PC alapú alkalmazások beágyazhatók a CAN hálózatokba. Az alkalmazás-programozási felület (API) egy 32 bites DLL, amely Windows alapú alkalmazások fejlesztését teszi lehetővé. A meghajtó-könyvtár és az API a következő lehetőségeket nyújtja:  CAN chipek inicializálása  CAN paraméterek beállítása (bitráta, kimeneti vezérlés stb.)  Adatkeretek és adatkérő üzenetek átvitele, időbélyeggel ellátott megerősítéssel (megszakítások használatának lehetőségével is)  Időbélyeggel ellátott adatkeretek valamint adatkérő üzenetek eseményvezérelt fogadása (megszakítások használatának lehetőségével is)  Adatkérő üzenetekre automatikus válasz küldésének lehetősége

54

  

Üzenetek szűrése Hibakeretek felismerése Busz állapotának felismerése (hiba aktív, hiba passzív)

A CANcard2 a CAN üzenetkezelésre nézve kétféle üzemmódban használható: FIFO mód, valamint CAN objektum-puffer mód, az utóbbi lehet dinamikus illetve statikus. 3.1.1 FIFO mód Ebben az esetben a CAN busz és a számítógépen futó alkalmazás közötti kommunikáció a DPRAM-on keresztül sorosan, két FIFO felhasználásával történik, fogadó FIFO és küldő FIFO. A FIFO-ba legelőször beírt elem kerül legkorábban feldolgozásra (3-1. ábra). ALKALMAZÁS

ALKALMAZÁS-PROGRAMOZÁSI FELÜLET

FOGADÁSI FIFO

KÜLDÉSI FIFO

események, fogadott üzenetek, nyugták

küldendő üzenetek max. 256 bejegyzés

max. 256 bejegyzés

FIRMWARE

CAN 1

CAN 2

3-1. ábra: FIFO mód

A vett üzenetek, busz események valamint a sikeres küldésekre érkező nyugták a fogadó FIFO-n keresztül jutnak el a futó alkalmazáshoz. A küldendő üzenetek hasonlóképpen előbb a küldő FIFO-ba íródnak, majd onnan megfelelő sorrendben a buszra kerülnek. Mindkét FIFO maximum 256 bejegyzést

55

tartalmazhat. Ha a fogadó vagy a küldő tár betelik, azt az eszköz mikrokontrollere felismeri, az elveszett üzeneteket számolja és jelzi az alkalmazásnak. 3.1.2 Dinamikus objektum-puffer mód Ebben az üzemmódban a CAN üzenetek és az adataik négy objektumlistában tárolódnak, mindkét CAN csatornának egy küldési és egy fogadási listája van. Minden egyes lista 200 objektumot tartalmazhat. A listák bejegyzéseit, azaz a fogadni illetve küldeni kívánt üzeneteket az alkalmazás inicializáló rutinjában kell definiálni. Egy objektum egy CAN üzenet azonosítóját, és az adatmezejét tartalmazza. Az API az objektumokat definiálásukkor kapott objektumszámok alapján azonosítja. Bármelyik időpillanatban lehetőség van olvasni vagy írni az előre definiált objektum adattartalmát. A küldési igények, a fogadott üzenetek, átvitt üzenetek nyugtázása és az üzenetkérő keretek minden egyes objektumra nézve egyénileg engedélyezhetők, vagy letilthatók. Üzenet érkezésekor az mindig beíródik a megfelelő objektumlistába, azonban szűrési megfontolásból az, hogy értesíti-e erről az alkalmazást (pl. generálódik-e megszakítás), engedélyezhető illetve letiltható. Minden objektum beállítható úgy, hogy ha megfelelő azonosítójú üzenetkérő keret (remote frame) érkezik, akkor a kártya mikrokontrollere automatikusan elküldi a kért azonosító objektum pufferének adattartalmát egy adatkeretben, ezzel is tehermentesítve az alkalmazást. A különböző események kezelése, lekérdezése két módszerrel történhet: FIFO segítségével (a küldendő üzenetek egy FIFO-n keresztüljutnak el a mikrokontrollerhez majd a buszra illetve a fogadott üzeneteket FIFO-n keresztül kapja meg az alkalmazás), valamint az egyes objektumok egymás után történő lekérdezésével (polling). Lekérdezés használata esetén általában előbb az alacsonyabb objektum-azonosítójúakat, majd a nagyobbakat kérdezi le. Mivel az objektumok a definiálásuk sorrendjében egyre növekvő azonosítókat kapnak, így érdemes a definiálást az üzenetazonosítók sorrendjében elvégezni, megőrizve így az üzenetek prioritását az objektumok szintjén is.

56

ALKALMAZÁS

ALKALMAZÁS-PROGRAMOZÁSI FELÜLET Küldés nyugtája

Objektum adat

Fogadás

Objektum adat

Objektum adat

?

?

Küldési objektumlista

Küldési objektumlista

Fogadási objektumlista

Fogadási objektumlista

CAN 1

CAN 2

CAN 1

CAN 2

max. 200 bejegyzés

max. 200 bejegyzés

max. 200 bejegyzés

max. 200 bejegyzés

? FIFO/ lekérdezés

Fogadás

Fogadás

Küldés kérése

FIRMWARE

CAN 1

CAN 2

3-2. ábra: Dinamikus objektum-puffer mód

3.1.3 Statikus objektum-puffer mód A kártya statikus objektum-puffer módban csak 11 bites azonosítójú, azaz standard üzenetkeretek esetén használható. Ha a programban nem állítjuk be a fenti üzemmódok egyikét, akkor a kártya automatikusan ebben az üzemmódban fog működni. Ebben az esetben az 1. CAN porthoz tartozó üzenetek két objektumlistában tárolódnak (egy a fogadáshoz valamint egy a küldéshez), a 2. CAN port pedig FIFO módban üzemel. Azonban ebben az esetben a CAN1 objektum-listáiban a dinamikus objektum-puffer móddal szemben csak 11 bites, standard azonosítók férnek el. Ettől az eltéréstől eltekintve ebben az üzemmódban a CAN1-re érkező üzenetek fogadása, illetve az onnan küldeni kívántak továbbítása ugyanúgy történik, mint ahogy azt a dinamikus objektum-puffer mód esetén leírtam, CAN2 pedig a korábban leírt FIFO mód szerint működik.

57

ALKALMAZÁS

ALKALMAZÁS-PROGRAMOZÁSI FELÜLET

Küldés nyugtája

Küldés kérése

Objektum adat

?

Fogadás

?

Küldési objektumlista

Fogadási objektumlista

CAN 1

CAN 1

max. 2032 bejegyzés

max. 2032 bejegyzés

?

Küldés nyugtája

Fogadás

Küldés kérése

Fogadás, küldés nyugtája

Küldési FIFO

Fogadási FIFO

CAN 2

CAN 2

Küldés kérése

FIFO/ lekérdezés

Fogadás, küldés nyugtája

FIRMWARE

CAN 1

CAN 2

3-3. ábra: Statikus objektum-puffer mód

3.1.4 A FIFO és az objektum-puffer mód összehasonlítása Az objektum-puffer mód fő előnye a FIFO móddal szemben az, hogy egy objektum legutoljára fogadott adatai minden esetben a feldolgozó alkalmazás rendelkezésére állnak, még akkor is, ha a korábban fogadottakat még nem sikerült feldolgozni. FIFO mód használata esetén azonban ha lassú a feldolgozás és a vételi FIFO betelik, akkor az újonnan érkező üzenetek elvesznek. További előnye az objektum-puffer mód használatának az, hogy az objektumok adatai a fogadásuk után azonnal rendelkezésre állnak, abban az esetben is, ha még vannak fel nem dolgozott, korábban fogadott üzenetek. FIFO-t használva az újonnan fogadott üzenet a sor végére kerül, és csak akkor válik elérhetővé az alkalmazás számára, ha minden korábban fogadott üzenet feldolgozása megtörtént. A FIFO mód előnye az objektum-puffer móddal szemben az, hogy ha egy objektum feldolgozása még nem történt meg, akkor annak adattartalma nem íródik felül az újonnan érkező, megegyező azonosítójú üzenet adataival. Továbbá így nincs korlátozás a fogadható üzenetek számára és típusára vonatkozóan,

58

valamint a feldolgozó alkalmazásnak nem objektumazonosító párosításokkal foglalkoznia. 3.2

kell

az

üzenetazonosító-

SysTec USB-CAN modul [12]

A Sys-Tec electronic GmbH az amerikai Phytec AG német leányvállalata. Felhasználói megoldásokat terveznek, és implementálnak az elosztott automatizálás és a beágyazott rendszerek területén. Az általuk kifejlesztett USBCANmodul USB-n (Universal Serial Bus) keresztül csatlakoztatja a számítógépet a CAN – hálózathoz. Az eszköz alább (3-4. ábra) látható.

3-4. ábra: SysTec USB-CANmodul

Az USB legnagyobb előnye, hogy azonnali használatot biztosít a hot plug and play módszer kiaknázásával, azaz a csatlakoztatás után rögtön megkezdhetjük a munkát a számítógép újraindítása nélkül. Manapság már minden PC rendelkezik USB csatoló felülettel, így nem okoz gondot a modul használata mind asztali, mind hordozható számítógépek esetén sem. Főbb technikai jellemzők:  CAN interfész:  CAN controller: Philips SJA 1000  CAN transceiver: Philips PCA82C251 /High-speed CAN/  Optikai leválasztás  Standard és kiterjesztet formátumú üzenetkeretek küldése és fogadása  Programozható, maximum 1Mbit/s adatátviteli sebesség  768 CAN üzenet tárolására alkalmas puffer a modulon  4096 CAN üzenet tárolására alkalmas puffer a PC-n  9 tűs D-Sub csatlakozó (DS102 szerinti tűkiosztás)  USB interfész:  Maximum 12 Mbps adatátviteli sebesség  Méretek: 102x54x30mm

59

A modul dinamikusan csatolt könyvtára (Dinamically Linked Library, DLL) könnyű hozzáférést biztosít az alkalmazás-programozási felülethez (Application Program Interface, API). A DLL-en keresztül használhatjuk az eszközt, ez felügyeli a használatban lévő modulokat és fordítja le az USB adat csomagjait CAN üzenetkeretekre, és vissza. A DLL használatakor az eszköznek három lehetséges állapota van, és minden állapotban csak meghatározott utasításokat tud értelmezni. Ezek az állapotok, és az állapotátmenethez szükséges függvények láthatók következő ábrán: DLL betöltve

UCanDeinitHardware()

DLL_INIT

UCanDeinitCan()

HW_INIT

UCanInitHardware()

CAN_INIT

UCanInitCan()

DLL használaton kívül

3-5. ábra: A DLL állapotdiagramja

A DLL és az API a következő lehetőségeket nyújtja:  CAN chip inicializálása  CAN paraméterek beállítása (bitráta)  Adatkeretek és adatkérő üzenetek átvitele, időbélyeggel ellátott megerősítéssel  Időbélyeggel ellátott adatkeretek valamint adatkérő üzenetek eseményvezérelt  Üzenetek szűrése  Busz állapotának felismerése (hiba aktív, hiba passzív) A modulhoz Visual Basic, és C forráskódot mellékelnek, hogy megkönnyítsék a DLL funkcióinak teljes körű kihasználását. Az USB-CAN modul úgynevezett FIFO módban működik, azaz sorosan, két FIFO (küldő FIFO, fogadó FIFO) felhasználásával kommunikál. A FIFO-ba legelőször beírt elem kerül legkorábban feldolgozásra. A vett üzenetek, busz események valamint a sikeres küldésekre érkező nyugták a fogadó FIFO-n keresztül jutnak el a futó alkalmazáshoz. A küldendő üzenetek hasonlóképpen előbb a küldő FIFO-ba íródnak, majd onnan megfelelő sorrendben a buszra

60

kerülnek. Az alkalmazásban megfelelő lekérdezésekkel implementálni kell, hogy felismerje és jelezze az eszköz, hogy a fogadó vagy a küldő tár betelt.

FOGADÁSI FIFO fogadott üzenetek, nyugták max.768 bejegyzés + (4096 a PC-n)

A L K A L M A Z Á S

F I R M W A R E

D L L

C A N p o r t

KÜLDÉSI FIFO küldendő üzenetek

3-6. ábra: Az USB-CAN modul működése

3.3

National Instruments PCI-CAN/XS2

A hazánkban is jelen lévő amerikai óriáscég szoftverekkel, és hardverekkel is képviselteti magát az ipari automatizálás területén. CAN-es interfész családjukból talán a legérdekesebb az asztali számítógépekbe szerelhető PCI-CAN/XS2. A PCI helyre beépíthető kártya Philips SJA1000-es CAN kontrollerrel, és egy Intel 386EX beágyazott processzorral van felszerelve. A kártya két CAN porttal rendelkezik, valamint Real-Time System Integration (RTSI) busszal, amelyen keresztül több interfészt tudunk szinkronizáltan működtetni közös órával, és meghajtó jelekkel. A CAN-buszt szabványos 9 tűs D-Sub csatlakózón keresztül érhetjük el, melynek tűkiosztása DS102 szerinti. Az XS típusokban lehetőség van szoftveresen kiválasztani, hogy milyen fizikai rétegnek megfelelően működjön az eszköz:  High-Speed:  Philips TJA 1041-es transceiver  az ISO 11898-as szabványnak megfelelően 1 Mbit/s-ig működik  optikai leválasztás biztosítja az NI CAN hardver, és a PC védelmét

61



Low-Speed/Fault-Tolerant:  Philips TJA 1054A transceiver  Maximum 125 kbps sebesség  optikai leválasztás  hibatűrő képesség, automatikusan felismeri és kezeli a következő buszhibákat:  CAN_H vagy CAN_L szakadása  CAN_H vagy CAN_L tápfeszültségre zárása  CAN_H vagy CAN_L VCC-re zárása  CAN_H vagy CAN_L földre zárása  CAN_H és CAN_L összezárása  Single Wire  Philips AU5790  33,3 kbps sebesség normál, 83,3 kbps High-Speed módban  Egyvezetékes üzemmód miatt a buszról is kell áramellátást biztosítani A National Instruments kártyáinak programozásához teljes támogatást kapunk a cégtől. Kétféle API közül választhatjuk ki, hogy melyikkel kényelmesebb, célravezetőbb a feladatunk megoldása. A Frame API-val a CAN üzenetkeretek szintjén dolgozhatunk, az adatbájtokat nyers formájukban érhetjük el. Itt is választhatunk azonban egy magasabb és alacsonyabb szintű hozzáférés közül:  CAN Network Interface Object: magát a portot jelenti. A buszon érkező adatokat egy olvasási sorba (read queue) kerülnek. A buszra írni is a NI Objecten keresztül tudunk.  CAN Object: egy meghatározott üzenet azonosítót és a hozzátartozó adatbájtokat jeleni. Több CAN Objectet használhatunk egy NI Objecthez társítva. Ez a mód magasabb szintű hozzáférést jelent az adatokhoz, ugyanis az eszköz a háttérben olvassa (és írja) a buszt és külön olvasási sorokat tart fenn minden egyes CAN Object számára (más-más arbitrációs azonosító).

62

Start

Vége

Objektumok konfigurálása

Igen

Nem

Minden objektum le van zárva? Az összes használni kívánt objektum be van állítva? Nem

Igen Objektumok lezárása (ncCloseObject)

Objektumok megnyitása (ncOpenObject)

Igen

Az összes használni kívánt objektum meg van nyitva?

Nem

Befejezõdött a kommunikáció?

Igen Kommunikácó Kommunikáció indítása (ncAction)

- várakozás az adatra (ncWaitForState) - adat kiolvasása (ncRead) - adat írása (ncWrite)

3-7. ábra: A Frame API folyamatábrája

A Channel API más megközelítést használ. A CAN adatkeretek által hordozott jelértékek az alapja. A Channel API-ban úgy vannak megírva a célfüggvények, hogy azokkal akár közvetlenül a jelek által hordozott fizikai értékhez férhetünk hozzá. Ehhez az adatokat egy konfigurációs fájlból (akár Vector CAN adatbázis) lehet beolvastatni, vagy lehetőség van új létrehozására, ehhez is komoly segítséget nyújt mind az API, mind a kártyához járó MAX nevű program.

63

Inicializálás - jelek egy csoportjának kiválasztása - mintavételezési gyakoriság beállítása - működési mód kiválasztás - kommunikáció indítása Mode = Bemeneti időbélyeggel

Mode = Bemeneti Mode = Kimeneti

Olvasás

Írás

- a mintavételezési időtől függően olvas (ncRead)

- a mintavételezési időtől függően ír (ncWrite)

Időbélyegezett olvasás (ReadTimestamped)

Törlés - leállítja a kommunikációt - törli a konfigurációt

3-8. ábra Channel API folyamatábrája

Mind a két API esetében széles választék áll a rendelkezésünkre eldönteni, hogy milyen programozási nyelven akarjuk használni. C, C++, Visual Basic mellett természetesen a cég saját LabVIEW-s környezetet is biztosít az alkalmazásfejlesztéshez. 3.4

Philips SJA1000 CAN kontroller

Az SJA1000-es a már megismert CAN architektúrák közül a különálló (standalone) vezérlők közé tartozik, amely megfelel a CAN specifikáció 2.0B részében leírt követelményeknek. Kezeli a standard és a kiterjesztett formátumú üzeneteket, legyen szó adathordozó, adatkérő, hiba-, vagy túlcsordulás üzenetről. Hogy biztosítva legyen a vezérlő kompatibilitása a régebbi architektúrákkal két különböző működési móddal rendelkezik az SJA1000-es:  BasicCAN mód: ez az alapértelmezés szerinti mód, amely lehetővé teszi a régebbi kontrollerekre írt alkalmazások változtatás nélküli futtatását.  PeliCAN mód: ebben a működési állapotban képes kezelni az összes 2.0B szerinti üzenet formátumot, ezen kívül rendelkezik néhány kibővített funkcióval, amelyek a diagnózis, karbantartás, és hiba analízis területén teszik még hatékonyabbá a vezérlőt. A legfontosabb jellemzők:  Mindkét működési módban elérhető:  Programozható kimeneti vezérlő (minden fajta fizikai réteghez)  Maximum 1 Mbit/s-os bitráta  CAN 2.0B passzív mód  64 bájtos fogadási FIFO  24 MHz es órajel  PeliCAN módban: 64

 CAN 2.0B aktív mód  Küldési puffer 1 üzenetnek 11 vagy 29 bites azonosítóval  Kétfajta üzenetszűrési lehetőség  Kiolvasható hibaszámlálók  Programozható hiba-határértékek  Regiszter a hibakódok tárolására  Megszakítás generálás hiba esetén  Megszakítás az arbitráció elvesztése esetén  Egylépéses küldés funkció  „Néma” üzemmód  Automatikus bitráta felismerés A vezérlő több funkcionális blokkra osztható, ezek logikai helyzete, és kapcsolódása a 3-9. ábrán látható. A CAN mag végzi az üzenetek fogadását és küldését. SJA1000

Küldési puffer

Mikrokontroller

CAN mag (2.0B)

Interfész logika Elfogadási szűrő

Fogadási puffer

Adó-vevő terminál (transceiver)

3-9. ábra Az SJA1000-es blokk diagramja

Az interfész logika biztosítja a csatolási felületet a fő mikrokontroller (host controller) felé. Itt vannak implementálva az alapvető írási, olvasási vezérlések. A küldési pufferben egy teljes CAN üzenet tárolható. Amikor küldést kezdeményez a vezérlő, az interfész logika kiolvastatja a puffer tartalmát a CAN maggal. Üzenet érkezésekor a CAN mag párhozamos adattá konvertálja a bitfolyamot az Elfogadási szűrő számára. Ez a blokk dönti el, hogy a mikrokontroller elfogadja-e az aktuális üzenetkeretet. Minden elfogadott üzenet a Fogadási FIFO-ba kerül, ahol a működési módtól, és az adathossz kódtól függően legfeljebb 32 üzenet tárolására van lehetőség. Ez lényegesen csökkenti az elvesztett (feldolgozás nélkül a FIFO-ban felülírt) üzenetek számát. BasicCAN módban két 8 bites regiszter (Acceptance Code Register-ACR, Acceptance Mask Register, AMR) valósítja meg az elfogadási szűrőt. Ezzel a 11 bites azonosítók 8 legmagasabb helyi értékű bitjét hasonlítja össze, így a maradék 3 alsó bit miatt mindig nyolcas csoportokban lehet megadni az elfogadható üzenetek azonosítóit.

65

PeliCAN módban már nyolc 8 bites regisztert (ACR0 – ACR3, AMR0 – AMR3) használhatunk, ezeket is kétféleképpen. Vagy egy – egy hosszú, vagy két – két rövidebb maszkot és kódot állíthatunk be. A kettős szűrés előnye, hogy jelentősen csökkentheti a kiszűrni kívánt, de a szűrőnek mégis megfelelő üzenetek számát. A PeliCAN mód új funkciói közül érdekes az arbitráció elvesztését figyelő regiszter, amelyben azt a bitet tárolja el, amelynél az előző elküldeni kívánt üzenet elvesztette az arbitrációt a többi csomóponttal szemben. Ez az értéket egy megszakítás hatására írja be, és mihelyt a vezérlő kiolvasta, az arbitráció elvesztését figyelő funkció újra aktiválódik. A másik hasznos újdonság, hogy az SJA1000-es képes tárolni a buszon bekövetkező hiba típusát, és a fellépés helyét (az üzenetkereten belül) egy regiszterben. Az előző két tulajdonság kihasználásával lehetőség nyílik, hogy hatékonyan használhassuk az egylépéses küldést. Az egylépéses küldés azt jelenti, hogy a vezérlő a küldés megkezdése után nem vár a státuszbit visszajelzésére, hogy sikeres volt-e a művelet, hanem elláthatja egyéb feladatait. Így nincs automatikus újraküldés hiba fellépése, vagy az arbitráció elvesztése esetén, hanem a két előbb említett regiszter állapotának megváltozása esetén kezdeményezhető az. A „Néma mód” lényege, hogy a csomópont nem írhat domináns bitet a buszra, még hiba, vagy túlcsordulás esetén sem, sőt pozitív nyugtát sem küldhet. Ez a működési mód használható az automatikus bitráta felismeréshez is.

Tartalmi összefoglaló A monográfia célja megismertetni az olvasót az autóiparban leginkább elterjedt CAN protokoll főbb tulajdonságaival és működésének mechanizmusával. Az olvasó megismerheti a CAN hálózatok felépítését, használatát, valamint a CAN szabványnak azon részét, amely szükséges a CAN eszközök és programozási technikák működésének a megértéséhez. A írás rövid betekintést nyújt jelenleg piacon kapható CAN-es hardver és szoftver eszközökről. Részletesen bemutatásra kerülnek a National Instruments CAN-es eszközei és azok használatával kapcsolatos ismeretek. Megismerteti az olvasót azzal, hogy hogyan lehet több modulból felépülő programot készíteni, milyen módon lehet Dynamic Linked Library (DLL)-eket alkalmazni, azoknak adatot átadni. Kulcsszavak: Controller Area Network, CANAlyzer, National Instruments CAN Cards, valósidejű analízis, Dynamic Linked Library, időzítés

66

Irodalomjegyzék [1] ETSCHBERGER, K. (2001). Controller Area Network. IXXAT Press, Weingarten [2] FARSI, M. and BARBOSA, M. (2000). CANopen Implementation: applications to industrial networks. Research Studies Press Ltd., Baldock [3] ISO-WD 11898-1 (1999). Road vehicles – Controller area network (CAN) – Part 1: Data link layer and physical signalling. [4] ISO-WD 11898-2 (1999). Road vehicles – Controller area network (CAN) – Part 2: High speed medium access unit [5] ISO-WD 11898-3 (1999). Road vehicles – Controller area network (CAN) – Part 3: Low speed medium access unit [6] LAWRENCE, W. (1997). CAN System Engineering From Theory to Practical Applications. Springer-Verlag, New York [7] NATIONAL Instruments (2004). NI-CAN Hardware and Software Manual. National Instruments, Austin [8] PHILIPS Semiconductors (1997). SJA1000 Stand-alone CAN controller, Application Note. Philips Semiconductors, Eindhoven [9] PHILIPS Semiconductors (2000). SJA1000 Stand-alone CAN controller, Data Sheet. Philips Semiconductors, Eindhoven [10] ROBERT BOSCH GmbH (1991). CAN Specification 2.0. Robert Bosch GmbH, Stuttgart [11] SOFTING AG (2002). CANcard2 User Manual. Softing AG, Haar [12] SYSTEC Electronic GmbH (2004). USB-CANModul GW002, Systems Manual. SysTec Electronic GmbH, Mainz [13] K. Tindell, A. Burns, and A. J. Wellings, Calculating ControllerArea Network(CAN) message response times, Control Engineering Practice, vol. 3, no. 8, pp. 1163-1169 (1995). [14] Audsley, N., Burns, A., Richardson, M.,Tindell, K., and Wellings, A., “Applying New Scheduling Theory to Static Priority Pre-emptive Scheduling,” Software Engineering Journal 8(5) pp. 284-292 (September 1993) [15] Leung, J., and Whitehead, J., “On The Complexity of Fixed-Priority Scheduling of Periodic Real-Time Tasks” Performance Evaluation 2(4), pp. 237250 (December 1982)

67

[16] T. Nolte, H. Hansson, C. Norstrom, and S. Punnekkat. Using bit-stuffing distributions in CAN analysis. IEEE/IEE Real-Time Embedded Systems Workshop

68