A Bosch által kidolgozott CAN (Controller Area Network) egy soros adatbusz, mely - bár járművekben való alkalmazásra tervezték - egyre terjed az automatizálásban is. A CAN-re fűzött eszközök száma már meghaladja a világban az 500.000-et. Itt az ideje, hogy a PID.hu-n összeszedjük a témával kapcsolatos alapismereteket!

can

Mire való, mire nem?

Mivel a buszon egy üzenet max. hossza 8 byte lehet, a felhsználás célszerűen az eszközbuszok terén valósítható meg. 8 byte-ba egy lebegőpontos szám is belefér, tehát analóg mérési adatok átvitele is megoldható. A CAN alkalmazásai között találhatunk a processz elemzős alkalmazásoktól a villamos szelephajtások terepi buszáig sok érdekességet. Ezek tipikus beágyazott eszközbusz megoldások. A CAN-en alapul pl. az Allen-Bradley DeviceNet-je is. Nem a CAN területe a rendszerbusz, ahol nagyobb adatcsomagokat kell mozgatni. Ez egyre inkább az Ethernet világává válik.

A CAN jellemzői röviden:

Kedvező költségű

  • kétvezetékes soros busz, 120 Ohm lezárással
  • maximális sebesség: 1Mbit/s (40 m-s buszhossznál)
  • áttehető más közegekre is (opto, rádió)

Megbízható

  • kifinomult hibaérzékelés és -kezelés
  • CSMA/CD hozzáférési rend
  • az üzenetek egyedi azonosítója tartalmazza a prioritást is
  • a hibás üzeneteket érzékeli és újra küldi
  • rendszerszintű adatkonzisztencia (minden eszköz értesül a hibáról)
  • a hibás egységek automatikusan kivonják magukat a kommunikációból
  • EMI elleni nagy védettség

Flexibilis

  • multi-master működés is megengedett
  • az eszközök könnyen le- és rácsatlakoztathatók (hot-swap)
  • az eszközök száma nincs korlátozva a protokoll által
  • broadcast lehetséges

Szabványosított ISO-IS 11898, ISO-IS 11519-2, ...

A fizikai szint

igazándiból nem része a CAN specifikációnak, de a leggyakoribb ma a sodrott érpár. A kétvezetékes, mindkét végén 120 Ohm-mal lezárt buszra párhuzamosan kapcsolódnak az eszközök. A CAN-ben minden eszköz olvas minden üzenetet. Az eszközök interfésze szimmetrikus, tehát nincs "föld" ill. "adat" vezeték. Az "1" jelnek a busz feszültség alatti állapota felel meg, "0" adásakor az eszköz szinte rövidre zárja a buszt. Így a "0" jel mindig felülírja az "1"-et. CAN szóhasználatban a "0" a domináns, "1" a recesszív állapot.

interface

Van prioritás!

A buszhoz való hozzáférést a Carrier Sense Multiple Acces with Collision Detection elv alapján kapják meg az eszközök. A busz szabaddá válásának érzékelésekor (Carrier Sense) mindegyik adni kívánó eszköz egyszerre kezdi az adást. A buszt az erősebb prioritású üzenetet adó nyeri el (ez az arbitráció), az üzenetének sérülése nélkül. Az alacsonyabb prioritású üzenetet később lehet továbbítani. Ez komoly különbség az Ethernet-hez képest!

Az arbitráció menete:

Képzeljünk el egy CAN buszt, melyen három node (A,B,C) működik. A busz szabaddá válásának pillanatában mindhárom adni kezd. (Adás közben folyamatosan ellenőrzik, hogy a busz feszültsége és az általuk adott feszültség egyezik-e. Ha nem egyezik, azt jelenti, egy másik node "0"-t ad, miközben ők "1"-et.) A jobboldali ábrán látható, hogy a startbitet szépen, szinkronban leadták, és - mivel nem mértek feszültségeltérést - folytatták az adást az üzenetük azonosítójának elküldésével. Az üzenetük első bitje azonos volt, így tovább folytatták az adást. A "B" node üzenetének 2. bitje "1" volt, míg a többieké "0". "B" node ekkor különbséget mér a buszfeszültség és az általa adott feszültség között, ezért önként és dalolva eláll a további adástól. "A" és "C" node tovább mérkőzik a buszért, "B" node a következő ciklusban újra pályázhat...

arbitracio

Frame, azaz keret

A CAN kommunikáció broadcast (mindenki veszi) üzeneteken alapul, amelyek lehetnek:

  • "Data frame"-ek (Adat csomag)
  • "Error frame"-ek (hiba csomag)
  • "Remote frame"-ek (Adatkérő csomag)
  • "Overload frame"-ek (túlterhelési csomag)

Normál esetben a küldő eszköz egy "data frame"-be csomagolva küldi el - max. 8 bájtos - üzenetét. A data frame felépítése a jobboldali ábrán látható. Vegyük sorra a keretet alkotó mezők funkcióját! A diagramban látható számok az adott mező hosszát jelölik, bitekben.

