CAN - Controller Area Network

CAN on hajautettujen reaaliaikajärjestelmien tarpeisiin suunniteltu verkko. Tähän rooliin se sopii, koska se on luotettava ja riittävän nopea. Tärkeää on että se pystyy takaamaan ylikuormitystilanteissakin tärkeimpien viestien kulun. Lisäksi käytössä on useita keinoja virheiden havaitsemiseksi.

CAN-protokollapinossa on standardin mukaan vain kaksi kerrosta. Tämä rajoittaa verkon ominaisuuksia, mutta toisaalta tekee siitä yksinkertaisen ja pitää kehyksen pienikokoisena. Lisää ominaisuuksia CANiin saadaan kun otetaan käyttöön jokin korkeamman tason protokolla.

CANia käytetään laajasti teollisuudessa ja kulkuneuvoissa.

Johdanto

CAN on tietoverkko, joka on suunniteltu hajautettujen reaaliaikajärjestelmien tarpeisiin. Se on tietokoneverkkojen pikkuveli, jossa monia ominaisuuksia, jotka löytyvät myös tietokoneverkoista, mutta CANin suunnittelun lähtökohta oli erilainen kuin tietokoneverkoilla.

Alullepanijana oli autoteollisuus, joka tarvitsi verkkoa, johon voisi liittää useita elektronisia ohjausyksiköitä (ECU). Verkko välittäisi mittausdataa, jota useat verkon solmut tarvitsevat.

CANin kehitti saksalainen Robert Bosch GmbH vuonna 1986. Ensimmäisen piille toteutetun CAN-piiri toi markkinoille Intel seuraavana vuonna. [5]

CAN - Protokolla

CAN-protokolla on määritelty vuonna 1994 julkaistussa standardissa ISO11989 "Interchange of digital information -- Controller area network (CAN) for high-speed communication". Se kertoo miten digitaalista informaatiota voidaan välittää CAN-verkolla varustetuissa ajoneuvoissa nopeuksilla 125 kbit/s - 1Mbit/s. CAN on sarjaliikennöintiprotokolla joka tukee hajautettua reaaliaikaista säätöä ja multipleksausta. Standardi kuvaa yleisen arkkitehtuurin kerroksina ISO:n OSI-mallin mukaisesti. [3]

Kaapelina CANissa käytetään suojaatua tai suojaamatonta kierrettyä paria [3]. Joissakin uusissa CAN-piireissä tuetaan yhden johdon käyttöä [8]. CAN-verkko on myös mahdollista rakentaa valokuidusta.

CANin ja tietokoneverkkojen merkittävimpiä eroja on, että CAN-standardissa ei verkkosolmuilla ole lainkaan osoitteita. Sen sijaan viesteille annetaan tunniste, jonka perusteella sen data yksikäsitteisesti tunnistetaan [2].

CANille asetetut vaatimukset

Koska CAN alunperin suuniteltiin autoon, sen pitäisi olla luotettava joka tilanteessa, häiriöisessä ympäristössä ja sen pitäisi olla nopea, koska autojen laitteiden (sytytys, polttoaineen syöttö, ABS) säätö asettaa tiukat reaaliaikavaatimukset. Niitä tarvittaisiin useita jokaiseen autoon, joten niiden pitäisi olla myös edullisia hankkia ja asentaa.

CANin vikasietoisuus on liitetty ISO11898-standardiin, tosin vain suosituksena. CANin pitäisi suosituksen mukaan toimia, vaikka toinen kahdesta johdosta olisi poikki tai oikosulussa maihin tai jännitelähteeseen. [12]

Hajautettuja reaaliaikajärjestelmiä tarvitaan muuallakin kuin autoissa eikä CANille tunnu olevan kilpailukykyisiä vaihtoehtoja. CANin ominaisuuksia ovat virheiden luotettava havaitseminen, nopeus 1 Mbit/s ja sopivuus vaativiin olosuhteisiin. Nykyään CAN-järjestelmiä löytyy lääketieteellisistä laitteista, kaikeinlaisista maalla ja merellä liikkuvista koneista kokoonapanolinjoista ja hisseistä [5] teollisuuden prosessinohjauksista ja säätölaitteista.

CAN vs OSI

ISOn OSI-malli sisältää seitsemän kerrosta. CAN-protokolla sisältää näistä sovelluskerroksen lisäksi vain kaksi alinta. Tämän on pakko riittää, koska CAN on tarkoitettu pieniin verkkoihin, joissa solmut ovat melko yksinkertaisia yleiskäyttöisiin tietokoneisiin verrattuna. Seurauksina on, että kaikkien CAN-verkossa olevien solmujen pitää käyttää samaa tiedonsiirtonopeutta ja datan esitystapaa, dataa voidaan lähettää vain pieniä määriä nopeasti ja kaikki tämä joudutaan päättämään ohjelmointivaiheessa.

Ylemmän tason protokollat

CANille on tarjolla ylemmän tason protokollia useilta eri toimittajilta ja ne pyrkivät tarjoamaan korkeampaa luotettavuutta, verkon diagnostiikkaa ja yleiskäyttöisyyttä. Ne eivät yleensä ole keskenään yhteensopivia.

Kehykset

CAN-versiot CAN2.0A ja CAN2.0B ovat tällä hetkellä käytössä ja versiot ovat taaksepäin yhteensopivia. Erot versioiden välillä rajoittuvat kehyksen rakenteeseen.

CAN-protokolla tarjoaa neljä erilaista kehystä: datakehys tiedonvälitykseen, remote-kehys tiedusteluun, error (virhe)-kehys tiedonsiirtovirheistä ilmoittamiseen ja overload-kehys, jota käytettään ilmoittamaan, kun joku verkon solmuista ei ehdi käsitellä kaikkea sille tulevaa dataa. CAN-kontrollereiden kehittyttyä overload-kehystä ei enää käytetä.

Datakehys

Datakehys on tavallisin kehystyyppi. Hieman yksinkertaistettuna se sisältää kolme pääkenttää, jotka ovat Arbitration, Data ja CRC. Lisäksi on kontrollitietoa ja kuittausbitit (Acknowledge Slot).

Arbitration-kenttä määrää viestin prioriteetin, kun kaksi tai useampi verkon solmuista yrittää lähettää yhtäaikaisesti. Sen sisältö riippuu käytetystä CAN-versiosta. CAN 2.0A:ssa kentässä on 11 tunnistebittiä (Identifier) ja RTR-bitti joka on datakehyksissä aina dominoiva (eli arvo on nolla). CAN2.0B:ssä arbitration-kenttä sisältää RTR-bitin ja 29 tunnistebittiä. Tunnistebitteihin kuuluu SRR ja IDE, jotka molemmat ovat peittyviä (arvo on yksi).

Datakenttä sisältää nollasta kahdeksaan tavua dataa. Datan määrä kerrotaan kontrollikentän DLC-kentässä.

CRC-kenttä sisältää 15-bittisen tarkistussumman, jota käytetään virhetarkistukseen.

Mikä tahansa CAN-verkon solmu, joka on onnistunut vastaanottamaan viestin ilman virheitä lähettää kuittausbitin joka viestin lopussa. Lähettäjä tarkistaa kuittausbitin ja jos kukaan ei ole kuitannut viestiä niin se lähetetään uudelleen. [9] Kuittausbitin saaminen tarkoittaa, että ainakin yksi verkon solmuista on saanut viestin, mutta ei takaa, että yksikään sitä tarvitseva olisi sen saanut. Jos kukaan ei lähetä kuittausta, on tapahtunut kuittausvirhe ja lähettäjä yrittää automaattisesti lähettää viestin uudelleen.

Remote-kehys

Remote-kehyksellä on datakehykseen verrattuna vain kaksi eroa: se on merkitty remote-kehykseksi eli RTR-bitti on peittyvä ja datakenttää ei ole lainkaan.

Remote-kehyksen avulla viestiä odottava verkon solmu voi käynnistää viestin lähetyksen. Tällöin se lähettää remote-kehyksen, jonka tunniste on sama kuin viestillä jonka se haluaa. Remote-kehystä ei juuri käytetä. [9]

Error-kehys

Error-kehys eli virhekehys on erityinen viesti, joka rikkoo CAN-viestien kehysrakenteen sääntöjä. Se lähetetään, kun viestissä huomataan virhe ja aiheuttaa sen, että kaikki muutkin verkon solmut huomaavat virheen. Lähettäjä yrittää automaattisesti uudelleenlähetystä.

Error-kehys koostuu virhelipusta (Error-flag) jossa on 6 dominoivaa bittiä ja 8 peittyvää bittiä. [9]

Linkkikerros

