Aplicații ale Protocolului Dhcp în Domeniul Automotive

UNIVERSITATEA “LUCIAN BLAGA” DIN SIBIU

FACULTATEA DE INGINERIE

DEPARTAMENTUL DE CALCULATOARE ȘI INGINERIE ELECTRICĂ

PROIECT DE DIPLOMĂ

Conducator științific : Prof dr ing Remus Brad

Absolvent: Băra Maria-Claudia

Specializarea Calculatoare

Sibiu, 2015 –

UNIVERSITATEA “LUCIAN BLAGA” DIN SIBIU

FACULTATEA DE INGINERIE

DEPARTAMENTUL DE CALCULATOARE ȘI INGINERIE ELECTRICĂ

Aplicații ale protocolului DHCP în domeniul automotive

Conducător științific : Prof dr ing Remus Brad

Absolvent: Băra Maria-Claudia

Specializarea Calculatoare

Cuprins

Prezentarea temei……………………………………………………………………..5

Considerații teoretice……………………………………………………………………….6

DHCP…………………………………………………………………………………………6

1.1 Prezentare generală…………………………………………………………………6

1.2 Funcționalitate……………………………………………………………………….7

2. DOIP……………………………………………………………………………………………12

2.1 Prezentare generală…………………………………………………………………12

2.2 Funcționalitate……………………………………………………………………….23

3. Protocoale de comunicație………………………………………………………………27

3.1 CAN………………………………………………………………………………………27

3.2 LIN………………………………………………………………………………………..28

3.3 Ethernet………………………………………………………………………………….29

4. Electronic Control Unit (ECU)………………………………………………………..33

4.1 Prezentare generală………………………………………………………………….33

4.2 Prezentare diferite funcționalități în corelație cu ECU………………….35

5. Aplicații pentru dezvoltare……………………………………………………………..40

5.1 CANoe…………………………………………………………………………………..40

III. Implementarea aplicației…………………………………………………………………44

1. Scopul aplicației………………………………………………………………………..44

2. Prezentarea aplicației………………………………………………………………….45

3. Funcționalități funcții…………………………………………………………………48

4. Configurația CANoe…………………………………………………………………..51

5.Funcționarea aplicației…………………………………………………………………53

6. Rezultate obținute………………………………………………………………………55

7. Dezvoltări ulterioare…………………………………………………………………..56

IV. Concluzii………………………………………………………………………………………..58

V. Bibliografie………………………………………………………………………………………59

VI. Anexă………………………………………………………….…………….60

I. Prezentarea aplicației

Aplicația dezvoltată are scopul de a simula diagnoza utilizând protocolul DoIp (Diagnostic over Internet Protocol).

Pentru a face posibilă această simulare , am pornit de la a configura o rețea cu nimic existent cum ar fii adrese MAC sau IP.

Primul pas facut a fost sa creez o configurație într-un tool specific domeniului Automotive , numit CANoe , unde am creat două noduri DHCP și DoIP. Aceste două noduri sunt conectate pe un BUS de ETHERNET , tehnologie foarte căutată datorită ușurinței în crearea rețelelor,de asemenea protocolul este proiectat să permită crearea rapidă și ușoară de rețele pentru noi dispozitive. Totodată este foarte ușor de adăugat noi dispozitive în rețele deja create.

După ce am creat nodurile , am luat pe rând fiecare nod începând cu DHCP scriind în cod pașii necesari pentru configurarea de rețea. I-am alocat adresă de IP clientului nostru care este ECU-ul și ne-am alocat adresă de IP nouă ca server. Aplicația este gândită în așa fel încât , atunci când primim informații pe bus-ul de comunicație de la ECU noi să le preluăm într-un șir pe care îl vom folosii mai departe în crearea pașilor specifici DHCP.

Pentru că știm fiecare informație pe ce poziție se află în șir , le vom prelua în variabile specific denumite. Prin urmare vom avea atât adrese IP cât și adrese MAC necesare în indentificarea în comunicație. Pașii specifici DHCP-ului sunt DISCOVER , OFFER, REQUEST si ACK. În cod se găsesc doar pașii OFFER și ACK specifici server-ului care reacționează ca și răspuns la cererile clientului de alocare de adresă IP și MAC. Prin urmare , la cerințele clientului , urmăm un set de pași prin care îi facem o ofertă clientului , iar prin schimbul de mesaje indentificăm faptul că acesta este de acord și preia ca date ceea ce trimitem noi.

Nodul de DOIP folosește adresele de IP din nodul DHCP , acestea fiind eticheta de interacționare dintre client și server. Ca și scop , prin DOIP dorim să trimitem o cerere de diagnoză către client , cu anumiți parametrii de configurare , la care să primim răspuns pozitiv . Parametrii de configurare reprezintă versiunea protocolului DOIP, tipul încărcăturii și date, necesare pentru a vedea dacă ce am trimis este și ceea ce am primit.

Pentru a fii mai ușor de urmărit , am făcut un Panel , în care avem posibilitatea de a schimba adresa de IP a clientului ( în caz ca dorim alta față de cea folosită), iar parametrii de configurare DOIP apar în câmpuri denumite specifice , având posibilitatea de trimitere a cererii și de vizualizare a răspunsului tot în câmpuri speficifice.

II. Considerații teoretice

1. DHCP

1.1 Prezentare generală

DHCP prescurtat de la Dynamic Host Configuration Protocol , este un protocol de rețea de calculatoare folosit de gazde (clienți DHCP) , care atribuie adrese IP și alte informații de configurare de rețea importante în mod dinamic.[1.1]

Prin DHCP calculatoarele cer adrese IP și parametrii de configurare a rețelei automat de la un server DHCP reducând necesitatea unui administrator de rețea care să configureze aceste cerințe manual.

Acest protocol operează pe baza modelului client-server. Este foarte larg răspândit în toate în toate rețelele moderne de la rețele în cadrul casei până la cele de campus sau regionale.[1.1]

Ca principiu de bază , DHCP, trimite un mesaj de broadcast , interogând informațiile necesare precum gateway, nume de domeniu etc.

Server-ul DHCP are 3 tipuri de implementări în funcție de implementare :

Alocare dinamică – administratorul de rețea rezervă o clasă de adrese de IP pentru DHCP, iar fiecare calculator din LAN este configurat să ceară o adresă IP de la server în timpul configurării. Această configurare folosește un concept de realocare de adrese IP fără reînoire după o anumită perioadă de timp.

Alocare automată – unde server-ul DHCP păstrează toate adresele alocate într-o tabelă putând aloca preferențial aceeași adresă IP unui client care a mai deținut aceea adresă.

Alocare statică – server-ul DHCP alocă o adresă de IP bazată pe adresa MAC a clientului.

1.2 Funcționalitate

Figura 1-1

Comunicarea DHCP-ului se face utilizând UDP (User Datagram Protocol). DHCP deține două porturi pentru operațiile sale, care sunt la fel ca și la protocolul BOOTP. Portul 67 este portul destinație al server-ului iar portul 68 este folosit de client.În principal , DHCP se încadrează în patru faze :descoperire server,se face oferta pentru adresa IP,se cere adresa IP,se confirma adresa IP.[1.1]

Figura 1-1 ilustrează pașii parcurși de Client și Server până la finalizarea acceptului de utilizare a rețelei.Primul pas este acela când se efectuează un broadcast (”difuzare”) inițiat de către client. Adresa de destinație folosită de către client este 255.255.255.255 sau subnet-ul specific.Clientul mai poate solicita , de asemenea , ultima sa adresa de IP folosită, iar dacă a rămas conectat la aceeași rețea , server-ul îi poate acorda cererea. Altfel , clientul este ”obligat” să refacă cererea.

Figura 1-2

Figura 1-2 prezintă conținutul mesajului DHCPDICOVER.

Atunci când server-ul primește un mesaj de tipul DHCPDISCOVER de la un client , mesaj ce reprezintă cererea de adresă IP, server-ul rezervă o adresă IP și îi face o ofertă prin intermediul mesajului DHCPOFFER. Mesaj ce conține adresa MAC a clientului, adresa IP care îi este oferită, masca subrețelei, durata de timp a ofertei precum și adresa IP a server-ului DHCP care face oferta.[1.1]

Figura 1-3

Figura 1-3 prezintă conținutul mesajului DHCPOFFER.

Ca răspuns la mesajul de DHCP offer al server-ului , clientul trimite un mesaj DHCPREQUEST , care reprezintă un broadcast către server , solocitând adresa oferită în mesajul anterior. Un client poate primii multiple oferte de la multiple servere, însă acceptă doar una dintre ele. În funcție identificarea de către server a opțiunilor din mesajul anterior , server-ele sunt informate a cui cerere a fost acceptată.[1.1]

Figura 1-4

Figura 1-4 prezintă conținutul mesajului DHCPREQUEST.

Când un server primește mesajul DHCPREQUEST de la client , procesul de configurare intră în faza finală. Faza de confirmare implică trimiterea unui pachet DHCPACK către client. Acest pachet conține durata de timp până la expirarea ofertei plus alte informații de configurare pe care clientul le-a cerut. În acest punct procesul de configurare este complet.

Figura 1-5

Figura 1-5 prezintă conținutul mesajului DHCPACK.

2. DOIP

2.1. Prezentare generală

Diagnostic Over Internet Protocol, denumit și ISO 13400, specifică cerințele de comunicare pe diagnoză între echipamentele de testare externe și componentele electronica ale unui vehicul care folosește IP (Internet Protocol),TCP (Transmision Control Protocol) sau UDP (User Datagram Protocol).

