Capitolul 1 ………………………….. ………………………….. ………………………….. ………………………….. .. 1… [627456]

Cuprins
Capitolul 1 ………………………….. ………………………….. ………………………….. ………………………….. .. 1
1. Introducere ………………………….. ………………………….. ………………………….. ………………… 1
1.1. Motivație ………………………….. ………………………….. ………………………….. ……………… 1
1.2. Clusterul de bord ………………………….. ………………………….. ………………………….. …… 1
1.3. Automatizare ………………………….. ………………………….. ………………………….. ………… 2
1.4. Scopul și structura lucr ării de licenț ă ………………………….. ………………………….. ……. 3
Capitolul 2 ………………………….. ………………………….. ………………………….. ………………………….. .. 4
2. Industria auto. Obiective și motivația alegerii subiectului ………………………….. …………. 4
2.1. Testarea ………………………….. ………………………….. ………………………….. ……………….. 4
2.1.1. EOL Test System ………………………….. ………………………….. ………………………… 4
2.1.2. Black -box testing ………………………….. ………………………….. ………………………… 6
2.1.3. White -box testing ………………………….. ………………………….. ……………………….. 6
2.2. Descrierea problemei ………………………….. ………………………….. …………………………. 6
2.3. Procedura de dezvoltare Software ………………………….. ………………………….. ……….. 7
Capitolul 3 ………………………….. ………………………….. ………………………….. ………………………….. 10
3. Proiectare, validare module, automatizare ………………………….. ………………………….. … 10
3.1. Modulul DIO ………………………….. ………………………….. ………………………….. ………. 10
3.1.1. Configurare pin: ………………………….. ………………………….. ………………………… 10
3.1.2. Citire valoare pin: ………………………….. ………………………….. ……………………… 12
3.1.3. Scriere valoare pin: ………………………….. ………………………….. ……………………. 13
3.1.4. Design și implementare: ………………………….. ………………………….. …………….. 14
3.1.5. Testarea ………………………….. ………………………….. ………………………….. ……….. 15
3.2. Modulul PWM ………………………….. ………………………….. ………………………….. ……. 16
3.2.1. Start PWM: ………………………….. ………………………….. ………………………….. ….. 17
3.2.2. Design și implementare ………………………….. ………………………….. ……………… 18
3.2.3. Testarea ………………………….. ………………………….. ………………………….. ……….. 19
3.3. Modulul ISM ………………………….. ………………………….. ………………………….. ………. 20
3.3.1. Inițializare Stepper Motor ………………………….. ………………………….. …………… 20
3.3.2. Mișc ă Pointer: ………………………….. ………………………….. ………………………….. . 22
3.3.3. Mișcare Ciclic ă: ………………………….. ………………………….. ………………………… 23
3.3.4. Mișcare Motor la 0: ………………………….. ………………………….. …………………… 24
3.3.5. Primește poziția: ………………………….. ………………………….. ……………………….. 25
3.3.6. Design și implementare ………………………….. ………………………….. ……………… 26
3.3.7. Testarea ………………………….. ………………………….. ………………………….. ……….. 29
3.4. Modulul TFT ………………………….. ………………………….. ………………………….. ………. 30

3.4.1. Curățare ecran: ………………………….. ………………………….. ………………………….. 30
3.4.2. Desenare pixel: ………………………….. ………………………….. …………………………. 31
3.4.3. Deseneaz ă imagine: ………………………….. ………………………….. …………………… 32
3.4.4. Deseneaz ă imagine periodic: ………………………….. ………………………….. ………. 33
3.4.5. Desenare dreptunghi: ………………………….. ………………………….. …………………. 35
3.4.6. Design și implementare ………………………….. ………………………….. ……………… 36
3.4.7. Testarea ………………………….. ………………………….. ………………………….. ……….. 39
3.5. Automatizare ………………………….. ………………………….. ………………………….. ………. 40
Capitolul 4 ………………………….. ………………………….. ………………………….. ………………………….. 41
4. Concluzii și dezvolt ări pe viitor ………………………….. ………………………….. ………………. 41
4.1. Concluzii ………………………….. ………………………….. ………………………….. ……………. 41
4.2. Dezvolt ări ulterioare ………………………….. ………………………….. ………………………… 41
Bibliografie ………………………….. ………………………….. ………………………….. …………………………. 42

1
Capitol ul 1
1. Introducere

1.1. Motivație
Istoria automobilului începe în anul 1769 când Nicolas -Joseph creează primul automobil
capabil să transporte oameni, acesta a funcționat cu un motor cu aburi. Motorul cu aburi ajunge
foarte repede să fie folosit și în alte tipuri de vehicule cum ar fi: locomotiva cu aburi, autobuzul,
vaporul etc. Motorul cu combustie internă a fost creat de Nicéphore Niépce și fratele lui Claude
în 1807. Aceștia au decis să îl instaleze pe un vas ce na viga pe râurile Franței. Prima mașină
care folosea pe post de combustibil petrol sau gaz a fost patentată de Benz Patent -Motorwagen
în anul 1886. Părintele mașinilor electrice este Thomas Parker. Acesta a creat prima mașină cu
motor electric în 1884. Indus tria mașinilor electrice există și în zilele noastre dar nu a fost așa
de mult promovată precum mașinile cu combustie internă. Automobilul se impune cu rapiditate
în țările dezvoltate ca principal mijloc de transport, urmând ca după cel de -Al Doilea Război
Mondial, industria auto să se dezvolte puternic. [1]
O data cu această dezvoltare încep cercetările în acest domeniu și aparițiile numeroaselor firme
ce au observat potențialul acestei invenții. Printre fabrici se numără: Daimler, Peugeot, Porsche,
Mercedes, Renault, etc. Principalul producător de automobile a fost Statele Unite ale Americi
urmând ca ulterior să se afirme China și Japonia. Componentele automobilelor au ajuns să fie
din ce în ce mai sofisticate, necesitând cunoștințe specializate în anum ite domenii, cât și un
volum tot mai mare de munca, astfel că producția lor a fost în mare măsură externalizată de
către firmele producătoare de mașini înspre firme specializate. Cum noile firme se ocupau doar
cu anumite componente, au putut să aloce mai m ult timp părții de cercetare și dezvoltare a
acestora. Acest lucru a dus la îmbunătățirea performanțelor și la diversificarea componentelor.
Una din cele mai mari companii în acest domeniu (și care produce componente utilizate în toate
părțile unui automob il – motor, transmisie, interior, etc.) este Continental AG, care are o ramură
importantă și în România (cu filiale în Timișoara, Sibiu și Iași). Aceste companii au ușurat mult
activitatea firmelor producătoare de mașini (ex. Ford, Audi etc.), munca lor re ducându -se la
proiectarea automobilului în ansamblu, retestarea componentelor livrate de către furnizori
(pentru a verifica calitatea acestora) și asamblarea lor în produsul final. În România, în ultimii
ani, în industria auto s -a evidențiat firma Continen tal Automotive România, care produce
dispozitive precum: BCM, ECM, SD, HUD și nu în ultimul rând clusterul, reprezentând o
componentă importantă încorporată într -un autoturism. Aceste dispozitive sunt gândite să
transforme conducerea unui autovehicul într -o activitate cât mai ușoară și plăcuta. Principalul
obiectiv al unui cluster de bord este afișarea informațiilor legate de funcționarea
autovehiculului. Fiind un instrument atât de important testarea lui trebuie să fie temeinică.
Verificarea lui se face im ediat ce a fost asamblat folosind testarea EOL.

1.2. Clusterul de bord
Clusterul sau computerul de bord are rolul de a transmite șoferului informații. Informațiile ce
ajung la șofer îl țin informat despre modul de funcționare a vehiculului. Clusterul este, de obicei,
prezent în fața șoferului și apare ca un ecran cu două sau mai multe indicatoare analogice și
numeroase leduri. De obicei indicatoarele analogice se folosesc pentru viteza autovehiculului,
turații ale motorului sau nivelul combustibilului. Pentru afișarea unor informații variabile
acestuia îi poate fi atașat și un display. Numeroase alte dispozitive pot fi atașate unui cluster
pentru a afișa mai multe informații sau din motive de design. Pe la începuturile automobilelor

2
clusterul trebuia să afișez e cat mai multe informații despre dispozitivele din care este compusă
mașina. Autovehiculul avea în componenta ei o mulțime de senzori. Cum industria nu era așa
de avansată toate informațiile date de acești senzori trebuiau interpretate de șofer.
Conducăto rului autovehiculului îi erau necesare aceste informații pentru a interveni și rezolva
probleme acolo unde era nevoie folosind cunoștințe avansate în domeniu. Pentru a ajunge să
conducă o mașina un individ trebuia, mai întâi, să aibă o buna înțelegere a fu ncționarii tuturor
subsistemelor vehiculului (motor, transmisie, direcție), sau a componentelor individuale (de ex.
senzorul de nivel al combustibilului). Cum industria s -a dezvoltat, informațiile despre
funcționarea autovehiculului au început să devină to t mai numeroase. În scurt timp cumulul de
informații a fost prea mare iar șoferul nu mai putea să ii dea fiecăreia atenția necesară. A apărut
necesitatea eliminări anumitor informații. Informațiile eliminate au început să fie prelucrate
automat. Ani au tre cut și o dată cu dezvoltarea industriei automobilelor, computerul de bord a
devenit din ce în ce mai mic afișând informații cât mai puține. Informațiile eliminate au fost
prelucrate de alte dispozitive ce lucrează în paralel. Rolul acestor dispozitive este să trimită un
semnal clusterului în cazul în care apare o problemă majoră (ex. un senzor nu mai funcționează),
să rezolve erorile ce sunt de competența lor (ex. răcirea motorului) și să monitorizeze
funcționarea vehiculului.

1.3. Automatizare
Automatizarea reprezintă o ramură a tehnicii, scopul fiind reducerea intervențiilor directe și
continue umane in funcționarea mașinilor si instalațiilor. Cu cât intervenția umana este redusă ,
cu atât gradul de automatizare este mai înalta .[10]
Automatizarea acoperă aplic ații variind de la un termostat de uz casnic care controlează un
cazan, până la un sistem industrial de control mare, cu zeci de mii de măsurători de intrare și
semnale de control al ieșirii. În complexitatea controlului, acesta poate varia de la simp lu
control pornit -oprit la algoritmi de nivel înalt multi -variabil.
Automatizarea a fost realizată prin diverse mijloace, inclusiv dispozitive mecanice, hidraulice,
pneumatice, electrice, electronice și calculatoare , de obicei în combinație. Sistemele
complicat e, cum ar fi fabricile moderne, avioanele și navele, utilizează în mod obișnuit toate
aceste tehnici combinate. Beneficiul automatizării include economii de muncă, economii de
costuri de energie electrică, economii de costuri materiale și îmbună tățiri ale calității, și
preciziei. [12]
Termenul de automatizare, inspirat de cuvântul anterior automat nu a fost folosit pe scară largă
înainte de 1947, când Ford a înființat un departament de automatizare. În această perioadă,
industria a adoptat rapid controlorii de feedback, care au fost introduse în anii 1930.

Paradoxul automatizării spune că cu cât este mai eficient sistemul automat, cu atât este mai
importantă contribuția umană a operatorilor. Oamenii sunt mai puțin implicați, dar imp licarea
lor devine mai cri tică.
Dacă un sistem automatizat are o eroare, acesta va multiplica acea stă eroare până când va fi
rezolvat sau oprit. Aici intră operatorii umani.
Un exemplu fatal a fost Air France Flight 447, unde un eșec al automatizării a pus piloții într –
o situație m anuală pentru care nu erau pregătiți. [11]

3
1.4. Scopul și structura lucrării de licență
Subiectul lucrării de licența reprezintă testarea unui cluster de bord pe linia de producție (deși
principiile discutate aici pot fi aplicate oricărei componente – ECU = El ectronic Control Unit).
Verificarea instrumentului de bord se realizează cu ajutorul a două aplicații dedicate:
 una care rulează pe microcontrolerul din instrumentul de bord (EOL Embedded
Software); ea va prelua comenzile de pe bus -ul de comunicare și va c ontrola perifericele
microcontrolerului
 cea de a doua rulează pe PC și prin intermediul ei testerul (operatorul uman) trimite
comenzi instrumentului de bord și evaluează răspunsurile date de acesta.
Lucrarea de licență va cuprinde produsul încărcat pe clus ter. În acest studiu voi realiza un
program care va fi capabil să testeze cele mai folosite funcționalități ale cluster -ului. Pentru a
efectua un test, userul va trebui să trimită comenzi clusterului și să compare rezultatele primite
cu cele așteptate. Luc rarea mea de licența va testa următoarele componente ale unui cluster de
bord:
 LED -uri, prin care se realizează iluminarea sau sunt afișate numeroase informații.
 Motoarele pas cu pas (stepper motor) folosite pentru afișarea informațiilor ce au mai
