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

În ultimii câțiva ani, am desfășurat consultări și instruire extinse cu echipele de dezvoltare de software, în timp ce dezvoltăm firmware pentru produse și familii de produse de succes și de lungă durată. În timp ce crearea unei arhitecturi solide de firmware și re-arhitectarea software-ului moștenit poate fi un proces complex de luni de zile, am identificat cinci pași cheie care formează o abordare pas cu pas, permițând echipei noastre să înceapă pe drumul cel bun.

Pasul 1: Definiți cerințele

Înainte ca un sistem încorporat sau firmware-ul acestuia să poată fi proiectat, 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ță să fie clară și testabilă. O afirmație lipsită de ambiguitate este clară și concisă și nu necesită explicații suplimentare.

Testabilitatea este un factor cheie; o cerință bine scrisă ar trebui să permită crearea simplă a testului pentru a verifica îndeplinirea acestuia. 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 claritatea și testabilitatea. În consecință, arhitectura eficientă se bazează pe cerințe bine definite.

Pasul 2: Faceți diferența între arhitectură și design

Experiența noastră a fost că mulți ingineri și managerii lor întâmpină dificultăți în a distinge diferitele aspecte ale ingineriei firmware. Arhitectura sistemului reprezintă cel mai înalt nivel de CUM, definind caracteristicile de durată ale produsului și făcându-l dificil de modificat odată stabilit. Este nevoie de o analiză atentă a utilizărilor prevăzute și permise ale produsului pentru a se asigura că este făcut corect.

Proiectarea unui sistem reprezintă stratul intermediar al modului. În timp ce arhitectura conturează caracteristicile generale, nu specifică funcții sau nume de variabile. Un document de proiectare a firmware-ului completează aceste detalii, inclusiv numele sarcinilor și responsabilitățile în cadrul anumitor subsisteme sau drivere de dispozitiv, RTOS utilizat (dacă există) și specificul interfețelor dintre subsisteme.

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

Pasul 3: Managementul 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, soft-real-time și hard-time-real-time. Dintre acestea, termenele limită sunt adesea cele mai dificile de definit, de testat și de implementat. Odată ce termenele sunt identificate, pasul inițial în procesul de arhitectură este de a descărca 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 cea mai mare parte a 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 asigurarea respectării consecvente a tuturor termenelor limită.

Pasul 4: Proiectați ținând cont de testare

Este esențial să testați fiecare sistem încorporat la mai multe niveluri. În multe cazuri, testarea la diferite niveluri este nu numai valoroasă, ci și obligatorie.

Cele mai comune niveluri de testare includ

1. Testele sistemului 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 cablaj de testare proiectat de ingineri.

2. Testele de integrare sunt efectuate pentru a se asigura că subseturile de subsisteme, 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 prevederilor. Aceste teste se concentrează pe API-ul public (Application Programming Interface) pe care componenta o 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 simplu de dezvoltat. Un cablaj de testare poate fi necesar pentru testele de inginerie și de acceptare din fabrică, dar acest proces este în general mai simplu decât testele de integrare și unitate, care necesită mai multă vizibilitate internă 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 de a structura interacțiunile dintre toate componentele software la nivelurile pe care intenționați să le testați.

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

În timpul fazei 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 schimbarea, este esențial să identificați mai întâi tipurile de schimbări care pot apărea în produsul dvs. Apoi, firmware-ul ar trebui să fie 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ă construcție cu comutatoare în timp de compilare și/sau timp de execuție, permițând în același timp adăugarea fără întreruperi de noi funcții fără a perturba funcționalitatea existentă.