Cercetări Privind Calibrarea Motorului Termic Si Electric Pentru Un Vehicul Hybrid Dacia Duster

Cercetări privind calibrarea motorului termic si electric pentru un vehicul hybrid Dacia Duster

1.Introducere

În ceea ce privește evoluția software-ului în sectorul autovehiculelor rutiere pentru a controla diferite funcționalități și pentru a adăuga unele noi , Denso a realizat un studiu care tratează 3 mari categorii [1]:

 Mediul inconjurător:

Reducerea emisiilor poluante și a consumului de combustibil, pentru a preveni încalzirea globală.

Dezvoltarea autovehiculelor hibride și electrice;

Favorizarea întreținerii unui mediu ,prietenos’ cu pământul;

Siguranța traficului :

Dezvoltarea unor sisteme inteligente ce asistă conducătorul auto în timpul deplasării sale;

Reducerea numărului de accidente;

Îmbunătățirea siguranței pasive și active prin cercetări în domeniu.

Dezvoltarea societații în viitor

Utilizarea vehiculelor de tip PHV(Plug–in Hybrid vehicle) sau EV(Electric Vehicle)

Implicarea cât mai redusă a conducătorului asupra autovehiculului.

Utilizarea dispozitivelor și funcționalităților legate prin rețea “broadband”;

Conducerea semiautomată a autovehiculelor cu ajutorul legăturii cu infrastructura(vehicul-vehicul sau drum-vehicul)

În figura următoare vor fi prezentate tendințele prezentate mai sus:

Fig 1.1 – Mediul înconjurător – nivel global (încălzirea globală și măsuri de combatere)

Fig.1.2 – Istoria și zonele de aplicabilitate a sistemelor electronice

În cele două figuri menționate mai sus se poate observa progresul tehnologiei electronice în ceea ce privește diferitele funcționalități și anumitele strategii care pot fi controlate și monitorizate cu ajutorul acestor tipuri de calculatoare specifice fiecărui sistem aflat pe autovehicul.

1.2. Unitatea electronică de control a motorului unui autovehicul

Poate fi definit ca un sistem activ care transformă acțiunea conducătorului auto într-o stare de funcționare a grupului motopropulsor ,dar în același timp ținând cont de toate acțiunile și reglementările (emisii – securitate – zgomot).

Figura 1.3 Acțiunea conducătorului auto asupra grupului motopropulsor

Electronic Computer Unit sau ECU (Unitate de control electronic) este o placă electronică care controlează acționări electronice, c de exemplu controlează și comandă cantitatea de combustibil,aer,necesare unui motor pentru o bună funcționare. Acesta este alcătuit dintr-o placă electronică cu circuite integrate montate într-o carcasă formată din microprocesoare,unităti de memorie,convertor analog-digital.

Convertoare analogice-digitale :

Convertorul analog-digital transformă valorile transmise de către senzori,valori de tensiune în anumite limite în format digital pe un anumit număr de biți,deoarece calculatorul primește doar date în format digital.

Convertoare digital-analogice :

Convertorul digital-analogic are rolul de a transforma datele cu format digital în analogic sub formă de valori de tensiune ce sunt transmise către senzori.

Rolul acestui tip de calculator este de a comanda cantitatea de combustibil care pătrunde în camerele de ardere, favorizând aprinderea amestecului aer-combustibil și toate acestea ținând cont de viteza, temperatura motorului și a mediului ambiant,și de aerul aspirat de motor. ECU primește toate datele de la senzorii care au diferite poziții și le utilizează ca parametrii în calculul ecuațiilor,iar rezultatul îl utilizează pentru a produce alte date de ieșire care vor comanda mecanismele asupra cărora se acționează.Exemplu de astfel de intrări și ieșiri[2]:

Figura 1.4 Preluarea datelor de intrare și comandarea detelor de ieșire de către ECU

