Echipament DE Testare A Senzorilor

ECHIPAMENT DE TESTARE

A SENZORILOR

(STU – Sensor Tester Unit)

CUPRINS

CUPRINS

1 Capitolul I: Noțiuni generale

1.1 Introducere

1.2 Tipuri de senzori utilizați de Hella

1.3 Aplicațiile unde sunt utilizați senzorii Hella

1.4 Obiectivele lucrării

2 Capitolul II: Principalele caracteristici ale STU

2.1 Tipuri de comunicații

2.1.1 Local Interconnect Network (LIN)

2.1.2 Universal Asynchronous Receiver/Transmitter (UART)

2.1.3 Serial Peripheral Interface (SPI)

2.1.4 Tipul de comunicație RS232

3 Capitolul III: Achiziția datelor și afișarea acestora

3.1 Tipuri de parametrii ce pot fi afișați și utilizarea lor în practică

3.2 Meniu display

3.3 Testarea valorilor afisate pe display utilizând CANoe

3.4 Pachetele de semnale obținute pe LIN

4 Capitolul IV: Interfață grafică pentru conexiunea UART

4.1 Crearea interfeței grafice utilizând CVI

4.2 Utilizarea interfeței grafice în practică

Concluzii și contribuții

Referințe

Table of figures

Capitolul I: Noțiuni generale

Introducere

Senor Tester Unit este utilizat ca un dispozitiv de testare/achiziționare de date .

Se conecteaza un sensor (IBS, RLS, AQS, Oil sensor) și cu ajutorul comunicatiei LIN datele sunt transmise catre STU(Sensor Tester Unit).

Acesta sunt afisate pe un display (4 linii, 20 coloane).

Totodata, printr-o comunicație serială, datele pot fi vizualizare și reprezentate grafic cu ajutorul tool-ului CVI (aici a fost creată o interfață grafică care permite selectarea tipului de sensor și a semnalelor care pot fi reprezentate grafic).

Figure 1: STU (Sensor Tester Unit)

Tipuri de senzori utilizați de Hella

IBS – Intelligent Sensor

Senzorul de baterie se montează pe borna negativa a bateriei. Acesta transmite informații catre un ECU central care după ce le interpretează , transmite mai departe anumite informații care sa asigure buna fnuctionare a sistemului.

De cele mai multe ori, datorită consumului ridicat din masină, aceasta nu mai porneste sau anumite functionalitați nu mai răspund la comenzi.

Unele dintre datele cele mai importante pe care le poate furniza IBS-ul sunt:

– tensiunea de la baterie

– curentul(este determinat cunoscand voltajul si rezitenta interna)

– temperatura

– starea de încarcare a bateriei (SOC) – o baterie descarcata va conduce automat la probleme de pornire a autovehiculului

– strarea de sănatate a bateriei – bateria este supusă mai multor procese de incarcare/descarcare a baterie si acest lucru va conduce la distrugerea acesteia in timp

Putem lua de exemplu cazul in care deshiderea masinii se face pe baza unui senzor care determină cand proprietarul este in apropierea mașinii si doreste deblocarea usilor. O incorectă alimentare a acestui senzor va duce la incapacitatea acestuia de a intra in masină.

Cunoscând toți acesti parametrii se pot evita anumite probleme de service, ceea ce va conduce automat și la reducerea costurilor.

Figure 2: IBS (Intelligent Sensor)

RLS – Rain Light Sensor

Senzorul de ploaie activează automat stergătoarele în cazul în care pe parbrizul mașinii sunt detectați stropi de apă. De asemenea, viteza de stergere este direct proporțională cu cantitatea de apa de pe parbriz si anume: cu cat plouă mai tare, cu atat viteza stregatoarelor crește.

Acest lucru va conduce automat la un confort crescut pentru șofer si totodata asigură o sigurantă sporită în timpul condusului.

Un alt avantaj al acestui sensor este dat de faptul că este capabil sa detecteze gradul de iluminare. Astfel, la intrarea intr-un tunel, farurile sunt aprinse automat, iar instrumentele de bord sunt iluminate corespunzator.

Figure 3: RLS (Rain Light Sensor)

PULS

Senzorul de ulei masoară nivelul uleiului si temperatura acestuia. Metoda utilizată pentru masurare este bazată pe un principiu ultrasonic. Acesti doi paremetrii, nivelul si temperatura uleiului sunt monitorizate în timpul în care autovehicolul are moturul pornit, dar si cât motorul este oprit. Există mai multe situații de montare a acestui senzor. Toate informațiile colectate de la acest senzor vor fi transmise catre unitatea centrala (ECU).

Alimenterea senzorului se face fie de la baterie, fie direct de la unitatea centrală la care acesta transmite datele. Temperatura de funcționare este de -40 …150 grade Celsius.

Figure 4: PULS (Packaged Ultrasonic Oil Level Sensor)

AQS

Senzorul de calitate a aerului din masină este foarte important pentru confortul șoferului si al pasagerilor în timpul utilizării autovehicului.

Acesta este capabil sa detecteze temperatura din exterior, precum si cea din interiorul habitaclului, dar si umiditatea. Datele colectate sunt de asemenea transmise unitații centrale care dupa interpretarea acestora poate da anumite comenzi catre unitătile periferice.

Figure 5: AQS (Air Quality Sensor)

Aplicațiile unde sunt utilizați senzorii Hella

Hella Romania are ca domeniu de activitate industria automotive. Compania are mai multe divizii, cum ar fi divizia de “lighting” sau cea de “electonics”.

Astefel, majoritatea senzorilor utilizați fac parte din cei corecpunzători industriei automotive. Aici putem menționa câțiva dintre cei mai importanți și anume:

IBS (Intelligent Battery Sensor) – senzorul de baterie

RLS (Rain Light Sensor) – senzorul de ploaie

AQS (Air Quality Sensor) – sonzor pentru climatul din mașină

PULS (Packaged Ultrasonic Oil Level Sensor) – senzorul de ulei

Obiectivele lucrării

Consumul foarte mare care există în mașinile din ziua de astăzi ne obligă să utilizăm dispozitive suplimentare care să asigure buna funcționare a tuturor consumatorilor. Ținându-se astfel cont de multitudinea de ECU-uri aceste dispozitive sunt utilizate mai ales pentru a ajuta în faza de proiectare a sistemului, respectiv la colectarea continuă a datelor din faza de testare.

Echipamentul de testare a senzorilor sau STU(Sensor Tester Unit )așa cum a fost numit, este creat pentru a colecta date de la diferiți senzori care se gasesc pe mașină.

De cele mai multe ori astfel de dispozitive de testare se conectează la un calculator sau au un slot de card unde pot fi stocate date pe o anumită perioadă. Aceste date sunt colectate mai apoi de inginerii de test, care la apriția unei defecțiuni sau a unei funcționalități incorecte, pot detecta eroarea mult mai rapid și mai usor.

Capitolul II: Principalele caracteristici ale STU

Tipuri de comunicații

Local Interconnect Network (LIN)

LIN (Local Interconnect Network) este un concept pentru retelele de automatizare cu cost redus, care completeaza soluțiile existente de rețele de automatizare. LIN a fost un factor decisiv pentru implementarea rețelelor ierarhice de automobile, cu scopul de a se obține câstiguri viitoare încalitate și reducerea costurilor vehiculelor. Standardizarea va reduce numărul de soluții low-end și va micșora costurile de dezvoltare, producție, service, și logistică înelectronica vehiculelor.

Istoric

In 1999 a fost publicata revizia LIN 1.0 și a fost puternic influențată de magistrală VLITE folosita de companiile automatizate. Standardul LIN a fost actualizat de două ori înanul 2000, rezultând LIN 1.2 înnoiembrie 2000. In noiembrie 2002 consorțiul LIN a lansat standardul LIN 1.3. Au fost facute modificări la Nivelul Fizic care urmareau imbunatățirea compatibilitații dintre noduri. LIN 2.0 este un pas imens fata de predecesorul, LIN 1.3. Nodurile proiectate pentru LIN 2.0 și LIN 1.3 comunica unul cu celalalt cu mici excepții.

