Instrumentul de bord al unui utilaj agricol [629751]

1
FUNDAȚIA PENTRU CULTURĂ ȘI ÎNVĂȚĂMÂNT “IOAN SLAVICI” TIMIȘOARA
UNIVERSITATEA “IOAN SLAVICI” TIMIȘOARA
FACULTATEA DE INGINERIE
DOMENIUL CALCULATOARE ȘI TEHNOLOGIA INFORMAȚIEI
FORMA DE ÎNVĂȚĂMÂNT – ZI

PROIECT DE LICEN ȚĂ

CONDUCĂTOR ȘTIINȚIFIC ,
Sef lucrare dr. Liviu HERMAN
Dr. habil ing. dr. ec. Titus SLAVICI

ABSOLVENT: [anonimizat] 2017 –

2

FUNDAȚIA PENTRU CULTURĂ ȘI ÎNVĂȚĂMÂNT “IOAN SLAVICI” TIMIȘOARA
UNIVERSITATEA “IOAN SLAVICI” TIMIȘOARA
FACULTATEA DE INGINERIE
DOMENI UL CALCULATOARE ȘI TEHNOLOGIA INFORMAȚIEI
FORMA DE ÎNVĂȚĂMÂNT – ZI

INSTRUMENTUL DE BORD AL UNUI
UTILAJ AGRICOL

CONDUCĂTOR ȘTIINȚIFIC ,
Sef lucrare dr. Liviu HERMAN
Dr. habil ing. dr. ec. Titus SLAVICI

ABSOLVENT: [anonimizat] 2017 –

3
UNIVERSITATEA DIN ORADEA
FACULT ATEA de Inginerie Electrică și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informației

TEMA : Instrumentul de bord al unui utilaj agricol

Proiectul de Finalizare a studiilor a student: [anonimizat]: Andronic Doru Alexandru
1). Tema proiectulu i de finalizare a studiilor: Instrumentul de bord al unui utilaj agricol
2). Termenul pentru predarea proiectului de diploma: 14 IUNIE 2017
3). Elemente inițiale pentru elaborarea proiectului de finalizare a studiilor: Lucrarea de față
tratează dezvoltar ea unui instrument de bord pentru un utilaj agricol
4). Conținutul proiectului de finalizare a studiilor :
Capitolul I: Introducerea
Capitolul II: Aspecte teoretice
Capitolul III: Prezentarea proiectului
Capit olul IV: Concluzii si perspective
Capitolul V: Lista tabele si figuri
Capitolul V I: Referinte bibliografice
Capitolul VI I: Anexe

5). Material grafic: scheme, imagini, print screen -uri

6). Locul de documentare pentru elaborarea proiectului de diplomă:
Universitatea Ioan Slavici – Facultatea de Inginerie

7). Data emiterii teme i: noiembrie 2017

Coordonator științific,
Dr. habil ing. dr. ec. Titus Slavic i

4
UNIVERSITATEA DIN OR ADEA

FACULTATEA DE INGINERIE ELECTRICĂ
ȘI TEHNOLOGIA INFORMAȚIEI
Adresa Oradea, Cod 410087, Bihor, Romania, Strada
Univ ersității, nr. 1 ,
Tel/Fax :+40 259/408412, Tel:+40 259/408104; +40 259/408204

REFERAT
PRIVIND PROIECTUL DE DIPLOMĂ
A

ABSOLVENT: [anonimizat] /ABSOLVENT: [anonimizat]: Andronic Doru Alexandru
DOMENIUL Calculatoare și tehnologia informației
SPEC IALIZAREA Calculatoare
PROMOȚIA 2017

1. Titlul proiectului: Instrumentul de bord al unui utilaj agricol

2. Structura proiectului:
Lucrarea este structurată pe șapt e capitole:
Capitolul I: Introducere
Capitolul II: Aspecte teoretice
Capitolul III: Prezentarea proiectului
Capit olul IV: Concluzii si perspective
Capitolul V: Lista tabele si figuri
Capitolul V I: Referinte bibliografice
Capitolul VI I: Anexe

3. Aprecieri asupra conținutului lucrării de LICENȚĂ ( finalizare a studiilor ), mod de
abordare, complexitate, actualitate, deficient:
Lucrarea prezintă o temă de actualitate, prin intermediul căruia studentul prezinta
dezvoltarea unui sistem software pentru un instrument de bord al unui utilaj agricol . Modul
de abordare este origina l, în lucrare fiind explicate toate principiile de funcționare,
componente folosite, precum și programul soft executat. Lucrarea are o complexitate foarte
mare. Nu s -au observat deficiențe în abordare.

4. Aprecieri asupra proiectului (se va menționa: numărul titlurilor bibliografice
consultate, frecvența notelor de subsol, calitatea și diversitatea surselor consultate;
modul în care absolventul a prelucrat informațiile din surse teoretice)
Lucrarea de față tratează dezvoltarea unui sistem software bazat pe un instrument de bord
hardware ce se asambleaza pe diverse utilaje agricole îmbinându -se cunoștințele acumulate pe
durata studiilor universitare cu documentarea propriu -zisă, autorul folosind o listă bibliografică
formată din 14 titluri bibliogra fice de actualitate. Se precizează că o mare parte dintre sursele
bibliografice citate sunt în limba engleză.

5
Documentarea a fost elaborată în cadrul Universității Ioan Slavici. De asemenea pentru
partea practică documentarea a fost realizată pr in studiu individual la locul de muncă, cu mențiunea
că partea aplicativă îi aparține în totalitate autorului.

5. Concluzii (coordonatorul proiectului trebuie să aprecieze valoarea proiectului
întocmit, relevanța studiului întreprins, competențele absolvent ului, rigurozitatea
pe parcursul elaborării proiectului, consecvența și seriozitatea de care a dat dovadă
absolventul pe parcurs)
Lucrarea de față tratează de zvoltarea unui sistem software bazat pe un instrument de bord ..
Doar consultând conținutul lucrări i, se poate deduce că lucrarea acoperă subiectul, iar în
urma studiului efectuat de către autor, se poate spune că acesta a dobândit cunoștințe vaste
în domeniu. Lucrarea este elaborată îngrijit, cu multe exemple, care vin să argumenteze
afirmațiile mențio nate. Având în vedere conținutul temei de proiectare, se poate considera
că autorul a dat dovadă de maximă seriozitate.

6. Redactarea proiectului respectă in totalitate cerințele academice de redactare
(părți, capitole, subcapitole, note de subsol și bibl iografie).

7. Consider că proiectul îndeplinește/ nu îndeplinește condițiile pentru susținere în
sesiunea de Examen de LICENȚĂ ( finalizare a studiilor ) din IULIE 2017 și propun
acordarea notei

Oradea,
Data
14.06.2017 Conducător științific
Dr. habil ing. dr. ec. Titus Slavici

6
Cuprins

1. INTRODUCERE ………………………….. ………………………….. ………………………….. ………………………….. 7
1.1. Contextul problemei ………………………….. ………………………….. ………………………….. ……………….. 7
1.2. Motivația ………………………….. ………………………….. ………………………….. ………………………….. ….. 7
1.3. Descrierea proiectului ………………………….. ………………………….. ………………………….. ……………… 7
2. ASPECTE TEORETICE ………………………….. ………………………….. ………………………….. ……………….. 9
2.1. Prezentare generală a instrumentelor de bord ………………………….. ………………………….. ………….. 9
2.2. Back -End: logi.CAD ………………………….. ………………………….. ………………………….. …………….. 14
2.3. Front -End: grADI ………………………….. ………………………….. ………………………….. …………………. 26
2.4. Simulare și testare: CANoe ………………………….. ………………………….. ………………………….. ……. 31
2.5. Protocol de comunicare: CAN ………………………….. ………………………….. ………………………….. … 34
3. PREZENTAREA PROIECTULUI ………………………….. ………………………….. ………………………….. .. 38
3.1. Prezentarea instrumentului de bord ………………………….. ………………………….. ……………………… 38
3.2. Modul: Symbols ………………………….. ………………………….. ………………………….. …………………… 41
3.3. Modul: SDS ………………………….. ………………………….. ………………………….. …………………………. 42
3.4. Modul: Popups ………………………….. ………………………….. ………………………….. …………………….. 46
3.5. Modul: Trailer brake pressure bar ………………………….. ………………………….. ……………………….. 52
4. CONCLUZII I SI PER SPECTIVE ………………………….. ………………………….. ………………………….. …. 57
5. LISTA TABELE SI FIGURI ………………………….. ………………………….. ………………………….. ………… 58
6. REFERINȚE BIBLIOGRAFICE…………………………………… …………………………. ………. ……………. …60
7. ANEXE ………………………….. ………………………….. ………………………….. ………………………….. ………… 61

7

1. INTRODUCERE
1.1. Contextul problemei
În prezent, în contextul în care tehnologia a început să revoluționeaze fiecare domeniu din
lumea industrială, aflăm că și agricultura a început să sufere modificări, echipamentele agrare
evoluân d cu o rată greu de urmărit.
Ne aflăm într -o perioadă de tranziție în care echipamentele și autovehiculele agrare devin tot
mai performante oferind rezultate mai de calitate, mai cu ușurință, într -un timp cât mai scurt.
Situația prezentată a ajuns să nece site implicare umană foarte puțin sau chiar deloc. Sub această
premisă, autovehiculele cele mai utilizate în agricultură sunt tractoarele, autovehicule care, luându –
le în considerare necesitatea pe teren și atitudinea competitivă a producătorilor, au nevoi e constantă
de implementare de noi tehnologii. Astfel, în domeniul automotive, tractoarele au ajuns să
reprezinte o categorie de sine stătătoare pentru dezvoltatorii de tehnologii.
1.2. Motivația
Considerând că autovehiculele reprezinta unul dintre mi jloacele principale de transport și
unul dintre mijloacele principale pentru muncă care necesită forță majoră, am luat decizia de a mă
angaja și lucra pe proiecte din domeniul automotive. Astfel, confruntat cu alegerea de a lucra la
dezvoltarea modulelor s oftware unui instrument de bord pentru camioane sau pentru tractoare,
decizia a mers către proiectul care promitea să schimbe experiența șoferului din agricultură.
Fiind un proiect diferit și nou pentru echipa de dezvoltare obișnuită cu proiecte pentru
camioane, instrumentul de bord s -a dovedit a fi o alegere interesantă, oferind posibilitatea învățării
și aplicării unor noi tehnologii, scopul final fiind de a revoluționa modul de funcționare al
tractoarelor.
1.3. Descrierea proiectului
Proiectul prez entat în această lucrare se formează din șase module software dezvoltate
pentru un instrument de bord de tractoare. Acest instrument de bord a fost conceput pentru a oferi
experiența cea mai utilă șoferului printr -un design atrăgător, funcții variate, vite ză de procesare și
informații de actualitate și prioritate mare. Dezvoltarea acestui proiect a decurs pe o perioadă de 18
luni, îndeplinind în totalitate cerințele impuse de client, dar nu și fără câteva provocări care, într -un
final, s -a dovedit că au avu t și scop educațional.
Modulele realizate, ca entități individuale, îndeplinesc scopuri diferite pentru zone diferite
ale întregului, fiind module de interfață directă cu șoferul, precum și module care procesează
informații în spate, oferind rezultate rel evante altor module sau altor unități electrice de control.
Cele șase module se denumesc astfel: Symbols, SDS, Popups, Trailer brake pressure bar, Internal
faults și CAN Output.
Modulul de Symbols se reprezintă ca două seturi a câte cinci icoane pe ecran având scopul
de a avertiza și a aduce la cunoștință șoferului despre evenimente care au loc în tractor precum
martorii de bord. Diferența dintre aceste simboluri și martorii de bord este că simbolurile, fiind