Odată cu avansarea tehnologiei ECU-urile sunt îmbunătățite cu un ‘’sistem cu inteligență proprie’’ denumit în limba engleză Embeded System,care constă dintr-un computer separat.Dimensiunea acestuia variază de la un circuit integrat cu un microprocesor până la sisteme multifuncționale.

Programarea sau reprogramarea ECU-ului se realizează prin folosirea memoriei ROM si a memoriei flash.[3]Pentru ca un ECU să fie funcțional acesta trebuie să aibă instalat un software care să fie dezvoltat ,adaptat cerințelor și funcționalităților în funcție de autovehiculul pe care urmează să fie utilizat.

Există mai mulți furnizori ce fabrică astfel de calculatore si anume:Bosch ,Continental, Valeo, care sunt în stransă legătură cu cerințele clientului,Renault,deoarece software-ul este făcut în mare parte de către acesta.

1.3. Principalele caracteristici pentru controlul unui motor termic ale unor sisteme de software integrate

Cu ajutorul controlului electronic,motoarele cu ardere internă au evoluat în privința reducerii emisiilor poluante,ceea ce a dus la creșterea costului de producție al autovehicului datorită numărului și complexității crescute a sistemelor auxiliare necesare motoarelor cu ardere internă,dar odată cu acestea au crescut și cerințele softului folosit pentru controlul motor.

În figura 1.3 este prezentat controlul cu ajutorul calculatorului motor (Engine control Unit – unitate electronică de control a motorului):

Fig.1.5 Sistem de control pentru un motor diesel – injectie „common rail”

În imagine putem observa unitatea electronică de control denumită ECU (Electronic Control Unit),aceasta este un calculator de mici dimensiuni ce controlează si supraveghează diferite sisteme și subsisteme ale unui autovehicul, de exemplu:motorul,cutia de viteze,airbag-urile,reglarea scaunelor).

Pentru a înțelege mai bine funcționarea calculatorului motor și modul în care el reglează,optimizează și monitorizează componentele unui subsistem vom prezenta o imagine clară în cele ce urmează.

Fig. 1.6 – Sistemul de injecție diesel common rail –controlat cu ajutorului calculatorului motor

În imaginea de mai sus se poate observa cum unitatea de control își obține datele de intrare de la toți senzorii aflați pe vehicul (debitmetru de aer, senzor de poziție clapetă de accelerație, senzor de presiune în galeria de admisie, senzor lambda, senzor poziție arbore cotit) și astfel poate interveni asupra sistemului de injecție (pompa de injecție, injectoarele, supapele).

Sistemul Common rail sau sistemul de injecție cu rampă comună,cu acumulator de înaltă presiune, este singurul sistem unde presiunea este generată independent de injecție,iar injectorul în acest fel este întotdeauna alimentat cu motorină la presiune înaltă și timpul și durata injecției este controlată de către calculatorul motorului,dar mai controlează și presiunea din rampă cu ajutorul senzorului de presiune calculează pierderea de combustibil și activează pompa de înaltă presiune pentru a reface presiunea din rampă [5].

Odată prezentate cele două sisteme de injecție controlate cu ajutorul unității controlului motorului,putem creiona câteva funcții pe care le poate îndeplini ECU:

Acesta în funcție de temperatura combustibilului,a aerului,și a motorului poate să corecteze cantitatea de combustibil injectată ceea ce duce la reducerea noxelor.Mai poate îndeplini următoarele funcții:controlează debitul de pornire,controlul funcționării uniforme,controlul momentului de inițiere a injecției.

Funcția de avarie denumită ,limp home’ este foarte importantă deoarece in momentul cand ECU detectează o defecțiune imediat reduce sarcina maxima și utilizează o valoare alternative pentru senzorul care nu mai funcționează.

Cruise control sau tempomatul,oferă conducătorului auto posibilitatea de a seta viteza de rulare dorită.

Recircularea controlată a gazelor din galeria de evacuare – Acest lucru reduce temperaturile de ardere și astfel este redusă și cantitatea de oxizi de azot

