Introducere ………………………….. ………………………….. ………………………….. …………………………….. [602310]

Controller Area Network
Magistrala CAN
Rolland Molnar
UNIVERSITATEA IOAN S LAVICI

1
Cuprins
Introducere ………………………….. ………………………….. ………………………….. ………………………….. …………. 2
Istorie ………………………….. ………………………….. ………………………….. ………………………….. ……………… 2
Versiuni ………………………….. ………………………….. ………………………….. ………………………….. …………… 3
Domenii de utilizare ………………………….. ………………………….. ………………………….. ………………………….. 4
Automobile ………………………….. ………………………….. ………………………….. ………………………….. ………. 4
Altele ………………………….. ………………………….. ………………………….. ………………………….. ………………. 4
Detalii de funcționare ………………………….. ………………………….. ………………………….. ………………………… 6
Standardul CAN ………………………….. ………………………….. ………………………….. ………………………….. … 6
CAN Standard sau Extended ………………………….. ………………………….. ………………………….. ……………. 6
Tipuri de mesaje ………………………….. ………………………….. ………………………….. ………………………….. .. 8
Arhitectura ………………………….. ………………………….. ………………………….. ………………………….. ………. 8
Concluzii ………………………….. ………………………….. ………………………….. ………………………….. ……………. 10
Bibliografie ………………………….. ………………………….. ………………………….. ………………………….. ………… 11

2
Introducere
Istorie
Magistrala CAN (Controller Area Network) a fost dezvoltat de BOSCH, ca un sistem multi –
master, pentru difuzarea mesajelor cu o rat ă maximă de semnalizare de 1 megabit pe
secundă (bps). Spre deosebire de o rețea tradițională, cum ar fi USB sau Ethernet, CAN nu
trimite blocuri mari de date punct -la-punct de la nodul A la nodul B sub supravegherea unui
master al magistralei. Într -o rețe a CAN, multe mesaje scurte precum temperatura sau RPM
sunt transmise către întreaga rețea, ceea ce asigură consistența datelor în fiecare nod al
sistemului.
Etape importante din istoria dezvoltării protocolului CAN:
1983 – demararea dezvoltării de către B osch Gmbh
1985 – prima versiune de specificație a protocolului
1986 – începerea standardizării protocolului de către ISO
1987 – introducerea primului circuit integrat CAN (Intel & Philips)
1991 – publicarea versiunii a doua a specificației protocolului
1992 – apariția primului automobil de serie ce utilizează protocolul CAN (Mercedes Benz,
clasa S)
1993 – publicarea primului standard al protocolului (ISO 11898)
2007 – producția anuală de module CAN atinge valoarea de aproximativ 600 de milioane de
module
2012 – Bosch lansează CAN FD 1.0 sau CAN Flexible Data -Rate.
CAN-ul este unul dintre cele cinci protocoale utilizate în standardul de diagnoză a vehiculelor
(OBD) -II pentru diagnosticarea vehicul elor. Standardul OBD -II a fost obligatoriu pentru toate
autoturismele și camioanele ușoare vândute în Statele Unite începând cu anul 1996.
Standardul EOBD a fost obligatoriu pentru toate vehiculele pe benzină vândute în Uniunea
Europeană începând din 2001, iar toate vehiculele diesel începând cu 2004.
Magistrala CAN este ideală pentru multe protocoale industriale de înalt nivel care folosește
CAN și ISO -11898: 2003 ca strat fizic. Costul, performanța și capacitatea de îmbunătățire
asigură flexibilitate ext raordinară în proiectarea sistemului.
Principalele cerințe ale aplicațiilor industriale pentru care a fost realizat conceptul CAN sunt:
– transmiterea multiplexata de pachete scurte de date de maximum 10 octeți ;
– semnalarea erorilor la recepție si imple mentarea unor proceduri de corecție ;
– asigurarea unui înalt nivel de siguranță a datelor;
– performante de viteza acceptabile (pana la 1Mbit/s);
– preț de cost al implementării redus prin linii de comunicații seriale;
– noduri ușor de implementat prin con troloare standard;