8
afișate pe un ecran, pot reprezenta orice fel d e avertizare, neavând restricția spațiului fizic de pe
instrumentul de bord.
Modulul SDS se reprezintă ca enumerare de patru stări a funcționării tractorului. Tractorul
pe care se montează acest instrument de bord are capacitatea de a funcționa automat fă ră a fi
necesar un șofer la volan, șoferul având posibilitatea de a programa pașii pe care trebuie să -i
execute tractorul înainte de a porni. Astfel, modulul SDS afișează pe ecran, în următoarea ordine,
acțiunea precedentă executată, acțiunea curentă, urmă torul pas și al doilea următor pas.
Popups sunt ferestre de informații care apar pe ecran. Acestea sunt alerte care aduc la
cunoștință șoferului ceea ce se întâmplă, indiferent de acțiunile pe care le execută tractorul. Aceste
popup -uri sunt șapte la num ăr, fiecare având propria implementare.
Trailer brake pressure bar este un modul care măsoară presiunea lichidului de frânare din
remorcă. Acesta se reprezintă pe instrumentul de bord ca o bară de zece LED -uri, două roșii, trei
galbene și cinci verzi.
Modulul de Internal faults este un modul care nu se manifestă vizual. Aici se
monitorizează anumite elemente din instrumentul de bord, cum ar fi intrările analogice, ieșirile
digitale, butoanele sau parametrii de EEPROM și oferă informații de diagnoză tot in strumentului de
bord pentru a fi procesate.
CAN Output , cum îi sugerează și numele, trimite informații ca ieșiri către CAN pentru a fi
procesate mai departe. Acest modul ia semnale individuale, le procesează și le grupează sub formă
de mesaje pentru CAN. Ca și internal faults, acest modul nu se manifestă vizual pentru șofer.

9

2. ASPECTE TEORETICE
2.1. Prezentare generală a instrumentelor de bord
Pentru asigurarea siguranței și comfortului în timpul condusului unui autovehicul, o
prezentare clară a inf ormației relevante în orice moment este indispensabilă. Astfel, datorită
conceptului de interfață sofisticată, instrumentele de bord oferă posibilități atractive și bine –
structurate pentru a menține șoferul informat. Un instrument de bord combină diverse i nformații
importante central, direct în raza de viziune a șoferului.
Printre principalele funcționalități ale unui instrument de bord se numără interfața om –
mașină (HMI) care are ca scop afișarea informațiilor către șofer, de a primi intrări de la utilizat or și
a acționa corespunzător sau a trimite comenzi către alte unități electrice de control și de a oferi
servicii de diagnosticare. Alte funcționalități cuprind citirea de intrări analogice/digitale și
transmiterea acestor informațiilor către alte unități electrice de control sau calcularea/stocarea
informațiilor importante despre vehicul: odometru, trip -metru, orele de funcționare ale motorului
etc.

[3] Figura 2.1.1: Instrument de bord clasic

Ca majoritatea proiectelor din domeniul automotive, arhitect ura de sistem a unui instrument
de bord cuprinde trei mari ramuri: Software, Hardware, Mechanical. Mai departe, vom detalia
elemente generale din fiecare ramură specifice instrumentelor de bord.
Comunicarea cu celelalte unități electrice de control din aut ovehicul reprezintă un criteriu
important pentru ca instrumentele de bord să ofere informații relevante și să dea comenzi altor
unități de control. Astfel, în domeniul automotive, comunicarea se obișnuieste a se face prin trei
metode:
 CAN: Permite trei ca nale de comunicare și îndeplinește părți funcționale (recepționează /
trimite informații de la / către alte unități de control din vehicul). De asemenea, permite
programare (scriere de memorie Flash cu Software) și diagnoză (poate primi informații de la
alte unități electrice de control care funcționează în service).
 K-Line: Permite comunicare printr -un singur fir serial și se poate programa și diagnostica.
 LIN: Aceasta este tot o comunicare serială foarte rar folosită.

10

[3] Figura 2.1.2: Vedere explozivă a unui instrument de bord (exploded view)

Arhitectura software a unui instrument de bord a suferit modificări de -a lungul timpului, având
la bază platforme pe diverse tehnologii. Ca platforme, menționăm:
 SYSA: Platformă veche având totul programat în C: drivere low -level + modulele din
aplicație. Refolosirea este slabă, însă poate fi ușor adaptată la cerințele clientului.
 FOX: Platformă mai veche ca SYSA încă folosită pentru proiecte în mentenanță.
 Hybrid (SPEED + C + Mathlab): SPEED este platforma pentr u drivere low -level, iar
modulele aplicației se fac în C și Simulink. Este adesea folosit pentru proiecte făcute la
comandă. Refolosirea este mare și este foarte adaptabilă la cerințele clientului.
 KIBES32 (RT + logi.CAD): Platformă mai nouă pe piață, fiin d folosită de 90% din noile
proiecte. Refolosirea este foarte mare, însă nu este foarte adaptabilă pentru cerințele
clientului.
Indiferent de platformă, există câteva notiuni teoretice care se folosesc în dezvoltarea
aplicației pentru instrumente de bord:
 Histereza;
 Mecanismul de -bounce;
 Algoritmul de damping cu filtru PT1;
 Interpolare liniară;
 Calcule integrale de bază ;
 Stări de sistem finite: stări, tranziții, stimuli.
Scopul histerezei este de a filtra semnale astfel încât ieșirea să reacționeze încet lu ând în
considerare trecutul. Se folosește de un interval de valori definit de doi parametri: TOn și TOff.
Ieșirea își schimbă starea în următoarele cazuri:

11
– Valoarea de intrare este inițial mai mare ca TOn și ajunge mai mică decât TOff;
– Valoarea de int rare este inițial mai mică ca TOff și crește mai mare decât TOn.

[4] Figura 2.1.3: Grafic afișând comportamentul histerezei

Mecanismul de de-bounce obține semnale de ieșire cât mai stabile. Contactul electric la
butoane mecanice adesea face și se într erupe la o singură apăsare de buton. Acest mecanism
înlătură semnalul pulsant rezultat și oferă o tranziție simplă către ieșire.
Scopul algoritmului de damping este de a încetini ritmul în care o masură variază.
Algoritmul se asigură că cu fiecare pas, va loarea calculată pentru ieșire este tot mai aproape de
valoarea de intrare. Damping -ul este controlat de un factor de damping care controlează rata cu care
ieșirea se apropie de valoarea de intrare. Timpul de damping constă în timpul necesar ieșirii pentru
a atinge valoarea intrării, într -o singură variație.
Pentru instrumente de bord se folosește un algoritm de damping cu filtru PT1 astfel:
N = V + ( C – V ) / D
N – Noua valoare a algoritmului după fiecare pas de calcul ;
V – Vechea valoare a algoritmului dupa pasul anterior (intrare în actualul pas) ;
C – Valoarea curentă de intrare ;
D – Factorul de damping.
Interpolarea liniară este o metodă de reprezenta cube folosind polinoame liniare. Adesea
este folosită pentru a umple lipsurile dintr -un tablou.

12

[3]
Figura 2.1.4: Grafice exemplificând comportamentul interpolării liniare

Printre cele mai importante elemente ale unui instrument de bord sunt cele care îi oferă
informația direct șoferului, elementele care apelează la principalele simțuri ale omului și a nume
văzul și auzul. Astfel, vom enunța câteva dintre acestea și anume martorul de bord (telltale),
cadranul (gauge), ecranul (display) și sunetele.
Martorii de bord sunt lămpi indicatoare cu scopul de a informa șoferul că un eveniment s -a
petrecut. Părți le mecanice ale unui martor de bord le reprezintă un LED, o parte conducătoare de
lumină și o mască. Forma martorului de bord este obținută perforând masca în forma dorită, lumina
LED -ului traversând prin perforații. Culorile martorilor de bord variază doa r între: roșu, galben,
amber, verde, alb și albastru, iar acești martori pot fi permanent aprinși sau pot clipi.
Printre posibilele indicații se numără erorile de la unități electrice de control (airbag,
tacograf etc.), nivel mic de lichide (ulei, urea, c ombustibil etc.), uși deschise sau centura nepusă.

[3] Figura 2.1.5: Exemplu de martori de bord
Cadranul este un sub -ansamblu mecanic -electric -programat folosit pentru a afișa o măsură
fizică. Componentele sale mecanice sunt: motorul stepper, indicatoru l și scara. Pentru a evita
mișcări bruște ale indicatorului atunci când valoarea de intrare fluctuează, se folosește algoritmul de
damping. Fiecare indicator are o curbă caracteristică unde intrarea este măsura care trebuie afișată,
iar ieșirea este număru l de pași pe care motorul stepper trebuie să -i facă pentru a afișa masura pe
scară. Aceasta caracteristică nu este liniară, motiv pentru care se folosește interpolarea liniară în
software.

13

[3] Figura 2.1.6: Exemplu de cadran

Sunetele la un instrument d e bord apar folosind un buzzer și boxe. Tipul de fișiere audio
suportate sunt fișierele wav. Frecvența și volumul cu care se emite un sunet pot fi controlate.
Ecranul poate fi de două tipuri: TFT sau segmentat. Ecranul TFT se bucură de o
popularitate mai mare pe instrumentele de bord, el fiind monocrom sau color. Dimensiunile sale pot
fi de la 3 inci până la 12 inci Full TFT.
Figur
a 2.1.7: Exemplu de ecran monocrom, color și full color

Ecranul segmentat din cristal lichid (SLCD) este un dispozitiv elect ronic de afișare folosit
pentru a afișa numere zecimale, fiind o alternativă pentru ecranul dot -matrix. Fiecare număr zecimal
poate fi format din șapte segmente oferind posibilitatea de a afișa informații precum odometrul, ora
și data sau temperatura.

[3] Figura 2.1.8: Notarea și poziționarea fiecărui segment / toate cele 128 de combinații ale unui ecran cu
șapte segmente

14

2.2. Back -End: logi.CAD

Figura 2.2.1: Logo -ul de start al logi.CAD -ului
Logi.CAD este un sistem de programare grafic pentru disp ozitive de automatizare bazate pe
IEC 61131 -3. În logi.CAD, programarea se face cu blocuri funcționale care, relaționând împreună,
oferă rezultatele necesare unui dispozitiv încorporat. Această tehnică se numește programare pe
modele.
Sub această premisă, logi.CAD ne oferă funcții și blocuri funcționale, cum sunt descrise în
standardul de programare PLC IEC 61131 -3 cu care ne putem realiza scopul incluse în bibliotecile
“IEC61131 -3 Standard library” și “IEC61131 -3_(Ext) Standard library”.
1) Se trag element ele pe ecran.

