Sistem de Testare a Senzorului R.l.s. Folosind Date Reale

Abstract + capitolele

Prin aceasta lucrare se doreste o analiza a evolutiei industriei auto din mai multe puncte de vedere, luand in considerare cele mai noi si actuale subiecte.

Intr-o masina se afla multi senzori, acestia vor fi impartiti in functie de anumite categorii, punandu-se accent pe senzorii de confort, respectiv pe senzorul de ploaie si lumina.

La senzorul de ploaie si lumina se vor prezenta caracteristicile acestuia, functionalitatea si beneficiile unui asemenea senzor.

Lucrarea cuprinde modul de testare din prezent al senzorului si insuficienta acestei metode. Se analiza problemele intalnite, se stabilesc solutiile pentru rezolvarea acestora si se implementeaza solutia optima.

Se face trecerea de la modul simulat la modul real prin introducerea datelor inregistrate anterior pe masina de test, in locul profilelor ideale realizate prin diferite functii.

Prezentare domeniu

Domeniul automotiv

Secolul in care ne aflam este denumit "secolul vitezei".

Masina a aparut din nevoia oamenilor de a parcurge o distanta mare in timp cat mai scurt, de a folosi cat mai putin timp pentru a ne deplasa de la A la B.

A trecut mai bine de un secol de cand a aparut prima masina cu motor. Astazi nu se mai poate trai fara ea. Fie ca mergem la scoala, serviciu, la cumparaturi sau in vacanta, avem nevoie de cel putin o masina in familie.

La inceput conta ca masina sa aibe "patru roti si un volan". In decursul timpului masina a avut transformari majore. Masina a devenit mai rapida, mai usoara si mai puternica, contine zeci de senzori si actuatori care monitorizeaza si controleaza diferite parti ale masinii. Masinile de ultima generatie au un design futurist, inglobeaza tot ce e nou pe piata in materie de tehnologie si poate fi conectat la aceasta orice dispozitiv.

Ne gandim si la masina viitorului: o masina care poate zbura, deoarece deja exista masini care se conduc singure sau sisteme de comunicare intre masinile apropiate.

Conexiunile erau realizate punct la punct in anii 1990. Functionalitati precum injectia electronica, controlul airbag-ului necesita tot mai multe legaturi intre diferitele componente, astfel subfunctiile trebuie sa coopereze intre ele folosint mediul existent de comunicatie: CAN si MOST. [200]

In automotive, termenul general folosit pentru unitatile care controleaza un sistem electric sau subsistem intr-un autovehicul este de unitati de control electronic (ECU-uri). BCM-ul (Board Control Module, sau mai este numit si Automotive Central Body Controller) este un anumit tip de ECU care supervizeaza si controleaza diferite functionalitatii ale masinii precum: luminile, geamurile, usile. Comunicarea cu BCM-ul se poate face pe CAN sau pe LIN.

ECU-urile, putine la numar la inceput, sunt conectate la senzori si la actuatori. Preiau datele de la senzori, le analizeaza si comanda actuatori pentru diferite task-uri. Cu cat numarul acestora intr-o masina s-a marit, cu atat comunicatia a trebuit sa fie tot mai rapida. In prezent ECU-urile sunt interconectate pentru a schimba informatii precum viteza masinii, temperatura din interior sau alte informatii utile pentru anumite componente alee masinii. Numarul lor variaza de la 30 de ECU-uri la masinile din gama standard, pana la aproximativ 100 de ECU-uri la masinile din gama premium. [201][202]

Grimm afirma ca cele mai importante criterii de calitate pentru un automobil sunt: fiabilitatea, disponibilitatea si siguranta. Masina trebuie sa functioneze in parametrii normali in conditiile stabilite de functionare, sa poata fi folosita pentru deplasare si sa fie sigura atat pentru pasageri, cat si pentru ceilalti participanti la trafic. [200]

Calitatea masinii s-a schimbat semnificativ odata cu dezvoltarea software-ului in industria automotive. Treptat s-a facut trecerea de la majoritatea componentelor mecanice si electrice, si catre software. S-au creat din ce in ce mai multe functii. Acum, acestea sunt inovatoare, prin ele se reduc anumite costuri ale masinii, trebuie sa fie cat mai eficiente, astfel ele sunt corelate si apartin unor sisteme de multi-functii. [200][201]

Dezvoltarea functiilor poate urma diferite design-uri: top-down sau bottom-up. Datorita procesului de dezvoltare a software-ului in inductria auto, design-ul top-down nu a fost folosit. Acesta implica o cunoastere de ansamblu a functionalitatii masinii, care apoi sa fie modularizata pentru implementare. Diferite functii lipsesc de la o masina la alta, sau sunt diferite, astfel se utilizeaza design-ul bottom-up. Broy afirma in acest sens ca inductria auto este bine organizata vertical, referindu-se la modularitatea dezvoltarii software-ului in masina. [201]

In timp, subsistemele dintr-o masina se schimba. Acestea trece de la o generatie la alta, devenind mai performante, mai economice. Functionalitatea acestora se schimba, iar dupa o analiza s-a constatat ca 10% se modifica si 90% este software rescris. Se intampla astfel deoarece exista o implementare hardware specifica, de tip low level care este greu de schimbat, de adoptat sau de portat codul deja existent, rezultand intr-o modificare masiva a codului. [201]

Masina este prezentata ca un sistem complex, in care toate functiile lucreaza impreuna. Este defapt vazuta ca un sistem integrat, asamblat din diferite componente, modularizat, fiind astfel programabil cu o mai mare usurinta. Subiecte precum confortul si manevrarea sport nu mai este determinata doar de partea mecanica, ci si de cea software. [201]

[201] – procesul de development??? 1 req, 2 design, 3 coding, 4 sw&sys integration, 5 QA, 6 mentenanta.

Datorita inovatiilor in tehnologie, soferul si pasagerii sunt acum inconjurati de ecrane tactile, butoane aflate in board-ul central, pe usi, sub scaun, incat interfata masinii cu "utilizatorul" a devenit din ce in ce mai greoaie. Din aceste motive, interfetele trebuie sa fie usor de utilizat si cat mai intuitive. [200]

Comunicarea intre masini. Acesta din urma exista ca sistem, nu se doreste a fi implementat datorita integritatii datelor despre pasageri, locurile vizitate si alte informatii care se doresc a ramane anonime.

-> Car to Car communication, V2V, vehicle to Vehicle

Siguranta la volan are un rol major in alegerea unei masini. Standard ISO…..

Inovatie: Tesla batteries

Senzorul este un dispozitiv care transforma o cantitate fizica intr-un semnal electric, pentru a servi ca date de intrare pentru un sistem/subsistem.