1.4. Principalele caracteristici pentru controlul unui motor electric ale unor sisteme de software integrate.

Figura 1.7 Datele transmise către ECM

Avem aici o lista cu mesajele calculatorului de DCDC, putem observa ca acesta acorda o atentie speciala citirii curentilor inainte si dupa convertor pentru a asigura transferul corect de energie dintre cele 2 baterii.

Figura1.8 Sistemul de management al bateriei

Putem observa aici o lista a mesajelor care au fost modelizate din BMS. Deși unele mesaje au fost transmise ca niște constante în mod default cum ar fi HVBatteryTemp transmis la 22 de grade sau indicatori de failure care indică că nu există probleme, acestea pot fi modificate de catre validatori pentru a verifica daca ECM-ul ia deciziile necesare in anumite scenarii.

Am să menționez una din ele, spre exemplu UserSOC este mesajul care spune ECM-ului gradul de încarcare a bateriei de 48V, inițial transmiteam exact gradul de încarcare calculat de modelul AMESim, dar în realitate calculatorul de BMS va transmite 0% daca bateria este sub 20% SOC si 100% daca este peste 90% tocmai pentru a evita o descarcare prea mare a bateriei sau o supraîncarcare.

Odată cu modificarea acestui mesaj au trebui modificate în acest sens si cele de AvailablePower și GeneratedPower (Puterea disponibil pentru cuplu și puterea disponibilă pentru reîncărcarea bateriei) care se calculează folosind SOC și tensiunea bateriei de 48V. Rezolvând această problemă ECM-ul a fost capabil să evite problemele menționate anterior privind supraîncărcarea/supradescărcarea bateriei de 48V.

Calculatorul de INV responsabil de comandarea motorului electric, pe baza cerintelor de cuplu efectuate de catre ECM.

Un alt exemplu de mesaj la care a trebui evoluat odata cu soft-ul a fost cel pentru cuplu maxim motor (adica cuplu pozitiv) si cuplu maxim de generare curent, pentru care au trebuit schimbate cartografiile de cuplu. O alta modificare a fost introducerea modului (VoltageMode) adica in situatia in care bateria de 48V este avariata se va cere un cuplu maxim de 6 Nm catre masina electrica suficient cat sa functioneze ca un alternator clasic si sa mentina bateria de 12V incarcata, si pe cea de 48V la o tensiune ceruta de ECM.

Figura 1.9 Informațiile transmise către ECM

2. Procesul de dezvoltare software pentru controlul motorului

2.1.1 Ciclul de dezvoltare software

Ciclul de dezvoltare al software-ului pentru controlul și funcționarea motorului este format din mai multe etape structurate sub următoare formă [3][4]:

Fig. 2.0 – Ciclul „W” pentru dezvoltare software calculator motor

Pentru conceperea unui nou software pentru noul model de autovehicul se pleacă de la cerințele deja definite care se doresc pentru controlarea si utilizarea motorului care folosește diferite surse de combustibil.

Dezoltarea software-ului constă în folosirea modulelor „Re-use” (refolosirea uneia sau mai multor părți dintr-un software, schimbând doar anumite funcționalități) sporind astfel calitatea controlului precum și reducerea costurilor și a timpului de dezvoltare. Acest lucru a reprezentat o trecere importantă de la structura anterioară, numită „NON-EMS”, în care pentru fiecare software dezvoltat, se pleacă de la zero, nefolosindu-se alte resurse.

Desigur, această soluție era mult mai închegată din punct de vedere al dezvoltării, se urma un ciclu sigur iar procesul era mult mai simplificat însă folosind sistemul nou de proiectare a software-ului au fost înregistrate economii substanțiale de costuri, precum și reducere a timpului de realizare, lucru foarte important pentru producătorii de autovehicule, în special dacă aceste reduceri provin din proiectare [1].