2) Se aranjează elementele.

3) Se fac conexiunile.

4) Rezultatul va fi in var c.

[4] Figura 2.2.2: Adunarea a două numere în logi.CAD

[4] Figura 2.2.3: Structura unui proiect în logi.CAD

15
Logi.CAD, fiind un sistem în care se fac proiecte de o complexitate mare, oferă o clasificare
a varibilelor folosite pentru o folosință cât mai uzuală. Această clasificare împarte variabilele în
cinci categorii, după cum urmează:
 Variabile globale: Sunt variabilele care se pot folosi în orice modul al proiectului.
 Variabile locale: Sunt variabilele care se folosesc doar într -un anumit modul al proiectului.
 Variabile de intrare: Sunt variabilele care servesc pe post de intrări ale modulului,
variabilele care conțin informația care urmează să fie procesată.
 Variabile de ieșire: Sunt variabilele care servesc pe post de ieșiri ale modulului, variabilele
care conțin informația proces ată.
 Variabile externe: Sunt variabilele folosite într -un modul, dar care sunt create în alt loc.
Toate variabilele în trebuie sa fie de un anumit tip de date. Logi.CAD dispune de o varietate
de tipuri de date cu care se pot realiza proiecte pentru orice dispozitiv încorporat:
[4] Tabelul 2.2.1: Tipurile de date posibile în logi.CAD

Definiția unei funcț ii, după IEC 61131 -3:
O funcție se definește ca fiind o unitate de organizare în program care, cand este executată,
oferă ca rezultat exact un singur element de informație (care poate din mai multe valori, ex: un
tablou de elemente sau o structură), și a cărei invocare poate fi folosită în limbaje textuale ca fiind
un operand într -o expresie.
Definiția unui bloc funcțional, dupa IEC 61131 -3:
Un bloc funcțional se definește ca fiind o unitate de organizare în program constând din:
definiția unei structuri de date împărțită în intrare, ieșire și variabile interne și un set de operații
care se vor executa asupra elementelor structurii de date când este invocată o instanță a tipului
blocului funcțional.

16

[4] Figura 2.2.4: Locația bibliotecilor IEC61131 -3 și IEC61131 -3_(Ext) în structura unui proiect
În continuare, vom enumera toate categoriile de funcții și blocuri funcționale cuprinse în
cele două biblioteci și vom detalia câte un exemplu din fiecare categorie :
 Funcții binare : Aceste funcții manipuleză vari abile la nivel de bit, cum ar fi șiftările binare
sau operațiile ȘI, SAU, SAU EXCLUSIV, NEGAȚIE etc.
Exemplu : ROR
Tabelul 2.2.2: Intrările și ieșirile blocului ROR
Identificator Tip de date
Intrări IN ANY_BIT
N INT
Ieșiri OUT1 ANY_BIT

Valoarea num erică conectată la intrarea IN este rotită binar spre dreapta de numărul de ori
de la intrarea N. Această rotație face ca biții șiftați afară de la capătul din dreapta să apară ca biți noi
în capătul din stânga.
 Funcții de comparare : Aceste funcții realize ază comparări de bază între variabile sau
valori numerice.
Exemplu: GE
Tabelul 2.2.3: Intrările și ieșirile blocului GE
Identificator Tip de date
Intrări IN1 ANY_ELEMENTARY
IN2 ANY_ELEMENTARY

17
(poate avea mai
mult de doua
intrări)
Ieșiri OUT1 BOOL

Acest bloc scoate la ieșirea OUT1 valoarea booleană 1 dacă condiția IN1 >= IN2 și IN2 >=
IN3 … și INn -1 >= INn este îndeplinită. În caz contrar, OUT1 va avea valoarea booleană 0.

 Blocuri bistabile : Aceste blocuri funcționale mențin un semnal de tip boolea n stabil până
sunt resetate de o altă acțiune.
Exemplu : RS
Tabelul 2.2.4: Intrările și ieșirile blocului RS
Identificator Tip de date
Intrări S BOOL
R1 BOOL
Ieșiri Q1 BOOL

În acest bloc, ieșirea Q1 este data de intrarea S, însă Q1 poate fi resetat de intrarea R1.
Reset -ul R1 este dominant.

[5] Figura 2.2.5: Funcționalitatea blocului RS

 Funcții și blocuri funcționale de conversie : Acest grup cuprinde funcții și blocuri pentru a
converti orice tip de date în orice alt tip de date, dar această conve rsie poate avea loc doar
dacă tipul de date o permite.
Exemplu : ATOREAL
Tabelul 2.2.5: Intrările și ieșirile blocului ATOREAL
Identificator Tip de date
Intrări IN1 ANY
Ieșiri OUT1 REAL

18
Valoarea conectată la intrare este convertită la tipul de date R EAL. Conectând o linie de tip
codat, se determină tipul de date care va fi convertit.
 Blocuri funcționale de numărare: Aceste blocuri realizează diverse contorizări.
Exemplu: CTUD
Tabelul 2.2.6: Intrările și ieșirile blocului CTUD
Identificator Tip de date
Intrări >CU BOOL
>CD BOOL
R BOOL
LD BOOL
PV INT
Ieșiri QU BOOL
QD BOOL
CV INT

Acesta este un UP -DOWN -COUNTER. Valoarea contorului CV poate fi resetată la 0 de
către intrarea R. Valoarea conntorului CV poate lua valoarea intrării PV da că intrarea booleană LD
primește valoarea 1. La fiecare trecere de la 0 la 1 a intrării booleane CU se incrementează valoarea
contorului cu 1, iar la fiecare trecere de la 0 la 1 a intrării booleane CD se decrementează valoarea
contorului cu 1. Ieșirea boo leană QU ia valoarea 1 când valoarea contorului CV atinge sau
depășește valoarea intrării PV, iar ieșirea booleană QD ia valoarea 1 când valoarea contorului CV
scade sub valoarea intrării PV sau ajunge la 0. Valoarea curentă a contorului poate fi oricând c itită
de la ieșirea CV.
Implementarea [5] blocului CTUD folosind Structure Text (ST):
IF R THEN CV := 0;
ELSIF LD THEN CV := PV;
ELSIF CU AND (CV < PVmax)
THEN CV := CV+1;
ELSIF CD AND (CV > PVmin)
THEN CV := CV -1;
END_IF;
QU := (CV >= PV);
QD := (CV <= 0);
 Blocuri funcționale EDGE: Aceste blocuri detectează trecerea dintr -o stare în alta a
intrărilor booleane.
Exemplu: R_TRIG

19
Tabelul 2.2.7: Intrările și ieșirile blocului R_TRIG
Identificator Tip de date
Intrări CLK BOOL
Ieșiri Q BOOL

Acest bloc detectează valori booleane în creștere. Dacă se detectează o urcare pozitivă la
intrarea booleană CLK, atunci ieșirea Q va primi valoarea 1 pentru un ciclu.
Implementarea [5] blocului R_TRIG folosind Structure Text (ST):
FUNCTION_BLOCK R_TRIG
VAR_INPUT CLK: BOOL; END_VAR
VAR_OUTPUT Q: BOOL; END_VAR
VAR M: BOOL := 0; END_VAR
Q := CLK AND NOT M;
M := CLK;
END_FUNCTION_BLOCK
 Funcții numerice: Acest grup conține funcții cu variabile numerice precum și funcții
aritm etice.
Exemplu: SIN
Tabelul 2.2.8: Intrările și ieșirile blocului SIN
Identificator Tip de date
Intrări IN1 ANY_REAL
Ieșiri OUT1 ANY_REAL

Funcția trigonometrică SIN primește ca intrare o valoare reală IN1 și calculează valoarea
sinusoidală în radiani , care va fi dată spre ieșirea OUT1.

 Funcții de selectare: Aceste funcții servesc spre a selcta o variabilă sau o valoare dintr -un
set de variabile sau valori. În funcție de criteriul conectat sau de funcția folosită, o selecție
diferită se realizează.
Exemplu: SEL
Tabelul 2.2.9: Intrările și ieșirile blocului SEL
Identificator Tip de date

20
Intrări G BOOL
IN0 ANY
IN1 ANY
Ieșiri OUT1 ANY

Oricare dintre cele două intrări, IN0 sau IN1, poate fi transmisă către ieșire. În funcția de
starea intrării b ooleane G, daca G = 0, atunci IN0 va fi transmis către ieșire, altfel, dacă G = 1,
atunci IN1 va fi transmis către ieșire.

 Funcții pentru șiruri de caractere: Aceste funcții se folosec pentru a manipula șiruri de
caractere. Printre altele, șirurile de car actere pot fi comparate, combinate, șterse sau găsite
incluse în alte șiruri.

Exemplu: CONCAT
Tabelul 2.2.10: Intrările și ieșirile blocului CONCAT
Identificator Tip de date
Intrări IN1 STRING
IN2
(pot fi folosite
mai mult de două
șiruri de
caractere ) STRING
Ieșiri OUT1 STRING

Toate șirurile de caractere de la intrări sunt combinate într -un singur șir de caractere care va
fi dat spre ieșire. Șirul rezultat poate avea un maxim de 127 de caractere.

 Funcții de timp: Acest grup oferă funcții numerice de calcul a tipului de date pentru timp și
funcții de combinare a timpului și dății într -o nouă valoare de tipul de date
DATE_AND_TIME.
Exemplu: CONCAT_D
Tabelul 2.2.11: Intrările și ieșirile blocului CONCAT_D
Identificator Tip de date
Intrări IN1 DATE
IN2 TIME_OF_DAY

21
Ieșiri OUT1 DATE_AND_TIME

O dată de la intrarea IN1 și un timp al zilei de la intrarea IN2 sunt combinate într -o dată cu
timp al zilei care se transmit către ieșirea OUT1.

 Blocuri funcționale de tip timer: Acest grup oferă diverse ti mer-e, cum ar fi întârziere
pentru activare, întârziere pentru dezactivare sau ceasuri în timp real.
Exemplu: TON
Tabelul 2.2.12: Intrările și ieșirile blocului TON
Identificator Tip de date
Intrări IN BOOL
PT TIME
Ieșiri Q BOOL
ET TIME

Acesta es te un timer de activare care așteaptă la intrare un EDGE înainte de a începe.
Perioada de întârziere a timer -ului se introduce la intrarea PT. Când intrarea booleană IN primește
valoarea 1, timer -ul pornește și, după ce perioada de întârziere trece, ieșire a booleană Q trece pe 1.
Ieșirea ET numără timpul, începând cu trecerea pe 1 a intrării IN, până ajunge la valoarea din PT,
moment în care se activează ieșirea Q. În oricare moment se poate citi timpul scurs de la ieșirea ET.

[5] Figura 2.2.6: Comportame ntul timer -ului TON

22