3
– implementare hardware a protocoalelor de nivel jos;
– implementare software a protocoalelor de nivel înalt ;
– încărcarea cat mai redusa a calculatorului front -end spre rețeaua CAN;
Versiuni
Specificația CAN, versiunea 1.0 a apărut in 1985.
Versiunea 1.1 din 1987 a refăcut o serie de modificări in specificațiile intervalelor de timp pe
bit.
Versiunea 1.2 din 1990, care este varianta cea mai răspândită si astăzi , a permis tolerante mai
mari la variațiile de viteza ale secvenței recepționa te.
Versiunea 2.0 din 1991 este compusa din 2 părți , partea A si partea B, dintre care partea A
este chiar versiunea 1.2 din 1990, păstrată astfel integral. Partea B definește un format
suplimentar opțional “extins”, care permite performante de multiplexar e in plus fata de cele
deja definite.
Intre versiunile 1.0 si 1.2 s -au adus numai modificări minore: versiunea 1.1 a schimbat
specificațiile privind cerințele pentru intervalele de timp in secvențele de semnale, pentru a
creste performantele si a ușura detecția ; versiunea 1.2 a adus câteva modificări la
interpretarea biților dominanți si a fost mărita toleranța sincronizării , permițându -se
implementări cu oscilatoare ceramice in locul celor cu cristale de cuarț .
Versiun ea 2.0 partea B a fost introdus ă pentr u a permite extinderea la un format nou,
opțional , care sa permită compatibilitate conceptului CAN cu cerințe de pe piața americana a
fabricanților de automobile. La aceasta categorie de aplicații sunt specificate rețele pentru
viteze de peste 100 Kbit/s ( denumite acolo “de clasa C”). Modificările s-au introdus la
procedurile de adresare, prin extinderea posibilităților de la un câmp de 11 biți la unul de 29
biți. Cu folosirea unui identificator de 29 biți se poate implementa o strategie de prelucrare a
mesajelor similara cu cea publicata de SAE (societatea inginerilor americani de automobile
– American Society of Automotive Engineers ) in specificația de protocol J1850, recomandata
pentru a fi aplicată in rețele de viteze mai mici (sub 100 Kbits, denumite de clasa A si B).

Ulterior, comitetul SAE -J1939 a acceptat conceptul CAN pentru autobuze , camioane, mașini
agricole si de construcții si l-a desemnat ca fiind destinat rețelelor de clasa C, respectiv pentru
250 Kbits/s, folosind avantajul unui spațiu de ad rese mult mai mare al formatului extins, ceea
ce permite standardizarea identificatorilor de mesaj folosiți in adresare.
Cu toate adăugirile si modificările specificațiilor CAN, majoritatea aplicațiilor folosesc formate
normale si proceduri standard, a căror stabilitate in t imp le confirma eficiența si le asigur ă o
compatibilitate excelent ă.

4
Domenii de utilizare
Scopul inițial al protocolului CAN a fost de a fi utilizat în industria automobilelor. Datorită
avantajelor pe care le aduce, în ceea ce privește comunicarea între modulele electronice, acest
protocol este utilizat și în alte industrii/domenii:
– vehicule grele, camioane, vehicule agricole
– industria roboților, automatizări
– industria aeronautică, aeronave
– vehicule militare
– echipamente medicale
– electroc asnice

Automobile
Automobilul modern poate avea p ână la 70 de unit ăți electronice de comand ă (ECU) pentru
diferite subsisteme. De obicei, cel mai mare procesor este unitatea de control a motorului.
Altele sunt utilizate pentru transmisie, airbag -uri, fr âne anti -blocare / ABS, „cruise control”,
servodirecție, sisteme audio, geamuri electrice, uși, reglarea oglinzilor, baterii și sisteme de
reîncărcare pentru mașini hibride / electrice.
Unele dintre acestea formeaz ă subsisteme independente, dar comunicarea, printre altele,
este esențial ă. Un subsistem poate avea nevoie s ă controleze servomotoarele sau s ă
primeasc ă feedback de la senzori. Standardul CAN a fost conceput pentru a satisface aceast ă
necesitate. Un avantaj cheie este c ă interconectarea între diferi te sisteme de vehicule poate
permite o gam ă largă de caracteristici de siguranț ă, economie și confort care s ă fie
implementate numai cu software -ul – funcționalitate care ar ad ăuga costuri și complexitate
dacă astfel de caracteristici au fost "prin cablu" cu ajutorul telecomunicațiilor tradiționale.
În ultimii ani, standardul LIN pentru magistrale a fost introdus pentru a completa CAN pentru
subsisteme non -critice, cum ar fi aer condiționat și infotainment, în cazul în care viteza de
transmisie a datelor și fiabilitatea sunt mai puțin critice.

