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

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

LUCRARE DE DISERTAȚIE

Iași, 2018

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

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

REȚELELE DE COMUNICAȚ IE LIN ȘI CAN

Profesor: Student:
s.l. dr. ing. Petre -Daniel Mătăsaru ing. Mazilu Andrei Marius

Iași, 2018

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

Introducere ……………………………………………………………….. ……………………….. 4

Cap I. Protocolul LIN – Local Interconnect Network ……….. ………………….. 6
1.1.Conceptul LIN …………………………………………………………. …………………….. 7
1.1.1. Concepte de bază ………………………………………………….. ……………………… 8
1.2.Transferul de date în rețeaua de comunica ție LIN …………. …………………… 12
1.3.Detectarea erorilor …………………………………………………… ……………………. 15
1.4.Managementul puterii în rețeaua LIN ………………………….. …………………… 17
1.5.Avantaje și dezavantaje în folosirea rețelei de comunicații LIN …………… 19

Cap II. Protocolul CAN – Controller Area Network …………………. ………… 20
2.1.Concepte de bază ……………………………………………………………… …………… 21
2.2.Transferul mesajelor ………………………………………….. …………….. …………… 25
2.3.Formatul CAN extins ………………………………………………………… …………… 30
2.4.Detectarea erorilor ……………………………………………………………. …………… 31
2.5.Avantaje și dezavantaje …………… ……………………………………….. …………… 33
2.6.LIN versus CAN ………………………………………………………………. …………… 35

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

Concluzii …………………………………………………………………………………………… 45

Prescurtări ………………………………………………………………………………………… 46

Bibliografie ……………………………………………………………………………………….. 47

Rețelele de comunicație LIN și CAN
4
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ți e. 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 d etectarea erorilor ș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 : C AN, 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ți e 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 comunic aț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
5
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ă , î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, actuatori și ECU, care acționează ca o poartă spre magistrala CAN.
CAN este un standard de magist rală 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 autodiagnos tica ș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 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 da te
tolerant la erori. Vitezele mai mari până la 1Mbps sunt conforme standardului 2.0 A

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

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 inteligenț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, actuatori și ECU, care acționează ca o poartă spre magistrala CAN.
LIN este un SCI /UART pe baza de serial, byte -orientate, timp declanșat protocol
de comunicare concepută pentru a sprijini rețele auto împreună cu Controller Area
Network (CAN), car e permite costeffective comunicarea cu senzorii și actuatorii atunci
când toate caracteristicile poate nu sunt necesare. Principalele caracteristici ale acestui
protocol (în comparație cu CAN) sunt costuri reduse și viteză redusă și utilizate pentru
distan ta scurta retele.
De obicei în aplicația auto, magistrală LIN este conectat între senzorul inteligent
sau de acționare și o unitate de control electronică (ECU) care este adesea un gateway cu
can bus. Ca poate, LIN este de asemenea o transmisie tip rețea d e serie, dar cu un singur
master și multiple (până la 16) sclavi. Nici o detectare coliziune există în LIN, prin
urmare toate mesajele sunt inițiate de către master cu cel mult o slave răspundeți pentru
un anumit mesaj de identificare.
In plus este un sing ur fir LIN 12V conexiunea CAN BUS, in care protocolul de
comunicare se bazează pe ISO 9141 NRZ -standard. O trăsătură importantă a
mecanismului de sincronizare este lin care permite ceasul recuperarea de catre nodurile
slave fără quartz sau ceramica rezonat orul. Numai nodul principal va fi folosind
dispozitivul oscilante. Nodurile pot fi adăugate la rețeaua LIN fără a necesita hardware
sau software modificările în alte noduri slave. Și viteză maximă a transmisiei va fi
20kbit/s.

Rețelele de comunicație LIN și CAN
7
1.1 Conceptul LIN

Stand ardul LIN conține specificațiile protocolului de transmisie, a mediului de
transmisie, interfața pentru programare software și interfața dintre diferitele unelte de
dezvoltare LIN garantează interoperabilitatea nodurilor rețelei din punct de vedere
hardwar e ș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 interfața dintre rețea și programul aplicație.
c. LIN Configuration Language descrie formatu l 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 )”

Fig. 1

O rețea LIN este alcătuită dintr -un master LIN și unul sau mai mulți sclapi LIN.
De obicei, în aplicații auto, magistrala LIN este conectată între un senzor inteligent sau
dispozitive de acționare și o unitate electronică de comandă (ECU), ad esea un gateway
cu magistrala CAN. Puteți găsi mai multe magistrale LIN care nu sunt interconectate
între ele așa cum se arată în figura de mai jos. Aceasta este o diferență majoră față de alte

Rețelele de comunicație LIN și CAN
8
autobuze cu cost redus, cum ar fi linia K, destinată conectări i tuturor ECU -urilor la un
instrument extern de analiză pentru diagnosticare.

Fig. 2

1.1.1. Concepte de bază