În figura următoare este reprezetantă în mod simbolic trecerea de la structura „Non-EMS” la structura „EMS 2010”.

Fig. 2.1 – Structura „Non-EMS” vs „EMS2010”

Structura ,,Non EMS’’ cât și structura ,,EMS2010’’ sunt formate din trei componente care alcătuiesc software-ul propriu-zis (cel funcțional):

Hardware calculator

Software de bază

Software aplicativ

Software-ul aplicativ nu mai este realizat doar pentru o singură aplicație în parte (cazul „Nonems”) ci, a fost efectuată o împărțire a software-ului pe diferite module, astfel încât de la o aplicație la alta, în funcție de cerințe și funcționalități să se modifice doar anumite părți ale software-ului, iar aspectele comune, deja utilizate pe alte aplicații, să fie refolosite, de aici denumirea de refolosire – „Re-use”. La nivel aplicativ, software-ul este structurat pe funcții, care la randul lor sunt împărțite în mai multe module, submodule iar acestea din urma din specificații (documentație, caiet de saricini). Specificațiile reprezintă de fapt strategiile după care funcționează controlul diferitelor functionalități. Acestea sunt transpuse în limbaj cod C++ și sunt scrie pe hardware-ul calculatorului.

Acesta este format din blocuri dinamice ,calibrări,constante,variabile cu ajutorul cărora se pot prelua informații de la senzorii fizici aflați pe motor,iar semnalul este trasnsformat în tensiune fiind preluat de către calculator și apoi să fie interpretat la nivelul software-ului.

Blocurile dinamice sunt construite cu ajutorul programului Matlab Simulink și reprezintă diferite strategii. Cu ajutorul acestor blocuri,variabile,constante putem creea specificațiile în diferite module ce alcătuiesc o funcție care la rândul lor sunt generate de Matlab și cu ajutorul lor putem valida diferite strategii.

În imaginea următoare putem vedea toate funcțiile care alcătuiesc arhitectura modulară software-ului pentru un motor termic:

2.2 – Funcțiile care alcătuiesc arhitectura modulară a software-ului

Putem observa în imaginea de mai sus urmatoarele funcții: funcția vehiculului(VF),sistemul de control al uleiului(CL),post tratarea(AT),arderea(CB),comunicare(CM) ,cuplul(TQ) ,siguranța(SF) ,diagnoza(DG),dar și partea de comunicare cu furnizorul (BI,BO).

Funcția de comunicare realizează legătura cu celelalte calculatore aflate pe autovehicul și ajută la diagnosticare, prin folosirea can-ului (magistrala de comunicare între calculatoare- CAN)

Funcția de diagnosticare, realizează partea de diagnosticare, contribuie la omologare, conține diferite servicii care permit testarea componentelor de pe autovehicul prin intermediul protocoalelor de comunicare (KWP sau UDS) cum ar fi electroventilatoarele (treptele acestora), injectoare, bobine, EGR etc prin intermediul testelor de tip intări/ieșiri („input/output control”) și bineințeles, monitorizează toate defectele care pot apărea atât la nivel electronic cât și mecanic prin intermediul managerului de pane.

În paralel cu dezvoltarea software-ului, la dezvoltarea proiectului sunt realizate de către calibratori, fișierele pentru calibrare reprezentând optimizarea strategiilor (valori pentru diferite funcționalități, limite maxime, minime etc).

În următoarea figură este prezentată arhitectura unui SW pentru un motor electric.

2.3 – Funcțiile care alcătuiesc arhitectura modulară a software-ului pentru un motor electric

Funcțiile care alcătuiesc arhitectura unui software pentru un motor electric: CM(managementul încărcării datelor transmise pe CAN), METS ( sistemul de gestionare electrotehnic), MEF (sistemul de gestionare al erorilor), MHVN (sistemul de gestionare al rețelei de înaltă tensiune), ECC(managementul cuplului), MC (controlul motorului), MHVB(sistemul de gestionare pentru înaltă tensiune a bateriei), M14N (sistemul de gestionare al bateriei de 14V), MCS(gestionarea sistemului de răciere),MVS(sistemul de vacuum), TC(controlul termic), DG(diagnoza).

