Rețelele de comunicație LIN și CAN [609893]

Rețelele de comunicație LIN și CAN
1

LUCRARE DE DISERTAȚIE

UNIVERSITATEA TEH NICĂ “Gheorghe Asachi” din Ia și
Facultat ea de Electronic ă, Telecomunica ții și Tehnologia
Informa ției
Specializarea: Re țele de comunica ție

Rețelele de comunicație LIN și CAN
2

Cuprins

Introducere

Cap I. Protocolul LIN – Local Interconnect Network
1.1.Conceptul LIN
1.1.1. Concepte de bază
1.2.Transferul de date în rețeaua de comunicație LIN
1.3.Detectarea erorilor
1.4.Avantaje și dezavantaje în folosirea rețelei de comunicații LIN

Cap II. Protocolul CAN – Controller Area Network
2.1.Concepte de bază
2.2.Transferul mesajelor
2.3.Formatul CAN extins
2.4.Avantaje și dezavantaje

Cap III. Simularea unei rețele de comunicație utilizând protocolul CAN în
CANoe

Concluzii

Prescurtări

Bibliografie

Rețelele de comunicație LIN și CAN
3

Introducere

„Un protocol de comunicație este prin definiție un set de reguli necesare pentru a
transmite informația printr -un canal de comunicație. Aceste reguli se aplică pentru
reprezentarea datelor, pentru transmisie, autentificare și detectare de erori ce pot aparea
în timpul transmisiei.
Un protocol de comunicație trebuie să urmărească următoarele principii:
– Siguranța: aceasta se referă la detectarea eroril or și corectarea lor. Măsura calității
protocolului este dată prin numărul de biți eronați / număr de biți transmiși.
– Flexibilitate: aceasta se referă la capacitatea protocolului de -a descoperi
problemele topologiei de rețea.
– Implementare cu ușurință : împarțirea protocolului se face pe nivele interconectate,
fiecare nivel realizând un anumit număr de operații. Se încearca o separare bine definită
a acestor nivele astfe încat interacțiunea dintre ele să fie minimă, un nivel interacționând
numai cu nivelul de deasupra sau cu cel de dedesubt. Astfel protocolul este mult mai ușor
de testat pentru că se poate testa fiecare nivel separat și nu necesita cazuri de test foarte
complicate.

Protocoalele de comunicație folosite în automotive sunt : CAN, LIN, FlexRay ,
Most și Bluetooth.
Protocoalele de comunicație utilizate în industria automobilelor se clasifică în
principal în funcție de viteza de transmitere a datelor. Societatea inginerilor de
automobile (SAE),) a clasificat rețelele de comunicație astfel:
– Clasa A: viteza <10kb/sec, aplicații: acționare a oglinzilor, a geamurilor
electrice se utilizează ca protocol de comunicație LIN -ul.
– Clasa B: viteza între 10 – 125kb/sec, aplicații: instrumente de bord, se utilizează
ca protocol de comunicație CAN low -speed.
– Clasa C: viteza între 125kb/sec – 1Mb/sec, aplicații: management motor,
transmisie, sisteme de frânare, se utilizează ca protocol de comunicație CAN high -speed.
– Clasa D : viteza >1Mb/sec , aplicații: sisteme “X -by-wire”, multimedia, se
utilizează ca protocol de comunicație FlexRay. „

Rețelele de comunicație LIN și CAN
4
LIN reprezintă un standard magistrală de comunicație, de cost scăzut, folosit
pentru comunicații între senzori inteligenți și actuatori . A plicații tipice pentru LIN sunt :
grupul de instrumente, senzori de lumină , înc hiderea ușilor, ferestre. Un LIN e compus
dintr -un LIN Master și mai multe LIN slave. În vehicule magistrala LIN este conectată
între senzori, actuatori și ECU, care acționează ca o poartă spre magistrala CAN.
CAN este un standard de magistrală bazat pe me saje, ce permite unităților ECU să
comunice între ele. În CAN mesaje scurte sunt distribuite în întreaga rețea. Oferă un
transfer de maximum 1Mbps, cu imunitate crescută la interferențe electrice. CAN este
proiectată pentru a se autodiagnostica și a repara erorile de comunicație.
Comunicațiile prin CAN sunt bazate pe standard CSMA/CD ( Carrier Sense
Multiple Access with Collision Detection ). Fiecare mesaj constă dintr -un identificator de
11 biți, care conține prioritatea mesajului, și date, care sunt tran smise pe magistrală și
recepționate de toate nodurile. Acest lucru este necesar pentru a asigurarea unei priorități
mai mari sistemelor sensibile de siguranță.
CAN de viteză scăzută oferă o viteză transfer date de 125Kbps cu transfer de date
tolerant la e rori. Vitezele mai mari până la 1Mbps sunt conforme standardului 2.0 A

Rețelele de comunicație LIN și CAN
5
Cap. I – Protocolul LIN – Local Interconnect N etwork

„LIN reprezintă un standard magistrală de comunicație, de cost scăzut, folosit
pentru comunicații între senzori int eligenți și actuatori . Aplicații tipice pentru LIN sunt :
grupul de instrumente, senzori de lumină , închiderea ușilor, ferestre. Un LIN e compus
dintr -un LIN Master și mai multe LIN slave. În vehicule magistrala LIN este conectată
între senzori, actuator i și ECU, care acționează ca o poartă spre magistrala CAN.

1.1 Conceptul LIN

Standardul LIN conține specificațiile protocolului de transmisie, a mediului de
transmisie, interfața pentru programare software și interfața dintre diferitele unelte de
dezvolt are LIN garantează interoperabilitatea nodurilor rețelei din punct de vedere
hardware și software, și o comportare EMC predictibilă.
Pachetul de specificații conține 3 părți :
a. Protocolul LIN descrie nivelul fizic și cel de date a LIN.
b. LIN API descrie inter fața dintre rețea și programul aplicație.
c. LIN Configuration Language descrie formatul fișierului de configurare LIN, care
este folosit pentru configura rețeaua și pentru a fi folosit ca o interfață între OEM
și furnizorii diferitelor noduri.
LIN completeaz ă protocoalele de comunicație în domeniul automotive în zona de
cost scăzut. (Fig. 1) ”

