CAN-FD

A CAN berobbanása óta egyre több és több feladatot bíznak rá, a vezérlők száma is folyamatosan nő a gépjárművekben, ami gyorsabb működést vár el a kommunikációs rendszertől. A hagyományos CAN-üzenetek 8 byte-os adatmennyisége a nagy mennyiségű információ miatt már kevésnek bizonyul, ezért a szakemberek új kommunikációs eljárás alkalmazását tűzték ki célul. A FlexRay és Ethernet alapú kommunikáció lehetne a kézenfekvő megoldás, de ezek járulékos költségei (mind hardver és szoftver oldalon) miatt egy járható út maradt: gyorsabbá kell tenni a CAN-t. Ezen megfontolásból fejlesztette ki a Bosch a CAN-FD-t, amellyel egy üzenetben 64 byte adat kaphat helyet.

CAN-alapok

A mikroprocesszorokból felépülő vezérlőegységek kezdetben függetlenül működtek egymástól, külön érzékelő és beavatkozó rendszereikkel. A nagyobb számú és egyre több funkciót megvalósító vezérlőegységekben átfedések jelentek meg, ezért a kommunikáció elkerülhetetlenné vált közöttük. Ebből az következett, hogy a vezérlőegységek között nagy mennyiségű adat- és információcsere jött létre, ami a csatlakozók és kábelek számának növekedésével járt együtt. A nehezen kezelhető, nemcsak súlyra, de hosszra is tetemes (egy felsőkategóriás luxusjárműnél csupán a kábelezés körülbelül 100 kg tömegű, míg teljes hossza megközelítheti a 2–2,5 km értéket is!) kábelkorbácsok a sok vezetőér és csatlakozó miatt egyre megbízhatatlanabbá válnak. Mindezt tetézi, hogy a nagy járműgyártók nemcsak egyféle, hanem különböző modellsorozatokat készítenek, melyekhez sokszor több száz féle kábelkialakítást használnak a gyártósorokon. A kábelkötegek előállítása, szerelése, javítása is egyre költségesebb és időigényesebb, mindez a megbízhatóság csökkenését is eredményezi. Két megoldás látszott kivitelezhetőnek. Az egyik egy olyan központi vezérlőegységet építeni, ami minél több, eddig különálló vezérlőegységet foglal magában, ezáltal a köztük lévő kommunikáció nagyban egyszerűsödik.

A másik megoldás, hogy egy olyan soros buszrendszert definiálnak, ami megfelel a gépjárművekkel szemben támasztott biztonságkritikus követelményeknek. Végül négy megoldás valósult meg: VAN, a J1850 SCP, a J1850 DLC és a CAN. A kifejezetten gépjárművekben történő felhasználásra szánt és szabványosított CAN-rendszerek kialakítási és fejlesztési munkáinak legnagyobb részét a Bosch és az Intel cég tervezői végezték. Kialakulása óta egyre több feladat hárul rá, ezért folyamatosan fejlesztik, hogy megfeleljen a felmerülő kihívásoknak. A CAN-szabványok 5 V-os, mindkét végén ellenállással lezárt, kétvezetékes differenciál buszt írnak elő fizikai adathordozó közegnek, amely a szimmetrikus jelátvitel miatt nagy közös modusú zavarjelelnyomással rendelkezik. A buszra kapcsolódó egységeket csomópontnak (node) hívják. Az azonos buszon elhelyezkedő csomópontok azonos jogokkal rendelkeznek, egyik sem rendelkezik a másikhoz képest kitüntetett szereppel. A később ismertetésre kerülő üzenet alapú kommunikáció lehetővé teszi, hogy egy korábban kiépített buszra bármikor újabb 9 csomópontot fűzzünk fel, vagy egy régi csomópontot távolítsunk el, a rendszer átprogramozása nélkül. A CAN-busz felépítése az ➊. ábrán látható.

➊ A CAN-rendszer felépítése

A hagyományos CAN-üzenetek