Apariția reviziei 2.1 a fost datorata credinței ca compatibilitatea este foarte importantă. LIN 2.1 este un superset al lui LIN 1.3. In LIN 2.1 nodul master poate manevra clustere constănd atat înslave-uri LIN 1.3 cat și LIN 2.1. Master-ul va evita astfel cererea caracteristicilor de LIN 2.1 de la un slave LIN 1.3 :

Checksum marit;

Reconfigurare și diagnoză;

Detecție automata de baudrate;

Monitorizarea starii Response_error.

Nodurile slave LIN 2.1 nu pot opera cu noduri LIN 1.3 (master-ul LIN 1.3 nu suportă checksum-ul mărit de la LIN 2.0)

Caracteristici

Standardul LIN include specificatiile protocolului de transmisie, mediul de transmisie, interfața dintre utilitarele de dezvoltare și interfața pentru programarea software.

LIN este un protocol serial de comunicatie, care suporta controlul nodurilor mecatronice dînaplicațiile de automatizare ditribuită.

Principalele caracteristici ale magistralei LIN sunt:

Conceptul cu un singur master și mai mulți slave;

Implementarea siliconului la un preț scăzut, bazată pe interfața hardware UART/SCI, un echivalent însoftware.

sincronizare automata, fără un rezonator de cermică sau quartz înnodurile slave.

Transmisie deterministă de semnal cu calculul apriori a timpului propagării semnalului.

Implementare cu cablu cu un singur fir (cost redus).

Viteze de pana la 20 kbit/s.

Reconfigurabilitate

Nivel de Transport și suport pentru diagnoză.

LIN ofera o comunicație de magistraă cu cost scazut, unde lațimea de bandă și suplețea protocolului CAN nu sunt necesare. Specificațiile liniei motor/receptor au la baza standardul ISO 9141 cu unele schimbari referitoare la EMI.

Configuration Language Specification permite o accesare sigură a nodurilor fără a primejdui funcționalitatea sistemului LIN prînincompatibilitatea de mesaje sau supraincăracarea retelei. Este un utilitar puternic pentru depanarea unui cluster LIN, inclusiv emularea nodurilor neterminate.

Node Capability Language Specification, ofera o sintaxa standardizata pentru specificatiile nodurilor slave. Aceasta va simplifica obtinerea nodurilor Standard slave cât și posibilitatea de a asigura utilitarelor acea generare automata de clustere. Astfel posibilitați reale de Plug-and-Play a nodurilor slave pot deveni o realitate.

Figure 6: Structura nodurilor intr-o rețea

Nodurile slave sunt conectate la nodul master formand un cluster LIN. In procesul de proiectare a cluster-ului LIN, fisierul cu capacitatea corespunzatoare a nodului, este analizata de utilitarul de proiectare a cluster-ul LIN, care generează un fisier cu descriere LIN (LDF). Fisierul LDF este analizat de generatorul de cluster care genereaza automat functii speciale LIN înnodurile dorite (Nodul Master și nodul Slave3 dînexemplul de mai sus). Fisierul LDF este folosit și de un utilitar analizor/emulator de magistrală LIN, pentru a permite depanarea cluster-ului.

Conceptul de nod

Fluxul de lucru descris mai sus generează un modul complet de interacțiune de cluster LIN și proiectantul nu trebuie decât sa furnizeze aplicației decât funcțiile logice a unui nod. Desi multe dînspecificatiile LIN presupun o implementare software a majoritații funcțiilor, sunt incurajate și relizari alternative.

Telegramele nu sunt accesate direct de o aplicație; un nivel interacțiune bazat pe semnal este adugat între aceastea. Complementar exista o interfață a Nivelului de Transport între aplicație și manipulatorul de telegrame.

Figure 7: Modalitatea de transport a datelor

Conceptul de funcționare Master și Slave

Un cluster constă intr-o sarcina master și mai multe sarcini slave. Un nod master conține sarcina master cat și o sarcina slave. Toate celelalte noduri slave conțînnumai o sarcina slave. Un nod poate parțicipa înmai mult de un cluster. Termenul de nod este asociat unei singure interfețe de magistrală a unui nod, dacă nodul are mai multe interfețe de magistrală.

Figure 8: Cluster cu un nod master și două noduri slave

Sarcina master decide când și care telegramă va fi transferata pe magistrală. Sarcina slave asigura datele transportate de fiecare telegramă. Atât sarcina master cat și cea slave sunt părți dînmanipulatorul de telegrame.

Telegrama

O telegramă constă într-un header (oferit de sarcina master) și într-un răspuns (oferit de o sarcină slave).

Header-ul constă într-un câmp de pauză și un câmp de sync urmat de identificatorul de telegramă. Identificatorul de telegramă definește în mod unic scopul telegramei. Sarcina slave numita sa asigure răspuns impreuna cu identificatorul de telegramă,na master cat și o sarcina slave. Toate celelalte noduri slave conțînnumai o sarcina slave. Un nod poate parțicipa înmai mult de un cluster. Termenul de nod este asociat unei singure interfețe de magistrală a unui nod, dacă nodul are mai multe interfețe de magistrală.

Figure 8: Cluster cu un nod master și două noduri slave

Sarcina master decide când și care telegramă va fi transferata pe magistrală. Sarcina slave asigura datele transportate de fiecare telegramă. Atât sarcina master cat și cea slave sunt părți dînmanipulatorul de telegrame.

Telegrama

O telegramă constă într-un header (oferit de sarcina master) și într-un răspuns (oferit de o sarcină slave).

Header-ul constă într-un câmp de pauză și un câmp de sync urmat de identificatorul de telegramă. Identificatorul de telegramă definește în mod unic scopul telegramei. Sarcina slave numita sa asigure răspuns impreuna cu identificatorul de telegramă, transmite răspunsul. Raspunsul constă într-un câmp de date și un câmp de checksum.

Sarcina slave interesata de datele asociate cu identificatorul de telegramă, recepționează răspunsul, verifica checksum și folosește data transportată.

Figure 9: Task sheduler

Acestea conduc la următoarele caracteristici:

Flexibilitatea sistemului: Pot fi adaugate noduri cluster-ului LIN fără a face modificări hardware sau software în celalalte noduri slave.

Rutare de mesaje: Conținutul unui mesaj este definit de identificatorul telegramei (similar cu CAN).

Multicast: Oricate de noduri pot recepționa simultan și poate acționa pe o singură telegramă.

Transportul datelor

Două tipuri de date pot fi transportate intr-o telegramă: semnale sau mesaje de diagnoză.

Semnale

Semnalele sunt valori scalare sau array-uri de byte care sunt împachetate în câmpul de date din telegrame. Un semnal este prezent întotdeuna în aceeași poziție a câmpului de date pentru toate telegramele cu aceiasi identificator de telegramă.

Un semnal scalar are între 1 și 16 biți. Semnal scalar de 1 bit este numit semnal boolean. Semnalele scalare cu mărimea între 2 și 16 biți sunt tratate ca intregi fără semn.

Un array de byte este un array de 1-8 biți.

Fiecare semnal este scris întotdeuna de același nod din cluster. Nici unul, 1 sau mai multe noduri pot subscrie semnalului.

Toate semnalele au valoari inițiale. Valoarea inițială pentru un semnal editor (publisher) este valabil pana când este receptionata o noua valoare actualizata de la un alt nod.

Mesajele de diagnoză

Mesajele de diagnoză sunt transportate întelegrame cu doi identificatori de telegramă rezervați. Interpretarea câmpului de date depinde de câmpul de date cât și de starea nodurilor care comunică.

Schedule Table

Sarcina master (din nodul master) transmite header-ele pe baza unui orar. Acesta specifica telegramele și intervalul dintre inceputul telegramei și inceputul telegramei urmatoare. Aplicația master poate folosi tabele orar diferite și poate face selectie între ele.

Împachetarea semnalelor