Rețelele de comunicație LIN și CAN
6

Fig. 1

1.1.1. Concepte de bază
„Principalele proprietăți ale protocolului LIN sunt :
– organizare single -master / multiple -slave (fără arbitrare pe bus)
– garantarea timpilor de latență pentru transmiterea semnalelor
– lungime variabilă a mesajelor : 2, 4, 8 octeți
– configurație flexibilă
– auto-sincronizare, nu are nevoie de quartz sau rezonatoare ceramice în nodurile
slave
– detecția nodurilor defecte din rețea
– implementare de cost scăzut
– viteze de până la 20 kbit/sec
Arhitectura nivelelor LIN în conformitate cu modelul OSI.
Nivelul fizic definește cum se transmit semnalele pe magistrală. Tot aici apar
definite caracteristicile receptorului și a driverului.
Nivel ul MAC reprezintă nucleul protocolului LIN. El prezintă mesajele
recepționate de la nivelul LLC și acceptă mesajele ce urmează să fie transmise la nivelul
LLC. Nivelul MAC este supravegheat de o entitate de comandă numită Fault
Confinement.
Nivelul LLC se ocupă de filtrarea mesajelor și managementul „recuperării”.

Rețelele de comunicație LIN și CAN
7
Scopul acestor specificații este acela de a defini nivelele fizic și de date și
consecința protocolului LIN asupra nivelelor înconjurătoare.

Mesajele
Informația pe bus este transmisă în format fi x de lungime variabilă. Fiecare frame
de mesaj este compus din 2, 4 sau 8 octeți de date și 3 octeți de control și siguranță.
Traficul pe bus este controlat de un singur master. Fiecare mesaj începe cu un
semnal de pauză și este urmat de un câmp de sincron izare și de unul de identificare, toți
trimiși de master. Slave -ul trimite înapoi câmpul de date și cel de control (figura 2).
Datele pot fi trimise de la master (unitatea de control a master -ului) la orice slave
(unitatea de control a slave -ului) prin sla ve task. O comunicare slave -la-slave poate fi
determinată de un ID de mesaj similar dat de master. ”

Fig. 2

Informația
„În sistemul LIN un nod nu folosește informația despre configurația sistemului,
exceptând nodul de master.
Flexibilitatea sistemului

Rețelele de comunicație LIN și CAN
8
Nodurile pot fi adăugate la rețea fără a fi necesare schimbări hardware sau
software în celelalte noduri slave.
Calea informației
Conținutul unui mesaj este dat de ID. Acesta nu indică destinația mesajului ci
semnificația datelor. Numărul maxim pentru ID es te de 64, ,din care 4 sunt rezervați
pentru comunicații speciale cum ar fi upgrade software sau diagnostice.
Multicast
Ca o consecință a filtrării mesajelor orice număr de noduri pot primi simultan
mesaje și pot proceda în consecință.

Viteza
Viteza maximă este de 20kbiti/sec dată de limitările EMI ale mediului de
transmisie cu un singur fir. Viteza minimă este de 1kbit/sec pentru a evita conflictele cu
implementarea perioadelor de time -out.
Pentru a permite implementarea de cost scăzut a dispozitivelor LIN este recomandată
folosirea următoarelor viteze:
a. Încet – 2400 bit/sec
b. Mediu – 9600 bit/sec
c. Rapid – 19200 bit/sec

Single -Master – fără arbitrare
Numai nodul conținând masterul are voie să transmită header -l mesajului, și un
slave răspunde la acesta. Pentru că nu avem arbitrare, o eroare apare dacă mai mulți slave
răspund. În acest caz utilizatorul trebuie să precizeze acțiunea în urma erorii, în funcție
de cerințele aplicației.

Securitate
Detecția erorilor
– monitorizare, transmițătorul compară valoarea de pe bus cu aceea ce ar trebui să fie pe
bus.
– protecție dublă -paritate pentru câmpul ID
– check -sum pentru câmpul de date

Rețelele de comunicație LIN și CAN
9
Performanța detecției erorilor
– toate erorile locale la transmițător sunt detectate
– acoperire mare a protocolului global de erori

1.2 Transferul de date în rețeaua de comunicație LIN

Sunt două tipuri de date care pot fi transportate printr -un cadru: semnale sau
mesaje de diagnoză.
Semnalele sunt valori scalare sau șiruri de octeti care sunt introduse într -un câmp
de date a unui ca dru. Un semnal este întotdeauna prezent în aceiași poziție în câmpul de
date pentru toate cadrele cu același identificator de cadru.
Mesajele de diagnoză sunt transportate în cadre cu doi indentificatori de cadru
rezervați. Interpretarea câmpului de date d epinde de câmpul de date în sine și de starea
nodurilor de comunicare.
Sarcina masterului transmite antetele pe baza unui tabel orar. Acest tabel orar
specifică cadrul și intervalul de timp dintre începutul unui cadru și începutul celui de -al
doilea cadru . Aplicația master poate folosi tabele diferite și să selecteze dintre ele.
Împachetarea semnalelor
Un semnal este transmis cu LSB la început și MSB la sfârșit. Nu este nici o
restricție la împachetarea semnalelor scalare. Fiecare octet dintr -un sir de oc teți trebuie
să treacă printr -un cadru cu un singur octet, începand de la cel mai mic octet de date
numerotat.
Atât timp cât nu se suprapun, într -un cadru pot fi împachetate mai multe cardre.
Același semnal poate fi împachetat în mai multe cadre atâta ti mp cât editorul
semnalului este același. Dacă un nod recepționează un semnal împachetat în mai multe
cadre, ultima valoare de semnal recepționată este validă.

Recepția și transmisia semnalului
Momentul în care semnalul este transmis/recepționat trebuie definit pentru a ajuta
în proiectare și testare la analiza timpilor semnalelor.