multe s tări (combustibil, viteza, turații).
 TFT – ecranul atașat clusterului.
 Memoria internă (RAM) folosită pentru a stoca date de volum mic care vor fi pierdute
o dată cu întreruperea tensiuni de la alimentare.
 Memoria flash folosi tă pentru a stoca volume mari de date (de ex. imagini, sunete, alte
resurse) care nu vor fi pierdute o dată cu întreruperea tensiuni de la alimentare.
În această lucrare voi cuprinde toate etapele creări și livrări unui cod de calitate. După ce voi
clarifica anumite aspecte legate de o biectul lucrări voi mai scrie în acest document importanța
produsului, cum se realizează acesta (voi prezenta detaliat fiecare pas pentru realizarea unui
produs software) și cum va fi folosit. Pașii pentru realizarea softului prezentat în acest document
vor include documentele realizate la fiecare pas (voi explica care este rolul lor și ce trebuie să
includă) și testele (de câte feluri sunt, care este scopul lor, ce trebuie testat și cum).
Pentru a explica cât mai bine procesul prin care voi realiza obiectu l lucrării de licența voi folosi
câteva exemple de module. Pentru aceste exemple voi scrie motivul pentru care modulele există
(de ce sunt necesare), interfețele (cum se va apela o funcționalitate a modulului), designul și
implementarea (voi explica cum va funcționa funcția, după acest document va fi implementat
codul) și testele (tabele cu exemple de teste).

4
Capitolul 2
2. Industria auto. Obiective și motivația alegerii subiectului
2.1. Testarea
„To test a program, is to try and make it fail. 1”

2.1.1. EOL Test Syst em
EOL (End Of Line) Test System reprezintă o soluție de testare a ECU -urilor la finalul liniei de
producție, soluție care implică o aplicație SW ce rulează în ECU (embedded SW) precum și o
alta aplicație pe PC. Aplicația embedded (numită și toolbox) este rulată din RAM -ul ECU -ului
ce urmează a fi testat, al cărui conținut se pierde atunci când este întreruptă alimentarea
dispozitivului cu energie electrică. Ea nu va fi livrată clientului, fiind destinată exclusiv uzului
intern în cadrul companiei. Numele d e „toolbox ”, indică tocmai versatilitatea acestei aplicații,
care permite testarea componentelor HW prin intermediul unor „unelte ” diferite. „Uneltele ”
sunt module diferite ce nu interacționează direct între ele și deci sunt ușor de combinat pentru
a obțin e produsul dorit. [2][3]
Scopul acestei testări este să ne asigurăm ca produsele livrate la client corespund standardelor
de calitate așteptate de acesta. Verificarea unui produs în timpul producției este un pas critic în
fabricarea unui produs de calitate . Produsele defecte sau cele care nu îndeplinesc limitele
specificate de client trebuie separate cât mai repede de cele ce trebuie livrate clientului. Testele
EOL nu vor testa doar cerințele funcționale, ci și cerințele nefuncționale (cerințe de:
performan ță, operare, verificare, fiabilitate, etc.), având tot timpul în vedere randamentul
procesului de producție.
Testarea trebuie să fie cât mai precisă și rapidă. Timpul alocat producerii unui cluster trebuie să
fie cât mai redus pentru a obține un profit cât mai mare. Acest lucru nu trebuie să fie afecteze
calitatea produsului de aceea validării trebuie să i se aloce o atenție deosebită. Cum timpul este
limitat a apărut necesitatea de a executa un număr cât mai mic de teste dar de importanță
maximă. Aici a ap ărut necesitatea EOL -ului care va testa doar dacă placa de bază nu prezintă
defecte hardware (de ex. linii scurtcircuitate la GND sau Vcc, conectarea necorespunzătoare a
dispozitivelor la circuitul principal, etc.) și dacă circuitele integrate aflate pe pl acă vor putea să
execute funcții de bază (de exemplu să activeze un ecran, să controleze un motor pas cu pas,
etc), funcții ce vor fi folosite mai târziu de aplicația SW principală2.
Utilizarea EOL test system presupune următorii 6 pași:
 Trimitere comandă de activare (O dată activat acest mod clusterul este pregătit să
încarce imaginea și să primească comenzi)
 Primire răspuns pentru comanda de activare și verificarea acestuia
 Trimitere imagine (imaginea va fi încărcată în memorie)
 Primire răspuns pentru tri miterea imaginii (succes sau eșec)
 Trimitere comandă
 Primire răspuns (răspunsul este trimis de funcția care realizează comanda)
Procesul de testare se realizează pe baza unui protocol de comunicare simplu, request -response:
testerul trimite (cu ajutorul u nei aplicații instalate pe PC) o comandă către ECU, acesta

1“Seven Principles of Software Testing ” Autor: Bertrand Meyer publicat de Sof tware Technologies, Au gust 2008

2 Prin Aplicație princi pală înțelegem acea aplicație SW care va fi livrată clientului final (de ex. Daimler, Renault,
etc.) și care implementează funcționalitatea cerută de acesta (afișarea vitezei automobilului, a kilometrajului, etc)

5
efectuează operația cerută (de ex. Citește conținutul unei locații de memorie, Aprinde un pin,
Desenează o imagine pe ecran, etc.) și trimite un răspuns înapoi către tester. Răspunsul poate fi
pozitiv (în cazul în care ECU -ul a executat cu succes comandă), sau negativ (motivele putând
fi: comandă incorectă, comanda nu a putut fi executată din motive ce țin de starea ECU -ului,
rezultatele execuției nu sunt cele așteptate ).

Figura 2 .1 Ordinea trimit erii comenzilor în protocolul EOL

Figura 2 .2 Comunicarea între PC și cluster

6
Deoarece regulile de comunicare sunt bine stabilite, procesul poate fi automatizat. Astfel
testarea se realizează mai repede și sunt evitate erorile ce pot fi făcute de teste r. Dacă procesul
presupune observarea unor rezultate (ex. Mișcarea pointerilor, Aprinderea ledurilor, Aprinderea
display -ului) va fi necesar un feedback al testerului. în unele cazuri, acest feedback e furnizat
de echipamente specializate (camere de luat v ederi „inteligente ”, senzori speciali, etc.)

2.1.2. Black -box testing
Testarea black -box va verifica dacă programul poate îndeplini cerințele funcționale fără a lua
în considerare structura programului. Pentru acest tip de testare nu este necesară cunoașterea
codului sursă, c unoașterea specificațiilor, a in putului și outputului fiind suficientă. Rezultatul
acestui tip de testare se stabilește prin compararea in putului cu outputul pe baza specificațiilor.
De asemenea tot pe baza specificațiilor se vor crea testele .
Este limpede că acop erirea unei plaje mai mari de in puturi ne va da o testare mai precisă. Nu
este întotdeauna posibil să testăm toată plaja de valori pentru imput deoarece combinațiile pot
fi mult prea numeroase. Cum specificațiile sunt cele care ne aj ută să cream testele un mare risc
este prezentat de posibilitatea specificațiilor incorecte sau incomplete.
În testarea black -box se urmărește maximizarea rezultatelor într -un număr cât mai mic de teste.
Cum nu este posibil, în totdeauna, să acoperim într egul set de inputuri , putem crea teste care să
acopere o serie de inputuri . Acest lucru este posibil dacă grupam serii de inputuri , considerate
echivalente, și te stăm doar anumite valori. [2]

2.1.3. White -box testing
Contrar testări black -box în testarea white -box testerul trebuie să aibă acces la codul
programului pentru a îl putea verifica. Acest tip de testare necesită cunoștințe specifice deoarece
este necesară citirea și înțelegerea codului precum și a structuri acestuia.
Testele sunt create p e baza codului pentru a ne asigura ca fiecare parte a programului este
folosită corect și nu există vreo parte redundantă. Testele se creează pe baza codului nu a
specificațiilor și trebuie să acopere o arie cât mai mare din codul sursă. Aceste teste trebuie și
să verifi ce dacă toate cazurile au fost acoperite de developer. [2]

2.2. Descrierea problemei
În acest studiu aș dori să aprofundez tehnicile de lucru cu microcontrolere. În programarea
microprocesoarelor se efectuează modificări direct cu memoria, orice schimbare î n memoria
internă fiind capabilă să modifice comportamentul sistemului. Această disciplina necesită
cunoștințe din mai multe domenii (ex. Electronică, Inginerie SW). Aceste domenii cuprind
cunoștințe ce ne permit înțelegerea și schimbarea atât comportament ului procesorului cât și a
sistemului în care este încorporat (ex. Cluster) și cu care interacționează în realizarea anumitor
acțiuni. [9]
Pentru a îndeplini cerințele date de client este conceput un întreg mecanism. Din acest
mecanism fac parte: procesorul (care va rula programul scris), dispozitivele periferice
(dispozitive legate de procesor, de exemplu circuite de memorie, drivere) și firele de legătură .
Perifericele au un scop precis și sunt controlate prin semnale transmise de controler. În lucrarea
mea voi încerca să cuprind cât mai multe funcții ce folosesc dispozitive periferice pentru a
îndeplini un număr de cerințe clasice ale clienților.
Cum testarea este foarte importantă este necesară o analiză a mai multor tehnici din acest

7
capitol, pentru a înțelege în ce situații o tehnică este preferabilă. Astfel de cunoștințe sunt
folosite pentru realizarea tuturor produselor software de calitate.
În acesta lucrare intenționez să realizez un program bine structurat ce va pitea fi capabil să
evalueze calitate a unui calculator de bord. Programul pe care doresc să îl realizez va avea ca
scop principalele funcții ce trebuie verificate. Aș vrea ca acest program să fie mult simplificat
față de actualele versiuni. Prefer o variantă simplificată deoarece scopul este studierea testări
nu realizarea de cod. Pe lângă acestea dacă pot aș vrea să aduc îmbunătățiri programelor
existente a.î. să fie optimizate și complete sau să implementez funcționalități noi. V oi face acest
lucru pentru a îmi verifica cunoștințele .
Aplica țiile care vor fi prezentate pe parcursul documentului vor face referire la implementarea
unor funcții cu ajutorul cărora se vor realiza teste de:
– verificarea funcțiilor motoarelor “pas cu pas ”
– de verificare a intensității luminii date de LED -uri
– de setar e și configurare a unor pini
– testarea afișajului TFT
– verificare a scrieri/citiri în/din cipul de memorie externă
– verificare a scrieri/citirii în/din memoria internă.
Nu în ultimul rând aș dori să învăț procedurile de dezvoltare optimă a unui produs softwa re. Un
procedeu de dezvoltare în care o dată primite cerințele se începe scrierea codului este o manieră
folosită de obicei de începători . În această manieră o dată cu scrierea codului se începe și
conceperea designului iar dacă pe parcurs apar modificări datorită neînțelegerilor totul trebuie
corectat. O astfel de manieră irosește foarte mult timp și deci este ineficientă. În această lucrare
voi încerca să abordez o metodă mai eficientă și structurată ce ar trebui să reducă timpul de
dezvoltare și să asigu re detectarea și corectarea cât mai timpurie a eventualelor probleme.

2.3. Procedura de dezvoltare Software

Figura 2.3 V cycle

Procedura generală pentru obținerea unui produs software este următoarea: Cerere -Analiză –
Proiectare/Design -Implementare -Testare. Toate aceste etape sunt necesare dezvoltării ordonate
și eficiente a unui astfel de produs. Oameni diferiți sunt implicați în faze diferite pentru o
dezvoltare mai bună a unui produs, astfel etapele sunt analizate de mai multe ori, și pentru
paralelizarea activităților (de ex. scrierea specificațiilor de testare poate fi făcută în paralel cu

8
implementarea funcționalității, imediat ce specificațiile au fost definitivate).

Figura 2.4 Comunicarea între etapele procesului de dezvoltare

În timpul realizării uneia dintre faze este posibil să descoperim erori în ce privește fazele
anterioare (de ex. în timpul elaborări designului, descoperim că avem de clarificat unele cerințe,
fapt ce face necesară revenirea la etapa anterioară).

o Analiză : presupune comunicar ea între un dezvoltator și un client pentru înțelegerea cât
mai bună a cerințelor. Dacă cerințele nu vor fi bine înțelese dezvoltarea ar putea merge într -o
direcție greșită. Faza se încheie cu redactarea unui document care conține cerințele clientului.
Aceste cerințe pot fi funcționale (de ex. aprinderea LED -urilor, mișcarea pointerilor, etc.), sau
ne-funcționale (de ex. consum maxim de RAM/ROM, plaja tensiunilor de alimentare, etc.).
În documentele ce trebuie realizate în această fază se vor nota informați i despre :
– Care este obiectivul modulului – scopul pentru care a fost realizat sau cerința la care
trebuie să răspundă .
– Comenzile – ce scop au acele comenzi (ce efect trebuie să producă).
– Cerințe software –Ex. ce versiune a programului X trebuie folosită.
– Cerințe hardware -cerințe legate de componentele clusterului.