„Mesajele
Informația pe bus este transmisă în format fix de lungime variabilă. Fiecare frame
de mesaj este compus din 2, 4 sau 8 octeți de dat e ș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 sincronizare și de unul de identificare, toți
trimiși de master. Slave -ul trimite înapoi câmpu l de date și cel de control (figura 3).
Datele pot fi trimise de la master (unitatea de control a master -ului) la orice slave
(unitatea de control a slave -ului) prin slave task. O comunicare slave -la-slave poate fi
determinată de un ID de mesaj similar dat de master. ”
Numai nodul principal inițiază comunicarea într -o rețea LIN. Nodul principal
definește viteza de transmisie, trimite impulsuri de sincronizare și monitorizează datele și

Rețelele de comunicație LIN și CAN
9
comută nodurile slave în modul somn / trezire. De asemenea, primește Wake up Break de
la nodurile slave atunci când autobuzul este inactiv și solicită o acțiune. Un nod slave
așteaptă impulsul de sincronizare și apoi face sincronizarea utilizând impulsul de
sincronizare și procesează identificatorul mesajului. Apoi, conform ID -ului, sclavul
decide ce să facă, fie pentru a primi date, fie pentru a transmite sau a nu face nimic. În
timp ce îl transmite, trimite 2, 4 sau 8 octeți de date în funcție de ID -ul primit, plus un
byte de control. Cele două tipuri de mesaje de date din rețe aua LIN sunt semnalul (datele
trimise în cadrul de date) și mesajul de diagnosticare.
Rețeaua constă într -o sarcină principală și mai multe sarcini slave. În nodul
master pot fi găsite ambele tasksmaster & slave, dar într -un nod slave numai sarcina
slave. Comunicarea poate avea loc de la nodul principal (folosind sarcina slave) la unul
sau mai multe noduri slave și de la un nod slave la nodul principal și / sau alte noduri
slave. Comunicarea este, de asemenea, posibilă direct de la slave la slave, fără a ru ta prin
nodul principal. LIN utilizează cadre pentru comunicații de date. Un cadru constă dintr –
un antet, un răspuns și un spațiu de răspuns, astfel încât sclavul va avea timp să răspundă.
Comandantul trimite un antet al mesajului sau, cu alte cuvinte, ant etele sunt situate într -o
sarcină principală, conține pauze de sincronizare, octet de sincronizare și identificatorul
mesajului, fiecare parte începe cu un bit de pornire și se termină cu un bit de stop.
Răspunsul conține unul până la opt octeți de date și un octet de control. Slave sarcina
este conectat la identificator și primește răspunsul, verifică suma de control și utilizează
transportul de date. Mesajele sunt create atunci când nodul principal trimite un cadru care
conține un antet. Nodul (i) slave u mple apoi cadrul cu date în funcție de antetul trimis de
master.

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

Fig. 3

Informația
„În sistemul LIN un nod nu folosește informația despre configurația sistemului,
exceptând nodul de master.
Flexibilitatea sistemului
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 este de 64, ,din care 4 sunt rezer vaț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ță.

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

Viteza
Viteza maximă este de 20kbiti/sec dată de l imită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 ur mă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 eroar e 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
Performanța detecției erorilor
– toate erorile locale la transmițător sunt detectate
– acoperire mare a protocolului global de erori ”

Rețelele de comunicație LIN și CAN
12
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 cadru. Un semnal este înto tdeauna 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 depinde 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 octeți trebuie
să treacă p rintr-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 timp cât editorul
semnalul ui 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.
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 head er-ul pe magistrală.
Un semnal este considerat recepționat și disponibil pentru aplicație după cum
urmează (figura 4):

Rețelele de comunicație LIN și CAN
13
– Nod master – la următorul bază de timp după lungimea maximă a cadrului. Nodul
master actualizează periodic semnalele recepționate la înc eputul 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 t ransmis în situațiile (figura 5) :
– Nod master – înainte ca transmisia cadrului să fie inițiată.
– Nod slave – când ID -ul pentru același cadru este recepționat ”

Fig. 4 – Timpul recepției semnalului

Fig. 5 – Timpul transmisiei semnalului

SCI este emulat de software utilizând captura de intrare și com pararea de ieșire a
timerului pe 16 biți pe chip. Când busul este inactiv, software -ul așteaptă o margine
negativă: Întreruperea capturii de intrare este activată și sună întreruperea LIN atunci
când apare o margine negativă. Timpul de captură de intrare e ste folosit pentru a genera
o comparație de ieșire în mijlocul primului bit. Rutina de întrerupere LIN se întoarce la
programul apelant. Când se produce evenimentul de comparare a ieșirii, întreruperea LIN
este chemată din nou. Nivelul magistralei este ver ificat și se stabilește o nouă comparație
de ieșire în mijlocul următorului bit. Ultimul proces se repetă până la stop.
Ca urmare, aplicația software nu trebuie:

Rețelele de comunicație LIN și CAN
14
– întârzierea apariției întreruperii IC prea mult. În mod specific: apare o problemă
dacă prim a comparație de ieșire este setată după apariția așteptată a evenimentului
comparație de ieșire, care este mijlocul bitului. Atât timp cât întreruperea IC se termină
înainte de mijlocul biților, întârzierea este acceptabilă. Vezi figura 6.

Fig. 6

– Întârzierea apariției fiecărui OC întrerupe prea mult. În mod specific: apare o
problemă dacă timpul de eșantionare definit la începutul întreruperii este întârziat astfel
încât să apară după s fârșitul bitului. Vezi figura 7.

Fig. 7

