Constantin Lazăr 
Silviu Cacoveanu 
Andrei Crăciun Crearea de software conceput pentru a acționa vehiculele autonome implică mai multe aspecte care nu sunt întâlnite în nicio altă industrie. Unul dintre acestea, pe care dorim să îl abordăm în acest articol, se referă la validarea algoritmilor care acționează "ochii" vehiculului. Este vorba de algoritmii de computer vision.
Pentru a simplifica felul în care arată acest software, vom spune că există o multitudine de senzori precum camere video, LIDAR, RADAR. Pe baza informațiilor furnizate de aceştia, o serie de algoritmi operează și calculează ceea ce "vede vehiculul". De exemplu, fiecare cadru capturat de camere este evaluat, iar obiecte precum alte vehicule, benzi de circulație, locuri de parcare, sunt identificate și se calculează dimensiunile lor. Testarea și validarea unor asemenea algoritmi este destul de dificil de făcut în modul clasic, deoarece se întâmplă adesea ca anumite scenarii să fie dificil de reprodus, iar altele să fie chiar foarte riscant de reprodus. (Imaginați-vă că dorim să testăm cum s-ar comporta vehiculul dacă se află în spatele unui camion încărcat cu lemne; le-a luat colegilor noștri care lucrează cu vehicule de test câteva săptămâni ca să găsească un astfel de scenariu) Chiar dacă scenariile sunt reproductibile, depanarea în timpul condusului nu este o opțiune. Dar nu vă îngrijorați, aceasta nu înseamnă că algoritmii nu sunt validați sau că va dura secole până când vom avea un software de încredere.
Soluția noastră a fost să dezvoltăm un ecosistem în care, odată ce anumite date au fost înregistrate într-un vehicul de test, acestea vor putea fi utilizate iar și iar într-un mediu simulat. Partea cea mai complexă a acestui ecosistem este reprezentată de sistemul care validează algoritmii care procesează date de la camerele video. Noi numim aceste medii artificiale HIL (Hardware in the Loop/ Hardware în buclă) și SIL (Software in the Loop/ Software în buclă). HIL înseamnă că o cameră așezată pe biroul developerului este capabilă să ruleze codul cu input din secvenţă, ca şi cum camera s-ar afla în vehicul în mod real, în scenariul înregistrat în secvenţă. Secvenţa este fișierul care conține anumite date înregistrate. SIL-ul ca şi HIL-ul foloseşte un mediu simulat cu excepția faptului că nu folosim o cameră, ci un emulator. Pentru validare automată, am construit o "Fermă HIL-uri", care este reprezentată de o multitudine de camere conectate la o rețea de calculatoare și este capabilă să facă teste într-o manieră HIL.
În continuare, vom expune provocările implicate în dezvoltarea unui asemenea ecosistem. Mai întâi, ar trebui să vorbim puțin despre secvențe. O secvență este un fișier ce conţine înregistrarea datelor într-o perioadă de timp. Datele pot fi streamuri video, informații CAN din vehicul, rezultate ale algoritmilor, informații despre locație, etc. Dimensiunea unor astfel de fișiere este de ordinul gigabyţilor pentru că vrem să avem date cât mai multe şi mai exacte şi vrem să le transmitem şi cât mai repede spre a fi procesate. Volumul acesta mare de date ne cam pune în dificultate.
Avem nevoie să procesăm date de la mai mulţi senzori, în acelaşi timp şi cât mai aproape de timpul prezent cu putinţă, pentru a lua decizii rapid şi pentru a ne adapta la mediul în continuă schimbare. Așadar, avem nevoie să procesăm date de la senzori ce pot fi de acelaşi tip (de exemplu, camere video), sau de tipuri diferite (de exemplu, camera video şi radar). Mai mulţi senzori trimit date spre a fi validate din acelaşi vehicul sau din mai multe vehicule simultan.
Dacă luăm în considerare numărul vehiculelor de test din lume și facem calculul, ţinând cont de dimensiunile fişierelor despre care am scris anterior, vom ajunge rapid la concluzia că "internetul nu este suficient". De ce? Pentru că avem nevoie de toate secvențele într-un singur loc. Am putea încerca o abordare distribuită cu mai multe centre de date, dar aceasta nu ar aduce mari îmbunătățiri. Indiferent de ce viteză sau lărgime de bandă avem - luând în considerare soluțiile disponibile în prezent- ne va lua perioade foarte lungi de timp pentru a încărca zeci de terabytes de date de la fiecare vehicul de test, zilnic. Din cauza acestor limitări, înregistrăm secvența pe unități de disc locale (HDD) și apoi "mutăm" aceste date într-un centru de date.
Odată ce hard diskurile sunt livrate la centrul nostru de date, ele sunt copiate într-un depozit de date și puse la dispoziția tuturor (adică a inginerilor care au făcut o cerere). Bineînțeles că sunt copiate într-un cluster cu backupuri, ceea ce înseamnă că fișiere diferite sunt salvate pe dispozitive diferite. Se întâmplă ca același fișier să poată fi partajat între dispozitive diferite.
Iată mai jos doar câteva dintre posibilele contexte:
Pentru a valida automat rezultatele dintr-un fișier de secvență, a fost scris un program care verifică dacă acele rezultate se potrivesc cu ceea ce numim ground truth. Ce înseamnă aceasta? Înseamnă că vehiculele de test sunt echipate cu senzori de referință. Pe de altă parte, se referă la faptul că există un proces numit labeling în care oamenii se uită la video-urile înregistrate și prin utilizarea unor tooluri software speciale, marchează obiectele care sunt vizibile. Pentru a da un exemplu specific, haideți să ne imaginăm că dorim să testăm un algoritm care detectează cicliștii care se mișcă în aceeași direcție cu vehiculul nostru. În acest caz, putem utiliza LIDAR-ul drept senzor de referință (acesta ne va spune că niște puncte care se potrivesc în linii mari cu forma unui ciclist sunt mai aproape de vehicul decât restul), iar informația de labeling va confirma că acolo se află o bicicletă. Problemele acestui scenariu de testare sunt următoarele: nevoia de a procesa fișiere mari de ordinul gigabyţilor (procesarea poate include copierea fișierului pe un dispozitiv de procesare) și obținerea datelor de labeling la fiecare rulare.
Pentru a rezolva problema cauzată de copierea repetată a fișierelor, am definit un nou nivel deasupra datelor brute, pe care îl numim meta-data. Pentru a obține meta-data, rulăm doar un singur program care extrage informații importante din fișierul înregistrat de ordinul gigabyţilor și creează un document mult mai compact (de ordinul megabyţilor de această dată), cu care continuăm într-un sistem de fișiere HDFS. Pe parcursul acestui proces ETL (Extragere, Transformare, Încărcare), fișierul de labeling și informațiile adiționale care ar putea fi necesare mai târziu sunt adăugate documentului și astfel, poate să înceapă validarea automată.
Acum că am creat contextul pentru validarea automată, ne putem concentra pe eliminarea greșelilor din program. Doar imaginați-vă că sunteți în pielea unui programator care trebuie să elimine o eroare care apare numai atunci când în fața vehiculului se află un altul de culoare roșie, pe o stradă din Japonia, pe vreme ploioasă. Pentru a reproduce această problemă particulară, el sau ea trebuie să descarce toate acele fișiere și să verifice dacă secvenţa video îndeplinește cerințele. Aceasta ar dura săptămâni, chiar dacă avem o lărgime nemaipomenită de bandă la birou, transmiterea prin email nu mai funcționează aici. În schimb, am dezvoltat un motor de căutare care caută prin meta-date și bineînțeles, se bazează pe un index construit deasupra nivelului de meta-date. Pentru a implementa acest motor de căutare, tool-uri de indexare precum ElasticSearch sau Solr se numără printre opţiuni.
În acest moment, este important să menționez un nou termen pe care îl folosim des, scena, care este un set de date caracterizate printr-un atribut (un exemplu bun este scena virajului la dreapta, care semnifică toate informațiile înregistrate în timp ce vehiculul virează la dreapta). Avem nevoie de un concept precum scena deoarece separarea timpului nu este întotdeauna corectă (uneori o scenă durează mai puțin de un minut, de exemplu, depășirea unui vehicul) și, de obicei, pe parcursul unei scene putem aplica tipare (traficul care vine din sens opus trebuie verificat înainte de depășirea vehiculului din față).
Secțiunea anterioară descrie situații de mutare și în final de procesare a unor volume mari de date de la vehicule, care vor folosi procesului de dezvoltare și vor da naștere unor algoritmi mai buni pentru componentele instalate în vehicul. În această secțiune, dorim să vă prezentăm o călătorie diferită în lumea datelor pe care o explorăm, de asemenea, un scenariu care este mai mult centrat pe imaginea de ansamblu a testării senzorilor. De îndată ce componentele dezvoltate pentru clienții noștri ating un stadiu de dezvoltare stabil, ele trebuie testate în situații din viața reală pentru un număr de ore (mii) pentru a fi validate. Acest proces va fi numit : de validare.
Abordarea anterioară, prin înregistrarea rezultatelor senzorilor din vehicul pe un hard-disk din vehicul și în final transferul acelor date pe serverele noastre de procesare, nu se potrivește foarte bine cu scenariul procesului de validare. Managerii sau responsabilii pentru procesul de validare s-ar afla în situația de a aștepta săptămâni sau chiar luni, până când datele sunt procesate, iar ei ar putea să-și formeze o privire de ansamblu asupra procesului de validare. Un proces de validare durează, în mod obișnuit, câteva luni. În acest caz, managerii sau inginerii responsabili pentru procesul de validare nu ar avea date suficient de recente pentru a lua decizii informate și pentru a adapta strategiile de testare.
Pentru a servi mai bine procesului de validare, ne concentrăm pe transferul și procesarea datelor într-un timp aproape real. Această abordare ar fi ideală pentru orice date înregistrate în vehicul, dar atunci când se înregistrează cantități mari de date, transferul lor în timp real prin rețele mobile poate deveni prohibitiv de scump. Pentru a soluționa această problemă, selectăm o submulțime redusă de date, ceea ce considerăm vital pentru analizarea procesului de validare și le trimitem numai pe acestea prin rețeaua mobilă. Datele pe care le selectăm constau în sub-eșantioane de valori ale senzorilor la intervale de timp periodice, de exemplu, la fiecare secundă. Aceste informații sunt încărcate în cantități mici, așa cum sunt înregistrate în vehicul.
Apoi trimitem aceste date în cloud (există mai mulți pași înainte ca datele noastre să ajungă de fapt în acest cloud), unde putem utiliza tehnologii big data pentru a le procesa prin noduri multiple. Aceste noduri de procesare funcționează permanent, primind datele noi când acestea sosesc și operând rezultatele complete de care avem nevoie. Această structură garantează că sistemul nostru poate prelucra informațiile provenite din parcuri auto multiple și le poate procesa aproape în timp real.
Când procesăm datele, ne concentrăm pe obținerea unor rezultate cât mai apropiate de ceea ce dorim să prezentăm utilizatorilor noștri. Sistemul nostru este conceput pentru a folosi cel mai mult timp de procesare în backendul distribuit, cu timp minim de procesare rezervat pentru UI, timp destinat grupării datelor prin selectarea perioadelor de timp și adunarea valorilor de interes. Rezultatul este un UI selectiv care prezintă ultimele date precalculate pe care le avem disponibile.
Rezultatele indicate se concentrează pe numărul total de ore de conducere în timpul unui proces de validare și, de asemenea, pe o împărțire a acestor ore după o combinație variată de factori (cum ar fi perioada din zi în care vehiculul a fost condus, defalcarea orelor pe țări sau condițiile meteo) care pot fi de interes pentru manageri. Apoi, afișăm informații la comandă pentru diferite proiecte de validare precum temperaturile înregistrate ale senzorilor din vehicul sau erorile înregistrate cu locația în care a apărut fiecare eroare, indicată pe o hartă. Cu aceste informații, managerii își pot adapta strategia și își pot instrui echipele să se concentreze pe testarea senzorilor în scenarii specifice, de exemplu, pe conducerea în timpul nopții pe vreme ploioasă.
Organizarea big data descrisă aici ne dă oportunitatea să răspundem și să fim suficient de flexibili încât să satisfacem nevoile colegilor și clienților noștri într-un timp rezonabil și să aducem perspective utile testării senzorilor auto din întreaga companie.
Toate datele colectate prin aceste canale sunt stocate într-un depozit comun pe care îl numim RAW Data (date brute). Pentru aceasta, profităm de avantajele oferite de opțiunile de depozitare HDFS; de asemenea, există numeroase centre de date care au un sistem de fișiere diferit, dar toate au puncte de montare în ecosistemul HDFS.
Datele raw oferă informații utile, iar îmbinarea multiplelor surse de date va duce la rezultate interesante și valoroase. Pentru a obține aceste rezultate, rulăm algoritmii furnizați de data scientists în joburi de Spark care sunt înlănțuite folosind subiecte Kafka și, în final, obținem un nou nivel de date pe care îl numim Meta Data. Deoarece acest tip de date sunt cele pe care le vom utiliza cel mai mult în procesările viitoare, le păstrăm în clusterul HDFS.
Odată ce Meta Datele sunt disponibile, cele mai frecvente cazuri de utilizare sunt indexarea datelor și evaluarea performanței. Indexarea se referă la construirea unui motor de căutare care poate fi folosit pentru a căuta diferite informații prin toate datele (foarte util pentru obținerea datelor de test), în timp ce evaluarea performanței înseamnă verificarea comportamentului algoritmilor în teste din viața reală.
Un caz de utilizare special este adăugarea tuturor informațiilor pe un graf de cunoştinţe (knowledge graph) pentru a putea căuta date semantice. La început, aceasta ar putea să se asemene cu indexarea, sau cel puțin cu o indexare pe steroizi, dar de îndată ce puterea sa se dezlănțuie, este mai mult decât atât. Utilizând modele adecvate, cererile de căutare apropiate de limbajul natural pot fi soluționate ușor, oferind astfel utilizatorului o experiență familiară.
Nu în ultimul rând, ar trebui să discutăm despre siguranță. La acest nivel, avem de a face cu două aspecte: pe de o parte, siguranța conexiunii și, pe de altă parte, protecția datelor. Cea mai importantă este protecția datelor și în special protecția datelor procesate, pentru rezultate. Și cum să protejezi ceva mai bine decât prin tăierea accesului la acel ceva?
Cu acestea în minte, am adus omagiu şablonului DMZ pentru abordare multistrat, cu datele cele mai sensibile depozitate în zona sigură și datele care ar trebui să fie publice în zone DMZ diferite, în funcție de publicul țintă. Ca să scurtăm povestea, datele dintr-o zonă mai puțin sigură nu pot fi împinse într-o zonă sigură, ci pot fi doar extrase din cea mai puțin sigură prin servicii care rulează în aceea sigură. Același lucru este valabil și pentru rezultate: ele sunt publicate de către servicii localizate în zona de siguranță și nu pot fi extrase din zona mai puțin sigură.
de Ovidiu Mățan
de Ovidiu Mățan
de Ovidiu Mățan