OSI-mallin linkkikerros on jaettu kahteen osaan, jotka ovat LLC ja MAC. CANissa linkkikerros välittää suoraan sovellluskerroksessta tulevat viestit fyysiselle kerrokselle. Näin säästytään ylimääräiseltä prosessoinnilta ja kehysksen koko säilyy pienenä. Toisaalta suurten datamäärien lähettäminen ei onnistu kovinkaan helposti. MACin tehtäviin kuuuluu kontrolloida kehyksiä, osa virhetarkistuksista, virheistä ilmoittaminen, sekä tarvittavat toimet väylälle pääsemiseksi, vikojen selvittäminen ja niistä ilmoittaminen. LLC taas suodattaa tulevia viestejä, tarjotaa datan siirto- ja pyyntöpalvelun ja hoitaa virheistä toipumisen. [1]

Logical Link Control LLC

Linkkikerros välittää dataa verkosta sovelluskerrokselle sen tarvitsemaa dataa ja välittää sovelluskerroksen lähettämän datan kehyksinä fyysiselle tasolle.

LLC suodattaa verkosta luetut viestit. Suodatus tapahtuu tutkimalla viestin tunnistebittejä, joita on versiosta riippuen joko 11 tai 29. Tunnistebittejä verrataan CAN-piirin tietyssä suodatinrekisterissä olevaan arvoon [10], jota kutsun tässä maskiksi. Jos tullut viesti sopii maskiin sen data annetaan sovelluskerrokselle. Maskin avulla ei aina pystytä kaikkia turhia viestejä karsimaan, mutta sovelluskerros jättää turhat viestit huomioimatta.

Viestien tunnisteet joudutaan päättämään viimeistään ohjelmointivaiheessa. Uusien viestien lähettämiseksi tai vastaanottamiseksi joudutaan ohjelmat päivittämään. Vastaanottajien lisääminen CAN-verkkoon on helppoa koska muihin laitteisiin tai niiden ohjelmiin ei tarvitse tehdä muutoksia.

MAC

MAC suorittaa väylän allokoinnin. CANilla on käytössä CSMA/CD aivan kuten Ethernetissä. Se tarkoittaa kaikki verkon solmut kuuntelevat linjaa (Carrier Sense). Ne solmut joilla on lähetettävää saavat oloitaa silloin kun linja vapaa. Useampi solmu saattaa aloittaa yhtä aikaa (Multiple Access). Kun solmut lähettävät kehystä, ne kuuntelevat onko verkkossa heidän lähettämiään bittejä vai ei. Niin kauan kuin bitit täsmäävät lähettäminen jatkuu. Kun ne ensimmäisen kerran poikeavat, alkaa arbitrointi. [4] Arbitroinnilla selvitetään kenen viesti pääsee verkoon. Aina löytyy tasan yksi tälläinen viesti, jonka lähettäminen jatkuu loppuun asti.

Arbitrointi

Arbitroinnissa vertaillaan lähetettävänä olevien viestien arbitration-kenttää eli prioriteetteja. Arbitrointi perustuu siihen, että dominoiva bitti peittää peittyvän.

Se viesteistä jossa arbitration-kentän arvo pienin (eli prioriteetti on korkein) pääsee läpi. Arbitroinnissa hävinneet osapuolet jäävat kuuntelemaan voittaneen osapuolen viestiä ja yksikään viesteistä ei tuhoudu arbitroinnin takia (= NDBA, Non-Destructive bus access).

Viestejä tuhoamattomassa arbitroinnissa yhtään aikaa ei kulu hukkaan prioriteettitarkasteluissa ja tärkeimmät viestit pääsevät läpi aina ilman viivietä. Nämä ovat reaaliaikajärjestelmälle erittäin tärkeitä ominaisuuksia, varsinkin sillon kun verkkoa kuormitetaan voimakkaasti.

Jos kaksi verkon solmuista lähettäisi viestiä, joilla on sama tunniste, niin molemmat viestit tuhoutuvat. Siksi järjestelmää suunniteltaessa on pidettävä huolta, että kaikkilla verkon viesteillä on eri tunnusbitit.

Fyysinen kerros

ISO11898 määrittelee CAN-verkossa käytettävän impedanssiltaa 120 Ohmin suojattua tai suojaamatonta parikaapelia, mutta myös valokuituratkaisuja on olemassa. Liittimistä ei ole olemassa standardia.

CANissa käytetään väylätopologiaa [1]. Tosin tarjolla on myös CAN-hubeja, jotka mahdollistavat myös tähtitopologian. Verkkojen laajentaminen onnistuu CAN-toistimilla.