Figura 2-2

Figura 2-1 ilustrează cele mai aplicabile implementări de aplicatii utilizând DOIP.

1.2 Cerințele Nivelului Rețea

1.2.1 Nivelul MAC

Are limită de aproximativ 1500 octeți conform standardului IEE 802.3 al sistemelor de bază, însă nivelele superioare (IP) vor gestiona fragmentarea.Adresa MAC trebuie să fie unică conform cu standardul IEE 802.3.

1.2.2 Protocolul de Internet (IP)

Protocolul specificat în această parte a ISO 13400 este bazat pe standardele Protocolului de Internet cunoscute ca și ”IPv4” , ”IPv6”.IPv4 este specificat pentru aplicații a acestui protocol de comunicație în zonele de rețea unde compatibilitatea IPv4 este necesară. Protocolul de Internet este bazat pe datagrame, fiabil și localizat pe nivelul rețea în conformitate cu arhitectura nivelurilor OSI.

IP-ul este primul protocol de transmisie-mediu-independent.

Figura 3-2

1.2.3 Address resolution protocol (IPv4)

Address resolution protocol (ARP) și protocolul Neighbour discovery protocol (NDP) sunt metode de a determina adresa hardware (MAC) a gazdei, atunci când doar IP-ul este cunoscut. Mai sunt folosite pentru a verifica dacă adresa IP este în folosință de altă gazdă.ARP este localizat în nivelul rețea în conformitate cu nivele OSI-ISO.

Dacă IPv4 este folosit atunci fiecare entitate DOIP trebuie să implementeze protocolul ARP.

1.2.4 Internet Control message protocol (ICMP)

Este o parte din suita IP și este folosit să trimită mesaje de eroare, de exemplu : pentru a indica dacă un serviciu de cerere nu este valabil sau că un dispozitiv gazdă nu a putut fi atins.Este o parte obligatorie a stivei IP și este localizat pe nivelul rețea în conformitate cu nivelurile OSI-ISO.

1.3 Cerințele Nivelului Transport

1.3.1 Transmission Control Protocol (TCP)

Este un protocol orientat pe conexiune unde aplicațiile pe rețeaua gazdă pot stabilii conexiuni punct la punct, unde se pot schimba informații.Protocolul garantează fiabilitate/siguranță în transmisia datelor de la transmițător la receptor.Mai deține controlul fluxului de date și controlul congestiei.Este localizat pe nivelul transport în conformitate cu nivelele OSI-ISO.Folosește o pereche de numere de porturi (unul pentru trimitere, unul pentru recepție,apelarea la distanță a portului, apelarea locală a portului) pentru a identifica o conexiune.Portul de trimitere pe o gazdă va fii portul de recepție pe o altă gazdă și vice-versa.

1.3.2 User Datagram Protocol (UDP)

Este un protocol de conexiune.Nu garantează siguranța și garanția comenzii cum face TCP.Pachetele ajung în orice ordine sau se pot pierde fără notificarea transmițătorului sau receptorului.Chiar și așa, UDP este mai rapid și mai eficient pentru multe scopuri legate de timp sau de categorie ușoară.UDP este localizat pe nivelul transport în conformitate cu arhitectura OSI-ISO.

Figura 4-3

Figura 2-3 semnifică porturile UDP, însă aceasta nu ilustrează care porturi sunt sunt necesare pentru a implementa alte standarde de protocoale specificate în ISO 13400.

1.4 Cerințele Nivelului Aplicație

1.4.1 Dynamic Host Configuration Protocol (DHCP)

Dynamic Host Configuration Protocol este un protocol de rețea de tip client-server care deține un mecanism pentru alocarea de adrese IP utilizând protocolul de transport UDP.

DHCP asigură mecanismul pentru ca un client să achiziționeze toti parametrii de IP de care are nevoie pentru a comunica cu succes pe rețeaua locală.

Figura 5-4

Figura 2-4 arată localizarea protocolului DHCP în cadrul nivelelelor OSI-ISO.

1.4.2 Atribuirea adresei IP

1.4.2.1 Generalități

Atribuirea adresei IP specifică felul cum o entitate de DOIP achiziționează o adresa de IP validă în așa fel încât sa comunice pe o rețea de bază.

În general următorii parametrii sunt necesari pentru o adresare IP :

-adresă IP

-mască subnet

Bazându-ne pe scenarile de comunicație specificate în ISO 13400-1, infrastructura de rețea asigura adrese IP sau prevede etitatea DoIP sa asigneze independet adrese IP care să nu fie în conflict cu adrese de IP ale altor noduri de rețea locală.

1.4.2.2 Alocarea adreselor IPv4

În functie de cum comunică o entitate de DoIP, intr-un mediu de infrastructură sau că operează intr-o conexiune punct la punct , adresa de IP trebuie să fie asignată luând în considerare specificațiile impuse de IPv4. Aceste subclauze descriu cum o adresă IP poate fi configurată într-un timp minim, pentru a asigura cu conexiune rapidă.

Foarte important : dacă echipamentele de testare externe sunt bazate pe sisteme de operare standard, timpul total necesar pentru a obține o adresă de IP depinde de configurație și de algoritmii de asignare a adresei IP a acestor operații, și pot varia între câteva secunde până la cateva minute.

1.4.2.3 Valabilitatea adresei IP si reînoirea acesteia

Aici vom specifica cererile pentru a șterge o adresă de IP configurată sau pentru a reînoii.

Fiecare enitate DoIP ar trebui sa steargă adresa IP atunci când una din condițile de mai jos :

-termenul de valabilitate (timpul) asignat de către DHCP pentru adresa IP a expirat, incluzând mesajul de DHCPNAK sau dacă o nouă asignare de adresă IP a apărut între timp.

-echipamentul de testare extern a fost deconectat.

-adresa de IP este invalidată de la distanță.

2.2 Protocolul DoIP – Descriere tehnică

2.2.1 Protocolul de comunicație IP bazat pe vehicul

2.2.1.1 Informații generale

-Item : un nume scurt pentru elemtul de mesaj. Acest nume va fi folosit atunci când elementul de mesaj este referit la această parte a ISO 13400.

-Pos.: definește poziția (număr pe biți) fiecărui element de mesaj individual intr-un mesaj de DoIP. Poziția bitului mereu startează cu zero si este contorizat de la începutul fiecărui mesaj în parte.

-Len:reprezintă lungimea(număr pe biți) respectivului element de mesaj.

-Description: conține o descriere mai detaliată a fiecărui mesaj individual și scopul lor.

-Values:afișeză intervalul de valori suportate și întelesul fiecărei valori în parte a respectivului element de mesaj.

-Support:conține informații care specifică dacă un mesaj specific sau un element de mesaj ar trebui suportat de entitatea DoIP. Chiar dacă un mesaj în sine este definit ca opțional, el ar trebui să conțină elemente obligatorii care ar trebui implementate dacă mesajul în sine este suportat.

-Port and protocol:specifică pe care protocol care stă la baza unui anumit tip de incărcătură este suportat și care port îl folosește.

2.2.1.2 Structura mesajului specific protocolului DoIP

Figura 6-5

Figura 7-6

Figura 8-7

Echipamentele de testare externe ar trebui să folosească header-ul de negative acknowledge al mesajului de DoIP în timpul fazei de dezvoltare pentru a verifica implementarea corectă a mesajului de DoIP în entitatea de DoIP. Cu toate acestea, echipamentele de test externe cu producție în serie nu ar trebui să trimită mesaje de negative acknowledge, pentru a prevenii mesajele de DoIP să se deplaseze înainte și înapoi între sistemele de test externe și entitățile de DoIP.

Figura 9-8

Figura 2-8 ilustrează structura antetului de negative acknowledge.

Figura 10-9

Figura 2-9 ilustrează valorile pe care le poate lua antetul de negative acknowledge.

2.2.1.3 Tipuri de încărcătură suportate pentru porturile TCP și UDP

Figura 11-10

Figura 12-11

Figura 13-12

2.2.1.4 Manipularea Socket

1. Stările de conectare

1.1 Informații generale

Descrie statusul informațiilor și cerințele comportamentale ale entităților DoIP pe partea de vehicul cu respectarea statusului informațiilor de conectare.

1.2 Tabela de conexiune

Figura 14-13

1.3 Statusurile de conectare

Când un nou socket este în stare ”TCP established”, ar trebui adăugat într-o tabelă de gestionare a conexiunii cu starea ”initialized”. Un timer cu starea inițială inactivă ar trebui startat și asignat unei intrări de conexiune.După primirea unui mesaj de activare de tipul routare DoIP și completarea cu succes a handler-ului de protocol DoIP, socket-ul inițializat va reprezenta o conexiune logică și îi va fi updatată starea la ”Registered[Pending for Authentication]”. Adresa sursă a echipamentului de testare extern ar trebui asociată și ea la conexiune. Starea de inactivitate inițială a timer-ului ar trebui oprită și un timer general de inactivitate ar trebui startat și asociat cu această conexiune.După completarea cu succes a mecanismului de autentificare sau dacă autentificarea nu este necesară, conexiunea ar trebui setată la starea ” Registered[Pending for Confirmation]”.După completarea cu succes a mecanismului de confirmare sau dacă nu este necesară confirmarea,conexiunea ar trebui setată la starea ” Registered[Routing Active]”.Mesajele de DoIP care sosesc, exceptând mesajul de routing de activare sau mesajul necesar pentru autentificare sau confirmare, nu ar trebui procesate sau rutate înainte de a trece conexiunea în starea ”Registered[Routing Active]”.

2.Adresarea logică

O adresă logică fizică reprezintă unic o enitate de diagnoză pentru nivelul aplicație între orice enitate DoIP sau orice ECU al vehiculului conectat prin gateway de DoIP. Procesul de descoperire a vehiculului permite echipamentului de test extern să mapeze adresa fizică logică la adresă IP. Adresele logice funcționale sunt folosite pentru a adresa mesaje la grupuri de, sau la toate, entități de la nivelul aplicație de diagnoză cu un vehicul. Pentru adresare funcțională , echipamentul de test extern ar trebui să trimită multiple pachete de IP pentru a ajunge tuturor ECU-rilor adresate de adrese logice funcționale. Nu există nici un mecanism de adresare de multiple entități de DoIP printr-o singură adresă de IP. Pentru un Gateway de DoIP , recepția unei adrese funcționale a mesajului de diagnoză implică mai multe sau broadcast pe conectare in subrețetele de vehicul.

2.2.1.5 Servicile nivelului Transport

1.Informații generale

Toate servicile de nivel Transport au aceeași structură generală. Pentru a definii servicile, trei tipuri de primitive de serviciu sunt specificate :

-un serviciu request primitive ,folosit de nivelurile de comunicație înalte sau de aplicații pentru a trece informația de control și datele necesare pentru a fi transmise nivelului Rețea.

-un serviciu indication primitive,folosit de nivelul DoIP pentru a trimite statusul informației și pentru a primii date de la niveluri superioare de comunicație sau aplicație.

-un serviciu confirmation primitive,folosit de nivelul DoIP pentru a trimite statusul informației la nivelurile superioare sau aplicație.

Toate nivelurile DoIP de servicii au același format general :

serice_name.type (

parameter A,

parameter B,

[,parameter C,….]

)

Unde ”service_name” este numele serviciul,exemplu : _DoIP_Data; ”type” indică tipul primitivei de serviciu; iar parametrii A,B,C… sunt ”DoIP_SDU” ca și listă de valori trimise de primitiva de serviciu; ”[ ]” indică faptul ca această listă de parametrii poate fi și goală.

Primitivele de serviciu definesc cum un utilizator de serviciu cooperează cu un provider de serviciu:

-folosind primitiva de serviciu request , un utilizator de serviciu cere un serviciu de la provider

-folosind primitva de serviciu indication, un provider de serviciu informează un utilizator de serviciu despre evenimente interne ale nivelului rețea sau de cererea de serviciu a unei entități de utilizator.

-folosind primitiva de serviciu confirm , un provider de serviciu informează utilizatorul despre rezultatele a unei cereri precedente de la utilizator.

2.Specificațiile primitivei de serviciu ale entității DoIP

2.1 DoIP_Data.request

Primitva de serviciu cere transmisia unui <MessageData> cu <Length> în biți, de la server la client, identificat prin informația de adresă regăsită în DoIP_SA,DoIP_TA,DoIP_Tatype.

DoIP_Data.request(

DoIP_SA

DoIP_TA

DoIP_Tatype

<MessageData>

<Length>

)

2.2 DoIP_Data.confirm

Primitva de serviciu confirmă completarea unui DoIP_Data.request indentificat de informația adresei regăsită în DoIP_SA,DoIP_TA,DoIP_Tatype. Parametrul <DoIP_Result> specifică statusul cererii.

DoIP_Data. confirm (

DoIP_SA

DoIP_TA

DoIP_Tatype

< DoIP_Result >

)

2.3 DoIP_Data.indication

Primitva de serviciu indică <DoIP_Result> evenimente și livrează <MessageData> cu <Length> în biți , primiți de la enitate de protocol punct la punct cu informația de adresă în DoIP_SA,DoIP_TA,DoIP_Tatype.

DoIP_Data.request(DoIP_SA , DoIP_TA , DoIP_Tatype , <MessageData> , <Length> , < DoIP_Result >) [2]

3. Protocoale de comunicație

3.1 CAN

CAN este un protocol de comunicație uzual folosit în automotive, utilizat la scară largă și poate cel mai des întâlnit. Acesta se bazează pe folosirea a două fire de cupru pentru interconectarea ECU-urilor costurile de implementare fiind foarte mici [3.1]

Figura 3.1-1

Protocolul CAN este un protocol de transmisie cu detecție a coliziunilor de date și cu detectare dinamică de erori apărute în comunicație. Transmisia pe CAN se face în funcție de prioritatea de transmisie, ceea ce înseamnă că întotdeauna mesajul cu cea mai mare prioritate este transmis primul. Acest lucru se face prin comparația ID-urilor mesajelor ce trebuiesc transmise. De asemenea, prin tehnici denumite Bit Stuffing, se detectează erori de transmisie în timpul comunicației iar acele mesaje pot fi ignorate sau se poate cere retransmisia. Ca și tehnici de fiabilitate protocolul CAN asigură transmisia de date și în cazul defecțiunii unui din cele două fire pe care se face comunicația datorită transmiterii datelor în oglindă din punct de vedere al nivelelor de tensiune. [3.1]

Mesajele transmise pe protocolul CAN pot transmite un pachet util de maxim 8 bytes de date. ID-urile mesajelor pot fi de două tipuri: ID normale, sunt codificate pe 9 biți și ID extinse pe 29 de biți. Prioritizarea transmiterii mesajelor se face pe baza ID-urilor în următorul mod: fiecare ECU va pune câte un bit din ID pe canal în același timp. Printr-o linie de feedback ECU-ul va citi tensiunea la acel moment prezentă în linie. Dacă ECU-ul a pus valoarea 1 însă linia are valoarea 0, atunci înseamnă că există un ECU care dorește să transmită un mesaj mai prioritar și renunță la transmisie. Practic cel mai mic ID va câștiga arbitrarea.

3.2 LIN

LIN este un protocol de comunicație ce utilizează un singur fir pentru transmisia de date. Protocolul este unul de tip Master-Slave cu un singur master posibil în permanență. Costurile de implementare pentru acest protocol sunt poate cele mai reduse, iar el este folosit în general pentru ECU-uri ce controlează componente mecanice, unde latențe de comunicare sunt acceptate și viteze mari de transmisie nu sunt necesare. [3.2].

Figura 3.2-1

Comunicația pe acest tip de canal se face în funcție de Master și funcționează astfel: ECU Master va pune un ID pe bus în funcție de o tabelă de priorități. ECU-ul Slave care își detectează ID-ul va pune pe bus datele cerute. Astfel pentru acest protocol nu este necesar nici un mecanism de evitare a coliziunilor, deoarece Masterul va decide în permanență cine va transmite datele. Master-ul poate acționa și ca și Slave, punând ID-ul propriu pe canalul de comunicație iar apoi adăugând și datele. Această funcționare este utilă pentru a informa ECU-urile slave despre diferite evenimente sau pentru a transmite date către ele.[3.2]

3.3 ETHERNET

Prima întrebare pusă ar fii : de ce Ethernet ?

Răspunsul este simplu , oferă o lărgime de bandă mare : 100Mbps , comunicația full duplex pe un singur cablu torsadat. Este un protocol dovedit stabil , standardizat în 1980 de către IEEE. Costul este scăzut , transciever –ul fizic este ieftin , costuri mici de cablare.

Ușurința în crearea rețelelor este de asemenea un răspuns deoarece protocolul este proiectat să permită crearea rapidă și ușoară de rețele pentru noi dispozitive. Totodată este foarte ușor de adăugat noi dispozitive în rețele deja create. [3.3]

Transferul datelor dintr-o rețea în alta necesită putere scăzută de procesare din partea CPU.

Figura 3.3-1

Figura 3.3-1arată faptul că procesarea datelor de pe nivelurile superioare nu necesită să transporte datele între dispozitivele de rețea în ordine.

De ce acum?

1. Broadcom’s BroadR – Reach tehnologie disponibilă

2. În Decembrie 2012 BroadR-Reach s-a realizat portofoliul de calificare și producție pentru a se lasa în automotive.

3. OPEN (One Pair Ether-Net) Alliance Special Interest Group (SIG) creată de către Broadcom,BMW și Compania Hyundai Motors cu scopul de a aborda cerințele industriei pentru îmbunătățirea siguranței în vehicul, comfort și infotainment (comunicația multimedia în mașina) reducând în acelși timp complexitatea rețelei și costurile de cablare. [3.3]

Tehnologia BroadR-Reach

Permite multiple sisteme în vehicul, cu scopul de a accesa informația simultan pe un singur cablu torsadat neecranat la viteze de până la 100Mbps. Eliminând cablul ecranat, producătorii de automotive pot reduce costul conectivității până la 80%, iar greutatea cablării cu până la 30%.

Figura 3.3-2

Figura 3.3-2 arată o pereche răsucită de cabluri full duplex cu 100 Mbps.

Figura 3.3-3

Figura 3.3-3 arată comunicația între IP ECU folosind BroadR-Reach.

Broadcom's BroadR-Reach suportă task-urile nivelului fizic necesare protocoalelor nivelelor superioare pentru a transfera datele între dispozitivele din rețea.

Poate fi folosit ca ”vehicul” pentru :

Protocolul Car2X (C2C – mașină la mașină și C21-mașină către infrastructură).

Sistemele ADAS. [3.3]

Figura 3.3-4 [3.4]

Figura 3.3-4 arată un exemplu de aplicabilitate a tehnologiei Ethernet în mașină.

Vector deja include în familia lor de produse cutii de VN care oferă suport pentru tehnologia BroadR-Reach.

Figura 3.3-5 [3.5]