Logi.CAD oferă posibilitatea testării logicii create printr -o simulare offline sau o simulare
online. Simularea offline are loc virtual, logi.CAD simulând strict logica creată oferind o viziune
asupra comportamentului codului scris de către programator. Simularea online are loc cu
dispozitivul încorporat, pe care se dorește descărcarea ulterioară a logicii create, conectat. Astfel,
programatorul are ocazia sa urmărească cum se manifestă codul scris de el direct pe dispozitiv.
În timpul simulării offline sau online, logi.CAD oferă posibilitatea folosirii de force -marker –
e, prin care se pot forța conexiuni. Astfel, programatorul poate modifica valoarea variabilelor pentru
a putea testa diverse situații în timpul simulării.

Tabelul 2.2.13 : Intrările și ieșirile unui force marker
Identificator Tip de date
Intrări IN ANY
Ieșiri OUT ANY

[5] Figura 2.2.7: Exemplu de simulare folosind force markere

Tipul de date determină culoarea cu care liniile de conexiune, câmpurile de valori și
câmpurile de connectori sunt afișate pe ecran.
Un caz special este culoarea gri deschis rezervată pentru elementele fără un tip de date
codificat:

În caz de eroare la o conexiune, obiectele în cauză sunt evidențiate în editor prin
, iar
aparența lor de pe ecran a câmpurilor conectate și a liniilor de conexiune se modifică astfel:

23

Alături de blocurile standard, programatorul își mai poate crea propriile blocuri în editorul
ST, folosind limbajul de programare IEC “structured text” (ST). Editorul ST și editorul FBD sunt
componentele de bază ale logi.CAD -ului. Acestea sunt mediile în care programatorul
implementează funcționalitatea de control.
Editorul ST permite dezvoltarea, testarea și documentarea proiectelor în limbaj ST, conform
cu IEC 61131 -3. Fol osind ST, programatorul poate crea funcții (ST), blocuri funcționale (ST) sau
programe (ST).

[5] Figura 2.2. 8: Editorul ST

 Statement editor: Aici se introduc expresiile și instrucțiunile care formează programul ST.
 Interface declaration editor (doar cu blocuri funcționale și funcții): În acest editor se
definește aparența grafică a blocului/funcției.
 Variable declaration editor: Aici se crează variabilele interne și de interfață cu exteriorul.
De asemenea, trebuiesc declarate și blocurile funcționale îna inte de a fi folosite în statement
editor.

24

Instrucțiunile limbajului ST sunt asemănătoare limnajelor de programare uzuale, fapt care face
munca oricărui programator amator foarte ușoară.
[5] Tabelul 2.2.14: Instrucțiunile limbajului ST alături de un exemplu fiecare

25

[5] Figura 2.2.9 : Exemple de blocuri funcționale create în ST denumite INTEGRAL și DERIVATIVE

Blocurile din Figura 2.2.10 pot fi folosite mai departe în componența altor blocuri. În
Figura 2.2.11 , s-au creat două variabile de tipu l celor două blocuri, INTEGRAL și DERIVATIVE,
create anterior, și au fost folosite în componența blocului PID. Funcțiile standard IEC se pot folosi
imediat fără a mai fi necesară o declarare în secțiunea variabilelor.

[5] Figura 2.2.1 0: Blocul PID creat în ST

26

2.3. Front -End: grADI

Figura 2.3.1: Logo -ul de start al aplicației grADI

Gradi (Graphical Application & Interface Design) este un instrument software dezvoltat de
Continental Automotive. Cu grADI se pot compune și implementa texte și obiecte graf ice pentru a
fi afișate pe ecranul unui dispozitiv încorporat.
Pentru a face acest lucru, grADI ne ajută în :
 Gestionarea resurselor de baz ă (șiruri de caractere, imagini bitmap, fonturi);
 Compunerea de obiecte Layer, Page, Text si Pixmap ;
 Aranjarea a astfe l de obiecte pe ecran și generarea fișierelor de date pentru sistemul țintă și
simularea LCD ;
 Generarea blocurilor funcționale care pot fi folosite pentru a construi aplicația dorită.
grADI este dezvoltat pe baza aplicației de design 3D CINEMA 4D . Nu este o aplicație de
sine stătătoare, ci un set de plug -in-uri, care extind functionalitatea aplicației CINEMA 4D. Așadar,
pentru a lucra cu grADI, este nevoie întâi de o instalare CINEMA 4D, însă nu sunt necesare
cunoștințe de lucru in CINEMA 4D pentru a putea lucra in grADI. Ceea ce grADI aduce în plus,
față de CINEMA 4D, sunt funcțiile specifice pentru a compune și implementa obiecte widget pentru
ecranul unui dispozitiv încorporat.
Dezvoltarea cu success a unei aplica ții in grADI trece prin trei faze mari :
1. Importarea fișierelor sursă;
2. Structurarea și atribuirea ;
3. Exportarea modelului grADI.

27

[6] Figura 2.3.2: Fluxul de lucru a unui proiect în grADI

Într-un proiect grADI se lucrează cu două tipuri de componente:
 Resurse: Sunt componentele de bază din grADI. Nu au o referință directă la ecran cum ar fi o
poziție, dar oferă o baza pentru a compune obiecte care pot fi afișate pe ecran.
 Obiecte: Sunt folosite pentru a poziționa resursele și a le grupa logic. Suma tuturor obiectelor
descrie prezentarea de p e ecran. Obiectele pot fi compuse din resurse sau alte obiecte.
Resursele sunt importate și gestionate în Managerul de Resurse. Ele nu sunt modificate în
grADI, ci cu programe externe.
[6] Tabelul 2.3.1: Tipuri de resurse
Resursă Descriere Simbol
Pixmap Reprezint ă imagini în grADI. De exemplu, sunt folosite
pentru icoanele de avertizare sau instructiunile de navigare.

Raster font Reprezint ă seturi de caractere în grADI. Fonturile raster
conțin codurile caracterelor și imaginile pixmap pentru
fiecare car acter.

String Reprezint ă secvențe de caractere în grADI fără un font sau
poziție, datele de text pur. Resursa string conține un string
pentru fiecare limbă.

Obiectele sunt gestionate în Layout Manager. Spre deosebire de resurse, există mult mai
multe tipuri de obiecte, ele fiind împărțite în trei clase:
 Obiecte de bază: Sunt folosite pentru a aranja straturile, un strat video, pagini și containere de
pagini pe ecran.

28
 Obiecte widget: Sunt folosite pentru a aranja resurse și alte obiecte widget pe un obiect pagină.
Unele obiecte widget sunt folosite pentru a realiza un obiect widget mai complex.
 Obiecte speciale: Sunt create automat de către obiecte widget pentru a realiza niște obiecte widget
mai complexe.

[6] Figura 2.3.3: Ierarhia obiectelor de b ază și a obiectelor widget în grADI

Interfața implicită a mediului grADI a fost făcută pentru a facilita accesul la orice comandă
cât mai ușor și pentru a fi cât mai sugestivă pentru un programator amator. Astfel, avem prezentată
în Figura 2.3.4 un exempl u de interfață a mediului cu fiecare componentă numerotată și explicată.

29

[6] Figura 2.3.4: Interfața mediului de dezvoltare grADI

Componentele din figură au următoarea semnificație:
1 – Meniu principal: reprezintă accesul utilizatorului către toate fu ncționalitățile oferite de grADI și
având aceasta în considerare, a fost necesară o structurare cât mai accesibilă.
2 – Bara de simboluri: reprezintă acces rapid la anumite comenzi.
3 – Managerul de resurse: reprezintă accesul la resursele de pixmap -uri, f ont-uri și string -uri care
vor fi folosite în proiect.
4 – Bara de status: aici se afișează detalii despre componentă.
5 – Vedere constructivă: aici se aranjează elementele ce vor compune proiectul.
6 – Managerul de straturi: reprezintă accesul la obiectel e folosite în proiect.
7 – Previzualizare resursă: aici se poate vedea componența resursei selectate.
8 – Managerul de attribute: aici se pot seta proprietățile fiecărui obiect selectat.

30
Având ca premise explicațile anterioare, putem enumera pașii dezvolt ării unui proiect în
grADI mai detaliat în următorul tabel.

[6] Tabelul 2.3.2: Pașii dezvoltării unui proiect în grADI
Pasul Acțiunea
1 Definirea unui nou proiect. Definirea datelor proiectului în conformitate cu cerințele în
dialogul New Project.
2 Definirea setărilor proiectului în conformitate cu cerințele în dialgul Project Settings.
3 Importarea fișierelor resursă. Dacă se dorește folosirea imaginilor bitmap în proiect,
trebuiesc importate resurse de icone. Daca se dorește folosirea string -urilor, trebuiesc
importate resurse string si resurse de font.
4 Structurarea resurselor importate în conformitate cu cerințele.
5 Definirea secvențelor de Blending și Fading, dacă sunt necesare în proiect.
6 Definirea frecvențelor de blinking în conformitate c u cerințele.
7 Definirea obiectelor de bază. Trebuie luată în considerare ierarhia straturilor. Se atribuie
obiectelor de bază setările proiectului și datele de Blending și Fading.
8 Definirea datelor de configurație generală.
9 Definirea obiectelor wid get sau generarea lor din resurse în conformitate cu cerințele.
Trebuie luată în considerare ierarhia straturilor.
10 Aranjarea obiectelor de bază și a obiectelor widget pe ecran în conformitate cu cerințele.
11 Definirea datelor de configurare a generăr ii codului în conformitate cu cerințele în
Managerul de configurare a generării codului.
12 Exportarea proiectului grADI.

31

2.4. Simulare și testare: CANoe

Figura 2.4.1: Logo -ul de start al aplicației CANoe

CANoe este o aplicație software direcționa tă spre dezvoltarea, testarea și analiza de rețele
întregi de ECU -uri sau ECU -uri individuale dezvoltată de către Vector. Ajută pe durata întregului
process de dezvoltare, de la plănuirea inițială până la lansarea de întregi sisteme distribuite de ECU –
uri.
O simulare include toate componentele software care pot apărea într -o unitate de cotrol reală
și comportamentul de bază al transmisiei în unitatea de control. Astfel, unitatea de control este
simulată în întregime.
CANoe suportă cele trei faze ale dezvo ltării, de la simularea unei întregi rețele și până la
analiza unei rețele reale. Asta presupune ca toate unitățile de control din rețea să fie integrate ca
noduri de rețea în setarea simulării. Canalul de comunicare este definit prin baze de date integrat e
(DBC, XML etc.).
Baza unei simulări a unei unități de control este simularea întregului comportament de
transmisie (timpii de transmisie și condițiile de transmisie pentru fiecare mesaj). Diverse metode
sunt posibile pentru realizarea unor astfel de sim ulări, printre care și modelele de transmisie
specifice OEM. Întregul scop al aplicației este să evalueze, proceseze și să seteze valorile
semnalelor și a variabilelor. Cu toate acestea, o simulare a tuturor funcțiilor nu este întotdeauna
necesară.
Accesu l semnalelor se poate realiza cu un generator de semnale. Astfel, un server de
semnale oferă acces ușor la semnale. Toate semnalele definite pentru comunicare sunt disponibile
pe acest server. Pe lânga aceasta, generatorul de semnale poate fi folosit să sc himbe variabile de
sistem și mediu. Primirea unui mesaj este mereu posibilă, însă reacția la un anumit mesaj trebuie
programată (în CAPL cu on message ).

32

