Trăim într-o eră în care mobilitatea și independența oferită de mașină au devenit o necesitate în viața noastră de zi cu zi. În ultimele decenii, amploarea invențiilor tehnologice de ultimă generație a atras mașina într-un proces accelerat de tranziție de la preponderența mecanică la preponderența electronică și software.
Această evoluție ne-a adus, pe lângă o multitudine de noi funcționalități, mai mult confort și, cel mai important, mai multă siguranță.
Mașina, astăzi, reprezintă în realitate un întreg ecosistem, la baza căruia stă un computer de bord care este bombardat la fiecare milisecundă de mesaje primite de la ECU-uri (Electronic Control Unit) care îndeplinesc diverse funcționalități, de la măsurarea presiunii în roți, până la module complexe de procesare de imagine, cum ar fi Lane Departure Warning sau Drowsiness detection.
Pentru ca toți acești senzori să fie interconectați, să comunice în timp real și să ofere răspuns sau să ia anumite decizii în timp real, mașina are nevoie să aibă la bază o rețea complexă, bazată pe diverse protocoale de comunicare, cum ar fi CAN, CAN FD, LIN, Ethernet.
Aici intervine diagnoza. În domeniul automotive, conceptul de diagnoză este definit de standardul ISO 14229 - Road vehicles — Unified diagnostic services (UDS). Funcționalitatea cea mai cunoscută a diagnozei, la fel ca vizita la doctor, este aceea de a identifica inițial problema (de a pune un diagnostic), folosind un dispozitiv numit "tester".
Figura 1: Arhitectura de rețea internă
Acest tester este conectat la un central gateway, care poate avea la bază implementat protocolul "Diagnostic over IP", fundamentat pe standardul ISO 13400. Unul dintre principalele roluri ale protocolului DoIP este de a ruta mesajele trimise de către tester la un anumit ECU.
Cele mai frecvente situații în care DoIP este folosit se manifestă în etapa de development, în linia de asamblare a mașinii când acestea sunt programate/re-softate, în service-uri pentru reparații sau când sunt efectuate inspecții periodice.
În aceste scenarii, poate să difere, de la caz la caz, modul în care mașina interacționează cu testerul, mai exact, felul în care ele sunt conectate prin rețea.
Dacă ar fi să dăm ca exemplu linia de producție, vom avea cazul în care mai multe vehicule vor fi conectate prin rețea la același echipament de testare.
Figura 2: Rețea la care sunt conectate mai multe vehicule și un singur echipament de testare
Pentru ca echipamentul de testare să poată comunica eficient cu mașina, prin intermediul DoIP, acesta trebuie să cunoască adresa IP a mașinii și VIN-ul (Vehicle Identification Number) aferent.
Inițierea conexiunii se face prin cererea de identificare a vehiculului, Vehicle identification request, prin care se compară VIN-ul (Vehicle Identification Number) din cerere cu cel returnat de către vehicul. Deoarece vorbim despre cazul în care mai multe mașini sunt conectate la aceeași rețea și au același IP, vrem să primim confirmare doar de la o mașină specifică. Celelalte mașini din aceeași rețea vor primi și ele această cerere, însă dacă VIN-ul nu coincide, vor renunța la transmisie.
Figura 3: Identificarea vehiculului
Dacă mașina răspunde pozitiv, dar în mesajul de răspuns este menționat codul "Further Action Required", acesta indică faptul că mai este nevoie de un pas adițional pentru a stabili conexiunea dintre tester și vehicul: Routing activation. În acest caz, testerul va trimite cererea de Routing Activation, în care va specifica adresa echipamentului de testare și tipul de activare dorit. Acest pas adițional este util mai ales în cazul în care este necesară o autentificare a testerului pentru a trece de layerul de securitate.
Figura 4: Routing Activation
În cazul în care gatewayul returnează un răspuns pozitiv, acesta va marca o conexiune reușită și va deschide calea către ECU-ul vizat. Dacă, însă, routing activationul nu este acceptat, la fel ca în cazul anterior, se va renunța la transmisie.
Odată ce conexiunea este deschisă, DoIP este liber să ruteze mesajele de diagnoză către ECU-ul care urmează a fi testat sau reprogramat.
Figura 5: Arhitectura AUTOSAR
Într-un sistem AUTOSAR, mesajul de diagnoză transmis de către un tester extern este împachetat sub formă de pachet TCP Datagram și trimis către gateway. Din acest pachet de tip datagram sunt extrase mai apoi informațiile legate de mesajul de diagnoză (DoIp data type, data length, target address, data payload) și sunt transmise mai departe la modulul DoIP.
Folosindu-se de datele extrase: target address și data payload, modulul de DoIP va transmite datele către ECU-ul final prin intermediul PDU Routerului, care abstractizează mediul final de transmitere al mesajului (Ethernet, CAN, FlexRay, LIN, etc).
Figura 6: Formatul mesajului DoIP
În continuare, odată ce mesajele sunt rutate către ECU-ul dorit, aceste cereri vor fi gestionate de către modulul local de diagnoză - Diagnostic Communication Manager (DCM) care implementează în totalitate standardul de diagnoză ISO 14229.
Una dintre principalele aplicații ale acestui protocol este de a oferi posibilitatea unui tester extern să diagnosticheze un ECU al mașinii care nu are o conexiune fizică de ethernet. În acest caz, testerul trimite către ECU cererea de Read Diagnostic Information (0x19) pentru a citi posibilele coduri de eroare stocate de acest ECU.
O altă utilitate ar fi în cazul în care o anumită componentă se defectează și trebuie schimbată, iar testerul poate cere Part Number-ul acelei componente, prin serviciul de diagnoză Read Data by Identifier.
Un al treilea caz în care acest protocol se dovedește a fi extrem de eficient este momentul în care apar actualizări de soft, unde reprogramarea anumitor ECU-uri sau chiar a întregii mașini se face wireless prin funcția numită: Flash over the air.
Dacă ar fi să menționăm și dezavantajele, acestea ar fi potențialele vulnerabilități pe care le pot prezenta mașinile în momentul în care sunt conectate online. Însă, la momentul actual, toți producătorii de automobile au implementate sisteme de cyber security, care fac hackuitul aproape imposibil.
În concluzie, utilizarea acestei capabilități oferă mult mai multă eficiență atât dealershipurilor, cât și service-urilor auto. Înlăturând nevoia de cabluri, adaptoare și echipamente adiționale de care ar fi fost nevoie în trecut, această soluție devine time and cost efective, făcând acest proces și ușor de automatizat.
Road vehicles — Diagnostic communication over Internet Protocol (DoIP) — Part 1: General information and use case definition (ISO 13400-1) - Part 2: Transport protocol and network layer services (ISO 13400-2)
Road vehicles — Unified diagnostic services (ISO 14229)
Setting up a Diagnostic Test System based on DoIP, Vector.com
de Ovidiu Mățan
de Mihai Talpoș
de Radu Saveanu