Rețelele de comunicație LIN și CAN
10
Timing -ul este diferit pentru un nod master față de slave, pentru că nodul master
controlează orarul și știe care cadru va fi transmis. Un nod slave primește informația
atunci când este transmis header -ul pe magistrală.
Un semnal este considerat recepționat și disponibil pentru aplicație după cum
urmează (figura 3):
– Nod master – la următorul bază de timp după lungimea maximă a cadrului. Nodul
master actualizează periodic semna lele recepționate la începutul cadrului.
– Nodul slave – când checksum -ul pentru telegrama recepționată este validat.
Nodul slave actualizează semnalul recepționat direct după ce telegrama este
terminată.
Un semnal este considerat transmis în situațiile (fi gura 4):
– Nod master – înainte ca transmisia cadrului să fie inițiată.
– Nod slave – când ID -ul pentru același cadru este recepționat ”

Fig. 3 – Timpul recepției semnalului

Fig. 4 – Timpul transmisiei semnalului

Filtrarea mesajelor se bazează pe între g identificatorul. Trebuie asigurat faptul ca
nu mai mult de un slave task să răspundă la acel identificator.
Validarea mesajelor . Mesajul este valid atât pentru transmițător cât și pentru
receptor dacă nu se detectează o eroare până la sfârșitul încadrări i. Dacă mesajul este
corupt, este considerat de master și de slave ca fiind netransmis.

Rețelele de comunicație LIN și CAN
11

1.3 Detec tarea erorilor

„Există 6 tipuri de mesaje de eroare :
1. Eroare de bit. Cel care trimite un bit monitorizează și magistrala. Eroarea apare
dacă valoarea bitului monitorizat este diferită de cea a bitului trimis.
2. Eroare de sumă de control. Apare dacă suma dintre suma inversată modulo 256 a
tuturor octeților recepționați și suma de control nu este ’0xFF’.
3. Eroare identificator paritate. Aplicațiile LIN obișnuite nu deosebesc un
identificator valid dar necunoscut și unul corupt. Totuși este obligatoriu pentru
toate nodurile slave ca pentru un identificator cunoscut să se evalueze toți cei 8
biți din câmpul ID și să distingă identificatorii cunoscuți și cei corupți.
4. Eroarea de nerăspundere a slave -ului. Este detectată dacă frame -ul de mesaje nu
este transmis complet în lungimea maximă permisă T FRAME_MAX de nici un slave
task în urma transmiterii câmpurilor de sincronizare și identificatorului.
5. Eroare de câmp de sincroni zare. Se detectează dacă un slave detectează fronturile
câmpului de sincronizare înafara toleranțelor admise.
6. Eroare de inactivitate pe bus. Se detectează dacă nu s -a primit nici un câmp de
sincronizare sau un octet în intervalul T TIMEOUT de la recepția ul timului mesaj
valid.

Semnalizarea erorilor . Detecția erorilor nu se face de către protocolul LIN. Erorile
sunt semnalizate în interiorul fiecărui nod și trebuie să fie accesibile de către „fault
confinement”.
Fault confinement ; acest concept se bazează pe nodul master care se va ocupa cât mai
mult de detecția erorilor, recuperarea în urma erorilor și dignosticul. Este foarte
dependent de cerințele sistemului și prin urmare nu face parte din protocolul LIN cu
excepția unor aspecte.

Rețelele de comunicație LIN și CAN
12
Unitatea de control m aster
Va detecta următoarele situații de erori:
– când master task transmite: se detectează o eroare de bit sau o eroare de paritate în
octetul de sincronizare sau identificator în timp ce se verifică transmisia proprie.
– când slave task din master recepț ionează: este detectată o eroare de sumă de control
sau nu răspunde slave -ul când se citesc date de pe bus.

Unitatea de control slave
Orice slave va detecta următoarele situații de erori:
– când slave task transmite: apare o eroare de bit într -un câmp de date sau sumă de
control când se verifică propria transmisie
– când slave task recepționează: apare o eroare de bit într -un câmp de date sau sumă
de control când se citește de pe bus
– când nu răspunde un slave atunci când un slave așteaptă un răspuns de l a un alt
slave în intervalul de lungime maximă a frame -ului de mesaje T FRAME_MAX . Când un
frame nu așteaptă un mesaj nu este necesară detecția acestei erori.
– când este detectată o eroare în octetul de sincronizare atunci când câmpul de
sincronizare nu es te detectat în toleranța admsă.

1.4 Avantaje și dezavantaje în folosirea rețelei de comunicații LIN

„Avantajele folosirii unei rețele de comunicație LIN:
a. Soluție de cost -scăzut, concepută special pentru folosirea unor noduri hardware
necostisitoare
b. Poate fi folosit ca alternativă de dimensiuni reduse la CAN
c. Abilitatea de a reconfigura rețeaua aduce mari beneficii de cost și timp la
diagnosticare și în timpul dezvoltării
d. Mediu integrat de dezvoltare
e. Implementare necostisitoare bazată pe UART
f. Timpi de latență garantați

Rețelele de comunicație LIN și CAN
13
Dezavantajele folosirii unei rețele de comunicație LIN:
a. Numai nodul master are voie să transmită header -ul mesajului, și un slave poate
doar răspunde la acesta. Pentru că nu avem arbitrare, o eroare apare dacă mai
mulți slave răspund . În acest caz utilizatorul trebuie să precizeze acțiunea în urma
erorii în funcție de cerințele aplicației.
b. Viteze de până la 20 kbit/sec „

Rețelele de comunicație LIN și CAN
14
Cap. II – Protocolul CAN – Controller Area Network