În cazul nostru ECU trebuie să controleze atât motorul termic cât și motorul electric,ceea ce vom avea în imaginea de mai jos,un exemplu pe care AVL îl folosește pentru autovehiculele hibride:

2.4 Arhitectură soft AVL

Figura 2.5 Procesul de concepere a software-ului

Calibrarea este un proces de optimizare sau tunning a algoritmului de control pentru a obține răspunsul dorit de la sistem.

Instrumentul de calibrare este o combinație dintre o interfață hardware și o aplicație software care fac posibilă ca inginerii să activeze ‘’variabilele de calibrare’’pe ECU și să le poată modifica.Teoretic, componentele algoritmului de control ,necesare calibrării sunt:tabelele și constantele.Structura algoritmului de control nu este modificată în timpul calibrării,nu putem adăuga o buclă ,,D’’ la un controler PI la forma unei bucle a unui PID în timpul unei calibrări, ci putem modifica doar constantele de tipul P,I și D.

Calibrarea este un proces în aval de instrumentele de design ale algoritmului precum controalelor rapide de prototipuri (RCP) și generarea automată de coduri.Structura algoritmului de control și calibrarea inițială este stabilită în RCP.Atunci algoritmul este codat manual sau cu ajutorul instrumentelor de autocodare.Putem urmări mai jos câteva exemple de calibrări:

1.Senzorii: Diferite vehicule pot folosi diferite pachete de senzori cum ar fi variațiile unei mase de aer,presiunea aerului,temperatura.Toți acești senzori vor avea un raspuns unic.Calibrarea unui tabel de căutare pentru liniarizare răspunsului lor ar trebuie să depindă de vehicul și de pachetul de senzori folosiți.

2. Performanța: Asupra unui autovehicul se poate efectua un process de tunning pentru a varia performanța cum ar fi puterea dezvoltată versus economia combustibilului.

3.Constantele: Un alt set de componente pe un vehicul poate solicita schimbarea unui algoritm de constante.De exemplu, folosirea unei largi game de pneuri pot să necesite o modificare în calcularea vitezei autovehiculului.

Un algoritm de control al sistemului de propulsie poate avea sute de parametri de calibrare serie.Mulți parametri care sunt folosiți, dezvoltă mai multe dificultăți în găsirea unei calibrări optime.Instumentele de calibrare ajută inginerii să ajungă la un parametru acceptabil de calibrare setat.Toți acești parametrii de calibrări tabel sunt grupați într-o scțiune specială a memoriei ECU numită memoria de calibrare.Instrumentele de calibrări ofera celui care le folosește accesul la această memorie asupra căreia se poate aplica procesul de tunning.

Un sistem de calibrare de bază constă dintr-o interfață ECU, un link către PC-ul gazdă, și o aplicație PC . Un sistem mai capabil va adăuga un link de rețea a vehicului precum și achiziție de module cu interfață a datelor analogice . ECU-ul este de obicei o interfață CAN atunci când un CAN este utilizată ca metodă de calibrare de bază, sau un Read-Only Memory-(ROM) și un emulator atunci când o metodă de acces direct la memorie este folosită.Aplicație PC-ul este de obicei un MS Windows .Figura 2.6 prezintă un sistem de calibrare tipic.

Figura 2.6 Un sistem de calibrare

După cum urmează vom discuta pentru început despre interfața ECU.Interfața ECu este oricare link Can sau un emulator ROM.Fiecare metodă are plusuri și minusuri în selectarea metodei corecte care depinde direct de aplicația dorită.Pentru a fi mai clar despre ceea ce am vorbit mai sus,urmează o descriere a fiecărei metode după cum urmează:

Interfața emulatorului ROM este o interfață aleasă pentru un ECU mai complex, cele cu cea mai mare memorie de calibrare, cum ar fi unitățile de control ale motorului sau unități de control al transmisiei,iar motivul pentru care am ales această interfață este:viteza.Emulatorul ROM este atașat fizic la CAN si microcontroler-ul aflat pe ECU. Memoria de calibrare este cartografiată de pe ECU și în emulator ROM în virtutea care conține acum memoria de calibrare, dispozitivul ROM emulator se pot conecta și manipula variabilele.Viteza pentru a schimba parametrii setați este realizată prin comutarea memoriei de calibrare,de asemenea procesorul este complet neafectat de instrumenul de calibrare(acesta chiar nu știe ca el este acolo). Dezavantajul emulatorului ROM este că e invasiv, adică, el trebuie să se conecteze la magistrala de date a ECU-ului. Producătorii de astfel de instrumente încearcă să reducă la minimum costurile de adaptare, dar acestea încă se mențin în ciuda eforturilor acestora.În figura următoare este prezentată arhitectura de bază a ROM:

Figura 2.7 Arhitectura interfaței emulatorului ROM a ECU-ului

Interfața CAN -ECU este conectată la portul de comunicare a CAN-ului la ECU. Majoritatea datele care sunt transmise folosesc o variantă a magistralei CAN pentru conectarea ECU-ului cu autovehiculul.

Interfața CAN-ECU este dependentă de o rutină de serviciu de calibrate anterior pentru a manipula memoria de calibrare a ECU-ului. Aplicația de calibrare PC-ul gazdă comunică cu ECU cu ajutorul serviciului de rutină prin intermediul unui protocol special numit CPC sau CAN Calibration Protocol,dar mai exista și o variant nouă a acestui protocol cu extensie funcțională denumită XCP.Avantajul a acestui tip de interfață,deseori numită calibrare CCP face posibilă conectarea cu hardware-ul ECU-lui.De multe ori este necesar un port CAN dedicat pentru performațe maxime,această metodă este mai puțin costisitoare decât folosirea unui emulator ROM și NRE nu este necesar.

Dezavantajul este că protocolul și serviciul de calibrare de rutină CPC sunt executate de către ECU și astfel,putem spune că primim un răspuns puțin mai tarziu datorită ciclului de calcul de la ECU.

Există, de asemenea, o limitare a lățimii de bandă privind achiziționarea și logare de date variabile de la ECU deoarec acesta trebuie să trimită aceste informații pe magistrala CAN.

Figura 2.8 Calibrarea prin CCP

Interfața ECU este în primul rând folosită pentru a modifica variabilele din calibrare,așa cum am menționat mai devreme este de asemenea și un instrument de colectare a informațiilor.În timpul procesului de calibrare,inginerul trebuie să aștepte să înregistreze și să compare datele obținute de pe ECU. Un exemplu de date ECU ar fi turația motorului, avans la scânteie, sau durata timpului de injecție.

Aceste date pot fi pe magistrala CAN a vehiculului, cum ar fi cutia de viteze a autovehiculului , sau date externe recepționate analog, cum ar fi temperatura ambiantă,iar pentru a înregistra aceste date instrumental de calibrare trebuie să aibă o conexiune cu magistrala CAN și/sau conexiunea cu dispozitivele de înregistrare a datelor.

Adăugând conexiunea rețelei vehiculului și datele analogice la sistemul de calibrare necesită utilizarea unui dispozitiv pentru a coordona timpul de obținere a datelor.Acest timp de obținere a datelor este necesat aplicației folosite de pe calculator pentru a fi capabilă să transmită datele,iar pentru a obține corelarea datelor din aceste surse diferite și în timp util, este utilizat un distribuitor de rețea.

Odată software-ul și calibrarea terminate urmează procesul de validare a acestora,care putem observa mai jos ca diferă în funcție de tipul validării cât și de locul validării,pe bancul HIL sau pe autovehicul.