o Proiectare/Design : în această etapă se descrie cât mai concret modul în care va fi
implementată funcționalitatea descrisă în faza anterioara. Rezultatul acestei etape este un
document de design , care trebuie să descrie obiectele software prin care vom realiza cerințele
utilizatorului final: module, funcții, variabile, etc. În plus, documentul trebuie să descrie și felul
în care aceste obiecte vor interacționa. În etapa de design se face trecerea de la „universul
problemei ” la „universul soluției ”, aici se pot detecta lipsuri ale specificațiilor, se pot propune
soluții pentru corectarea acestora. Tot aici dezvoltatorul poate propune și analiza diverse soluții,
pentru a o alege pe cea optimă.

o Impl ementare : scrierea codului astfel încât să se realizeze cerințele cât mai repede și
precis. Implementarea trebuie să se realizeze după designul făcut anterior. Dacă avem un model
în prealabil al sistemului ce trebuie dezvoltat vom evita să pornim pe o dire cție greșită (să
dezvoltăm un cod care, la un moment dat, să nu mai poată îndeplini cerințele).

o Testare : Verificarea este foarte importantă, ea ne asigură că vom livra clientului ceea ce
acesta a cerut. Se vor verifica documentele, codul și testele pentru a ne asigura că nu conțin

9
erori și ca sunt consistente între ele. Este important ca acest pas să fie realizat de o altă persoană
decât cea care a implementat modulul/sistemul SW, deoarece o perspectivă nouă asupra
funcționalități poate scoate la iveală de ficiențe în definirea și/sau implementarea cerințelor.
Această etapă este împărțită în alte 3 etape:
 Teste de modul: verifică implementarea corectă a designului modulului SW
 Teste de integrare: sunt dedicate verificării interacțiunilor dintre module, grupu ri
de module, subsisteme, etc.
 Teste de sistem: Acestea sunt teste ale sistemului complet de programe și
echipamente. Scopul e să testăm funcționalitatea sistemului, așa cum îl va folosi
clientul.

Se recomandă ca un test să acopere o funcționalitate cât m ai bine definită pentru a localiza cât
mai ușor problema. De aceea testarea concretă se realizează prin așa numitele „Test-Case ”-uri
(teste atomice, care verifică, în mod ideal, un singur aspect al funcționalității). Un Test -Case
constă din:
– Setup: o serie de operațiuni prin care aducem sistemul într -o stare clar definită.
– Acțiune: descrie operația pe care tester -ul trebuie s -o execute asupra sistemului.
– Reacția așteptată: ce ne așteptam să facă sistemul.
– Reacția efectivă: cum reacționează sistemul în reali tate.
– Rezultat: dacă reacția efectivă coincide cu cea așteptată, rezultatul e PASS (sau OK),
în caz contrar, e FAIL (sau NOK)

Nu de fiecare data putem reduce testarea la mici teste independente, deseori este nevoie de o
corelație între ele astfel încât . să ajungem la rezultatul dorit. Dacă testele sunt interdependente
ne va fi destul de greu să testăm funcționalitatea pe care ne -o dorim deoarece va trebui să urmăm
o listă de pași, ceea ce va costa timp. Pe lângă acesta dacă vom rula mai multe teste iar la final
rezultatul este FAIL, nu vom putea afla care este testul care nu face ce trebuie, decât după
cercetări amănunțite care necesită mult timp.
Dacă în urma rulării unui test obținem un rezultat negativ, va trebui să verificăm:
 Specificațiile de testare ș i testele: testul este scris corect sau testăm funcționalitatea
așa cum trebuie.
 Codul și designul acestuia: problema apare ca urmare a scrieri greșite a codului sau
în designul acestuia.
 Documentele de cerințe: eroarea apare ca urmare a unei înțelegeri g reșite a cerințelor
sau apare ca efect al unor cerințe inconsistente
.
Aceste verificări se aplică și în cazul în care se raportează erori (de către utilizator) după ce
produsul a fost livrat.
Review -ul reprezintă inspecția ale codului de către mai multe p ersoane, pentru acesta se
întocmesc documente specifice. Participanții la review vor nota toate observațiile într -un
document.
Acel document va conține:
– numele fișierelor p e care s -au făcut verificările
– câteva informații prin care să putem identifica exa ct acele fiș iere (ex. calea, versiunea)
– observațiile participanților. [4]

10
Capitolul 3

3. Proiectare, validare module , automatizare

Prin modul înțelegem o componentă a unei aplicații SW, având o funcționalitate bine definită
(de ex modulul DIO se ocupă d oar cu intrările și ieșirile digitale ale microcontrolerului). În
elaborarea acestui proiect am încercat ca modulele se fie cât mai independente unele față de
celelalte. Un avantaj al acestei independențe este economia de memorie data, de exemplu, dacă
utilizatorul va dori să testeze doar motoarele va trebui încărcată imaginea ce conține doar
modulul ISM (Intelligent Stepper Motor).
Se preferă ca orice modul să fie capabil să aducă sistemul din starea inițială, oricare ar fi aceea
(după reset sau după ce s-au trimis un număr mare comenzi) într -o stare în care să poată
funcționa. Acest lucru se va face prin modificarea setărilor inițiale ale procesorului a.î. cerințele
să poată fi îndeplinite. Designul modulelor este proiectat de dezvoltator a.î. să ofere cli entului
un control cât mai eficient al resurselor microcontrolerului (configurare pini, control
caracteristici semnal PWM de ieșire, etc) și echipei de dezvoltare o bază solidă pentru
reutilizare și mentenanță ușoară.
Clientul (cu ajutorul unui PC) comunic ă cu aceste module prin interfețe (comenzi trimise pe
bus ce respecta anumite reguli, vezi tabelele de mai jos, și determină o anumită funcționalitate
a modulului). De exemplu, în cazul modulului DIO avem o interfață dedicată pentru
configurarea unui pin, și o altă interfață pentru citirea valorii unui pin. Validarea parametrilor
comenzii se va face de către fiecare modul, orice problemă fiind semnalată printr -un mesaj de
eroare.
Modulele realizate de mine sunt următoarele :
-DIO (Digital Input Output)
-ISM (Inteligent Stepper Motor)
-TFT (Thin Film Transistor)
-PWM (Pulse With Modulation)

3.1. Modulul DIO
Modulul permite configurarea porturilor microcontroler -ului, setarea unui pin de ieșire pe o
anumită valoare, precum și citirea porturilor de intrare. M ai detaliat, operațiile realizate de
acesta sunt:
– configurează pinii microcontrolerului (în modul GPIO, sau funcții dedicate: SPI, ADC, etc)
– citește starea unui pin dat (precum și modul în care pinul este configurat)
– setează un pin dat pe valoarea lo gică 1/0 (dacă pinul a fost configurat în prealabil ca ieșire)
Observație: nu toți pinii pot fi configurați deoarece uni sunt necesari pentru buna funcționare a
clusterului (de exemplu un pin poate fi folosit pentru alimentarea la tensiune a întregului sis tem,
acesta ar trebui mereu să fie configurat a.î. să primească tensiune). Dacă se va trimite o comandă
de modificare a registrelor unui port care nu face parte din porturile ce pot fi configurate se va
întoarce un mesaj de eroare. [6]
Acest modul are 3 comenzi:
3.1.1. Configurare pin:
Configurează direcția pinulului (imput/output) și funcția pe care o va avea de îndeplinit.
Configurarea efectivă va fi realizată prin scrierea unui set de registri cu valorile specificate de

11
manualul microcontrolerului . Comanda va verifica dacă regiștri pinului au fost scriși și ne va
da o eroare în cazul în care unul nu a fost scris.

Tabelul următor descrie conținutul comenzii care trebuie transmisă cluster -ului.
Tabelul 3 .1 Formatul comenzii „Configurare pin”
Index Byte Semn ificație Valori Permise
0 ID-ul comenzii – DIO 0x10
1 ID-ul comenzii – Configurare pin 0x10
2 Numărul portului 0xXX*
3 Numărul pinului 0x00 – 0x0F
4 Funcția alternativă 0x00 – 0x04
5 Direcția 0x00 – 0x01
6 Biți de verificare a mesajului 0x00 – 0xFF
*aici p oate fi folosită orice valoare.
Unde:
Numărul portului: Are valori diferite în funcție ce microcontroler
Numărul pinului: Are valori între 0 și 0xF și reprezintă numărul pinului pe care vrem să îl
folosim.
Funcția alternativă: numerele de la 0 la 4 c odifică funcționalități diferite ale pinilor. Codul
este numărul funcționalității pinului din data -sheet. [6]
Direcția: 1-Input, 0 -Output
Biți de verificare a mesajului: specifici protocolului EOL.

În urma executării comenzii, ECU -ul va returna următorul răspuns:
Tabelul 3 .2 Formatul de răspuns al comenzii „ Configurare pin”
Index Byte Semnificație Valori Permise
0 Statusul sistemului 0xXX
1 Statusul execuției comenzii Vezi tabelul 3 .3
2 Biți de verificare a mesajului 0x00 – 0xFF
Unde:
Statusul sistemu lui: ne va spune dacă sistemul funcționează corect ( 0x00) sau dacă sistemul a
avut o eroare: de comunicare (eroare de CRC, timeout, etc.), de stare (sistemul e într -o stare în
care nu poate procesa cererea) etc.
Statusul execuției comenzii: care va spune d acă această a fost terminată cu succes sau eroare
și în acest din urmă caz vom primi un cod ce va reprezenta tipul erorii.
Biți de verificare a mesajului: specifici protocolului EOL

Tabelul 3 .3. Valorile date de „ Statutul comenzii” implementate în cod
Statusul Numele statusului Descriere
0xA0 Funcție executată cu succes Comanda e corectă și a fost executată cu
succes
0xB0 Eroare de parametri Unul sau mai mulți parametri au valori
incorecte
0xB3 Eroare de lungime Prea puțini sau prea mulți parametri
0xB6 Eroare privind ID -ul comenzii Nu există o comandă cu acest ID

12
0xE0 Eroare de configurare Unul sau mai mulți registri nu a putut fi
scris

3.1.2. Citire valoare pin:
Acesta comandă va citi modul de funcționare al pinului (GPIO sau funcție dedicată), valoar ea
(1 sau 0) și direcția. Acestea se pot realiza prin simpla citire a registrilor de stare/date asociați
respectivelor porturi.
Formatul comenzii este:
Tabelul 3 .4 Formatul comenzii „Citire valoare pin”
Index Byte Semnificație Valori Permise
0 ID-ul come nzii- DIO 0x10
1 ID-ul comenzii – Citire valoare pin 0x30
2 Numărul portului 0xXX*
3 Numărul pinului 0x00 – 0x0F
4 Biți de verificare a mesajului 0x00 – 0xFF
*aici poate fi folosita orice valoare.

Unde:
Numărul portului: Are valori diferite în funcți e ce microcontroler
Numărul pinului: Are valori între 0 și 0xF și reprezintă numărul pinului pe care vrem să îl
folosim.
Biți de verificare a mesajului: specifici protocolului EOL
Răspunsul ECU -ului va conține datele cerute, sau un cod de eroare, în cazul în care comanda
nu a fost corect formulată.
Tabelul 3 .5 Formatul de răspuns al comenzii „Citire valoare pin”
Index Byte Semnificație Valori Permise
0 Statusul sistemului 0xXX
1 Statusul execuției comenzii Vezi tabelul 3 .6
2 Modul de control al pinului (DIO/Alternative)* 0x00 -0x04*
3 Valoarea logică a pinului (0 low/1 high) 0x00 -0x01
4 Modul pinului (ieșire /intrare) 0x00 -0x01
5 Biți de verificare a mesajului 0x00 – 0xFF
* un pin poate funcționa în modul DIO sau în alte 4 moduri Alternative

Unde:
Statusul sistemului ne va spune dacă sistemul funcționează corect ( 0x00) sau dacă sistemul a
avut o eroare: de comunicare (eroare de CRC, timeout, etc.), de stare (sistemul e într -o stare în
care nu poate procesa cererea) etc.
Statusul execuției comenzii: care ne va spune dacă funcția a fost terminată cu succes sau eroare
și dacă a avut eroare vom primi un cod ce va spune tipul ei.

Tabelul 3 .6. Valorile date de „Statutul comenzii ” implementate în cod
Statusul Numele statusului Descriere
0xA0 Funcție exe cutată cu succes Comanda e corectă și a fost executată cu