A CAN-ről már sok cikk látott napvilágot az Autótechnikában is, most részletesen csak az átviteli sebességgel és az üzenet felépítésével foglalkozunk, hiszen a változások ezeket a területeket érintik a legjobban. Az átviteli sebesség 5 Kbit/s – 1 Mbit/s határok között választható, azzal a megjegyzéssel, hogy a felső határérték csak 40 m-nél rövidebb buszvonalak esetén közelíthető meg. Ez az átviteli sebesség azonban csupán akkor igaz, ha az egységnyi információk átviteléhez a legegyszerűbb NRZ (Non Return to Zero) bitkódot használjuk, amelyet feszültséggel realizálva, pl. egymás után következő igen, vagyis 1-es bitértékek között a feszültségszint nem esik vissza nullára, hanem „fennmarad” a magas szinten, és így egy bit átviteléhez egy időegység elegendő. Ez a bitkód viszont szinkronizálási problémákat vet fel az üzenetet adó, illetve vevő egységek között, melynek kiküszöbölése további intézkedéseket igényel.

A kábelek hosszával is összefüggésben van az átviteli sebesség, hiszen az adó által kiadott bit a jelterjedési idő miatt különböző késésekkel érkezik meg a különböző távolságra lévő vevőkhöz. Fontos, hogy az így kialakuló időkésedelem nem érheti el a bitidő felét, hiszen az üzenet visszaigazolása is ugyanolyan időkésedelemmel jár. Az alábbi táblázatban található maximális sebesség és távolság összefüggések megsértése helytelen beolvasást eredményez.

➋ A hagyományos CAN-üzenet felépítése

Az üzenet felépítése ➋ is fontos tényező abban, hogy időegység alatt mennyi információ továbbítható a rendszeren. A start-bit (SOF: Start Of Frame) az üzenetes első bitje, ami alapesetben magas (1) szinten van. Amennyiben valamelyik „node” üzenetet kíván küldeni, ezt a bitet alacsony, azaz „0” szintre húzza. Ez a szintváltozás azt eredményezi, hogy a többi résztvevő elkezdi figyelni az üzenetet, és megkezdik a szinkronizációt az üzenet feladójával. Hagyományos CAN-ről lévén szó, a rendszeren belül egyféle bitátviteli sebesség használata szokásos, de az ehhez szükséges „órajelet” minden résztvevő maga állítja elő. A bitek szinkronizálása az üzenetek start/stop keretezése mellett egy ún. „bit-stuffing” (bit-beszúrás) módszerrel történik, ami azt jelenti, hogy egymás után maximum öt bit lehet azonos polaritású. Ha egymás után öt vagy ötnél több azonos bitet kell átküldeni, akkor az adó az ötödik után beilleszt egy ellentétes polaritású bitet, a vevő ehhez szinkronizálja a belső órajelét, a beszúrt bitet persze a vevő eltávolítja a hasznos adatbitek közül (destuffing). Ahány lefutó él van egy üzenetben, annyiszor történik szinkronizáció a résztvevők között.

Az arbitrációs vagy más néven döntési bitmező (Arbitration Field) a buszhasználat jogosultságának eldöntésére szolgál. Az itt található 11+1 bit (CAN 2.0A) vagy 11+2+18+1 bit (CAN 2.0B) 2-es számbeli értéke dönti el, melyik üzenet élvez prioritást, mégpedig úgy, hogy a kisebb értékhez tartozik a nagyobb prioritás. Fontos, hogy nem az dönti el az üzenet fontosságát, hogy melyik résztvevő küldi, hanem maga az üzenet tartalma. Miután az összes résztvevő figyeli a vonalat (amelyik meg megszerezte, éppen üzenetet küld), az üzenet arbitrációs mezőjével a buszhasználati jogosultság eldöntésén kívül a címzés is megoldható, még ha indirekt formában is. Egyetlen esetben történhetne csak „összetűzés” két, a buszt használni igyekvő résztvevő között, ha mindketten ugyanazt az arbitrációs bitsorozatot ültetik a vonalra.