3.Procedeele și modalitățile de testare a software-ul

Obiectivul acestor procedee și modalități de testare a software-ului este de a verifica buna relaționare dintre caietul de sarcini (specificații) și cod și de rezolvarea posibilelor erori ce pot să apară pe parcursul dezvoltării software-ului.Astfel putem enumera cateva modalități de testare și validare a întregului soft și a calibrării:

MIL – model in the loop (model în buclă) – acest tip de validare permite verificarea modelelor matlab înainte de faza de dezvoltare a codului.Acestă validare constă în aplicarea unor stimuli reali direcți de pe autovehicul și transpunerea lor ca date de intrare în strategiile create cu ajutorul matlabului.Aceste date de ieșire generate de matlab trebuie să îndeplinească cerințele impuse anterior,numai atunci se vor livra specificațiile.

Figura 3.0 Validare MIL

SIL – software in the loop (doftware în buclă),după ce s-a terminat procesul de codare al specificațiilor se trece la validarea codului și inclusiv a semnalelor de intrare/ieșire specifice MIL.

HIL – Hardware in the loop (hardware în buclă) acesta următoarele roluri:

Simulează în timp real sistemele fizice care există pe autovehicul;

Dezvoltă noi modele virtuale de vehicule și oferă mentenanță pentru modelele existente;

Verifică funcțional strategiile impuse de anumite strategii;

3.1 Testarea și verificarea funcționalității cu ajutorul HIL

Intervenția in ciclul procesului de dezvoltare a validării cu ajutorul HIL :

3.1 Intervenția în ciclul procesului de dezvoltare a validării cu ajutorul HIL

Cu ajutorul HIL putem în cazul de mai sus să testăm un motor real sau o unitatea electronică de control.În cazul nostru motorul va fi simulat,iar noi vom intervenii doar asupra unității electronice de control,care este o componentă reală

Scopul principal al folosirii acestor teste HIL este :

De a observa non regresia software-ului;

De a testa fără a defectarea echipamentelor sau de a pune în pericol oamenii;

De a gestiona creșterea complexității a calculatoarelor pentru motor;

De a testa codurile și integrarea specificațiilor cerute;

De a testa functional anumite strategii noi sau asupra cărora s-au adus unele modificări.

De a furniza toți stimulii electrici necesari pentru a testa și valida unitatea electronica de control specifică tipului de motor.[4]

Pentru o mai bună întelegere a noțiunii de HIL ,vom prezenta simbolic funcționalitatea acestuia.

3.2 Componentele și aparatura folosită de HIL

Alcătuirea sistemului HIL după cum urmează în cazul Renault:

Un model matematic al sistemului ce trebuie testat (un model de motor,sau un model de vehicul) ;

Modele de senzori;

Un calculator cu date de intrăre/ieșire;

Încarcări reale sau simulate;

Un calculator ce controlează ce legătura de comunicare a calculatorului motor cu diagnosticarea ECU-ului;

O interfață grafică (IGU) necesară controlului în timp real;

3.3 Structura și component bancului HIL

Bancul HIL conține un procesor care este în legătură direct cu ECU,unde calculele sunt efectuate în mai puțin de 1 secundă,o interfață de control pe care utilizatorul o folosește de pe un laptop și o cutie care conține componentele fizice existente pe autovehicul care nu pot fi simulate ușor(Load Rack) ,dar și unele ce sunt simulate cu ușurință( injectoare,bujii,valve EGR,etc.).

Producătorul bancului HIL este dSPACE și este colaboratorul companiei Renault.

Pe langă cutia cu component și model se mai găsesc și conexiunile ce comandă actuatorii(IO control),pini pentru a putea simula unele defecte pe care le vrem,dar și legăturile cu următoarele programe utilizate în testarea,controlarea și validarea software-ului:

Control Desk – este interfața grafică pentru conectarea la bancul HIL.