13
succes
0xB0 Eroare de parametri Unul sau mai mulți parametri au valori
incorecte
0xB3 Eroare de lungime Prea puțini sau prea mulți parametri
0xB6 Eroare privind ID -ul comenzii Nu există o comandă cu acest ID

3.1.3. Scriere valoare pin:
Pune un pin pe 0=Low (0 V) sau 1=High (5 V) prin scrierea acestei valori într -un registru.
Comanda verifică registrul pinului astfel încât valoarea să fi fost scrisă, în caz contrar se va
returna un mesaj de eroare.
Com anda pe care o vom transmite este:
Tabelul 3 .7 Formatul comenzii for “Scriere valoare pin”
Index Byte Semnificație Valori Permise
0 ID-ul comenzii – DIO 0x10
1 ID-ul comenzii – Scriere valoare pin 0x20
2 Numărul portului 0xXX*
3 Numărul pinului 0x00 – 0x0F
4 Valoarea logica a pinului 0x00 – 0x01
5 Biți de verificare a mesajului 0x00 – 0xFF
*aici poate fi folosita orice valoare
Unde:
Numărul portului: Are valori diferite în funcție ce microcontroler
Numărul pinului: Are valori între 0 și 0xF și reprezintă numărul pinului pe care vrem să îl
folosim.
Valoarea logica a pinului: (0 low/1 high)
Biți de verificare a mesajului: specifici protocolului EOL

Și ne vom aștepta la un răspuns de forma:
Tabelul 3 .8 Formatul de răspuns al comenzii „Scriere valoare pin”
Index Byte Semnificație Valori Permise
0 Statusul sistemului 0xXX
1 Statusul execuției comenzii Vezi tabelul 3 .9
2 Biți de verificare a mesajului 0x00 – 0xFF
Unde:
Statusul sistemului: ne va spune dacă sistemul funcționează corect (0x00) sau dacă sistemul a
avut o eroare: de comunicare (eroare de CRC, timeout, etc.), de stare (sistemul e într -o stare în
care nu poate procesa cererea) etc.
Statusul execuției comenzii: care ne va spune dacă funcția a fost terminată cu succes sau eroare
și dacă a avu t eroare vom primi un cod ce va reprezenta tipul ei.

Tabelul 3 .9 Valorile date de “ Statutul comenzii” implementate în cod
Statusul Numele statusului Descriere
0xA0 Funcție executată cu succes Comanda e corectă și a fost executată
cu succes

14
0xB0 Eroare de parametri Unul sau mai mulți parametri au valori
incorecte
0xB3 Eroare de lungime Prea puțini sau prea mulți parametri
0xB6 Eroare privind ID -ul comenzii Nu există o comandă cu acest ID
0xE0 Eroare de scriere Registrul nu a putut fi scris

3.1.4. Design și implementare:
Interfețe publice:
 void DIO_vToolbox (void): e un dispecer, va fi apelat atunci când ECU -ul
primește o comandă cu ID -ul 0x10. În funcție de valoarea celui de -al 2-lea parametru, va apela
alte funcții (private) ale modulului, pentru a real iza funcționalitatea cerută.

Figura 3.1 Diagrama de activitate a funcției „DIO_vToolbox()”

Variabile globale: nu avem.
Funcții și variabile statice:
 static void DIO__vWrite_pin() verifică parametri, scrie valoarea primită și
verifică dacă pinul s -a putu t scrie.
 static void DIO__vRead_pin() citește valorile asociate pinului.
 static void DIO__vConfigurePin() verifică dacă datele primite sunt corecte,
configurează pinul și verifică dacă datele s -au scris.
 static uint8 DIO__u8IsValidPort() ajută celelalte f uncții în verificarea
parametrilor. Aceasta verifică dacă portul ales face parte din cele ce pot fi configurate.
Variabile globale (definite în alte module) folosite:
 EOLOS_nFrameIn.by – Buffer de intrare: aici loader -ul pune octeții citiți de pe
bus.
 EOLO S_nFrameOut.by – Buffer de ieșire: aici modulul scrie codul de eroare
care trebuie returnat pe bus (dacă e cazul) precum și eventualele date adiționale.
Funcții care implementează comenzile modulului:

15
 static void DIO_vConfigurePin(void)

Figura 3.2 Diagrama de activitate a fun cției „DIO_vConfigurePin(void)”

 static void DIO_vWrite_pin(void)

Figura 3.3 Diagrama de activitate a funcției „DIO_vWrite_pin(void)”

 static void DIO_vRead_pin(void)

Figura 3.4 Diagrama de activitate a funcției „DIO_vRead_p in(void)”

3.1.5. Testarea
Pentru testarea acestui modul vom adăuga câteva teste care să acopere toate cerințele.
Tabelul 3 .10 Testare DIO
ID Cerința la
care trebuie
să răspundă Starea
inițială Acțiune Reacție așteptată Reacție
efectivă Rezultat
1 Configurare După
reset 10 10
01 0F
00 00 ECU -ul răspunde pozitiv
(codul 0xA0)
2 Configurare După
reset 10 10
01 0B
00 00 ECU -ul răspunde pozitiv
(codul 0xA0)
3 Citire După
reset 10 30
01 0F ECU -ul răspunde pozitiv
(codul 0xA0, urmat de
detaliile funcționării pinu lui)

16
4 Citire După
reset 10 30
01 0B ECU -ul răspunde pozitiv
(codul 0xA0, urmat de
detaliile funcționării pinului)
5 Scriere După
testul 1 10 20
01 0F
00 Led-ul de pe pinul 15 portul
01 este aprins și ne așteptăm
să primim un mesaj de
succes
6 Scriere După
testul 2 10 20
01 0B
00 Led-ul de pe pinul 11 portul
01 este aprins și ne așteptăm
să primim un mesaj de
succes
Descrierea coloanelor tabelului de mai sus:
Starea inițială: descrie starea sistemului dinaintea executări testului.
Acțiune: Acțiu nea executată supra sistemului (în cazul de fata, ce comandă EOL vom trimite).
Reacție așteptată: evenimentul la care ne așteptăm după efectuarea testului.
Reacția efectivă: reacția pe care a avut -o, dacă a avut.
Rezultat test: valori posibile: OK/NOK; dac ă Reacție așteptată și Reacția efectivă sunt
identice, rezultatul testului e OK, în caz contrar î l vom nota cu NOK.
Pentru a ajunge în starea “După reset” se vor efectua următori pași:
– Se va efectua un reset fizic (se va întrerupe alimentarea cu energie el ectrică și se va
restaura) sau unul software (printr -o comandă specifică).
– Se va activa EOL (se va trimite un mesaj specific).
– Se va încărca imaginea.

3.2. Modulul PWM
PWM (Pulse Width Modulation) urmărește, în general, obținerea unei tensiuni variabile.
Proce sorul nu poate da decât tensiuni de 5V așa că vom folosi următorul principiu: Dacă într -o
unitate de timp T, o unitate de timp P (cu P<T) pinul va avea valoarea 5V iar în unitatea de timp
T-P pinul va avea valoarea 0V , atunci media valori va fi T/P. Mărind unitatea de timp P vom
observa că media valori se va majora, dar nu mai mare de 5V . Poate fi determinat experimental
că acea medie se apropie de realitate atunci când valoarea T scade foarte mult (ex. T = 1
nanosecunde). Acest lucru este posibil deoarece natura nu realizează linii drepte ci mai degrabă
curbe așa cum se poate vedea în Figura 2.9.

Figura 3.5 Semnalul PWM văzul la osciloscop

Unitatea de timp T, folosită anterior, este dată de frecvența cu care se realizează semnalul.
Frecvența este măsur a numărului de repetări ale unui fenomen periodic în unitatea de timp, cu
cât Numărul de repetări este mai mare cu atât timpul scurs între repetări este mai mic.
Unitatea de timp P este de numește ciclu de lucru. În funcție de valoarea ciclului se va obțin e o

17
anumită tensiune.

Figura 3.6 Duty Cycle (ciclul de lucru)

Acest semnal este folosit pentru a comunica cu dispozitivele analogice. Practic un led acționat
cu un semnal PWM se poate aprinde și stinge gradual sau în cazul unui motor acesta se poate
mișca mai repede sau mai încet. [6] [7]
Acest modul are următoarea comandă:
3.2.1. Start PWM:
Această comandă va porni un semnal PWM de o frecvența și un ciclu date. Înainte de apelarea
acesteia pinul trebuie configurat pe GPIO folosind modulul DIO.
Frecvența și ciclul nu pot fi redate exact de către procesor. În figura 2.10 vedem cum arată
semnalul văzut la osciloscop. Se poate observa că la o frecvența mai mica curentul ajunge la
5V respectiv 0V , iar la o frecvența mare semnalul nu mai reușește să atingă pragul 5V sau cel
de 0V . Cu cât frecvența este mai mare vom obține un semnal mai liniar. Acest semnal liniar va
avea o tensiune foarte apropiată de ceea pe care ne -o dorim.

Figura 3.7 Semnalul văzut la osciloscop pentru diferite valori ale frecvenței

Ciclul de lucru este dat în procente. Procentele reprezintă perioada, din unitatea de timp alocată
transmiteri semnalului, în care pinul va da o valoare de 5V (ex. 500 reprezintă faptul că pinul
are valoare 5V în 50% din timp, adică media valori este de aproxima tiv 2,5V).
Valoarea frecvenței și ciclului de lucru vor trebui convertite în hexazecimal și trimise ca
parametri. Fiecare canal poate transmite la alte frecvențe. Canalele nu au aceiași limită de
frecvență . [6]

Pentru această operațiune va trebui să tran smitem un mesaj de forma:
Tabelul 3 .11 Formatul comenzii „Start PWM”
Index Byte Semnificație Valori Permise
0 ID-ul comenzii – PWM 0x66
1 ID-ul comenzii – Start PWM 0x00
2 Canalul PWM -ului 0x00 – 0x5B
3 Frecvența PWM
[Hz]
MSB 0x00 – 0xFF
4 Byte 2 0x00 – 0xFF
5 Byte 1 0x00 – 0xFF

18
6 LSB 0x01 – 0xFF
7 Ciclu de lucru
[%]
MSB 0x00 – 0xFF
8 LSB 0x00 – 0xFF
9 Biți de verificare a mesajului 0x00 – 0xFF
Unde:
Canalul PWM -ului: Vor fi luate din specificațiile procesorului. Acesta ne dă un pin și un port
ce pot fi folosite pentru a obține un semnal PWM.
Frecventa PWM: un număr între 0 și maximul dat de procesor luat din data -sheet-ul
procesorului.
Ciclu de lucru o valoare intre 0 și 1000 , dacă valoarea aleasă este 0 semnalul nu va fi un PWM.

MSB -Most Significant Byte
LSB -Least Significant Byte

Și ne vom aștepta la un mesaj de forma:
Tabelul 3 .12 Formatul de răspuns al comenzii „Start PWM”
Index Byte Semnificație Valori Permise
0 Statusul sistemului 0xXX
1 Statusul execuției comenzii Vezi tabelu l 3.13
2 Biți de verificare a mesajului 0x00 – 0xFF
Unde:
Statusul sistemului ne va spune dacă sistemul funcționează corect (0x00) sau dacă sistemul a
avut o eroare: de comunicare (eroare de CRC, timeout, etc.), de stare (sistemul e într -o stare în
care nu poate procesa cererea) etc.
Statusul execuției comenzii care va spune dacă funcția a fost terminată cu succes sau eroare și
dacă$ a avut eroare vom primi un cod ce ne va reprezenta tipul erorii.

Tabelul 3 .13 Valorile date de “ Statutul comenzii” imple mentate în cod
Statusul Numele statusului Descriere
0xA0 Funcție executată cu succes Comanda e corectă și a fost executată cu
succes
0xB0 Eroare de parametri Unul sau mai mulți parametri au valori
incorecte
0xB3 Eroare de lungime Prea puțini sau prea m ulți parametri
0xB6 Eroare privind ID -ul comenzi Nu există o comandă cu acest ID

3.2.2. Design și implementare
Interfețe publice:
 void PWM_vToolbox(void): e un dispecer, va fi apelat atunci când ECU -ul
primește o comandă cu ID -ul 0x66. În funcție de valoarea c elui de -al 2-lea parametru, va apela
alte funcții (private) ale modulului, pentru a realiza funcționalitatea cerută.
Variabile: nu avem
Funcții și variabile statice

19
 static uint32 u32GetFreq() primește canalul și returnează frecvența maximă a
acelui canal. Folosită doar în realizarea PWM -ului.
 void vStartPWM() veifică parametri și va genera semnalul PWM.
