Depanarea hardware − activitatea zilnică a unui dezvoltator de software embedded
În anii ’90, existau practic două soluții bazate pe instrumente pentru depanarea software-ului încorporat în hardware-ul real: “Debuggerul monitor”, adică o ‘bucată’ de software care era programată în memoria sistemului embedded și care reacționa la solicitările unui software de depanare din exterior și “Emulatorul in-circuit”, o piesă hardware (de mari dimensiuni) care înlocuia și emula microcontrolerul/procesorul aflat în hardware-ul țintă prin adaptare.
Figura 1: Emularea în circuit la sfârșitul anilor 1980 (© iSYSTEM)
Soluția depanatorului ‘monitor’ era ieftină și îndeplinea funcțiile de depanare de bază; soluția emulatorului în circuit era foarte scumpă, greu de utilizat, iar adaptarea era adesea nesigură și predispusă la erori. În schimb, dezvoltatorul primea transparență totală și acces la toate magistralele microcontrolerului/procesorului. Atât măsurătorile de sincronizare, cât și analiza de acoperire a codului erau deja posibile la acea vreme. Cu toate acestea, producătorii de semiconductori trebuiau să dezvolte un așa-numit cip de emulare special, cu pini suplimentari în acest scop. Un factor economic esențial pentru toți cei implicați.
Miniaturizarea crescândă a semiconductorilor și introducerea interfețelor de depanare pe cip au avut un mare impact asupra arhitecturii unui depanator ca instrument de dezvoltare în sine. Din ce în ce mai multe funcționalități care erau realizate anterior în hardware erau acum implementate în software. Mediile de dezvoltare și software-ul de depanare au devenit mai puternice, iar hardware-ul mai mic, cu performanțe din ce în ce mai mari în ceea ce privește lățimea de bandă și viteza. Cu toate acestea, cazurile de utilizare de bază ale depanării sunt aceleași și astăzi.
Depanatorul hardware în dezvoltare
Figura 2: Depanarea hardware − activitatea zilnică a unui dezvoltator de software embedded (© iSYSTEM)
De la printf la “just” flash la puncte de întrerupere (breakpoints), ceasuri în timp real și ‘step over’, iată cum ați putea descrie pe scurt depanarea. În principiu, depanarea este utilizată pentru dezvoltare și depanarea defecțiunilor în dezvoltarea de drivere, instalarea plăcii/hardware, procesele de pornire și multe altele ca metodă standard pentru dezvoltarea “low-level”, adică legată de hardware. Un depanator este utilizat pentru a afișa software-ul pe un hardware țintă, pentru a începe execuția sau pentru a o stopa într-un anumit punct al codului prin intermediul unui punct de întrerupere, pentru a verifica zonele de memorie și regiștrii sau pentru a le manipula pentru testare, pentru a citi stiva de apeluri și așa mai departe. Din punct de vedere aplicativ, depanarea este simplă și ușor de înțeles. De cele mai multe ori, nu avem suficient timp să ne ocupăm intensiv de depanatorul propriu-zis pentru a descoperi eventual “Sfântul Graal al depanării”, caracteristici suplimentare care ar putea, în cele din urmă, să economisească mult timp în depanare și testare. De exemplu și în acest context, o tehnică subestimată este trasarea (tracing). Aceasta oferă informații despre execuția software-ului fără a afecta comportamentul în timpul execuției. Dezvoltatorul obține astfel o imagine reală a execuției software-ului pe hardware. Pot fi descoperite erorile și blocajele care apar sporadic în software. Acesta este doar un exemplu din numeroasele cazuri alternative de utilizare a unui depanator.
Microcontrolere, procesoare și SoC-uri
Evoluția depanării a fost însoțită de miniaturizarea semiconductorilor, de creșterea complexității și a vitezei acestora. În ultimii 15 ani, industria embedded, în special industria auto, a introdus numeroase funcții suplimentare în produsele sale pentru a respecta reglementările actuale și viitoare în materie de mediu, pentru a reduce numărul de accidente auto în general, pentru a dezvolta și produce vehicule mai eficient prin distribuirea funcționalităților în mai multe unități de control electronic (ECU) în loc să dezvolte un ECU dedicat fiecărei funcții și pentru a se diferenția de concurență. Pentru a realiza toate acestea, industria automobilelor avea nevoie de producători de semiconductori care să le îndeplinească cerințele prin dezvoltarea și producerea de microcontrolere mai compacte și mai rapide.
Așa au luat naștere microcontrolerele ‘multicore’ embedded, controlere cu două sau mai multe nuclee. Trecerea de la arhitecturi cu un singur nucleu la arhitecturi multinucleu în ECU a venit cu noi provocări pentru toată lumea. Furnizorii de instrumente software embedded s-au confruntat cu noi probleme, de la cum să acceseze cu ușurință toate nucleele unui ECU multicore până la cum să distribuie software-ul embedded și moștenit pe diferite nuclee care să ruleze cel mai eficient, menținând în același timp performanțe ridicate. Modul tradițional de dezvoltare a software-ului încorporat era deja pus sub semnul întrebării la acest nivel.
Figura 3: Analizatorul winIDEA de la iSYSTEM; în stânga obiectele înregistrate și în dreapta corelația lor temporală. (© iSYSTEM)
Odată cu introducerea platformelor de calcul de înaltă performanță și a sistemelor cu mai multe nuclee, se folosesc acum arhitecturi de procesoare și mai complexe pentru dezvoltarea de aplicații foarte sofisticate. Ce rol mai joacă aici depanarea? În principiu, rămâne cu elementele de bază. Pe lângă componentele flash interne ale unui microcontroler, trebuie operate și componentele flash externe ale SoC-ului. Depanatoarele ajută mai întâi la controlul procesului de pornire și apoi, în etapa următoare, la examinarea îndeaproape a părților individuale și a nucleelor acestor procesoare, precum și a software-ului care rulează pe astfel de dispozitive. Pe lângă funcțiile standard de depanare și datorită complexității tot mai mari a acestor sisteme software, se utilizează din ce în ce mai des opțiuni de analiză, cum ar fi analiza sincronizării, profilarea funcțiilor sau măsurarea sarcinii unității centrale de procesare (CPU) (figura 3). Condițiile prealabile pentru acest demers presupun existența unor interfețe de urmărire (trace interfaces) pe semiconductorul utilizat și a unui depanator corespunzător al cărui software implementează astfel de funcții.
Evoluțiile tehnice din industria semiconductorilor schimbă procesul de dezvoltare a software-ului și, la rândul său, depanatorul, ca instrument fundamental, devine un instrument de proces.
Procese de dezvoltare de software și standarde
Echipe de dezvoltare distribuite, o bază de cod din ce în ce mai complexă, cerințe funcționale din ce în ce mai mari, standardizare și presiunea timpului: chiar și în dezvoltarea de software embedded, provocarea de a aduce pe piață un produs fiabil și sigur în cel mai scurt timp posibil poate fi îndeplinită doar cu un grad mai mare de abstractizare și automatizare.
Figura 4: În prezent, depanatoarele oferă API-uri care realizează procesele de dezvoltare și testare cu tranziții ușoare și automatizate ale instrumentelor. (© iSYSTEM)
Prin urmare, instrumentele de dezvoltare în sens clasic trebuie să fie mai versatile ca niciodată. Folosit anterior exclusiv de către experții în microcontrolere ca instrument de dezvoltare legat de hardware, un depanator poate fi întâlnit acum din ce în ce mai des într-o mare varietate de situații de dezvoltare de software. Depanatorul reprezintă în continuare conexiunea cu hardware-ul țintă real prin intermediul interfețelor de depanare standard, cu scopul de a dezvolta și testa software-ul încorporat cât mai aproape posibil de hardware-ul real. Pe lângă simpla interfațare cu un hardware țintă, depanatoarele oferă funcționalități de depanare mai avansate, inclusiv capabilități de testare. Astfel, dezvoltatorul are posibilitatea de a urmări execuția software-ului care rulează. În acest scop, starea programului poate fi inspectată, iar execuția programului poate fi oprită în anumite condiții. Acest lucru se face cu o influență minimă sau deloc asupra software-ului testat. Soluțiile profesionale de depanare permit, în plus, înregistrarea în timp real a proceselor din software (tracing), înregistrarea timpilor de execuție în intervalul ciclurilor de ceas, precum și evaluarea părților procesate ale software-ului relevante pentru testare (code coverage).
Pentru ca un client să poată utiliza în mod flexibil toate aceste funcționalități, producătorii de depanatoare oferă interfețe generice (API-uri) care permit integrarea acestor instrumente în procesul de dezvoltare și testare al clientului (figura 4). Aceste interfețe trebuie să fie adecvate pentru rezolvarea unei mari varietăți de sarcini (dezvoltare, testare, verificare și validare de software și hardware). Standardul în acest caz este suportul limbajelor de programare (C, C++, C#, Java etc.) și de scripting (Python etc.) pentru “controlul de la distanță” al instrumentului de dezvoltare de la o altă aplicație (de asemenea, specifică clientului). Practic, anumite părți ale procesului pot fi astfel automatizate atât în timpul dezvoltării, cât și al testării.
În plus, depanatoarele actuale oferă așa-numitele funcționalități “mini-HIL” (hardware-in-the-loop, module de măsurare și de stimulare pentru teste) pentru a genera sau măsura semnale digitale și analogice, înregistrând și corelând în același timp execuția programului. Acest lucru face posibilă testarea foarte aproape de realitate și cât mai devreme posibil în timpul dezvoltării software-ului. Totul realizat din mediul cunoscut, aproape “din mers” și fără a învăța o nouă metodologie.
Figura 5: Pipeline-ul unei infrastructuri de integrare continuă cu construcție, analize statice, teste unitare, teste de sistem și, în final, un produs livrabil. (© iSYSTEM)
Un caz tipic de utilizare a acestor interfețe flexibile pentru automatizarea testelor este integrarea continuă (CI − Continuous Integration). CI sprijină dezvoltarea și testarea agilă/distribuită a software-ului prin integrarea modificărilor sau a codului nou creat de către dezvoltatori într-un depozit partajat cu echipa, la intervale scurte de timp. Există mai multe servere de integrare continuă adecvate în acest scop, cum ar fi Jenkins, GitLab, TeamCity, CircleCI sau GitHub Actions. Odată cu integrarea, o serie rapidă și foarte automatizată de pași − numită “pipeline” − este declanșată prin intermediul unui software CI găzduit intern sau în cloud. De obicei, pipeline-ul include și combină compilarea, analiza statică, testele unitare și de sistem.
Depanatorul clasic devine astfel un instrument de testare pentru verificările pe hardware-ul real.
În general, software-ul poate fi, de asemenea, supus unor teste extinse pe o platformă PC, independent de hardware-ul țintă. Cu toate acestea, nu toate erorile potențiale sunt detectate în mediile simulate: de exemplu, de multe ori, periferia hardware necesară nu este disponibilă sau aplicația nu se comportă la fel ca pe hardware-ul real, comportamentul de sincronizare este diferit sau compilatorul încrucișat generează un cod obiect specific țintei și, prin urmare, nu același cod ca cel al compilatorului utilizat pentru mediul de testare. Prin urmare, este logic să se testeze cât mai aproape posibil de hardware-ul real într-un stadiu incipient pentru a se asigura funcționarea corectă a produsului final, precum și comportamentul exact al aplicației în ceea ce privește sincronizarea.
Standardele de siguranță, cum ar fi ISO26262 și DO-178C, au o influență asupra domeniului de aplicare funcțional al instrumentelor și asupra furnizării dovezilor de corectitudine a acestor funcții către client. În special în domeniul aviației, producătorii de instrumente au fost obligați să coopereze de ceva timp în privința calificării instrumentelor − dar și mai recent în industria auto, cu ISO26262. În acest scop, producătorii de instrumente trebuie să creeze opțiuni de verificare a corectitudinii funcționale a instrumentelor utilizate în raport cu cazuri de utilizare specifice. Acestea pot fi măsuri organizatorice, de exemplu, audituri externe ale procesului de dezvoltare sau certificarea instrumentelor de către părți terțe independente, sau suite de instrumente de referință care sprijină clientul în realizarea dovezii de corectitudine. Metodele descrise mai sus pentru automatizarea procedurilor de testare cu ajutorul depanatoarelor sunt foarte potrivite pentru implementarea unor astfel de procese de calificare a instrumentelor.
Concluzie
Depanatorul se transformă din ce în ce mai mult într-un instrument de proces. Funcțiile de bază ale unui depanator își găsesc aplicarea obișnuită și sunt completate de funcții de analiză puternice. Complexitatea crescândă a software-ului, numărul mare de instrumente software și hardware utilizate în dezvoltarea software-ului propriu-zis și interdependențele dintre acestea determină nevoia de transfer de cunoștințe și servicii de consultanță între producătorii de instrumente, furnizorii de cipuri și clienți. O comunicare continuă și deschisă între toate părțile implicate în aceste evoluții este cheia succesului. În prezent, clienții nu mai doresc să cumpere instrumente, ci să le utilizeze oricând și oriunde sunt necesare. Vor apărea noi modele de afaceri pentru dezvoltarea de software embedded și testarea de software, în care instrumentele, transferul de cunoștințe și consultanța vor fi un produs comun și, în cele din urmă, un serviciu. La fel ca în industria software, modelul de afaceri prin abonament este cel mai potrivit pentru dezvoltarea și testarea globală a software-ului embedded.
Autor:
Erol Simsek
CEO al iSYSTEM,
o companie privată care dezvoltă și produce instrumente și soluții pentru dezvoltarea și testarea software-ului embedded.