Figura 3.3-5 prezintă un exemplu de cutie VN5610 care deține 2 x BroadR-Reach.

4. Electronic Control Unit (ECU)

4.1 Prezentare generală

ECU sunt în esență computere de mici dimensiuni specializate spre îndeplinirea unor sarcini prestabilite, al căror rol nu poate fi schimbat fără modificarea implementării acestora.[4.1]

Figura 4.1-1

Aceste componente sunt destinate uzului în domeniul automotivelor pentru eficientizarea controlului componentelor din interiorul vehiculelor într-un mod cât mai complex și cât mai rapid, pentru eliminarea riscurilor de defecțiune și pentru reducerea costurilor de producție a vehiculelor, prin reducerea cantității de cabluri din vehicul. ECU-urile sunt interconectate în interiorul vehiculelor în diferite arhitecturi de funcționare (cel mai des utilizată fiind cea de tip stea, prin folosirea unui ECU destinat în principal controlului și administrării celorlalte ECU din vehicul în stilul routerelor folosite în rețelele de internet) folosindu-se mai multe canale de comunicație de diferite tipuri.[4.1]

ECU-urile au fost dezvoltate din necesitatea introducerii în vehicule a multor noi tehnologii și procese de automatizare (ex: cutie de viteze automată). Această necesitate a fost rezolvată cu ușurință prin creare ECU-urilor, care pot fi dezoltate să execute absolut orice operație necesară în vehicul.

ECU-urile sunt dezvoltate pe baza diferitelor tipuri de microcontrollere, unele specializate pe domeniul automotivelor, cu putere de procesare destul de ridicată (acolo unde este cazul, ex: display-uri touchscreen pentru pasageri pentru activități multimedia precum filme, muzică, etc) , microcontrollere rezistente la temperaturi și șocuri înalte, cu stabilitate de funcționare. Memoriile folosite în ECU-uri sunt de dimensiuni relativ mici datorate volumului nu foarte ridicat de date stocate și de asemenea, software-ului care este rulat de acestea, în general de dimensiuni mici (ex: 2 MB) și optimizat pentru rulare eficientă.[4.1]

Însă cel mai important din toate tehnologiile încorporate sunt tehnologiile de comunicație pe care le implementează acestea pentru a asigura comunicație între mai multe ECU-uri din mașină. Prezente pe piață sunt foarte multe variante de protocoale de comunicație existente spre a fi utilizate în domeniul automotivelor, acestea fiind CAN, LIN, FLEXRAY, MOST, Ethernet, dar de asemenea fiecare are și mediu specific de transmisie de date, de exemplu tehnologia CAN folosește 2 fire de cupru relativ subțiri care funcționează în mod diferențial pentru, practic informația transpusă în nivele de voltaje se transmite de 2 ori, o dată pe fiecare fir în paralel, pe un fir transmițându-se un anumit nivel de tensiune care indică o valoare, iar pe cel de-al doilea fir se transmite un alt nivel de tensiune, care indică aceeași valoare, iar ca și alt exemplu, protocolul MOST se implementează folosind fibră optică.[4.1]

ECU-urile sunt componente specializate spre a suporta diferite funcționalități bine definite. Pentru dezvoltarea acestora se alege din start functionalitatiile din vehicul pentru care sunt dezvoltate, tehnologiile de implementare, componentele hardware, tipul de comunicație și de asemenea componentele mecanice controlate dacă este cazul (ex: ECU dedicat pentru controlul scaunului poate avea tehnologie de comunicație pe CAN iar ca funcționalități pot fi încălzire în scaun, reglaj automat și manual pentru pozițiile componentelor scaunului, beltfeeder, o componentă de predare a centurii de siguranță pasagerului prin aducerea acesteia într-o poziție ușor accesibilă pasagerului). În general în fază de design al ECU-ului se definesc toate functionalitatiile pe care le poate implementa acesta, iar dezvoltarea se face în sensul implementării tuturor functionalitatiilor. Software-ul ce va fi instalat pe ECU este întotdeauna complet implementând toate functionalitatiile posibile pentru aria de utilizare specifică, iar selecția opțiunilor active pe variantă de vehicul asamblat se face prin parametrizarea software-ului.

Deși pot exista multe opțiuni de implementat pe un singur ECU (ex: în cazul controlului unei uși de mașină) acestea în general seamănă din punct de vedere funcțional și sunt grupate astfel încât dezvoltarea să se facă cu ușurință iar consumul de resurse să fie minim.

Un aspect foarte important pentru funcționarea corectă a acestor componente este cel de fiabilitate în condiții extreme. ECU-urile trebuie să fie capabile să funcționeze în parametrii corecți în condiții de temperaturi foarte ridicate (peste 70 grade Celsius în cazul ECU-urilor destinate ușilor) datorită poziționării lor. De asemenea trebuie să se asigure rezistente la supratensiune de alimentare, rezistentă la scurt circuit, trebuie să se asigure rezistente la șocuri mecanice puternice și trebuie să asigure mecanisme de detectare a tuturor problemelor posibile să apară în funcționarea acestora din timpul utilizării vehiculelor (ex: întreruperea alimentării, întreruperea canalului de comunicație, lipsa unui ECU din vehicul, etc).

Mecanismele de detecție ale diferitelor probleme sunt implementate ținând cont de configurația vehiculului din punct de vedere al arhitecturii de comunicație, al configurației tuturor ECU-urilor din mașină și de asemenea din punct de vedere al priorității și relevanței. În general aceste mecanisme sunt implementate prin funcționalități denumite Error Memory, o funcționalitate specializată pe detecția și tratarea de erori din vehicul.[4.1]

4.2 Prezentare diferite funcționalități în corelație cu ECU

În arhitecturile existente în vehicule există foarte multe tipuri de ECU-uri pentru executarea functionalitatiilor necesare sau existente. Pentru mai bună înțelegere a arhitecturii se prezintă următoarele:

– Gateway ECU

– Door ECU

– Seat ECU

– Instrument Cluster ECU

Gateway ECU

Gateway ECU este un tip deosebit de ECU implementat în marea majoritate a autovehiculelor prezente în circulație. Aceste ECU-uri rareori sunt conștientizate ca și existente și nu sunt în general vizibile din punct de vedere funcțional, însă rolul pe care îl îndeplinesc este unul critic din punct de vedere al funcționării autovehiculului în parametrii normali.

Figura 4.2-1

Acest tip de ECU poate fi comparat cu routerele utilizate în rețelele de internet, deoarece scopul lui este interconectarea tuturor celorlalte ECU-uri din mașină și administrarea lor.

Acest ECU are ca scop principal asigurarea comunicației în orice direcție între oricare alte ECU-uri din mașină. El trebuie să asigure că orice date ajunse la el sunt retransmise către destinație fără producerea unei erori. De asemenea acest ECU acționează ca un gardian în autovehicul, el având monitorizarea tutror celorlalte ECU-uri din mașină și semnalarea de probleme în cazul existenței lor. Prin mecanisme de tip Error Memory acesta poate seta semnalarea de probleme ce pot apărea, fie ele de tip de comunicație, fie de funcționare proastă sau de lipsă în totalitate a altui ECU.

Un alt scop al acestui ECU este diagnoza în vehicul. Diagnoza reprezintă un tip special de comunicație ce are ca scop parametrizarea sau citirea de parametrii de funcționare din ECU-uri. În general diagnoza este folosită în primul rând la fabricarea vehiculului, când pe linia de producție se setează toți parametrii de funcționare ai acestuia, dar se folosește în mod deosebit și în service, când cu ajutorul său se identifică probleme la vehicul, sau se modifică diferiți parametrii de funcționare. Diagnoza poate fi și de tip internă, în sensul că gateway-ul poate executa sesiuni de diagnoză între el și alt ECU pentru diferite verificări de parametri sau pentru rescrierea acestora.

Door ECU

Aceste ECU-uri sunt specializate pe taskuri destinate ușilor. Acestea, în funcție de cerințele producătorilor, pot fi implementate pe diferite canale de comunicație, de viteză mai mare sau mai mică, în funcție de tipul funcționalităților controlate.

Aceste ECU-uri controlează funcțiile cunoscute tuturor în cadrul ușilor cu sunt modificarea pozitei oglinzii, închidere centralizată, ridicarea și coborârea geamului, sisteme de protecție pentru împiedicarea prinderii de obiecte la închiderea geamului (Antipinch) și alte funcționalități specifice. De obicei funcțiile îndeplinite de aceste ECU-uri nu necesită foarte multă comunicație în mașină și prin urmare, sunt implementate folosind canale de comunicație pe tehnologii mai puțin costisitoare (ex: LIN).

Pentru siguranța pasagerilor însă aceste ECU-uri pot controla funcții critice de blocare/deblocare a ușilor în diferite situații, funcții de airbag, funcții care pot necesita prioritate mare de comunicație și atunci se rezumă la utilizarea altor tehnologii de comunicație.

Figura 4.2-2

Seat ECU

ECU-urile pentru scaune controlează funcții de destinate confortului în general. Printre acestea se numără încălzire în scaun, poziționare automată sau manuală a șezutului, a spătarului, încălzire pentru ceafă, beltfeeder, modificarea formei scaunului conform cu caracteristicile fizice ale pasagerului.

Tehnologiile de comunicație implementate de obicei pentru aceste ECU-uri sunt tehnologii de viteză scăzută, deoarece sunt puține funcții critice pentru siguranță pasagerului pe care le controlează.

Însă arhitectura hardware ale acestora poate fi puțin diferită datorită controlului a multor componente mecanice. Asta înseamnă consumuri mai mari pentru funcționarea ECU-ului și de asemenea probleme de stabilitate.

Instrument Cluster ECU

Majoritatea componentelor prezente pe bord pentru afișarea de informații pentru șofer sunt controlate de un singur ECU. Acest ECU de obicei are denumirea de Instrument Cluster iar scopurile sale sunt de obicei de natură informativă.

Există însă și alte funcționalități posibile ale acestuia, spre exemplu poate funcționa ca și back-up pentru configurația vehiculului, ca în caz de defecțiuni să se poată rescrie aceeași parametrii la schimbarea unui alt ECU din mașină.

Acest ECU, după caz, poate implementa și soluții de tip multimedia, fiind necesare în aceste situații prioritizari de funcționalități.

Figura 4.2-3

5. Aplicații pentru dezvoltare

5.1 CANoe

CANoe este un tool versatil destinat dezvoltării, testării și analizei unei rețele întregi de ECU-uri și de asemenea a unui ECU individual. Acesta suportă arhitecți de rețea, dezvoltare și igineri de testare ai OEM și ai producătorilor pe parcursul întregului proces de dezvoltare, de la planificare până la pornirea întregului sistem distribuit sau a ECU-ului individual.[5.1]

La începuturile procesului de dezvoltare, CANoe este utilizat la crearea modelelor de simulare care simulează comportamentul ECU-urilor. Pe parcursul dezvoltări ECU-ului, aceste modele servesc ca și bază pentru analiză, testare și integrarea sistemelor de comunicare și a ECU-urilor. Astfel se face posibilă detectarea problemelor foarte devreme și corectarea lor. Modalități de evaluare grafică și pe bază de analiză sunt oferite pentru evaluarea rezultatelor.[5.1]

CANoe oferă un set de utilitare pentru testare pentru execuția ușoară de teste automate. Este folosit pentru modelarea și execuția secvențială de secvențe de teste și pentru generarea automată de rapoarte de testare. De asemenea mai oferă un set de utilitare pentru diagnoză pentru simularea și testarea comunicației de diagnoză cu ECU-ul.[5.1]

Funcțiile de bază oferite de CANoe sunt:

– Utilizarea de baze de date ce descriu rețele specifice(ex. DBC, FIBEX, LDF, NFC, AUTOSAR System Description, etc.)

– Simularea unor sisteme complete și a bus-urilor rămase

– Analiza comunicației pe bus

– Testarea întregii rețele și/sau a ECU-urilor individuale

– Comunicarea de diagnoză folosind protocoalele KWP2000 și UDS și utilizarea ca și sistem complet funcțional de tester de diagnoză

– Programare folosind limbajul de programare CAPL pentru suportul simulării, analizei si testării

– Crearea de interfețe grafice costumizate pentru controlul simulării si a testelor sau pentru a afișa date de analiză

– Integrarea de hardware I/O adițional și/sau hardware de testare special

– Interfată intuitivă și costumizabilă cu meniuri ușor accesibile

– Suport pentru hardware Vector nou pentru bus [5.1]

Bază de analiză pentru CANoe este fluxul de date de la sursă către display sau sistemul de monitorizare. Datele pot fi de asemenea procesate. CANoe oferă utilizatorului ferestre și blocuri specializate pentru diferite interpretări ale datelor, grafice sau textuale.

În dezvoltarea unor sisteme de comunicație distribuite cu CANoe, restul simulării de bus este creată automat bazat pe informațiile existențe în bazele de date, incluzând interfețele grafice pentru utilizator pentru control și display. Comportamentul comunicației al acestor sisteme poate fi complet simulat și analizat. Pe parcursul procesului de dezvoltare, noduri individuale pot fi înlocuite cu ECU-uri reale în simulare. Canalele de comunicație rămase și mediul simulat oferă dezvoltatorului un mediu de dezvoltare și de test pentru tot sistemul cât și pentru fiecare ECU individual și module.[5.1]

Unul din principalele scopuri de utilizare ale CANoe este testarea ECU-urilor și a rețelelor. Asemenea teste sunt utilizate pentru a verifica fiecare pas individual de dezvoltare, prototipuri de testare sau pentru a executa teste de regresie și de conformitate. Pentru a asigura că task-urile de testare pot fi implementate simplu și flexibil, setul de funcții de testare oferit este compus din următoarele componente:

– Fluxuri de test secvențiale sunt implementate în test module XML, CAPL sau .NET, care sunt subclasificate în grupuri de test și cazuri de test.

Modulele individuale pot fi executate oricând în timpul unei măsurători. În modulele XML, testele sunt asamblate din tipare predefinite de teste, și sunt ușor de parametrizat prin vectori de intrare și ieșire. Modulele .NET pot fi programate în C# sau în VB.NET în funcție de necesități.

– În paralel cu execuția de țeste, alte stări de sistem pot fi verificate cum sunt conformanta la ciclii de timpi ai mesajelor individuale. Aceste constrângeri sunt adăugate automat la evaluarea testelor.

– Pentru fiecare modul de teste se crează un raport de testare. În acest raport apar numele cazurilor de testare executate și rezultatele individuale ale fiecăruia, informații definite de utilizator sau capturi ale diferitelor ferestre de analiză. De asemenea rezultatele mai sunt trecute într-un raport de tip XML ce poate fi procesat mai departe.

– CANoe poate administra mai multe medii de testare separate. Fiecare mediu de testare poate conține module de testare dar și alte blocuri funcționale pentru execuția testelor și sunt salvate independent de configurația sistemului. Astfel se pot folosi în mai multe proiecte cu ușurință.

– Controlul direct al dispozitivelor de I/O în CANoe face posibilă utilizarea de interfente analogice și digitale cu ECU-urile în plus față de canalele de comunicație de tip bus. Impremuna cu componente I/O standard, sistemul Vector VT System reprezintă un sistem hardware modular pentru testarea ECU-urilor în domeniul automotivelor. [5.1]

CANoe este folosit în dezvoltarea sistemului de diagnoză al ECU-urilor. În această zonă, CANoe suportă atât implementarea cât și testarea funcționalităților de diagnoză oferind acces la interfețele de diagnoză ale ECU-urilor. Conceptele și funcțiile disponibile sunt următoarele:

– Suport pentru cele mai importante descrieri de format pentru diagnoză pentru KWP2000 si UDS:

o ODX 2.0.1/2.2.0

o MDX 3.0

o CANdelaStudio

– Posibilitatea de modificare de parametri cheie pentru comunicarea de diagnoză al descrierii de diagnoză în dialogul de configurare Diagnostic/ISO-TP

– Editor de diagnoză de bază pentru definirea rapidă de servicii simple de diagnoză, dacă nu este disponibilă nici o descriere de diagnoză

– Tester interactiv de diagnoză cu consolă de diagnoză, interfață pentru memoria de erori și sesiunea de diagnoză cu DLL-uri de securitate configurabile

– Suport pentru mai multe scheme de adresare și tipuri de adresare

– Analiza comunicației de diagnoză la nivel de servicii și de parametri in ferestrele de Trace, Data si Graphic.

– Afișarea erorilor de protocol

– Simulare de funcționalități de diagnoză ale ECU-urilor si multe alte opțiuni [5.1]

Limbajul de programare CAPL (Communication Access Programming Language) extinde scopul funcțional al CANoe enorm. Caracteristicile speciale ale acestuia sunt:

– Ușor de invățat deoarece este bazat pe limbajul de programare C .

– Complet controlat de evenimente in operație.

– Suporta acces simbolic la toate informatiile din bazele de date ca mesajele și semnalele lor.

– Limbajul a fost extins cu funcții speciale pentru implementare rapidă pentru soluții la probleme în diferite cazuri de utilizare

Extensie flexibilă folosind librari externe [5.1]

Limbajul de programare CAPL este un limbaj event-controlled. În comparație cu C, handlere de evenimente special predefinite sunt disponibile în CAPL, care sunt executate în permanență când un eveniment specific are loc sau, dacă este controlat de timp, atunci lansat de hardware sau intern în CANoe.[5.1]

III. Implementarea aplicației

1.Scopul aplicației

Datorită dezvoltării acestui domeniu de automotive , a tehnologiei tot mai avansate dar și a necesității de siguranță și comfort sporit la volan, aplicația are scopul de a ilustra o comunicație tipică întâlnită în mașină , și anume diagnoza identitificată la noi prin protocolul DoIP.

Diagnoza este necesară datorită dotării mașinilor cu ECU (electronic control unit) iar termenul de diagnoză definește comunicația cu aceste unități. ECU-urile au rolul de a monitoriza prin intermediul senzorilor , diverși parametrii care automat influențează sistemul pe care îl gestionează.[1]

În principal , atunci când ceva se strică într-un ECU se va genera un cod de eroare care ulterior se va citii prin diagnoză indicând o direcție către reparare.[1]

Pentru a face posibilă aceasta, ca prim pas în comunicare , am folosit protocolul de DHCP ( Dynamic Host Configuration Protocol) definit de standardul RFC 1541 și care permite server-ului sa aloce adresă IP și informații de configurare dinamic către clienți. În general , DHCP oferă default adresa de IP, masca subrețelei și gateway.

Prin urmare, aplicația are ca scop trimiterea unei cereri pe magistrală de Ethernet simbolizată de id-ul 0x0001 care reprezintă Vehicle identification request message și ne așteptăm sa avem ca și răspuns 0x0004 care reprezintă Vehicle announcement message/vehicle identification response message.

2.Implementarea aplicației