Variabile globale (definite în alte module) folosite:
 EOLOS_nFrameIn.by – Buffer de intrare: aici loader -ul pune octeții citiți de pe
bus.
 EOLOS_nFrameOut.b y – Buffer de ieșire – aici modulul scrie codul de eroare
care trebuie returnata pe bus (dacă e cazul) precum și eventualele date adiționale.
În diagrama de mai jos, am reprezentat funcționalitatea modulului:

Figura 3.8 Diagrama de activitate a modulului PWM

3.2.3. Testarea
Pentru testarea acestui modul vom adăuga câteva teste care să acopere toate cerințele
Tabelul 3 .14 Testare PWM
ID Cerința la care
trebuie să
răspundă Starea
inițială Acțiune Reacție așteptată Reacție
efectivă* Rezultat
1 Transmiterea
unui semnal de
tensiune între
0V și 5V După
reset 66 02 00 20
0A A0 00
00 32 ECU -ul răspunde
pozitiv (codul 0xA0)
iar pe pinul respectiv
vom putea citi
frecvența și duty
cycle -ul (date prin
comanda) la un
osciloscop
2 Transmiterea
unui semnal de
tensiune înt re
0V și 5V După
reset 66 02 00 20
0A A0 00
00 50 ECU -ul răspunde
pozitiv (codul 0xA0)
iar pe pinul respectiv
vom putea citi
frecvența și duty
cycle -ul (date prin
comanda) la un
osciloscop
3 Transmiterea
unui semnal de
tensiune între
0V și 5V După
reset 66 02 00 20
0A A0 00
00 ECU -ul răspunde
negativ (codul 0xB3)
* Aici vor fi notate valorile obținute experimental

20

Descrierea coloanelor tabelului de mai sus:
Starea inițial ă descrie starea sistemului dinaintea executări testului.
Acțiune Acțiunea execu tată supra sistemului (în cazul de față, ce comandă EOL vom trimite).
Reacție așteptată evenimentul la care ne așteptăm după efectuarea testului.
Reacția efectivă reacția pe care a avut -o, dacă a avut.
Rezultat test valori posibile: OK/NOK; dacă reacția a șteptată și reacția efectivă sunt identice,
rezultatul testului e OK, în caz contrar îl vom nota cu NOK..

Pentru a ajunge în starea “După reset ” se vor efectua următori pași:
– Se va efectua un reset fizic (se va întrerupe alimentarea cu energie electrică ș i se va
restaura) sau unul software (printr -o comandă specifică)
– Se va activa EOL (se va trimite un mesaj specific)
– Se va încărca imaginea.

3.3. Modulul ISM
ISM (Inteligent Step per Motor) reprezintă modulul ce poate controla motoarele în pași. Acestea
se numes c motoare “pas cu pas ” deoarece la primirea unui semnal se rotește cu un anumit număr
de grade. Acest număr de grade se numește pas deoarece nu poate fi modificat și orice mișcare
se face dintr -o sumă a acestora. Pentru a le putea roti pe distanțe mari se folosesc semnale
asemenea celor folosite la modulul PWM (vezi 2.1.2 Modulul PWM). Acești pași sunt foarte
mici pentru o acuratețe mare a deplasări. Pe lângă acestea sistemul motoarelor mai dispune și
de alte funcții cum ar fi detectarea poziției actuale sa u revenirea la poziția inițială . [6] [7]
Comenzile acestui modul sunt următoarele:
3.3.1. Inițializare Stepper Motor
O comandă ce are un număr mare de parametri fiecare din aceștia fiind necesare unei utilizări
cât mai complexe. Aceasta are funcția de a configur a și de a seta niște limite pentru următoarele
mișcări. Comanda de inițializare trebuie apelată înaintea oricărei alte funcții în caz contrar toate
celelalte funcții vor returna un mesaj de eroare.
Comanda de inițializare se poate aplica pe un set diferit de motoare pentru fiecare dintre ele
trebuie să fie dat și intervalul în care acestea se vor putea mișca. Procesorul poate fi configurat
pentru a folosi mai multe motoare dar s -ar putea să nu fie nevoie de toate. Prin limite înțeleg
pozițiile între care p ointerul se poare mișca. V om fi nevoiți să dăm limite pentru fiecare motor
a.î. ele să se poată mișca diferit.
Inițializarea va schimba setările pinilor care pot deservi motoare . Astfel dacă se va dori testarea
acelor pini cu funcții ce fac parte din alte module, pini vor trebui reconfigurați.
Limitele vor define aria în care motoarele pot să se miște. O dată inițializat, motoarele vor merge
până la limita inferioară dată. Orice mișcare în afara acestei ari ne va da un me saj de eroare.

Mesajul pe care îl vom transmite va fi de forma:
Tabelul 3 .15 Formatul comenzii „ Inițializare Stepper Motor”
Index Byte Semnificație Valori Permise
0 ID-ul comenzii – ISM 0xB3
1 ID-ul comenzii – Inițializare Stepper Motor 0x00
2 Indexul motoarelor 0x00 – 0x3F
3 Motorul 1 Poziția de start MSB 0x00 – 0xFF

21
4 LSB 0x00 – 0xFF
5 Poziția de final MSB 0x00 – 0xFF
6 LSB 0x00 – 0xFF
7
Motorul 2 Poziția de start MSB 0x00 – 0xFF
8 LSB 0x00 – 0xFF
9 Poziția de final MSB 0x00 – 0xFF
10 LSB 0x00 – 0xFF
11
Motorul 3 Poziția de start MSB 0x00 – 0xFF
12 LSB 0x00 – 0xFF
13 Poziția de final MSB 0x00 – 0xFF
14 LSB 0x00 – 0xFF
15
Motorul 4 Poziția de start MSB 0x00 – 0xFF
16 LSB 0x00 – 0xFF
17 Poziția de final MSB 0x00 – 0xFF
18 LSB 0x00 – 0xFF
19
Motorul 5 Poziția de start MSB 0x00 – 0xFF
20 LSB 0x00 – 0xFF
21 Poziția de final MSB 0x00 – 0xFF
22 LSB 0x00 – 0xFF
23
Motorul 6 Poziția de start MSB 0x00 – 0xFF
24 LSB 0x00 – 0xFF
25 Poziția de final MSB 0x00 – 0xFF
26 LSB 0x00 – 0xFF
27 Biți de ve rificare a mesajului 0x00 – 0xFF
Unde:
Motor reprezintă indexul motorului folosit (se găsește în datasheet).
Indexul Motoarelor : V om folosi 8 cifre codificare în binar astfel: 00000000 dacă nici un motor
nu va fi folosit, 00000001 dacă doar primul motor v a fi folosit, 00000011 dacă cel de -al doilea
motor și primul vor fi folosite etc. Acest număr va fi codificat în hexazecimal și transmis ca
parametru.
Pentru fiecare motor vor trebui date Poziția de start și Poziția de final care ne vor spune între
ce limi te pot fi mișcați pointeri . Poziția de start trebuie să fie o valoare mai mica decât Poziția
de final, iar Poziția de final trebuie să fie o valoare mai mică de 0x12C 0 deoarece motorul nu
poate atinge poziții mai mari.
MSB -Most Significant Byte
LSB -Least Significant Byte

Și ne vom aștepta la un răspuns de forma:
Tabelul 3 .16 Formatul de răspuns al comenzii „Inițializare Stepper Motor”
Index Byte Semnificație Valori Permise
0 Statusul sistemului 0xXX
1 Statusul execuției comenzii Vezi tabelul 3.17
2 Biți de verificare a mesajului 0x00 – 0xFF

22
Unde:
Statusul sistemului ne va spune dacă sistemul funcționează corect (0x00) sau dacă sistemul a
avut o eroare: de comunicare (eroare de CRC, timeout, etc.), de stare (sistemul e într -o stare în
care nu poate p rocesa cererea) etc.
Statusul execuției comenzii care va spune dacă funcția a fost terminată cu succes sau eroare și
dacă a avut eroare vom primi un cod ce ne va reprezenta tipul erorii.
Tabelul 3 .17 Valorile date de “Statutul comenzii ” implementate în co d
Statusul Numele statusului Descriere
0xA0 Funcție executată cu succes Comanda e corectă și a fost executată cu
suces
0xB0 Eroare de parametri Unul sau mai mulți parametri au valori
incorecte
0xB3 Eroare de lungime Prea puțini sau prea mulți parametri
0xB6 Eroare privind ID -ul comenzi Nu există o comandă cu acest ID

3.3.2. Mișcă Pointer:
Funcția “Mișcă Pointer ” este funcția care ne permite să testăm mișcarea motoarelor. Numărul
de pași dat va reprezenta ținta la care motorul trebuie să ajungă. Înainte de t rimiterea aceste
comenzi motorul trebuie inițializat (folosind comanda Inițializare Ste pper Motor).

Comanda pe care o vom trimite este următoarea :
Tabelul 3 .18 Formatul comenzii „Mișcă Pointer”
Index Byte Semnificație Valori Permise
0 ID-ul comenzii – ISM 0xB3
1 ID-ul comenzii – Mișcă Pointer 0x20
2 Indexul motorului 0x00 -0x05
3 Număr de pași MSB 0x00 -0xFF
4 LSB 0x00 -0xFF
5 Biți de verificare a mesajului 0x00 – 0xFF

Unde:
Indexul motorului: În datasheet se pot identifica un număr de 6 motoare aici se va introduce
indicele motorului care va fi folosit. Trebuie avut în vedere că motorul să fi fost, în prealabil,
inițializat.
Număr de pași: Numărul de pași efectuați. Trebuie să se încadreze în limitele date la
inițializare.
MSB -Most Significant Byte
LSB-Least Significant Byte

Și ne vom aștepta la un răspuns de forma:
Tabelul 3 .19 Formatul de răspuns al comenzii „Mișcă Pointer”
Index Byte Semnificație Valori Permise
0 Statusul sistemului 0xXX
1 Statusul execuției comenzii Vezi tabelul 3 .20
2 Biți d e verificare a mesajului 0x00 – 0xFF

23
Unde:
Statusul sistemului ne va spune dacă sistemul funcționează corect (0x00) sau dacă sistemul a
avut o eroare: de comunicare (eroare de CRC, timeout, etc.), de stare (sistemul e într -o stare în
care nu poate procesa cererea) etc.
Statusul execuției comenzii care va spune dacă funcția a fost terminată cu succes sau eroare și
dacă a avut eroare vom primi un cod ce ne va reprezenta tipul erorii.
Tabelul 3 .20 Valorile date de “ statutul comenzii” implementate în cod
Statusul Numele statusului Descriere
0xA0 Funcție executată cu succes Comanda e corectă și a fost executată
cu succes
0xB0 Eroare de parametri Unul sau mai mulți parametri au valori
incorecte
0xB3 Eroare de lungime Prea puțini sau prea mulți parametri
0xB6 Eroare privind ID -ul comenzi Nu există o comandă cu acest ID
0xE0 Eroare privind Numărul de
pași Numărul de pași nu se încadrează în
limitele primite la inițializare
0xE1 Eroare de inițializare Motorul nu este inițializat

3.3.3. Mișcare Ciclică:
Funcția “Mișcare Ciclică ” va efectua o tranziție între limitele motorului. Înainte de trimiterea
acestei comenzi motorul trebuie inițializat (folosind comanda Inițializare Step per Motor).
Comanda de inititializare ve na da și limitele de tranziție.
Tranziția va muta motorul către limita minimă, va aștepta un timp suficient ca efectul să poată
fi observat, va mișca motorul către limita maximă, va aștepta din nou și va trimite motorul la
limita minimă.
Comanda pe care o vom trimite este următoarea:
Tabelul 3 .21 Formatul comenzii „Mișcare Ciclică”
Index Byte Semnificație Valori Permise
0 ID-ul comenzii – ISM 0xB3
1 ID-ul comenzii – Miscare Ciclică 0x30
2 Indexul motorului 0x00 -0x05
3 Biți de verificare a mesajului 0x00 – 0xFF
Unde:
Indexul motorului -în dataset sunt un număr de 6 motoare aici se va introduce indicele
motorului care poate fi folosit.
Și ne vom aștepta la un răspuns de forma:
Tabelul 3. 22 Formatul de răspuns al comenzii „Mișcare Ciclică”
Index Byte Semnificație Valori Permise
0 Statusul sistemului 0xXX
1 Statusul execuției comenzii Vezi tabelul 3 .23
2 Biți de verificare a mesajului 0x00 – 0xFF
Unde:
Statusul sistemului ne va spune dacă sistemul funcționează corect (0x00) sau dacă sistemul a
avut o eroare: de comunicare (eroare de CRC, timeout, etc.), de stare (sistemul e într -o stare în
care nu poate procesa cererea) etc.