„CAN este un standard de magistrală bazat pe mesaje, ce permite unităților ECU
să comunice între ele. În CAN mesaje scurte sunt distribuite în întreaga rețea. Oferă un
transfer de maximum 1Mbps, cu imunitate crescută la interferențe electrice. CAN este
proiectată pentru a se autodiagnostica și a repara erorile de comunicație.
Comunicațiile prin CAN sunt bazate pe standard CSMA/CD ( Carrier Sense
Multiple Access with Collision Detection ). Fiecare mesaj constă dintr -un identificator de
11 biți, care conține prioritatea mesajului, și date, car e sunt transmise pe magistrală și
recepționate de toate nodurile. Acest lucru este necesar pentru a asigurarea unei priorități
mai mari sistemelor sensibile de siguranță.
CAN de viteză scăzută oferă o viteză transfer date de 125Kbps cu transfer de date
tolerant la erori. Vitezele mai mari până la 1Mbps sunt conforme standardului 2.0.
CAN HS poate avea viteza de transfer a datelor de 125, 250, 500 sau 1000 kb/s.
Datorită vitezei mari de transfer a datelor este utilizat mai mult pentru motoare, cutie de
viteze și sisteme de siguranță activă (ABS, ESP).
CAN LS are viteza de transfer între 40 și 125 kb/s. Protocolul CAN LS are
avantajul că este tolerant la erori (fault tolerant). În cazul în care unul din cele două fire
este întrerupt comunicația se realizează pe un singur fir. Acest tip de protocol CAN este
utilizat cu precădere la închiderea centralizată și la imobilizator, datorită funcționării și în
regim de avarie.
Pentru a obține un design transparent și flexibil CAN a fost împărțit în nivele:
– nivelul ob iect
– nivelul transfer
– nivelul fizic

Nivelul obiect și cel de transfer cuprind toate serviciile și funcțiile nivelului
legăturilor de date definit de modelul ISO/OSI. Scopul nivelului obiect include:
– găsirea mesajelor de transmis
– decizia asupra mes ajului de actualitate primit de la nivelul de transfer
– o interfață către nivelul aplicație aflat în legătură cu hardware -ul.

Rețelele de comunicație LIN și CAN
15
Scopul nivelului de transport este protocolul de transfer (controlul cadrelor,
arbitrajul, detecția și semnalizarea erorilor și limitarea defectelor. În cadrul nivelului de
transfer se decide dacă magistrala este liberă pentru pornirea unei noi transmisii sau dacă
începe o recepție, sau funcții legate de rata de transfer. Acest nivel nu suportă modificări.
Scopul nivelului fizic re prezintă schimbul de biți între noduri cu respectarea tuturor
proprietăților electrice. Nivelul fizic trebuie să fie același pentru toate nodurile. ”

2.1 Concepte de bază

„CAN are o structură pe 3 nivele:
– Nivelul fizic definește modul cum sunt transmise semnalele. El cuprinde mediul
de transmisie, nivelele semnalelor și reprezentarea biților, dar nu permite optimizarea
acestora pentru o anumită aplicație.
– Nivelul de transfer reprezintă nucleul (kernel) protocolului CAN. Acesta
prezintă mesajele recepți onate și acceptă mesajele de transmis de la nivelul obiect. Tot
acest nivel este responsabil pentru rata de transmisie și sincronizare, pentru încadrarea
mesajelor, arbitraj, confirmare, detecție de erori, semnalizare și reținerea defectelor.
– Nivelul obi ect se ocupă de filtrarea mesajelor, precum și de starea și
manipularea acestora.

Dacă nivelul fizic este fixat prin circuitele de interfață utilizate iar nivelul obiect
este puntea de legătură cu programul aplicație, nivelul de transfer este cel care asi gură
compatibilitatea tuturor dispozitivelor conectate la magistrală. Este definit și standardizat
prin specificație tehnică. Aceasta definește o serie de termeni utili pentru înțelegerea
modului cum sunt transferate, validate, codate și testate pentru det ecția erorilor mesajele
vehiculate prin interfață.
Informația pe magistrală este transmisă prin mesaje cu format fix sau diferitdar
limitate ca lungime. Mesajele pot fi inițiate de orice dispozitiv conectat la magistrală
atâta vreme cât aceasta din urmă es te liberă.
În sistemele CAN nodurile nu utilizează informații despre configurarea sistemului
(adresele nodurilor), lucru care are câteva consecințe importante:

Rețelele de comunicație LIN și CAN
16
– flexibilitatea sistemului: noduri suplimentare pot fi adăugate fără a necesita
schimbări în so ftware -ul sau în hardware -ul nodurilor existente, sau în vreunul din nivele
aplicație.
– rutarea mesajelor: conținutul unui mesaj include un identificator, acesta
neindicând destinația mesajului, dar descrie semnificația datelor, astfel încât toate
noduril e din rețea sunt în stare să filtreze mesajele pentru a determina dacă acestea sunt
utile pentru ele sau nu.
– multi -distribuție: oricare dintre noduri pot recepționa și acționa simultan la
același mesaj
– consistența datelor: conceptul CAN garantează că u n mesaj oarecare este
acceptat simultan de toate nodurile sau de nici unul. Astfel dacă un nod a detectat o
eroare atunci transmisia este oprită prin transmiterea unui fanion de eroare prin care se
previne acceptarea de către celelalte noduri a mesajului.
Mesajele au priorități diferite, aceasta fiind definită prin identificator. Dacă un
nod cere altui nod un pachet de date , acesta trimite pachetul cu același identificator ca și
cererea.
Magistrala CAN este de tip multi -master, oricare din noduri putând po rni
transmisia. Nodul ce transmite mesajul cu prioritatea cea mai mare va câștiga accesul la
magistrală. Pentru aceasta este nevoie de arbitraj. Dacă 2 sau mai multe noduri încep să
transmită în același timp atunci conflictul este rezolvat prin arbitrajul pe baza
identificatorului. Mecanismul de arbitrare garantează ca nici o informație să nu fie
pierdu tă. Dacă transmisia unui mesaj de date și a unui mesaj de cerere de date, având
același identificator, sunt inițiate în același timp, atunci mesajul de date are prioritate. În
timpul arbirajului fiecare transmițător compară nivelul bitului transmis cu nive lul de pe
magistrală. Dacă cele două nivele sunt aceleași atunci acesta continuă să transmită. Când
se transmite un nivel regresiv (recessive – eng.), adică 1 logic) și se detectează un nivel
dominant (dominant – eng.), adică 0 logic, atunci nodul a pierdu t arbitrajul și trebuie să
se retragaă fără a mai transmite vreun bit.
Singuranța transferului datelor este asigurată prin metodele de detecție a erorilor,
semnalizare și auto -verificare implementate:

Rețelele de comunicație LIN și CAN
17
– detecția erorilor presupune următoarele măsuri: monit orizarea (emițătoarele
compară nivelele biților de transmis cu cele detectate pe magistrală), verificarea
redundanței ciclice, umplerea biților (bit stuffing) și verificarea structurii mesajului.
– performanța detecției erorilor: mecanismele de detecție a erorilor realizează
detecția tuturor erorilor globale, a erorilor locale la nivelul emițătorului, a până la 5 erori
aleatorii într -un mesaj, a erorilor de șarjă (burst), precum și a erorilor oricărui număr
impar din mesaj.
Semnalizarea erorilor și a mesaje lor corupte poate fi făcută de către orice nod.
Astfel de mesaje sunt abandonate și retransmise automat. Timpul de revenire de la
detectarea erorii până la începerea mesajului următor este de cel puțin 29 de perioade de
bit cu condiția să nu mai apară alte erori.
Nodurile trebuie să fie capabile să distingă între perturbații scurte și căderi
permanente, iar nodurile defecte sunt închise.
Magistrala CAN pemite conectarea teoretică a unui număr nelimitat de noduri.
Practic numărul total este limitat de timpii de întârziere și de încărcarea acesteia. Fizic,
magistrala este reprezentată de un singur canal prin care circulă semnalul electric ce
poartă informația (datele). Din aceste date se extrage informația de sincronizare, dar și
datele în sine. Tensiunea de p e linie poate avea una din două valori complementare:
dominantă (0) sau regresivă (1). Atunci când două emițătoare plasează pe linie, unul un
bit dominant și celălalt unul recesiv, valoarea rezultantă va fi cea dominantă. Aceasta se
datorează implementării de tip ȘI -cablat.
Toate receptoarele verifică conținutul mesajului și vor confirma un mesaj corect
sau vor semnaliza un mesaj incorect. Pentru a reduce consmul de putere, un dispozitiv
CAN poate fi trecut în modul „sleep”, fără activitate internă și cu ci rcuitele de interfață
deconectate. Din acest mod ieșirea se face la prima activitate apărută pe magistrală sau la
o condiție internă. Activitatea internă este repornită, iar nivelul de transfer așteaptă
pentru ca oscilatorul sistemului să se stabilizeze și apoi până se va sincroniza la
activitatea magistralei (verificarea a 11 biți regresivi consecutivi). Pentru a „trezi” alte
noduri ale sistemului care sunt în modul „sleep” se transmite un mesaj de trezire cu cel
mai mic identificator (rrr rrrd rrrr, r=reg resiv, d =dominant). ”

Rețelele de comunicație LIN și CAN
18
2.2 Transferul mesajelor

„Pe magistrala CAN se pot transmite 4 tipuri de mesaje:
– mesaj de date – transferă datele de la un emițător la receptoare.
– mesaj de cerere – când un nod trimite o cerere de transmitere a unui mesaj de
date cu același identificator
– mesaj de eroare – transmis de un nod care a detectat o eroare
– un mesaj de supraîncărcare – anunță o cerere de întârziere între mesajul
precedent și cel următor.
Mesajele de date și cele de cerere sunt separate de mesajele pr ecedente printr -un
spațiu intermesaj (figura 5 și figura 6). ””

Fig. 5 – Structura unui mesaj de date

„Mesajul de date este compus din 7 câmpuri: câmp de start (SOF), câmp de
arbitrare, câmp de control, câmp de date, câmp de CRC și câmp de sfârșit. Câmp ul de
date poate avea și lungimea zero.
Câmpul de start marchează începutul mesajului de date sau de cerere și constă
dintr -un singur bit dominant. Un nod poate începe transmisia doar când magistrala este
liberă (idle). Toate nodurile trebuie să se sincron izeze pe frontul crescător al acestui
câmp.

Rețelele de comunicație LIN și CAN
19
Câmpul de arbitrare conține un identificator și un bit RTR. Identificatorul are 11
biți, biți care se transmit începând cu cel mai semnificativ ID10 și terminând cu cel mai
puțin semnificativ ID0. Cei mai semnifi cativi 7 biți (ID10 la ID4) nu trebuie să fie toți
regresivi. Bit -ul RTR (Remote Transmission Request) este bit dominant în mesajele de
date și regresiv în mesajele de cerere.
Câmpul de control constă din 6 biți și include lungimea câmpului de date și 2 bi ți
rezervați pentru extensii viitoare. Biții rezervați trebuie să fie întotdeauna dominanți.
Câmpul de date are lungimea în octeți indicată de câmpul anterior pe ultimii 4 biți
(poate conține de la 0 la 8 octeți). Fiecare octet se transmite începând cu MSB .
Fiecare mesaj de date sau de cerere sunt teminate cu un câmp terminator de
mesaj. Acesta constă dintr -o secvență de 7 biți regresivi.
Mesajul de cerere poate fi trimis de către un nod receptor pentru a cere date de la
un nod sursă. Un astfel de mesaj est e format din 6 câmpuri: Câmp de start, Câmp de
arbitrare, Câmp de control, Câmp CRC, Câmp de acceptare și Sfârșit de mesaj. ”

Fig. 6 – Structura unui mesaj de cerere

Mesajul de eroare (figura 7) constă în două câpuri diferite. Primul este dat de
suprapu nerea fanionului de eroare (Error Flag) provenind de la diferite noduri. Cel de -al
doilea câmp este delimitatorul de eroare (Error Delimiter). Pentru a termina mesajul de

Rețelele de comunicație LIN și CAN
20
eroare în mod corect, un nod are nevoie ca magistrala să fie liberă cel puțin 3 perio ade de
bit.

Fig. 7 – Structura unui mesaj de eroare