Altele
Cum a fost menționat mai sus , datorită avantajelor pe care le aduce, în ceea ce privește
comunicarea între modulele electronice, acest protocol este utilizat și în alte
industrii/domenii:
– CAN a fost utilizat pe sistemul electronic de schimbare a treptelor de vitez ă ,Shimano
DI2, pentru biciclete rutiere încep ând din 2009 .
– CAN este folosit ă ca o zon ă de comunicație în general în mediile de automatizare, în
primul r ând datorit ă costului sc ăzut al unor controller e și procesoare CAN.

5
– Produc ătorii, cum ar fi NISMO, intenționeaz ă să utilizeze date din magistral ă CAN
pentru a recrea turele de curse din viața real ă în jocul video Gran Turismo 6, folosind
funcția GPS Data Logger a jocului, ceea ce ar permite juc ătorilor să lupte împotriva
turelor reale .
– Laboratorul de proteze modulare (MPL) al Laboratorului de Fizic ă Aplicat ă al
Universit ății Johns Hopkins utilizeaz ă o magistral ă local ă CAN pentru a facilita
comunicarea între servomecanisme și microcontrol ere din brațul protetic.

6
Detalii de funcționare
Standardul CAN
CAN este o magistr ală de comunicații definit ă de organizație internațional ă de stand ardizare
(ISO), inițial dezvoltat pentru industria auto pentru a înlocu i cablajul complex cu una cu dou ă
fire. Specificații le solicit ă o imunitate ridicat ă la interferențe electrice și capacitatea de auto –
diagnosticare și reparare a erori lor de date. Aceste caracteristici au dus la popularitatea CAN
într-o varietate de industrii, inclusiv în construire automatizat ă, medical ă și de fabricație.
Protocolul de comunicații CAN, ISO -11898: 2003, descrie modul în care se transmite
informația între dispozitivele dintr -o rețea și se conformeaz ă modelului Open Systems
Interconnection (OSI) definit în termeni de straturi. Comunicarea efect ivă între dispozitivele
conectate de mediul fizic este definit ă de stratul fizic al modelului. Arhitectura ISO 11898
definește cele mai joase dou ă straturi ale celor șapte nivel de model OSI / ISO ca strat de
legătură de date și strat fizic în Figura 1.

CAN Standard sau Extended
Protocolul de comunicație CAN este un protocol de acces multiplu, cu detectare a coliziunii și
arbitraj pe prioritatea mesajului (CSMA / CD + AMP). CSMA înseamn ă că fiecare nod de pe
magistral ă trebuie s ă aștepte a perioad ă de in activitate prescris ă înainte de a încerca s ă
trimite un mesaj. CD + AMP înseamn ă că coliziunile sunt rezolvat e printr -o arbitrare
„bitwise”, bazat ă pe o prioritate preprogramat ă a fiec ărui mesaj în câmpul de identificare al
mesajului. Identificatorul de pr ioritate mai mare c âștigă mereu accesul la magistral ă. Adic ă,
ultimul 1 logic în identificator continu ă să transmit ă, deoarece este cea mai mare prioritate.
Standardul ISO -11898: 2003, cu identificatorul standard de 11 biți, asigur ă rate de
semnalizare de la 125 kbps la 1 Mbps. Standardul a fost modificat ulterior cu identificatorul

7
"extins" de 29 biți. Standardul cu câmpul de identificare de 11 biți din figura 2 prevede 211 ,
sau 2048 identificatori diferiți de mesaje, în timp ce extensia , cu c âmpul de i dentificare de 29
de biți în Figura 3 prevede 229 , sau 537 milioane de identificatori.

– Start of frame (SOF): Indică începutul transmiterii mesajului
– Identifier : Un identificator (unic) care reprezint ă și prioritatea mesajului
– Remote Transmission request ( RTR): Trebuie s ă fie dominant ă (0) pentru cadrele de
date și recesive (1) pentru cadrele de solicitare la distanț ă
– Substitue remote request ( SRR): Trebuie s ă fie recesiv (1 )
– Identifier extension bit (IDE): Trebuie sa fie dominant ă (0) p entru formatul mesajului
de baz ă cu identificatori pe 11 biți si recesiv (1) pentru format de mesaj extins cu
identificator pe 29 de biți.
– Reserved bit ( r0, r1 ): Bit rezervat, trebuie sa fie dominant ă (0), dar acceptat ă ca
dominant ă sau recesiv ă.
– Data Length Code ( DLC): Numărul de octeți de date ( 0-8 octeți )
– Data field ( 0…8 Bytes Data ): Datele care trebuie tr ansmise (lungimea în octeți dictat ă
de câmpul DLC)
– Cyclic Redundancy Check (CRC): metod ă matematic ă folosit ă pentru a verifi ca
integritatea datelor
– Acknowledge (ACK): Fiecare nod care primește un mesaj precis suprascrie acest bit
recesiv în mesajul inițial cu un bit dominat, indic ând faptul c ă a fost trimis un mesaj
fără erori .
– End of frame ( EOF): marcheaz ă sfârșitul unui mesaj CAN , trebuie s ă fie recesiv (1)
– Interframe Space ( IFS): Conține timpul necesar pentru ca controlerul s ă pune mesajul
primit corect la poziți a sa corect ă într-o zon ă de buffer de mesaje .

8
Tipuri de mesaje
Exist ă 4 tipuri de mesaje ce pot fi transmise pe magistral ă de CAN:
– Data Frame : Tipul de date este cel mai obișnuit tip de mesaj și cuprinde c âmpu l
Arbitrare, c âmpul de date, c âmpul CRC și c âmpul de confirmare. C âmpul de arbitraj
conține un identificator pe 11 biți în Figura 2 și bitul RTR, care este dominant pentru
cadrele de date. În Figura 3, acesta conține identificatorul de 29 de biți și bitul RTR. În
continuare se afl ă câmpul de date care conține zero p ână la opt octeți de date și
câmpul CRC care conține suma de control pe 16 biți utilizat ă pentru detectarea
erorilor. Ultimul este c âmpul de confirmare.

– Remote Frame : Scopul dorit este de a soli cita transmiterea datelor de la un alt nod.
Mesajul de la distanț ă este similar cu mesajul de date, cu dou ă diferențe importante.
În primul r ând, acest tip de mesaj este explicit marcat ca un mesaj la distanț ă de un
bit RTR recesiv în câmpul de arbitraj, ș i în al doilea r ând, nu exist ă date.

– Error Frame : Este un mesaj special care încalc ă regulile de formatare ale unui mesaj
CAN. Se transmite atunci c ând un nod detecteaz ă o eroare într-un mesaj și determin ă
toate celelalte noduri din rețea s ă trimit ă un m esaj de eroare. Emiț ătorul original
retransmite automat mesajul. Un sistem elaborat de contoare de erori în controlerul
CAN asigur ă că un nod nu poate lega o magistral ă prin transmiterea repetat ă a
mesajului de eroare.

– Overload Frame : Mesajul de suprasarc ină este menționat pentru completare. Este
similar cu mesajul de eroare cu privire la format și este transmis de un nod care
devine prea ocupat. Este folosit în primul r ând pentru a oferi o întârziere dintre
mesaje.
Un mesaj este considerat a fi f ără eroa re atunci c ând ultimul bit al c âmpului EOF final al unui
mesaj este primit în starea recesiv ă fără erori. Un bit dominant în câmpul EOF determin ă
repetarea transmisiei de către emiț ător.

Arhitectura
Două sau mai multe noduri sunt necesare în rețeaua CAN p entru a comunica. Complexitatea
nodului poate varia de la un dispozitiv I / O simplu p ână la un calculator încorporat cu o
interfaț ă CAN și software sofisticat. Nodul poate fi, de asemenea, un gateway care s ă permit ă
unui computer standard s ă comunice prin intermediul unui port USB sau Ethernet c ătre
dispozitive dintr -o rețea CAN.
Toate nodurile sunt conectate între ele printr -o magistral ă cu dou ă fire. Firele sunt o pereche
torsadat ă cu o impedanț ă caracteristic ă nominal ă de 120 Ω (nominal ă).

9
Legătura de d ate (Data -Link Layer) și straturile fizice de semnalizare (Physical Signaling) din
Figura 1, care sunt în mod normal transparente pentru un operator de sistem, sunt incluse în
orice controler care implementeaz ă protocolul CAN. Conectarea la mediul fizic es te apoi
implementat ă printr -un transceiver de linie pentru a forma un nod de sistem ca prezentat ă în
figura 6.

Semnalarea este diferențial, de aici CAN își obține imunitatea robust ă față de zgomot și
toleranța la erori. Echilibrarea diferențial ă de semna lizare reduce cuplajul de zgomot și
permite viteze mari de semnalizare prin perechea răsucit ă de cablu. Echilibrat înseamn ă că
curentul care curge în fiecare linie de semnal este egal, dar opus în direcție, rezult ând un
efect de anulare a c âmpului, care re prezint ă cheia emisiilor de zgomot redus. Utilizarea unui
diferențial echilibrat receptoarele și cablajul cu perechi torsadate sporește respingerea în
mod obișnuit și imunitatea ridicat ă la zgomot a unui CAN.

10
Concluzii
CAN este ideal pentru aplicații care necesit ă un num ăr mare de mesaje scurte cu fiabilitate
ridicat ă în medii de operare robuste. Deoarece CAN este bazat pe mesaj și nu pe baz ă de
adrese, este mai ales potrivit ă atunci c ând sunt necesare date de mai mult de o locație și o
consistenț ă a datelor la nivel de sistem este obligatoriu.
Determinarea defecțiunilor este, de asemenea, un beneficiu major al CAN -ului. Nodurile
defecte sunt automat abandonate din magistra lă, împiedic ând astfel un singur nod s ă aduc ă
întreaga rețea jos și asigur ă că lățimea de band ă este întotdeauna disponibil pentru
transmiterea mesajelor critice. Aceast ă limitare a erorilor permite, de asemenea, ad ăugarea
de noduri la o magistral ă în timp ce sistemul este în funcțiune, altfel cunoscut sub numele de
conectare fierbinte (hot-plugging ).
Multe caract eristici ale transmiț ătorilor CAN le fac ideale pentru multe aplicații robuste la
care se adapteaz ă protocolul CAN. Printre aplicațiile care g ăsesc soluții cu CAN sunt
automobile, camioane, motociclete, snowmobile trenuri, autobuze, avioane, agricultur ă,
construcții, minerit, și vehiculele maritime.

11
Bibliografie
Wikipedia – https://en.wikipedia.org/wiki/CAN_bus
Wikipedia – https://ro.wikipedia.org/wiki/Controller_Area_Network
Texas Instruments – http://www.ti.com/lit/an/sloa101b/sloa101b.pdf
Techopedia – https://www.techopedia.com/definition/32255/controller -area -network -can
EL-PRO-CUS – https://www.elprocus.com/controller -area -network -can/
E-automobile – http://ww w.e-automobile.ro/categorie -electronica/74 -protocol -can-
auto.html
Unitbv – http://vega.unitbv.ro/~romanca/EmbSys/arhiva/12 -13-CAN -bus.pdf
Rasfoiesc – http://www.rasfoiesc.com/educatie/informatica/calculatoare/CAN -CONTROLLER –
AREA -NETWORK -PR76.php