24
Statusul execuției comenzii care va spune dacă funcția a fost terminată cu succes sau eroare și
dacă a avut eroare vom primi un cod ce ne va reprezenta tipul erorii.
Tabelul 3 .23 Valorile date de “Statulul comenzii ” implementate în cod
Statusul Numele statusului Descriere
0xA0 Funcție executată cu succes Comanda e corectă și a fost executată
cu suces
0xB0 Eroare de parametri Unul sau mai mulți parametri au valori
incorecte
0xB3 Eroare de lungime Prea puțini sau prea mulți parametri
0xB6 Eroare privind ID -ul comenzi Nu există o comandă cu acest ID
0xE1 Eroare de inițializare Motorul nu este inițializat

3.3.4. Mișcare Motor la 0:
Funcția “Mișcare Motor la 0” va aduce motorul la poziția 0 . Aceasta este diferită de funcția
“Mișcă Pointer ” deoarece merge pană la limita fizică a motorului, în timp ce funcția “Mișcă
Pointer ” poate avea erori datorate frecărilor. Motorul de va muta către poziția 0 pană când
aceasta va fi atinsă. Acestă comandă necesită reconfigurarea motorelor, așa că pentru a efectua
o altă manevră motorul va trebui reiniițializat (prin comanda “Inițializare Stepper Motor ”).
Înainte de trimiterea acestei comenzi motorul trebuie inițializat (folosind comanda Inițializare
Stepper Motor).

Mesajul pe care il vom transmite va fi de forma:
Tabelul 3 .24 Formatul comenzii „Mișcare Motor la 0”
Index Byte Semnificație Valori Permise
0 ID-ul comenzii – ISM 0xB3
1 ID-ul comenzii – Mișcare Motor la 0 0x10
2 Indexul motorului 0x00 -0x05
3 Biți de verificare a mesajului 0x00 – 0xFF

Unde:
Indexul motorului: aici se va introduce indicele motoruluicare poate fi folosit (în dataset sunt
un număr de 6 motoare cu indezul de la 0 la 5).
Și ne vom aștepta la un răspuns de forma:
Tabelul 3 .25 Forma tul de răspuns al comenzii „Miscare Motor la 0”
Index Byte Semnificație Valori Permise
0 Statusul sistemului 0xXX
1 Statusul execuției comenzii Vezi tabelul 3 .26
2 Biți de verificare a mesajului 0x00 – 0xFF

Unde:
Statusul sistemului ne va spune dacă sistemul funcționează corect ( 0x00) sau dacă sistemul a
avut o eroare: de comunicare (eroare de CRC, timeout, etc.), de stare (sistemul e într -o stare în
care nu poate procesa cererea) etc.
Statusul execuției comenzii care va spune dacă funcția a fost term inată cu succes sau eroare și
dacă a avut eroare vom primi un cod ce ne va reprezenta tipul erorii.

25
Tabelul 3 .26 Valorile date de “Statulul comenzii ” implementate în cod
Statusul Numele statusului Descriere
0xA0 Funcție executată cu succes Comanda e core ctă și a fost executată
cu suces
0xB0 Eroare de parametri Unul sau mai mulți parametri au valori
incorecte
0xB3 Eroare de lungime Prea puțini sau prea mulți parametri
0xB6 Eroare privind ID -ul comenzi Nu există o comandă cu acest ID
0xE1 Eroare de iniț ializare Motorul nu este inițializat

3.3.5. Primește poziția:
Comanda “Primește poziția ” va returna poziția actuală a motorului. Poziția va fi returnată în
număr de pași de la poziția inițială la cea actuală.

Mesajul pe care il vom transmite va fi de forma:
Tabelul 3 .27 Formatul comenzii „Primește poziția”
Index Byte Semnificație Valori Permise
0 ID-ul comenzii – ISM 0xB3
1 ID-ul comenzii – Primește poziția 0x40
2 Indexul motorului 0x00 -0x05
3 Biți de verificare a mesajului 0x00 – 0xFF

Unde:
Indexul moto rului: aici se va introduce indicele motorului care poate fi folosit (în dataset sunt
un număr de 6 motoare cu indexul de la 0 la 5). Trebuie avut în vedere că motorul să fi fost în
prealabil inițializat.

Și ne vom aștepta la un răspuns de forma:
Tabelul 3.28 Formatul de răspuns al comenzii „Primește poziția”
Index Byte Semnificație Valori Permise
0 Statusul sistemului 0xXX
1 Statusul execuției comenzii Vezi tabelul 3 .29
2 Număr de pași MSB 0x00 – 0xFF
3 LSB 0x00 – 0xFF
4 Biți de verificare a mesaju lui 0x00 – 0xFF
Unde:
MSB -Most Significant Byte
LSB-Least Significant Byte
Număr de pași: Numărul de pași efectuați. Trebuie să se încadreze în limitele date la
inițializare.
Statusul sistemului: ne va spune dacă sistemul funcționează corect (0x00) sau dacă sistemul a
avut o eroare: de comunicare (eroare de CRC, timeout, etc.), de stare (sistemul e într -o stare în
care nu poate procesa cererea) etc.
Statusul execuției comenzii: care va spune dacă funcția a fost terminată cu succes sau eroare

26
și dacă a av ut eroare vom primi un cod ce ne va reprezenta tipul erorii.

Tabelul 3.29 Valorile date de “ statutul comenzii” implementate în cod
Statusul Numele statusului Descriere
0xA0 Funcție executată cu succes Comanda e corectă și a fost executată cu
succes
0xB0 Eroare de parametri Unul sau mai mulți parametri au valori
incorecte
0xB3 Eroare de lungime Prea puțini sau prea mulți parametri
0xB6 Eroare privind ID -ul comenzi Nu există o comandă cu acest ID
0xE0 Eroare privind Numărul de
pași Numărul de pași nu s e încadrează în
limitele primite la inițializare
0xE1 Eroare de inițializare Motorul nu este inițializat

3.3.6. Design și implementare
Interfețe publice:
 void ISM_vToolbox(void) e un dispecer, va fi apelat atunci când ECU -ul
primește o comandă cu ID -ul 0xB3. Î n funcție de valoarea celui de -al 2-lea parametru, va apela
alte funcții (private) ale modulului, pentru a realiza funcționalitatea cerută.

Figura 3.9 Diagrama de activitate a funcției “ISM_vToolbox ()”

Variabile:
 static uint8 u8InitializedMotors[6] reține motoarele ce au fost inițializate.
 static const uint32 ISM__au8CCDVandCCDH[6] va reține date ce vor defini
mișcarea pointerului.
 static const uint32 rau32PWMTable[2][128] va defini sensul motorului.
 static const uint32 rau32ZPDTable[16] va da mișcarea pentru comanda „Mișcare
Motor la 0”.
 static uint8 ISM__au8MotorPorts[6] reține porturile pe care sunt motoarele .
 static uint16 ISM__au16MotorSet[6] reține pini pe care sunt motoarele.
 static const uint32 ISM__rau32ParamSet_Motor[9] va reține informații ce trebuie

27
încărcate în ECU pentru a lucra cu acel tip de motor.
 static tstrPozitionlimitation strMotorLimits[5] structura ce reține limitele primite din
comanda de inițializare.

Funcții și variabile statice
 static void ISM__vVariableSet() va efectua setăr i ale motoarelor
 static void ISM__vPMPUpdate() va încărca tabelul de viteză primit ca parametru
(u32TGT_PMP).
 static void ISM__vSetTimer() va seta timer -ul.
 static void ISM__vAsignTable() va încărca tabelul de PWM și „Zero point detection ”
(Mișcare către 0 )
 static void ISM__vInitMotor() va configura pini motorului.
 static void ISM__vInitStepperMotor() va inițializa motorul
 static void ISM__vGlobalManagement() va seta un flag. O dată setat putem face
modificări în setările actuale ale stepper motoarelor.
 static void ISM__vComandManager() va seta un flag. O dată setat motorul va începe
executarea activitatea pentru care au fost făcute setările .
 static void ISM__vMoveAbsolute() va verifica datele primite de comanda „Mișca
Pointer ” și va apela funția ”static voi d ISM__vMove(uint 32 NrStep,uint 8 MotorNumber) ”.
 static void ISM__vMove() va mișca motorul cu un număr de pași primiți ca parametru.
 static void ISM__vSwTimerWait() va așteptă un timp primit ca parametru.
 void ISM__vZPD () va executa acț iunea comenzii „Mișc are motor la 0”
 static void ISM__vParametersUpdate() va seta driverul cu o secvență de date primită
ca parametru (rau 32ParamSet). Setările făcute vor ajuta driverul să lucreze cu un anumit tip de
motor.
 static void ISM__vCyclicSweepID() va verifica paramet ri funcției „Mișcare Ciclică ”
și va executa acțiunea ei.
 static void ISM__GetPozition() va verifica parametri funcției „Primește poziția ” și va
returna poziția actuală a motoarelor.
 static void ISM__vMove_to_0() va verifica parametri primiți de comanda „Mișcare
Motor la 0”.

Variabile globale (definite în alte module) folosite:
 EOLOS_nFrameIn.by – Buffer de intrare: aici loader -ul pune octeții citiți de pe
bus.
 EOLOS_nFrameOut.by – Buffer de ieșire – aici modulul scrie codul de eroare
care trebuie returnat pe bus (dacă e cazul) precum și eventualele date adiționale.

Funcții care implementează comenzile modulului:

28
 static void ISM__vInitStepperMotor()

Figura 3.10 Diagrama de activitate a funcției “ISM__vInitStepperMotor()”

 static void ISM__vCyclicSw eepID()

Figura 3.11 Diagrama de activitate a funcției “ISM__vCyclicSweepID()”

 static void ISM__vMoveAbsolute(uint 32 u32NrStep,uint 8 u8MotorNumber)

Figura 3.12 Diagrama de activitate a funcției “ISM__vMoveAbsolute()”

 static void ISM__vMove_to_0(uint 8 u8MotorNumber)

Figura 3.13 Diagrama de activitate a funcției “ISM__vMove_to_0()”

29
 static void ISM__GetPozition()

Figura 3.14 Diagrama de activitate a funcției “ISM__GetPozition()”

3.3.7. Testarea
Pentru testarea acestui modul vom adăuga câteva teste care să acopere toate cerințele
Tabelul 3 .30 Testare ISM
ID Cerința la
care
trebuie să
răspundă Starea
inițială Acțiune Reacție așteptată Reacție
efectivă Rezultat
1 Inițializare
pointeri După
reset B3 00 03 00 FF 00
FF 00 FF 00 FF 00
FF 00 FF 00 FF 00
FF 00 FF 00 FF 00
FF 00 FF ECU -ul răspunde
pozitiv (codul 0xA0)
2 Mutare
pointeri După
Init
motor B3 20 02 00 0F Ne vom aștepta ca
motorul să parcurgă
15 micro pași *
3 Mutare
pointeri După
Init
motor B3 20 02 00 FF Ne vom aștepta ca
motorul să parcurg ă
255 micro pași *
4 Doar
motoarele
inițializate
trebuie să
execute
comenzile După
Init
motor B3 20 03 00 FF ECU -ul răspunde
pozitiv (codul 0xE1)
5 Testarea
limitelor
pointerilor După
Init
motor B3 30 03 Ne vom aștepta să
observam o tranziție
completa a
pointerului
6 Testarea
limitelor
pointerilor După
Init
motor B3 30 03 00 Ne vom aștepta să
primim un mesaj de
eroare( 00 B3)
* Se va nota dacă motorul a făcut un număr de pași observabili iar pentru acuratețe
se poate folosi funcția de citire a Nu mărului de pași realizați (Primește poziția).
Descrierea coloanelor tabelului de mai sus:
Starea inițială descrie starea sistemului dinaintea executări testului
Acțiune Acțiunea executată supra sistemului (în cazul de față, ce comandă EOL vom trimite)

30
Reac ție așteptată evenimentul la care ne așteptăm după efectuarea testului
Reacția efectivă reacția pe care a avut -o
Rezultat test valori posibile: OK/NOK; dacă reacția așteptată și reacția efectivă sunt identice,
rezultatul testului e OK, în caz contrar îl vo m nota cu NOK.
Pentru a ajunge în starea “După reset ” se vor efectua următori pași:
– Se va efectua un reset fizic (se va întrerupe alimentarea cu energie electrică și se va
restaura) sau unul software (printr -o comandă specifică)
– Se va activa EOL (se va tr imite un mesaj specific)
– Se va încărca imaginea.