Numarul senzorilor dintr-o masina poate varia intre 60 si 100, astepnadu-se ca prin jurul anumui 2020, numarul acestora sa ajunga la aproape 200. {http://www.automotivesensors2015.com/ }

Senzorii din inductria automotiv trebuie sa satisfaca criterii precum acuratete, robustete, sa fie sustituibili si sa aibe un pret scazut. Cu cat senzorul este mai precis, cu atat informatiile sunt de calitate, iar deciziile sunt mai potrivite; senzorul intr-o masina trece prin socuri, vibratii, oscilatii ale temperaturii, astfel el este solid si compact. Costul scazut al componentelor masinii duce la un pret mai mic al masinii. [203]

In articolul despre noi tipuri de senzori, Fleming incadreaza senzorii in 15 mari categorii:

"Smart sensor", senzori inteligenti care contin si partea de procesare a semnalului;

senzori de viteza si te timp. acestia sunt folositi in special pentru anumite masuratori la motor;

senzori de pozitie, precum pozitia volanului, nivelul combustibilului;

senzori de presiune, pentru suspensia hidraulica, lichidul de frana;

senzori de temperatura, la motor, in habitaclul;

senzori pentru masurarea curentului de aer (mass air flow) la motor;

senzori care masoara rasucirea;

senzori pentru acceleratia liniara;

senzori pentru viteza unghiulara;

senzori pentru compozitia gazului si elementelor chimice;

senzori de siguranta si securitate;

senzori de distanta;

senzori de "night vision";

senzori de viitor;

senzori de confort si comoditate.

Senzori de confort fac calatoria mai placuta atat soferului, cat si pasagerilor. Sunt inclusi in instrumentatia de bord, lumini, scaune, clima, deschiderea/inchidere masina, sistem de alarma, controlul geamurilor, recunoasterea vocii si altele.

Senzorul de ploaie si lumina (Rain Light Sensor) face parte din categoria senzorilor de confort. Acesta imbunatateste vizibilitatea pe timp de ploaie prin adaptarea automata a modului de stergere a parbrizului, prin aprinderea farurilor in momentele necesare precum intrarea intr-un tunel, dar si confortul pasagerilor prin racirea in modul dual.

Senzorul de ploaie și lumină

Ultima generatie de sonzor are cinci functionalitati: ploaie, lumina, sarcina solara, umiditate si HUD (heads-up display).

Senzorul preia informatii despre intensitatea ploii, a luminii si poate controla functii precum: stergerea parbrizului, luminile, aerul conditionat in functie de sarcina solara si luminozitatea display-ului (HUD) pentru o vizibilitate optima a soferului.

Functioneaza in diferite conditii: ploaie, zapada, lapovita etc. avand comportament diferit in functie de acestea.

Este montat in spatele oglinzii retrovizoare, lipit de parbriz.

Comunicarea senzorului cu componentele masinii se face prin LIN. Acesta primeste si trimite frame-uri de LIN catre ECU-uri ale sistemului de stergere a parbrizului, cel al luminilor din fata si spate si unitatii de control al climei.

Pentru a functiona, senzorula are nevoie de informatii, precum pozitia stergatoarelor, viteza stergatoarelor si starea motorului, daca masina este pornita sau nu, viteza masinii, temperatura ambientala. Exista si alte informatii care imbunatatesc functionalitatea senzorului.

In functie de componenta analizata de senzor, se trimit informatii despre:

ploaie: viteza stergatoarelor, detectia stropirii parbrizului sau a ghetii

lumina: aprinderea sau stingerea luminilor

soare: valori solare (1 sau 2)

umiditate: procent de umiditate si temperatura parbrizului

HUD: luminozitatea portiunii de proiectare

diagnoza pentru functia de ploaie, lumina, soare, umiditate si comunicare.

Persoana care are cele mai mari beneficii de pe urma unui astfel se senzor este soferul. Atunci cand ploua, daca stergatoarele sunt puse in pozitia automat, senzorul v-a prelua informatii despre intensitatea ploii si v-a mentine parbrizul curat. In cazul in care soferul poate modifica senzitivitatea, timpul dintre doua stergeri consecutive ale stergatoarelor creste sau scade. Un factor important este si viteza de deplasare a masinii, care cu cat este mai mare, cu atat creste si senzitivitatea senzorului.

Pe vreme cu soare puternic, senzorul poate lua decizii precum modificarea climei pe modul dual; de exeplu atunci cand soarele bate din partea stanga, jumatatea stanga a masinii va seta temperatura mai scazuta decat in partea dreapta pentru a mentine temperatura dorita si un confort mai ridicat al soferului. Senzorul are acces la clima si in cazul detectiei de ceata. Acesta masoara umiditatea de pe parbriz, comandand sistemul de clima pentru dezaburire atunci cand vizibilitatea poate fi ingreunata pentru sofer.

Exista cazuri care sunt tratate special, cum ar fi detectia ghetii pe parbriz. In acest caz daca semnalul de detectie este primit, stergatoarele raman in pozitia lor initiala, si astfel se evita stricarea sau deteriorarea acestora.

In functie de datele primite de senzor, acesta trimite catre ECU date pentru a aprinde sau a stinge luminile. Exista masuri de siguranta in cazul in care semnalul nu este primit; daca senzorul nu poate citi informatii despre lumina sau se pierde comunicarea cu senzorul, ECU-ul comanda automat aprinderea farurilor. O masina nu are voie sa circule in conditii de lumina redusa fara lumini.

O metoda de siguranta este luata si in cazul functionalitatii de ploaie. Atunci cand semnalul nu se mai trimite catre ECU sau este pierduta comunicarea cu acesta, daca stergerea parbrizului este pusa in pozitia auto, stergatoarele vor fi pornite pe o viteza prestabilita, pentru a pastra vizibilitatea soferului cat mai buna in timpul calatoriei.

Senzorul de ploaie respecta standardul ISO 26262. Standardul este derivat din IEC 61508, adaptat pentru industria automotiv. Standardul clasifica ASIL-ul pe mai multe nivele, de la A pana la D, nivelul D fiind cel mai sigur dintre ele pe pardea de siguranta. RLS-ul este incadrat ca ASIL B, nefiind vital precum sunt airbag-urile. [204]

– sw customiztion

– Diode care masoara intensitatea de lumina infrarosie, fiind folosita pentru a masura lumina ambientala la un anumit unghi si diode cu senzor optic care masoara lumina ambientala in firectia de mers a masinii.

-photodiodes 3 diode emitatoare

3 canale de ploaie

-photorecetors

-LIN

Tabel 2.1 Proprietati ale senzorului [209]

– http://www.slideshare.net/GvAnu90/rain-light-sensor

Prezentare capitole + descriere pe scurt

Justificarea temei alese

Senzorul de ploaie si lumina este larg utilizat în industria automobilelor. Aproape orice mașină produsă în prezent are acest senzor aflat sub oglinda retrovizoare la autoturisme.

Acest senzor este unul de confort, ajutând conducatorul pe timp de ploaie sau lumina puternica prin a porni automat stergatoarele, a modifica luminile, a intensifica lumina ambientala sau chiar de a porni clima.

Am ales aceasta tema din dorinta de a rezolva anumite probleme care apar conducand masina si care nu au fost depistate doar prin simularea modelului.

Problemele au aparut prin comportamentul neasteptat al senzorului in anumite situatii precum stergerea parbrizului cand nu a fost detectata ploaie. Acesta se numeste false wipe si a aparut la trecerea masinii pe sub copaci, de la jocul de lumini printre frunzele acestora.

Se pot detecta de asemenea bug-uri de regresie, aparute ulterior in anumite functionalitati deja testate. Spre exemplu, modificarea unor parametrii la modelul de tunel poate duce la lipsa aprinderii farurilor. El poate fi vazut ca un test de regresie care necesita doar timp pentru rulare/executie, nu si pentru preparare.

Fiind conducator auto, am realizat cat de importanta este vizibilitatea la volan si cum o clipa de neatentie sau o fractiune de secunda in care nu esti atent la drum, poate avea ramificari devastatoare.

Senzorul respecta standardul ISO 26262 ASIL B. (dezvolt ideea)

Consider ca aceasta tema este o provocare prin a cerceta solutiile viabile ale problemei, a le analiza si a implementa-o pe cea mai buna dintre ele.

De cand eram mica, m-au fascinat masinile. Mi-am dorit sa conduc, sa fiu un bun sofer si acum am ajuns si sa ma implic in rezolvarea unor probleme din acest domeniu.

Prezentarea lucrării

Structura lucrării

In prima parte voi prezinta tool-urile folosite….dezvoltare

x

x

Tool-uri

In acesta lucrare am folosit tool-uri precum editor de text, Notepad++, pentru a modifica diferite fisiere de log-uri, Matlab in realizarea modelului pentru RCP, CodeComposer Studio v3.3 si Jtag pentru a genera automat cod din modelul de matlab si a flash-ui placuta. Diferite tool-uri de la Vector precum CANdb++ Editor pentru crearea si modificarea mesajelor de CAN din baza de date (fisier .dbc) sau LDF Editor(??) pentru mesajele de pe LIN (fisiere .ldf) , CANoe 8.1 si CANcase in simularea nodurilor pentru a crea astfel un mediu de comunicatie atat pe CAN cat si pe LIN. Realizarea unei interfete in CANoe cu Panel Designer pentru transmiterea datelor din fisierele de log. Am scris functii in CAPL pentru realizarea unui anumit comportament in comunicarea cu HIL-Head-ul si cu senzorul.

RCP(Rapid Control Prototyping)

RCP este o componenta hardware care ajuta la testarea rapida a unui algoritm.

Algoritmul este testat pe un astfel de hardware/sistem deoarece componenta hardware specializata nu este inca realizata. Se ruleaza astfel modele matematice in timp real, inainte sau in acelasi timp cu dezvoltarea unitatilor de control dorite.

Avantajul este imens deoarece se pune accent pe inovatie, pe descoperirea ideilor si testarea conceptelor intr-un timp cat mai scurt. Nu este necesara realizarea componentei specifice pana nu este testat si acceptat algoritmul.

Elementul cheie pentru RCP este generarea automata de cod dintr-un model, astfel se elimina unele erori. Inginerii se pot orienta pe design-ul sistemului, pe implementare si evaluare, in loc sa piarda timp ocupandu-se de programarea "low level". [305]

Placuta de RCP poate fi cumparata sau dezvoltata intern de firma care are nevoie de aceasta. Design-ul este unul general, placuta fiind folosita la o multitudine de aplicatii, simuland un comportament diferit in functie de produsul modelat.

Conventional, un sistem RCP trebuie sa aiba anumite caracteristici pentru a nu da mai multe batai de cap programatorilor, iar acestia sa petreaca mai mult timp incercand sa rezolve problemele de design. Caracteristicile ar fi: un procesor in virgula mobila puternic, de cateva ori mai rapid decat procesorul stabilit, porturi de intrare/iesire variate, mai multe tipuri, si multa memorie. [305]

HIL-Head-ul

Simularea HIL este o metoda de testare puternica, utilizata in testarea eficienta a sistemelor de control incorporate. Simularea include emularea unor senzori sau a unor actuatori, care sunt controlati printr-o interfata si datele sunt citite de catre sistemul testat. [300]

Testand sistemul, criterii precum controlul, siguranta, disponibilitatea si costul sunt luate in considerare, fiind cateodata dificil prin testarea intregului sistem. [300]

HIL-Head-ul este componenta hardware cu ajutorul careia transmitem senzorului informatii cand acesta este intr-un sistem simulat, pentru testarea senzorului.

In masina, senzorul se afla intr-o incapere aflata in spatele oglinzii retrovizoare. Acesta este lipit de parbriz printr-un gel. Pentru a simula conditiile reale dintr-o masina, in care senzorul primeste informatii despre ploaie si lumina prin diode, acesta este astfel pus alaturi de HIL-Head. Acest hardware trimite datele direct la diodele receptoare ale senzorului.

Datele trimise simuleaza anumite conditii din mediul real: diferite profile de ploaie, ploaie mai marunta, ploaie densa, trecere pe sub un pod, intrarea sau iesirea dintr-un tunel, prin care se testeaza raspunsul senzorului la un astfel de profil, se urmareaste comportarea lui si situatiile in care nu se respecta anumiti timpi sau mod de functionare.

In modelul dezvoltat pe RCP, mesajele sunt primite pe CAN si copiate la o anumite adresa pentru a fi mai departe interpretate de catre HIL. Modificarea valorilor pe diodele transmitatoare se realizeaza prin trimiterea unor mesaje care contin diferite semnale.

++ http://www.ni.com/white-paper/10343/en/

MATLAB – Simulink

MATLAB (matrix laboratory) este un mediu de dezvoltare creat de cei de la MathWorks pentru analiza statistica si calcul numeric. Cu MATLAB se pot vizualiza functii, implementa algoritmi, manipula matrici, crea interfete pentru user si interactiona cu diferite alte limbaje precum Java, C, C++ si altele. [400]

Simulink, dezvoltat tot de MathWorks, este un mediu de programare grafic pentru modelare, simulare si analiza. Interfata primara a acestuia este una grafica cu diagrame bloc si cu un set de blocuri din librarie. [500]

Din Simulink se poate genera cod utilizand un add-on, numit Real-Time Workshop (RTW), care genereaza automat cod in limbajul ANSI-C sau in ADA, din diagramele bloc din Simulink. Codul generat din RTW nu este destinat unui hardware specific, el poate fi pus pe o multitudine de sisteme, spre exemplu pe calculatorul personal, pe un procesor de semnal digital (DSP) sau chiar si pe un microcontroler. [305]

RTW genereaza doua tipuri de cod in C: cod generic si cod embedded. Cel din urma este mai optimizat in performanta si spatiul utilizat. Facand build la modelul din Simulink, el este convertit intr-un fisier de descriere a modelului (.rtw). Pentru a crea o aplicatie specifica, RTW utilizeaza un makefile template (.tmf) care specifica tool-urile pentru generarea codului. Din acesta se transforma in target makefile (.mk), ca mai apoi TLC-ul (Target Language Compiler) sa genereze codul C. Fisierul .mk este cel care contine informatiile necesare generarii codului pentru fiecare bloc din Simulink. Daca exsita bucati de cod care trebuie compilate din nou, acestea sunt recompilate, iar codul final este generat si copiat pe placuta. [305]

[305]

RCP-ul este folosit cu succes in scop educational. Se minimizeaza procesul prin faptul ca se trece usor de la teorie la partea practica. Studentii pot deveni in scurt timp familiari cu RCP-ul si cu modelul dezvoltat in Simulink.

[501] http://www.mathworks.com/help/simulink/gs/model-based-design.html

MATLAB R2011a, aparut in 8 aprilie 2011, este a 25-a versiune. [http://en.wikipedia.org/wiki/MATLAB]

-> include MATLAB Coder, a new product for generating portable C/C++ code directly from MATLAB.[ http://www.mathworks.com/videos/r2011a-matlab-coder-69516.html]

-> new toolbox for communication and DSP [505][506]

->[https://help.ubuntu.com/community/MATLAB/R2011a]

CCS -> CodeComposerStudio v3.3

JTAGJet C2000

JTAGJet C2000 este un emulator pentru familia C2000 la microcontrolere si DSP-uri de la Texas Instruments. El este un debugger de dimensiuni mici, echipat cu interfata USB 2.0 care ruleaza in mod high-speed la 480 Mb/sec si o sonda detasabila cu 14 pini pentru conectarea de DSP. [511][510]

Este compatibil cu Code Composer Studio (CCS) 3.3 sau versiune mai noua. Se instaleaza in directorul de la CCS si devine vizibil ca si JTAGjet Emulator, fiind usor de configurat utilizand drag and drop si fereastra de configurare. [511]

Flasher-C2000 este un utilitar care permite emulatorului Signum JTAGjet sa programeze memoria flash a RCP-ului. [511]

Cu ajutorul acestui produs am realizat incarcarea modelului din MATLAB pe placuta de RCP. In momentul build-uirii incrementale a modelului, se genereaza cod C si acesta este incarcat pe placuta de RCP prin JTAGJet C2000.

JTAGJet C2000 [510]

Vector, CANoe, CANcaseXL, CAPL

Vector Informatik este o companie ce dezvolta tool-uri si componente software pentru comunicarea intre sistemele electronice cu magistrala seriala. Protocoalele de comunicatie folosite sunt CAN, LIN, FlexRay, MOST, Ethernet si altele. [600]

-> odata cu capatarea experientei -> demenii: aviatie, masini de mare tonaj, masini speciale si sisteme embedded [600]

-> produse precum CANalyzer(tool de analiza), CANoe(tool de development, suport ptr simulare, diagnoza si testare), CANape(development ptr calibrarea algoritmilor); [600]

CANoe 8.1

CANcaseXL pe scurt CANcase cu CAN si LIN

[http://vector.com/vi_automotive_en.html]

CANcase

CAPL

CAPL este un limbaj de programare bazat pe evenimente, dezvoltat de la Vector, folosit exclusiv. Programul in CAPL consta in proceduri prin care se pot

Sintaxa limbajului este asemanatoare cu cea in C.

x

x

x

x

x

Analiza modului actual de testare

2 moduri:

-> testare soft, model matlab

->testare RLS cu Execution and Evaluation tools

In prezent, senzorul de ploaie si de lumina este testat pe testbench-ul de RLS.

Un testbench include un calculator, CANcase, placuta RCP, flasher-ul JTAGJet C2000, senzorul RLS si HIL-head-ul ca si componente hardware. Componentele software sunt MATLAB/Simulink cu modelul .mdl, CANoe de la Vector prin care se realizeaza comunicarea cu HIL-head-ul si cu senzorul RLS. ???

RCP-ul este alimentat la 12V de o sursa de tensiune de curent continuu. RPC-ul este conectat la JTAGJet C2000. Acesta este atat alimentat cat si comunica cu calculatorul prin USB.

Senzorul nu comunica cu placuta de RCP??? pe LIN.

Informatiile de pe RCP ajung la HIL-head prin comunicatie LIN, DAC-uri???? Digital to Analog Convertor???

Pe calculator este pornit Matlab-ul. Prin incremental build din modelul aflat in Simulink prin flash-uire se genereaza automat cod care este incarcat pe placuta de RCP.

In primul rand senzorul este flash-uit cu un software curat.

x

x

x

x

x

Fundamente matematice ????

Prezentare model

Setup-ul

Avem nevoie de diferite componente hardware pentru conectarea senzorului RLS la calculator in realizarea comunicarii cu acesta pe LIN si transmiterea datelor reale din fisierele de log pentru analizarea comportamentului senzorului in diferite situatii (primirea datelor de stropirea a parbrizului sau a detectiei ghetii) sau pe diferite profile de ploaie sau lumina.

Setup-ul este astfel alcatuit din urmatoarele componente hardware: calculator, CANcase, placuta de RCP, HIL-head-ul, senzorul RLS si JTAGJet C2000 si cabluri de conectare intre acestea.

Modelul hardware al setup-ului

Setup-ul

Componentelor hardware li se adauga componentele software necesare realizarii sistemului de testare, dar si pregatirii informatiilor in etapa anterioara rularii precum si in timpul testarii senzorului. Acestea sunt:

MATLAB/Simulink pentru realizarea si incarcarea modelului pe RCP;

CANoe pentru realizarea comunicarii pe LIN cu senzorul RLS, dar si pe CAN cu HIL-Head-ul;

CAPL Editor pentru crearea codului in CAPL utilizat la extragerea datelor din fisierele de log si transmiterea lor pe CAN sau LIN;

CANalyzer si MDF Viewer(???) pentru analizarea semnalelor si transformarea fisierelor de log din formatul initial .mdf in .ascii pentru prelucrarea lor;

Notepad++ pentru editarea fisierelor si vizualizarea lor;

CANdb++ Editor pentru adaugarea si modificarea semnalelor de CAN, LDF Editor(???) folosit in acelasi scop pentru semnalele de LIN;

Panel Designer pentru interfata cu utilizatorul in CANoe, folosita pentru setarea unor semnale, dar si trimiterea datelor din fisierele de log catre senzorul de RLS si catre HIL-Head.

JTAGJet C2000 este conectat la calculator prin USB, realizandu-se atat alimentarea acestuia cat si transmisia de date, iar la RCP prin 14 pini. In momentul buid-uirii modelului din MATLAB, pe calculator, acesta este transformat in cod si incarcat pe RCP. Dupa incarcarea modelului, nu mai este nevoie de JTAGJet.

CANcase-ul este legat prin USB la calculator, realizandu-se atat alimentarea CANcase-ului, cat si transmisia datelor de la PC. CAN-case-ul are doua canale, unul de LIN cu senzorul si unul de CAN cu HIL-head-ul.

Comunicarea cu senzorul se face astfel pe LIN, dar magistrala de LIN trece si prin placuta de RCP, in eventualitatea modificarii modelului pentru procesarea mesajelor pentru senzor. Trimiterea mesajelor se poate realiza si din model direct catre senzor daca este necesar.

Transmisia mesajelor catre HIL-head se face pe CAN prin modelul uploadad in RCP, astfel ca RCP-ul primeste mesajele pe CAN prin configuratia de CANoe realizata. In model, mesajele de pe CAN sunt despachetate si informatiile necesare sunt puse in locatii speciale de memorie pentru a fi folosite de catre HIL-head. Acesta preia valorile din locatiile de memorie si controleaza diode emitatoare de pe urma valorilor. Senzorul RLS si HIL-head-ul sunt conectati optic. Diodele receptoare ale senzorului detecteaza informatiile trimise de la diodele emitatoare ale HIL-head-ului, precum acesta ar fi localizat pe parbriz si ar bate lumina.

.

Diodele de pe HIL-Head controlate din model

Punerea informatiei pentru HIL-head

Datele de intrare necesare pentru noul mod de testare se preiau din testele realizate deja pe autoturismul de test.

Modul de realizare a acestor log-uri este unul obisnuit. Masina cu senzorul RLS montat si conectat la un calculator cu CANalyzer, pentru a inregistra datele furnizate de senzor pe LIN, este pusa in diferite conditii pentru testarea senzorului.

Testele realizate pe masina sunt in diferite conditii precum: pe timp de ploaie, cu diferite profile, ploaie marunta, plaoie deasa, puternica pentru analiza comportamentului senzorului. Acesta trimite destul de repede comanda de stergere a parbrizului conform profilului de ploaie existent sau vizibilitatea este ingreunata? La schimbarea vitezei peste o anumita valoare se fac ajustari la anumiti parametri pentru a micsora timpul dintre doua stergeri consecutive ale parbrizului. De asemenea testarea atat pe timpul zilei cat si pe timpul noptii cand ploua. Cazuri diverse de stropire a parbrizului de un camion de pe contrasens, daca parbrizul este inghetat.

Testarea functionalitatii de lumina prin trecerea pe sub un pod, trecerea printr-un tunel care trebuie sa provoace aprinderea luminilor, precum si dezaburirea parbrizului pe conditii de ceata sau pornirea climei in modul dual si reglarea acesteia daca soarele bate mai tare pe o parte.

Comunicatia pe LIN cu senzorul este stocata de catre CANalyzer intr-un fisier de log cu extensia .mdf. Cu ajutorul programului CANalyzer care are un editor MDF Viewer(???), se poate face conversia la un format ASCII, care este usor de citit si perceput din punct de vedere uman ca si format.

Structura noului fisier este simpla: pe prima linie se afla puse numele tuturor semnalelor trimise pe LIN, separate intre ele de punct si virgula (";").

Liniile urmatoare contin atatea valori cate semnale sunt pe prima linie, despartite tot de punct si virgula.

Datele aflate in acest fisier nu ne sunt toate de folos. Printr-o analiza a senzorului si a HIL-head-ului, pentru a emite pe diode diferite intensitati, avem nevoie de datele neprocesate primite de catre senzorul testat pe masina, cum ar fi valorile de ploaie pe cele trei canale, valorile de lumina, sarcina solara, umiditate colectate de senzorul RLS.

Configurația din CANoe

Prin configuratia de CANoe se realizeaza comunicatia, iar mesajele si semnalele pot fi vazute in fereastra de trace a programului. Pentru ca mesajele si semnalele sa poata fi interpretate de catre utilizator, datele sunt stocate intr-o baza de date. In baza de date se afla diferite informatii despre semnale.

Fisierele cu baza de date pentru comunicarea pe CAN sunt cu extensia .dbc, iar cele de pe LIN au extensia .ldf. Aceste prescurtari provin de la: DataBase CAN pentru dbc si LIN Description File pentru ldf. (detaliere)

DESCRIERE STRUCTURA fisier LIN si CAN

x

x

x

x

Avand un CANcaseXL cu doua canale, am utilizat canalul 1 pentru comunicarea pe CAN si canalul 2 pentru comunicarea pe LIN. Acesta este util prin faptul ca avem o singura instanta de program pornita cu doua configuratii diferite, una pentru CAN si una pentru LIN care functioneaza concomitent.

CANcase-ul a fost configurat hardware, continand cate un tranceiver CANpiggy si unul LINpiggy pentru fiecare din cele doua tipuri de comunicare. Schimband aceste tranceivere, CANcase-ul poate avea doua canale de CAN, doua de LIN sau combinat cum este in acest caz, unul de CAN si unul de LIN.

Configuratia pentru comunicarea pe CAN este reprezentata in figura X 4.5.??? de mai jos:

Configuratia pentru comunicarea pe CAN

Canalul de CAN contine noduri, generatoare, generator interactiv, bloc de replay, bazele de date cu mesajele si semnalele aferente CAN, dar si canalele de comunicatie care este CAN-ul pentru acest caz.

Comunicarea cu HIL-Head-ul se realizeaza pe CAN. In configuratie avem nodul cu numele CAN_HIL prin care se trimit datele, adica nodul din configuratia de CAN prin care se transmit datele spre HIL-Head. Modul de comunicare cu HIL-Head-ul este unidirectional. Noi nu primim date inapoi pe CAN de la acesta, dar schimbarile sunt vizibile cu ochiul liber pentru semnalul de lumina ambientala spre exemplu. Diodele care emit lumina infrarosie nu pot fi percepute de om.

Atunci cand senzorul este conectat la HIL-Head, modificarea valorilor de pe diodele acestuia, indiferent care, vor fi receptionate de catre senzorul de RLS si vor fi trimise mai departe pe canalul de LIN. Prin configuratia noastra, putem vizualiza valorile receptionate de catre senzor si astfel sa analizam datele si sa calibram senzorul daca este cazul.

Nodul de Interactive Generator (IG) permite transmiterea manuala a mesajelor pe CAN, respectiv pe LIN. Mesajele pot fi transmise atat prin schimbarea valorii si apasarea butonului de send now, cat si setarea unui timer ciclic.

Datele din mesaje pot fi schimbate, dar se pot genera si semnale noi. Se pot transmite valori intre diferite invervale, valori aleatoare, sinus, rampe, impulsuri, variabile de mediu sau definite de user. [701]

Initial pentru testare, am trimis mesajele din IG. Avand realizata baza de date in fisierul HIL.dbc datorita comunicarii cu HIL-Head-ul, am selectat semnalul vizibil de lumina ambientala, caruia i-am modificat valoarea pentru a observa scimbarea hardware ce a avut loc. Se poate observa in poza X 4.5.???, dioda in cauza se afla in partea de jos a imaginii.

Aceste date au fost date manual pentru a verifica comunicarea cu HIL-Head-ul, ca mai apoi cu ajutorul programului scris in CAPL informatiile sa fie luate si transmise prin mesaje pe CAN catre HIL-Head. Codul CAPL aferent se extragerii informatiilor din fisierul de log stocat in aceeasi locatie cu configuratia si trimiterea lor prin mediul de comunicatie se afla in nodul CAN_HIL.

Configuratia pentru comunicarea pe LIN este cea prezentata in figura X 4.5.??? de mai jos:

Configuratia pentru comunicarea pe LIN

Canalul de LIN contine noduri, generatoare interactive, blocuri replay, bazele de date cu mesajele si semnalele de pe LIN, precum si canalele de comunicatie, care in acest caz este setat de tip LIN.

In comunicarea cu senzorul RLS, avem nevoie de un canal de LIN configurat corespunzator. Acesta contine nodul FEM care ii transmite senzorului date si le poate receptiona de la senzorul de RLS.

In orice comunicare pe LIN este nevoie de un nod de tip master si de noduri de tip slave . In configuratia de CANoe, nodul simulat numit FEM este unul de tip master, iar senzorul RLS este slave.

Am folosit IG-ul pentru a testa comunicatia cu senzorul de ploaie si lumina, avand doar senzorul conectat si baza de date deja realizata. Datorita numelui nodului adaugat in configuratia de CANoe, senzorul percepe informatiile primite/trimise de catre el ca fiind o comunicare cu restul masinii.

Informatiile pe care le-am testat pentru a le vedea in fereastra de trace ca se modifica au fost cele de lumina ambientala primita de la HIL-Head.

HIL-Head-ul primeste astfel prin IG de la calculator diferite valori pentru lumina ambientala. Acesta schimba valorile pe diode, rezultand comunicarea optica cu senzorul de RLS. Senzorul trimite pe LIN informatii despre lumina ambientala receptionata pe diode si astfel in fereastra de trace de pe LIN, cu senzorul, se observa modificari ale semnalului respectiv in functie de datele trimise de pe calculator, manual.

Comunicatia cu senzorul se face si prin trimiterea de date cu ajutorul mesajelor si semnalelor sau receptionarea acestora prin cod CAPL scris in blocul FEM din configuratia de LIN.

Modelul pentru HIL-Head

Modelul realizat in Simulink pentru HIL-Head are rolul de a receptiona mesajele din mediul de transmisie, de pe CAN si a le transmite mai departe HIL-Head-ului prin intermediul unor locatii din memorie.

Cele patru blocuri de eCAN Receive notate de la 1 la 4 sunt blocurile care receptioneaza mesajele pe CAN. Pentru ca acestea sa fie intelese in model si folosite mai departe, mesajele sunt despachetate in semnalele continute de mesaje prin blocurile de despachetare.

In blocurile de despachetare denumite HIL command from PC, notate de asemenea de la 1 la 4, unul pentru fiecare mesaj pe can, acestea despacheteaza in semnalele corespunzatoare. Ca si setari ale blocului, acesta primeste ID-ul mesajului pe CAN a carei informatie o primeste, dar si informatiile despre cum trebuie despachetat mesajul.

Pentru a despacheta un mesaj, este necesara cunoasterea informatiilor codate de catre acestea. Informatiile precum bit-ul de start al unui semnal in mesajul care il contine si lungimea acestuia sunt absolut necesare pentru intelegerea datelor transmise. Calcularea valorii semnalului se face automat in interiorul blocului.

Informatiile despre construirea semnalelor pot fi date manual in interiorul blocului sau prin fisierul .dbc deja configurat. Cum anterior, in capitolul 4.5.2 ?? am configurat deja fisierul .dbc pentru comunicarea pe CAN, am dat calea acestuia in interiorul blocului pentru despachetarea semnalelor.

Avem acum semnalele necesare la iesirile blocurilor HIL command from PC. Acestea contin valorile necesare HIL-Head-ului pentru a modifica valorile de pe diodele emitatoare, ca mai departe senzorul RLS sa citeasca valori pe diodele receptoare formand diferite profile de ploaie sau lumina.

In blocul albastru, numit WriteExternalDACs din figura X se scriu valorile semnalelor primite pe CAN intr-o memorie externa de date. Informatiile scrise sunt preluate si transformate de catre DAC-uri (Digital to Analog Converter) in semnal analogic pentru a comanda diodele existente pe HIL-Head.

Model Simulink pentru HIL-Head

Extragerea și trimiterea datelor

Informatiile care ajung la senzorul de RLS sunt date reale colectate de pe masina de test. Aceste date au fost inregistrate in diferite conditii de ploaie si lumina pentru a verifica functionalitatea produsului in timp real.

Fisierele de log care au fost inregistrate, nu au mai fost pana acum rulate din nou pe senzor. Cu ajutorul unui tool de evaluare, stiind informatii despre conditiile pe care a functionat senzorul pe masina, se pot verifica anumite valori de semnale, daca acestea se incadreasa intre anumite valori, cand si daca au trecut in anumite stari cu anumite valori sau chiar sa nu fie setate cu anumite valori.

Toate aceste date sunt preluate astfel de CANalyzer si stocate intr-un fisier cu format .mdf. Pentru a fi mai usor de inteles si de a extrage informatiile din acesta, el a fost transformat intr-un fisier ASCII.

Formatul fisierului este precum un tabel. Pe prima linie se afla informatiile despre semnalele continute. Numele acestora sunt scrise pe prima linie din fisier, separate prin punct si virgula (";"). Restul liniilor contin valorile pentru toate semnalele. Fiecare linie contine un numar de valori egal cu numarul de semnale, despatite de asemenea precum semnalele de punct si virgula (";").

Exemplu de fisier de log:

Timpul[s]; Semnal1[]; Semnal2[]; Semnal3[]; […] SemnalN[];

0,024790;128,000000;36,000000;255,000000; […] 100,000000;

0,045160;125,000000;38,000000;255,000000; […] 120,000000;

0,064500;123,000000;36,000000;253,000000; […] 180,000000;

…

In continuare, datele din fisierul de log trebuie extrase, procesate si trimise pe CAN catre HIL-Head. Acesti pasi sunt realizati prin intermediul limbajului de programare CAPL.

Limbajul CAPL este asemanator ca sintaxa cu limbajului C, nefiind greu de inteles, dar ii este inferior acestuia, lipsindu-i tipuri de baza si functii.

In general, codul este scris in nodul din configuratia de CANoe; pentru ca mesajele sa fie trimise pe CAN, acesta trebuie sa fie scris intr-un nod din configuratia de CAN, respectiv LIN pentru comunicatia pe LIN. In aceste cazuri, codul pentru transmiterea mesajelor pe CAN a fost scris in CAN_HIL, respectiv in FEM pentru mesajele pe LIN la senzorul de RLS.

Structura unui program CAPL este impartita in trei sectiuni. Prima sectiune este de include, in care se adauga fisiere externe sau biblioteci. Urmeaza sectiunea de variabile, semnificand variabilele globale ale programului, care pot fi vazute de orice functie, definite prin keyword-ul static in C. Ultima sectiune este cea de functii.

Prima parte in care s-ar include diferite fisiere la noi lipseste deoarece nu avem nevoie de fisiere sau biblioteci externe.

CAPL-ul fiind un limbaj bazat pe evenimente foloseste mesajele de CAN si LIN pe care le poate trimite sau receptiona si executa functii in urma acestor activitati.

HIL-Head-ul nu este configurat sa primeasca mesaje pe CAN, el doar citeste informatiile de la o adresa din memoria externa si modifica valorile pe diode. Din aceste considerente, ID-urile mesajelor de pe CAN nu sunt fixate. Tinand cont de modelul realizat in Simulink, prin care se receptioneaza mesajele de pe CAN, apoi sunt despachetate semnalele si valorile acestora sunt puse la adrese din memorie, ID-urile le-am ales atunci cand am facut modelul. Datele pentru profilul de ploaie se gasesc in mesajele cu ID-ul trei, cele de lumina in patru si sase, iar cele de umiditate in mesajul cinci.

Din fiecare linie cu valori din fisierul de log, sunt luate doar datele necesare. Pentru transmiterea pe CAN, aceste informatii sunt doar pentru comunicarea cu HIL-Head-ul. Structura semnalelor din nodul CAN_HIL este astfel cea din myStruct.

Valorile extrase din fisiere vrem sa le punem in mesaje pe CAN si sa le trimitem. Este important momentul in care dorim sa le trimitem si perioada de timp dintre trimiterea a doua mesaje de can consecutive. Pentru aceasta avem nevoie de un timer.

Cod de definirea a variabilelor

variables
{
  message 0x03 HIL_RainOut;
  message 0x04 HIL_StaticLight;
  message 0x05 HIL_HUD;
  message 0x06 HIL_Light;
 
  dword readHandle = 0;
  char Buffer[1500];
  char SignalName[50];
  msTimer cyclicTimer;
 

// Structura unei linii din fisier
  struct myStruct
  {
    float time;
    int rain1;
    int rain2;
    int rain3;
    int staticLight1;
    int staticLight2;
    int staticLight3;
    int ambientLight;
    int frontLight;
    int solarLight1;
    int solarLight2;
    int hud;
  };
  struct myStruct signals;
}

Bazat pe evenimente, la pornirea simularii (on start) codul aflat in acesta sectiune este executat primul. Aici am setat calea si numele fisierului de log din care vom prelua datele necesare pentru comunicarea cu HIL-Head-ul si cu senzorul de RLC.

Codul executat la pornirea simularii:

on start
{

// Setarea caii fisierului
  setFilePath("C:\\Users\\mastiu1\\Desktop\\RLS\\CANoe cfg\\RLS HIL CANoe configuration ", 1);
  // Deschiderea fisierului pentru citire
  readHandle = openFileRead ("LogFile.txt", 0);
}

In urmatorul subcapitol voi prezenta interfata realizata pentru testare. Acolo, prin apasarea unui buton pentru transmisia pe CAN sau pe LIN, se seteaza cate o variabila de sistem. Prin aceasta variabila inseamna ca butonul a fost apasat, iar noi in cod folosim un listener pentru a executa codul. O parte din cod de afla in X123.

on sysvar_update RLS::logCAN

Prin executarea codului se preia din fisierul de log doar header-ul, capul de tabel cu numele semnalelor.

Verificarea din if se face pentru a nu fi ajuns deja la sfarsitul fisierului, iar datele intoarse de catre functia de citire sa nu fie zero.

Prin variabila Buffer se stocheaza toata linia pentru a fi procesata mai departe.

In for se verifica fiecare caracter, delimitand numele semnalelor prin caracterul punct si virgula si retinandu-le in SignalName.

X123 Cod in listener-ul pentru variabila de sistem logCAN

int index;

if(readHandle != 0 && fileGetString(Buffer, elcount(Buffer), readHandle) != 0 )
  {
    for(index=0;index<strlen(Buffer);index++)
    { […] }

}
  setTimer(cyclicTimer,500);

Pentru a citi in continuare urmatoarele linii, vom folosi un timer. Odata linia cu valori pentru semnale citita, ea este impartita si sunt extrase semnalele necesare, ca mai apoi acestea sa fie trimise pe CAN prin mesaje.

Mesajele trimise prin mediul de comunicatie au un delay intre ele. De exemplu, senzorul trimite ciclic informatiile pe care le inregistreaza o data la 5 milisecunde. In acest scop am folosit timerele din CAPL.

Odata cu apasarea butonului din interfata grafica pentru a trimite mesajele pe unul din mediile de comunicatie, acesta intra in executarea codului de la listener-ul respectiv, cel prezentat cu cateva randuri mai sus. Dupa ce prima linie din fisierul de log este citita, este activat un timer.

Timerul cyclicTimer de tipul msTimer

Apelul timerului:

on timer cyclicTimer
{
  int index;
  int starti;
  int i;
  char signalValueStr[20];
  long signalValue;
  int nrSignal;
  write("!!!!Timer");
  if(readHandle != 0 && fileGetString(Buffer, elcount(Buffer), readHandle) != 0 )
  {
    write("DATA %s", Buffer);
    nrSignal = 0;
    for(index=0;index<strlen(Buffer);index++)
    {
      starti = index;
      while(index<strlen(Buffer) && Buffer[index]!=';')
      {
//        if(Buffer[index]!=',')
//          signalValueStr[index-starti] = '.';
//        else
          signalValueStr[index-starti] = Buffer[index];
        index++;
      }
      signalValue = atol(signalValueStr);
      nrSignal++;
      switch (nrSignal)
      {
        case 1:
          signals.time = signalValue;
          break;
        case 2:
          signals.ambientLight = signalValue;
          break;
        case 5:
          signals.frontLight = signalValue;
          break;
          default: break;
      }
      SendMessagesCAN();

      write("SIGNAL %d VALUE %d", nrSignal, signalValue);
      for(i=0;i<strlen(signalValueStr);i++) signalValueStr[i] = ' ';
    }
    write("ALL: %d, %d, %d, %d", signals.time, signals.ambientLight, signals.frontLight, signals.rain1);
  }
  setTimer(cyclicTimer,500);
}

Trimiterea mesajelor pe can:

SendMessagesCAN()
{
  HIL_RainOut.HIL_RainOut1 = signals.rain1;
  HIL_RainOut.HIL_RainOut2 = signals.rain2;
  HIL_RainOut.HIL_RainOut3 = signals.rain3;
  output(HIL_RainOut);
 
  HIL_StaticLight.HIL_StaticLight1 = signals.staticLight1;
  HIL_StaticLight.HIL_StaticLight2 = signals.staticLight2;
  HIL_StaticLight.HIL_StaticLight3 = signals.staticLight3;
  output(HIL_StaticLight);
 
  HIL_Light.HIL_AmbientLight = signals.ambientLight;
  HIL_Light.HIL_FrontLight = signals.frontLight;
  HIL_Light.HIL_SolarLight1 = signals.solarLight1;
  HIL_Light.HIL_SolarLight2 = signals.solarLight2;
  output(HIL_Light);
}

Interfața grafica

Utilizatorul, in acest caz tester-ul, trebuie sa aiba o interfata cat mai "user friendly", si daca se poate, totul cat mai automatizat.

Interfata este realizata cu Panel Designer, din CANoe.

-> setarea starii initiale eventual

-> setarea semnalelor

-> trimiterea pe CAN si LIN a info

De luat imaginea de la lucru:

Interfata grafica

Datele de la RLS

Code Composer Studio 3.3

Senzorul RLS montat cu HIL-Head-ul

Probleme întampinate și rezolvarea lor

Citirea din fisier cu CAPL. nu citeste mai mult de 30,000 de linii.. log-urile au peste 200,000. =>un script care sa-l imparta in mai multe fisiere sau punerea fisierului pe RCP si citirea lui in MATLAB + trimiterea mesajelor pe CAN din model.

o config de CANoe cu 2 canale de CAN si de LIN sau 2 fiecare cu cate un canal???

CANoe run/ CANoe full / Keyman Dongle

Fisier MDF -> ASCII

Modificarea numelui fisierului mdf si a locatiei din interfata si nu din CAPL

x

x

x

Rezultate generale

Mesaje pe CAN trimise la HIL-Head

Mesajele de pe LIN de la senzor

Concluzii

A inceput sa se foloseasca si LabVIEW??? – o alternativa mai buna? [305]

Direcții de continuare a dezvoltării sistemului

-> simulare RAIN -> model in MATLAB/Simulink

-> imbunatatirea procesului prin???

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

Bibliografie

[0] Documentatie HELLA

Jennifer Healey – TED Talks – If cars could talk, accidents might be avoidable -> http://www.ted.com/talks/jennifer_healey_if_cars_could_talk_accidents_might_be_avoidable?language=en

[200] Klaus Grimm – Software Technology in an AutomotiveCompany – Major Challenges {grimm.pdf}

[201] Manfred Broy – Challenges in Automotive Software Engineering {p33.pdf}

[202] Performance Boundaries of Massive Floating Car Data Offloading – Silvia Ancona, Razvan Stanica, Marco Fiore {ECUs-2014_hal.pdf}

[203] William J. Fleming – New Automotive Sensors – A Review (IEEE SENSORS JOURNAL, VOL. 8, NO. 11, NOVEMBER 2008)

[204] Automotive Hardware Development According to ISO 26262, Seo-Hyun Jeon, Jin-Hee Cho, Yangjae Jung, Sachoun Park, Tae-Man Han

[209] http://www.hella.com/microsite-electronics/143.html

http://www.slideshare.net/GvAnu90/rain-light-sensor

http://papers.sae.org/2010-01-0296/

http://www.automotivesensors2015.com/

[300] http://www.ni.com/white-paper/10343/en/

[305] Rapid Control Prototyping using MATLAB/Simulink and a DSP-based MotorController, Darko Hercog, Karel Jezernik {RCP.pdf}

https://www.google.com/patents/US6326613

[400] http://en.wikipedia.org/wiki/MATLAB

[500] http://en.wikipedia.org/wiki/Simulink

[501] http://www.mathworks.com/help/simulink/gs/model-based-design.html

[505] http://www.mathworks.com/products/communications/

[506] http://www.mathworks.com/products/dsp-system/

[510] http://www.signum.com/Signum.htm?p=c2000.htm

[511] http://www.signum.com/images/pdf/jet_c2000.pdf

[600] http://en.wikipedia.org/wiki/Vector_Informatik

[610] https://vector.com/portal/medien/cmc/info/CANalyzer_ProductInformation_EN.pdf

[700] https://www.vector.com/portal/medien/vector_cantech/faq/ProgrammingWithCAPL.pdf

[701] http://www.vector.com/portal/medien/cmc/manuals/CANoe75_Manual_EN.pdf

Test-System Development Guide A Comprehensive Handbook for Test Engineers

Designing Automated Test Systems A Practical Guide to Software-Defined Test Engineering

Anexe

Listă abrevieri:

RLS – Rain Light Sensor

CAN – Controller Area Network

CAPL – CAN Access Programming Language

MOST – Media Oriented System Transport

LIN – Local Interconnect Network

RCP – Rapid Control Prototyping

DAC – Digital to Analog Converter

HIL – Hardware-in-the-Loop

BCM – Board Control Module

ECU – Electronic Control Unit

ISO – International Organization for Standardization

ASIL – Automotive Safety Integrity Level

DSP – Digital Signal Processor

MCU – Microcontroler

TLC – Target Language Compiler

CCS – Code Composer Studio

.dbc – DataBase CAN

.ldf – LIN Description File

IG – Interactive Generator

Listă figuri:

Listă tabele: