A CAN buszrendszer

A Controller Area Network (CAN-busz) egy robusztus járműbusz-szabvány, amelyet arra terveztek, hogy a mikrokontrollerek és eszközök gazdaszámítógép nélkül kommunikáljanak egymás alkalmazásaival. Ez egy üzenetalapú protokoll, amelyet eredetileg az autókban lévő multiplex elektromos vezetékekhez terveztek, hogy megtakarítsák a rézhasználatot, de számos más környezetben is használható.

Ez volt az egyik első ilyen protokoll a járműiparban, mely a mai napig töretlenül jelen van a szegmensben.

Történeti áttekintés

A CAN busz fejlesztése 1983-ban kezdődött a Robert Bosch GmbH-nál. A protokoll hivatalosan 1986-ban jelent meg a Society of Automotive Engineers (SAE) konferencián a Michigan állambeli Detroitban. Az első CAN vezérlő chipeket 1987-ben az Intel, majd nem sokkal ezután a Philips vezette be. Az 1991-ben kiadott Mercedes-Benz W140 volt az első olyan sorozatgyártású jármű, amely CAN-alapú multiplex vezetékrendszerrel rendelkezett.

A Bosch a CAN specifikáció több változatát is közzétette, a legújabb pedig az 1991-ben kiadott CAN 2.0. Ez a specifikáció két részből áll; az „A” rész a szabványos formátumra vonatkozik 11 bites azonosítóval, a „B” rész pedig a kiterjesztett formátumra 29 bites azonosítóval. A 11 bites azonosítókat használó CAN-eszközöket CAN 2.0A-nak, a 29 bites azonosítókat használó CAN-eszközt pedig CAN 2.0B-nek nevezik. Ezek a szabványok szabadon beszerezhetők a Boschtól, más specifikációkkal és tanulmányokkal együtt.

1993-ban a Nemzetközi Szabványügyi Szervezet (ISO) kiadta az ISO 11898 CAN szabványt, amelyet később két részre strukturáltak; Az ISO 11898-1, amely lefedi az adatkapcsolati réteget, és az ISO 11898-2, amely lefedi a CAN fizikai rétegét a nagy sebességű CAN számára. Az ISO 11898-3 később jelent meg, és lefedi a CAN fizikai rétegét az alacsony sebességű, hibatűrő CAN számára. A fizikai réteg ISO 11898-2 és ISO 11898-3 szabványai nem részei a Bosch CAN 2.0 specifikációnak. Ezeket a szabványokat az ISO-tól lehet megvásárolni.

A CAN busz egyike annak az öt protokollnak, amelyeket az OBD-II járműdiagnosztikai szabványban használnak. Az EOBD szabvány 2001 óta kötelező az Európai Unióban értékesített összes benzinüzemű járműre, 2004 óta pedig minden dízelmotoros járműre.

Alkalmazások az autóiparban

A modern autók akár 70 elektronikus vezérlőegységgel (ECU) is rendelkezhetnek különböző alrendszerekhez. Hagyományosan a legnagyobb processzor a motorvezérlő egység. Mások autonóm vezetésre, fejlett vezetőtámogató rendszerre (ADAS), sebességváltóra, légzsákokra, blokkolásgátló fékrendszerre/ABS-re, tempomat, elektromos szervokormányra, audiorendszerekre, elektromos ablakemelők, ajtók, tükörállítás, akkumulátor és hibrid/elektromos töltőrendszerek használatára szolgálnak.

Az egyik legfontosabb előny az, hogy a különböző járműrendszerek összekapcsolása lehetővé teszi a biztonsági, üzemeltetési és kényelmi funkciók széles skálájának megvalósítását pusztán szoftver használatával – ez a funkcionalitás növelné a költségeket és a bonyolultságot, ha ezeket a funkciókat hagyományos elektromos eszközökkel „huzaloznák”. Erre számos példát hozhatnánk a start-stop rendszerektől az elektromos rögzítőfékeken át a parkolást segítő rendszerekig, és így tovább.

A CAN üzenet

A CAN busz egy broadcast típusú busz. Ez azt jelenti, hogy minden csomópont „hall” minden adást. Nincs mód arra, hogy csak egy adott csomóponthoz küldjünk üzenetet; minden csomópont mindig felveszi az összes forgalmat. A CAN hardver azonban helyi szűrést biztosít, így minden csomópont csak a számára releváns üzenetekre reagálhat.

A CAN rövid üzeneteket használ – a maximális segédprogram terhelés 94 bit. Az üzenetekben nincs kifejezett cím; ehelyett az üzenetek tartalom-címzettnek mondhatók, azaz tartalmuk implicit módon meghatározza a címüket.

Üzenettípusok

A CAN buszon négy különböző üzenettípus (vagy „keret”) található:

• Data Frame
• Remote Frame
• Error Frame
• Overload Frame

Data Frame

A leggyakoribb üzenettípus. A következő főbb részekből áll:

• Arbitration Field, amely meghatározza az üzenet prioritását, amikor két vagy több csomópont verseng a buszért. A választottbírósági mező a következőket tartalmazza:
• A CAN 2.0A esetén egy 11 bites azonosító és egy bit, az RTR bit, amely domináns az adatkeretek esetében.
• CAN 2.0B esetén egy 29 bites azonosító (amely két recesszív bitet is tartalmaz: SRR és IDE) és az RTR bitet.
• a Data Field, amely nullától nyolc bájtig terjedő adatot tartalmaz.
• a CRC mező, amely az üzenet legtöbb részén kiszámított 15 bites ellenőrző összeget tartalmaz. Ezt az ellenőrző összeget a hiba észlelésére használják.
• egy nyugtázási nyílás; minden CAN vezérlő, amely képes volt megfelelően fogadni az üzenetet, minden üzenet végén nyugtázó bitet küld. Az adó ellenőrzi a nyugtázási bit jelenlétét, és ha nem észlelt nyugtázást, újraküldi az üzenetet.

Remote Frame

A Remote Frame pont olyan, mint a Data Frame, két fontos különbséggel:

• kifejezetten remote frame-ként van megjelölve (az Arbitration Field RTR bitje recesszív), és
• nincs adatmező.

A Remote frame rendeltetése a megfelelő Data Frame továbbításának kérése. Ha mondjuk az A csomópont 234-re beállított választottbírósági mezővel remote frame-et küld, akkor a B csomópont megfelelő inicializálás esetén egy adatkerettel válaszolhat, amelynek az Arbitration Field értéke szintén 234.

A remote frame-ek kérés-válasz típusú buszforgalom-kezelés megvalósítására használhatók. A gyakorlatban azonban a Remote Frame-et kevesen használják. Azt is érdemes megjegyezni, hogy a CAN szabvány nem írja elő az itt vázolt viselkedést. A legtöbb CAN-vezérlő programozható úgy, hogy automatikusan válaszoljon egy remote framere, vagy ehelyett értesítse a helyi CPU-t.

A Remote Frame-nek van egy bökkenője: az adathossz-kódot a várt válaszüzenet hosszára kell beállítani. Ellenkező esetben az arbitráció nem fog működni.

Error Frame

Egyszerűen fogalmazva, az error frame egy speciális üzenet, amely megsérti a CAN üzenetek keretezési szabályait. A rendszer akkor továbbítja, amikor egy csomópont hibát észlel, és az összes többi csomópont hibát észlel – így ők is küldenek error frame-eket.

Az adó ezután automatikusan megpróbálja újraküldeni az üzenetet. Van egy kidolgozott hibaszámláló séma, amely biztosítja, hogy egy csomópont ne tudja tönkretenni a buszforgalmat az error frame-ek ismételt továbbításával.

Overload Frame

Az Overload Frame itt csak a teljesség kedvéért szerepel. A formátum tekintetében nagyon hasonlít az error frame-hez, és egy túl elfoglalt csomópont továbbítja. Az Overload Frame-et nem használják túl gyakran, mivel a mai CAN vezérlők elég ügyesek ahhoz, hogy ne legyen rá szükség. Valójában az egyetlen vezérlő, amely túlterhelési kereteket generál, a mára elavult 82526-os.