3.4. Modulul TFT
Acest modul se oc upa cu testarea display -ului. Di splay -ul este ecranul alb -negru prezent pe
cluster. Modulul este capabil să aprindă display -ul și să deseneze anumite imagini pentru a
demonstra că toți pixeli de pe ecran pot fi scriși. Ecranul este alb -negru având o paletă de 16
nuanțe de gri.
Toate operațiile se vor face prin trimiterea de comenzi și date către driver -ul dedicat display –
ului. [6] [8]
Acest modul are 5 comenzi:
3.4.1. Curățare ecran:
Această comandă va colora uniform ecranul cu o culoare primită în comandă.
Tabelul următor descrie conținutul comenzii care trebuie transmisă cluster -ului.
Tabelul 3 .31 Formatul comenzii „Curățare ecran”
Index Byt e Semnificație Valori Permise
0 ID-ul comenzii – TFT 0xCA
1 ID-ul comenzii – Curățare ecran 0x01
2 Nuanța de gri 0x00 – 0x0F
3 Biți de verificare a mesajului 0x00 – 0xFF

Unde:
Nuanța de gri: Nuanța de gri codificată în hexazecimal (unde 0f înseamnă alb și 00 reprezintă
negru).
Și ne vom aștepta la un răspuns de forma:
Tabelul 3 .32 Formatul de răspuns al comenzii „Curățare ecran”
Index Byte Semnificație Valori Permise
0 Statusul sistemului 0xXX
1 Statusul execuției comenzii Vezi tabelul 3 .33
2 Biți d e verificare a mesajului 0x00 – 0xFF

Unde:
Statusul sistemului ne va spune dacă sistemul funcționează corect (0x00) sau dacă sistemul a
avut o eroare: de comunicare (eroare de CRC, timeout, etc.), de stare (sistemul e într -o stare în
care nu poate proces a cererea) etc.
Statusul execuției comenzii care ne va spune dacă funcția a fost terminată cu succes sau eroare
și dacă a avut eroare vom primi un cod ce va reprezenta tipul ei.

31
Tabelul 3 .33 Valorile date de “ Statutul comenzii” implementate în cod
Statusul Numele statusului Descriere
0xA0 Funcție executată cu succes Comanda e corectă și a fost executată
cu succes
0xB0 Eroare de parametri Unul sau mai mulți parametri au valori
incorecte
0xB3 Eroare de lungime Prea puțini sau prea mulți parametri
0xB6 Eroare privind ID -ul comenzii Nu există o comandă cu acest ID

3.4.2. Desenare pixel:
Aceasta comandă va desena un pixel pe ecran cu poziția și culoarea transmise prin comanda.
Poziția se va specifica în funcție de axele de coordonate.
Tabelul următor descrie c onținutul comenzii care trebuie transmisă cluster -ului.
Tabelul 3 .34 Formatul comenzii „Desenare pixel“
Index Byte Semnificație Valori Permise
0 ID-ul comenzii – TFT 0xCA
1 ID-ul comenzii – Desenare pixel 0x01
2 Coordonatele pe axa X MSB 0x0000 –0x00F0 3 LSB
4 Coordonatele pe axa Y MSB 0x0000 –0x0140 5 LSB
6 Nuanța de gri 0x00 – 0x0F
7 Biți de verificare a mesajului 0x00 – 0xFF

Unde:
MSB -Most Significant Byte
LSB -Least Significant Byte
Coordonatele pe axa X: Coordonatele pe axa orizontală.
Coord onatele pe axa Y: Coordonatele pe axa verticală.
Nuanța de gri: Nuanța de gri codificată în hexazecimal (unde 0f înseamnă alb și 00 reprezintă
negru).
Și ne vom aștepta la un răspuns de forma:
Tabelul 3 .35 Formatul de răspuns al comenzii „Desenare pixel“
Index Byte Semnificație Valori Permise
0 Statusul sistemului 0xXX
1 Statusul execuției comenzii Vezi tabelul 3 .36
2 Biți de verificare a mesajului 0x00 – 0xFF

Unde:
Statusul sistemului ne va spune dacă sistemul funcționează corect (0x00) sau dacă sist emul a
avut o eroare: de comunicare (eroare de CRC, timeout, etc.), de stare (sistemul e într -o stare în
care nu poate procesa cererea) etc.
Statusul execuției comenzii care ne va spune dacă funcția a fost terminată cu succes sau eroare
și dacă a avut eroa re vom primi un cod ce va reprezenta tipul ei.

32
Tabelul 3 .36 Valorile date de “ Statutul comenzii” implementate în cod
Statusul Numele statusului Descriere
0xA0 Funcție executată cu succes Comanda e corectă și a fost executată cu
succes
0xB0 Eroare de parametri Unul sau mai mulți parametri au valori
incorecte
0xB3 Eroare de lungime Prea puțini sau prea mulți parametri
0xB6 Eroare privind ID -ul comenzii Nu există o comandă cu acest ID

3.4.3. Desenează imagine:
Aceasta comandă va desena o imagine, primită pr intr-o hartă de biți, la anumite coordinate date
și cu folosind două culori primite ca parametru.
Pentru a realiza harta de biți se va proceda astfel: fiecare pixel va fi codificat în binar (valoarea
1 pentru culoarea desenului și valoarea 0 pentru culoare a fundalului), valorile rezultate de vor
codifica în hexa -zecimal și vor fi transmise ca parametri (ex. Imaginea 2.18 ). Tabelul de biți
are o mărime fixă de 8 pixeli pe orizontală și 8 pixeli pe verticală.

Figura 3.15 Cum se obține harta de biți

Tabe lul următor descrie conținutul comenzii care trebuie transmisă cluster -ului.
Tabel ul 3.37 Formatul comenzii “Desenează imagine”
Index Byte Semnificație Valori Permise
0 ID-ul comenzii – TFT 0xCA
1 ID-ul comenzii – Desenează imagine 0x02
2 Coordonatele pe axa X MSB 0x0000 –0x00F0 3 LSB
4 Coordonatele pe axa Y MSB 0x0000 –0x0140 5 LSB
6 Nuanța de gri a desenului 0x00 – 0x0F
7 Nuanța de gri a fundalului 0x00 – 0x0F
8
Harta de biți Bit 1 0x00 – 0xFF
9 Bit 2 0x00 – 0xFF
10 Bit 3 0x00 – 0xFF
11 Bit 4 0x00 – 0xFF
12 Bit 5 0x00 – 0xFF
13 Bit 6 0x00 – 0xFF
14 Bit 7 0x00 – 0xFF
15 Bit 8 0x00 – 0xFF

33
16 Biți de verificare a mesajului 0x00 – 0xFF
Unde:
Coordonatele pe axa X: Coordonatele pe axa orizontală.
Coordonatele pe axa Y: Coordonatele pe axa verticală.
MSB -Most Significant Byte
LSB -Least Significant Byte
Nuanța de gri: Nuanța de gri codificată în hexazecimal (0F = alb și 00 = negru).
Și ne vom aștepta la un răspuns de forma:
Tabelul 3 .38 Formatul de răspuns al comenzii „Desenează imagine”
Index Byte Semnificație Valori Permise
0 Statusul sistemului 0xXX
1 Statusul execuției comenzii Vezi tabelul 3 .39
2 Biți de verificare a mesajului 0x00 – 0xFF
Unde:
Statusul sistemului ne va spune dacă sistemul funcționează corect (0x00) sau dacă sis temul a
avut o eroare: de comunicare (eroare de CRC, timeout, etc.), de stare (sistemul e într -o stare în
care nu poate procesa cererea) etc.
Statusul execuției comenzii care ne va spune dacă funcția a fost terminată cu succes sau eroare
și dacă a avut ero are vom primi un cod ce va reprezenta tipul ei.
Tabelul 3 .39 Valorile date de “ Statutul comenzii” implementate în cod
Statusul Numele statusului Descriere
0xA0 Funcție executată cu succes Comanda e corectă și a fost executată
cu succes
0xB0 Eroare de parametri Unul sau mai mulți parametri au valori
incorecte
0xB3 Eroare de lungime Prea puțini sau prea mulți parametri
0xB6 Eroare privind ID -ul comenzii Nu există o comandă cu acest ID

3.4.4. Desenează imagine periodic:
Aceasta comandă va desena o imagine, p rimita printr -o harta de biți cu niște culori primite ca
parametru. Imaginea va fi desenată repetitiv pe o suprafață cuprinsă intre coordonatele date.
Pentru a realiza harta de biți se va proceda astfel: unde fiecare pixel va fi codificat în binar
(valoar ea 1 pentru culoarea desenului și valoarea 0 pentru culoarea fundalului), valorile
rezultate de vor codifica în hexa -zecimal și vor fi transmise ca parametri (ex. Imaginea 2.20).
Tabelul de biți are o mărime fixă de 8 pixeli pe orizontală și 8 pixeli pe ve rticală. Imaginile vor
fi desenate de la stânga la dreapta și de sus în jos (vezi imaginea 2.21).

Figura 3.16 Cum se obține harta de biți pentru desenare periodică

34

Figura 3.17 Cum se desenează imaginea periodică pe display

Tabelul următor descrie con ținutul comenzii care trebuie transmisă cluster -ului.
Tabelul 3 .40 Formatul comenzii “Desenează imagine periodic”
Index Byte Semnificație Valori Permise
0 ID-ul comenzii – TFT 0xCA
1 ID-ul comenzii – Desenează imagine periodic 0x03
2 Coordonata inițială pe axa X MSB 0x0000 –0x00F0 3 LSB
4 Coordonata finală pe axa X MSB 0x0000 –0x0140 5 LSB
6 Coordonata inițială pe axa Y MSB 0x0000 –0x00F0 7 LSB
8 Coordonata finală pe axa Y MSB 0x0000 –0x0140 9 LSB
10 Nuanța de gri a desenului 0x00 – 0x0F
11 Nuanța de gri a fundalului 0x00 – 0x0F
12
Harta de biți Bit 1 0x00 – 0xFF
13 Bit 2 0x00 – 0xFF
14 Bit 3 0x00 – 0xFF
15 Bit 4 0x00 – 0xFF
16 Bit 5 0x00 – 0xFF
17 Bit 6 0x00 – 0xFF
18 Bit 7 0x00 – 0xFF
19 Bit 8 0x00 – 0xFF
20 Biți de verificar e a mesajului 0x00 – 0xFF
Unde:
Coordonatele pe axa X: Coordonatele pe axa orizontală.
Coordonatele pe axa Y: Coordonatele pe axa verticală.
Nuanța de gri: Nuanța de gri codificată în hexazecimal (0F = alb și 00 = negru).
MSB -Most Significant Byte
LSB -Least Significant Byte

35
Și ne vom aștepta la un răspuns de forma:
Tabelul 3 .41 Formatul de răspuns al comenzii “Desenează imagine periodic”
Index Byte Semnificație Valori Permise
0 Statusul sistemului 0xXX
1 Statusul execuției comenzii Vezi tabelul 3 .42
2 Biți de verificare a mesajului 0x00 – 0xFF
Unde:
Statusul sistemului ne va spune dacă sistemul funcționează corect (0x00) sau dacă sistemul a
avut o eroare: de comunicare (eroare de CRC, timeout, etc.), de stare (sistemul e într -o stare în
care nu p oate procesa cererea) etc.
Statusul execuției comenzii care ne va spune dacă funcția a fost terminată cu succes sau eroare
și dacă a avut eroare vom primi un cod ce va reprezenta tipul ei.
Tabelul 3 .42 Valorile date de “ Statutul comenzii” implementate în cod
Statusul Numele statusului Descriere
0xA0 Funcție executată cu succes Comanda e corectă și a fost executată
cu succes
0xB0 Eroare de parametri Unul sau mai mulți parametri au valori
incorecte
0xB3 Eroare de lungime Prea puțini sau prea mulți param etri
0xB6 Eroare privind ID -ul comenzii Nu există o comandă cu acest ID

3.4.5. Desenare dreptunghi:
Aceasta comandă va desena un dreptunghi pe ecran.
Tabelul următor descrie conținutul comenzii care trebuie transmisă cluster -ului.
Tabelul 3 .43 Mesajul comenzii “Desenare dreptunghi”
Index Byte Semnificație Valori Permise
0 ID-ul comenzii – TFT 0xCA
1 ID-ul comenzii – Desenare pixel 0x01
2 Coordonatele pe axa X MSB 0x0000 –0x00F0 3 LSB
4 Coordonatele pe axa Y MSB 0x0000 –0x0140 5 LSB
6 Lățimea MSB 0x0000 –0x00F0 7 LSB
8 Înălțimea MSB 0x0000 –0x0140 9 LSB
10 Nuanța de gri 0x00 – 0x0F
11 Umplere 0x00 – 0x01
12 Biți de verificare a mesajului 0x00 – 0xFF