Un semnal este transmis cu LSB la început și MSB la sfârșit. Nu este nici o restricție la împachetarea semnalelor scalare. Fiecare byte dîntr-un array de byte trebuie sa treaca intr-o telegramă cu un singur byte, incepand de la cel mai mic byte de date numerotat.

Intr-o telegramă pot fi impachetatemai multe semnale, atata timp cat nu se suprapun.

Același semnal poate fi impachetat în mai multe telegrame atâta timp cât editorul semnalului este același. Dacă un nod receptionează un semnal împachetat în mai multe telegrame, ultima valoare de semnal receptionata este valida.

Recepția și transmisia semnalului

Momentul încare semnalul este transmis/recepționat trebuie definit pentru a ajuta utilitarele de proiectare și testare înanaliza timpilor semnalelor.

Timing-ul este diferit pentru un nod master fata de slave, pentru ca nodul master controleaza orarul și stie care telegramă va fi transmisă. Un nod slave primeste informația atunci când este transmis header-ul pe magistrală.

Un semnal este considerat recepționat și disponibil pentru aplicație dupa cum urmează:

Nod master – la următorul time base tick dupa lungimea maxima a telegramei. Nodul master actualizează periodic semnalele receptionate la inceputul time base.

Nodul slave – când checksum-ul pentru telegramă recepționata este validat. Nodul slave actualizează semnalul recepționat direct dupa ce telegramă este terminată.

Figure 10: Transmisia/Recepția unui semnal

Un semnal este considerat transmis în situațiile:

Nod master – înainte ca transmisia telegramei sa fie inițiata.

Nod slave – când ID-ul pentru aceeasi telegramă este recepționat

Structura telegramei

Telegrama este alcatuita din mai multe câmpuri: un câmp de pauză urmat de 4-11 câmpuri de byte.

Timpul în care este trimisa o telegramă este timpul insumat al timpilor pentru a trimite fiecare byte plus răspunsul și inter-byte-ul.

Figure 11: Structura unei telegrame

Fiecare câmp de byte, exceptie facând câmpul de pauză, este trimis ca în figura de mai jos. Primul trimis este LSB, ultimul fiind MSB. Bit-ul de start este codat ca bit cu valoarea 1 (regresiv).

Figure 12: Transmisia unui câmp de byte

Campurile header-ului

Brake Field

Folosit pentru a semnaliza începutul unei noi telegrame. Este întotdeuna generat de sarcina master (înnodul master) și trebuie sa fie de cel putin 13 bit time din valoarea dominantă, urmat de un delimitator de pauză (cel putîn1 bit time).

Figure 13: Structura unui brake

Câmpul byte-ului de Sync

Conține informatia pentru sincronizarea de ceas. Are valoarea de 0x55, caracterizat prin cinci creste (regresive și dominante) intr-o distanta de 8 bit time.

Figure 14: Campul byte-ului de Sync

Câmpul identificatorului de protecție

Constâ din două subcâmpuri: identificatorul telegramei și paritatea. Biți 0-5 sunt identificatorul telegramei, iar biți 6-7 sunt paritatea.

Figure 15: Câmpul identificatorului

Identificatorul de telegramă are valori cuprinse între 0 și 63:

0-59 (0x3B) folosit pentru telegramele transportoare de semnal;

60 (0x3C) și 61 (ox3D) folosit pentru transportul datelor de diagnoză și configurare;

62 (0x3E) și 63 (0x3F) sunt rezervate pentru implementari viitoare ale protocolului.

Paritatea este calculata astfel :

Câmpul de Date

O telegramă transporta 1-8 byte de date. Pentru transmisii de date mai mari de 1 byte, LSB este conținut în byte-ul trimis primul iar MSB înbyte-ul trimis ultimul.

Figure 16: Numerotarea de byte de date într-o telegramă cu 8 byte

Checksum

Conține suma celor 8 biți inversată, supra toți biții de date transportați cu sau fără identificator. Calculul checksum fără identificator este folosit pentru telegramă de cerere a master-ului, a slave-ului și comunicatia cu slave-urile LIN 1.x și se numeste clasic checksum. Calculul cu identificator este folosit pentru comunicatia cu slave-urile LIN 2.x și se numeste enhanced checksum.

Telegrame Event triggered

Scopul unei astfel de telegrame este de a mari responsabilitatea cluster-ului LIN fără a atribui prea mult dînlatimea de banda, la apelarea selectiva a nodurilor slave cu evenimente ce apar rar.

Toți abonatii la telegramă event triggered vor receptiona telegramă și vor folosii datele ca și cum telegramă unconditional asociata a fost receptionata. Dacă telegrama unconditional asociata cu telegrama event triggered este prevazută ca o telegramă unconditional, răspunsul va fi întotdeuna transmis.

Header-ul unei telegrame event triggered este transmis când slotul alocat telegramei event triggered este procesat. Editorul al unei telegrame unconditional va transmite numai răspunsul dacă cel putin un semnal transportat în telegramă unconditional este actualizat. Dacă răspunsul este transmis, semnalul nu mai este considerat a fi actualizat.

Dacă nici un nod slave nu răspunde la header, restul slotului telegramei este “silent” și header-ul este ignorat. Dacă mai mult de un nod slave răspunde la header înacelasi slot telegramă va rezulta o coliziune.

Nodul master trebuie sa rezolve coliziunea intr-o tabela orar de rezolvare de coliziuni. Fiecare telegramă event triggered are asociată o tabelă orar de rezolvare a coliziunilor. Trecerea la această tabela se face automat de catre driver-ul dînnodul master. Tabela va fi activata la începutul slotului telegramă următor dupa coliziune.

In aceasta tabela vor aparea toate telegramele unconditional asociate. Tabela poate conține și alte telegrame unconditional decât cele asociate (acestea pot fi de lungimi diferite).

Telegrame Diagnoză

Transporta datele Nivelului de Transport și conțîn8 biți de date. Identificatorul este fie 60, numit telegramă răspuns master, sau 61, numit telegramă răspuns slave. Inainte de transmiterea unei telegramă răspuns master, sarcina master interogheaza modulul de diagnoză dacă sa transmita sau dacă magistrală va fi “silent”. O telegramă răspuns slave este trimisa neconditionat.

Wake-up

Orice nod dîntr-un cluster LIN sleeping, poate cere wake-up (trezirea), prin transmiterea unui semnal de wake –up. Acest semnal este transmis prin fortarea magistralei în starea dominanta pentru 250 μs pana la 5 ms. Nodul master poate emite un câmp de pauză, spre exemplu emiterea unui header, deoarece pauză va actiona ca semnal de wake-up.

Fiecare nod slave va trebui sa detecteze semnalul de wake-up, și sa fie pregatit pentru comenzile magistralei în100 ms. Dacă nodul care a transmis semnalul de wake-up este slave, va fi gata sa receptioneze sau sa transmita telegrame imediat. Nodul master va trebui sa fie și el “treaz” când nodurile slave sunt disponibile, pentru a transmite header-e pentru a afla cauza wake-up-ului.

Dacă nodul master nu transmite câmpul de pauză sau dacă nodul care a emis semnalul de wake-up nu receptioneaza semnalul de wake-up de la alt nod, în intervalul 150-250 ms, nodul care a emis semnalul de wake-up va transmite un nou semnal de wake-up. În cazul în care nodul slave transmite un semnal de wake-up înacelasi timp încare master-ul transmite un câmp de pauză, slave-urile vor trebui sa receptioneze și sa recunoasca acest câmp. Dupa trei cereri nereusite nodul va astepta minim 1.5 secunde inainte de a emite un al patrulea semnal de wake-up. Motivul este de a permite cluster-ului sa comunice în cazul încare nodul slave are probleme.

Go To SLEEP

Master-ul seteaza cluster-ul înmodul sleep prin transmiterea comenzii de sleep. Cererea un va obliga nodurile slave sa între într-un mod low-power.

In cazul încare magistrală este inactiva un nod slave trebuie sa fie capabil sa receptioneze /transmita telegrame pentru 4 s.

