UNIVERSITATEA TEHNICĂ “GHEORGHE ASACHI” din IAŞI

FACULTATEA DE AUTOMATICĂ ŞI CALCULATOARE

Protocol de comunicație
LIN(Local Interconnect Network)

Profesor: Student:
Postolache Mihai Baban Marius Adrian

1
 Standardul LIN
(Local Interconnect Network)

Noţiuni introductive LIN

• LIN este o magistrală serială bazată pe magistrala SCI /UART, cu transmitere pe octet,
protocol de comunicaţie declanşat în timp
• LIN este o reţea serială de tip broadcast (difuzare) – nu se folosesc adrese fizice pentru
nodurile sclav (la fel ca la CAN)
• La LIN toate mesajele sunt inițiate de master, cu cel mult un sclav care răspunde unui
identificator al mesajului dat
– Nu există coliziuni şi nu e necesară arbitrare
• Masterul conţine un microcontroler mai de puternic
• Sclavii pot conţine microprocesoare mai puțin puternice şi mai ieftine, sau ASIC-uri
dedicate.
• Mecanismul de sincronizare permite recuperarea ceasului la noduri sclav fără cuarț sau
rezonator ceramic
– Numai nodul master va utiliza un oscilator de ceas cu cuarţ.

Structura fizică generală a reţelei LIN

• Un cluster LIN este format dintr-un număr de noduri, care sunt

interconectate printr-un mediu fizic de transmisie
– Nod master - controlează accesul la magistrală
– Noduri sclav - pot trimite și primi informații.
• Din motive de cost, nu se implementează un controler dedicat de
comunicaţie
• Potocolul de comunicaţie este integrat ca o componentă software în
microcontroler (task master / slave)

2
• Un cluster conţine un task master şi mai multe task-uri sclav
• Nodul master conţine ambele taskuri
– Task master decide când și ce cadru va fi transferat pe magistrală
– Taskurile sclav furnizează datele transportate de fiecare cadru.

Principiul simplificat al interfeţei – driver şi niveluri de tensiune

Cluster LIN

Niveluri de tensiune pe linia magistralei

3
 LIN completează protocoalele de comunicaţie în domeniul automotive în zona de
cost scăzut.

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
dezvoltare LIN garantează interoperabilitatea nodurilor reţelei din punct de vedere
hardware şi software, şi o comportare EMC predictibilă.

4
 Pachetul de specificaţii conţine 3 părţi :
-Protocolul LIN descrie nivelul fizic şi cel de date a LIN.
-LIN API descrie interfaţa dintre reţea şi programul aplicaţie.
-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.
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 este prezentat mai jos:

5
 Nivelul fizic defineşte cum se transmit semnalele pe magistrală. Tot aici apar
definite caracteristicile receptorului şi a driverului.
Nivelul 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”.
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 fix 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 sincronizare şi de unul de identificare, toţi
trimişi de master. Slave-ul trimite înapoi câmpul de date şi cel de control.
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.
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
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ţă.

6
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:

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
Performanţa detecţiei erorilor
- toate erorile locale la transmiţător sunt detectate
- acoperire mare a protocolului global de erori

Transferul Mesajelor
Există un singur frame de mesaje. Acesta poartă informaţia de sincronizare şi
identificatorul de la master task la toate slave task şi informaţii de la un slave task la
celelalte slave task. Master task se află în nodul master şi este răspunzător pentru
planificarea mesajelor. El trimite un Header al frame-ului de mesaj. Slave task care se
găseşte în toate nodurile (inclusiv în master) trimite raspunsul mesajului.
Un frame de mesaj este compus din header care este trimis de master şi
un raspuns care este trimis de master sau de unul din slave. Header-ul este compus din
mai multe câmpuri: SYNCH BREAK, de sincronizare şi ID. Răspunsul este compus din 3
până la 9 octeţi: 2,4 sau 8 octeţi de date şi un câmp CHECKSUM. Octeţii sunt despărţiţi
de un spaţiu între octeţi. Header-ul şi răspunsul sunt despărţite la rândul lor de un
spaţiu.

7
Câmpul de date
Fiecare câmp are lungimea a 10 biţi. Bitul de start marchează începutul câmpului şi
este dominant. El este urmat de 8 biţi de date, LSB fiind primul transmis. Bitul de stop
marchează sfâşitul şi este recessive.

Câmpul header
Pauza de sincronizare
Pentru a identifica clar începutul frame-ului de mesaj primul câmp este acela de
pauză de sincronizare (trimis întotdeauna de master task). Acesta permite slave-urilor
de a se sincroniza. Este compus din 2 părţi (fig. 3.3). Prima este o valoare dominantă de
durată TSyNBRK sau mai mare. A doua este un delimitator de sincronizare recessive cu o
durată minimă de TSZNDEL. Acesta este necesar pentru a permite detecţia bitului de start
al următorului câmp de sincronizare.

Câmpul de sincronizare
Conţine informaţia necesară pentru sincronizare. Este transmis 0x55 care este
caracterizat de 5 fronturi căzătoare pe cei 8 biţi.

Câmpul identificator
Indică conţinutul şi lungimea mesajului. Conţinutul este reprezentat de 6 biţi + 2
biţi de paritate. Biţii ID4 şi ID5 indică numărul câmpurilor de date NDATA
dintr-un mesaj.