Aplicația a fost dezvoltată în tool specific domeniului de testare în cadrul automotivelor numit CANoe, unde am creat o configurație care comunică pe magistrala de Ethernet. Am ales Ethernet deoarece tot mai multe tehnologii se dezvoltă pe acest concept datorită cablului coaxial partajat , viteză de comunicație ridicată iar pentru acoperirea distanțelor mari fibra optică a luat amploare.

În cadrul configurației am adăugat două noduri numite DOIP și DHCP prin intermediul cărora realizăm comunicația.

Pentru a face posibilă comunicația cu mașina noastră , care este reprezentat de ECU am implementat protocolul DHCP.

Protocolul DHCP ne ajută pe noi să atribuim adrese IP și alte informații necesare , toate în mod dinamic. Implementarea protocolului DHCP se face în două părți. O parte care vine de la client și o parte pe care noi ca server o implementăm.

Prin urmare , vom avea două funcții Offer si Ack. Funcția Offer alocă ECU-ului nostru adresă de IP alături de opțiuni care se identifică în cadru după Magic Cookie = 0x63825363.

Pentru mesajul de DHCPOFFER ‚pentru a știi clientul ce tip de mesaj trimitem , la campul OP vom pune 0x02 care îl identitifică unic, urmat de opțiuni precum masca subclasei, gateway, DNS și timpul pentru care alocăm adresa. Ca și funcționalitate, precum spune și numele funcției , îi facem o ofertă clientului ca răspuns venit de la el prin DHCPDISCOVER.

Dacă este de acord cu oferta noastră , primim DHCPREQUEST , în care ne cere informațiile. DHCPACK face același lucru ca și DHCPOFFER doar că dacă cea de ofertă nu era acceptată , cea ACK nu mai avea loc cu aceeași parametrii, ci trebuia refăcută cererea.

Acest schimb de mesaje dintre client și server este regăsit și pe Trace.

Protocolul DOIP folosește adresele de IP alocate anterior în nodul DHCP, deoarece la fel cum sugereză și numele protocolului, diagnoza se va face asupra adresei de IP.

În cadrul acestui nod , vom crea cererea pentru ECU , cerere care conține tipul protocolului de DOIP, în cazul nostru 0x02FD , tipul de încărcătură și datele propriu zise pe care vrem să le transmitem. Cererea este trimisă către ECU cu ajutorul funcției predefinite de CANoe ” udpSendTo” cu parametrii un socket creat de noi prin funcția “UdpOpen” , cu IP-ul clientului și al nostru dar și cu datele propuse. Pentru a primii datele , avem ca și funcție de callback , OnUdpReceiveFrom care reacționează la orice eveniment de primire de date.

Pentru a face aplicația mai usoară , am creat o interfață cu ajutorul unui panel , din care avem posibilitatea de a modifica adresa IP pe care server-ul DHCP o negociază cu ECU-ul dar avem și paramaterii descriși mai sus , unde se pot vizualiza valorile necesare cererii de diagnoză.

La apăsarea butonului Send , cu parametrii doriți , primim tot pe panel în câmpul DoIP Payload Type, răspunsul ECU-ului , și anume 0004.

3.Funcționalități funcții

Are rolul de a convertii din string în șir de biți ceea ce preluăm de pe panel pentru a facilita folosirea acestuia.

Atunci când schimbăm valoarea în panel a adresei IP , această funcție preia noua valoare , care va înlocuii vechea valoare pentru a putea fii folosită în cod.

Se apelează de fiecare dată când se pornește aplicația, unde facem preluarea tuturor datelor pe care le primim pe magistrala de Ethernet și preluăm valoarea definită default a adresei de IP.

Preluăm timpul la care ajung informațiile , deoarece conexiunea va fii valabilă doar o anumită perioadă de timp. Aici facem o distincție de valorile care ajung pe bus, fiind un frame întreg de Ethernet , datele despre DHCP de vor găsii abia după byte-ul 240. Dacă a venit primul bit cu valoare 1, mesajul este de tipul DISCOVER și se va apela funcția fDHCP_Offer împreună cu tot conținutul primit. Dacă pimul bit venit este însă 3 , vom apela funcția fDHCP_Ack împreună cu datele primite.

Instanțiem parametrii de nivelul 2 și 3 , unde parametrii de nivel 2 sunt adresele MAC iar parametrii de nivel 3 sunt IP-uri. Tot aici umplem toate câmpurile cadrului Offer , începând cu OP și terminând cu opțiunea 255 care arată sfârșitul cadrului.

Face același lucru ca și Offer . alocă IP și adrese MAC și adaugă optiuni.

Preia opțiunea pe care noi o dăm , alături de index pe care le adăugăm cadrului. Această funcție a fost o soluție de optimizare a codului.

La fel se apelează de fiecare dată când se rulează aplicația, preluăm valoarea IP-ului în caz de modificări , apelăm funcția DoIPCreateRequest și funcția GetValueOfSysvar.

Preia valorile tuturor câmpurilor din panel, valori date default dar având posibilitatea modificării acestora.

Dacă s-a apăsat butonul de Send de pe panel , se vor lua valorile din câmpurile de pe panel , modificate sau nu și se va crea cererea, trimițând tot o dată datele către ECU prin intermediul funcției specifica CANoe , numită udpSendTo. Pentru a putea trimite datele, s-a creat un port prin care să comunice aplicația cu ECU-ul.

Este cea mai importantă funcție din program. Aici folosim datele preluate de pe panel, pe care le adaugăm într-un șir de bytes , evident după ce valorile au fost convertite din string in byte. Aici se deschide portul prin intermediul funcției de CANoe UdpOpen , și tot aici apelăm și funcția specifică la fel CANoe , UdpReceiveFrom prin care sugerăm ca suntem gata să primim datele înapoi de la ECU.

Va compara fiecare caracter de pe panel , dacă are cifre sau litere în range-ul acceptat returnând diferite valori sau -1 dacă ce s-a introdus nu este corect.

4.Configurația CANoe

Aplicația CANoe este specifică domeniului de testare , având un rol important în cadrul companiei. Aplicația fiind instalată , ca prim pas , alegem din File -> New Configuration.

Adaugăm un nod numit ETHERNET , care va reprezenta magitrala de comunicație. Pentru a realiza interacțiunea cu magistrala , asignăm nodurilor DoIP și DHCP dll-ul de Ethernet.

La pornirea configurației , sursa va alimenta ECU-ul care va trimite datele pe magistrala de Ethernet și implicit în amandouă nodurile legate la magistrală.

Aplicația va permite nodurilor DHCP și DoIP să fie editate , adaugat cod , compilate, generând automat pentru ele , fișiere cu extensia .can

5.Funcționarea aplicației

La lansarea aplicației , se va afișa Panel1 , de unde avem posibilitatea modificării adresei IP , o adresă de IP fiind deja alocată în cod . Câmpurile specifice DoIP sunt deja predefinite cu valori , fiecare având o semnificație . La apăsarea butonului Send din Panel , se vor trimite datele prin intermediul magistralei către ECU.

Pentru a face posibilă această trimitere și primire de parametrii , introducem noțiunea de variabile de sisteme =sysvars , care pot stoca valori de tipul șir de caractere, numere întregi , sau valori float. Valabilitate acestora este din momentul definirii și până la sfârșitul contextului de folosire.

Pentru fiecare câmp din panel , avem cate un sysvar definit specific , menit să preia datele sau să le afișeze pe panel.

6.Rezultate obținute

Din trace putem revedea comunicația cu ECU-ul unde RX reprezintă mesajele de cerere iar TX mesajele de răspuns.

Pentru o mai bună înțelegere , am afișat și răspunsul primit pe magistrală de la ECU, date pe care le preiau într-un buffer.

Din acest buffer, nouă ne sunt necesare ca date , doar primii 6 bytes , care reprezintă răspunsul din Panel.

7.Dezvoltări ulterioare

Dezvoltările ulterioare își propun extinderea setului de opțiuni DoIP , pentru că momentan , aplicația reflectă doar o cererea tipică de interogare unde mesajul trimis să fie și mesajul primit. În același timp , extinderea aplicației presupune și trecea de la UDP la protocolul TCP.

Folosirea protocolului UDP rezultă din funcțiile folosite , precum UdpReceiveFrom , udpSendTo, UdpOpen. Acesta permite transportul sau transferul de mesaje. Nu este un protocol bazat pe conexiune unde viteza de răspuns este mare, și este util pentru servere care răspund cerințelor scurte venite de la mai multi clienți. TCP în schimb este bazat pe conexiune unde mesajele merg dintr-o parte în alta și oferă garanția că datele ajung intacte la destinație fiind și mai lent.

Figura 1

Figura 1 reflectă opțiunile DoIP care se pot folosii doar în cazul protocolului de TCP.

Figura 2

În comparație cu Figura 1 , Figura 2 reflectă doar ce am implementat pe baza protocolului de UDP , unde trimitem id-ul 0x0001 ca și cerere iar răspunsul este id-ul 0x0004.

IV. Concluzii

Diagnoza este o partea esențială în mersul normal și în siguranță a mașinii , tocmai de aceea s-au și dezvoltat deferite aplicații de identificare a problemelor în mașină. Aceasta reprezintă comunicația dintre client (tester) și server (gateway) prin intermediul unor protocoale de diagnoză și protocoale de transport. Fără aceste aplicații munca unui electronist mecanic sau chiar a unui inginer ar fii mult mai mult îngreunată. În cazul apariției unei erori , se va returna un DTC –data trouble code , aratând problema apărută.

Studiul și aplicația prezentată în această lucrare demonstrează eficiența ce poate fi obținută prin simpla implementare a serviciului de diagnoză. În domeniul testării ECU-urilor investițiile făcute sunt mari dar si justificate. Activitatea de zi cu zi în acest domeniu implică teste de diagnoză la fiecare apariție de noi tipuri de soft.

Pe lângă această citire a codurilor de eroare , diagnoza mai permite și citirea diferiților parametrii inscriși pe ECU. Putem citii tipul de soft, temperatura ECU-ului, putem influența diferite comportamente ale ECU-ului prin diferite comenzi.

V. Bibliografie

[1] http://www.iovi.ro/blog/ce-inseamna-diagnoza-computerizata-avantaje-si-limite/ [accesat 04.05.2015]

[1.1] http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol [accesat 07.04.2015].

[1] ISO 13400-2:2012(E),Road vehicles — Diagnostic communication over Internet Protocol(DoIP) —Part 2:Transport protocol and network layer services Copyright and property of Continental Automotive Systems.

[3.1] CiA, „CAN history,” 2001-2014 http://www.can-cia.de/index.php?id=161 [accesat în 30.03.2015]

[3.2] LIN Config Language Spec Revision 2.2A December 31, 2010; Disponibil pe http://www.cs-group.de/fileadmin/media/Documents/LIN_Specification_Package_2.2A.pdf [accesat în 30.03.2015]

[3.3] Ethernet_Automotive.ppt Copyright and property of Continental Automotive Systems.

[3.4]https://www.google.ro/search?q=ethernet+on+car&biw=1088&bih=453&source=lnms&tbm=isch&sa=X&ei=5FEVVfutKIbXUcHegYAJ&ved=0CAYQ_AUoAQ#imgdii=_&imgrc=mPzdG_VtnsovQM%253A%3BOiyaIwEOR5XnlM%3Bhttp%253A%252F%252Felectronicdesign.com%252Fcontent%252Fcontent%252F64326%252F64326_fig2.jpg%3Bhttp%253A%252F%252Felectronicdesign.com%252Fautomotive%252Fautomotive-ethernet-arrives%3B1200%3B868 [accesat în 27.03.2015]

[3.5]https://www.google.ro/search?q=vn5610&biw=1088&bih=409&source=lnms&tbm=isch&sa=X&ei=b1QVVa2lH4isPOXigcgI&sqi=2&ved=0CAcQ_AUoAg#imgdii=_&imgrc=Azc2ZR0YRxxuVM%253A%3B5J7DuhcLc4RCqM%3Bhttp%253A%252F%252Fvector.com%252Fportal%252Fmedien%252Fpni%252Fvn56xx%252Fvn5610_small.jpg%3Bhttp%253A%252F%252Fvector.com%252Fvi_vn5610_en.html%3B253%3B172 [accesat în 27.03.2015]

[4.1] Wikipedia, „Software Testing,” http://en.wikipedia.org/wiki/Software_testing [accesat 07.04.2015].

[5.1] Vector Informatik Gmbh, „CANoe ECU Development & Test,” Vector Informatik Gmbh http://vector.com/portal/medien/cmc/info/CANoe_ProductInformation_EN.pdf http://en.wikipedia.org/wiki/Software_testing [accesat 07.04.2015]

VI. Anexă

1. Cod sursă nod DHCP

includes

{

}

variables

{

char Ip_Sysvar[100];

char Mac_sysvar[100];

byte buffer_ip[20];

byte gDHCP_SERVER_ADDRESS[4] = {192, 168, 0, 1};

byte gDHCP_CLIENT_ADDRESS[4] = {192, 168, 0, 10}

byte gSUBNET_MASK[4] = {255, 255, 255, 0};

byte gDHCP_LEASE_TIME[4] = {0x00, 0x00, 0x0E, 0x10};

byte gMAGICCOOKIE[4] = {0x63, 0x82, 0x53, 0x63};

byte raw_eth_frame[1500];

byte DHCPDiscover=1;

byte DHCPReq=3;

byte gBOOTP_CONTENT[548];

int gDHCP_OPTIONS_INDEX;

struct DCHP_Option

{

byte option_Code[1];

byte option_Length [1];

byte option_Content[256];

};

struct DHCPOption_Cluster

{

struct DCHP_Option OptionList[16];

byte NoOfOptions;

};

struct DHCPFRAME

{

float TimeStamp;

byte DestMac[6];

byte SourceMac[6];

byte SourcePort[2];

byte DestPort[2];

byte IpSender[4];

byte IpReceiver[4];

byte MagicCookie[4];

byte TransactionID[4];

byte MessageType[1];

byte DHCP_Options[512];

int DHCP_Options_Index;

};

struct DHCPFRAME gDHCP_OFFER_FRAME, gDHCP_ACK_FRAME, gCurrentDHCPFrame;

byte emptyMacAddress[6]={0x00,0x00,0x00,0x00,0x00,0x00};

}

int fDataFromByteStringToByteConvert(char inputCharacter[],int returnByteLength ,byte returnByte[])

{

char string[100],buff[100],dotCounter;

int charLength,i,j,ind,numberOfConsecutiveCharacters;

int groupOfCharacters;

int offset;

i=0;

j=0;

offset=0;

dotCounter=0;

numberOfConsecutiveCharacters=0;

charLength=strlen(inputCharacter);

snprintf(string,elcount(string),"");

groupOfCharacters=3;

while(i<charLength)

{

if((inputCharacter[i]=='.')|| inputCharacter[i]=='\0' )

{

if((numberOfConsecutiveCharacters>=1)&&(numberOfConsecutiveCharacters<=groupOfCharacters))

{

memcpy_off(string,0,inputCharacter,offset,numberOfConsecutiveCharacters);

returnByte[dotCounter++]=atol(string);

offset=offset+numberOfConsecutiveCharacters+1;

numberOfConsecutiveCharacters=0;

}

}

else

{

if((inputCharacter[i]>=48)&&(inputCharacter[i]<=57))

numberOfConsecutiveCharacters++;

else

return -1;

}

i++;

}

}

on preStart

{

EthReceiveRawPacket( 0x7, emptyMacAddress, emptyMacAddress, 0x0000, "onDHCPFrame");

}

void fDHCPProcess(byte CurrentDHCPRawData[])

{

gCurrentDHCPFrame.TimeStamp=EthGetThisTimeNS();

memcpy_off(gCurrentDHCPFrame.MessageType,0,CurrentDHCPRawData,284,1);

if(gCurrentDHCPFrame.MessageType[0]==DHCPDiscover)

{

gDHCP_OPTIONS_INDEX = 240;

fDHCP_Offer(CurrentDHCPRawData);

}

if(gCurrentDHCPFrame.MessageType[0]==DHCPReq)

{

gDHCP_OPTIONS_INDEX = 240;

fDHCP_Ack(CurrentDHCPRawData);

}

}

on key 'A'

{

fDHCP_Offer (gBOOTP_CONTENT);

fDHCP_Ack (gBOOTP_CONTENT);

}

void fDHCP_Ack(byte InputDhcpFrame[])

{

LONG packetHandle;

CHAR error[100];

byte dhcpoffer[15000];

int i;

byte data [256];

byte destination_MAC[6], source_MAC[6]; //layer 2

byte destination_ip[4], source_ip[4]; //layer 3

byte transaction_ID[4];

memcpy_off(destination_MAC,0,InputDhcpFrame,0,6);

memcpy_off(source_MAC,0,InputDhcpFrame,6,6);

memcpy_off(transaction_ID, 0,InputDhcpFrame,46,4);

packetHandle = EthInitPacket("udp");

if(EthGetLastError()==0)

{

// set protocol fields

//layer 2 -> pot sa folosesc membri din structura primita ca parametru

EthSetTokenData(packetHandle,"eth","source",6, source_MAC);

EthSetTokenData(packetHandle,"eth","destination",6, destination_MAC);

//layer 3 -> instantiaza source and destination MAC

EthSetTokenInt(packetHandle,"ipv4","source",0xC0A80001 );// 192.168.0.1

EthSetTokenInt( packetHandle, "ipv4", "destination", 0xFFFFFFFF ); // 255.255.255.255

EthSetTokenInt( packetHandle, "udp", "source", 0x43 );

EthSetTokenInt( packetHandle, "udp", "destination", 0x44 );

// set UDP payload

//XID = transaction ID

EthResizeToken( packetHandle, "udp", "data", 548*8);

gBOOTP_CONTENT[0]=0x02; //campul op din dhcpoffer

gBOOTP_CONTENT[1]=0x01;//campul htype din dhcpoffer

gBOOTP_CONTENT[2]=0x06;//campul hlen din dhcpoffer

memcpy_off(gBOOTP_CONTENT, 4, transaction_ID, 0, 4);//campul xid din dhcpoffer

memcpy_off(gBOOTP_CONTENT, 16, gDHCP_CLIENT_ADDRESS, 0, 4);//campul ciaddr din dhcpoffer

memcpy_off(gBOOTP_CONTENT, 28, source_MAC, 0, 6);//campul chaddr din dhcpoffer

memcpy_off(gBOOTP_CONTENT,236, gMAGICCOOKIE, 0, 4);//campul magic cookie din dhcpoffer

//––––optiunea 53 – dhcp message type–––

//option code

data[0]=0x05;

OptionAdd(53, 1, data);

//––––––optiunea 1 – subnet mask–––

OptionAdd(1, 4, gSUBNET_MASK);

//––––––optiunea 3 – router–––––

OptionAdd(3, 4, gDHCP_SERVER_ADDRESS);

//––––––optiunea 6 – DNS–––––

OptionAdd(6, 4, gDHCP_SERVER_ADDRESS);

//––––optiunea 54 pentru dhcp server–––

OptionAdd(54, 4, gDHCP_SERVER_ADDRESS);

//––––optiunea 51 lease time–––

OptionAdd(51, 4, gDHCP_LEASE_TIME);

//––––optiunea 255-END–––-

data[13]=255;

OptionAdd(255,0,data);

//setting UDP payload

EthSetTokenData(packetHandle,"udp","data",548, gBOOTP_CONTENT);

// Complete and send packet

EthCompletePacket( packetHandle );

EthOutputPacket( packetHandle );

// release packet

EthReleasePacket( packetHandle );

}

else

{

EthGetLastErrorText( elCount(error), error );

write("Error: %s", error );

}

}

