Procesul nostru de dezvoltare a firmware-ului se bazează pe o abordare în cinci pași

În ultimii ani, am desfășurat consultări și instruiri ample cu echipele de dezvoltare software, dezvoltând firmware pentru produse și familii de produse de succes și durabile. Deși crearea unei arhitecturi firmware robuste și rearhitectura software-ului vechi poate fi un proces complex, care durează luni de zile, am identificat cinci etape cheie care formează o abordare pas cu pas, permițând echipei noastre să pornească pe drumul cel bun.

Pasul 1: Definiți cerințele

Înainte de a putea fi proiectat un sistem integrat sau firmware-ul său, sunt esențiale cerințe clare. Cerințele bine definite specifică ce va face produsul pentru utilizator, fără a detalia modul în care vor fi atinse aceste obiective. Este esențial ca fiecare declarație de cerințe să fie lipsită de ambiguitate și testabilă. O declarație lipsită de ambiguitate este clară și concisă, nenecesitând explicații suplimentare.

Testabilitatea este un factor cheie; o cerință bine scrisă ar trebui să permită crearea simplă a testelor pentru a verifica îndeplinirea acestora. Un set adecvat de cerințe constă în declarații care încep cu „[produsul] ar trebui ...”, concentrându-se pe ceea ce este necesar mai degrabă decât pe modul în care este realizat și asigurând claritate și testabilitate. Prin urmare, o arhitectură eficientă se bazează pe cerințe bine definite.

Pasul 2: Diferențierea dintre arhitectură și design

Experiența noastră a arătat că mulți ingineri și managerii lor au dificultăți în a distinge între diversele aspecte ale ingineriei firmware-ului. Arhitectura sistemului reprezintă cel mai înalt nivel al modului de realizare (CUM), definind caracteristicile durabile ale produsului și făcând dificilă modificarea acestuia odată stabilit. Aceasta necesită o analiză atentă a utilizărilor prevăzute și permise ale produsului pentru a se asigura că este realizată corect.

Designul unui sistem reprezintă stratul intermediar al modului în care funcționează. Deși arhitectura prezintă caracteristicile generale, aceasta nu specifică numele funcțiilor sau variabilelor. Un document de proiectare a firmware-ului completează aceste detalii, inclusiv numele sarcinilor și responsabilitățile din cadrul subsistemelor sau driverelor de dispozitiv specifice, RTOS-ul utilizat (dacă există) și specificul interfețelor dintre subsisteme.

Faza de implementare reprezintă cel mai scăzut nivel al ierarhiei managementului de proiect. Atunci când interfețele sunt clar definite în etapa de proiectare, inginerii pot începe implementarea diferitelor componente în paralel. Deși provocările pot varia în funcție de industrie, acestea se încadrează de obicei în trei categorii principale: respectarea termenelor limită în timp real, testarea și gestionarea diversității. Aceste probleme sunt abordate în ultimii trei pași.

Pasul 3: Gestionarea timpului

Unele cerințe de produs vor specifica constrângeri de timp explicite. De obicei, produsele includ o combinație de cerințe non-real-time, soft-real-time și hard-real-time. Dintre acestea, termenele limită soft sunt adesea cele mai dificil de definit clar, testat și implementat. Odată ce termenele limită sunt identificate, pasul inițial în procesul arhitectural este de a transfera cât mai multe cerințe sensibile la timp de la software la hardware.

Separarea funcționalității în timp real de software-ul principal oferă două beneficii cheie. În primul rând, simplifică proiectarea și implementarea software-ului care nu este în timp real. Prin eliminarea constrângerilor de timp din partea majorității codului, chiar și dezvoltatorii începători pot contribui fără a compromite siguranța utilizatorilor. În al doilea rând, consolidarea funcționalității în timp real facilitează analiza și asigură respectarea constantă a tuturor termenelor limită.

Pasul 4: Proiectarea având în minte testarea

Este esențial să se testeze fiecare sistem integrat la mai multe niveluri. În multe cazuri, testarea la diferite niveluri nu este doar valoroasă, ci și obligatorie.

Cele mai comune niveluri de testare includ

1. Testele de sistem au confirmat că produsul, în ansamblu, îndeplinește sau depășește cerințele specificate. Se recomandă ca aceste teste să fie dezvoltate în afara departamentului de inginerie, deși pot fi încorporate într-un sistem de testare proiectat de ingineri.

2. Testele de integrare sunt efectuate pentru a se asigura că subseturile subsistemelor, așa cum sunt prezentate în diagramele de arhitectură, interacționează corect și produc rezultatele așteptate. Aceste teste sunt de obicei dezvoltate de o echipă de testare sau de o persoană din cadrul departamentului de inginerie software.

3. Testele unitare garantează că componentele software individuale, așa cum sunt definite în etapa intermediară de proiectare, funcționează conform așteptărilor. Aceste teste se concentrează pe API-ul public (Application Programming Interface) pe care componenta îl oferă altor componente. De obicei, testele unitare sunt dezvoltate de aceleași persoane care scriu codul testat.

Dintre cele trei tipuri de teste, testele de sistem sunt cele mai simple de dezvoltat. Un sistem de testare poate fi necesar pentru testele de inginerie și de acceptare în fabrică, dar acest proces este în general mai simplu decât testele de integrare și cele unitare, care necesită o vizibilitate internă mai mare asupra funcționării dispozitivului. Pentru a eficientiza dezvoltarea, utilizarea și întreținerea testelor de integrare și unitare, este recomandabil să proiectați firmware-ul într-un mod care să se alinieze cu un cadru de testare software. Cea mai eficientă abordare este structurarea interacțiunilor dintre toate componentele software la nivelurile pe care intenționați să le testați.

Pasul 5: Pregătiți-vă pentru schimbare

În faza de arhitectură a firmware-ului, este esențial să se acorde prioritate gestionării diversității caracteristicilor și personalizărilor produsului. Pentru a planifica eficient schimbările, este crucial să se identifice mai întâi tipurile de modificări care sunt susceptibile de a apărea în produsul dumneavoastră. Apoi, firmware-ul ar trebui proiectat pentru a se adapta acestor modificări în cel mai eficient mod posibil. O arhitectură bine concepută permite gestionarea diversității caracteristicilor printr-o singură compilare cu comutatoare la compilare și/sau la rulare, permițând în același timp adăugarea fără probleme de noi caracteristici fără a perturba funcționalitatea existentă.