Identificatorii 0x3C, 0x3D, 0x3E şi 0x3F împreună cu câmpurile corespunzătoare ,

0x7D, 0xFE şi 0xBF (toate mesaje pe 8 octeţi) sunt rezervate pentru frame-uri de
comandă şi extinse.

Câmpul de răspuns
În funcţie de aplicaţie, câmpul de răspuns (date + sumă de control) pot dar nu
trebuie neapărat procesate dacă informaţia conţinută este irelevantă pentru unitatea de
control. Acesta este cazul în care avem identificator necunoscut sau viciat. În acest caz
calcularea sumei de control poate fi omisă.
Câmpul de date
Conţine 8 biţi de date care să fie transferaţi de un frame de mesaje. Transmisia se face
cu LSB primul.

8
Lungimea frame-urilor de mesaje
Frame-urile de mesaje încep cu un câmp de sincronizare şi se termină cu un
câmp sumă de verificare. Câmpurile de mesaje din frame-ul de mesaje sunt despărţite
de spaţii între octeţi şi un spaţiu de răspuns. Lungimea acestor spaţii nu este definită ci
numai lungimea totală a frame-ului de mesaje este limitată. Lungimea minimă
TFRAME_MIN este timpul minim necesar ca transmiterii unui frame complet (marimea
spaţiilor este 0). Lungimea maximă TFRAME_MAX este timpul maxim permis pentru
transmisia unui frame.

Semnalul WAKE-UP
Poate fi trimis de orice slave task dar numai dacă magistrala este în modul sleep
şi există o cerere internă din partea nodului în aşteptare. Semnalul constă din
caracterele ‚0x80’. Când slave-ul nu este sincronizat cu masterul semnalul poate fi cu
15% mai lung sau mai scurt decât în cazul unui semnal în care avem sincronizare.
Caracterul ‘0x80’ va fi detectat de master ca un octet de date valid, sau ca ‘0xC0’, ’0x80’
sau ’0x00’. Primul câmp este dat de o secvenţă TWUSIG de biţi dominanţi (8 încluzând
bitul de start). A-l doilea câmp este delimitatorul cu o durată de cel puţin 4 biţi TWUDEL
(recessive).
După semnalul de wake-up toate nodurile rulează procedura de start şi aşteaptă
ca master task să trimită câmpul de sincronizare. Dacă acesta nu este detectat în TOBRK
(Time-out after wakeup signal) este transmis un nou semnal de wake-up de către nodul
care cere primul wake-up. Acest lucru se repetă de cel mult 3 ori apoi se suspendă
pentru timpul TT3BRK după care se reia procesul.
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 frame-ului.
Dacă un mesaj este corupt, le este considerat de master şi slave ca netransmis.
Detecţia erorilor
Există 5 tipuri de mesaje de eroare :
Eroare de bit:
Cel care trimite un bit monitorizează şi magistrala. Eroarea apare dacă valoarea bitului
monitorizat este diferită de cea a bitului trimis.
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’.
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.
Eroarea de nerăspundere a slave-ului
Este detectată dacă frame-ul de mesaje nu este transmis complet în lungimea maximă
permisă TFRAME_MAX de nici un slave task în urma transmiterii câmpurilor de
sincronizare şi identificatorului.

9
Eroare de câmp de sincronizare
Se detectează dacă un slave detectează fronturile câmpului de sincronizare înafara
toleranţelor admise.
Eroare de inactivitate pe bus
Se detectează dacă nu s-a primit nici un câmp de sincronizare sau un octet în intervalul
TTIMEOUT de la recepţia ultimului 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.
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 date de pe bus.

Unitatea de control slave

Orice slave va detecta următoarele situaţii de eroare:
- 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 la un
alt slave în intervalul de lungime maximă a frame-ului de mesajeTFRAME_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
este detectat în toleranţa admisă.

Sincronizarea
Dacă nu se specifică viteza este dată de nodul de master.
Câmpul de sincronizare este dat de o secvenţă 0x55. Procedura de sincronizare
se bazează pe măsurarea timpului dintre fronturile căzătoare ale secvenţei.
Se recomandă să se măsoare timpul dintre fronturile căzătoare atât la bitul de
start cât şi la bizul 7, şi să se împartă valoarea obţinută la 8.

10
LINE DRIVER/RECEIVER
Configuraţie
Magistrala este o implementare a standardului ISO 9141. Constă într-o magistrală
LIN bidirecţională care este conectată la driverul/receptorul fiecărui nod, şi este
conectată printr-o rezistenţă şi o diodă la VBAT. Dioda este obligatorie pentru a preveni o
supraîncărcare a ECU (Electronic Control Unit) în cazul pierderii bateriei. Este important
de observat că specificaţiile LIN se referă la tensiunile la conexiunile electrice externe
ECU şi nu la cele interne. Trebuie luate în considerare mai ales tensiunile parazite ale
diodelor polarizate invers atunci când se proiectează un transceiver LIN.

Example LIN communication process (from Vector Informatik GmbH)

11
Example LIN communication process

Example LIN communication process

12
Example LIN communication process

Example LIN communication process

13
Example LIN communication process

Example LIN communication process

14
Example LIN communication process

15