Model de Simulare Pentru Comunicarea Ecu Urilor pe Can
LUCRARE DE LICENȚĂ
Model de simulare pentru comunicarea ECU-urilor pe CAN
Cuprins
Introducere
În prezent sistemele electronice de pe automobile cunosc o dezvoltare fără precedent. Pentru automobilele de lux se estimează că sistemele electronice reprezintă aproximativ 23% din costul total al automobilului. De asemenea, experții estimează că aproximativ 80% din inovațiile aduse în domeniul auto fac parte din categoria sistemelor electronice.
Pentru a putea discuta despre protocoale de comunicație utilizate pe automobile mai întâi trebuie să clarificam modul în care calculatoarele ce echipează un automobil schimbă informații între ele. Să presupunem că automobilul este echipat cu un calculator de injecție (ECU), are transmisie automată(TCU) și de asemenea este prevăzut cu sistem de frânare ce previne blocarea roților (ABS).
În tabelul de mai jos sunt date ca exemplu informațiile care sunt schimbate între cele trei calculatoare. „Tx”semnifica faptul ca informația este transmisa iar „Rx” înseamnă că informația este recepționată.
Pentru a explica conținutul tabelului luăm ca exemplu informația "viteza automobilului". Acesta este trimisă de calculatorul sistemului de frânare (ABS) și este recepționată de calculatorul de injecție (ECM) și al cutiei de viteze automată (TCU).
Conexiunea electrică clasică între calculatoarele unui automobil
Astfel pentru a putea împărții aceste informații intre cele trei calculatoare, pentru fiecare semnal, trebuie realizata o conexiune electrică. Acest mod de a comunica anumite informații prezintă numeroase dezavantaje, cum ar fi:
creșterea greutății totale a automobilului datorită numărului mare de cabluri și conectori electrici;
scăderea fiabilității automobilului datorită posibilității de defectare a unei conexiuni;
complexitatea crescută a cablajului automobilului, pentru fiecare noua informație trimisă/recepționată este nevoie de cabluri adiționale.
Conexiunea electrică dintre calculatoarele unui automobil pentru protocolul CAN
În prezent, datorită numărului mare de calculatoare utilizate pentru un automobil, acest mod, de a schimba informații, este imposibil de folosit. Pentru a îndepărta aceste inconveniente s-a trecut la multiplexare, care reprezinta de fapt transmiterea mai multor informații utilizînd aceleași fire electrice. Avantajele utilizării comunicatiei multiplexate (magistrală) comparativ cu o comunicatie filară (pe fir) sunt urmatoarele:
În cazul unei comunicări filare, fiecare calculator are o legătură electrică separată pentru fiecare canal de comunicatie. Astfel dacă, de exemplu, avem 3 calculatoare care comunică fiecare cu fiecare, utilizînd 2 fire, vom avea în total 12 fire (4 fire pe calculator)! Dezavantajul acestui tip de comunicatie este reprezentată de masa mare a firelor si a conectorilor precum si de complexitatea mare a retelei de comunicatie.
În cazul utilizării unui sistem de comunicatie tip magistrală, comparativ cu un sistem filar, se elimină cantităti importante de conectori si cabluri. De asemenea sistemul de comunicatie este simplificat si se poate diagnostica mai usor.
Principalele motive pentru care se utilizează un sistem de comunicatie multiplexat (magistrală):
facilitează partajarea de parametrii între calculatoarele automobilului;
îmbunătăteste securitatea si modul de diagnosticare
reduce costul total al sistemului datorită reducerii numărului de fire si conectori
cerintă prevăzută în standardele de diagnoză EOBD
Un automobil de clasă medie din anii 90 continea aproximativ 2 km de cabluri care cântăreau în jur de 70-90 de kg! De asemenea un automobil Mercedes Benz, clasa S, din anul 2002, avea în jur de 50 de calculatoare. Cresterea numărului si a complexitătii sistemelor electronice de pe automobile a impus utilizarea sistemelor de comunicatie multiplexate (CAN).
Capitolul I
Magistrala CAN ( controller area network)
I.1.Prezentare generala
Este un standard de magistrala pentru vehicule conceput pentru a permite microcontrolerelor și dispozitivelor sa comunice unul cu altul într- un vehicul fără un computer gazdă .
Magistrala CAN are un protocol bazat pe mesaje , special conceput pentru aplicatii auto , dar folosit , de asemenea, si în alte domenii , cum ar fi industria aerospațială , maritima , automatizari industriale si echipamente medicale .
Dezvoltarea de magistrala CAN a început inițial în 1983 la Robert Bosch GmbH . Protocolul a fost lansat oficial în 1986 , la congresul Societatii Inginerilor Auto ( SAE ) co în Detroit , Michigan . Primele controler chip-uri CAN , produse de Intel si Philips , au intrat pe piata in 1987 . Bosch a publicat specificatia CAN 2.0 în 1991 . În 2012, Bosch a publicat protocolul CAN îmbunătățit ”data link layer”, denumit CAN FD , care va extinde standardul ISO 11898-1 . Principial, diferențele dintre versiunea 1.2 si 2.0 a standardului, constau în domeniul de adresare a nodurilor, care a fost extins în noua versiune. Mai exact, CAN 1.2 definește doar un singur tip de mesaj (mesaj standard) având lungimea câmpul de identificare a nodului (Id) de 11 biti, pe când versiunea CAN 2.0 mai introduce, pe lângă tipul de mesaj definit anterior si un mesaj cu lungimea Id-ul de 29 de biti numit mesaj extins.
Magistrala CAN este unul dintre cele cinci protocoale utilizate în standardul de diagnosticare de vehicule ( OBD ) – II . Standardul OBD -II a fost obligatoriu pentru toate autoturismele si camioanele ușoare vândute în Statele Unite in 1996 , iar standardul EOBD a fost obligatoriu pentru toate vehiculele pe benzină vândute în Uniunea Europeană in 2001 și toate vehiculele diesel din 2004 . Aplicativitatea pentru magistrala CAN exista cu precadere in domeniul automotive .Un automobil modern poate avea pana la 70 de unitati electronice de control ( ECU) pentru diferite subsisteme .De obicei, cel mai mare procesor este unitatea de control a motorului ( de asemenea, modul de control al motorului / ECM sau modul Powertrain de Control / PCM în automobile ) ; altele unitati electronice de control sunt folosite pentru transmisie , airbag-uri , ABS , cruise control , Servodirectie asistata electronic / EPS , sisteme audio , geamuri electrice , usi ,reglare a oglinzilor , baterie si sisteme de reîncărcare pentru hibride / masini electrice , etc. Unele dintre acestea formeaza subsisteme independente , dar de comunicarea intre ele este esentiala . Un subsistem ar putea fi necesar pentru a controla dispozitive de actionare sau de a primi feedback de la senzori . Standardul CAN a fost conceput pentru a rezolva această necesitate .
Magistrala CAN poate fi utilizata în vehicule pentru a conecta unitatea de control a motorului cu cea a transmisiei , sau ( pe o magistrala diferita ) pentru a conecta încuietorile ușilor , controlul Climei, controlul scaun , etc. Astăzi, magistrala CAN este , de asemenea, utilizata ca o magistrala de câmp , în general,in medii de automatizare , în primul rând din cauza costului redus al controlerelor si procesoarelor. a început sa fie utilizat su succes si în alte ramuri ale electronicii industriale (echipamente medicale, războaie de tesut).Pe lângă industria de automobile (sisteme de frânare, o gama larga de senzori, lampi de semnalizare, controlul automat al usilor) protocolul CAN datorită avantajelor pe care le aduce, în ceea ce priveste comunicarea între modulele electronice, este utilizat si în alte industrii/domenii:
vehicule grele, camioane, vehicule agricole
industria robotilor, automatizări
industria aeronautică, aeronave
vehicule militare
echipamente medicale
electrocasnice
Bosch detine brevete pe tehnologie , si producătorii de microprocesoare compatibile , pot plăti taxe de licență la Bosch , care în mod normal sunt transmise clientului în pretul microprocesorului . Producătorii de produse cu cu circuite integrate personalizate specifice aplicatiilor care contin module CAN compatibile – ar putea avea nevoie să plătească o taxă pentru licența CAN protocol.
I.2. Arhitectura retelei CAN
Specificația de CAN definește mai multe nivele:
nivelul fizic – descrie modul de transmitere a semnalului pe magistrala (reprezentare unui bit, nivele de transmisie a semnalelor, aspecte legate de mediul de transmisie)
nivelul transfer – descrie tipurile de mesaje trimise/receptionate de un nod de la nivelul sau superior (obiect); tot în grija acestui nivel sunt si aspectele legate de durata unui bit, sincronizare, formatul mesajelor, tehnici de arbitrare, confirmare, detectie de erori precum si mecanisme de restrângere a perturbatiilor
nivelul obiect – se ocupa cu aspecte ce tin de filtrarea si manipularea mesajelor
nivelul aplicatie
I.3. Tehnologia
CAN este o magistrală de transmisie serială multi-master pentru conectarea ECU-urilor.
Fiecare nod este capabil de a trimite și primi mesaje , dar nu în același timp . Un mesaj constă în primul rând dintr-un ID ( identificator ) , care reprezintă prioritatea mesajului , și contine până la opt bytes de date .Varianta imbunătățită de CAN ( CAN FD ) extinde lungimea secțiunii de date de până la 64 de biti per cadru . Aceasta este transmisa serial pe magistrala . Acest model de semnal este codat în sistem non retur la zero ( NRZ ) și este sesizată de către toate nodurile .Dispozitivele care sunt conectate printr-o rețea CAN sunt, de obicei senzori , elemente de acționare , precum si a altor dispozitive de control . Aceste dispozitive nu sunt conectate direct la magistrala , ci printr- un procesor gazdă și un controler CAN .
În cazul în care magistrala este inactiva , situatie care este reprezentata de nivelul recesiv ( Logical 1 ) , orice nod poate începe să transmită . În cazul în care două sau mai multe noduri încep trimiterea de mesaje în același timp , mesajul cu ID-ul dominant ( care are de ordin dominantă – de exemplu , la zero – bit ) va fi prioritar ID-urilor de mai putin dominante alte noduri " , astfel încât în cele din urmă ( după aceasta selectare de ID-uri. ) doar mesajul dominant rămâne si este primit de către toate nodurile . Acest mecanism este denumit selectare pe magistrala bazata pe prioritate . Mesaje cu ID-ri de valori reduse numeric au o prioritate mai mare si sunt transmise mai întâi .
Fiecare nod necesită o unitate centrală de procesare sau procesor gazdă.Procesorul gazdă decide semnificatia mesajelor primite si care din mesaje se vor transmite mai departe .
Senzori , elemente de actionare si dispozitive de control pot fi conectate la procesorul gazdă .
I.4 Tipuri de retele CAN
Protocolul CAN, în functie de viteza de transfer a datelor, este de două feluri:
CAN HS (High Speed) – viteză mare
CAN LS (Low Speed) – viteză mică
CAN HS poate avea viteza de transfer a datelor de 125, 250, 500 sau 1000 kb/s. Datorită vitezei mari de transfer a datelor este utilizat cu precădere pentru motor, cutie de viteze si sistemele de sigurantă activă (ABS, ESP).
CAN LS are viteza de transfer între 40 si 125 kb/s. Protocolul CAN LS are avantajul că este tolerant la erori (fault tolerant). În cazul în care unul din cele două fire este întrerupt comunicatia se realizează pe un singur fir. Acest tip de protocol CAN este utilizat cu precădere la închiderea centralizată si la imobilizator, datorită functionării si în regim de avarie.
Nivelul fizic al protocolului CAN
Din punct de vedere fizic, protocolul CAN contine o magistrală, formată din două fire răsucite, si calculatoare care contin fiecare câte un circuit integrat de emisie-receptie (CAN transceiver). Firele pe care se transmite informatia sunt răsucite pentru a elimina eventualele perturbatii electromagnetice.
Componentele fizice ale unei retele CAN
Circuitele integrate de emisie-receptie combină functia de primire a mesajelor cu cea de trimitere, în aceeasi componentă. CAN transceiver-ul este alimentat la o tensiune de 3…5 V si are rolul de a face conversia tensiunilor electrice, de pe magistrală, în semnale digitale si invers.
Nivelul fizic al protocoluluotocolului CAN.
Lungimea maximă a magistralei poate să fie de 250 m (CAN HS) sau de 50 m (CAN LS). Numărul de calculatoare care pot fi conectate la magistrală variază în functie de viteza si de numărul parametrilor ce trebuie transmisi. O retea CAN poate suporta până la 50 de calculatoare interconectate. În capetele magistralei sunt prevăzute rezistente electrice de aproximativ 120 Ω care au rolul de a creste impedanta retelei, în scopul eliminării fenomenului de „reflexie” a semnalelor.
Exemplu de retea CAN
ECM (Engine Control Module) – calculatorul de injectie (motor)
TCU (Transmission Control Unit) – calculatorul transmisiei automate
ABS (Anti-lock Braking System) – calculatorul sistemului de frânare
BCM (Body Control Module) – calculatorul de habitaclu
Roof (Plafon) – calculatorul pentru controlul trapei
Seat (Scaun) – calculatorul pentru controlul scaunelor
Clim (climatizare) – calculatorul pentru controlul climatizării
Diag. (diagnostic) – conectorul de diagnosticare
Exemplu dat de retea CAN contine două sub-retele, CAN motor si CAN vehicul, conectate printr-un „gateway” care este reprezentat de calculatorul de habitaclu (BCM). Această arhitectură are avantajul că un defect la una din cele două sub-retele nu o va afecta pe cealaltă.
Magistrala CAN contine două fire numite CAN_H (High voltage) si CAN_L (Low voltage). Pe firul CAN_H tensiunea electrică poate avea două nivele: 2.5 si 3.5 V. Pe firul CAN_L tensiunea electrică poate fi de 1.5 si 2.5 V.
Semnalul de tensiune de pe o retea CAN
Semnalele de tensiune pe cele două fire au ambele valoarea 2.5 V sau 3.5 V pe CAN_H si 1.5 V pe CAN_L. Traducerea acestor valori de tensiune în semnal digital se face prin diferenta celor două tensiuni. Când tensiunea pe cele două fire este de 2.5 V diferenta este de 0 V, când cele două tensiuni au 3.5 si 1.5 V, diferenta este de 2 V. Semnalul de tensiune ce are valori de 0 si 2 V reprezintă valori digitale de 1 si 0.
Cele două valori digitale nu sunt reprezentata exact de valori fixe de tensiune. Datorită eventualelor perturbatii aceste valori pot varia între anumite limite. Astfel, valoarea digitală de 0 poate fi reprezentată de o tensiune între -1.0 si 0.5 V iar valoarea digitală 1 înseamnă o tensiune între 0.9 si 5.0 V.
Atentie: Să nu se facă confuzie între CAN HS (High Speed) si CAN_H (High voltage). Primul reprezintă viteza de transfer a datelor iar a doua tensiune electrică din fir. Aceeasi observatie este valabilă si pentru CAN LS (Low Speed) si CAN_L (Low voltage). Ambele versiuni de viteză contin cele două fire CAN_H si CAN_L!
I.5.Transmisii de date
CAN descrie o transmisie arbitrara libera. Un mesaj CAN care este transmis cu prioritatea cea mai ridicata va trece mai departe, iar nodul care transmite mesajul cu prioritatea cea mai scazuta va detecta acest lucru, nu va mai transmite ci va astepta.
Aceasta se realizează prin transmiterea CAN a datelor prin intermediul unui model binar de biti " dominanti " si biti " recesivi " unde dominant este un 0 logic si recesiv este un 1 logic .
Aceasta inseamna un colector deschis sau implementarea fizica cuplata a magistralei de transmisie (dar intrucat dominant este, se face referire la acesta sub numele de cuplat). În cazul în care un nod transmite un bit dominant si un alt nod transmite un bit recesiv , atunci bitul dominant "castiga" ( un si logic între cele două ) .
Asadar, daca un bit recesiv este transmis, in timp ce un bit dominant este trimis, bitul dominant este afisat, ca dovada a unei coliziuni. (Toate celelalte coliziuni sunt invizibile). Un bit dominant este declarat prin crearea unui voltaj de-a lungul conductorilor pe cand un bit recesiv nu este nicidecum declarat in magistrala de transmisie. Daca orice nod marcheaza o diferenta de voltaj, toate nodurile o vor demonstra. Asadar nu exista nicio intarziere a prioritatii celei mai ridicate a mesajelor si orice nod care transmite o prioritate scazuta a mesajelor incearca sa retransmita cele sase ceasuri de biti dupa sfarsitul mesajului dominant.
Cand este folosit cu o magistrala de transmisie diferentiala, un transportor care detecteaza accese multiple, schema arbitrara a bitilor (CSMA/BA) este adesea implementata : daca doua sau mai multe dispozitive incep sa transmita in acelasi timp, exista o prioritate bazata pe o schema arbitrara care sa decida care dintre ele ii va fi permis sa continue sa transmita. Solutia CAN la acest lucru este o arbitrara prioritizata (si pentru mesajul dominant fara intarziere), CAN devenind potrivit pentru timpul real de prioritizare a mesajelor de comunicare.
In timpul arbitrarii, fiecare nod de transmisie monitorizeaza statusul magistralei de transmisie si compara bitul primit cu bitul transmis. Daca bitul dominant este primit atunci cand bitul recesiv este transmis, nodul va opri transmisia (eg. arbitrare pierduta), Arbitrarea se realizeaza in timpul transmisiei campului identificat. Fiecare nod care incepe sa transmita in acelasi timp trimite un ID in care dominant este 0 binar, pornind de la cel mai inalt bit. De indata ce ID-ul lor este un numar mare ( prioritate scazuta), ei vor trimite 1( recesiv) si a se vedea 0 (dominant), deci ei nu mai transmit, La sfarsitul transmisiei ID, toate nodurile insa doar unul nu a mai transmis, iar la prioritatea cea mai ridicata mesajul trece neintarziat.
De exemplu, sa luam 11 bit a retelei CAN, cu doua noduri cu ID-uri de 15 (reprezentare binara, 00000001111) si 16 (reprezentare binara, 00000010000). Daca aceste doua noduri transmit in acelasi timp, fiecare va transmite primele sase zerouri a ID-ului lor nerealizandu-se nicio decizie arbitrara. Atunci cand al 7-lea bit este transmis, nodul cu ID-ul 16 transmite 1 (recesiv) pentru ID-urile lui, iar nodul cu ID-ul 15 transmite 0 (dominant) pentru ID-urile lui. Cand acest lucru se intampla, nodul cu ID-ul 16 va arata ca exista o arbitrare pierduta si va permite nodului cu ID-ul 15 sa-si continue transmisia. Aceasta asigura ca nodul cu valoare mai scazuta a bitului sa castige intordeauna arbitrarea. ID-ul cu cel mai mic numar va castiga dreptul de utilizare.
I.6.Alocarea ID-ului
Mesajul ID trebuie sa fie unic pe o singura magistrala de transmisie CAN, in caz contrar doua noduri vor continua transmisia dincolo de capatul campului arbitrar (ID) producand o eroare.La inceputul anilor 1990, alegerea ID-ului pentru mesaje se facea pur si simplu pe baza identificarii tipului de date si a nodului de transmisie; cu toate acestea, deoarece ID-ul este folosit ca mesaj de prioritate, acesta conduce la o performanta scazuta a timpului real. In astfel de scenarii, o utilizare scazuta a magistralei de transmisie CAN de circa 30% a fost in mod obisnuit ceruta sa asigure ca toate mesajele isi vor indeplini termenele. Totusi, daca ID-urile sunt insa determinate pe baza termenului de indeplinire a mesajelor, cu cat e mai scazut ID-ul numeric cu atat e mai ridicata prioritata mesajului, asadar utilizarile magistralei de la 70 la 80% pot fi atinse in mod normal inainte ca orice termene de mesaj sa fie ratate. Se va folosi metoda CSMA/CD intr-un mod eficient.
Timpul de inregistrare al bit-ului
Fiecare nod din cadrul unei retele CAN are propriul sau ceas si nicio masuratoare nu e trimisa in timpul transmisiei. Sincronizarea este facuta prin divizarea fiecarui parcurs de bit intr-un numar de segmente: sincronizare, propagare, faza1 si faza 2. Lungimea fiecarui segment de faza poate fi ajustata pe baza retelei si a conditiilor nodului. Punctul de proba se plaseaza intre buffer-ul faza segment 1 si buffer-ul faza segment 2, care contribuie la facilitarea unei sincronizari continue. La randul ei sincronizarea continua ii permite receptorului sa citeasca in mod adecvat mesajele.
I.7.Sincronizarea bitilor
Fiecare nod într-o rețea CAN are propria frecventa , si aceasta nu este trimisa în timpul transmisiei de date . Sincronizarea se face prin împărțirea fiecare parte a mesajului într-o serie de segmente : . Sincronizare , propagare , faza 1 si faza 2 Lungimea unui segment de fază poate fi ajustată în funcție de condițiile de retea si nod . Punctul de probă se încadrează între faza 1(phase 1) si faza 2(phase 2) ,lucru care ajută la facilitarea sincronizarii continue . Sincronizarea continuă , la rândul său permite receptorului să poată citi corect mesajele .
Exemplu de sincronizare a bitilor pe CAN cu 10 cuante de timp pentru fiecare bit
I.8.Layere
Protocolul CAN , ca multe alte protocoale de transmisie in retea , poate fi descompus în următoarele “layere” de abstractizare :
Layer aplicatie
Despre acest layer se va discuta mai pe lar in capitolul de prezentare al aplicatiei CANoe
Layer obiect
filtrare mesaj
manipulare mesaj si stare
Layer de transfer
Cea mai mare parte a standardului CAN se aplică layer-ului de transfer . Layer-ul de transfer primeste mesaje de la layer-ul fizic si transmite aceste mesaje în layer-ul obiect . Layer-ul de transfer este responsabil de de sincronizare , divizarea mesajelor , arbitraj , receptie , de detectare a erorilor si de semnalizare , si izolarea erorilor . Acest layer efectuează :
Izolarea erorilor
Detectia erorilor
Validarea mesajelor
Confirmarea
Arbitrarea
Framing mesaj(divizarea mesajelor)
Rata de transfer si de sincronizare
Rutare de informații
Layer-ul fizic
Magistrala CAN bus ( ISO 11898-1:2003 )a specificat initial protocolul de layer de legătură doar cu cerinte abstracte pentru layer-ul fizic , de exemplu , evidentiind utilizarea unui mediu cu acces multiplu la nivel de biti prin utilizarea de stari dominante si recesive . Aspectele electrice ale layer-lui fizic ( tensiune , curent , numărul de conductori ) au fost specificate în ISO 11898-2:2003 , care este acum larg acceptată
Exemplu de topologie pentru magistrala CAN cu rezistoare terminale
Cu toate acestea , aspectele mecanice ale layerului fizic ( tip si numar de conectori , culori , etichete , PIN – uts ), nu au fost încă să fie specificate în mod oficial . Ca urmare , un ECU de automobile va avea de obicei un conector special personalizat , de multe ori , cu diferite tipuri de cabluri , dintre care două sunt liniile de magistrala CAN . Cu toate acestea , au apărut mai multe standarde pentru implementarea mecanica , cele mai frecvente fiind conectorul tată de tip D – cu 9 pini cu următoarele iesiri de pin :
pin 2 : CAN – Low ( CAN – )
pin 3 : GND ( Ground )
pin 7 : CAN – High ( CAN + )
pin 9 : CAN V + (Power )
Acest standard mecanic pentru CAN ar putea fi implementat cu un nod conectoare tata si mama de tip D – cablate electric între ele în paralel în cadrul nodului . Puterea magistralei este furnizata la conectorul tata al nodului si magistrala ia putere de la la conectorul mamă al nodului . Aceasta urmează conventia de inginerie electrică prin care sursele de alimentare sunt finalizate la conectorii mama . Adoptarea acestui standard evită necesitatea de a fabrica repartitoare personalizate pentru a conecta cele două seturi de fire de magistrala la un singur conector D la fiecare nod . Un astfel de cablaj(splitter) non-standard ( personalizat ) , care se unesc cu conductoarele din afara nodului reduc fiabilitatea magistralei , elimina interschimbabilitatea cablurilor , si reduc compatibilitatea de cablajelor ,si duc la cresterea costurilor .
Absenta unei specificatii complete pentru layer-ul fizic ( mecanic , în plus fata de partea electrica ),a eliberat magistrala CAN de constrângerile și complexitatea de implementare fizică . Cu toate acestea, a lasta magistrala CAN deschisa la probleme de inter- interoperabilitate din cauza incompatibilitatii mecanice .
Ecranarea prin ISO 11898-2:2003 se realizează prin mentinerea impedantei diferentiale a magistralei la un nivel scăzut , cu rezistente de valoare mică ( 120 ohmi ) la fiecare capăt al magistralei . Cu toate acestea , o magistrala cu impedanta redusă , cum este magistrala CAN atrage mai mult curent ( si putere ) decât alte magistrale de semnalizare pe baza de tensiune . Pe sistemele de magistrală CAN , linie de funcționare echilibrată , unde curentul într-o linie de semnal este echilibrat cu precizie de curentul în directia opusă al celuilalt semnal oferă un independent si stabil 0 V referinta pentru receptoare . Practica stabileste că la magistrala CAN echilibrarea semnalelor perechi se face prin folosirea de fire torsadate într-un cablu ecranat pentru a reduce la minim emisiile RF si a reduce interferentele în mediul RF deja zgomotos al unui automobil .
ISO 11898-2 asigura o oarecare imunitate la tensiunea de mod comun între emitator si receptor prin asigurarea unei diferente de potential de 0 V pe parcursul magistralei pentru a menține un grad ridicat de asociere a tensiunii între noduri . De asemenea , în configuratia mecanică mentionata mai sus , o linie alimentare este inclusa pentru a distribui puterea la fiecare dintre nodurile de emisie-receptie . Designul ofera o sursa de alimentare comuna pentru toate transceiverele . Tensiunea reală care trebuie aplicata de magistrala si la care din noduri li se aplică sunt specifice aplicatiilor si nu sunt specificate în mod oficial . Practica cea mai comuna pentru design-ul nodurilor oferă pentru fiecare nod transceivere care sunt izolate optic de la nodul lor gazda si din care deriva tensiunea de alimentare de 5 V reglementată liniar pentru emisie-recepție de la linia universala de alimentare furnizata de magistrala . Acest lucru permite , de obicei, marja de operare de pe linia de alimentare suficienta pentru a permite interoperabilitatea în mai multe tipuri de noduri . Valorile tipice ale tensiunii de alimentare de pe astfel de rețele sunt 7-30 V. Cu toate acestea , lipsa unui standard oficial înseamnă că proiectanții de sisteme sunt responsabili de compatibilitatea liniei de aprovizionare .
ISO 11898-2 descrie implementarea electrica provenita dintr-o linie de configurație multi-dropped cu un singur capăt cu rezistor de terminare la fiecare capăt al magistralei . În această configuratie o stare dominantă este asigurata de unul sau mai multe emitatoare de comutare care trec CAN- pe 0 V și ( simultan) trec CAN + la tensiunea de magistrala de 5 V formând astfel o cale de curent prin rezistențe care finalizeaza magistrala . Ca atare, rezistentele terminale constituie o componentă esentială a sistemului de semnalizare si sunt incluse nu doar să asigure ecranarea la înaltă frecvență .
În timpul unei stari recesive liniile de semnal si rezistoarele rămân într-o stare de impedanta ridicata fata de CAN + si CAN – . Tensiunile pe CAN + si CAN – pot tinde( slab ) inspre ½ din tensiunea de linie . Un stare recesiva este prezenta pe magistrala doar atunci când nici unul dintre emitătoarele de pe magistrala nu asigura o stare dominanta .
În timpul stării dominantă liniile de semnal si rezistentele trec la o stare de impedantă redusă în raport cu liniile , astfel încât curentul trece prin rezistenta . Tensiunea CAN + tinde la +5 V și CAN – tinde la 0 V.
Indiferent de starea semnalului liniile de semnale sunt întotdeauna în stare de impedanță redusă în raport una fată de cealaltă datorita rezistentei terminale de la sfârsitul magistralei .
Această strategie de semnalizare diferă semnificativ de alte tehnologii de transmisie pe linie precum RS -422 /3, RS – 485 , etc, care folosesc drivere/receivere de linii diferentiale si utilizează un sistem de semnalizare bazat pe tensiunea de mod diferential a liniei echilibrate prin care trec 0 V. Accesul multiplu pe astfel de sisteme se bazează în mod normal cele trei stari ( active high , active low si inactive tri-state) si este tratată în domeniul timp . Acces multiplu pe magistrala CAN se realizează prinl ogica electrică a sistemului ce suporta doar două stări ce sunt conceptual analoage cu o retea cablata “SAU logic”.
I.9 Frame-uri
O retea CAN poate fi configurata pentru a lucra cu două formate de mesaje diferite ( sau " frame " ) : formatul standard sau de bază ( descris în CAN 2.0 A și CAN 2.0 B ) , si formatul cadru extins ( descris doar in CAN 2.0 B ) . Singura diferență între cele două formate este urmatoarea:" frame-ul CAN de bază " suportă o lungime de 11 biti pentru identificator , si " frame-ul CAN extins " suportă o lungime de 29 de biți pentru identificator , format din identificatorul de 11 biti ( " identificator de bază " ) si o extensie de 18 – biti ( " extensie identificator " ) . Distinctia între frame-ul CAN de bază si frame-ul CAN extins se face prin utilizarea bitul IDE , care este transmis ca dominant în cazul unui frame de 11 – biți , și transmis ca recesiv în cazul unui frame de 29 – biti .Controlerele CAN care acceptă mesaje în frame extins sunt , de asemenea, capabile de a trimite si primi mesaje in frame CAN de bază . Toate frame-urile încep cu un bit inceput de start de frame ( SOF ) care denotă începutul transmisiei frame-ului .
CAN are patru tipuri de frame-uri :
Frame de date : un frame care contine un nod de date pentru transmitere
Frame “remote” : un frame care solicită transmiterea unui identificator(ID) specific
Frame de eroare : un frame transmis de orice nod ce detecteaza o eroare
Frame “overload” : un frame acre injecteaza o intarziere intre date si/sau frame-ul remote
Frame-ul de date
Frame-ul de date este singurul frame destinat pentru transmisia de date . Există două formate de mesaje :
Format frame de bază : cu 11 biti de identificare
Format frame extins : cu 29 de biti de identificator
Standardul CAN necesită ca punerea în aplicare să accepte formatul de bază si poate accepta formatul extins , dar trebuie să tolereze formatul extins.
Format frame de bază
CAN – frame în format de bază cu nivele electrice fără stuffbits
Formatul frame-ului este după cum urmează :
Este posibil din punct de vedere fizic pentru o valoare între 9-15 să fie transmisa în DLC de 4 – bit , desi datele sunt limitate la opt bytes . Anumite controlere permit transmisia si/sau receptia unui DLC mai mare de opt , dar lungimea efectivă de date este întotdeauna limitată la opt octeti .
Formatul de frame extins
Formatul frame este după cum urmează :
Este posibil din punct de vedere fizic pentru o valoare între 9-15 să fie transmisa în DLC de 4 – bit , desi datele sunt limitate la opt bytes . Anumite controlere permit transmisia si/sau receptia unui DLC mai mare de opt , dar lungimea efectivă de date este întotdeauna limitată la opt octeti .
Cele două campuri de ID ( A & B ) se combină pentru a forma un identificator de 29 – biti .
Frame-ul remote
În general transmiterea datelor se realizează pe o bază autonomă , cu un nod sursă de date ( de exemplu , un senzor ) care trimite un cadru de date . Este de asemenea posibil , cu toate acestea , ca un nod destinatie sa solicite date de la sursa prin trimiterea unui remote frame .
Există două diferente între un frame de date si un cadru de la distantă . În primul rând, bitul RTR este transmis ca un bit dominant în frame-ul de date si în al doilea rând , în Remote Frame nu există un camp de date .
adică ,
RTR = 0 ; Dominant în frame-ul de date
RTR = 1 ; Recesiv în frame-ul remote
În cazul putin probabil ca un frame de date si un frame remote cu acelasi identificator sa fie transmise în acelasi timp deoarece cadrul de date câstigă arbitraj datorită bitului dominant RTR ce urmeaza dupa identificator . În acest fel , nodul care a transmis frame-ul remote primeste imediat datele dorite .
Frame-ul de eroare
Frame-ul eroare constă din două campuri diferite :
Primul câmp este dat de suprapunerea de FLAG-uri EROARE ( 6-12 biti dominanti / recesivi ) obtinuti de la diferiti transmitatori .
Cel de-al doilea câmp este de DELIMITATORUL DE EROARE ( 8 biti recesivi) .
Există două tipuri de flag-uri de eroare :
Flag de eroare activa
Sase biti dominanti – transmisi de către un nod ce detecteaza o eroare în retea , care sunt în starea de " eroare activă " .
Flag-ul de eroare pasiva
Sase biti recesivi – transmisi de către un nod ce detecteaza un frame de eroare activă în retea , care sunt în starea " eroare pasivă " .
Frame-ul overload
Frame-ul overload contine două câmpuri de biti pentru Flag-ul de overload(suprasarcina) si delimitarea de suprasarcina . Există două tipuri de conditii de overload , care pot duce la transmiterea unui flag de overload :
Conditiile interne ale unui receptor , care necesită o întârziere a următorului frame de date sau frame remote.
Detectarea unui bit dominant în timpul pauzei .
Începutul unui frame overload in cazul 1 este permis sa fie pornit doar concomitent cu primul bit al unei pauze asteptate , în timp ce frame-ul overload din cazul 2 începe la un bit după detectarea bitului dominant . Flag-ul de overload este format din sase biti dominanti . Forma generală corespunde cu cea a flag-ului de eroare activă . Forma flag-ului de overload distruge forma fixă a câmpului de pauză . Ca urmare , toate celelalte noduri receptive detecteaza , de asemenea, o conditie de suprasarcină si din partea lor încep transmiterea unui flag de overload. Delimitatorul de overload este format din opt biti recesivi . Delimitatorul de suprasarcină este de aceeasi formă ca si delimitatorul de eroare .
Distanta interframe
Frame-urile de date si frame-urile remote sunt separate de frame-uri precedente de un câmp de biti numit spatiu interframe . Frame-urile de suprasarcină si frame-urile de eroare nu sunt precedate de un spatiu interframe si mai multe frame-uri de overload nu sunt separate de un spatiu interframe . Spatiul interframe contine pauza dintre câmpurile de biti bus idle(magistrala inactiva) , si suspenda transmiterea de nodurilor pasive de eroare , care au fost transmitătoare al mesajului anterior . Spatiul interframe este format din cel putin trei biti recesivi(1) consecutivi .
Bit stuffing
În frame-urile CAN , un bit de polaritate opusă se introduce după cinci biti consecutivi de aceeasi polaritate . Această practică se numeste bit stuffing , si se datorează codarii NRZ non- revenire la zero. Frame-urile de date astfel “umplute” sunt interpretate de către receptor . Deoarece bit stuffing-ul este folosit , sase biti consecutivi de acelasi tip ( 111111 sau 000000 ) sunt considerati o eroare .
Bit stuffing-ul implică faptul că frame-urile de date transmise ar putea fi mai mari decât ar fi de asteptat prin simpla enumerarea bitilor prezentati în tabelele de mai sus .
I.10 Standarde
Există mai multe layere fizice CAN si alte standarde din care amintim :
ISO 11898-1 : CAN Data Link Layer si Physical Signalling
ISO 11898-2: CAN High-Speed Medium Access Unit:
ISO 11898-2 foloseste un sistem de “signalling” echilibrat cu doua fire . Acesta este stratul fizic cel mai utilizat în aplicații ale sistemului de propulsie auto si retele de control industrial .
ISO 11898-3 : CAN Low – Speed , Fault – Tolerant , Interfata Medium -dependent
ISO 11898-4 : CAN Time-Triggered Communication
Standardul ISO 11898-4 defineste comunicarea time-triggered pe CAN ( TTCAN ) . Ea se bazează pe protocolul CAN data link layer oferind un clock de sistem pentru programarea mesajelor .
ISO 11898-5 : CAN High-Speed Medium Access Unit cu mod Low Power
ISO 11898-6 : CAN High-Speed Medium Access Unit cu functionalitate selectiva de wake up
ISO 11992-1 : CAN fault-tolerant pentru comunicare camion / remorcă
ISO 11783-2 : 250 kbit / s , Standard Agricol
ISO 11783-2 utilizează patru fire răsucite neecranate ; două pentru CAN si două de încheiere pentru circuit bias ( TBC ) de putere si pamantare . Aceasta magistrala este folosita pe tractoare agricole . Aceasta magistrala este destinata să asigure interconectarea cu orice implementarea ce adera la punerea în aplicare a standardului .
ISO 15765-2 , de asemenea, numit ISO – TP , este un standard de control al fluxului si de manipulare a mesajelor mai mari de opt bytes .
SAE J1939 – 11 : 250 kbit / s , Shielded Twisted Pair ( STP )
SAE J1939 – 15 : 250 kbit / s , Unshielded Twisted Pair ( UTP ) ( layer redus )
Standardul SAE J1939 foloseste o pereche răsucita de fire , -11 are un ecran în jurul perechii de fire in timp ce -15 nu . SAE 1939 defineste , de asemenea, aplicativitatea practica si este utilizat pe scară largă în industria automobilelor grele ( camioane ) si industria auto de transport , precum si în industria echipamentelor agricole si de constructii .
SAE J2411 :-Single wire CAN ( SWC )
Securitatea datelor
CAN este un protocol de nivel scăzut , si nu are suport pentru toate caracteristicile de securitate intrinseci . Aplicatiile sunt de asteptat să implementeze mecanismele lor de securitate proprii; de exemplu , pentru autentificare reciprocă . Imposibilitatea de a face acest lucru poate duce la diferite tipuri de atacuri , în cazul în care atacatorul reuseste să insereze mesaje pe magistrala . Există mecanisme de password pentru transfer de date , care poate modifica software-ul de control unit , cum ar fi download-ul de software sau codurile de pornire al automobilului , dar , de obicei, nu pentru comunicarea standard.
Capitolul II
Instrumente de dezvoltare si testare
In timpul dezvoltarii si / sau rezolvarii de probleme pe magistrala CAN , examinarea semnalelor hardware poate fi foarte importanta . Analizoarele logice si analizoarele de magistrala sunt instrumente care colectează , analizează , decodeaza si inmagazineaza semnalele astfel încât să se poată vedea formele de undă de mare viteză oricand. Există, de asemenea, instrumente de specialitate , precum si monitoare de autobuz CAN .Un astfel de instrument este si CANoe dezvoltat de compania Vector.
II.1 Prezentare generala CANoe(layerul aplicatie)
CANoe reprezinta un mediu universal destinat pentru dezvoltare(development),testare si analiza pentru sisteme CAN bus care este folosit in general in toate etapele procesului de dezvoltare al unui astfel de sistem.Producatorul unui astfel de sistem poate folosi CANoe pentru suport pe partea de functionare,verificare si integrare al sistemului el obtinand un mediu de testare aproape ideal prin simularea a ceea ce ramane din magistrala si mediul de comunicare.
Procesul de development este se imparte in trei etape principale dupa cum urmeaza:
Etapa 1: Analiza cerintelor(requirementurilor) si design-ul sistemului
În primul rând , partea responsabilă pentru proiectare distribuie functionalitatea de ansamblu a sistemului între diferite noduri de retea si rafinează la proiectare până la nivelul de
nod de retea . Aceasta include definirea de mesaje și selectarea ratei de transfer de
magistrala . În cele din urmă trebuie să fie specificat comportamentul magistralei de noduri de retea individuale ,de exemplu sub formă de cicluri sau protocoale mai complexe .
Etapa 2 : Implementarea componentelor cu simularea pentru restul de magistrala
După ce prima fază a fost finalizată proiectarea si dezvoltarea de noduri de retea individuale este de obicei efectuată de către toti participantii , în mod independent si în paralel . Modelele pentru alte noduri de retea pot fi acum utilizate pentru a simula restul magistralei pentru testarea unui nod de retea dezvoltat(developed) . Instrumentul necesită o interfată de magistrala reala pentru acest lucru, si acesta trebuie să fie capabil să efectueze simularea în timp real .
Etapa 3 : Integrarea sistemului global
În această ultimă fază de dezvoltare toate nodurile de retea reale sunt conectate la magistrala într-o manieră pas-cu-pas . Pentru a realiza acest lucru trebuie să fie posibil să se “deconecteze " modelele – unul cate unul din simularea restului magistralei . Instrumentul
serveste tot mai mult ca un instrument de analiză inteligentă care observă traficul de mesaje
între nodul de retea real si cele simulate de pe magistrala si compară rezultatele cu cerintele specificate .
Imaginea de mai jos descrie cele trei etape
La prima pornire a mediului CANoe, cand functionalitatea si controalele sale sunt încă complet noi pentru utilizator , exista posibilitatea ca acesta să se familiarizeze cu conceptul de operare si caracteristicile sale cele mai importante folosind notiunile de baza descrise mai jos.
Pentru acest lucru utilizatorul va defini mai întâi o magistrala CAN foarte simpla pentru cazul în care CANoe îsi asumă rolurile atât expeditor si receptor . În prima etapă CANoe va fi configurat ca o sursă de date , si anume ca o statie de emisie . De asemenea vor fi descrise optiuni de analiză CANoe prin studierea datelor generate în ferestrele de măsurare.
În sistemele reale complexe, de obicei, CANoe presupune , de asemenea, ambele roluri(expeditor si receptor) . Exista posibilitatea de a utiliza programul ca o sursă de date pentru a transmite date la alte controlere , dar se poate folosi simultan pentru a observa , inregistra si pentru evaluarea traficului de date de pe magistrala CAN .
În ultima parte a prezentarii se vor descrie cateva notiuni de utilizare a limbajului de programare CAPL si metoda de creare a două noduri de retea ale unui sistem distribuit pentru a rezolva o simulare simplă în CANoe.
CANoe are mai multe ferestre de evaluare ( Trace , date , grafice , ferestre de statistici si ferestre de statistici de magistrala ), precum si o fereastră de configurare de măsurare si o fereastră de configurare de simulare care arată fluxul de date si în acelasi timp permit configurarea CANoe.
Pot fi accesate toate ferestrele de program din meniul View din bara de meniu principal .
II.2 Configurarea CAN Bus
Pentru a porni CANoe este recomandabil să se folosească o configurare de test cu doar două noduri de rețea care este independenta de sistemele existente CAN bus . Cele două controlere de pe cardul PC furnizat pot servi ca noduri de retea .
De asemenea trebuie luate in considerare definitiile parametrilor de magistrala ( viteza de transmisie , punct de prelevare de probe , etc) care trebuie să fie stabilite pentru fiecare dintre cele două controlere participante .
Meniul View da posibilitatea de selectie al mediului de simulare prin fereastra “Simulation setup” configurarea canalelor realizandu-se prin selectarea meniului pop-up ce apare prin click pe butonul din dreapta al mouse-ului pe patratul care reprezintă sistemul de magistrala,selectand apoi “Channel configuration”
Apoi se poate selecta.+. si Setup din fereastra de configurare pentru primul controler CAN 1 utilizatorul avand posibilitatea sa configureze optiunea “baudrate”(rata de transfer).
Selectia unei viteze de 100 de kbps are sens pentru ambele tipuri de magistrala cu viteză redusă,sau de mare viteză. După ce se activeaza butonul Update, CANoe recomandă valori implicite pentru registrele controler, care se accepta cu OK. Când se realizeaza acest lucru – în afară de viteza de transmisie de 100 kBps – se definesc, de asemenea, implicit si alti parametri ai controlerului (Sampling point, BTL cycles, si “synchronization jump width”). Pentru ca sistemul general sa functioneze în mod corespunzător, aceleasi valori exacte trebuie să fie configurate pentru cel de-al doilea controler CAN2. La iesirea din dialog, valorile parametrilor se accepta.
II.3 Transmiterea Datelor
Pentru configurarea unei surse de date care sa asigure transmiterea mesajelor ciclice pe CAN.Acest lucru se poate realiza prin inserarea unui bloc generator in fereastra simulation setup care genereaza mesajele ce vor fi transmise.Se realizeaza acest lucru din meniul popup care apare prin click dreapta pe liniile magistralei ca in imaginea de mai jos si selectand Insert generator block.
Dupa acest lucru generatorul bloc apare in fereaztra “simulation setup” ca un bloc rectangular care este conectat reteaua simulata acest lucru fiind semnalat prin linia rosie.Se poate apoi configura acest bloc din meniul care apare prin click dreapta pe el.
Exemplu:
Configuratie CANoe astfel incat – dupa pornirea masuratorii – un mesaj CAN cu identificatorul 64(hex) este plasat pe magistrala la fiecare 100 de milisecunde.In acest caz mesajul trebuie sa contina exact patru bytes cu valorile D8 (hex), D6 (hex), 37 (hex) and 0.
Masuratoarea se porneste prin apasarea butonului de start de pe toolbar.CANoe incepe imediat sa transmita ciclic mesajul care a fost configurat in generatorul bloc.Se poate vedea acest lucru in fereastra “Trace” care apare automat in momentul in care masuratoarea a fost pornita.In prima linie se poate observa mesajul care este transmis de catre generatorul bloc iar in prima coloana se transmite timpul relativ de la inceperea masuratorii.
II.4 Analiza datelor
Analiza datelor din fereastra de trace
Fereastra de trace este folosita pentru analiza datelor generate de blocurile generator in configurarea simularii .Datele care ajung in fereastra de Trace ,descrisa mai sus, sunt afisate in fereastra de Trace sub forma de mesaje.Pe langa timp se apoate afisa controllerul CAN,identificatorul,un atribut care diferentiaza mesajele intre mesaje receptionate si mesaje transmise,si bytes de date din mesajul CAN.
Se poate configura fereastra de trace –ca orice alta fereastra de analiza – din meniul popup ce se poate accesa prin meniul popup ce apare prin click dreapta pe blocul ce se doreste configurat.
Fereastra de statistica ofera de asemenea informatii legate de magistrala.Aici se poate observa frecventa de transmisie a mesajelor semnalate prin identificatori.Pe langa faptul ca arata numarul total de semnale pentru fiecare identificator,raportul statistica arata si valorile semnalelor,deviatia standard,si minimul si maximul intervalului transmis inregistrat.Alta fereastra legata de magistrala,”Bus statistic window”,ofera o privire de ansamblu asupra traficului inregistrat pe magistrala.Aici este afisat totalul frecventelor de date,frame-urile,remote,error si overload,incarcarea pe magistrala si status-ul controller-ului de CAN.
Analiza datelor simbolice
De prim interes in analiza sistemelor CAN-pe langa informatiile ce le constituie mesajele,frame-urile de eroare,si frecventa mesajelor,sunt informatiile despre datele utile cum ar fi semnalele ce dau informatii de la controlerele individuale(de exemplu RPM,temperatura sau turatia motorului)acestea fiind transmise pe magistrala cu ajutorul mesajelor.
Pentru a descrie aceste informatii din punct de vedere simbolic,CANoe asigura formatul baza de date DBC si un editor de baze de date cu care se pot scrie,crea si modifica bazele de date CAN.Mai multe informatii legate de editorul de baze de date pot fi obtinute consultand manualul CANdb++ si manualul help online inclus cu pachetul CANoe.
Analiza valorilor semnalelor din fereastra de date
Pe langa folosirea numelor simbolice de mesaje,baza de date asociata poate fi de asemenea folosita pentru analiza valorilor semnalelor.Scopul “Data window” este de a asista in studiul valorilor instantanee ale semnalelor.Asta explica de ce “Data window” este initial goala intr-o configuratie noua.Valorile semnalelor ce sunt afisate sunt exclusiv dependente de informatiile din baza de date.Utilizatorul trebuie sa decida valorile caror semnale trebuie afisate.
Exemplu
Configuratia “Data window” pentru afisarea valorilor semnalelor continute de mesajul EngineData(ID 64 hex) care este generat in ramura de transmisie se executa dupa cum urmeaza:
Se deschide meniul Data window si apoi se porneste dialogul de configurare.Initial lista de semnale din dialog este goala.Prin apasarea butonului “New Signal” se porneste “Signal Explorer” ceea ce permite selectia unui semnal din baza de date.Ierarhia obiectelor din partea stanga a dialogului permite cautarea unui mesaj specific.In partea dreapta se gasesc semnalele mesajului selectat.Pentru exemplul de mai sus se va selecta EngineData din lista de mesaje.
Prin selectia si acceptarea semnalelor din lista de dialog din partea dreapta numele semnalelor vor fi introduse in fereastra.La pornirea simularii blocul generator va incepe sa trimita ciclic mesajul EngineData cu data bytes D8,D6,37 si 0 pe magistrala.Conform cu descrierea mesajului in baza de date blocul de date din measurement setup interpreteaza aceste valori ca fiinf viteza motorului,temperatura si starea de functionare si va afisa valorile corespunzatoare in Data window in unitati fizice.
Cu ajutorul formulei de conversie din baza de date,viteza motorului este afisata in RPM,iar temperatura este afisata in grade Celsius.Valorile celor trei semnale raman constante in timp deoarece mesajul este transmis sonstant cu aceeasi bytes de date D8, D6, 37 and 0.
Analiza valorilor semnalelor în fereastra Graphics
În timp ce fereastra de date afisează valori de semnal instantanee , in fereastra Graphics se pot vedea variatiile volorilor semnalelor in timp. După încheierea masuratorii graficele cu valorile semnalelor sunt disponibile pentru studiu cu funcții de analiză user-friendly .
Utilizarea bazei de date în transmiterea mesajelor
La deschiderea listei de transmisie a generatorului block se exista posibilitatea de introducere a unui mesaj direct din baza de date folosind butonul Symbol fara a mai fi nevoie sa se foloseasca identificatorul(ID).
II.5 Crearea unui raport de masurare(logare)
CANoe are functii extinse de logare pentru inregistrarea datelor . În “measurement setup” ramura de logare este afisata în partea de jos a ecranului . Fisierul de logare este umplut cu date de pe magistrala CAN din timpul măsurării .
Log-urile în format binar ocupă mai puțin spatiu pe hard disk , dar ele nu pot fi citite de editoare de text normale . Modul offline al programului oferă aceleasi optiuni de evaluare pentru loguri in ambele formate.
Exista posibilitatea de a se specifica ,in blocul de logare, conditiile de declansare pentru inregistrarea in fisier. Acest lucru este de multe ori de dorit , deoarece in general tot traficul de date de pe magistrala CAN a lungul întregii perioade de măsurare nu este de interes ci doar intervale pe o anumită perioadă de timp , de exemplu, atunci când există valori de semnal neverosimile sau atunci când apar frame-uri de eroare .
Pentru a inregistra întreaga măsuratoare este suficient a schimba modul de la Single Trigger la Entire measurement în caseta de dialog de configurare de trigger .
Caseta de dialog se inchide cu OK și apoi începe măsuratoarea , care se poate opri dupa perioada dorita. Acum, cu un dublu clic pe pictograma fisierului jurnal , se poate deschide fisierul ASCII logat . Pe lângă mesajele inresistrate se poate vedea ca informatiile statistice au fost de asemenea. Aceste linii corespund exact cu informațiile care sunt afisate în fereastra Bus Statistics window dinn timpul unei măsurători .
Evaluarea un fisier log
Fisierele log în format ASCII poate fi vizualizate cu editoare de text, dar pentru o evaluare completa este mai bine sa se utilizeze functiile pe care CANoe le prevede pentru analiza offline a fisierelor log.
De exemplu pentru a reda fisierul log înregistrat pentru ultima masuratoare în modul offline, si să se vizualizeze semnalul de răspuns în fereastra de Graphics se va proceda dupa cum urmeaza:
Se va trece CANoe in modul de lucru Offline.Din fereastra Measurement Setup se va selecta fisierul de log inregistrat la ultima masuratoare ca si sursa de date.Se poate porni acum din nou măsuratoarea cu tasta F9. Spre deosebire de modul Online aici CANoe oferă optiunea de a reluare a măsuratorii în slow motion (Start | Animate menu item sau tasta F8) sau în modul Single-Step (Start|Step menu item sau tasta F7).
Aceleasi functii de analiză sunt disponibile pentru a lucra în modul offline la fel ca în modul online. Datele logatei sunt afisate în format CAN în fereastra Trace si exista posibilitatea de a observa variatiile valorilor semnalelor in fereastra de Graphics.
Se pot introduce, de asemenea, filtre sau programe CAPL în configurarea de măsurare pentru a reduce si mai mult dimensiunea datelor sau se pot introduce functii suplimentare de analiză definite de utilizator.
Capitolul III
Introducere in limbajul de programare CAPL
Bazat pe limbajul de programare C , CAPL , sau CAN Acces Programming Language , este limbajul de programare utilizat exclusiv în mediile de instrumente bazate pe de CANalyzer si CANoe. Intentia originala de design al CAPL ( care se pronunță " kapple " ), a fost de a satisface cerintele pe bază de CAN ale de dezvoltatorilor de sisteme embedded printre care si :
• un control al tuturor operatiunilor de testare si măsurare
• control al sistemului sau al modululelor simulate specifice – CANoe sau CANalyzer –
• suport pentru unul sau mai multe canale de comunicare
• control de înregistrare si redare al evenimentelor si mesajelor
• Abilitatea de a interconecta cu alte aplicatii PC
Crearea mediului de programare CAPL a devenit necesara pentru a îndeplini aceste cerinte .
Folosirea CANalyzer sau CANoe în combinatie cu CAPL face posibilă crearea de aplicatii personalizate cu comportament definit de utilizator. Aplicatiile potentiale sunt limitate doar de imaginatia utilizatorului , sau de limitările hardware ( dacă este cazul ) , precum si de viteza a PC-ului .
III.1 Capacitatea de evaluare a programului CAPL
Instrumentul CANalyzer sau CANoe în sine , fără programe de CAPL , este suficient pentru a executa o simplă măsurare si analiză .
Cu programul CAPL implicat , măsurarea si analiza este foarte extinsă pentru comunicarea pe CAN . Un domeniu in care instrumentul CANoe nu poate functiona fără CAPL este o analiză care implică sincronizare . CAPL poate face o analiză mai eficient cu ajutorul de timer-elor .
CAPL poate fi folosit într- o aplicatie pentru :
• Analiza mesajelor specifice sau datelor specifice
• Analiza traficului de date
• Crearea si modificarea mediului de măsurare al instrumentelor CANoe sau CANalyzer
• Proiectarea unui modul de test personalizat
• Crearea asa numitului mediu “blackbox” pentru a simula restul retelei
• Crearea unui simulator de modul
• Crearea unui modul de testare personalizat
• Crearea unui modul de diagnosticare personalizat
• Crearea de programe pentru a efectua analize personalizate de log-uri de retea (sau redare ) fisiere
• Crearea de filtre complexe pentru logare
• Crearea unui mesaj complet sau generarea de continut de date de testare pentru validarea modulului / retelei .
• Programarea unui gateway functional între două retele diferite
III.2 Capacitatea de simulare a programului CAPL
De multe ori , atunci când o aplicatie embedded este în curs de dezvoltare,apare situatia ca o parte din aceasta sa nu fie disponibila pentru testare . Mediul sistem poate fi imitat cu ajutorul CAPL , de exemplu , pentru a simula traficul de date din toate nodurile de retea rămase . Din acest motiv , CAPL poate fi de asemenea utilizat pentru a simula :
• comportamentul sistemului folosind instructiuni usor de citit
• mesaje de “event” , mesaje periodice , sau mesaje repetitive conditionat
• evenimente produse de utilizator , cum ar fi apăsarea butoanelor de pe tastatura PC-ului
• noduri de retea
• evenimente de timp multiple , fiecare cu propriul său comportament programabil
• Functionare normală sau operare de diagnoza
• Modificări ale parametrilor fizici sau valori simbolice ( de exemplu , , " ON " , " OFF " )
• functii simple sau complexe ( sin, cos )
III.3 Crearea unui program CAPL
Desi CANoe asigura un numar mare de functii pentru analiza si transmitere care pot fi parametrizate in ferestre de configuratie specifice varietatea cerintelor pe partea de testare sau simulare vor duce la necesitatea utilizatorului de a creea propriile functii.Din acest motiv CANoe ofera limbajul de programare similar cu C numit CAPL.
Exemplu:
Crearea unui program CAPL cu care se pot numara mesajele de tipul EngineData(ID 64 hex) si scrie numarul acestora in Write window in momentul apasarii unei taste
In primul rand CANoe trebuie trecut in modul online.In simulation setup generatorul bloc care trimte mesajele Engine Data ciclic pe magistrala reprezinta sursa de date.In primul rand trebuie sa se decida unde se doreste inserarea programului CAPL in schema de masurare(measurement setup).Acest lucru se poate realiza prin functia Insert program node care apare prin click dreapta pe oricare din “hotspot-urile” disponibile in measurement setup.O functie bloc cu simbolul de program P apare in punctul selectat din measurement setup.Prin dublu click pe acest nod se poate selecta din meniul aparut un program deja existent sau prin introducerea unui nume oarecare se va incepe un nou program cu acel nume prin deschiderea automata a browser-ului CAPL.
CAPL este un limbaj de programare bazat pe evenimente.Fiecare program CAPL consta in proceduri bazate pe evenimente,cu care programul poate”reactiona” la evenimentele externe(aparitia mesajelor specifice pe magistrala CAN) sau apasarea unor taste.Cu ajutorul panourilor existente va permite utilizatorului sa creeze si sa editeze programe CAPL repede si usor.In principiu se,se poate folosi un editor de text oarecare pentru crearea programului simplu si rapid.Programele CAPL sunt fisiere ASCII cu numele default *.CAN,care trebuie compilat inaintea inceperii masuratorii folosind compilatorul furnizat impreuna cu CANoe.
Pentru programul descris mai sus va si mai intai nevoie de o variabila intreaga care va numara mesajele(counter).Exista un bloc definit pentru variabile in partea satnga sus a browser-ului unde trebuie introdusa aceasta variabila ca in exemplul urmator :
La fel ca orice variabila globala,aceasta variabila este automat initializata cu 0 la inceputul masuratorii.In urmatorul pas,aceasta variabila ar trebui incrementata oricand un mesaj EngineData este inregistrat.Prin urmare programul CAPL trebuie extinsa cu o procedura “on message”(care reactioneaza la evenimetul mesaj).Pentru a realiza acest lucru se da click dreapta e tipul de evenimente CAN din Browser si se selecteaza inserarea unei proceduri noi de acest tip
Acum un sablon de procedura apare in editorul text de proceduri.Se inlocuieste textul <newMessage> cu numele simbolic EngineData,care se poate scoate direct din baza de date cu ajutorul meniului popup CANdb Message.In timpul compilarii compilatorul CAPL inlocuieste numele simbolic cu identificatorul corespunzator 0x64.Acum raman de definit doar actiunile care trebuie realizate cand evenimentul apare.Deoarece scopul programului este sa numere mesaje,variabila counter trebuie incrementata de cate ori un mesaj este inregistrat.Procedura completa este urmatoarea:
Ultimul pas este scrierea numarului de mesaje Write window.Acest lucru poate fi facut de exemplu cand se apasa tasta “a”.In browser se poate selecta tipul Keyboard.Acest lucru determina procedura eveniment on message sa dispara deoarece apartine unui alt tip de evenimente.Aceasta ramane o componenta a programului CAPL si va aparea din nou in momentul in care se va selecta tipul mesaje.Acum se poate insera un eveniment de tip “Keyboard” in program din meniul popup dupa cum urmeaza:
Formatul de intrare %d se refera la variabila intreaga counter care se introduce dupa virgula.In cea mai mare parte aceasta comanda se aseamana cu comanda din C printf().Acesta este finalul programului care poate fi apoi salvat si rulat.Se compileaza cu tasta F9 iar daca s-a facut vreo eroare in program un mesaj va apare inpartea de jos semnaland aceasta eroare iar prin dublu click pe acest mesaj se va ajunge la locul unde a aparut eroarea.Dupa ce se corecteaza eroarea se recompileaza.In momentul in care programul a fost compilat fara erori mesajul “Compiled” apare in partea de jos a browser-ului.Se poate apoi porni masuratoareaGeneratorul bloc va incepe sa transmita mesaje ciclic de tipul EngineData,care sunt acum contorizate de program.De fiecare data cand se apasa tasta “a” in Write window va apare textul “n EngineData mesagges counted” unde n reprezinta numarul de mesaje numarate.
III.4 Simulare a sistemelor embedded in CaNoe
CaNoe furnizeaza variabile ale mediului cu scopul de a modela nodurile de retea ale magistralei de transmisie functionala. Aceste variabile de mediu sunt descrise de evenimente si stari ale sistemelui de mediu ( presiunea externa, temperatura, schimbarea pozitiilor etc.). Se pot observa si comuta in mod intentionat aceste stari- de ex. valorile variabile ale mediului- asupra utilizatorilor definiti a panourilor de control.
Pentru a lucra cu variabile de mediu in CAPL se foloseste procedura tip envVAr (cu rolul de a schimba variabile de mediu). Functiile CAPL getValue () and putValue () sunt utilizate sa citeasca si sa scrie variabile de mediu. Aceste limbaje de sistem si de acces simbolic catre diferite variabile definite in baza de date face posibila crearea de prototipuri simple de noduri de retea. Urmatoarea cerinta consta in crearea une configuratii complete CaNoe cu doua modele de noduri de retea si periferie asociata, adica panouri de control. Acest lucru ar trebui sa implice numai implementarea de functii distribuite. Dupa ce utilizatorul activeaza un comutator, primul nod il informeaza pe cel de-al doilea despre aceasta actiune. Al doilea nod activeaza apoi o lampa de semnalizare din perimetrul ei.
Aceasta functionalitate simpla a fost selectata ca sa directioneze atentia utilizatorului catre crearea de modele si nu catre functionalitate. Mai multe sisteme complexe de distributie pot sa cladeasca acelasi model conceptual in CaNoe fara nicio dificultate.
Un model pentru sisteme de distribuie poate fi creat in mod eficient in CaNoe in trei pasi :
Creaza baza de date cu mesaje, semnale si variabile de mediu.
Creaza perimetrul retelei de noduri, adica panourile de control.
Creaza modelele retelei de noduri in CAPL.
III.5 Crearea bazei de date
Primul pas consta in crearea unei baze de date care sa descrie urmatoarele doua aspecte semnificative ale sistemului :
Schimbul de informatii intre doua noduri de retea prin comunarea medie, adica magistrala de transmisie ; si
Interfata I/O care perimetru, adica “cuplarea” dintre fiecare nod si unitatile de intrare si iesire.
Mesajul bazei de date si semnalul obiectelor sunt disponibile pentru a descrie schimbul de informatii de-a lungul magistralei de transmisie CAN. Functionalitatea simpla a exemplului poate fi produsa de un semnal 1-bit care descrie starea comutarii la primul nod.
Acest semnal este reprodus intr-un mesaj CAN si este transmis doar daca statusul comutarii se schimba ( transmisie spontana).
Astfel, se creeaza o baza de date cu Editorul CANdb++, iar in baza de date se creeaza un mesaj, de ex. cu numele Msg 1 si identificator 100, care o sa fie transmis de primul nod. Se creeaza semnalul bsSwitch care sa descrie pozitia comutarii si sa o lege de Msg 1. In acest caz o lungime de semnal de un bit este suficienta atata timp cat cele doua statusuri au nevoie sa fie transmise, On (1) si Off (0) :
Baza de date furnizeaza varibilele de mediu care sa descrie interfata I/O intre noduri si perimetrul lor. Fiecare element periferic (Comutator, lampa indicatoare, slider, etc.) este ,,cuplat”de o variabila environment, adica este conectat la programul CAPL din cadrul retelei de noduri.
In acest exemplu sunt exact doua elemente periferice : A comuta la primul nod si o lampa indicatoare la al doilea nod. Asadar, doua variabile de mediu trebuie sa fie create in baza de date, ex. evLight si evSwitch :
Se salveaza baza de date, ex. sub denumirea de TOUR.DBC si se asociaza cu o configuratie goala ( Meniul de comanda : Dosar/Baza asociata).
III.6 Crearea panourilor
O aplicatie diferita, Editorul de panouri, este furnizata de CANoe pentru crearea periferiei de noduri.
In cadrul configuratiei in cauza, un panou trebuie sa fie creat pentru fiecare doua noduri. Primul panou are un singur punct de control, un comutator, in timp cel de-al doilea are o mica lampa ce serveste drept element indicator :
Editorul de panouri se poate porni prin activarea butonului de pe bara de instrumente CANoe.
Acesta asigura ca baza de date sa fie disponibila cu variabilele environment evSwitch si evLight care sunt necesare pentru cuplare.
In Editorul de panouri prima data se introduce numele primului nod in Optiuni/Marimea Panoului, Nume, Culori si Fond, ex. Panoul 1. In bara de sistem a Editorului de panou se alege un comutator si se plaseaza pe panou. Poti cupla comutatorul prin dublu click si apoi prin asignarea variabilei environment evSwitch la el. Poti eticheta comutatorul alegand elementul de afisaj de pe bara de instrumente, plasandu-l pe panou in stanga comutatorului si apoi configurandu-l cu un text, ex. ‘’Switch’’. Poti modifica marimea panoului printr-un click pe panoul de bord si tragand de el. Incearca sa nu adaugi panouri mai mari decat necesar, intrucat spatiul de ecran disponibil este de obicei foarte limitat si deci este o resursa pretioasa.
Salveaza panoul, ex. sub numele de SWITCH.CNP. Apoi creeaza panoul pentru cel de-al doilea nod in acelasi mod. Spre deosebire de un comutator, aici ar trebui sa introduci o lampa indicatoare drept element de afisaj. Pentru a face acest lucru, alege bitmap-ul indicator din bara de instrumente si apoi, prin dublu click, configureaza elementul precum un element de afisaj cu 2 stari. In casuta de dialog de configuratie trebuie de asemenea sa introduci un bitmap care sa fie folosit ca un indicator. In loc de a crea un nou bitmap, trebuie sa folosesti de exemplu, dosarul LAMP_2.BMP din directorul demo al CANoe DEMO_CAN_CN\AUTOMOT\BITMAPS\-BMP_2.
Inainte de a salva panoul, ex. sub numele de LIGHT.CNP, poti de asemenea eticheta lampa indicatoare prin insertia si configurarea textului static din stanga lui.
Finalizezi acest pas integrand panourile create in cadrul configuratiei CANoe. Pentru a face acest lucru, se deschide casuta de dialog a panoului de configuratie si se selcteaza din meniul de comanda Panou/Configurarea panourilor.
Se adauga cele doua panouri SWITCH.CNP si LIGHT.CNP la lista de panouri permanente si se deschid panourile prin activarea butonului Deschide toate panourile. Pozitioneaza panourile pe ecran conform cerintelor de lucru si salveaza pozitiile panoului selectat la meniul de comanda Panou/Salveaza pozitiile de panou. Inainte de a crea modelele nodului de retea, trebuie sa salvezi configuratia pe care tocmai ai creat-o apasand butonul de pe bara de instrumente.
III.7 Crearea Modelelor Nodurilor de Retea
Se creeaza modelele nodului de retea folosind fereastra simulation setup. Cel putin modelul primului nod trebuie sa transmita un mesaj atunci cand comutatorul este activat si asadar nu poate fi inserat in setup-ul de masurare.
In setup-ul de simulare se da click pe liniile magistralei de transmisie pentru a insera noi modele de noduri de retea.
In acest exemplu este nevoie de doua noduri de retea in setup-ul simularii : Primul nod inlocuieste pozitia de comutare, iar al doilea reactioneaza la acesta prin activarea sau dezactivarea unei mici lampi. Se poate accesa casuta de dialog a configuratiei pentru cele doua noduri prin apasarea din nou a butonului din dreapta a mouse-ului. Aici se introduce numele nodului (ex. ECU 1 sau ECU 2) si se asigneaza un nume de dosar la fiecare dintre cele doua noduri (ex. ECU1.CAN sau ECU2.CAN). Numele nodului sunt mentionate in iconitele nodurilor ; numele dosarului se refera la programele CAPL care simuleaza functionalitatea celor doua noduri. Se da dublu click pe fiecare nod pentru a deschide browser-ul CAPL in mod particular pentru programul CAPL.
Primul program CAPL apartine de nodul in perimetrul caruia exista o comutare.
Cand pozitia de comutare se schimba, programul are nevoie de o noua valoare de comutare si imediat isi are iesirea in magistrala de transmisie :
Cel de-al doilea nod de retea reactioneaza la acest mesaj. Programul CAPL citeste valoarea semnalului magistralei de transmisie pentru pozitia de comutare si apoi activeaza sau dezactiveaza lampa indicatoare din perimetrul ei. A se nota ca valoarea de comutare este primita numai prin intermediul valorii de semnal a magistralei de transmisie. Valoarea variabilei environnment envSwitch nu este cunoscuta in cadrul programului CAPL. Prin aceasta are loc comunicarea dintre cele doua noduri exclusiv prin magistrala de transmisie CAN :
Acum are loc masurarea din CANoe. Ori de cate ori se activeaza comutarea in Panoul 1 lampa indicatoare lumineaza. Ori de cate ori se opreste comutarea, lampa indicatoare se stinge.
Fereastra ‘’the Trace’’ iti arata atat comunicarea magistralei de transmisie (Transmisia spontana a mesajului Msg. 1 atunci cand pozitia de comutare se schimba) si valorile variabilelor environment evSwitch si evLight.
A se nota cat de usor si direct acest model al unul sistem de distributie poate fi modelat in CAPL si cum baza de date isi asuma importanta centrala.
Comunicarea dintre cele doua noduri prin intermediul magistralei de transmisie CAN prin mijloacele emisiei spontane, adica transmitand mai departe imediat un mesaj CAN ca raspuns la o schimbare de stare, nu reprezinta singura capacitate de modelare a comportamentului magistralei de transmisie al unui nod de retea.
Protocolul de transmisie ciclica poate fi de asemenea implementat cu sistemul de limbaj CAPL precum timpi.
Capitolul IV
Comunicarea cu sursa programabila de tensiune EX355P
Comunicatia cu sursa de tensiune are aplicatie pe partea de testare fiind utila din acest punct de vedere in initializarea comunicatiei pe magistrala si setarea sistemului intr-o faza incipienta in care se afla de obicei(in caza real) masina inaintea pornirii motorului.Programul de comunicatie cu sursa de tensiune programabila este realizat in CAPL si este folosit in simulare de catre nodul SourceCom.Programul se foloseste de variabilele declarate in baza de date Source database.dbc Comunicatia se realizeaza printr-un cablu serial cu adaptor RS232 to USB.
La inceputul programului se initializeaza comunicatia cu portul serial prin apelarea functiei InitSerialPort.
IV.1Functia InitSerialPort
In faza initiala portul va fi inchis si apoi deschis pentru a initializa comunicatia urmand ca prin comanda RS232Configure sa se configureze parametri pentru comunicatie cu sursa.
RS232Configure(getValue(EnvPort3),9600,8,1,0))
Aceeasi parametri va trebui sa fie prezenti si in configurarea sursei pentru ca aceasta sa poata comunica :port, baudrate, numberOfDataBits, numberOfStopBits, parity
In cazul acesta valoarea portului este data de variabila environment EnvPort3 care in cazul acesta are valoarea 12.Motivul pentru care se foloseste o variabila environment este ca pe tot parcursul programului este necesara declararea portului de repetate ori iar in cazul in care portul se schimba este necesara doar inlocuirea variabilei din baza de date pentru ca programul sa functioneze
Comanda de handshake asigura in cazul in care se transmite un volum mare de date ca receiver-ul este pregatit sa primeasca datele respectiv ca transmitter-ul este pregatit sa le transmita.In cazul acestui program fiind vorba de un volum mai mic de date handshake-ul este setat pe disable
(Rs232SetHandshake(getValue(EnvPort3), kHANDSHAKE_DISABLED, 0, 0, 0, 0))
Prin comanda Rs232Receive se pregateste buffer-ul pentru receptionarea datelor pe cablul serial Dupa aceasta comanda se ajunge la sfarsitul functiei.
IV.2.Functia RS232OnSend
In cadrul acestei functii se initializeaza variabila flag GSending cu valoarea 0 pentru a nu permite trimiterea altor date pana cand transmisia existenta nu se incheie.
RS232OnSend( dword port, byte buffer[], dword number )
{
// set state
gSending = 0;
writeLineEx(0,kINFO,"Transmission of %d bytes from port %d completed !", number, port);
}
IV.3.Functia RS232OnReceive
Aceasta functie are rolul ca la primirea datelor de la surasa sa nu lase sa se depaseasca numarul de bytes alocati pentru buffer-ul in care se vor copia datele primite.
RS232OnReceive( dword port, byte buffer[], dword number )
{
dword numberOfBytesToCopy;
// collect data as long as buffer has space for it
if ( (gNumberOfReceivedBytes+number)>kBUFFER_SIZE )
{
numberOfBytesToCopy = kBUFFER_SIZE-gNumberOfReceivedBytes; // no more than that ! it is full now
} else {
numberOfBytesToCopy = number;
}
if ( numberOfBytesToCopy==0 )
{
return; // nothing to add
}
CopyBuffer(gReceiverBuffer,gNumberOfReceivedBytes,buffer,numberOfBytesToCopy);
gNumberOfReceivedBytes += numberOfBytesToCopy;
}
IV.4.Functia CopyBuffer
Copierea bytes-ilor primiti va fi realizata cu functia CopyBuffer
CopyBuffer( byte destBuffer[], dword destOffset, byte srcBuffer[], dword srcNumber )
{
dword i;
for (i=0; i<srcNumber; i++)
{
destBuffer[destOffset+i] = srcBuffer[i];
}
}
IV.5.Programul principal
Dupa apelarea functiei InitSerialPort se verifica flag-ul gSending care este initial pe 0.Acesta se foloseste pentru a semnaliza o transmisie in curs de desfasurare in cazul in care are valoarea 1,iar in caz contrar putand fi efectuata o noua transmisie.
if ( gSending )
{
writeLineEx(0,kWARN,"Ongoing transmission, please wait for completion of previous one !");
return;
writeLineEx(0,kWARN,"Transmission finished");
}
In variabila buffer de tip sir de bytes se stocheaza datele care vor fi transmise apoi catre sursa de tensiune.In faza initiala se trimit aceste data cu functia Rs232Send pe ca tensiunea si curentul existente pe displayul sursei sa fie afisate si pe panoul sursei
buffer[0] = 0x56;
buffer[1] = 0x3F;
buffer[2] = 0x0D;
buffer[3] = 0x0A;
// writeLineEx(0,kWARN,"Transmission finished");
if(0==Rs232Send(getValue(EnvPort3),buffer,4))
{
writeLineEx(0,kERROR,"An error occurred during write of block of data to the serial port %d.", getValue(EnvPort3));
return;
} else {
writeLineEx(0,kINFO, "Write block of bytes to serial port %d worked well.", getValue(EnvPort3));
}
setTimer(initdisplay,2000);
In cadrul bazei de date Source database.dbc sunt definite variabilele environment EnvVoltageCoarseLeft, EnvVoltageCoarseRight, EnvVoltageFineLeft, EnvVoltageFineRight, EnvCurrentRight si EnvCurrentLeft acestea fiind conectate la butoanele de reglaj al tensiunii respectiv al curentului.
Prin apasarea butonului de pe panoul de comanda Coarse Left se apeleaza subprogramul aferent variabilelor care are ca efect scaderea tensiunii pe sursa cu un volt.
on envVar EnvVoltageCoarseLeft
{
byte buffer[kBUFFER_SIZE];
if ( gSending )
{
writeLineEx(0,kWARN,"Ongoing transmission, please wait for completion of previous one !");
return;
}
if(getValue(this)!=1)
return;
buffer[0] = 0x56;
buffer[1] = 0x3F;
buffer[2] = 0x0D;
buffer[3] = 0x0A;
if(0==Rs232Send(getValue(EnvPort3),buffer,4))
{
writeLineEx(0,kERROR,"An error occurred during write of block of data to the serial port %d.", getValue(EnvPort3));
return;
} else {
writeLineEx(0,kINFO, "Write block of bytes to serial port %d worked well.", getValue(EnvPort3));
}
CoarseLeft = 1;
cancelTimer(tBytesReceived);
setTimer(tBytesReceived,1000);
// set state
gSending = 1;
}
Prin apasarea butonului de pe panoul de comanda Coarse Right se apeleaza subprogramul aferent variabilelor care are ca cresterea tensiunii pe sursa cu un volt.
on envVar EnvVoltageCoarseRight
{
byte buffer[kBUFFER_SIZE];
if ( gSending )
{
writeLineEx(0,kWARN,"Ongoing transmission, please wait for completion of previous one !");
return;
}
if(getValue(this)!=1)
return;
buffer[0] = 0x56;
buffer[1] = 0x3F;
buffer[2] = 0x0D;
buffer[3] = 0x0A;
if(0==Rs232Send(getValue(EnvPort3),buffer,4))
{
writeLineEx(0,kERROR,"An error occurred during write of block of data to the serial port %d.", getValue(EnvPort3));
return;
} else {
writeLineEx(0,kINFO, "Write block of bytes to serial port %d worked well.", getValue(EnvPort3));
}
CoarseRight = 1;
cancelTimer(tBytesReceived);
setTimer(tBytesReceived,1000);
// set state
gSending = 1;
}
Prin apasarea butonului de pe panoul de comanda Fine Left se apeleaza subprogramul aferent variabilelor care are ca efect scaderea tensiunii pe sursa cu un milivolt.
on envVar EnvVoltageFineLeft
{
byte buffer[kBUFFER_SIZE];
if ( gSending )
{
writeLineEx(0,kWARN,"Ongoing transmission, please wait for completion of previous one !");
return;
}
if(getValue(this)!=1)
return;
buffer[0] = 0x56;
buffer[1] = 0x3F;
buffer[2] = 0x0D;
buffer[3] = 0x0A;
if(0==Rs232Send(getValue(EnvPort3),buffer,4))
{
writeLineEx(0,kERROR,"An error occurred during write of block of data to the serial port %d.", getValue(EnvPort3));
return;
} else {
writeLineEx(0,kINFO, "Write block of bytes to serial port %d worked well.", getValue(EnvPort3));
}
FineLeft = 1;
cancelTimer(tBytesReceived);
setTimer(tBytesReceived,1000);
// set state
gSending = 1;
}
Prin apasarea butonului de pe panoul de comanda Fine Right se apeleaza subprogramul aferent variabilelor care are ca efect cresterea tensiunii pe sursa cu un milivolt.
on envVar EnvVoltageFineRight
{
byte buffer[kBUFFER_SIZE];
if ( gSending )
{
writeLineEx(0,kWARN,"Ongoing transmission, please wait for completion of previous one !");
return;
}
if(getValue(this)!=1)
return;
buffer[0] = 0x56;
buffer[1] = 0x3F;
buffer[2] = 0x0D;
buffer[3] = 0x0A;
if(0==Rs232Send(getValue(EnvPort3),buffer,4))
{
writeLineEx(0,kERROR,"An error occurred during write of block of data to the serial port %d.", getValue(EnvPort3));
return;
} else {
writeLineEx(0,kINFO, "Write block of bytes to serial port %d worked well.", getValue(EnvPort3));
}
FineRight = 1;
cancelTimer(tBytesReceived);
setTimer(tBytesReceived,1000);
// set state
gSending = 1;
}
Prin apasarea butonului de pe panoul de comanda Current Right se apeleaza subprogramul aferent variabilelor care are ca efect cresterea curentului pe sursa cu un miliAmper.
on envVar EnvCurrentRight
{
byte buffer[kBUFFER_SIZE];
if ( gSending )
{
writeLineEx(0,kWARN,"Ongoing transmission, please wait for completion of previous one !");
return;
}
if(getValue(this)!=1)
return;
buffer[0] = 0x49;
buffer[1] = 0x3F;
buffer[2] = 0x0D;
buffer[3] = 0x0A;
if(0==Rs232Send(getValue(EnvPort3),buffer,4))
{
writeLineEx(0,kERROR,"An error occurred during write of block of data to the serial port %d.", getValue(EnvPort3));
return;
} else {
writeLineEx(0,kINFO, "Write block of bytes to serial port %d worked well.", getValue(EnvPort3));
}
CurrentRight = 1;
cancelTimer(tBytesReceived);
setTimer(tBytesReceived,1000);
// set state
gSending = 1;
}
Prin apasarea butonului de pe panoul de comanda Current Left se apeleaza subprogramul aferent variabilelor care are ca efect scaderea curentului pe sursa cu un miliAmper.
In toate cazurile variabilele CoarseLeft,CoarseRight,FineLeft,FineRight,CurrentLeft si CurrentRight iau valoarea 1 fiind folosita cu rol de flag dupa cum se va putea observa in continuare.
In cadrul apelului fiecarui subprogram prezentat mai susse foloseste comanda set Timer(tBytesReceived,1000);aceasta avand ca efect executia subprogramului declarat in cadrul timerului tBytesReceived dupa 1 secunda de la pornirea acestuia.Inaintea acestui apel se foloseste functia cancelTimer pentru a se evita o apelare redundanta.Acest subprogram definit in cadrul apelarii timer-ului se foloseste pentru afisarea tensiunii si curentului citite de la sursa,pe panoul de comanda.Pentru fiecare din flag-urile setate mai sus se apeleaza un subprogram care afiseaza dupa caz tensiunea si curentul pe display-ul de la sursa dupa cum urmeaza:
on timer tBytesReceived
//Coarse Left
{ if ( CoarseLeft==1 )
{if (gReceiverBuffer[3] == 48)
{gReceiverBuffer[2] = gReceiverBuffer[2]-1;
gReceiverBuffer[3] = 57;
}
else {gReceiverBuffer[3] = gReceiverBuffer[3]-1;
}
VoltageDisplay=(gReceiverBuffer[2]-48)*10+(gReceiverBuffer[3]-48)+((gReceiverBuffer[5]-48)*0.1)+((gReceiverBuffer[6]-48)*0.01);
putValue(EnvVoltageDisplay,VoltageDisplay);
}
In aceeasi maniera se trateaza si celelalte flag-uri:Coarse Right,Fine Left,Fine Right,Current Left si Current Right.
Capitolul V
Model de simulare pentru comunicarea ECU-urilor pe CAN
Acest model este constituit din trei noduri care comunica intre ele pe CAN.Simularea are atasat baza de date Opel.dbc in care sunt descrise in detaliu nodurile Engine,Display si Light.
Nodul Engine transmite mesajul EngineState care este compus din semnalele OnOff si EngineSpeed.Semnalul OnOff este relevant pentru controlul starii motorului pornit/oprit iar semnalul EngineSpeed pentru controlul turatiei motorului.Nodul Light transmite mesajul LightState care este compus din semnalele HeadLight si FlashLight.Aceste noduri sunt folosite pentru a modifica semnalele descrise de mai sus acest lucru realizandu-se prin intermediul panoului de comanda Control
Prin intermediul acestui panou se pot modifica valorile semnalelor de mai sus acest lucru realizandu-se prin intermediul variabilelor de sistem la care sunt legate butoanele panoului de comanda.Nodul Display are rolul de a prelua mesajele EngineState si LightState si de a afisa valorile semnalelor continute de acestea pe panoul Display.
Mesajele descrise mai sus sunt continute de baza de date Opel.dbc.Intr-un mediu real este importanta respectarea ciclicitatii fiecarui mesaj care este transmis pe CAN.Daca un mesaj este transmis in mod normal ciclic la fiecare 40 de ms si o eroare de comunicatie are ca efect de exemplu intarzierea acestui mesaj cu 10 milisecunde acest lucru va declansa o eroare de comunicare.De obicei cerintele legate de acest aspect sunt impuse de catre beneficiarul proiectului cum de asemenea beneficiarul poate sa ceara ca aceste cerinte sa fie testate.
V.1.Testarea ciclicitatii mesajelor
Un exemplu poate fi testarea ciclicitatii mesajelor transmise pe CAN.Acest test este realizat in programul CAPL care a fost descris intr-un capitol precedent.
Testul CycleTime verifica ciclicitatea mesajelor EngineState si LightState.
Acest lucru este realizat cu ajutorul functiei G_TST_CheckCycleTime care are la baza functiile predefinite din CAPL G_TST_CheckCycleTime si TestCheckConstraint.
Aceste functii sunt interdependente prima avand rolul de a verifica daca intervalul de transmitere al unui mesaj se incadreaza intre valorile minima si maxima dorite,aceasta verificare facandu-se pe parcursul unui interval de timp predefinit,iar cea de-a doua sa verifice daca intervalele de transmitere au fost in afara valorilor minima si maxima pe parcursul verificarii.In cazul in care cel putin o data acest lucru s-a intampla testul va cadea iar in caz contrar ca trece.
Dupa efectuarea testului raportul obtinut va evidentia intervalul de timp in care s-a facut verificarea si decate ori s-a depasit valoarea minima sau maxima
Dupa cum se poate vedea in raportul de mai sus valoarea minima asteptata este de 18 ms iar cea maxima de 21 ms,verificarea realizandu-se pe parcursul a 5000 de ms.In acest interval de timp s-au facut 249 de verificari care au avut ca rezultat un ciclu mediu de 20 de ms pentru mesajul EngineState testul fiind finalizat cu rezultatul Pass.
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Model de Simulare Pentru Comunicarea Ecu Urilor pe Can (ID: 107408)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.