1: startbit, (mindig domináns) 2: azonosító, mely a tarta- lomra és a prioritásra is utal. Az újabb verziókban az adatkeretnek használható egy 18 bittel hosszabb azonosítójú (extended) verziója is. Ennek segítségével több információ tehető ide. 3: Remote Transmission Request, adatküldési kérelem, ami adat frame esetében mindig "0" 4: Identifikációs bit, adat keretnél "0" 5: Nem használt bit, "0" 6: Adatmező hossza bájtokban mérve 7: Adatmező, azaz a tartalom. Hossza tehát nem fix! 8: CRC, azaz ellenőrző összeg, az átviteli hiba érzékelésére 9: CRC vége, kötelezően "1" azaz recesszív. 10: Nyugtázás bit. Erről bővebben kell szólni: Ha a buszon bármely node sikeresen vette az üzenetet, a nyugtázás bit adásának idején "0"-ba viszi a buszt. Az adó innen tudja, sikerrel adott. 11: Nyugtázás vége. A nyugtázó node itt vissza kell hogy engedje a buszt recesszív állapotba. Így garantált, hogy sem egy esetleges busz rövid-zár, sem egy busz szakadás nem eredményez nyugtázást. Ha az üzenet nem került érvényesen nyugtázásra, a node megkísérli újra leadni a következő körben. 12: Keret vége, 7 bitideig tartó recesszív állapot. Nem a keret része már, de kötelező a keret után 3 bitnyi szünetet hagyni. (recesszív buszállapot)

dataframe

Ha a CRC nem passzol Amennyiben egy vevő node a CRC segítségével átviteli hibát állapít meg, egy hibaüzenetet ad a buszra. (Error frame). Ez a következőképpen néz ki: Az adat keret "CRC végjel" bitjétől kezdve 6...12 bitideig "0"-ba (domináns állapotba) viszi a buszt, majd 8 bitideig recesszív állapotban hagyja. Belátható, hogy a CRC hiba esetén kiadott hibajel egy másik, esetlegesen jól vevő node nyugtázását is lehetetlenné teszi, mivel a "nyugtázás vége" időben a busz nem megy vissza "1"-be. A hibás adatkeretből vett adatokat minden node megsemmisíti.

Hibafigyelés

A kommunikációhoz hasonlóan a hibakezelés is egyszerű és robusztus. Az előző részben ismertetett "error frame" azaz hibajel a következő esetekben generálódik:

  • CRC hiba (Előző rész)
  • Nyugtázás hiba (Ha senki nem nyugtázta az adást.)
  • Formai hiba (Ha domináns bitet érzékelnek a "fix 1" mezők valamelyikében.)
  • Bithiba (Ha az adó által adott és a buszról visszaolvasott jel nem egyezik.)
  • Beszúrási hiba. Erről részletesebben kell szólni: Mivel a CAN az átvitelre NRZ kódolást használ, az adó és vevő node-oknak szinkronban kell lenni. A szinkronozást a node-ok lefutó éleknél végzik. Az NRZ kódolásban pedig azonos bitek adásakor nincs szintváltozás. A CAN-ben előírás, hogy 5 azonos bit után be KELL szúrni egy szinkronozó bitet. (A vevő a beszúrt bitet eltávolítja, de szinkronozásra előbb felhasználja.) Ha 5-nél több bitideig nincs szintváltás, beszúrási hibáról beszélünk.

A fenti hibák érzékelése esetén az adó az üzenetet újra megpróbálja elküldeni az arbitrációs szabályok betartásával.

Túlterhelés

Elméletileg előfordulhat, hogy egy node túlterhelődik és nem képes újabb adatokat fogadni. Ezt ő egy "overload frame" adásával jelzi. Az overload frame a következőképpen épül fel: A túlterhelt node az előző keret végénél 6..12 bitideig domináns állapotba viszi a buszt, majd 8 bitidőn át recesszív állapotban hagyja.

Hibaállapotok

Minden CAN node-ban van két számláló: A Receive Error Counter (REC) és a Transmit Error Counter (TEC). Az első a vett hibákat, a második az adás közbeni hibákat számlálja. E két számláló tartalma határozza meg, a node milyen zavar-üzemállapotban van:

  • Error-active: Ez az üzemállapot azt jelenti, hogy a node üzembiztosan kommunikál. Az ilyen node-oknak jogukban áll error frame-eket adni, ha hibát észlelnek a buszon. Ha a két számláló valamelyike eléri a 128-at, a következő állapot áll be.
  • Error passive: Ekkor a node már nem küldhet error frame-eket, csak csendben figyelheti a buszt. (Mint a magyar küldöttek az EU parlamentjében...) Programozható számú sikeres üzenetvétel esetén a node CPU-ja resetelheti a két számlálóját, és visszaállhat "error-active" üzemmódba.
  • Bus-off: Ha a TEC értéke meghaladja a 255-öt és túlcsordul (8 bites), a node köteles önként leválni a buszról. Ennek az állapotnak csakis az eszköz inicializálása vethet véget.

error

Mennyi lehet a hibázás? Hogy ezek az alarm-üzemmódok nem túl gyakran váltogatják egymást egy jól üzemelő rendszerben, azt a következő adatok bizonyítják: Egy 25%-os terheltségű buszon, 500 kbps sebesség mellett, a hibázás statisztikai gyakorisága: 200 év.