Käytettäessä parikaapelia johdoista käytetään nimityksiä High ja Low. Kun verkossa lähetetään arvoa nolla, on High-johdon jännite 3.5 Volttia ja Low:n jännite 1.5 Volttia. Kun verkkoon lähetetään arvoa yksi, on molempien johtojen jännite 2.5 Volttia. [6]

CANillä lähetystapa on kantataajuinen (baseband) [13]. Se tarkoittaa, että bittien jännitearvot johdetaan kaapeliin sellaisenaan ilman mitään koodausta tai modulointia.

Virheiden havaitseminen

Toisin kuin monet muut järjestelmät, CANillä ei kuittauksen perusteella pysty päättelemään menikö viesti perille vai ei. Kuittaushan voi tulla sellaiselta solmulta, joka viestiä ei edes tarvitse. Sen sijaan ilmoitetaan tapahtuneista virheistä. Lisäominaisuuksia saadaan ottamalla käyttöön sopiva ylemmän tason protokolla.

CAN-kontrollerit pitävät myös kirjaa tapahtuneista virheistä ja sen perusteella yrittävät päätellä onko kysymyksessä hetkellinen häiriö vai pysyvä vika. Virhetietojen perusteella ne voivat jopa pudottaa itsensä verkosta. [11]

Kehystasolla

CANin virheidenhavaitsemistavoista kehystasolla on mainuittu jo CRC ja kuittausvirhe, joka tapahtuu, kun kukaan ei ole saanut vastaanotettua viestiä oikein tai vastaanottajia ei ole lainakaan.

Näiden lisäksi suoritetaan kehystarkistus, jossa tarkastellaan kehyksen rakennetta ja kokoa. [5]

Bittitasolla

Sen lisäksi että lähettäjä tarkkailee verkkoa lähettämisen aikana, ylimääräisten bittien lisäämistä (Bit Stuffing) käytetään virheiden havaitsemiseen. Jos lähetettävässä viestissä on viisi bittiä samaa arvoa niin lähettäjä lisää perään yhden eriarvoisen bitin, jonka vastaanottaja sitten poistaa [7]. Bittien lisääminen ei koske error-kehyksiä. Bit Stuffing:in avulla varmistetaan myös riittävän usein tapahtuva tilanmuutos CAN-väylällä. Tilanmuutoksia tarvitaan pitämään bittiajastus kohdallaan.

Viitteet

[1]: Aladjem S, CAN - Networking for Real-Time Systems, 29.1.1998; <http://bbs.uniinc.msk.ru/tech1/1997/can/can.htm>
[2]: Anon, How CAN Works, 2.1.1997; <http://www.ncl.ac.uk/~nrauto/canworks.htm>
[3]: Anon, Interchange of digital information -- Controller area network (CAN) for high-speed communication; <http://www.sae.org/PRODSERV/stds/ISO11898.htm>
[4]: Bagschik P, An Introduction to CAN, 14.8.1998; <http://www.ime-actia.com/can_intro.htm>
[5]: CiA, Controller Area Network, 2.7.1998; <http://www.can-cia.de/ican4.htm>
[6]: Goodwin T, Controller Area Network and DeviceNet Technical FAQ's, 25.9.1998; <http://www.wmg.warwick.ac.uk/capabilities/can/faq.htm>
[7]: Kvaser AB, KVASER CAN Pages: Error Handling In CAN, 24.9.1998; http://www.kvaser.se/can/protocol/canerror.htm
[8]: Kvaser AB, KVASER CAN Pages: The CAN Physical Layer, 14.9.1998; http://www.kvaser.se/can/protocol/canphys.htm
[9]: Kvaser AB, KVASER CAN Pages: The CAN Protocol, 24.9.1998; http://www.kvaser.se/can/protocol/canproto.htm
[10]: NRTT Ltd, Frequently Asked Questions, 28.5.1997; http://www.nrtt.demon.co.uk/canfaq.html
[11]: Schofield M J, Controller Area Network - Error Handling, 12.7.1998; http://www.omegas.co.uk/CAN/errors.htm
[12]: Schofield M J, Controller Area Network - How CAN Works, 12.7.1998; http://www.omegas.co.uk/CAN/canworks.htm
[13]: Tang K H, Everything about Controller Area Network (CAN), 5.1.1998; http://www.csv.warwick.ac.uk/~esrpy/can1.htm

Lisätietoja

CiA, CAN in Automation

Paljon tietoa CANistä automaatiossa ylemmän tason protokollista

CANHUG, CAN Hydraulic User Group

CANin käytöstä hydraulisissa järjestelmissä