Pentru transmisie, softw are-ul folosește doar caracteristica Output Compare a
cronometrului pe 16 biți. Pentru fiecare bit, se generează două întreruperi OC. Primul
este generat pentru a extrage valoarea noului bit. Cel de -al doilea este folosit pentru

Rețelele de comunicație LIN și CAN
15
citirea înapoi a magistrale i și verificarea faptului că valoarea de ieșire este de fapt
trimisă, cu alte cuvinte pentru a verifica dacă există o eroare de biți. Vezi figura 8 .

Fig. 8

Filtrarea mesajelor se bazează pe întreg 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ării. Dacă mesajul este
corupt, este considerat de master și de slave ca fiind netransmis.
În întârzierile de transmisie provenite din aplicație nu poate fi afectată
funcționarea corespunzătoare a software -ului. Acest lucru va întârzia transmiterea și
problema este mai mult o problemă de expirare pe cadrul transmis curent: Dacă timpul
de întrerupere este foarte lung, cadrul transmis poate depăși timpul maxim permis al
cadrului. Întreruperea SCI în transmisie are loc și la stop. Dacă apariția întreruperii este
întârziată de aplicare, timpul de interbate va crește.

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ă s uma dintre suma inversată modulo 256 a
tuturor octeților recepționați și suma de control nu este ’0xFF’.

Rețelele de comunicație LIN și CAN
16
3. Eroare identificator paritate. Aplicațiile LIN obișnuite nu deosebesc un
identificator valid dar necunoscut și unul corupt. Totuși este obligatoriu pen tru
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 sincronizare. Se detectează dacă un slave detectează fronturile
câmpului de sincronizare înafara to leranț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 ultimului mesaj
valid.

Semnalizarea erorilor . Detecția erorilor nu se face de către protocol ul 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 erori lor și dignosticul. Este foarte
dependent de cerințele sistemului și prin urmare nu face parte din protocolul LIN cu
excepția unor aspecte.

Unitatea de control master
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 da te 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

Rețelele de comunicație LIN și CAN
17
– 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 la un alt
slave în intervalul de lungime maximă a frame -ului de mesaje T FRAME_MAX . Când un
fram e 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 este detectat în toleranța admsă.

1.4 Managementul puterii în rețeaua LIN

Gestionarea rețelei într-un cluster LIN conține "trezire" și "go -to sleep".
Toate nodurile slave dintr -un cluster LIN activ pot fi modificate în modul de
hibernare prin trimiterea unui cadru de solicitare a masterului de diagnosticare cu primul
octet de date egal cu zero. Ac eastă utilizare specială a unui cadru de diagnostic este
numită comanda go -to-sleep. Slave nodurile pot intra automat în modul sleep dacă busul
LIN este inactiv timp de mai mult de 4 secunde.
Orice nod dintr -un cluster LIN care poate dormi poate trimite o cerere de cluster
de trezire. Cererea de trezire poate schimba magistrala în starea dominantă pentru 250 ms
până la 5 ms. Fiecare nod de slave poate detecta cererea de trezire (un impuls dominant
mai mare de 150 ms) și să fie gata să asculte comenzile magi stralelor în decurs de 100
ms, măsurate de la marginea finală a impulsului dominant.
Nodul principal se poate, de asemenea, trezi și, când nodurile slave sunt gata,
începeți să trimiteți anteturile de cadre pentru a afla cauza trezirii. Dacă masterul nu
obține anteturi de cadre în termen de 150 ms de la cererea de trezire, nodul care trimite
cererea poate încerca să trimită o nouă solicitare de trezire. După trei solicitări nereușite,
nodul trebuie să aștepte minim 1,5 secunde înainte de a trimite oa treia solicitare de
trezire.
Protocolul LIN permite să fie în modul somn pentru a fi conform cu standardele și
constrângerile de mediu. Când vehiculul nu este utilizat, consumul întregului vehicul
trebuie să fie mai mic de câteva milliampe, pentru a nu descărca bateria. Deci, fiecare

Rețelele de comunicație LIN și CAN
18
ECU trebuie să intre în modul de repaus. Astfel, strategiile au fost implementate pentru a
gestiona modurile de somn / trezire de pe bussesurile de comunicare.
Comandantul trebuie să trimită de trei ori solicitarea modului de repaus:
identificatorul 0x3C și octetul de date 0x00. Sclavii trebuie să intre în modul de repaus în
mai puțin de 25000 BitTime și apoi autobuzul să rămână la nivelul recesiv.
Timpul dintre prima comandă de somn și modul eficient de repaus este mai mic
de 30 ms + Tsleep.

Fig. 9

Dacă apare un eveniment, un sclav poate să trezească comandantul și
comunicarea va începe din nou. Acesta va folosi identificatorul de trezire 0x80. Stăpânul
trebuie să gestioneze un semnal rău de trezire. Când autobuzul devine dominant, este o
condiție de trezire. Cu toate acestea, comandantul trebuie să verifice validitatea
mesajului de avertizare pentru a începe din nou operația normală.

Fig. 10

Stăpânul poate să trezească sclavi prin trimiterea mesajului de avertizare 0x80.
Odată ce cererea a fost trimisă, comandantul își reia comunicarea normală.

Fig. 11

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

