Echipe de dezvoltare distribuite, o bază de cod din ce în ce mai complexă, cerințe funcționale în creștere și constrângeri de timp: În multe domenii, inclusiv în dezvoltarea de software embedded, presiunea de a comercializa un produs fiabil și sigur în cel mai scurt timp posibil poate fi satisfăcută doar cu un grad mai mare de automatizare. De aceea, integrarea continuă (Continuous Integration – CI), cu instrumentele sale de construcție și de testare automate, devine din ce în ce mai răspândită în dezvoltarea de software embedded.
Automatizarea testelor cu CI
Datorită CI, toți membrii echipei, care lucrează împreună cu alții la un produs software, își trimit codul lor modificat sau nou creat la intervale scurte de timp într-un depozit de cod unic, partajat de întreaga echipă.
Figura 1: Pipeline-ul unei infrastructuri de integrare continuă; aceasta cuprinde construcția, analiza statică, testarea unitară, testarea sistemului și, în final, software-ul lansat. ▶
Există mai multe servere de integrare continuă potrivite pentru acest scop, cum ar fi Jenkins, GitLab, TeamCity, CircleCI sau GitHub Actions. Cu fiecare trimitere în depozit, o serie rapidă și foarte automatizată de pași – numită “pipeline” – este declanșată prin intermediul unui software CI care este găzduit intern sau în cloud. Pipeline-ul include, de obicei, construcția, analiza statică, testarea unitară și de sistem (Figura 1).
Un raport final arată dezvoltatorilor cum au afectat modificările de cod funcția și calitatea software-ului: De exemplu, este posibil ca procesul de construcție să fi fost defectuos, un test să fi eșuat sau să fi fost încălcate metrici importante. Datorită feedback-ului primit în timp util, dezvoltatorii își pot corecta codul în mod corespunzător și îl pot ” re-comite” la depozit, declanșând o altă execuție a pipeline-ului pentru a verifica din nou în mod automat cele mai recente modificări.
Prin automatizare cu ajutorul integrării continue și grație feedback-ului imediat, erorile în dezvoltarea de software embedded pot fi detectate și corectate într-un stadiu incipient. Codul de bază rămâne neafectat, deoarece, dacă, de exemplu, testele eșuează, codul modificat nu este integrat în ramura principală. În timpul procesului, dezvoltatorii se pot concentra asupra codului și nu trebuie să mențină configurații de testare pe computerele lor locale. Astfel, implementată în mod corespunzător, CI crește productivitatea în dezvoltarea de software embedded, îmbunătățește direct calitatea software-ului și economisește resurse și timp.
Verificați comportamentul de sincronizare printr-un sistem de urmărire (tracing) hardware în infrastructura de integrare continuă (CI)
În principiu, software-ul embedded poate fi testat pe scară largă, independent de un hardware țintă. Totuși, mediile simulate nu dezvăluie adesea toate erorile potențiale: De exemplu, perifericele hardware necesare sunt adesea indisponibile sau nu se comportă la fel ca pe hardware-ul real; sincronizarea este diferită sau cross-compilatorul generează un cod obiect specific țintei și, prin urmare, diferă de codul generat de compilatorul utilizat pentru mediul de testare. În consecință, are sens să se testeze cât mai aproape posibil de hardware-ul real într-o etapă timpurie pentru a asigura funcționarea corectă a produsului final, precum și comportamentul exact al aplicației în ceea ce privește sincronizarea.
Figura 2: Infrastructură de integrare continuă cu depanare hardware utilizând platforme (rackuri) de testare.
Deoarece aplicațiile devin din ce în ce mai complexe, iar performanța procesorului trebuie adesea folosită la maximum, este necesar să vă puneți de la început câteva întrebări, cum ar fi, de exemplu: “Cum afectează o modificare de cod performanța aplicației?” sau “Cum influențează un anumit modul comportamentul sistemului în timpul execuției?”. Răspunsurile la aceste întrebări sunt furnizate prin analiza sincronizării grație urmăririi hardware (tracing), care înregistrează date privind timpul de execuție al programului pe baza unui modul special ‘on-chip trace’ de pe procesorul țintă respectiv. Prin implementarea unei analize automatizate, dezvoltatorul poate verifica constrângerile de timing și poate supraveghea parametrii importanți de sincronizare în timpul dezvoltării de software. Blocajele pot fi identificate într-un stadiu incipient, iar software-ul poate fi corectat dacă este necesar. Utilizarea tracing-ului hardware permite, în plus, inginerului de testare să măsoare neintruziv acoperirea codului, adică să descopere codul care nu a fost testat. Codul de instrumentare care afectează comportamentul în timpul execuției nu este necesar.
Cu toate acestea, tracing-ul hardware prezintă unele provocări, deoarece, de exemplu, hardware-ul, plăcile de evaluare și instrumentele nu sunt disponibile pentru toți membrii echipei de dezvoltare, iar configurațiile de testare pot fi costisitoare pentru a fi instalate și actualizate. Rackurile hardware consacrate testelor oferă o soluție: aici, sunt conectate o serie de depanatoare la diverse ținte embedded și sunt accesibile prin USB și Ethernet. Acest lucru permite dezvoltatorilor să acceseze hardware-ul țintă în orice moment, indiferent de locația lor și să declanșeze teste simultane pentru mai multe ținte.
Tracing-ul hardware poate fi integrat în infrastructura de Integrare Continuă existentă a unei companii (Figura 2). Dezvoltatorii pot apoi să verifice funcționalitatea și calitatea codului lor, în special în execuția pe hardware-ul țintă, ca de obicei, prin comitere și să îl optimizeze dacă este necesar.
BlueBox în rackul de testare
În ultimii ani, iSYSTEM a acumulat multă experiență în ceea ce privește CI în dezvoltarea de software embedded și a implementat-o în sisteme CI reale – pentru propria dezvoltare de software și pentru clienții cu cerințe ridicate privind noile funcții software și disponibilitatea rapidă a acestora. Atunci când implementează teste automate de software și hardware într-o infrastructură de Integrare Continuă (CI), iSYSTEM se bazează pe produse dovedite și își folosește expertiza în activitatea de consultanță personalizată pentru clienți. BlueBox iC5000/iC5700 CI a fost dezvoltat special pentru implementarea într-o configurație de rack de testare CI. În combinație cu produsele software iSYSTEM winIDEA și testIDEA și cu interfețele și opțiunile de automatizare respective, BlueBox servește ca un framework de testare “la țintă”.
Figura 3: Rack-uri de testare la “iSYSTEM Labs” cu peste 150 de framework-uri de testare și plăci hardware țintă.
Pentru a efectua teste “on-target” prin intermediul unui BlueBox, hardware-ul trebuie să fie integrat în pipeline-ul (pipeline-urile) de Integrare Continuă. Acest lucru se face prin intermediul unei interfețe de automatizare, care este parte integrantă a winIDEA. Integrarea se poate face prin intermediul unor limbaje diferite, cum ar fi Python, Java sau C#.
Pentru dezvoltarea de software în cadrul companiei, iSYSTEM a creat rack-uri de testare în laboratoarele sale “iSYSTEM Labs”, unde există peste 150 de stații de testare individuale distribuite pe sertare în mai multe cabinete de testare (Figura 3). Fiecare dintre acestea cuprinde framework-ul de testare cu BlueBox și o țintă embedded. Toate sertarele au o sursă de alimentare proprie, putând fi deconectate și repuse sub tensiune individual și de la distanță. Fiecare hardware țintă poate fi utilizat de către infrastructura CI, precum și de inginerii de dezvoltare și testare care au nevoie rapid de un sistem țintă individual. iSYSTEM oferă o aplicație software dezvoltată intern, bazată pe web. Testele inițiate sunt colectate, puse în coadă de așteptare pe nodurile PC disponibile și, în cele din urmă, executate pe hardware-ul țintă respectiv. Rezultatele testelor sunt stocate într-o bază de date de testare corespunzătoare, iar modificările aduse funcționalității sunt transmise automat părților interesate. Tot hardware-ul este amplasat la nivel central într-un mediu adecvat, nemaifiind necesar să fie instalat în birourile dezvoltatorilor implicați în proiect, aflați oriunde în lume. Aceștia pot utiliza în paralel diferitele configurații hardware pentru a executa testele “on-target”. Acest lucru duce la timpi de execuție mai rapizi, iar răspunsul pentru dezvoltatori privind modificarea codului este disponibil mai rapid.
Concluzie
Avantajele Integrării Continue (CI – Continuous Integration) pentru dezvoltarea de software embedded sunt evidente: personalul de testare și integratorii pot detecta și corecta mai rapid erorile software, pot reproduce mai bine erorile, au software disponibil în permanență, livrabil și executabil, păstrează o bună imagine de ansamblu asupra stării proiectelor și au parte de mai puțin stres. A fi competent din punct de vedere tehnic în domeniul CI, încă de la început, este o cerință de bază pentru implementarea cu succes a acestei strategii. Eficiența infrastructurii CI hardware și software influențează nivelul de acceptare din partea dezvoltatorilor și, în cele din urmă, succesul sistemului.
Despre autorul articolului: Matthias Scheid este inginer de sistem la iSYSTEM. După ce a studiat informatică tehnică la OTH Regensburg, în calitate de inginer software, a dezvoltat module software asociate unui hardware în care erau prevăzute cerințe de siguranță funcțională pentru diverse arhitecturi de procesoare. La iSYSTEM, Matthias Scheid se ocupă de soluții de tracing bazat pe hardware, AUTOSAR, integrare continuă și testare.