Ez a határeset azért fordulhat elő, mert a rendszerben nemcsak adatokat lehet egy üzenetben továbbítani (Data Frame), hanem adatkérést (Remote Frame) is végre lehet hajtani. Az arbitrációs mezőt a kontroll mező követi. Az ebben elhelyezkedő 6 bit tartalmazza a rendszerkódot, valamint azt az összegkódot, melyet az üzenetben soron következő adatmezőben található adat byte-ok képeznek. Mivel a CANrendszerben 0–8 byte között változhat az adatmező kitöltöttsége, ezért az adathossz előzetes megadására 4 bit elegendő. A maradék 2 bit közül az első (IDE) domináns (0) értéke azt tudatja a résztvevőkkel, hogy az alap CAN 2.0A rendszerben használt 11 bites arbitrációs formáról van szó, míg ennek recesszív (1) értéke a kibővített 29 bites CAN 2.0B rendszer üzenetére utal. A második bit (0) egy fenntartott (rezervált) bit, melynek a későbbi továbbfejlesztéseknél lesz jelentősége, értéke jelenleg domináns, azaz (0). A kontroll mező a hibafelismerésben is fontos szerepet játszik, hiszen közli a vevővel, hogy hány adat byte-ot tartalmaz az üzenet. Ha a vett üzenet adat byte száma eltér a kontroll mezőben megadott értéktől, akkor az átvitel közben hiba történt. A kontrollt az adat-bitmező követi (Data Field), ami 0–64 bitet tartalmazhat.

A gyakorlatban az adatmező legtöbbször 2–4 byte-ból áll. A következő 15+1 bitből álló mező a ciklikus redundancia vizsgálatához szükséges kód (CRC – Cyclic Redundancy Check Field), amit mindig az adó képez, az üzenet előre rögzített bitképe alapján. A CRC-bitek az üzenet bitjeiből származnak, egy matematikai műveletsor eredményeként. A vevő a fogadott üzenetből elkészíti ugyanazzal a matematikai művelettel a saját CRC-mezőjét, és a két CRC-mező összehasonlításával lehet következtetni arra, hogy a vétel hibátlan volt-e. A plusz 1 bit mindig recesszív (1), és a CRC-mező végét jelzi. A következő ún. nyugtázó mező (Acknowledgement Field) 1+1 bitből áll és arra szolgál, hogy a vett üzenet hibás vagy hibátlan voltát visszajelezze az üzenetet küldőnek. A két eredetileg recesszív bit közül jelző funkciója csak az elsőnek van. Mivel az adó által küldött üzenetet minden vevő figyeli, és ha bármelyik hibátlannak tartja, akkor ezt az első (ACK-Slot) bitet 1-es értékről átírja 0-ra, azaz dominánsra. Mint tudjuk, a buszon a recesszív bit mindig átírható dominánsra, így az adó, figyelve saját adását azonnal észleli, hogy legalább egy vevő hibátlannak ítélte a leadott üzenetet. Hibás üzenet esetén a vevő recesszív állapotban hagyja az ACK-Slot bitet, amiről az adó felismeri, hogy egyetlen vevőhöz sem jutott el kifogástalan üzenet, így azt meg kell ismételni. A második bit mindig recesszív, és csupán a nyugtázó mező végét jelzi. Az üzenet formátuma a keret vége (EOF End Of Frame) mezővel zárul. Ez 7 recesszív bitet tartalmaz, így ismeri fel a vevő, hogy az üzenet véget ért. Itt már nem érvényes a bitbeültetési szabály. A vevőnek időbe telik feldolgozni és eltárolni a kapott üzenetet, ezért egy Interframe Space-nek nevezett közbenső mező biztosítja, hogy legkorábban 3 bit elteltével jöjjön új üzenet.

A továbbfejlesztett CAN- – a CAN-FD – üzenetek felépítése

➌ A kommunikációs rendszerek átviteli sebessége és beépítési költsége közötti kapcsolat