[7] Figura 2.4.2: Unitate de control simulată în CANoe

Stimularea prin schimbarea valorilor semnale lor și a variabilelor
Sunt diverse metode prin care CANoe poate seta valori semnalelor și variabilelor.
 Programe: Programe CAPL și .NET pot fi folosite pentru a seta valori semnalelor și
variabilelor. Pe lângă programare, CANoe oferă și pași pre definiți de programare pentru
crearea ușoară de secvențe de comndă în Managerul de secvențe vizual a configurației.
 Modele: Programarea poate fi modelată grafic în Matlab și integrată în CANoe ca un model
compatibil.
 Interfețe cu utilizatorul configurabile : CANoe oferă o interfață cu utilizatorul
configurabilă care este folosită pentru a seta valori pentru semnale și variabile și pentru a
genera modele de valori. Pe lângă această interfață predefinită, utilizatorul își poate genera
propriile interfețe, numi te panouri.
 Module de testare: Modulele de testare (CAPL, .NET, XML) permit diverse test case -uri
pentru o unitate de control să fie executate unul după altul. În funcție de scenariul testului,
sunt posibile și schimbări de valori.
Simularea compotamentulu i de transmisie
În CANoe, există diverse posibilități pentru a simula comportamentul de transmisie al unei
unități de control:
Cu sau fără baza de date
 Programe: Programe CAPL și .NET pot fi folosite pentru a reproduce orice comportament
de transmisie a m esajelor. Prin această procedură, fiecare pas trebuie programt manual și
dacă apare o schimbare în baza de date, toate programele trebuie adaptate individual.
 Interfețe cu utilizatorul configurabile: CANoe oferă interfețe cu utilizatorul interactive
care p ermit mesajelor să fie selectate și transmise rapid și cu ușurință.
 Module de testare
 Redarea datelor înregistrate: Un trafic de date poate fi generat redând o înregistrare dintr –
un fișier log.

33
Cu baza de date
 Mijloace de transmisie automată: Comportamentu l de transmisie a mesajelor și
semnalelor este descris într -o baza de date integrată. Timpii și asocierea semnalelor la
mesaje depind de sistemul de comunicare.
Având ca premise toate cele explicate anterior, în figura următoare, avem prezentată fereastra cu
setările de bază a unei simulări, fiecare componentă fiind explicată după cum urmează:
 Bloc generator (G): Acest bloc poate genera mesaje de date, remote sau erori. Activarea sa
poate fi realizată prin apăsare de buton sau la sosirea unui alt mesaj. Est e capabil sa
interacționeze cu baza de date CAN.
 Bloc generator interactiv (IG): Ca și G, acest bloc poate genera mesaje de date, remote sau
erori și poate fi activat prin apăsare de buton sau la sosirea unui alt mesaj. Ceea ce -l face
interactiv este faptu l că poate manipula și afișa semnalele în timp ce se execută simulrea.
 Nod de rețea (ECU): Acest bloc poate fi programat în limbaj CAPL pentru a putea
interacționa cu canalul de comunicare CAN. De asemenea, poate interacționa și cu baza de
date CAN.
 Bloc d e repetare (Replay): Acest bloc poate transmite către ieșire mesaje stocate într -un
fișier log.
 Canalul CAN de comunicare simulat (Bus): Poate fi schimbat în modul timp real.
 În dreapta imaginii se află baza de date care conține mesajele cu care lucrează s imularea.

[7] Figura 2.4.3: Setările de bază ale unei simulări în CANoe

34

2.5. Protocol de comunicare: CAN
Pentru acest proiect s -a folosit, ca și protocol de comunicare, CAN. Controller Area
Network (CAN) este un protocol de comunicare standard pentru aplicații automotive, dezvoltat în
1980 de către Robert Bosch GmbH, pentru conectarea unităților electrice de control (ECU).
Capacitățile CAN -ului includ transmisie asincronă, conexiune bidirecțională, liniară și cu
protocol (adresă + date + verificare da te + informații semnal). De asemenea, CAN -ul permite
conexiune multi -master, ceea ce înseamnă că orice nod poate porni comunicarea.
Pentru comunicarea între unitățile electrice de control, în domeniul Automotive, trebuiesc
luate în considerare costurile, necesitatea transmisiei într -o zonă cu zgomot de frecvență,
comportamentul în timp real, manevrabilitatea și standardizarea. Aici intervine CAN -ul, care
reprezintă cea mai bună soluție, îndeplinind toate condițile.

[8] Figura 2.5.1: Sistem de unități ele ctrice de control dintr -un autovehicul fără CAN
Avantajele folosirii protocolului CAN are diverse avantaje, cum ar fi numărul mic de fire și
conexiuni, greutatea scăzută, spațiul ocupat mic. Folosind CAN scade și posibilitatea interferențelor
electromagne tice, ni se permit adăugarea de noi noduri cu ușurință, costuri de asamblare mici și mai
multă siguranță la transmisie. De asemenea, CAN -ul este un protocol care respectă anumite
standarde, cum ar fi ISO 11898, 11519, 11992, SAE j1939 etc.

35

[8] Figura 2.5 .2: Sistem de unități electrice de control dintr -un autovehicul cu CAN

Pentru acest proiect s -a folosit soluția oferită de către Vector de subsistem CAN:

[8] Figura 2.5.3: Subsistem CAN creat de Vector

 Driver CAN: Codul generic de driver CAN este inde pendent față de Aplicație. Acesta are
scopul de a inițializa controller -ul CAN, de a transmite un singur mesaj CAN, de a primi un

36
singur mesaj CAN, de a manevra starea de Bus -Off (un controller CAN este în stare de Bus –
Off dacă nu participă în traficul de comunicare) și de a manevra modul de sleep.
 Administrarea rețelei (NM): Aici se asigură tranziția la modul de sleep a tuturor unităților
electrice de control (ECU), se determină și monitorizează configurația rețelei și se obțin
informațiile unui nod sau a întregii rețele.
 Protocolul de transport (TP): Dacă lungimea datelor depășește 8 bytes, este nevoie de un
protocol de transport. În acest caz, transmițătorul trebuie să dividă datele într -un număr de
mesaje CAN cu același identificator. De asemenea, este n evoie de informații suplimentare
pentru ca receptorul să pună la loc datele.
 Stratul de interacțiune (IL): Acesta reprezintă interfața dintre aplicație și date. Aici se
asigură consistența oricărei informații transmise sau recepționate pentru a nu fi nevoi e de
verificări auxiliare în aplicație.
Standardul j1939
Transmisia datelor urmăresc standardul j1939. Acest standard are ca și caracteristici pentru
mesaje un identificator de 29 de biți, transmisie peer -to-peer și broadcast, protocoale de transport
până la 1785 de bytes, administrarea rețelelor și definirea grupurilor de parametri.
Interpretarea identificatorului unui mesaj este după cum urmează (PDU = Protocolul unității
de date):

[8] Figura 2.5.4: Structura pe biți a unui identificator dintr -un mesaj transmis pe CAN

Grupurile de parametri combină semnale similare sau asociate. Conform SAE J1939 -71,
grupurile de parametrii sunt definite cu semnalele pe care le conțin. Fiecare grup de parametri este
adresat unic printr -un număr, Număr Grup de Parametri.
PGN = DP + PDUF + PDUS [8]
Pentru grupuri de parametri trimise către toate unitățile de control (broadcast), se alocă
PGN -uri globale. Aici, toți cei 16 biți sunt folosiți, iar valoarea primilor 8 biți (PDU format) trebuie
să fie mai mare dec ât 239 (0xF0).
Pentru grupurile de parametri care sunt transmise către dispozitive particulare (peer -to-peer)
se alocă PGN -uri specifice. Aici, doar primii 8 biți (PDU format) sunt valizi și trebuie să fie mai
mare ca valoare decât 240 (0xF1). Ultimii 8 b iți (PDU specific) au mereu valoarea 0.
Într-o rețea j1939, fiecare dispozitiv are o adresă unică. Fiecare mesaj transmis de către un
dispozitiv conține această adresă de sursă. Sunt 255 de adrese posibile:

37
– 0…253 Adrese valide de unități electrice de co ntrol ;
– 254 Zero;
– 255 Global.
Pentru transmisii broadcast este folosit protocolul BAM (Broadcast Announce Message).
Aici, după ce s -a transmis mesajul BAM, transmițătorul trimite restul informațiilor sub formă de
alte mesaje la un interval minim de 50 ms.
– Primul mesaj: BAM;

[8] Figura 2.5.5: Stuctura binară a mesajului BAM

– Următoarele mesaje până la terminarea datelor: DT (Data Transfer) ;

[8] Figura 2.5.6: Stuctura binară a mesajului DT

– Ultimul mesaj este un DT cu biții rămași setați pe 1.

[8] Figura 2.5.7: Stuctura binară a ultimului mesaj DT

38

3. PREZENTAREA PROIECTULUI
3.1. Prezentarea instrumentului de bord
Instrumentul de bord pentru care s -au realizat modulele software este unul de tractoare high –
level, având ca interfață 4 cadrane de indic are, 26 de martori de bord și un ecran full -color de 5 inci.

[2] Figura 3.1.1: Vedere din față și din spate a instrumentului de bord pentru tractoare

Întregul proces de dezvoltare al acestui instrument de bord s -a întins până la 18 luni, timp în
care a trecut prin toate fazele unui proces de dezvoltare (analiză, implementare, testare etc.).

[2] Figura 3.1.2: Vedere explozivă a instrumentului de bord pentru tractoare

39
Comunicarea dintre instrumentul de bord (IC) și alte unități electrice de control (E CU) se
reazlizează prin mesaje periodice de CAN și un protocol de comunicare custom care respectă
standardul j1939. Acesta se numește protocolul multipachet (MPP).

[10] Figura 3.1.3: Schimb de mesaje prin MPP dintre ECU și IC

Ecranul instrumentului de bord este un TFT full -color de 5 inci care permite afișarea
elementelor grafice de calitate mare, având un număr mare de culori. Toate modulele software care
compun interfața cu șoferul a ecranului au fost concepute cu dimensiuni de afișare prestabilite, f iind
de cinci feluri, în ordinea dimensiunii: jumătate de rând, un rând, două rânduri, patru rânduri sau o
pagină întreagă.
Ecranul ar putea afișa în total 9 module de dimensiune un rând. Ceea ce face diferit acest
instrument de bord este că un modul, ind iferent de dimensiune, ar putea fi așezat la orice poziție de
pe ecran și ar putea apărea și in mai mult de un exemplar.

[1] Figura 3.1.4: Dimensiunile modulelor pe ecran (stânga) și un exemplu de configurație de module pe
ecran (dreapta)

40
Instrumentu l de bord pentru tractoare nu are butoane integrate în el. Navigarea pe care o va
permite prin paginile și setările sale se va realiza prin patru butoane care se vor afla în bordul
tractorului pe o altă unitate de control. Folosindu -ne de aceste butoane, v om putea naviga în oricare
din cele 5 pagini ale meniului: setările, alarme, distributoarele, monitorul de performanță și pagina
principală.

[1] Figura 3.1.5: Pagina de meniu
 Pagina principală este locul unde vor fi afișate modulele de dimensiuni mai mic i decât o
pagină. Această pagină va fi constant folosită de către șofer, fiind pagina care îi va oferi
toate informațiile din tractor.
 Pagina de setări este pagina care va afișa și va oferi șoferului posibilitatea de a aduce
modificări asupra modulelor car e să-i fie afișate pe pagina principală sau asupra
parametrilor care influențează funcționarea tractorului.
 Pagina de alarme afișează o listă cu toate unitățile electrice de control alături de informații
despre fiecare (versiunea de software, erori, dezvol tator etc.).
 Pagina monitorului de performanță oferă posibilitatea setării indicilor de performanță ai
tractorului, precum și vizualizarea actualei configurații.
 Pagina de distributoare arată informații despre fiecare valvă electrică din tractor.

41

3.2. Mo dul: Symbols
Acest modul are scopul de a afișa pe ecran diverse alerte, informații și avertizări sub formă
de două seturi a câte 5 icoane. Fiecare set se afișează pe un singur rând din ecran și există
posibilitatea de a fi afișat un set, ambele seturi sau nici unul. În principiu, acest modul indeplinește
funcția martorilor de bord, cu excepția că pe ecran poate fi afișată orice alertă disponibilă, neavând
restricția spațiului fizic cu care se confruntă martorii de bord, icoanele venind dintr -o bază de date
cu peste 500 de icoane.
În figura 3.2.2 avem prezentată logica sub care funcționează modulul Symbols . Pentru
început, se testează dacă mesajul TP_CM_BAM_HLHP2 se transmite corect, fără erori (0 – fără
erori). În caz de eroare, icoanele nu se vor mai afi șa pe ecran, iar modulul va fi gol.

[1] Figura 3.2.1: Modulul de symbols afișat pe ecran fără eroare (stânga) și cu eroare (dreapta)
Apoi, pentru fiecare icoană afișată, se testează dacă mesajul este în eroare, caz în care se
trimite valoarea 0 spre i eșire (0 – icoană goală), altfel se va trimite indexul conținut în semnalul de
MPP Simbol X. Indiferent de valoarea trimisă, se atribuie un offset de 1000 pentru icoanele mici,
care se vor afișa pe ecran.

Figura 3.2.2: Code snippet cu logica modulului Sym bols

42
3.3. Modul: SDS
Acest modul afișează starea tractorului în modul SDS din următoarele faze: pasul precedent,
pasul curent, pasul următor și al doilea pas următor. Când tractorul se află în mod SDS, el este în
modul automat, ceea ce înseamnă că acesta va executa pașii programați de dinainte de către șofer,
fără a mai fi nevoie de prezența sa la volan.
Este un modul mai complex și de aceea codul său a fost împărțit pe secțiuni și explicat în
pași pentru o mai bună înțelegere de către cititor. Modulul SD S poate fi afișat pe ecran în două
moduri: pe un rând sau pe două rânduri, motiv care a dus și la particularități ale codului, pe lângă
secțiunile comune.
În figura următoare se încadrează prima parte a modulului. Se convertește semnalul de
status al SDS -ului din formatul unsigned int în formatul byte și se stochează primii 2 biți ai săi în
conectorul StatusSDS . După care se procesează cei 2 biți stocați cu ajutorul a două blocuri tip
multiplexor pentru a decide indexul icoanei de status (play, record, not active) care va fi afișat pe
ecran în modulul pe un rând și două rânduri. Acest index se stochează în semnalele de ieșire
SDS_ModeBig și SDS_ModeSmall .
Pasul următor este de a verifica unul din semnalele de ieșire care conțin indexul modului (s –
a ales SDS_ModeBig ) dacă are valoarea 0 (not active) pentru a seta semnalul de vizibilitate al
icoanei care afișează modul pe ecran SDS_ModeVizibilitate .
Folosind același semnal de status al SDS -ului, SDS_StatusParametru , se convertește din
nou în fomatul byte, se shiftează cu 2 biți, respectiv 4 biți, apoi se verifică valoarea zecimală a
primilor 2 biți din semnalul shiftat dacă este mai mare decât valoarea 1 pentru a determina valoarea
(0 sau 1) semnalelor de vizibilitate a două săgeți (stânga și dreapta) de pe e cran,
Sageata_DreaptaVizibilitate și Sageata_StangaVizibilitate.

Figura 3.3.1: Code snippet cu prima parte a modulului SDS

43
În următoarea figură este prezentă logica pentru pasul precedent. Fiecare pas reprezintă un
sfert din afișajul modulului pe ecran și este format dintr -o icoană, o valoare, bordură pentru icoană
și simbol.
În figură, preluăm un semnal venit prin protocolul MPP, numit IcoanaPrecedenta_ID , care
conține indexul icoanei care va fi afișată dintr -o bază de date a icoanelor și îi atribuim u n offset de
1000 pentru a avea indexul potrivit pentru grADI, unde se va face afișarea efectivă.
Fiecare pas vine cu un semnal trigger, în acest caz TriggerPrecedent , venit și el prin MPP
căruia i se vor prelucra biții din componență pentru a extrage rest ul informațiilor. Astfel, acest
semnal trigger, împreună cu statusul modului SDS calculat în prima secțiune a modulului și
numărul pasului pentru care facem calculele (1, 2, 3 sau 4) vor reprezenta intrările blocului
Procesare biti , care va prelucra aceste intrări pentru a da spre ieșire valoarea pasului, indexul
bordurii afișate, indexul simbolului afișat și semnalele de vizibilitate ale acestora.
Analog, se face aceeasi logica, dar cu intrări și ieșiri diferite, și pentru pasul următor și al
doilea următ or.

Figura 3.3.2: Code snippet cu logica pentru pasul precedent
Pentru pasul curent, logica este puțin diferită față de ceilalți pași deoarece la pasul curent se
manifestă diferențele modulului SDS pe un rând față de cel pe două rânduri.
Diferențele vi zibile în figura următoare se rezumă la adăugarea a două semnale suplimentare
și anume OUT_IcoanaCurentaBig_ID și OUT_BorduraCurentaBig care reprezintă indexul icoanei
și indexul bordurii care vor fi afișate.

Figura 3.3.3: Code snippet cu logica pentru p asul curent

44
Fiecare pas se folosește de blocul Procesare biti pentru a prelucra semnalele trigger primite
și a obține informațiile dorite pentru afișare. În figura următoare avem logica din interiorul acestui
bloc.
În prima fază, primii 4 biți ai semnal ului trigger constituie o valoare temporară, următorii 2
biți constituie o bordură temporară, iar următorii 2 biți constituie un simbol temporar. Apoi,
folosindu -ne de valoarea temporară, simbolul temporar și sistemul de măsură al instrumentului de
bord (m etric sau imperial), vom determina daca valoarea care trebuie afișată este o măsură de
distanță sau timp. Dacă este de distanță, determinăm dacă este distanță metrică sau imperială, în
cazul distranței imperiale, valoarea temporară suferind o transformare din metri în feet.
În finalul figurii, determinăm cu exactitate ce fel de simbol afișăm pe ecran. Dacă este de
timp, valoarea se va afișa în secunde (s), iar daca este de distanță, simbolul afișat va fi de metri (m)
sau feet (ft).

Figura 3.3.4: Code sn ippet cu prima secvență de logică din blocul Procesare biti
În a doua secvență din acest bloc, folosindu -ne de bordura temporară, statusul modului SDS
și pasul pentru care se fac calculele, determinăm bordura care trebuie să o afișăm, vizibilitatea sa,
precum și vizibilitatea simbolului sau a textului “TIP”, în cazul în care nu va fi afișat nici un
simbol.
Dacă pasul este cel curent și modul SDS este în modul RUN (Active), bordura va fi mai
groasă decât celelalte borduri. Posibilitățile de bordură sunt: nici o bordură, albastru subțire, verde
subțire, roșu subțire, gri gros, albastru gros, verde gros sau roșu gros.

45

Figura 3.3.5: Code snippet cu a doua secvență de logică din blocul Procesare biti
Logica prezentată în figurile de mai sus constituie “cod ul” acestui modul. Ca și exemplu, pe
ecran, modulul SDS pe un rând și două rânduri, se prezintă asemănător figurilor următoare.

[1]Figura 3.3.6: Exemplu de modul SDS pe un rând (stânga) și modul SDS pe două rânduri (dreapta)

[1] Tabelul 3.3.1: Semnifi cația elementelor numerotate din figura 3.3.6
1 – Icoana pasului precedent 8 – Bordura celui de -al doilea pas următor
2 – Bordura pasului precedent 9 – Valoarea și simbolul pasului precedent
3 – Icoana pasului curent 10 – Valoarea și simbolul pasului cur ent
4 – Bordura pasului curent 11 – Valoarea și simbolul pasului următor
5 – Icoana pasului următor 12 – Valoarea și simbolul celui de -al doilea pas următor
6 – Bordura pasului următor 13 – Săgeata din stânga
7 – Icoana celui de -al doilea pas următor 14 – Săgeata din dreapta

46
3.4. Modul: Popups
Popup -urile sunt ferestre de informații care apar pe ecran. Acestea sunt alerte care aduc la
cunoștință șoferului ceea ce se întâmplă, indiferent de acțiunile pe care le execută tractorul. Aceste
popup -uri sunt șapte la număr, fiecare având propria implementare.
Înainte de a selecta popup -ul care va fi afișat pe ecran, se testează dacă instrumentul de bord
se află pe pagina principală deoarece doar pe acea pagină pot apărea aceste ferestre de informații.
Dacă pag ina principală este activă, se verifică semnalul primit prin MPP ActivePopup , care conține
indexul popup -ului care trebuie afișat. Dacă acest semnal conține una din valorile 1, 3, 4, 5, 6, 15
sau 17, conectorul corespunzător valorii va primi valoarea boole ană 1. Popup -urile cu indecșii 15 și
17 se afișează pe un singur rând, popup -urile cu indecșii 1, 4, 5, 6 se afișează pe două rânduri, iar
popup -ul cu indexul 3 se afișează pe patru rânduri.
Grafica realizată în grADI pentru aceste popup -uri are trei semna le de activare pentru un
rând, două sau patru rânduri. Cum pe ecran poate fi afișat un singur popup într -un moment, unul din
cele trei semnale va lua valoarea indexului popup -ului care urmează a fi afișat, iar celelalte două vor
lua valoarea 0, care semnif ică neafișare. Această atribuire a celor trei semnale, Popup1Linie,
Popup2Linii, Popup4Linii , are loc la finalul figurii 3.4.1 . Înainte de această atribuire, se verifică
dacă instrumentul de bord se află în stare activă și dacă self -testul s -a terminat.

Figura 3.4.1: Code snippet cu logica de selec ție a popup -urilor
Popup -ul cu index 1, este supran umit Icon & Text , deoarece conține o icoană și trei șiruri
de caractere. Icoana și textele din acest popup se preiau dintr -o baza de date pentru icoane și una
pentru texte prin indexuri.

47
Aceste indexuri vin prin MPP și se trimit către grADI pentru afișare. Icoanei, însă, trebuie să
i se atribuie un offset de 2000 pentru a fi aleasă icoana dorită în format mare. Icoanele cărora li se
atribuie offset de 1000 sunt mai mici.