Unde:
Coordonatele pe axa X: Coordonatele inițiale pe axa orizontală a dreptunghiului.
Coordonate le pe axa Y: Coordonatele inițiale pe axa vertical dreptunghiului.
Lățimea și Înălțimea : Sunt date în număr de pixeli și reprezintă mărimea dreptunghiului.
Nuanța de gri: Nuanța de gri codifi cată în hexazecimal (0F = alb și 00 = negru).

36
Umplere: Pentru val oarea 0 dreptunghiul va fi umplut cu culoare, iar pentru valoarea 1 vor fi
desenate doar marginile dreptunghiului.
MSB -Most Significant Byte
LSB -Least Significant Byte

Și ne vom aștepta la un răspuns de forma:
Tabelul 3 .44 Formatul de răspuns al comenzii “Desenare dreptunghi”
Index Byte Semnificație Valori Permise
0 Statusul sistemului 0xXX
1 Statusul execuției comenzii Vezi tabelul 3 .45
2 Biți de verificare a mesajului 0x00 – 0xFF

Unde:
Statusul sistemului ne va spune dacă sistemul funcționează cor ect (0x00) sau dacă sistemul a
avut o eroare: de comunicare (eroare de CRC, timeout, etc.), de stare (sistemul e într -o stare în
care nu poate procesa cererea) etc.
Statusul execuției comenzii care ne va spune dacă funcția a fost terminată cu succes sau er oare
și dacă a avut eroare vom primi un cod ce va reprezenta tipul ei.
Tabelul 3.45 Valorile date de “ Statutul comenzii” implementate în cod
Statusul Numele statusului Descriere
0xA0 Funcție executată cu succes Comanda e corectă și a fost executată
cu succes
0xB0 Eroare de parametri Unul sau mai mulți parametri au valori
incorecte
0xB3 Eroare de lungime Prea puțini sau prea mulți parametri
0xB6 Eroare privind ID -ul comenzii Nu există o comandă cu acest ID

3.4.6. Design și implementare
Interfețe publice:
 void TFT_vToolbox(void): e un dispecer, va fi apelat atunci când ECU -ul
primește o comandă cu ID -ul 0xCA. În funcție de valoarea celui de -al 2-lea parametru, va apela
alte funcții (private) ale modulului, pentru a realiza funcționalitatea cerută.

Variabile : Nu avem
Funcții și variabile statice

37

Figura 3.18 Diagrama de activitate a funcției “TFT_vToolbox ()”

 static void TFT_vSwTimerWait() va așteptă un număr de secunde
primit ca parametru
 void TFT__vSendByte() va trimite un bit către display
 void TFT__v Init() va inițializa display -ul și apelează funcția TFT_
ClearDisplay ()
 void TFT__vClearDisplay() va curata uniform ecranul
 void TFT__vClearDisplayVerify() va verifica parametri pentru
comanda „Curata ecran ”
 void TFT__vSetPixelVerify() va verifica para metri comenzii
„Desenează pixel ”
 void TFT__vSetPixel() va colora un pin pe display
 void TFT__vdrawBitmapPeriodically() va verifica parametri
comenzii „Desenează imagine periodica ” și va desena imaginile
 void TFT__vdrawBitmap() va verifica parametri come nzii „Desenează
imagine ” și va desena imaginea
 void TFT__vDrawRectangle() va verifica parametri comenzii
„Desenează dreptunghi ” și va desena imaginea
Variabile globale (definite în alte module) folosite:
 EOLOS_nFrameIn.by – Buffer de intrare: aici loader -ul pune octeții citiți de pe
bus
 EOLOS_nFrameOut.by – Buffer de ieșire – aici modulul scrie codul de eroare
care trebuie returnat pe bus (dacă e cazul) precum și eventualele date adiționale

Funcții care implementează comenzile modulului:
 static void TFT__ vClearDisplayVerify()

38

Figura 3.19 Diagrama de activitate a funcției “TFT__vClearDisplayVerify()”

 static void TFT__vSetPixelVerify (uint 32 u32XCoordonate,uint 32 u32YCoordonate,
uint16 u16GrayColor)

Figura 3.20 Diagrama de activitate a funcției “TFT__v SetPixelVerify()”

 static void TFT__vdrawBitmapPeriodically()

Figura 3.21 Diagrama de activitate a funcției “TFT__vdrawBitmapPeriodically ()”

 static void TFT__vdrawBitmap()

Figura 3.22 Diagrama de activitate a funcției “TFT__vdrawBitmap ()”

 static vo id TFT__vDrawRectangle()

Figura 3.23 Diagrama de activitate a funcției “TFT__vDrawRectangle ()”

39

3.4.7. Testarea
Pentru testarea acestui modul vom adăuga câteva teste care să acopere toate cerințele
Tabelul 3 .46 Testare TFT
ID Cerința la care
trebuie să
răspundă Starea
inițială Acțiune Reacție așteptată Reacție
efectivă Rezultat
1 Scriere tuturor
pixelilor După
reset CA 00 0F Ne vom aștepta să
observăm fiecare
pixel colorat cu
aceeași culoare
2 Scrierea unui
pixel După
reset CA 01 07 00
23 00 A0 Ne vom a ștepta să
observăm un pixel
colorat cu culoarea
aleasa
3 Scrierea unui
sablon După
reset CA 02 00 00
00 00 00 0F
42 A5 99 81
42 24 18 18 Ne vom aștepta ca
șablonul să apară
pe display
4 Scrierea unui
sablon pe
întregul ecran După
reset CA 03 00 00
00 F0 00 00
01 40 00 0F
42 A5 99 81
42 24 18 18 Ne vom aștepta ca
șablonul să apară
pe display în mod
repetat
5 Desenare linii După
reset CA 04 00 30
00 30 00 50
00 50 00 00 Ne vom aștepta să
observăm linia
desenată pe display
6 Scriere tuturor
pixelil or După
reset CA 00 0F 01 ECU -ul răspunde
negativ (codul
0xB3)
7 Scrierea unui
pixel După
reset CA 01 10 00
23 00 A0 ECU -ul răspunde
negativ (codul
0xB0)
8 Scrierea unui
șablon După
reset CA 02 00 F1
00 00 00 0F
42 A5 99 81
42 24 18 18
ECU -ul răspun de
negativ (codul
0xB0)

9 Scrierea unui
șablon pe
întregul ecran După
reset CA 03 00 00
00 F0 00 00
01 40 00 0F
42 A5 99 81
42 24 18 18
01 ECU -ul răspunde
negativ (codul
0xB3)

10 Desenare linii După CA 04 00 03 ECU -ul răs punde

40
reset 00 03 00 90
00 90 00 negativ (codul
0xB3)

Descrierea coloanelor tabelului de mai sus:
Starea inițială: descrie starea sistemului dinaintea executări testului.
Acțiune Acțiunea executată supra sistemului (în cazul de față, ce comandă EOL vom trimite).
Reacție așteptat ă evenimentul la care ne așteptăm după efectuarea testului.
Reacția efectivă reacția pe care a avut -o, dacă a avut.
Rezultat test : dacă reacția așteptată și reacția efectivă sunt identice, rezultatul testului e OK,
în caz contrar îl vom nota cu NOK.
Pentru a ajunge în starea “După reset ” se vor efectua următorii pași:
– Se va efectua un reset fizic (se va întrerupe alimentarea cu energie electrică și se va
restaura) sau unul software (printr -o comandă specifică)
– Se va activa EOL (se va trimite un mesaj spec ific)
– Se va încărca imaginea.

3.5. Automatizare
Gradul de automatizare a testelor EOL depinde numai de numărul proiectelor si accesul la
hardware necesar. Pentru automatizarea testelor se folosește un modul de relee. Numărul
releelor afectează proporțional num ărul proiectelor ce pot fi automatizate. De exemplu cu un
modul cu 4 relee se poate automatiza testele pentru 4 proiecte diferite, cât timp cu un modul de
16 relee, numărul urca la 16.

Figura 3.24 Modul 4 relee 12V cu port USB pentru conexiune PC

Modulu l de relee este conectat pe o parte la surs ă, iar de pe alta parte fiecare releu este conectat
la câte un cluster de bord , comandând când care cluster de bord este alimentat.
Pe partea de software, aplicația de testare folosește batch -uri pentru chemarea funcțiilor de
comand ă a modulului de relee furnizate de producător.

41
Capitolul 4
4. Concluzii și dezvoltări pe viitor
4.1. Concluzii
Din această lucrare am învățat multe despre procesul de dezvoltare al unui produs software.
Studiind procesele de dezvoltare softwa re am înțeles importanța pașilor ce trebuie urmăriți și
succesiunea în care ceștia se realizează. De asemenea din acest studio am înțeles importanța
documentației proiectului. Documentele au rolul de a le spune celor ce nu cunosc programul
aplicației cum s ă lucreze cu programul a.î. să execute acțiunea dorită. Când proiectul ajunge la
client documentația, trimisă o dată cu el. trebuie să descrie cât mai bine cum trebuie folosit
astfel fiind evitată ajungerea într -un impas. Pentru cei ce cunosc programarea d ocumentația
trebuie să îi ajute la înțelegerea cât mai rapidă a metodelor folosite.
Am învățat diferența dintre un cod al cărui design se face înainte, a.î. să ai o înțelegere clară a
ceea ce trebuie implementat, și un cod care se concepe o dată cu scriere a lui. Prima procedură
iți permite să scrii un cod curat și reduce riscul de greșeli. Procedura în care codul este scris
fără un design prestabilit poate duce la un impas. Acesta procedură generează erori și poate
duce la rescrierea codului de mai multe or i.
Testele sunt de asemenea necesare și au menirea de a verifica toate funcționalitățile din cod.
Este indispensabilă verificarea datelor de intrare și semnalarea problemelor corespunzător.
Fiecare valoare a datelor de intrare este verificată a.î. nici o v aloare greșită să nu se poată
accepta și că nu execute nici o comandă, comandă ce ar putea strica sistemul.
Studiul principal al lucrări de licență au fost microcontrolerele. Despre acestea am învățat: cum
se calculează o adresă, cum se accesează aceasta s au cum se modifică aceasta. O dată cu acestea
am învățat despre semnale, despre memorie (cum este structurată, câte tipuri de memorie există
și care sunt diferențele etc.)
4.2. Dezvoltări ulterioare
Deși în acest proiect am realizat o bună parte din testele nec esare producerii unui cluster. Pe
viitor aș dori să adaug funcționalități noi a.î. într -o zi proiectul să poată fi adăugat unei lini de
producție. Modulele pe care le -am creat deja ar mai putea suporta modificări a.î. să cuprindă
mai multe funcționalități ale dispozitivelor.
Domeniu în care se înscrie proiectul de licență este într -o continuă schimbare. Mereu și mereu
vor apărea dispozitive noi. Aceste dispozitive se schimbă din necesitatea ca ele să aducă o cât
mai mare funcționalitate. Noile mecanisme vor diferi, mai mult sau mai puțin, în funcționalitate
decât precedentele lor. Pe viitor o dată cu apariția unor tehnologi noi, acestea vor fi adăugate în
proiect .
Lucrarea mea se îndreaptă către un anumit tip de procesor și de hardware (cele pe care am
lucrat) dar cum tehnologia e mereu în schimbare și programul realizat de mine trebuie să fie cât
mai versatil. Pe viitor voi analiza și alte tipuri de clustere de bord a.î. să pot modifica programele
pentru a se potrivi mai multor tipuri de hardware . Prin acesta modificare voi încerca să păstrez
o simplitate a utilizării comenzilor.

42
Bibliografie
[1] http://www.britannica.com/technology/automobile/History -of-the-automobile
[2] Mark Utting și Bruno Legeard: Practical model -based testing Editia 1 Editur a: Morgan
Kaufmann
[3] EOL_protocol.doc al firmei Continental Automotive
[4] Jeffrey C. Carver: Software Engineering for Science Publicat de IEEE volumul 18 an 2016
[5] Dr. Richard Turner : Toward Agile Systems Engineering Processes Publicat de CrossTalk
Volume 20 and 2007
[6] Spe cificațiile procesorului JCP2016 LL_HL ale firmei Continental
[7] Stuart Ball: Analog Interfacing to embedded Microprocessors. Real World Design Editura
Newnes, An 2001, Loc Boston, Oxford, Auc kland
[8] Robert A. Street : Thin-Film Transist ors An 2009 Journal: Advanced materials
[9] Cooke P. : An Introduction to Microcomputers Journal: Electronics + power Volumul: 23
An 1977
[10] https://en.wikipedia.org/wiki/Automation#Advantages_and_disadvantages
[11] https://ro.wikipedia.org/wiki/Automatiz are
[12] Ion Rares Stanciu și Ciprian Șorândaru : Instrumentaie virtuala, automatizari si control cu
calculatorul An 2015