1.5 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 f olosirea 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

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 arbit rare, 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
20

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, care 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 dat e 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 fo st împărțit în nivele:
– nivelul obiect
– 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 mesaje lor de transmis
– decizia asupra mesajului 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
21

Scopul nivelului de transport este protocolul de transfer (controlul cadrelor,
arbitrajul, d etecț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ă m odificări.
Scopul nivelului fizic reprezintă 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ă

Majoritatea aplicațiilor din rețea urmează o abordare stratificată a implementării
sistemului. Această abordare sistematică permite interoperabilitatea între produsele
producătorilor diferiți. Un standard a fost creat de Organizația Internațională pentru
Standarde (ISO) drept model care trebuie urmat pentru această abordare stratificată. Se
numește Model de referință pentru straturile de rețea pentru interconectarea sistemelor
ISO Open Systems (OSI) și este prezentat în figura 1 pentru referință.
Protocolul CAN implementează cel mai mult cele două str aturi inferioare ale
acestui model de referință. Partea din mediul de comunicare a modelului a fost lăsată în
mod intenționat din specificația CAN Bosch pentru a permite proiectanților de sistem să
adapteze și să optimizeze protocolul de comunicare pe mai multe medii pentru
flexibilitate maximă (pereche torsadată, izolație izolată, RF, IR etc.) . Cu această
flexibilitate vine totuși posibilitatea unor preocupări privind interoperabilitatea.
Pentru a ușura unele dintre aceste preocupări, Organizația Internaț ională pentru
Standarde și Societatea Inginerilor de Automobile (SAE) a definit câteva protocoale
bazate pe CAN care includ definiția Interfeței Dependente Media, astfel încât să fie
specificate toate cele două straturi inferioare.
„
CAN are o structură p e 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.

Rețelele de comunicație LIN și CAN
22
– Nivelul de transfer reprezintă nucle ul (kernel) protocolului CAN. Acesta
prezintă mesajele recepționate ș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ți e de erori, semnalizare și reținerea defectelor.
– Nivelul obiect 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 asigură
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
modulu i cum sunt transferate, validate, codate și testate pentru detecț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 dispozi tiv conectat la magistrală
atâta vreme cât aceasta din urmă este liberă.
Multi-distribuție . Oricare dintre noduri pot recepționa și acționa simultan la
același mesaj . Mesajele au priorități diferite, aceasta fiind definită prin identificator.
Dacă un nod c ere altui nod un pachet de date , acesta trimite pachetul cu același
identificator ca și cererea.
Structura nodurilor CAN. Stratul de obiecte se ocupă de filtrarea mesajelor,
precum și de gestionarea stării și a mesajelor. Stratul de transfer reprezintă nu cleul
protocolului CAN. Prezintă mesajele primite la stratul de obiecte și acceptă mesajele care
trebuie transmise prin stratul de obiecte. Stratul de transfer este responsabil pentru
sincronizarea și sincronizarea biților, încadrarea mesajelor, arbitrajul , recunoașterea,
detectarea și semnalizarea erorilor și confidențialitatea erorilor. Stratul fizic definește
modul în care sunt transmise efectiv semnalele. Stratul fizic nu este definit aici, deoarece
va varia în funcție de cerințele aplicațiilor individu ale (de exemplu, implementările de
mediu de transmisie și de semnal).
Informația de routing. În sistemele CAN un nod nu utilizează nicio informație
despre configurația sistemului (de exemplu, adresele de noduri). Acest lucru are câteva
consecințe important e.

Rețelele de comunicație LIN și CAN
23
Flexibilitatea sistemului. Nodurile pot fi adăugate în rețeaua CAN fără a fi
necesară nicio modificare a software -ului sau a hardware -ului unui nod sau a stratului
aplicației.
Rutarea Mesajelor. Conținutul unui mesaj este descris de un identificator.
Identificatorul nu indică destinația mesajului, ci descrie semnificația datelor, astfel încât
toți nodurile din rețea să poată decide prin filtrarea mesajelor dacă datele vor fi prelucrate
de acestea sau nu.
Cosistența datelor. Într-o rețea CAN se garanteaz ă că un mesaj este acceptat
simultan fie de către toate nodurile, fie de nici un nod. Astfel, consistența datelor este o
proprietate a sistemului realizată de conceptele de multicast și de manipularea erorilor.
Conceptul CAN garantează că un 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.
Magistrala CAN e ste de tip multi -master, oricare din noduri putând porni
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
pierdută. Dacă transmisia unui mesaj de date și a unui mesaj de cerere de date, având
același identificator, s unt inițiate în același timp, atunci mesajul de date are prioritate. În
timpul arbirajului fiecare transmițător compară nivelul bitului transmis cu nivelul 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 pierdut arbitrajul și trebuie să
se retragaă fără a mai transmite vreun bit.
Singuranța transferului datelor e ste asigurată prin metodele de detecție a erorilor,
semnalizare și auto -verificare implementate:
– detecția erorilor presupune următoarele măsuri: monitorizarea (emițătoarele
compară nivelele biților de transmis cu cele detectate pe magistrală), verificare a
redundanței ciclice, umplerea biților (bit stuffing) și verificarea structurii mesajului.

Rețelele de comunicație LIN și CAN
24
– 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 mesajelor 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 nodu ri.
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 sin cronizare, dar și
datele în sine. Tensiunea de pe 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 c ea 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 circuitele 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ă
pentr u 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=regresiv, d =dominant). ”

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