Figura 3.4.2: Code snippet cu logica primului popup

Ceea ce este prezentat în figura 3.4.2 reprezintă popup 1 în spate, iar în figura 3.4.3 este
prezentat popup 1 la suprafață, pe ecran cu o icoană si texte aleatoare.

[1] Figura 3.4.3: Exe mplu de popup 1 pe ecran
Popup -ul cu index ul 3 este supranumit Icon & Bar și conține trei icoane și o bară gradată.
Așa cum este prezentat în figura 3.4.4 , cele trei icoane se preiau din baza de date a icoanelor.
Primei icoane, care se va afla deasupra bă rii gradate, i se atribuie un offset de 2000, ceea ce
înseamnă ca va fi o icoană mare, iar celorlalte două icoane, care se vor afla în stânga și dreapta
bării, li se atribuie un offset de 1000, ceea ce înseamnă că sunt icoane mici.
Pentru o afișare calita tivă a bării gradate, aceasta trebuie să aibe o valoare minimă (de la
care începe gradarea), o valoare maximă (limita bării gradate) și o limită actuală, care reprezintă
umplerea bării proporțional cu valoarea minimă și maximă. Aceste trei valori trebuiesc prelucrate
înainte de a fi trimise către grafică spre afișare, motiv pentru care fiecare va trece printr -un bloc
numit Units . Acest bloc primește ca intrări o valoare care se procesează, un index al unității de
măsură în care se măsoară valoarea primită ș i sistemul de măsură al instrumentului de bord (metric
sau imperial). După prelucrare, blocul dă la ieșiri valoarea prelucrată, un conector cu rezoluția
acestei valori prelucrate sub formă de -1, -2 sau -3, reprezentând valoare x 10-1, -2 sau -3, indexul
unității de măsură care va fi afișată pe ecran, un conector boolean pentur a ști dacă valoarea este
întreagă sau cu virgulă și un conector care spune dacă valoarea va fi afișată (în caz de eroare, nu se
afișează).

48
În ultima parte a figurii 3.4.4, se verfic ă conectorii cu rezoluție pentru fiecare valoare
(minimă, maximă și actuală) pentru a stabili valorile a altor trei conectori, pentru fiecare
valoare, semnificând valoarea booleană a vizibilității valorii cu o zecimală, două zecimale
sau trei zecimale.

Figura 3.4.4: Code snippet cu prima din trei părți de logică pentru Popup 3
În figura următoare , se atribuie valorile conectorilor pentru vizibilitatea zecimalelor celor
trei valori semnalelor destinate graficii care controlează apariția acestor zecimale, dar nu înainte de
a verifica dacă valoarea minimă, maximă sau actuală sunt în stare de eroare, comparându -le cu
65535 (doi bytes cu 1 pe fiecare bit). În caz de eroare, nu se va afișa nici o zecimală și nici o unitate
de măsură.

49

Figura 3.4.5: Code snippe t cu a doua din trei părți de logică pentru Popup 3
În ultima parte a logicii destinate popup -ului 3, se calculează procentajul de umplere a bării
gradate prin următoarea formulă:
Procentaj = ( ValoareActuală – ValoareMinimă ) x 100 / ( ValoareMaximă – ValoareMinimă ).
Folosindu -ne de acest procentaj, în cazul în care valorile nu sunt în stare de eroare, calculăm
factorul exact de umplere al bării, luând în considerare că pentru o bără gradată plină, factorul de
umplere trebuie să fie doi bytes pe 1, adic ă 65535. Astfel, avem următoarea formulă:
UmplereBara = LIMIT [ 0, 65535 ] ( Procentaj x 32767 / 100 )

50

Figura 3.4.5: Code snippet cu ultima parte de logică pentru popup 3
Acesta este singurul popup pe patru r ânduri din ecran. Urmând logica prezentată an terior, pe
ecran ar trebui să fie afișat un popup asemănător figurii 3.4.6.

[1] Figura 3.4.6: Exemplu de afișare pe ecran a popup -ului 3
Popup -ul cu indexul 4 este supranumit Two big icons și conține, așa cum îi sugerează
numele, două icoane mari. Logic a este relativ simplă, luând indecșii celor două icoane din baza de
date a icoanelor, atribuindu -le câte un offset de 2000 și trimițând aceste valori procesate semnalelor
de ieșire OUT_P4_IconLeft și OUT_P4_IconRight.

Figura 3.4.7: Code snippet cu logica pentru popup 4.
Având logica realizată anterior, pe ecran vom vedea figura 3.4.8.

51

[1] Figura 3.4.8: Exemplu de afișare pe ecran a popup -ului 4
Popup -ul cu indexul 5 este supranumit One icon . Acesta conține doar o icoană mare, fapt
pentru care se adaug ă un offset de 2000 indexului icoanei din baza de date a icoanelor.

Figura 3.4.9: Code snippet cu logica pentru popup 5
Având logica realizată anterior, pe ecran vom vedea figura 3.4.10 .

[1] Figura 3.4.10: Exemplu de afișare pe ecran a popup -ului 5
Popup -ul cu indexul 6 este supranumit Icon & Custom message și este asemănător popup –
ului 1, cu o icoană mare și trei șiruri de caractere, diferența fiind că cele trei șiruri nu sunt
predefinite într -o bază de date, ci sunt definite manual, caracter cu cara cter de către programator sau
în service.
Cele trei șiruri de caractere, deși în logică par a fi trei entități individuale, sunt de fapt trei
tablouri, fiecare element fiind o valoare pe 2 bytes, reprezentând codul ASCII pentru câte un
element.

Figura 3 .4.11: Code snippet cu logica pentru popup 6
Având logica prezentată anterior, pe ecran vom vizualiza popup -ul 6 în formatul următor:

52

[1] Figura 3.4.12: Exemplu de afișare pe ecran a popup -ului 6
Popup -ul cu indexul 15 este supranumit One small icon & Text și conține o icoană și un
text. Icoana este mică, fapt pentru care indexul din baza de date primește un offset de 1000, iar
textul este unul predefinit, activat printr -un index.

Figura 3.4.13: Code snippet cu logica pentru popup 15
Ultimul popup ar e index 17 și este supranumit One small icon & Custom message. Acesta
este asemănător celui cu index 15, diferența fiind că șirul de caractere nu este predefinit, ci este
introdus manual, caracter cu caracter.

Figura 3.4.14: Code snippet cu logica pentru popup 17
Având logica prezentată în figurile 3.4.13 și 3.4.14 , cele două popup -uri vor fi vizualitate pe
ecran ca în figura 3.4.15.

[1] Figura 3.4.15: Exemplu de afișare pe ecran a popup -ului 15 sau 17

3.5. Modul: Trailer brake pressure bar
Pe instr umentul de bord se află patru bări gradate fizice. Una dintre acestea este bara pe care
se afișează presiunea lichidului de frânare din remorcă. Bara este formată din zece LED -uri: două
roșii, trei galbene și cinci verzi.

53
Deși pe instrument , dimensiunea b ării ar putea da ideea unei funcționalități scurte, situația se
prezintă altfel. Se testează, pentru început, valoarea parametrului de EEPROM
INOUT_NVM_CM3.TrailerPressureBar pentru valoarea 1, ceea ce înseamnă că bara gradată este
activă. După care se ver ifică dacă mesajul de diagnoză a celei de -a doua intrare analogică a
instrumentului (pe care vin valorile bării), DIAG_IN_ANA_02 , este în stare de eroare “circuit
deschis” sau “scurt circuit”. Verificarea de eroare este, de fapt, o comparare binară cu valo area 768,
pentru ambele tipuri de eroare (256 – scurt circuit, 512 – circuit deschis = > 256 + 512 = 768).
Valoarea de la a doua intrare analogică reprezintă valoarea neprocesată a presiunii. Ea
trebuie să treacă printr -un bloc de damping cu filtru PT1 pân ă a fi reprezentată pe bară. Algoritmul
de damping se folosește de factorul de damping din parametrul de EEPROM
IN_NVM_Par.TrailerPressDampFactor pentru a face afișarea în pași. În cazurile când intrarea
analogică își revine din stare de eroare sau instrum entul de bord tocmai a terminat self test -ul,
valoarea din intrarea analogică neprocesată nu mai trece prin blocul de damping spre reprezentare
pe bară. Însă, înainte de a ajunge la blocul de damping, intrarea analogică mai trece printr -un filtru,
dar doar în cazul când își revine din stare de eroare. Filtrul acesta îi atribuie valorii analogice un
offset.

Figura 3.5.1: Code snippet cu prima parte din modulul de Trailer brake pressure bar
Conectorul DampedValue , calculat anterior, care conține valoarea a nalogică procesată de
blocul de damping se folosește în continuarea modulului. Cele zece LED -uri au fiecare câte o
treaptă care trebuie depășită pentru a fi activat. Un LED este activat dacă valoarea procesată
depășește acea treaptă printr -o histereză.
În continuarea modulului, calculăm o valoare maximă care ne asigură activarea tuturor
LED -urilor, adunând ultima treaptă, IN_NVM_Par.TrailerPressBarCurve [9], cu variabila de
histereză. Apoi, verificăm dacă instrumentul de bord se află în stare de Over Voltag e, caz în care se
trimite spre afișare ultima valoare validă și nu cea din acest ciclu.
Dacă instrumetul de bord tocmai a fost pornit (dacă a fost introdusă cheia în contact) ,
valoarea bării va fi 0 pentru acest ciclu, dacă nu, se continuă cu valoarea pro cesată până acum. În
ultima parte din figură, se testează dacă instrumentul de bord se află în self test, caz în care se vor
activa toate LED -urile folosind valoarea maximă calculată la începutul figurii, altfel se va trimite
valoarea procesată până acum.

54

Figura 3.5.2: Code snippet cu a doua parte din modulul de Trailer brake pressure bar
În final, se mai fac verificări pentru a determina cu exactitate dacă bara gradată ar trebui să
fie activată, după care se trimite valoarea procesată într -un bloc de hi stereză pentru a determina
dacă se va aprinde primul LED din bară sau nu. Intrările blocului de histereză sunt valoarea
procesată, treapta corespunzătoare LED -ului și variabila de histereză, iar ieșirea va fi o valoare
booleană (1 sau 0) pentru semnalul de activare al LED -ului. Analog, se face acest proces și pentru
celelalte 9 LED -uri.

Figura 3.5.3: Code snippet cu ultima parte din modulul de Trailer brake pressure bar

55

