Vissza a tudásbázishoz
Vissza a tudásbázishoz
Ezen rendszerek funkcióinak bonyolultsága elkerülhetetlenné teszi az adatcserét közöttük. A hagyományos rendszerekben az adatcsere dedikált adatvonalakon keresztül történik, de ezt a vezérlési funkciók bonyolultabbá válásával egyre nehezebb és drágább megvalósítani. A bonyolult vezérlőrendszerekben az összeköttetések száma tovább már nem növelhető.
Egyre több olyan rendszert is kifejlesztenek, amik több vezérlőeszköz együttműködését igénylik. Ilyen például az ASC, ahol a motor időzítése és a karburátor vezérlése működik együtt, hogy a meghajtott kerék megcsúszásakor csökkentsék a forgatónyomatékot. Egy másik példa az elektronikus sebességváltó vezérlés, ahol a sebességváltás a gyújtás precíz beállításával könnyíthető.
Ha figyelembe vesszük a járművek optimalizálására megcélzott további fejlesztéseket, szükségessé válik a vezérlőeszközök hagyományos összekötésének lecserélése. Ez csak a rendszer elemeinek egy soros buszrendszert használó hálózatával lehetséges. Ezért fejlesztette ki a Bosch a "Controller Area Network"-öt, amit szabványosítottak (ISO 11898) és sok félvezető gyártó kínál hozzá eszközöket.
A CAN használatakor az állomások (vezérlők, érzékelők és beavatkozók) soros buszon keresztül vannak összekapcsolva. A busz egy szimmetrikus vagy aszimmetrikus kétvezetékes áramkör, ami lehet árnyékolt vagy árnyékolatlan is. A fizikai átvitel elektromos paramétereit szintén az ISO 11898 szabvány specifikálja.
A CAN protokoll, mely az ISO/OSI hivatkozási modell adatkapcsolati rétegének felel meg, megfelel a járműipari alkalmazások valósidejű követelményeinek. A hálózat detektálja és kijavítja az elektromágneses zajokból eredő átviteli hibákat. Az egyszerű konfigurálás és a központi hibaellenőrzés szintén a hálózat előnyös tulajdonságai. A CAN rendszerek járművekben való használatának célja annak lehetővé tétele, hogy az állomások központi vezérlő számítógép használata nélkül tudjanak kommunikálni.
Az alváz elektronika és a kényelmet szolgáló elektronika is hálózatba kapcsolható. Erre példa a világítás, a légkondícionálás, a központi zár, a szék és a tükör beállítása. Itt a tipikus átviteli sebesség 50 kbps.
A közeljövőben a soros kommunikációt a mobil kommunikációban is alkalmazni fogják az autórádió, mobiltelefon, navigációs eszközök, stb. központi panelben történő összekapcsolására. A Prometheus projektben definiált olyan funkciók, mint a jármű-jármű ill. jármű-infrastruktúra kommunikáció, a soros kommunikáció további bővítését fogja igényelni.
Az adatátvitel megbízhatóságán túl az állomásokra eső alacsony kapcsolati költség is jelentős érv a CAN használata mellett. Az olyan alkalmazásokban, ahol a költség kritikus, felhasználhatjuk a sok gyártó által kínált CAN chipeket. A kompakt vezérlőchipek előnyösen használhatók fel például a kisfeszültségű kapcsolóberendezésekben.
Ha egy adott állomás CPU-ja egy vagy több állomásnak üzenetet akar küldeni, az átviendő adatokat és azonosítókat a hozzárendelt CAN chipnek továbbítja ("Make ready"). Ennyi a CPU összes feladata. Az üzenet összeállítása és elküldése a CAN chip feladata. Amint a CAN chip megszerzi a buszhozzáférés jogát ("Send Message"), az összes többi állomás veszi az üzenetét ("Receive Message"). A CAN hálózat minden állomása, mely helyesen vette az üzenetet, végrehajt egy elfogadási tesztet, hogy eldöntse, a vett adat neki szól-e ("Select"). Ha igen, feldolgozza ("Accept"), különben eldobja.
A tartalom orientált címzési sémának köszönhetően a rendszer és a konfiguráció nagyfokú rugalmassága érhető el. Nagyon egyszerűen lehet új állomást felvenni a hálózatba a többi állomás szoftverének vagy hardverének módosítása nélkül, ha az új állomások csak vevők. Mivel az adatátviteli protokoll nem használ fizikai címeket, broadcast és multicast üzenetek is küldhetők, és elosztott folyamatok is szinkronizálhatók: a több vezérlő által is igényelt mérési információt át lehet küldeni a hálózaton, így nincs szükség arra, hogy minden vezérlőnek saját érzékelője legyen.
A valósidejű feldolgozás adatainak sürgőssége nagyon különböző lehet: egy gyorsan változó mennyiséget (pl. a motor fogyasztása) sokkal gyakrabban kell átvinni, tehát kisebb késleltetéssel más lassan változó mennyiségekhez (pl. a motor hőmérséklete) képest.
Az átviendő üzenet prioritását az az azonosító határozza meg, melyhez az üzenet tartozik. A prioritási szinteket a rendszer tervezésekor binéris számokban kódolják, ez tehát nem változtatható dinamikusan. A legkisebb bináris szám jelenti a legmagasabb prioritást.
A buszhozzáférési konfliktusok az azonosítókon alapuló bitenkénti döntés módszerével oldhatók fel, melyeket minden állomás figyel. A "huzalozott ÉS kapcsolatnak" megfelelően, amikor a domináns állítás (logical 0) felülírja a recesszívet (logical 1), a buszhozzáférési versenyt is azok az állomások veszítik el, melyek átvitele recesszív, megfigyelése pedig domináns. Az összes "vesztes" a legmagasabb prioritású üzenet vevőjévé válik, és nem kísérli meg az átvitelt mindaddig, míg a busz ismét szabad nem lesz.
A CAN esetében a busz allokációt csak az átvitelre várakozó üzenetek határozzák meg, tehát az igény szerinti busz allokáció osztályába tartozik.
A hatékonyság vizsgálatának másik szempontja a buszhozzáférési eljárás lehet:
Az összes lehetséges átviteli kérés feldolgozásához a CAN protokollnak szavatolnia kell a kétértelműséget többszörös hozzáférés esetén. Ezt bitenkénti döntéssel valósítja meg, az üzenetek azonosítóit figyelve, legkésőbb 13 (standard formátum) vagy 33 (kiterjesztett formátum) bitidő alatt. Az üzenetenkénti döntéstől eltérően (CSMA/CD) ez az eljárás garantálja, hogy a buszon csak hasznos információk közlekednek.
A hozzáférés prioritásának az üzenet tartalmától való függésének köszönhetően a rendszer még a busz túlterhelésekor is hatékonyabb, mint a CSMA/CD vagy a tokenes protokollok: az elégtelen adatátviteli kapacitás ellenére minden létező kérést feldolgoz a rendszer, fontosságának megfelelő sorrendben (amit az üzenet prioritása határoz meg). A rendelkezésre álló átviteli kapacitás hatékonyan van felhasználva a hasznos adatok átvitelére, mivel a busz allokációs "rések" nagyon kicsik. A túlterhelés miatti rendszer összeomlás, mely előfordulhat a CSMA/CD protollnál, itt lehetetlen. Ezért a CAN a gyors, forgalomfüggő buszhozzáférést valósítja meg, ami non-destructive, mivel az üzenetek prioritásán alapuló bitenkénti döntést alkalmazza.
A non-destructive buzhozzáférés tovább osztályozható:
Az adatátviteli kérések kezelése fontosságuk sorrendjében történik a rendszer egészére nézve. Ez főleg túlterhelés esetén bizonyul hasznosnak. Valósidejű rendszerekben garantálhatók a kis egyedi késleltetési idők,
A standard formátumú üzenet a "start of frame" bittel kezdődik, ezt követi az "arbitration field", ami az azonosítót tartalmazza, és a "RTR" (remote transmission request) bit, ami azt jelzi, hogy az adott keret adat keret vagy adatot nem tartalmazó kérés keret-e. A "control field" az IDE (identifier extension) bitet tartalmazza, mely a standard és kiterjesztett formátum közül választ, 1 későbbi felhasználásra fenntartott bitet és - az utolsó 4 bitben - az adatmezőben levő adatbyte-ok számát. A "data field" 0-8 byte hosszú lehet és a "CRC field" követi, amit a keret a bithibák detektálására biztonsági ellenőrzésre használ. Az "ACK field" része az ACK slot (1 bit) és az ACK delimiter (1 recesszív bit). Az ACK slotban levő bit recesszív bitként kerül elküldésre, és domináns bittel azok a vevők írják felül, akik helyesen vették az adatot (pozitív nyugta). A korrekt üzeneteket a vevők az elfogadási teszttől függetlenül nyugtázzák. Az üzenet végét az "end of frame" mező jelzi. Az "Intermission" az egymást követő üzenetek közti minimális bitidőt adja meg. Ha egyik állomás sem jelentkezik hozzáférési igénnyel, a busz idle állapotban marad ("bus idle").
A CAN protockoll implementálja a bit szintű hibadetektálás két mechanizmusát is:
Ha legalább 1 állomás hibát detektál a fenti mechanizmusokkal, az aktuális átvitelt megszakítja egy "error flag" elküldésével. Ezzel elkerülhető, hogy más állomás esetleg elfogadja az üzenetet, és biztosítható az adatok konzisztenciája az egész hálózaton belül.
Miután a hibás üzenet átvitele megszakadt, az adó automatikusan újra megkísérli az átvitelt (automatikus ismétlés kérés). Ekkor ismét versengés támadhat a busz hozzáférés jogáért. Szabályként elfogadhatjuk, hogy az újraküldés a hiba detektálását követő max. 23 biten belül megkezdődik. Speciális esetekben a rendszer feléledési ideje 31 bitidő.
Bármennyire is hatékony ez az eljárás, egy meghibásodott állomás az összes üzenet átvitelét megszakíthatja, blokkolva az egész rendszert, ha nincs önellenőrzés. A CAN protokoll ezért tartalmaz egy mechanizmust a szórványosan előforduló és az állandó hibák megkülönböztetésére, és a hibás állomások beazonosítására.
Ez az állomások hibáinak statisztikai kimutatásából indul ki, kiegészítve az állomások saját hibáit felismerő mechanizmussal és egy olyan működési móddal, amikor a CAN hálózat többi részére nem gyakorol káros befolyást. Ezzel az állomás odáig is elmehet, hogy lekapcsolja magát a hálózatról.
A célt elérjük, ha az adatok megbízhatósága elég nagy vagy a megmaradó hibavalószínűség elég kicsi. Busz rendszer esetén az adat megbízhatósága alatt az átviteli hibák felismerésének lehetőségét értjük. A megmaradó hibavalószínűség annak a valószínűsége, hogy az átviteli hiba detektálatlan marad. Ennek olyan kicsinek kell lennie, hogy a rendszer élettartama alatt várhatóan ne legyen ilyen esemény.
A megmaradó hibavalószínűség kiszámításához fel kell mérni a potenciális hibalehetőségeket és az átviteli utat egy modellben kell leírni. Ha megállapítjuk a megmaradó hibavalószínűség bithiba valószínűségtől való függését 80-90 bit hosszú üzenetekre, akkor pl. egy 5-10 állomással rendelkező rendszer és 1/1000-es hibavalószínűség (1 hiba jut 1000 üzenetre) esetén, a maximális bithiba valószínűség kb. 0.02, aminek 10-13 megmaradó hibavalószínűség felel meg. Erre alapozva adott CAN hálózat esetén kiszámíthatjuk a detektálhatatlan üzenetek maximális számát.
Például ha egy CAN hálózat Mbps-os adatátviteli sebességgel működik a busz kapacitásának átlagosan 50%-os kihasználtsága mellett, 4000 órás teljes élettartamot és 80 bites átlagos üzenethosszt véve az összes üzenet száma 9 * 1010-re adódik. Ezért a detektálatlan átviteli hibák statisztikai száma legfeljebb 10-2. Másképpen fogalmazva: 8 órás napi működtetést alapul véve az év 365 napján működő rendszerben ha a hibavalószínűség 0.7, minden ezer évben 1 detektálatlan hiba fordul elő (statisztikai átlag)
Ezért a CAN protokollt kiterjesztették a 29 bites azonosító mező bevezetésével. Ez egyrészt a már létező 11 bites azonosítót (alap ID), másrészt a 18 bites bővítményt tartalmazza. Így a CAN protokoll két üzenetformátumot támogat: a StandardCAN-t (2.0A verzió) és az ExtendedCAN-t (2.0B verzió). Mivel együttesen használják ugyanazt a buszt, meghatározták, hogy melyiknek magasabb a prioritása abban az esetben, amikor különböző formátumú, de azonos alap azonosítójú üzenetek ütköznek. A standard formátumú üzenet prioritása mindig nagyobb, mint a kiterjesztett formátumú üzeneté.
A kiterjesztett formátumú üzeneteket támogató CAN vezérlők standard formátumú üzenetek forgalmazására is képesek. Ha olyan CAN vezérlőt is használunk, amelyik csak a standard formátumot támogatja (2.0A verzió), csak a standard üzenetet használhatjuk az egész hálózatban. A kiterjesztett formátumú üzenet ebben az esetben félreérthető lenne. Vannak azonban olyan CAN vezérlők is, melyek annak ellenére, hogy csak a standard formátumot támogatják, felismerik a kiterjesztett formátumú üzeneteket és figyelmen kívül hagyják azokat (2.0B passzív verzió).
A standard és kiterjesztett formátumú üzenetet az IDE bit (Identifier Extension Bit) különbözteti meg, mely standard formátumú üzenet esetén dominánsan, kiterjesztett formátum esetén pedig recesszíven kerül átvitelre.
Az RTR bit attól függően domináns vagy recesszív, hogy adat átvitelére vagy egy állomástól kért speciális üzenet beolvasására használjuk. A standard formátum RTR bitjének helyén az SRR (substitute remote request) bit kerül átvitelre a kiterjesztett formátumú keretek esetén. Az SRR bit mindig recesszív, biztosítandó, hogy azonos alap azonosítók esetén a standard formátumú keretnek legyen magasabb a prioritása a busz allokációs folyamatban.
A standard formátumtól eltérően a kiterjesztett formátumban az IDE bitet követi a 18 bites azonosító bővítmény, az RTR bit és a reserved bit (r1).
Az összes többi mező azonos a standard formátuméval.
Typically, CAN controllers with intermediate buffer have two reception and one transmission buffer. The 8-bit code and mask registers allow a limited acceptance filtering (8 MSB of the identifier). Suitable choice of these register values allows groups of identifiers or in borderline cases all IDs to be selected. If more than the 8 ID-MSBs are necessary to differentiate between messages then the microcontroller following the CAN controller in the circuit must complement acceptance filtering by software. CAN controllers with intermediate buffer may place a strain on the micro-controller with the acceptance filtering, but they require only a small chip area and can therefore be produced at lower cost. In principle they can accept all objects in a CAN network.
CAN controllers with object storage are designed to take as much strain as possible off the local microcontroller. These CAN controllers require a greater chip area, however, and are therefore more expensive. In addition to this, they can only administer a limited number of chips.
CAN controllers are now available which combine both principles of implementation. They have object storage, at least one of which is designed as an intermediate buffer. For this reason there is no longer any point in differentiating between basicCAN and fullCAN.
Vissza a tudásbázishoz