void OptionAdd(byte InputOptionCode, byte InputOptionLength , byte InputOptionContent[])

{

byte current_option[258];

int complete_option_length;

complete_option_length = 1 + 1 + InputOptionLength;

gBOOTP_CONTENT[gDHCP_OPTIONS_INDEX] = InputOptionCode;

gBOOTP_CONTENT[gDHCP_OPTIONS_INDEX + 1] = InputOptionLength;

memcpy_off(gBOOTP_CONTENT, gDHCP_OPTIONS_INDEX + 2, InputOptionContent, 0, InputOptionLength);

gDHCP_OPTIONS_INDEX = gDHCP_OPTIONS_INDEX + complete_option_length;

}

void onDHCPFrame(long channel, long dir, long packetLength )

{

EthGetThisData(0,1500, raw_eth_frame);//incepe de la 0 si are 15000

if((raw_eth_frame[36] == 0x00)&&(raw_eth_frame[37]== 0x43))

{

gDHCP_OPTIONS_INDEX = 0;

fDHCPProcess(raw_eth_frame);

}

}

void fDHCP_Offer(byte InputDhcpFrame[])

{

LONG packetHandle;

CHAR error[100];

struct DHCPFRAME Myframe_offer;

int i;

byte data[256];

byte destination_MAC[6], source_MAC[6]; //layer 2

byte destination_ip[4], source_ip[4]; //layer 3

byte transaction_ID[4];

memcpy_off(destination_MAC,0,InputDhcpFrame,0,6);

memcpy_off(source_MAC,0,InputDhcpFrame,6,6);

memcpy_off(transaction_ID, 0,InputDhcpFrame,46,4);

packetHandle = EthInitPacket("udp");

if(EthGetLastError()==0)

{

// set protocol fields

EthSetTokenData(packetHandle,"eth","source",6, source_MAC);

EthSetTokenData(packetHandle,"eth","destination",6, destination_MAC);

EthSetTokenInt(packetHandle,"ipv4","source",0xC0A80001 );// 192.168.0.1

EthSetTokenInt( packetHandle, "ipv4", "destination", 0xFFFFFFFF ); // 255.255.255.255

EthSetTokenInt( packetHandle, "udp", "source", 0x43);

EthSetTokenInt( packetHandle, "udp", "destination", 0x44);

// set UDP payload

//XID = transaction ID

EthResizeToken( packetHandle, "udp", "data", 548*8);

gBOOTP_CONTENT[0]=0x02; //campul op din dhcpoffer

gBOOTP_CONTENT[1]=0x01;//campul htype din dhcpoffer

gBOOTP_CONTENT[2]=0x06;//campul hlen din dhcpoffer

memcpy_off(gBOOTP_CONTENT, 4, transaction_ID, 0, 4);//campul xid din dhcpoffer

memcpy_off(gBOOTP_CONTENT, 16, gDHCP_CLIENT_ADDRESS, 0, 4);//campul ciaddr din dhcpoffer

memcpy_off(gBOOTP_CONTENT, 28, source_MAC, 0, 6);//campul chaddr din dhcpoffer

memcpy_off(gBOOTP_CONTENT,236, gMAGICCOOKIE, 0, 4);//campul magic cookie din dhcpoffer

//––––optiunea 53 – dhcp message type–––

//option code

data[0]=0x02;

OptionAdd(53, 1, data);

//––––––optiunea 1 – subnet mask–––

OptionAdd(1, 4, gSUBNET_MASK);

//––––––optiunea 3 – router–––––

OptionAdd(3, 4, gDHCP_SERVER_ADDRESS);

//––––––optiunea 6 – DNS–––––

OptionAdd(6, 4, gDHCP_SERVER_ADDRESS);

//––––optiunea 54 pentru dhcp server–––

OptionAdd(54, 4, gDHCP_SERVER_ADDRESS);

//––––optiunea 51 lease time–––

OptionAdd(51, 4, gDHCP_LEASE_TIME);

//––––optiunea 255-END–––-

data[13]=255;

OptionAdd(255,0,data);

//setting UDP payload

EthSetTokenData(packetHandle,"udp","data",548, gBOOTP_CONTENT);

// Complete and send packet

EthCompletePacket( packetHandle );

EthOutputPacket( packetHandle );

// release packet

EthReleasePacket( packetHandle );

}

else

{

EthGetLastErrorText( elCount(error), error );

write("Error: %s", error );

}

}

2.Cod sursă DoIP

includes

{

}

variables

{

byte local_ip[4] = {192, 168,0,11};

byte local_port[2] = {0x86, 0xC7};

byte remote_ip[4] = {192, 168,0,10};

byte remote_port[2] = {0x34, 0x58};

byte mock_doip_request[8] = {0x02, 0xFD, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00};

char Receive_Data[128];

byte Receive_Data_Byte[128];

int i;

long local_socket, error;

dword Receive_Data_Size;

struct four_bytes_to_dword

{

dword content;

};

struct two_bytes_to_dword

{

word content;

};

struct four_bytes_to_dword local_dword_ip, remote_dword_ip;

struct two_bytes_to_dword local_dword_port, remote_dword_port;

}

on start

{

memcpy(local_dword_ip, local_ip);

memcpy(local_dword_port, local_port);

local_dword_port.content = swapWord(local_dword_port.content);

memcpy(remote_dword_ip, remote_ip);

memcpy(remote_dword_port, remote_port);

remote_dword_port.content = swapWord(remote_dword_port.content);

local_socket = udpOpen(local_dword_ip.content, (dword)local_dword_port.content);

error = ipGetLastError();

udpReceiveFrom(local_socket, Receive_Data_Byte, elcount(Receive_Data_Byte));

}

on sysvar_update sysvar::UDP_Stack_Variables::sysDoIP_VEHICLE_IDENT_REQUEST_SEND

{

udpSendTo(local_socket, remote_dword_ip.content, (dword)remote_dword_port.content, mock_doip_request, 8);

error = ipGetLastError();

}

on sysvar Button::Btn_Send

{

byte DoIP_vehicle_ident_request[256];

if(SysGetVariableInt(sysvar::Button::Btn_Send)==1)

{

sysSetVariableData(sysvar::UDP_Stack_Variables::sysDoIP_VEHICLE_IDENT_REQUEST_SEND, DoIP_vehicle_ident_request, elcount(DoIP_vehicle_ident_request));

}

}

void OnUdpReceiveFrom( dword socket, long result, dword address, dword port, byte buffer[], dword size)

{

int response_length;

byte doip_response[120];

memcpy(Receive_Data_Byte, buffer, size);

write("Received %d bytes", size);

for(i=0; i<size; i++)

{

write("Received data[%d] is %02X", i, Receive_Data_Byte[i]);

}

udpReceiveFrom(local_socket, Receive_Data_Byte, elcount(Receive_Data_Byte));

OutputToPanel();

}

void fConvertByteArrayToString(char newString[], byte byteBuffer[], int offset, long noOfBytes)

{

char stringaux[3];

int i;

for(i=offset; i<offset + noOfBytes ; i++)

{

snprintf(stringaux,3,"%.2x",byteBuffer[i]);

strncat(newString,stringaux,2*noOfBytes+1);

}

}

int fGetASCII(char input)

{

int returnVal;

switch(input)

{

case '0':

returnVal=0;

break;

case '1':

returnVal=1;

break;

case '2':

returnVal=2;

break;

case '3':

returnVal=3;

break;

case '4':

returnVal=4;

break;

case '5':

returnVal=5;

break;

case '6':

returnVal=6;

break;

case '7':

returnVal=7;

break;

case '8':

returnVal=8;

break;

case '9':

returnVal=9;

break;

case 'A':

returnVal=10;

break;

case 'B':

returnVal=11;

break;

case 'C':

returnVal=12;

break;

case 'D':

returnVal=13;

break;

case 'E':

returnVal=14;

break;

case 'F':

returnVal=15;

break;

case 'a':

returnVal=10;

break;

case 'b':

returnVal=11;

break;

case 'c':

returnVal=12;

break;

case 'd':

returnVal=13;

break;

case 'e':

returnVal=14;

break;

case 'f':

returnVal=15;

break;

default:

returnVal=-1;

break;

}

return returnVal;

}

void OutputToPanel()

{

char version[5], type[5], data[5];

fConvertByteArrayToString(version, Receive_Data_Byte, 0, 2);

sysSetVariableString(sysvar::DoIP_Response::Res_Version,version);

fConvertByteArrayToString(type, Receive_Data_Byte, 2, 2);

sysSetVariableString(sysvar::DoIP_Response::Res_PayloadType,type);

fConvertByteArrayToString(data, Receive_Data_Byte, 4, 2);

sysSetVariableString(sysvar::DoIP_Response::Res_Data,data);

}