„Mesajul de supraîncărcare (figura 8) conține două câmpuri de biți: fanionul de
supraîncărcare și delimitatorul de mesaj. Sunt două tipuri de condiții de supraîncărcare:
– condiții interne ale recepto rului care cer o întârziere a următorului mesaj de date
sau de cerere
– detectarea unui bit dominant în timpul pauzei (Intermission).
Începerea transmisiei unui mesaj de eroare datorat primei condiții este permis la
primul bit al unei pauze, în timp ce un mesaj datorat condiției 2 poate începe la primul bit
dupa detectarea unui bit dominant. ”

Fig. 8 – Structura unui mesaj de supraîncărcare

Rețelele de comunicație LIN și CAN
21
„Mesajele trebuie separate între ele de un câmp de biți de spațiere intermesaj
(figura 9 – Interframe Space). Mesaj ele de eroare și cele de supraîncărcare nu sunt
separate de astfel de spații. După aceste spațiu urmează o zonă cu magistrala liberă (idle).
Această durată poate avea o lungime variabilă. Dacă era un mesaj în așteptare, atunci
acesta va începe să fie trimi s pe durata primului bit după pauză. ”

Fig. 9 – Spațiu intermesaj

1.3 Formatul CAN extins

„Pe lângă formatul CAN prezentat mai sus, există și formatul CAN extins.
Diferența față de formatul standard îl constituie biții SRR și r1. Bitul SRR este un bit
regresiv și se traduce ca bit de substituție de cerere la distanță (Substitute Remote
Request Bit) și înlocuiește bitul RTR din formatul standard. ” (figura 10)

Fig. 10 – Formatele CAN: Standard și extins.

Rețelele de comunicație LIN și CAN
22

1.4 Avantaje și dezavantaje

„Protocolul CAN est e ideal pentru aplicații care necesită un numar mare de
mesaje scurte. Mecanismul de arbitraj asigură transmiterea mesajelor urgente în timp
util.
CAN este un protocol broadcast care aduce un plus de flexibilitate rețelei.
Adugarea unei noi stații nu impl ică modificări hard sau soft pentru că stațiile deja
existente în rețea sunt doar receptoare.
CAN necesită un canal specific de tip serial spre de doesbire de MODBUS și
PROFIBUS care se pot implementa atât peste serial cât și peste Ethernet.
CAN se adres ează mediilor afectate de interferențe electromagnetice (PROFIBUS
este pentru sisteme în timp real, MODBUS a fost conceput pentru a comunica cu
controlerele programabile).
Dacă o eroare este detectată atunci automat se genereză un mesaj de eroare care
va anunța celelalte noduri să ignore mesajul primit.
CAN înlocuiește cablarea complexă cu o magistrală formată din două fire. Rața
de 1Mbps, imunitatea la interferențele electrice și capabilitatea de a descoperi errori și de
a le rezolva rapid a facut CAN un protocol foarte popular în indistrustiile auto.
Spre deosebire de Ethernet, CAN nu poate trimite blocuri mari de mesaje de la un
nod la altul sub controlul unui dispozitiv master.
Protocolul CAN are o fiabilitate sporită și o viteza mare de transmisie.
Magistrala nu presupune o ierarhizare a nodurilor, cand magistrala este liberă,
oricare unitate poate începe transmiterea unui mesaj. Unitatea cu mesajul cel mai
prioritar va castiga accesul la magistrala.
Pentru a realiza cea mai mare siguranța în trans ferul datelor, în fiecare nod al
magistralei CAN sunt implementate mijloace puternice pentru detectarea erorilor,
semnalizarea acestora și auto -verificare.
Atunci cand magistrala este liberă, oricare unitate poate demara începerea unei
transmiteri a unui mesaj. Daca încep să transmită simultan două sau mai multe unitați,
conflictul de acces pe magistrala este rezolvat prin arbitrarea bit cu bit, utilizând
identificatorul. Mecanismul arbitrării garantează că nu se pierde nici timp, nici vreo
informație. Pe parcursul arbitrarii fiecare transmițător compară nivelul bitului transmis

Rețelele de comunicație LIN și CAN
23
cu nivelul existent pe magistrală. Daca nivelele sunt egale, unitatea continuă să
transmita. Dacă ea transmite un nivel “recesiv” și magistrala monitorizează un nivel
“dominant”, un itatea pierde arbitrarea și trebuie să se retraga, fară a mai transmite un
singur bit. Acest sistem de arbitrare, conceput special pentru autovehicule, permite
rezolvarea unor evenimente de importanță mai mare în funcționarea mașinii, care
necesită o deciz ie mai rapidă, prioritar față de evenimente pentru care deciziile mai pot
întârzia. ”

Rețelele de comunicație LIN și CAN
24
Cap III. Simularea unei rețele de comunicație utilizând
protocolul CAN în CANoe

S-a creat o configurație cu un canal CAN1 cu o frecvență de quart z de 16000kHz
și o rată de transfer a datelor de 500kbps. (Fig. 11)

Fig. 11 – Configurație

Apoi s -au creat 3 noduri Motor, BCM (body contol module) a nd Key. Click
dreapta pe Nodes – Insert Network Nodes. (figura 12)

Rețelele de comunicație LIN și CAN
25

Fig. 12 – Crearea Nodurilor de Reț ea

Fiecare nod de rețea reprezintă un ECU (electronic control unit). Nodurile sunt
conectate la rețeaua de CAN și sunt interconectate între ele ca în figura urm ătoare.
(figura 13)

Fig. 13 – Interconectarea nodurilor în rețea

Rețelele de comunicație LIN și CAN
26

Fiecare ECU conține niște m esaje, semnale și variabile de environment. Aceste
mesaje semnale și variabile corespunzatoare fiecarui nod au fost definite într -o baza de
date numită CAN1. Pentru creearea bazei de date s -a utlizat programul VectorCANdb++
Editor. Baza de date arată ca în figura 14.

Fig. 14 – Baza de date