A CAN-üzenetek gyorsabbá tételén kívül a mérnököknek adott volt a lehetőség egy Ethernet vagy FleyRay alapú kommunikációra, viszont ahogy a ➌. ábra is mutatja, ezeknek a költsége messze túllépi a CAN-FD-jét, ami éppen egy leheletnyivel kerül többe, mint a jelenlegi rendszerek. A CAN-FD rövidítés a Flexible Data Rate-ből ered, ami flexibilis (változtatható) adatátviteli sebességet jelent. A technológia kialakításánál az elsődleges szempont az volt, hogy úgy alkossanak gyorsabb rendszert, hogy a jelenlegi eszközöket tudják alkalmazni, és a programozási eljárás se változzon nagy mértékben. Így fogalmazódott meg az ötlet, hogy megpróbálják úgy növelni az átviteli sebességet, hogy az üzenet keretszerkezete megmaradjon, felépítése ne változzon, és mivel az adatmező tekinthető a legterjedelmesebb résznek, ezért annak csökkentésével szabadítható fel a legtöbb idő, valamint, ha az üzenet időbeli hossza nem is változik, akkor több információt tartalmazhat az üzenet ➍. A CAN-FD üzenetek felépítését mutatja az ➎. ábra. Látható, hogy az arbitrációs mező kiegészült, és a hagyományos elrendezésben feltartott bit, melyet EDL-lel jelölnek (Extended Data Length), recesszív állapota azt jelenti, hogy CAN-FD üzenetről van szó, ha állapota domináns, akkor pedig azt jelzi, hogy hagyományos CAN-üzenet érkezik. Az r0 és r1 biteket későbbi protokollvariánsokhoz tartják fenn, értékük domináns. A BRS-bit (Bit Rate Switch) recesszív állapota azt jelzi, hogy bitsebesség-változás következik. Ha értéke domináns, akkor nem változik a bitsűrűség. Az ESI-vel (Error State Indicator) jelölt hibaállapot-mutató bit recesszív állapota a hibamentes üzemet jelöli, a domináns állapot pedig aktív hibát jelez. Az adatmező 0–64 byte-ot tartalmazhat. A CRC-mező hossza az adatmennyiségtől függ. 16 byte-os adatmezőig 17 bitet tartalmaz a CRC-mező, annál több adat esetén pedig 21-et.

➍ A CAN-FD üzenet összehasonlítva a hagyományos üzenettel

➎ A CAN-FD üzenet felépítése

Ha nem üzenetküldés történik, hanem távoli adatkérés (RTR – Remote Transmit Request), akkor az a hagyományos CAN távoli adatkérés szerkezete szerint történik ➏.

➏ A CAN-FD adatkérő üzenet megegyezik a hagyományos CAN RTR üzenettel

A CAN-FD az előbb látottak alapján megfelelő utódja lehet a jelenlegi szabványoknak, a Bosch már megkezdte az új technológia standardizációját. A jelenlegi hardvereket nem kell módosítani, a jeladók és érzékelők programozása igényel csak bizonyos strukturális változást, és a költségek is kordában tarthatók. A Bosch nemcsak személyautókban, hanem autóbuszokban és tehergépjárművekben is teszteli a rendszert, lehetséges, hogy pár éven belül már sorozatgyártott autókban látjuk viszont a CAN-FD-t.

A flexibilis átviteli sebesség előnyét bemutatandó, végezzünk egy mintaszámolást, amelyben 32 byte adatot szeretnénk küldeni. Standard CAN átviteli sebesség 500 kb/s, az FD-sebesség pedig 2 MB/s. 4 hagyományos CAN-üzenet elküldése 1021 µs-ot vesz igénybe. Egy CAN-FD üzenet 32 byte adatot tartalmazhat, hogy időben ne lépje túl az 500 kbit/s-mal küldött 8 byte hosszát. Tehát a 32 byte 1 üzenetben elküldhető, így a segédbiteket elég egyszer elküldeni. Így a teljes üzenet 229 µs alatt ér célba. Ez azt jelenti, hogy ugyanolyan mennyiségű hasznos adat negyedannyi idő alatt ér célba, mintha hagyományos CAN-protokollt használtunk volna.

Érdekes számítás lehet még egy átlagos adatátviteli sebesség kiszámolása is, hiszen az üzenet különböző részeit más sebességgel továbbítja a rendszer. 32 byte-os adattal, 11 bit-es arbitrációs mezővel számolva, ha a sebesség 1 Mbit/s-ról 4 Mbit/s-ra nő az adatmező alatt, akkor átlagosan 3,1 Mbit/s-mal számolhatunk. Ez azt jelenti, hogy az adatmezőn történő 4-szeres sebességnöveléssel 3-szoros teljes sebességnövekedést sikerült elérni. Minél hosszabb az adatmező, átlagosan annál többet gyorsul az üzenetküldés.

A CAN-FD üzenet adatmezejének hossza és rendszersebesség kapcsolata