2.2 Transferul mesajelor

Protocolul CAN este un protocol bazat pe mesaje, nu un protocol bazat pe adrese.
Acest lucru înseamnă că mesajele nu sunt transmise de la un nod la alt no d pe baza
adreselor. Încorporat în mesajul CAN în sine este prioritatea și conținutul datelor
transmise. Toate nodurile din sistem primesc fiecare mesaj transmis pe magistrală (și vor
confirma dacă mesajul a fost primit în mod corespunzător). Depinde de fi ecare nod din
sistem să decidă dacă mesajul primit ar trebui să fie imediat aruncat sau să fie prelucrat.
Un singur mesaj poate fi destinat pentru un anumit nod pentru a primi sau pentru multe
noduri bazate pe modul în care sunt proiectate rețeaua și siste mul.
De exemplu, un senzor de airbag pentru autovehicule poate fi conectat prin CAN
doar la un nod de router al sistemului de siguranță. Acest nod router are alte informații
despre sistemul de siguranță și îl direcționează către toate celelalte noduri din rețeaua
sistemului de siguranță. Apoi, toate celelalte noduri din rețeaua de sisteme de siguranță
pot recepționa simultan cele mai recente informații ale senzorului airbag -ului din router,
confirmă dacă mesajul a fost recepționat corect și dacă decide să u tilizeze aceste
informații sau să le elimine.
O altă caracteristică utilă integrată în protocolul CAN este capacitatea unui nod de
a solicita informații de la alte noduri. Aceasta se numește Cerere de transmisie la distanță
(RTR). Acest lucru este diferit de exemplul din paragraful precedent deoarece, în loc să
aștepte ca informațiile să fie trimise de un anumit nod, acest nod cere în mod specific
date care trebuie trimise către el.
De exemplu, un sistem de siguranță într -o mașină primește actualizări frecv ente
de la senzori critici, cum ar fi airbagurile, însă este posibil să nu primească actualizări
frecvente de la alți senzori, cum ar fi senzorul de presiune a uleiului sau senzorul de
baterie scăzută, pentru a vă asigura că acestea funcționează corect. Pe riodic, sistemul de
siguranță poate solicita date de la acești alți senzori și poate efectua o verificare completă
a sistemului de siguranță. Designerul de sistem poate utiliza această caracteristică pentru
a minimiza traficul în rețea, menținând în acelaș i timp integritatea rețelei.
Un avantaj suplimentar al acestui protocol bazat pe mesaje este că pot fi adăugate
noduri suplimentare în sistem fără a fi nevoie să reprogramați toate celelalte noduri

Rețelele de comunicație LIN și CAN
26
pentru a recunoaște această adăugire. Acest nou nod va înc epe să primească mesaje din
rețea și, pe baza ID -ului mesajului, decide dacă va procesa sau ar elimina informațiile
primite.
Protocolul CAN definește patru tipuri diferite de mesaje (sau Frames). Primul și
cel mai comun tip de cadru este un cadru de date. Acest lucru este folosit atunci când un
nod transmite informații către oricare sau toate celelalte noduri din sistem. În al doilea
rând, este un cadru la distanță, care este în esență un cadru de date cu bitul RTR setat
pentru a indica că este o solicitare de transmisie la distanță. Celelalte două tipuri de cadre
sunt pentru erorile de manipulare. Unul se numește Frame Error și unul se numește
Frame Overload. Rata de eroare este generată de noduri care detectează oricare dintre
erorile de protocol definite de CAN. Erori de suprasarcină sunt generate de noduri care
necesită mai mult timp pentru a procesa mesajele deja primite.
Ori de câte ori magistrala este liberă, orice nod poate începe să transmită un
mesaj. Dacă două sau mai multe noduri încep să transmit ă mesaje în același timp,
conflictul de acces la magistrală este rezolvat printr -o arbitrare biți folosind
identificatorul. Mecanismul arbitrajului garantează că nici informațiile, nici timpul nu
sunt pierdute. Dacă un cadru de date și un cadru la distanță cu același identificator sunt
inițiate în același timp, cadrul de date predomină peste cadrul Remote. În timpul
arbitrajului fiecare transmițător compară nivelul bitului transmis cu nivelul monitorizat
pe magistrală. Dacă aceste nivele sunt egale, nodul p oate continua să trimită. Când un
nivel recesiv este trimis, dar un nivel dominant este monitorizat, nodul a pierdut
arbitrajul și trebuie să se retragă fără a trimite biți suplimentari.

„Pe magistrala CAN se pot transmite 4 tipuri de mesaje:
– mesaj de d ate – 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ărca re – anunță o cerere de întârziere între mesajul
precedent și cel următor.
Mesajele de date și cele de cerere sunt separate de mesajele precedente printr -un
spațiu intermesaj (figura 12 și figura 13).””

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

Fig. 12 – Structura unui mesaj de date

„Mesajul d e 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âmpul de
date poate avea și lungimea zero.
Câmpul de start marchează începutul mesajului de date sau de cerere și cons tă
dintr -un singur bit dominant. Un nod poate începe transmisia doar când magistrala este
liberă (idle). Toate nodurile trebuie să se sincronizeze pe frontul crescător al acestui
câmp.
Câmpul de arbitrare conține un identificator și un bit RTR. Identificat orul 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 semnificativi 7 biți (ID10 la ID4) nu trebuie să fie toți
regresivi. Bit -ul RTR (Remote Transmission Request) este bit dom inant î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 lun gimea î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.

Rețelele de comunicație LIN și CAN
28
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 este 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 d e mesaj. ”

Fig. 13 – Structura unui mesaj de cerere

Mesajul de eroare (figura 14 ) constă în două câpuri diferite. Primul este dat de
suprapunerea 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
eroare în mod corect, un nod are nevoie ca magistrala să fie liberă cel puțin 3 perioade de
bit.

Fig. 14 – Structura unui mesaj de eroare

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

„Mesajul de supraîncărcare (figura 15) conține două câmp uri 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 receptorului 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. 15 – Structura unui mesaj de supraîncărcare

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

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

Fig. 16 – Spațiu intermesaj

2.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 17)

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

Rețelele de comunicație LIN și CAN
31
2.4 Detectarea erorilor

O valoare de verificare a redundanței ciclice pe 15 biți (CRC) este calculată de
către nodul de transmisie și această va loare de 15 biți este transmisă în câmpul CRC.
Toate nodurile din rețea primesc acest mesaj, calculează un CRC și verifică dacă valorile
CRC se potrivesc. Dacă valorile nu se potrivesc, apare o eroare CRC și se generează un
cadru de eroare. Deoarece cel pu țin un nod nu a primit mesajul în mod corespunzător,
acesta este apoi trimis după un timp corespunzător de întrerupere.
În câmpul Acknowledge al unui mesaj, nodul de transmisie verifică dacă Slotul de
confirmare (pe care l -a trimis ca bit recesiv) conține un bit dominant. Acest bit dominant
ar recunoaște faptul că cel puțin un nod a primit corect mesajul. Dacă acest bit este
recesiv, atunci niciun nod nu a primit mesajul corect. A apărut o eroare de confirmare.
Apoi, se generează un cadru de eroare, iar mes ajul original va fi repetat după o perioadă
de întrerupere corespunzătoare.
Dacă un nod detectează un bit dominant într -unul din următoarele patru segmente
ale mesajului: End of Frame, Interframe Space, Acknowledge Delimiter sau CRC
Delimiter, protocolul C AN definește aceasta ca fiind o încălcare a formularului și este
generată o eroare de formă. Mesajul inițial este apoi trimis după un timp corespunzător
de întrerupere.
O eroare de bit apare dacă un transmițător trimite un bit dominant și detectează un
bit recesiv sau dacă trimite un bit recesiv și detectează un bit dominant atunci când
monitorizează nivelul real al magistralei și îl compară cu bitul pe care tocmai la trimis. În
cazul în care transmițătorul trimite un bit recesiv și un bit dominant este de tectat în
câmpul de arbitrare sau în caseta de confirmare, nu se generează nicio eroare de biți
deoarece se produce arbitraj sau confirmare normală. Dacă se detectează o eroare de biți,
se generează un cadru de eroare, iar mesajul inițial este trimis după un timp
corespunzător de întrerupere.
Protocolul CAN utilizează o metodă de transmisie non -return -to-zero (NRZ).
Aceasta înseamnă că nivelul de biți este plasat pe magistrală pentru întregul timp de biți.
CAN este, de asemenea, asincronă, iar umplutura de biți este utilizată pentru a permite
sincronizării nodurilor receptoare prin recuperarea informațiilor de ceas din fluxul de
date. Nodurile de primire se sincronizează pe tranziții recesive cu cele dominante. Dacă

Rețelele de comunicație LIN și CAN
32
există mai mult de cinci biți de aceeași p olaritate într -un rând, CAN va umple automat un
bit de polaritate opus în fluxul de date. Nodul recepționer (e) îl va folosi pentru
sincronizare, dar va ignora bitul de chestii în scopuri de date. Dacă, între începutul
cadrului și CRC Delimiter, sunt detec tați șase biți consecutivi cu aceeași polaritate,
atunci regula de umplutură a biților a fost încălcată. Apare o eroare de lucru, se trimite un
cadru de eroare și se repetă mesajul.
Erori le detectate sunt făcute publice tuturor celorlalte noduri prin Frame s de
eroare sau Flaguri de eroare. Transmisia unui mesaj eronat este întreruptă, iar cadrul se
repetă de îndată ce mesajul poate câștiga din nou arbitraj în rețea. De asemenea, fiecare
nod se află într -una din cele trei stări de eroare, eroare activă, eroa re pasivă sau bus -off.
Un nod Eroare -activ poate lua parte activ la comunicația cu magistrală, inclusiv
trimiterea unui semn de eroare activ, care constă din șase biți dominanți consecutivi.
Flagul de eroare încalcă în mod activ regula de umplere a biților și determină ca toate
celelalte noduri să trimită un mesaj de eroare, denumit Flag Echo de eroare, ca răspuns.
Un flag activ de eroare, iar ulterior Error Echo Flag poate provoca până la doisprezece
biți dominanți consecutivi pe autobuz; șase de la Flagul de eroare activă și zero până la
încă șase de la Flag Echo de eroare, în funcție de momentul în care fiecare nod
detectează o eroare pe magistrală. Un nod este Error -Active atunci când atât Contorul de
eroare de transmisie (TEC), cât și Counter Error Rece ive (REC) sunt mai mici de 128.
Error -Active este modul normal de funcționare, permițând nodului să transmită și să
primească fără restricții.
Un nod devine Eroare -Pasivă când fie Counter -eroarele de transmisie, fie
Counter -eroarele de recepție depășesc 12 7. Nodurile de eroare -pasive nu au permisiunea
de a transmite semnele de eroare activă pe magistrala, ci transmit în schimb semnale de
eroare pasivă care constau din șase biți recesivi. Dacă nodul de eroare pasiv este în
prezent singurul emițător pe magist rală, atunci pavilionul de eroare pasivă va încălca
regula de umplutură a biților și nodurile receptoare vor răspunde cu propriile lor etichete
de eroare (fie active, fie pasive, în funcție de propria eroare stat). Dacă nodul de eroare
pasiv în cauză nu es te singurul emițător (adică în timpul arbitrajului) sau este un
receptor, atunci semnalul de eroare pasivă nu va avea niciun efect asupra magistralei
datorită naturii recesive a semnalizatorului de eroare. Atunci când un nod de eroare
pasivă transmite un s emn de eroare pasivă și detectează un bit dominant, acesta trebuie

Rețelele de comunicație LIN și CAN
33
să vadă magistrala ca fiind inactivă timp de opt ori mai mult timp după o întrerupere
înainte de a recunoaște autobuzul ca fiind disponibil. După aceasta, va încerca să
retransmită.
Un nod intră în starea Bus -Off când eroarea de transmisie este mai mare de 255
(erorile de recepție nu pot determina un nod să meargă la Bus -Off). În acest mod, nodul
nu poate trimite sau primi mesaje, confirma mesaje sau transmite cadre de eroare de
orice fel. A cesta este modul în care se realizează confundarea cu erori. Există o secvență
de recuperare a magistralei care este definită de protocolul CAN care permite unui nod
care este Bus -Off să se recupereze, să revină la Error -Active și să înceapă din nou să
transmită în cazul în care condiția de defect este eliminată.

2.5 Avantaje și dezavantaje

„Protocolul CAN este 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 implică 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 adresează 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, imunitat ea 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.

Rețelele de comunicație LIN și CAN
34
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 transferul 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, uti lizâ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
cu nivelul existent pe magistrală. Daca nivelele sunt egale, unitatea co ntinuă să
transmita. Dacă ea transmite un nivel “recesiv” și magistrala monitorizează un nivel
“dominant”, unitatea pierde arbitrarea și trebuie să se retraga, fară a mai transmite un
singur bit. Acest sistem de arbitrare, conceput special pentru autovehic ule, permite
rezolvarea unor evenimente de importanță mai mare în funcționarea mașinii, care
necesită o decizie mai rapidă, prioritar față de evenimente pentru care deciziile mai pot
întârzia. ”
Protocolul CAN a fost optimizat pentru sistemele care trebuie să transmită și să
primească cantități relativ mici de informații (comparativ cu Ethernet sau USB, care sunt
proiectate să transfere blocuri de date mult mai mari) în mod fiabil la oricare sau la toate
celelalte noduri din rețea. CSMA / CD permite fiecărui nod să aibă șanse egale de a avea
acces la autobuz și permite o manevrare ușoară a coliziunilor.
Deoarece protocolul este bazat pe mesaje, nu pe bază de adrese, toate mesajele de
pe magistrală primesc fiecare mesaj și confirmă fiecare mesaj, indiferent da că are nevoie
de date sau nu. Acest lucru permite ca magistrala să funcționeze în formate de mesaje
nod-nod sau multicast fără a trebui să trimită diferite tipuri de mesaje.
Transmisia rapidă și robustă a mesajului cu limitarea defecțiunilor este, de
aseme nea, un mare plus pentru CAN deoarece nodurile defecte vor cădea automat pe
magistrală, permițând niciunui nod să nu aducă o rețea în jos. Acest lucru garantează în
mod eficient că lățimea de bandă va fi întotdeauna disponibilă pentru transmiterea
mesajelo r critice. Cu toate aceste beneficii integrate în protocolul CAN și impulsul său în

Rețelele de comunicație LIN și CAN
35
lumea automobilelor, alte piețe vor începe să vadă și să pună în aplicare CAN în
sistemele lor.

2.6 LIN versus CAN

Unele dintre principalele dezavantaje ale LIN sunt lărg imea de bandă mai mică și
schema de acces la magistrale mai puțin eficiente cu configurația master -slave.
Nu există niciun sens de a compara CAN și LIN deoarece nu abordează aceleași
probleme. Cu toate acestea, vă poate oferi o imagine generală a LIN în im aginea de
ansamblu. După cum am văzut deja, LIN se adresează aplicațiilor low -end, unde costul
de comunicare pe nod trebuie să fie de două până la trei ori mai mic decât cel al CAN,
dar în cazul în care performanțele, robustețea și versatilitatea CAN nu su nt necesare.
Principalul factor economic în favoarea LIN este evitarea rezonatoarelor de cuarț sau
reziduuri ceramice în nodurile slave, deoarece acestea pot efectua auto -sincronizarea. Un
mic studiu comparativ oferă următoarele puncte.