Nodul slave trebuie sa intre automat în modul magistralei, de sleep nu mai devreme de 4 s și cel tarziu 10 s de inactivitate pe magistrală (nici o transmisie între valorile de bit dominante și regresive).

Serviciile de Configurare și Identificare a Nodului

Definesc cum se configureaza un nod, și cum se identifica un nod slave folosind serviciul de identificare. Sunt transportate de Nivelul de Transport.

Memoria unui nod slave:

VRAM – invalida dupa reset;

NVRAM – se mentine dupa resetsi poate fi modificata prînprocese interne;

ROM – memorie constănta care nu poate fi modificata prînprocese interne.

Sunt definite trei tipuri de noduri slave :

Noduri slave Neconfigurate – dupa reset nodurile slave nu conțîno configuratie valabila, acesta trebuie configurat de master.(config este memorata înVRAM)

Noduri slave Preconfigurate – aceste noduri au dupa reset o configurare valida.(config este memorata normal înROM)

Noduri slave Configurate Complet – nodul slave memoreaza configuratia înNVRAM, care va fi activa dupa reset.

Toate cererile sunt transportate în telegrame master cerere, și toate răspunsurile sunt transportate în telegrame răspuns slave, folosesc numai telegrame SF. Un nod slave isi va aminti răspunsul la o cerere pana ce o noua cerere este receptionata de la nodul master.

Servicii:

Asignare NAD (Node Address) – folosit pentru a rezolva conflictele de adrese NAD dîncluster folosind noduri slave noi sau refolosite.

Conditional change NAD – folosit pentru a detecta noduri slave necunoscute într-un cluster și de a le separa NAD-ul. Apariția acestor noduri necunoscute, este datorată asamblarii incorecte la crearea cluster-ului sau o inlocuire incorecta a unui slave întimpul service-ului.

Data dump – folosit pentru configurarea initiala a nodului slave de catre furnizorul de noduri.

Salvarea configuratiei – acest serviciu informeaza nodul slave ca aplicatia slave va salva configuratia curenta.

Asignarea clasei de identificare pentru telegramă – folosit pentru a elimina PID-uri de pana la patru telegrame

Universal Asynchronous Receiver/Transmitter (UART)

Transmisia de date.Notiuni de baza

Prin comunicație de date se ințelege schimbul de informație numerică codificată între două DTE.

Trebuie făcută distincția între termenii "dată" și "informație". Termenul "dată" este folosit pentru a desemna un set sau un bloc de caractere numerice sau alfabetice codificate ce sunt schimbate între două echipamente. In cadrul comunicației de date înafară transferului acestui tip de date este de asemenea necesar ca cele două echipamente să schimbe și diverse mesaje de control (de exemplu pentru a preveni sau corecta erorile de transfer). De aceea termenul de informație este folosit cu un inteles mai larg desemnând atât date cât și mesaje de control.

Comunicația de date se ocupă nu numai cu modul de transmisie a datelor prîntr-un mediu de transmisie fizic ci și cu tehnicile ce trebuie folosite pentru detectarea și corectarea erorilor de transmisie, cu controlul ratei de transfer a datelor și stabilirea formatului datelor ce trebuie transferate.

Dînpunct de vedere al numărului de linii ce interconectează două echipamente se deosebesc două tipuri de conexiuni:

modul de transfer paralel presupune folosirea câte unui fir pentru fiecare bit de date (al unui cuvânt). Aceasta inseamnă că mai multe fire sunt folosite pentru interconectarea a două DTE. Din acest motiv modul de transfer paralel nu se folosește decât în cazul în care distanța între DTE este mică.

modul de transfer serial presupune folosirea unei singure perechi de fire pentru interconectarea echipamentelor.

La un moment dat pe linie se transmite un singur bit, pentru fiecare bit fiind alocat un interval de timp fix. Viteza de transfer este mai mică decât încazul 1 dar distanța între DTE poate fi mult mai mare.

Comunicația de date între două echipamente se poate realiza în trei moduri:

simplex: presupune transmisia datelor intr-o singură direcție.

half-duplex: presupune transferul de date alternativ între cele două echipamente. Când unul dînechipamente se află înstarea de emisie celălalt se află înrecepție.

duplex (full-duplex): presupune schimbul de date înambele direcții simultan.

Comunicația între două echipamente poate fi de două tipuri:

1) asincronă – dacă ceasul receptorului este independent de cel al emițătorului.

2) sincronă – dacă ceasurile emițătorului și receptorului sunt sincrone.

În cazul în care datele ce trebuie transmise sunt formate din caractere separate de intervale de timp de lungime aleatoare atunci fiecare caracter este transmis ind ependent și receptorul se sincronizează la inceputul fiecărui nou caracter primit. Pentru acest tip de comunicație se folosește transmisia asincronă.

În cazul încare datele ce trebuie transmise sunt formate din blocuri conținând mai multe caractere (octeți) fiecare, ceasurile emițătorului și receptorului trebuie să se afle în sincronism pentru mai mult timp și de aceea se folosește transmisia sincronă.

Transmisia asincronă

Această metodă este folosită atunci când datele ce trebuie transmise sunt generate la intervale de timp aleatoare de exemplu atunci când un utilizator comunică de la un videoterminal cu un calculator. In acest caz intervalul de timp între două caractere tastate este de lungime aleatoare. Aceasta inseamnă că pe linia de transmisie semnalul va fi pentru un timp mai lung înstarea de idle (off).

În cazul acestui tip de comunicare este necesar ca receptorul să fie capabil să se resincronizeze la începutul fiecărui nou caracter recepționat. Pentru a realiza acest lucru trebuie ca fiecare caracter să fie incadrat de un bit de start și unul sau mai mulți biți de stop.

Figure 17: Transmisia asincronă

Așa cum se poate observa în figură polaritatea bitului de start este diferită de cea a biților de stop. Astfel se asigură cel puțin o tranziție (1-0-1) între două caractere consecutive indiferent de secvența de biți ce trebuie transmisă. Prima tranziție 1-0 după un interval de linie liberă este folosită de echipamentul receptor pentru a determina inceputul fiecărui nou caracter.

In plus, folosind un ceas cu o frecvență de N ori mai mare decât frecvența de emisie (de obicei N=16), echipamentul receptor poate determina mai exact valoarea fiecărui bit transmis prin eșantionarea semnalului recepționat aproximativ încentrul fiecărei celule bit.

Din cele prezentate rezultă că pentru transmiterea unui octet de informație utilă se folosesc de fapt 10 sau 11 biți. Deci, dacă presupunem o rată de emisie de 1200 bps atunci în cazul folosirii a doi biți de stop se obține o rată de 1200/11 aprox. 110 bytes pe secundă. Rata de emisie folosită în realitate este de fapt mai mică din motive ce vor fi discutate mai târziu.

Când se definește rata de emisie a unei linii se folosește de obicei termenul "baud". In înțelesul său corect, termenul indică numărul de tranziții pe secundă ale semnalului transmis pe linie. În cazul în care fiecare element de semnal poate lua numai două valori atunci baud este echivalent cu bps. În unele cazuri se folosesc mai mult de două nivele pentru un element de semnal (un element de semnal codifică mai mulți biți). Astfel, un semnal cu o rată de 300 baud și 4 biți pentru un element de semnal poate fi folosit pentru transmisia informației cu o rată de 1200 bps.

Transmisia sincronă

In cazul transmisiei asincrone folosirea biților adiționali (de start și stop) este nesemnificativă datorită intervalelor mari de timp între două caractere.

Uneori este necesară însă transmisia unor blocuri de date de lungime mare (transmisia de fișiere între două calculatoare). In acest caz folosirea biților suplimentari la fiecare caracter devine supărătoare.

Totodată, datorită mecanismului de sincronizare folosit de schema asincronă, aceasta nu poate funcționa fără erori decât până la aprox. 19200 bps.

Alternativa eficientă înaceste situații este transmiterea unui bloc complet ca o singură entitate, adică transmisia sincronă.

Pentru a permite echipamentului receptor să se sincronizeze trebuie respectate condițiile:

fluxul de biți transmis să fie astfel codificat incât receptorul să poată fi menținut însincronism la nivel de bit;

toate blocurile transmise să fie precedate de unul sau mai multe caractere speciale astfel incât la recepție să poată fi delimitați corect octeții (sincronism la nivel de caracter);

conținutul fiecărui bloc să fie delimitat de o pereche de caractere speciale.

Figure 18: Transmisia sincronă

Ultima condiție permite receptorului să determine începutul unui nou bloc atunci când a primit un caracter special (de start) după o perioadă liberă.

În intervalul de timp dintre două blocuri, fie sunt transmise continuu caractere de sincronizare (pentru a intreține sincronismul receptorului la nivel de bit și byte), fie blocurile sunt precedate de unul sau mai mulți octeți de sincronizare (permițând astfel receptorului să revină însincronism).

In cadrul transmisiei sincrone este necesar să se asigure că octeții sau caracterele de sincronizare să fie unice adică să nu fie prezente și înconținutul blocului ce se transmite.

Serial Peripheral Interface (SPI)

SPI este un standard sincron (ca și I2C) dezvoltat de Motorola ce opereaza în mod full-duplex (transferul de date are loc în ambele directii simultan). Device-urile comunică folosind o relatie de tipul master/multi slave (nu sunt suportati mai multi masteri) master-ul fiind cel care initiaza frame-urile de date.

SPI se mai numeste și "four wire" serial bus pentru al deosebi de celelalte standarde ce folosesc 1, 2 sau 3 fire. Cele 4 fire

SCLK — Serial Clock ( output from master)

MOSI/SIMO — Master Output, Slave Input (output from master)

MISO/SOMI — Master Input, Slave Output (output from slave)

SS — Slave Select (active low; output from master)

Figure 19: Transmisia “four wire”

Se poate observa ca de data aceasta avem două fire pe care se transmit date (MOSI și MISO). De asemenea, slave-ul este selectat direct prin intermediul semnalului SS, pentru fiecare slave fiind nevoie de înca un fir de selectie

Figure 20: Transmisia “full duplex”

Putem enumera următoarele avantaje ale SPI:

Comunicatie full-duplex

Flexibilitate pentru bitii transferati

Nu exista limitarea la cuvinte de 8-bit

Se pot trimite mesaje de orice lungime

Se interfateaza usor, usurinta în folosire

Mai eficient în comunicarea point-to-point

Dintre dezavantaje amintim:

Foloseste mai multe fire

Nu are suport pentru adresarea device-rurilor; este necesar câte un semnal de Slave Select pentru fiecare slave.

Nu exista flow control și slave acknowledgement (master poate "vorbi îngol" fără sa stie).

Suporta numai un singur master

Functionează pe distante mici spre deosebire de RS-232

Pentru a porni comunicatia masterul trebuie sa seteze ceasul la o frecventa cel mult egala cu frecventa suportata de slave. Masterul selecteaza apoi cipul slave dorit, punand 0 pe linia SS spre acesta.

In timpul unui ciclu SPI, transmisia este full-duplex: masterul trimite un bit pe linia MOSI, iar slave-ul il citeste de pe aceeasi linie; slave-ul trimite un bit pe linia MISO, iar master-ul il citeste de pe aceeasi linie.

Comunicatia pe SPI implica de obicei existenta a doi registri de shiftare (Shift Registers), unul în master și unul în slave, conectati în ciclu:

Figure 21: Transmisia Master-Slave pe SPI

De obicei primul bit shiftat pe liniile de MISO/MOSI este bitul cel mai semnificativ, în timp ce un nou bit este adaugat pe pozitia cea mai putin semnificativa din registru.

Dupa ce intregul cuvant a fost trimis, prin shiftare, masterul și slave-ul au interschimbat valorile din cei doi registri de shift. Dacă mai exista date de transmis, procesul este reluat.

Cand nu mai exista date de transmis, masterul întrerupe generarea ceasului și, îngeneral, pune 1 pe linia de SS asociata slave-ului.

Cipurile slave care nu au fost selectate vor ignora semnalele de pe SCK și MOsi și nu vor genera nimic pe MISO.

Masterul poate selecta doar un singur slave la un moment dat.

Tipul de comunicație RS232

Este cel mai cunoscut și utilizat standard de comunicație serială asincronă. El a fost definit de mai multe organisme internaționale de standardizare sub diferite nume : IEC232, CCITT-V24, RS232C. Inițial standardul a fost conceput cu scopul de a permite conectarea unui terminal inteligent la un calculator central printr-o legătură telefonică. Standardul precizează interfața dintre un echipament de calcul (DTE- Data Terminal Equipment) și adaptorul sau la linia telefonică ( DCE – Data Circuit – terminating Equipment ), cunoscut și sub numele de modem ( Modulator / Demodulator ). Interfața permite comunicația serială bidirecțională între cele două echipamente, și este simetrică la cele două capete ale liniei. Ulterior specificațiile acestei interfețe s-au folosit pentru a realiza legături seriale între diverse echipamente fără a se mai folosi un modem.

Principalele precizări ale standardului RS232 se referă la :

– modul de transmisie : serial asincron, bidirecțional (pe două linii de date separate)

– codificarea informațiilor binare : prînnivele de tensiune sau curent (bucla de curent) :

– 1 logic – (-3V … -15V);

– 0 logic – (+3V…-15V).

– structura informației elementare transmise :

– un bit de start (0 logic);

– 5-8 biți de date.

– 0-1 bit de paritate (paritate para sau impara);

– 1-2 biți de stop (1 logic).

Figure 22: Structura unui caracter transmis conform standardului RS232

– semnale utilizate pentru transmisia de date și pentru controlul fluxului de date ;

– tipul de conectori folosiți (RK 25, mufa și soclu) și poziția semnalelor pe pinii conectorilor;

– modul de interconectare a semnalelor la cele două capete ale unui cablu de transmisie;

– viteza de transmisie (110, 300, 600, 1200, 2400, 4800, 9600, 19200 bauds);

– reguli de control al fluxului de date (control hardware – protocolul DTR/DSR sau

software – protocolul XON/XOFF);

In cazul transmisiei seriale asincrone, sincronizarea între unitatea emitentă și cea receptoare se realizează la inceputul fiecărui caracter prînbitul de start (0 logic). De precizat că în repaus linia este în1 logic. Citirea datelor se face secvențial, la jumătatea intervalelor de bit care urmează bitului de start. Protocolul asigură citirea corectă a datelor chiar și în cazul în care există mici diferențe (sub 2%) între frecvența de emisie și cea de citire a datelor. Această sincronizare nu s-ar păstra în cazul în care lungimea datelor utile ar fi mai mare. Pentru controlul fluxului de date transmise se poate utiliza un protocol hardware sau unul software. In primul caz se utilizează semnale explicite (grupul de semnale DTR/DSR sau RTS/CTS) prin care unitatea receptoare poate să oprească temporar fluxul de date transmis. In acest fel se poate sincroniza frecventa de emisie a datelor la viteza de prelucrare a unitarii receptoare. A două metoda nu utilizează semnale de control ; în schimb folosește un set de coduri speciale prin care poate să oprească (codul XOFF) sau sa repornească (codul XON) fluxul de date. Această metoda se poate utiliza numai la transmiterea unor date încodificare ASCII. La transmisia binară codurile de control ar putea sa fie prezente în datele de transmis. In cazul în care se conectează două echipamente aflate la distantă mică (ex : îninteriorul unei incăperi) se pot utiliza numai o parte din semnalele precizate în interfața RS232. In acest fel cablul de legătură devine mai ieftn și mai ușor de manipulat.

Mediul de dezvoltare LabWindows/CVI conține o bibliotecă de funcții pentru gestionarea comunicației seriale (open/close, input/output, control, status, callback, etc.):

Deschis / Inchis

OpenComConfig – Deschide un port COM și setează parametrii acestuia;

CloseCom – Inchide un port COM;

OpenCom – Deschide un port COM folosind parametri impliciți;

Intrare / Ieșire:

ComRd – Citește un număr specificat de octeți dînbufferul de intrare și îi stochează înbufferul dat ca parametru;

ComRdTerm – citește dînbufferul de intrare până când este intâlnit codul ASCI al unui caracter dat ca parametru ori s-a citit un număr specificat de octeți (oricare dîncondiții apare prima);

ComRdByte – Citește un octet dînbufferul de intrare al portului specificat ca parametru;

ComToFile – Citește dînbufferul de intrare al portului dat ca parametru și scrie datele înfișierul specificat de fileHandle dat de asemenea ca parametru;

ComWrt – Scrie un număr de octeți înbufferul de ieșire al portului specificat;

ComWrtByte – Scrie un octet înbufferul de ieșire al portului specificat;

ComFromFile – Citește dînfișierul specificat și scrie înbufferul de ieșire al portului dat ca parametru;

Control:

SetComTime – Setează limite de timeout pentru operații de intrare ieșire;

SetXMode – Validează sau invalidează software handshaking validând sau invalidând senzitivitatea XON / XOFF la transmisia și recepția datelor.

SetCTSMode – Setează hardware handshaking.

FlushInQ – Șterge toate caracterele dînbufferul de intrare al portului dat ca parametru.

FlushOutQ – Șterge toate caracterele dînbufferul de ieșire al portului dat ca parametru.

Status:

GetComStat – Returnează informații despre starea unui port serial;

GetComConnectionState – Returnează starea conexiunii unui port serial;

GetInQLen – Returnează numărul de caractere dînbufferul de intrare a unui port;

GetOutQLen – Returnează numărul de caractere dînbufferul de ieșire a unui port;

ReturnRS232Err – Returnează codul de eroare al celui mai recent apel de funcție dînprocesul curent;

GetRS232ErrorString – convertește un cod de eroare returnat de una dînfuncțiile de mai sus într-un șir de caractere ce conține informații despre eroare respectivă;

Callback

InstallComCallback – instalează o funcție sincronă de callback pentru un port serial;

Capitolul III: Achiziția datelor și afișarea acestora

Tipuri de parametrii ce pot fi afișați și utilizarea lor în practică

Fisierul de configurare a parametrilor care sunt transmiși pe LIN:

/* signals */

#define IBS_BatteryCurrent_ST 0 // startbit (bits)

#define IBS_BatteryCurrent_LEN 24 // length (bits)

#define IBS_BatteryCurrent_ENC 1 // LSB(from LDF)*10^*_RES

#define IBS_BatteryCurrent_RES 3 // no. of decimals

#define IBS_BatteryCurrent_OFF (-2000000) // offset*10^*_RES

#define IBS_BatteryVoltage_ST 24 // startbit (bits)

#define IBS_BatteryVoltage_LEN 16 // length (bits)

#define IBS_BatteryVoltage_ENC 1 // LSB(from LDF)*10^*_RES

#define IBS_BatteryVoltage_RES 3 // no. of decimals

#define IBS_BatteryVoltage_OFF 0 // offset*10^*_RES

#define IBS_BatteryTemperature_ST 40 // startbit (bits)

#define IBS_BatteryTemperature_LEN 9 // length (bits)

#define IBS_BatteryTemperature_ENC 5 // LSB(from LDF)*10^*_RES

#define IBS_BatteryTemperature_RES 1 // no. of decimals

#define IBS_BatteryTemperature_OFF (-400) // offset*10^*_RES

Sunt prezentate valorile care sunt utilizate în calcul pentru 3 parametrii care sunt transmisi pe LIN.

Aceste valori fac parte dîntr-un tabel de descriere (LIN matrix) unde, pentru fiecare semnal în parte sunt prezentate mai multe valori care sunt utilizate mai apoi pentru determinarea valorii finale.

De asemenea, toate aceste semnale sunt descrise într-un fisier de tip “.ldf”, acesta putând fi încărcat înconfiguratia de CANoe. Se poate realize astfel un “trace” pentru semnale care sunt transmise pe LIN.

Dupa cum se poate observa în exemplul de mai jos, toate semnalele care sunt transmise pe LIN sunt grupate în frame-uri. Un frame conține toate semnalele care vor fi transmise simultan.

Figure 23: Descrirea unui frame de LIN în tabelul de semnale

Putem considera de exemplu semnalul IBS_BatteryVoltage, care este tensiunea pe care senzorul IBS o determina la baterie. Pentru acest semnal ne sunt furnizate urmatoarele informații:

init value: 0xFFFF

valoarea fizica: 0…50000 mV

valoarea zecimala: 0…50 V

rezolutia: 1 mV

offsetul : 0 mV

bitul de start: 24

bitul de sfârșit: 39

lungimea (bitul start al urmatorului semnal – bitul de start) : 16 biți

Cu ajutorul acestor informatii despre fiecare semnal în parte se va utiliza urmatoarea formulă pentru a se determina valoarea finala (pentru un caz general) :

Valorea finală = valoarea fizică * LSB + offset

In cazul nostru de exemplu, pentru a determina valorea tensiunii care va fi afisată pe display, se va utiliza urmatorul principiu.

O parte din codul scris pentru receptionarea datelor si afișara acestora pe disply este descris în cele ce urmează

value = lin_extract_signal_value(l_buffer, IBS_BatteryVoltage_ST, IBS_BatteryVoltage_LEN);

float2str(textvalue, value * IBS_BatteryVoltage_ENC + IBS_BatteryVoltage_OFF, 2, IBS_BatteryVoltage_RES);

unde:

înparametrul “value” se va extrage valorea din bufferul corespunzator începand cu bitul de start și terminand cu bitul de sfârșit

datele de start, respective de sfarsit ae bitului ne sunt furnizate din tabelul de descriere al semnalelor

“float2str” va returna caracterele ascii pentru un număr cu virgula; aceasta funcție va avea ca și parametrii de intrare :

value * IBS_BatteryVoltage_ENC + IBS_BatteryVoltage_OFF

numarul de cifre înainte de virgulă

numarul de cifre dupa virgulă

Nota:

Toate aceste valori ale semnalelor sunt regasite în fisierul de configurare de LIN.

Meniu display

În cele ce urmează este prezentată schema bloc de conexiune dintre STU și baterie. În cazul nostru, de proiectare a sistemului, s-a utilzat o sursa pentru alimentarea cu 12 V a echipamentelor.

Trebuie menționat faptul ca IBS (Intelligent Battery Sensor ) se montează pe borna negativă a bateriei. Aceasta are 2 ieșiri

Un cablu pentru alimentarea cu 12 V

Un cablu care este specific comunicatiei LIN

Pe langa aceste iesiri, mai exista si conexiunea de ground, acesta facându-se de asenenea direct de pe sensor

Figure 24: Conexiunea Baterie-STU

Meniul principal :

Meniul principal permite alegerea tipului de senzoe care este conectal la un moment dat:

IBS – Intelligent Battery Sensor

RLS – RaînLight Sensor

AQS – Air Quality Sensor

Oil Sensor

În cazul nostru, a fost selectat senzorul de baterie (IBS), Acesta va funiza informații despre starea bateriei precum și parametrii acesteia

Figure 25: STU Display

Trecerea dîntr-un meniu în celălalt va putea fi realizata cu ajutorul unei tastaturi (not implemented yet).

Datele furnizate de senzorul de baterie(IBS):

Datorită consumului tot mai mare de energie în masina (numar mare de ECU-uri, implementarea unor functionalități multiple care sa asigure un confort ridicat și o siguranță sporită a pasagerilor), se incearcă descoperirea unor metode care sa previna aceste probleme.

Intelligent Battery Sensor se montează pe borna negativa a bateriei. Rolul acestuia este de a transmite informații despre starea bateriei (SOC – State of Charge, SOH – State of health), precum și paremetrii bateriei (Tensiune, Curent, Temperatura).

SOC – State of Charge – parametru care ne arata cat de incarcată este bateria în fiecare moment