„Fiecare nod poate trimite s au primi mesaje. Când se crează un mesaj i se alocă
automat un ID unic altfel dacă ar exista două noduri cu acealși ID ar cauza erori. Fiecare
mesaj are în componenta sa 1 sau mai multe sem nale.
Nodul BCM trimite 3 mesaje : Klemmen, ReqData, ReqEngineStatus și primește
3 mesaje de la nodul Motor primește mesajul CarStatus iar de la nodul Key primește 2
mesaje : KeyData si KeyRequest.
Nodul Key trimite 2 mesaje : KeyData, KeyRequest și prim ește 2 mesaje de la
BCM : Klemmen și ReqData.
Nodul Motor trimite un singur mesaj CarStatus și primește 2 mesaje de la BCM :
Klemmen și ReqData.
În baza de date avem informații și despre Id -ului și formatul acestuia. În cazul de
față formatul este standar d, dacă era extin s în colana ID -format apă rea CAN Extended.
DLC (data lenght code) este numarul de biți din câmpul de date acesta poate să difere în

Rețelele de comunicație LIN și CAN
27
funcție de mesaj, numarul maxim de octeți care poate să îl ia un DLC este de 8octeți.
Coloana Tx Method con ține modul în care se updatează mesajele pe CAN ciclic sau la
apariția unui eveniment. Du blu clik pe mesaj la Attributes – GenMesgSendType și putem
alege modul în care să se updateze mesajul pe CAN ciclic sau la aparitia unui eveniment.
Atunci când mesajul se updateaza ciclic are un timp dupa care se updatează numit cycle
time și este de 100ms la mesajul CarStaus și de 50 la mesajul Klemmen. ”

Fig. 15 – Mesajele

„Fiecare mesaje are unu sau mai multe semnale. Mesajul CarStatus are 4 semnale:
CRC_CAR_STAT, ALIVE_CAR_STAT, ST_ENG și VEH_SPEED. Baza de date oferă
informații asupra bitului de start care ne spune de la ce bit începe transmiterea
semnalului în msesaj. Lengh bit se referă la numarul de biți ocupați pentru transmiterea
semnalului în mesaj. Byte Or der depinde de microcontrolerul folosit poate fi Intel sau
Motorola. Coloana cu Value Type conține tipul datei cu semn (signed), fara
semn(unsigned), float sau double. În cazul de fată s -au folosit date cu semn. Putem de
asemena scrie maximul și minimul ca re îl poate lua semnalul de ex. la semnalul
VEH_SPEED minimul este 0 km/h iar maximul de 200km/h, sau putem bifa opțiunea
Automatic min -max calculation și astfel iși calculează singur minimul și maximul fară să
il scriu în baza de date.
Semnalul CRC_CAR_S TAT reprezintă valoarea CRC (Control Redundant Ciclic)
pentru data salvată în mesaj.
Semnalul ALIVE_CAR_STAT este un counter care începe cu valoarea 0 și se
incremeteaza cu o unitate iar când ajunge la valoare 14(0x0E) se reseteaza la zero și
continuă se in cremeteze.
Semnalul ST_ENG este semnalul ce oferă informații asupra motorului și poate
avea 3 valorii: 0 – motor oprit, 1 – motor gata de pornire și 2 – motor pornit.

Rețelele de comunicație LIN și CAN
28
Semnalul VEH_SPEED este semnalul ce oferă informații asupra vitezei mașinii. ”

Fig. 16 – Semnale din mesajul CarStatus

Mesajul Key Data conține un singur semnal.
ST_Key_ID este semnalul ce conține ID -ul cheii.

Fig. 17 – Semnalul din mesajul KeyData

Mesajul KeyRequest conține două semnale.
Semnalul ST_KEY_POS oferă informații despre po ziția cheii.
Semnalul ST_KEY_PRESED oferă informații asupra cheii care a fost apasată.
Poate lua urmatoarele valori 1 – lock, 2 – unlock, 0 – default.

Fig. 18 – Semnalele din mesajul KeyRequest

„Mesajul Klemmen conține patru semnale.
Semanlul CRC_Klemme n reprezintă valoarea CRC (Control Redundant Ciclic)
pentru data salvată în mesaj.
Semnalul ALIVE_Klemmen este un counter care începe cu valoarea 0 și se
incremeteaza cu o unitate iar când ajunge la valoare 14 se reseteaza la zero și continuă se
incremete ze.
Semnalul ST_KL oferă informații asupra stausului clemei. Poate lua următoarele
valori : 1 – 30 F (30Fault – atunci cand șoferul nu este în mașina), 2 – 30B (30 Basic –

Rețelele de comunicație LIN și CAN
29
atunci cand șoferul este în mașina), 3 – 15 ( cheia este în contact), 4 – 50 (atunci cand
pornești mașina – cranking).
Semnalul ST_Start_Stop oferă informații asupra butonului de Start/Stop și poate
lua urmatoarele valori: 0 – released , 1 – pressed. Valoarea default este 0. ”

Fig. 19 – Semnalele din mesajul Kelemmen

Mesajul ReqData co nține un singur semnal.
Semnalul KEY_ID este semnalul folosit pentru a cere ID -ul cheii. Poate lua
urmatoarele valori: 0 – nu s-a cerut ID -ul cheii, 1 – s-a cerut ID -ul cheii.

Fig. 20 – Semnalul mesajului ReqData

Mesajul ReqEngineStatus are un singur semnal.
Semnalul ENG_STATUS poate lua 2 valori : 0 – nu se cere statusul motorului, 1 –
se cere statusul motorului.

Fig. 21 – Semnalul mesajului ReqEngineStatus

Baza d e date CAN1 a fost adugată rețel ei CAN Networks ca în figura 22 .

Rețelele de comunicație LIN și CAN
30

Fig. 22 – Rețeaua CAN

„Pentru a putea comunica între noduri , în spatele fiecarui nod stă un cod CAPL(or
CAN Access Programming Language).
În figura 23 este un trace din Canoe cu toate mesajele care se trimit pe bus. Pentru
fiecare mesaj este specificat DLC si Id -ul care le setat în baza de date. În plus aici putem
vedea și data care se transmite, de exemplu pentru mesajul Klemmen data care se trimite
este 0E 06 03 00. O alta informație oferită în acest trace este timpul la care începe
transmiterea cadrului. Colana Channels ne spune pe ce canal se transmit mesajele, în
cazul de fată este vorba de canalul 1 – CAN1.
Pentru toate mesajele în coloana Dir observam ca scrie Tx, acest lucru este din
cauza că nodurile sunt simulate. Dacă mesajele erau trimise de un ECU real și nu sim ulat
atunci in coloana Dir am fi avut RX. ”