Fig. 1 8

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

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 quartz de 16000kHz
și o rată de transfe r a datelor de 500kbps. (Fig. 19 )

Fig. 19 – Configurație

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

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

Fig. 20 – 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 21 )

Fig. 21 – Interconectarea nodurilor în rețea

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

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

Fig. 22 – 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 semnale.
Nodul BCM trimite 3 mesaje : Klemmen, ReqData, ReqEngineStatus și primește
3 mesaje de la nodul Motor pri mește mesajul CarStatus iar de la nodul Key primește 2
mesaje : KeyData si KeyRequest.
Nodul Key trimite 2 mesaje : KeyData, KeyRequest și primește 2 mesaje de la
BCM : Klemmen și ReqData.
Nodul Motor trimite un singur mesaj CarStatus și primește 2 mesaj e 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 standard , dacă era extin s în colana ID -format apă rea CAN Extended.
DLC (data lenght code) este numarul de biți din câmp ul de date acesta poate să difere în

Rețelele de comunicație LIN și CAN
39
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 At tributes – 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. 23 – 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 Order depinde de microcontrolerul folosit poate fi Intel sau
Motorola. Coloana cu Value Type conține tipul datei c u 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 care î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_STAT reprezintă valoarea CRC (Control Redundant Ciclic)
pentru data salvată în mesaj.
Semnalul ALIVE_CAR_STAT est e 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 incremeteze.
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
40
Semnalul VEH_SPEED este semnalul ce oferă informații asupra vitezei mașinii. ”

Fig. 24 – Semnale din mesajul CarStatus

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

Fig. 25 – Semnalul din mesajul KeyData

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

Fig. 26 – Semnalele din mesajul KeyRequest

„Mesajul Klemmen conține patru semnale.
Semanlul CRC_Klemmen 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
incremeteze.
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
41
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 po ate
lua urmatoarele valori: 0 – released , 1 – pressed. Valoarea default este 0. ”

Fig. 27 – Semnalele din mesajul Kelemmen

Mesajul ReqData conț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. 28 – 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 motoru lui.

Fig. 29 – Semnalul mesajului ReqEngineStatus

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

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

Fig. 30 – Rețeaua CAN

„Pentru a putea comunica între noduri , în spatele fiecarui nod stă un cod CAPL(or
CAN Access Programming L anguage).
În figura 31 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 d ata 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 mesaje le î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 simulat
atunci in coloana Dir am fi avut RX. ”

Fig. 31 – Transmiterea semnalelor pe rețeaua CAN

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

Observăm că fiec are 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. 32 – 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 es te 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 semnifică 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
44
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 dechidere -închidere a uși și se presupune ca șoferul nu este în
mașina.
Dacă șoferul este în mașină și a fost apasa t 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 este 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
45
Concluzii

„În aceast ă lucrare s -au studiat două protocoale de comuni cație ut ilizate î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 c and 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 pune toate
nodurile informația odata pe bus, nodurile trebuie să astepte și să reactioneze în functie
de un tabe l 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 cadrului 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 cerere răspuns.
Protocolul CAN a fost optimizat pentru sistemele care trebuie să transmită și să
primească cantit ăți relativ mici de informații (comparativ cu Ethernet sau USB, care sunt
proiectate să transfere blocuri de date mult mai mari) în mod fiabil la oricare sau la toate
celelalte noduri din rețea. CSMA / CD permite fiecărui nod să aibă șanse egale de a avea
acces la autobuz și permite o manevrare ușoară a coliziunilor.

Rețelele de comunicație LIN și CAN
46
Acronime

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
ISO International Standardization Organization
SAE Society of Automotive Engineers
LSB Lower Significa nt Bit
CPLD Complex Programmable Logic Device
MSB Most Significant Bit
OSI Open Systems Interconnections
SCI Serial Communication Interface
UART Universal Asynchronous Receiver Transmitter

Rețelele de comunicație LIN și CAN
47
Bibliografie

1. Lin Specification Package, Rev ision 2.2a, Lin Consortium, 2010
2. Canoe Tutorial, Version 2.0, 2008
3. Testing With Canoe, Version 1.0, 2005
4. Rețele Pentru Comunicatii Industriale, Miron Mandoiu – Universitatea Politehnica
Bucuresti, 2007.
5. http://www.e -automobile.ro/categorie -electronica/74 -protocol -can-auto.html
6. Local Interconnect Network, Universitatea Politehnica Timișoara Facultatea De
Electronică Și Telecomunicații
7. Vector Informatik Gmbh, E -Learni ng, Lin Bus, https://elearning.vector.com
8. http://www.lin -subbus.org/
9. Lin Specification Package Revision 1.3 – December 12th, 2002 – Lin Consortium
10. Lin (Local Interconne ct Network) Solutions, Microcontroller Division
Applications
11. Controller Area Network (Can) Basics, Keith Pazul & Microchip Technology Inc.
12. Lin ( Local Interconnect Network ), Stéphane REY, Revision 1.0 – May 13th, 2003