4. CONCLUZII ȘI PERSPECTIVE
În finalul lucrării putem susține că industria aut omobilelor agrare este în continuă dezvoltare
și, odată cu evoluția întregului, este necesară și evoluția părților. Și dat fiind faptul că șoferul
trebuie să aibă acces imediat la informații și comenzi ale vehicului, instrumentul de bord este
printre compo nentele care trebuie să evolueze cel mai mult.
Astfel, dezvoltarea instrumentelor de bord a devenit un domeniu de sine stătător integrând
tehnologii variate pentru o centralizare cât mai completă a tot ceea înseamnă informație oferită și
interfață cu șofe rul. Alertele, afișarea resurselor, detectarea erorilor și procesarea informațiilor
reprezintă elemente esențiale pentru un instrument de bord, deci o responsabilitate mare pentru
dezvoltator.
În realizarea acestui proiect am avut ocazia să trec prin toat e fazele dezvoltării unui modul
software, de la analiza și determinarea cerințelor corecte până la testarea, rezolvarea de bug -uri,
integrare într -un sistem mai complex și livrare la client. Mi s -a oferit ocazia de a lucra pe ceva nou,
în necunoștință de t ehnologie fapt care m -a determinat să îmi îmbunătățesc cunoștințele și, per
ansamblu, să evoluez și eu. Fiind proiect realizat în cadrul unei firme și știind că aceste module vor
fi parte dintr -un întreg, fără care nu ar fi complet și care va trebui livrat unui client, au oferit
responsabilitatea și determinarea necesară pentru motivarea realizării până la final.
Pentru viitor, putem spune că aceste module software vor servi ca bază pentru viitoare
instrumente de bord pentru tractoare, fiind deja plănuit u n astfel de proiect pentru un nou tractor cu
capacități mai performante, dar și pentru un proiect personal din acest domeniu. Ca îmbunătățiri
pentru modulele software descrise în acest proiect, putem menționa redarea de sunete pentru popup –
uri sau atingere a unui prag critic al presiunii lichidului de frânare, îmbunătățirea design -ului popup –
urilor, creșterea spațiului de memorie pentru a putea stoca și procesa mai multe tipuri de erori sau
înlocuirea ecranului cu unul mai performant care ar determina îmbună tățirea calității elementelor
grafice pentru toate modulele de pe ecran.
Cert este că nevoia modulelor software precum afișarea alertelor sau interceptarea erorilor
din sistem se prezintă a fi tot mai mare și eficiența lor tot mai evidentă.

56

5. LISTĂ TABE LE ȘI FIGURI

 Tabelul 2.2.1: Tipurile de date posibile în logi.CAD
 Tabelul 2.2.2: Intrările și ieșirile blocului ROR
 Tabelul 2.2.3: Intrările și ieșirile blocului GE
 Tabelul 2.2.4: Intrările și ieșirile blocului RS
 Tabelul 2.2.5: Intrările și ieșirile bloc ului ATOREAL
 Tabelul 2.2.6: Intrările și ieșirile blocului CTUD
 Tabelul 2.2.7: Intrările și ieșirile blocului R_TRIG
 Tabelul 2.2.8: Intrările și ieșirile blocului SIN
 Tabelul 2.2.9: Intrările și ieșirile blocului SEL
 Tabelul 2.2.10: Intrările și ieșirile b locului CONCAT
 Tabelul 2.2.11: Intrările și ieșirile blocului CONCAT_D
 Tabelul 2.2.12: Intrările și ieșirile blocului TON
 Tabelul 2.2.13: Intrările și ieșirile unui force marker
 Tabelul 2.2.14: Instrucțiunile limbajului ST alături de un exemplu fiecare
 Tabelul 2.3.1: Tipuri de resurse
 Tabelul 2.3.2: Pașii dezvoltării unui proiect în grADI
 Tabelul 3.3.1: Semnificația elementelor numerotate din figura 3.3.6
 Figura 2.1.1: Instrument de bord classic
 Figura 2.1.2: Vedere explozivă a unui instrument de bord (expl oded view)
 Figura 2.1.3: Grafic afișând comportamentul histerezei
 Figura 2.1.4: Grafice exemplificând comportamentul interpolării liniare
 Figura 2.1.5: Exemplu de martori de bord
 Figura 2.1.6: Exemplu de cadran
 Figura 2.1.7: Exemplu de ecran monocrom, col or și full color
 Figura 2.1.8: Notarea și poziționarea fiecărui segment / toate cele 128 de combinații ale unui ecran
cu șapte segmente
 Figura 2.2.1: Logo -ul de start al logi.CAD -ului
 Figura 2.2.2: Adunarea a două numere în logi.CAD
 Figura 2.2.3: Structura unui proiect în logi.CAD
 Figura 2.2.4: Locația bibliotecilor IEC61131 -3 și IEC61131 -3_(Ext) în structura unui proiect
 Figura 2.2.5: Funcționalitatea blocului RS
 Figura 2.2.6: Comportamentul timer -ului TON
 Figura 2.2.7: Exemplu de simulare folosind force m arkere
 Figura 2.2. 8: Editorul ST
 Figura 2.2.9: Exemple de blocuri funcționale create în ST denumite INTEGRAL și DERIVATIVE
 Figura 2.2.10: Blocul PID creat în ST
 Figura 2.3.1: Logo -ul de start al aplicației grADI
 Figura 2.3.2: Fluxul de lucru a unui proiect în grADI

57
 Figura 2.3.3: Ierarhia obiectelor de bază și a obiectelor widget în grADI
 Figura 2.3.4: Interfața mediului de dezvoltare grADI
 Figura 2.4.1: Logo -ul de start al aplicației CANoe
 Figura 2.4.2: Unitate de control simulată în CANoe
 Figura 2.4.3: Set ările de bază ale unei simulări în CANoe
 Figura 2.5.1: Sistem de unități electrice de control dintr -un autovehicul fără CAN
 Figura 2.5.2: Sistem de unități electrice de control dintr -un autovehicul cu CAN
 Figura 2.5.3: Subsistem CAN creat de Vector
 Figura 2.5.4: Structura pe biți a unui identificator dintr -un mesaj transmis pe CAN
 Figura 2.5.5: Stuctura binară a mesajului BAM
 Figura 2.5.6: Stuctura binară a mesajului DT
 Figura 2.5.7: Stuctura binară a ultimului mesaj DT
 Figura 3.1.1: Vedere din față și din spate a instrumentului de bord pentru tractoare
 Figura 3.1.2: Vedere explozivă a instrumentului de bord pentru tractoare
 Figura 3.1.3: Schimb de mesaje prin MPP dintre ECU și IC
 Figura 3.1.4: Dimensiunile modulelor pe ecran (stânga) și un exemplu de config urație de module pe
ecran (dreapta)
 Figura 3.1.5: Pagina de meniu
 Figura 3.2.1: Modulul de symbols afișat pe ecran fără eroare (stânga) și cu eroare (dreapta)
 Figura 3.2.2: Code snippet cu logica modulului Symbols
 Figura 3.3.1: Code snippet cu prima parte a modulului SDS
 Figura 3.3.2: Code snippet cu logica pentru pasul precedent
 Figura 3.3.3: Code snippet cu logica pentru pasul curent
 Figura 3.3.4: Code snippet cu prima secvență de logică din blocul Procesare biti
 Figura 3.3.5: Code snippet cu a doua sec vență de logică din blocul Procesare biti
 Figura 3.3.6: Exemplu de modul SDS pe un rând (stânga) și modul SDS pe două rânduri (dreapta)
 Figura 3.4.1: Code snippet cu logica de selec ție a popup -urilor
 Figura 3.4.2: Code snippet cu logica primului popup
 Figura 3.4.3: Exemplu de popup 1 pe ecran
 Figura 3.4.4: Code snippet cu prima din trei părți de logică pentru Popup 3
 Figura 3.4.5: Code snippet cu a doua din trei părți de logică pentru Popup 3
 Figura 3.4.5: Code snippet cu ultima parte de logică pentru popu p 3
 Figura 3.4.6: Exemplu de afișare pe ecran a popup -ului 3
 Figura 3.4.7: Code snippet cu logica pentru popup 4.
 Figura 3.4.8: Exemplu de afișare pe ecran a popup -ului 4
 Figura 3.4.9: Code snippet cu logica pentru popup 5
 Figura 3.4.10: Exemplu de afișare pe ecran a popup -ului 5
 Figura 3.4.11: Code snippet cu logica pentru popup 6
 Figura 3.4.12: Exemplu de afișare pe ecran a popup -ului 6
 Figura 3.4.13: Code snippet cu logica pentru popup 15
 Figura 3.4.14: Code snippet cu logica pentru popup 17
 Figura 3.4.1 5: Exemplu de afișare pe ecran a popup -ului 15 sau 17
 Figura 3.5.1: Code snippet cu prima parte din modulul de Trailer brake pressure bar
 Figura 3.5.2: Code snippet cu a doua parte din modulul de Trailer brake pressure bar
 Figura 3.5.3: Code snippet cu ult ima parte din modulul de Trailer brake pressure bar

58

6. REFERINȚE BIBLIOGRAFICE

[1] – “PERF_SDF_HLC_IC_SW_PerformanceSpecification_1.2 ” (Documentația cerințelor
software a proiectului, Continental Automotive România)
[2] – “PERF_SDF_HLC_IC_SY_Performanc eSpecification_3.0 ” (Documentația cerințelor de
sistem a proiectului, Continental Automotive România)
[3] – “Instrument Cluster Features ” (Prezentare generală powerpoint a funcționalităților
instrumentelor de bord, Continental Automotive România)
[4] – “Logicad_Training_Ver4 ” (Prezentare p owerpoint a mediului de dezvoltare integrată
logi.CAD, Continental Automotive România)
[5] – “LogicadHelp” (Chestiuni infografice ajut ătoare ale mediului de dezvoltare integrată
logi.CAD, Continental Automotive România)
[6] – “CINEMA4DHelp ” (Chestiuni infografice ajutătoare ale mediului de dezvoltare integrată
CINEMA4D, MAXON)
[7] – “CANoeCANalyzer ” (Chestiuni infografice ajutătoare ale mediului de testare și analiză
CANoe, Vector)
[8] – “CANTrainingPresentation ” (Prezentar e powerpoint a protocolului de comunicare CAN,
Continental Automotive România)
[9] – “SAE J 1939 -73” (Documenta ție detaliată a standardului j1939, SAE INTERNATIONAL)
[10] – “MPP Presentation” (Prezentare general a protocolului Multi -Package Protocol, Conti nental
Automotive România)

59

7. ANEXE
i) Schemă bloc generală a unui instrument de bord

60
ii) Schema bloc a instrumentului de bord pentru tractoare

61

DECLARAȚIE DE AUTENTICITATE
A
PROIECTULUI DE FINALIZARE A STUDIILOR

Titlul proiectului : Instrumentul de bord al unui utilaj agricol
Autorul proiectului: Andronic Doru -Alexandru

Proiectul de finalizare a studiilor este elaborat în vederea susținerii
examenului de finalizare a studiilor organizat de către Facultatea
_______________I.E.T.I._______________ __________ din cadrul Universității din
Oradea, sesiunea________iulie_________ a anului universitar 2017
Prin prezenta, subse mnatul (nume, prenume, CNP): Andronic Doru -Alexandru
CNP 1880803115189 , declar pe proprie răspundere că aceast proiect a fost s cris de
către mine, fără nici un ajutor neautorizat și că nici o parte a proiectului nu conține
aplicații sau studii de caz publicate de alți autori.
Declar, de asemenea, că în proiect nu există idei, tabele, grafice, hărți sau alte
surse folosite fără re spectarea legii române și a convențiilor internaționale privind
drepturile de autor.

Oradea,
Data
14.06.2017 Semnătura