Cu ajutorul lui putem selecta modelul (datele tehnice de pe autovehicul montate pe unitatea de control care pot fi modificate prin intermediul CAN), se poate manevra virtual autovehiculul prin intermediul unui tablou de bord care indică turația, viteza precum și prin intermediul simulării frânei, accelerației, ambreiajului etc, întocmai ca pe autovehicul.

3.4 Interfața grafică Control desk

INCA (Etas) – este un program care permite achiziția de date nu numai de pe unitatea electronică de control ci și de pe celelalte calculatoare care există pe autovehicul.

Este un sistem de măsurare,calibrare,reglare și diagnosticare care permite culegerea și evaluarea datelor de pe autovehicul cu ajutorul senzorilor și transmise pe CAN către ECU și interpretate cu ajutorul sistemului ETAS.

3.5 Conexiunea ECU-ETAS-PC

DDT 2000 – este un program de diagnosticare (citirea-ștergerea erorilor) folosit pentru toate calculatoarele de pe autovehicul,acesta se conectează cu rețeaua CAN de pe vehicul cu ajutorul mufei OBD ( On board diagnostic).

Utilizarea DDT 2000 pe calculatoarele care echipează vehiculele Renault:

Diagnosticarea erorilor;

Identificarea software-ului existent pe unitatea electronică de control;

Reprogramarea ECU folosind o altă versiune software;

Controlarea actuatorilor cu ajutorul datelor de intrare/ieșire;

Interpretarea și modificarea mesajelor transmise pe CAN;

Rescrierea codurilor de injectoare;

Salvarea datelor înregistrate.

Fig.3.6 Interacțiunea PC-DDT-ECU

Canalyser – realizează monitorizarea,vizualizarea și modificarea mesajelor transmise cu ajutorul rețelei CAN – BUS,se pot vedea toate mesajele care ies/intră în ECU.

Interacțiunea PC-Canalyser-ECU

Validări finale – sunt sistem unde se fac teste în ultima parte a ciclului procesului de dezvoltare a software-ului înainte de industrializare.

Scopul acestor validări finale:

-funcționarea și monitorizarea motorului;

-validare întregului sistem –se testează întreaga funcționalitate a întregului sistem,deoarece âană acum s-au efectuat doar testarea și validarea pe bucăți.

-efectuarea de teste și simularea anumitor defecte elctrice care pot apărea oricărui conducător auto.

În cazul autovehiculului nostru Dacia Duster hybrid după toate operațiile pe care le-am enunțat mai sus,și anume: realizarea software-ului (plecand de la arhitectura codului,calibrări,specificații,funcții),apoi modurile de testare a software-ului ,ajungem la software-ul final pe care îl vom folosi.

Pentru a putea utiliza acest software pe autovehiculul nostru hybrid vom parcurge următoarele etape :

1.Folosirea DDT 2000:

Copierea software-ului pe unitatea electronica de control a noului Dacia Duster hybrid- se face cu ajutorul instrumentului DDT 2000

Selectarea tipului de rețea CAN și a tipului de ECU

Identificarea noului software pe care l-am instalat pe ECU pentru a ne asigura că testele se vor face pe software-ul dat.

Ștergerea posibililor erori apărute.

2. Folosirea instrumentului INCA

În figura următoare de mai sus sunt evidențiați câțiva parametri principali ai autovehiculului, respectiv ai motorului, citiți prin intermediul programului INCA direct de pe unitatea electronică de control – ECU.

4. Bibliografie

*Masahiro Goto – 29 august, 2013 – Denso corporation Presentation

Autosar.org

Wikipedia

P. M. Lahore, Laurent Royer / François Seprey / Pierre Yves Le-Morvan „Renault model based design – Powertrain control development process”, Renault, France

5. Documentație – Renault Technology Roumanie – Centrul Tehnic TITU -2014

6. Curs Metode și tehnologii moderne de diagnosticare a automobilelor – 2013