SOH – State of Health – parametru care arată “buna funcționare”; bateria este supusă mai multor cicluri de dscarcare/incarcare și acest lucru va duce la aparția anumitor probleme (masina nu mai poate porni)

Tensiune, Curent, Temperatură – acesti parametri sunt esentiali pentru descoperirea anumitor consumatori care nu functioneaza corect; detectarea unor probleme la pornirea/oprirea vehicolului

Codul C prin care datele de tensiune, curent, temperature sunt afisate pe display:

if (sensor4_schedule1 >= SENSOR4_SCHEDULE1_STEPS)

{

if (1 == group)

{

value = lin_extract_signal_value(l_buffer, IBS_BatteryCurrent_ST, IBS_BatteryCurrent_LEN);

float2str(textvalue, value * IBS_BatteryCurrent_ENC + IBS_BatteryCurrent_OFF, 1, IBS_BatteryCurrent_RES);

lcd_write_string("BattCurr:", 2, 1);

lcd_write_string(textvalue, 2, 10);

value = lin_extract_signal_value(l_buffer, IBS_BatteryVoltage_ST, IBS_BatteryVoltage_LEN);

float2str(textvalue, value * IBS_BatteryVoltage_ENC + IBS_BatteryVoltage_OFF, 2, IBS_BatteryVoltage_RES);

lcd_write_string("BattVolt:", 3, 1);

lcd_write_string(textvalue, 3, 10);

value = lin_extract_signal_value(l_buffer, IBS_BatteryTemperature_ST, IBS_BatteryTemperature_LEN);

float2str(textvalue, value * IBS_BatteryTemperature_ENC + IBS_BatteryTemperature_OFF, 2, IBS_BatteryTemperature_RES);

lcd_write_string("BattTemp:", 4, 1);

lcd_write_string(textvalue, 4, 10);

}

Driverul de SPI a fost implementat tinându-se cont de specificațiile microcontroller-ului.

SPI – ATMega32M1

Microcontroller ATMega16 pune la dispozitia utilizatorilor sai și interfață SPI putand functiona atat ca master cat și ca slave. Pentru configurarea și utilizarea unei interfețe se lucrează cu registri: de control, de stare și de date. Pentru interfață SPI implementata în ATMega32M1 avem urmatorii registri:

SPCR – Control Register – în acest registru dăm enable la SPI, activam întreruperile asociate, setăm modul de funcționare a microcontrolerului (master sau slave) și ceasul. SPSR – Status Register – cel mai important bit din acest registru este SPIF, care semnalizeaza când s-a terminat o transmisie. SPDR – Data Register – acesta este registrul dîncare citim, sau încare scriem, datele pe care leam primit, sau pe care vrem sa le trimitem.

Testarea valorilor afisate pe display utilizând CANoe

Utilizand Tool-urile de la vector, și anume CANoe se poate realize o configuratie.

Aceasta va avea extensie “.cfg”.

Se va crea o rețea de comunicare(încazul nostru o rețea LIN).

Se va încarca în configuratia de CANoe și fisierul “.ldf”. Aici se gasesc toate pachetele de semnale (frame-uri), impreuna cu ID-ul fiecarui frame, lungimea, bitul de start, tipul comunicatiei LIN, etc.

Figure 26: Afisarea datelor înCANoe

Dupa ce configuratia a fost realizata și senzorul a fost conectat, se poate observa pachetul de semnale trimis in fiecare moment (acesta depinde de scheduler-ul care il avem).

In cazul nostrum, este transmis IBS_FRM2 cu semnalele de current, tensiune, temperature, eroare.

Toate aceste pachete de semnale pot fi vizualizate direct din CANoe cu “LIN Network Viewer”. și aici, ca și înfisierul de ldf se poate observa pentru fiecare semnal în parte bitul de start, lungimea și valuarea de inceput.

Aceste valori sunt foarte importante, deoarece în functie de ele, se va extrage din bufferul corespunzator valoarea dorita pentru fiecare semnal, care este mai apoi prelucrată. Această valoare fie stocata, fie este transmisă mai departe pentru a putea fi utilizată.

Figure 27: LIN Network Viewer

Configurarea nodurilor este folosita prin setarea nodurile slave într-un cluster. Este un set de servicii creat pentru a evita conflictele dintre nodurile slave dîntr-un cluster. Configurarea este facuta prin detinerea unui spatiu de adrese, constănd int-un Identificator de Produs LIN și un NAD initial pentru nodurile slave. Folosind aceste valori este posibil schițarea de identificatori de telegrame unice pentru toate telegramele transportate în cluster.

Pachetele de semnale obținute pe LIN

Figure 28: LIN frames

Figure 29: LIN frame detaliat

Figure 30: Componența unui frame de LIN (1)

Figure 31: Componenta unui frame de LIN (2)

Din figurile de mai sus se pot observa break-uk, pachetul de date care este transmis, checksumul pachetului de semnale care este transmis pe LIN.

Capitolul IV: Interfață grafică pentru conexiunea UART

Crearea interfeței grafice utilizând CVI

LabWindows/CVI este o platformă pentru dezvoltare de software cu orientare pe aplicații de instrumentatie. Dupa cum se deduce din denumirea sa (CVI – C for Virtual Instrumentation), limbajul acceptat este ANsi C, cu extensii specifice. CVI ne pune la dispozitie un mediu interactiv de dezvoltare a unor aplicatii pentru sistemul de operare Windows. Îmbină deci avantajele programarii de tip vizual cu avantajele simplitatii și flexibilitatii limbajului C. Deși a fost creat special pentru aplicatii de instrumentatie și control, multiplele lui facilități îl fac capabil sa suporte și dezvoltarea unor aplicatii de marime medie care sa fie de alta factură. Fiecare functie de biblioteca din cadrul acestui mediu are o interfață specializată numita panoul functiei ( function panel ) care permite:

• Help on-line;

• Selectare și declarare de variabile sau constănte necesare;

• Executie interactiva;

• Inserarea functiei editate într-un text sursa

Mediul este extrem de flexibil, permitând interfațărea bidirectionala cu alte compilatoare de C

sau C++. De asemenea se pot folosi s i DLL-uri.

Puterea mediului LabWindows/CVI este data de bibliotecile puse la dispoziția programatorului, acestea conținând functii pentru implementarea diverselor faze care conduc la o aplicație din domeniul achiziției de date sau a controlului automat.

Pentru achiziția de date exista următoarele biblioteci specializate:

• de instrumente,

• pentru interfață GPIB/GPIB 488.2 ( General Purpose Interface Bus ),

• pentru achiziție de date,

• pentru operații I/O încazul achizitiei de date,

• pentru interfață seriala RS232,

• pentru sistemul VXI.

Biblioteci specializate pentru analiza datelor:

• pentru I/O

• pentru formatarea speciala

• pentru analiză

• pentru analiză avansată

Biblioteci specializate pentru vizualizare date:

• pentru crearea unei interfețe utilizator de tip vizual

Biblioteci specializate pentru lucrul în rețea și comunicarea între diverse aplicații:

• pentru DDE (Dynamic Data Exchange)

• pentru TCP (Transmision Control Protocol)

• pentru sistemul X de sub Unix

In afără de acestea mai există o bibliotecă speciala numita biblioteca de instrumente care conține: drivere și sursele lor pentru osciloscoape, multimetre și generatoare de functii. De asemenea exista posibilitatea crearii unui instrument propriu.

Biblioteca pentru interfață cu utilizatorul conține functiile necesare crearii unui GUI ( Graphical User Interface = Interfață grafica cu utilizatorul) dupa necesitati.

Structura generica a unei aplicatii dezvoltate sub CVI

Un proiect complet pentru una din clasele de aplicații specifice mediului CVI are următoarele componente generice:

• interfață cu utilizatorul;

• partea de control a aplicației;

• partea specializata pentru achizitia datelor;

• partea specializata înanaliza respectivelor date.

Tipuri de fis iere folosite încadrul CVI

*.PRJ se refera la fisiere de tip proiect

*.UIR se refera la fisiere care conțîndescrierea unei interfețe grafice cu utilizatorul

*.C fisiere sursa

*.H fisiere header

*.FP fisiere care retîndescrierea unui instrument

*.LIB fisiere biblioteca

*.DLL fisiere link-editate pentru apel dinamic

*.OBJ fisiere obiect

Figure 32: Schema generică a aplicațiilor CVI

Se poate observa în cele ce urmează conexiune bloc dintre IBS – STU – PC

Așa cum a mai fst mențonat, în faza de proiectare bateria a fost înlocuită cu o sursa de tensiune, Acesata permite modificarea nivelului de tensiune (pentru IBS putem modifica tensiunea între 6-20 V).

Totodata sursa poate fi transformata într-o sursă de curent. Astfel poate fi aplicat sensorului un curent.

Aceste teste ajuta la validarea informațiilor care sunt extrase, transmise si afișate pe display-ul STU.

Figure 33: Conexiunile IBS-STU-PC

Utilizarea interfeței grafice în practică

Pentru a putea verifica datele afisate pe display, s-a realiat o interfață grafica în CVI.

Aceasta permite selectarea tipului de sensor care este conectat la un moment dat la Sensor Tester Unit.

Prin apasarea butonului de “Receive ON” / “Receive OFF” se începe/intrerupe transmisia datelor pe serial.

De asemenea o parte din parametrii senzorului sunt afisați în partea dreapta a interfeței.

Figure 34: Interfața grafică pentru comunicația cu STU

Prin selectarea butonului “Open Graph Window” se va deschide o noua fereastră unde se pot selecta semnalele pentru care se doreste reprezentarea grafică.

Pentru a vizualiza graficele odată cu pornirea transmisiei, trebuie selectată și optiunea “Log Data to Graph”

Datele ce sunt transferate sunt formate din unități de lungime fixă, de obicei de câte 8 biți. De exemplu când un terminal comunică cu calculatorul fiecare caracter tastat este codificat intr-o valoare binară de 8 biți, intregul mesaj fiind format dîntr-un șir de astfel de caractere codificate. Deoarece fiecare caracter este transmis serial, echipamentul receptor pentru a decodifica și interpreta corect biții transmiși trebuie să cunoască:

– rata de emisie a biților (durata unei celule bit);

– începutul și sfârșitul fiecărui caracter (octet);

– începutul și sfârșitul fiecărui mesaj complet (bloc).

Acești trei factori sunt cunoscuți sub numele de sincronism la nivel de bit, sincronism la nivel de caracter și sincronism la nivel de bloc.

Figure 35: Grafice generate de interfața grafică

Concluzii și contribuții

Echipamentul de testare a senzorilor este un dispozitiv care ajută la achiziționarea și interpretarea datelor furnizate de anumiți senzori care se află pe mașină.

In funcție de fiecare senzor utilizat, un fișier de configurare trebuie creat, iar apoi prin intermediul comunicației LIN, datele sunt transmise de la senzor catre STU, respectiv printr-o comunicație serială, datele sunt transmise către un calculator unde acestea pot fi stocate și interpretate ulterior la apariția unei defectiuni.

Interpretarea datelor într-un anumiti moment va conduce la reducerea costurilor de service, precum și la prevenirea unor probleme care pot să apară in mașină si care pot afecta siguranța șoferului si a pasagerilor.

Contribuțiile proprii aduse lucrării de disertație sunt:

În primul rând am creat driverele de UART/ LIN/ SPI. Aceste drivere au fost modificate pentru a putea fi utilizate strict pentru acest dispozitiv, pentru a se putea asigura o bună trasmisie a datelor de la senzor catre STU/ calculator.

Am creat un meniu pentru display, care in funcție de parametrii cu care sunt apelate anumite funcții, poate afișa datele de la senzorii conectați. Se doreste in viitor implementarea unui driver de tastatura care sa permita o mai usoara navigare prin meniul STU.

Pentru fiecare senzor în parte am realizat fișiere de configurare. Aici trebuie adugate informații despre fiecare senzor in parte, cum ar fi : bitul de start dintr-un pachet pentru fiecare semnal in parte, lungimea semnalului, rezoluția, offsetul. Aceste date au fost mai apoi preluate (s-a facut o funcție care extrage din fiecare buffer în parte informația) si afișate pe display.

Am creat o configuratie de CANoe unde se poate observa un pachet de date care este trasmis de la senzorul de baterie către STU.

Am fost creat o interfată grafică in CVI, care permite colectarea informațiilor care sunt afișate pe display si realizarea unor grafice in funcție de parametrii doriți.

Cu ajutorul osciloscopului am obținut formele de undă pentru niște pachete de semnale din care se pot observa parametrii specifici comunicației LIN (ID, break, pachetul de date).

Referințe

[1]Miron Mandoiu, stst.elia.pub.ro/…/RETELE%20PENTRU%20COMUNICATII%20INDUSTRIALE.doc

[2] B. , LIN2.0 driver suite, 07.07.2006

[3]andrei.clubcisco.ro/cursuri/3pm/lab6.pdf

[4]Vector, “Canoe – User Manual”, www.vector.com/vi_index_en.html

[5]www.cs.ucv.ro/staff/dmancas/CD/ro/Cap3.doc

[6]http://www.hella.com/hella-com-en/270.html

[7]http://www.hella.com/hella-com-en/287.html

[8]http://www.hella.com/hella-com-en/298.html

[9]http://www.hella.com/hella-com-en/300.html

Table of figures

Figure 1: STU (Sensor Tester Unit) 3

Figure 2: IBS (Intelligent Battery Sensor) 4

Figure 3: RLS (Rain Light Sensor) 5

Figure 4: PULS (Packaged Ultrasonic Oil Level Sensor) 5

Figure 5: AQS (Air Quality Sensor) 6

Figure 6: Structura nodurilor intr-o rețea 9

Figure 7: Modalitatea de transport a datelor 10

Figure 8: Cluster cu un nod master și două noduri slave 10

Figure 9: Task sheduler 11

Figure 10: Transmisia/Recepția unui semnal 13

Figure 11: Structura unei telegrame 13

Figure 12: Transmisia unui câmp de byte 14

Figure 13: Structura unui brake 14

Figure 14: Campul byte-ului de Sync 14

Figure 15: Câmpul identificatorului 15

Figure 16: Numerotarea de byte de date intr-o telegramă cu 8 byte 15

Figure 17: Transmisia asincronă 20

Figure 18: Transmisia sincronă 22

Figure 19: Transmisia “four wire” 23

Figure 20: Transmisia “full duplex” 23

Figure 21: Transmisia Master-Slave pe SPI 24

Figure 22: Structura unui caracter transmis conform standardului RS232 26

Figure 23: Descrirea unui frame de LIN în tabelul de semnale 31

Figure 24: Conexiunea Baterie-STU 33

Figure 25: STU Display 34

Figure 26: Afisarea datelor înCANoe 37

Figure 27: LIN Network Viewer 38

Figure 28: LIN frames 39

Figure 29: LIN frame detaliat 40

Figure 30: Componența unui frame de LIN (1) 40

Figure 31: Componenta unui frame de LIN (2) 41

Figure 32: Schema generică a aplicațiilor CVI 44

Figure 33: Conexiunile IBS-STU-PC 45

Figure 34: Interfața grafică pentru comunicația cu STU 46

Figure 35: Grafice generate de interfața grafică 47

Referințe

[1]Miron Mandoiu, stst.elia.pub.ro/…/RETELE%20PENTRU%20COMUNICATII%20INDUSTRIALE.doc

[2] B. , LIN2.0 driver suite, 07.07.2006

[3]andrei.clubcisco.ro/cursuri/3pm/lab6.pdf

[4]Vector, “Canoe – User Manual”, www.vector.com/vi_index_en.html

[5]www.cs.ucv.ro/staff/dmancas/CD/ro/Cap3.doc

[6]http://www.hella.com/hella-com-en/270.html

[7]http://www.hella.com/hella-com-en/287.html

[8]http://www.hella.com/hella-com-en/298.html

[9]http://www.hella.com/hella-com-en/300.html