Fig. 23 – Transmiterea semnalelor pe rețeaua CAN

Rețelele de comunicație LIN și CAN
31

Observăm că fiecare semnal are o v aloare, aceste valori se modifică în funcție de
ce buton se apasă sau ce ușă este deschisă .
Pentru aceasta s -a creat un Panel din Tools – Panel Desig ner cu numele de Car
Simulation. În acest panel s -au aduagat : 1 Group Box, 2 butoane și s -au inserat imagini
predefinite.

Fig. 24 – Panoul Car Simulation

„Cu ajutorul butoanelor LOCK si UNLOCK putem bloca sau debloca ma șina.
KeyID[0] și KeyID[1] sunt ID -urile che ilor folosite pent ru a bloca sau debloca maș ina.
Used Key este cheia care este folosită pentru a debloca mașina. În cazul în care cheia
este greșită, mașina nu se deblochează, rămâne încuiată. Statusul prin care vedem dac ă
mașina este blocată sau nu, este evidențiat cu ajutorul imagini i DOOR LOCKED.
Start/Stop este un buton pentru a porni motorul maș inii sau pent ru a-l opri.
LED -ul de pe mașină ne arată dacă șoferul este în mașină sau nu. Atunci când a re
culoarea verde se mnifică că ș oferul este în maș ină iar câ nd are culoarea verde semnifică
faptul că șoferul nu este în mașină .

Rețelele de comunicație LIN și CAN
32
Farurile pot avea două culori : roșu și verde. Roșu atunci când o ușă este deschisă
și apeși butonul de lock .
Dacă butonul de lock sau de unlock a fost apăsat atunci se trimite mesajul
KeyRequest de la nodul Key la nodul BCM.
Dacă nodul Key primeș te ReqData cu Key_ID pe 1(ke y request). Atunci el trimite
ID-ul chei i de pe panel ST_KEY_ID.
BCM -ul compara ID -ul primit de la nodul Key cu cheia invatat. Și daca este
aceiași cheie blochează sau deblochează mașina. Daca cheia nu este cea învațată atunci
nu permite deblocarea sau blocarea mașinii.
Dacă ușa soferului este dechisă și apoi închisă se presupune ca șoferul este în
mașină, încă un ciclu de dechi dere-închidere a uși și se presupune ca șoferul nu este în
mașina.
Dacă șoferul este în mașină și a fost apasat butonul de Start/Stop pentru cel puțin
1 sec BCM -ul se va schimba status clemei în 3. Daca se mai apasă odata butonul de
Start/Stop și viteza e ste zero, statusul clemei se schimbă în 4 și motorul pornește. La
urmatoarea apăsare a butonului de start -stop motorul se oprește.
Atunci câ nd clema este 30F sau 30B mesajul CarStatus nu este disponibil.
Simularea începe cu clema pe 1 și celelalte semnale de la clema pe 0. ”

Rețelele de comunicație LIN și CAN
33
Concluzii

„În aceast ă lucrare s -au studiat două protocoale de comuni cație utilizate în
automotive LI N și CAN.
Protocolul de comunicatie LIN se bazeaza pe o interacțiune de tip master slave.
Masterul este cel care știe câ nd și ce mesaj se trimite pe baza unui tabel orar. Slave -ul
citește tot timpul informația de pe bus și atunci cand vede Id -ul pentru el doar atunci
raspunde și completeaza cadru cu date.
Diferența majora dintre cele doua protocoale este că la LIN nu pot p une toate
nodurile informația odata pe bus, nodurile trebuie să astepte și să reactioneze în functie
de un tabel orar. În timp ce la protocolul CAN informația este tot timpul disponibila pe
bus.
LIN-ul trebuie utilizat atunci când nu se necesită un schimb mare de informații.
În protocolul CAN nu există o ierarhie de tip master slave și nici un tabel orar în
funcție de care să se transmită mesajele pe bus. Fiecare nod trimite și receptionează
datele care îl intresează. Am observat de asemenea că Id -ul cadr ului este pus pe bus de
fiecare nod spre deosebire de LIN unde ID -ul este pus doar de master. Identificatorul
unic determină și prioritatea mesajului cu cât valoare Id -ului este mai mica cu atat
prioritatea s -a este mai mare.
Atât la protocolul LIN cât și la protocolul CAN mesajele nu se transmit pe bază
de adresă ci pe bază de ID.
Protocolul CAN trebuie utilizat atunci când se necesită un schimb mai mare de
informație și când intereacțiunea dintre noduri nu trebuie sa fie una de tip master salve
adica ce rere răspuns. ”

Rețelele de comunicație LIN și CAN
34

Prescurtări

LIN Local Interconnect Network
CAN Controller Area Network
CSMA/CD Carrier Sense Multiple Access With Collision Detection
RTR Remote Transmission Request
SRR Substitute Remote Request
BCM Body Contol Module
ECU Electronic Control Unit
DLC Data Lenght Code
CRC Control Redundant Ciclic
CAPL Can Access Programming Language

Rețelele de comunicație LIN și CAN
35

Bibliografie

1. LIN Specification Package, Revision 2.2A, LIN Consortium, 2010
2. Canoe Tutorial, Version 2.0, 2008
3. Testing with CANoe, Version 1.0, 2005
4. Retele pentru comunicatii industriale, Miron Mandoiu – Universitatea Polite hnica
Bucurest, 2007.
5. http://www.e -automobile.ro/categorie -electronica/74 -protocol -can-auto.html
6. Local Interconnect Network, Universitatea Politehnica Timișoara Facul tatea de
Electronică și Telecomunicații
7. Vector informatik GMBH, e -Learning, LIN Bus, https://elearning.vector.com