Při návrhu firmwaru postupujeme v pěti krocích

V posledních letech jsme věnovali značný čas konzultacím a školení týmů vývoje softwaru. Také jsme hráli zásadní roli při vývoji firmwaru pro úspěšné a trvalé produkty a produktové řady.

Zvládnutí tvorby robustní architektury firmwaru a souběžné přepracování staršího softwaru může být náročný a časově náročný proces.

Tuto cestu jsme však zefektivnili do pěti odlišných kroků, které slouží jako základ, který povede náš tým ke správnému začátku.

Krok 1: Určete potřebné specifikace.

Jasné požadavky jsou zásadní před zahájením architektonického návrhu vestavěného systému nebo jeho firmwaru. Přesně definované požadavky nastiňují nezbytné vlastnosti a kvality produktu.

Co produkt uživateli nabízí? Je nezbytné poznamenat, že dobře vytvořený požadavek se soustředí na „co“ a vyhýbá se podrobnostem o „jak“ dosáhnout konkrétní funkce v širším kontextu.

Každé prohlášení o požadavcích by mělo být jasné a testovatelné, aby bylo zajištěno, že je snadno pochopitelné a ověřitelné. Jasné prohlášení je stručné a jednoduché, nevyžaduje žádné další vysvětlení.

Klíčovým prvkem je testovatelnost. Dobře napsaný požadavek umožňuje snadné vytvoření kolekce testů k ověření, zda byl požadavek splněn.

Kompletní soubor požadavků se skládá z písemných prohlášení, která začínají klíčovou frází „[produkt] by měl ...“.

Tato prohlášení se vyhýbají specifikaci podrobností o implementaci a zajišťují, že zůstanou jasná, jednoznačná a testovatelná. Výsledkem je, že robustní architektura závisí na požadavcích, které jsou dobře definované.

Krok 2: Rozlišujte mezi architekturou a designem

Postupem času jsme pozorovali, že mnoho inženýrů a jejich manažerů se snaží rozlišovat mezi různými komponentami nebo úrovněmi inženýrství firmwaru.

Architektura systému je nejvyšší vrstvou funkčnosti produktu. Tato vrstva definuje dlouhotrvající vlastnosti, takže je obtížné ji změnit. V důsledku toho je důležité důkladně posoudit cílené a schválené účely produktu.

Návrh systému slouží jako mezivrstva implementace. Je důležité poznamenat, že architektura nezahrnuje specifika názvů funkcí nebo proměnných. Tyto podrobnosti jsou zdokumentovány v dokumentu návrhu firmwaru.

Příklady těchto podrobností zahrnují názvy úloh a související odpovědnosti v určených subsystémech nebo ovladačích zařízení, vybranou značku RTOS (pokud je to možné) a specifikace rozhraní mezi subsystémy.

Implementace je nejpodrobnější fází procesu. Jasná rozhraní vytvořená během fáze návrhu umožňují inženýrům souběžně provádět jednotlivé součásti.

Význam těchto výzev se může v různých odvětvích lišit, ale neustále zahrnují tři zásadní překážky, které vyžadují pečlivou pozornost: dodržování přísných termínů, provádění důkladného testování a efektivní řízení rozmanitosti. Řešení těchto problémů představuje poslední tři kroky.

Krok 3: Time Management

Specifikace produktu budou zahrnovat časové rámce. Produkty obvykle obsahují kombinaci požadavků, které nejsou v reálném čase, v měkkém reálném čase a v tvrdém reálném čase.

Stanovení měkkých termínů může být často náročné. Jakmile jsou stanoveny termíny, je prvním krokem převedení co největšího počtu požadavků na včasnost ze softwaru na hardware.

Zachování jasného rozlišení mezi funkčností v reálném čase a zbytkem softwaru má velkou hodnotu ze dvou důvodů. Zaprvé zjednodušuje návrh a implementaci softwaru, který není v reálném čase.

Oddělení požadavků na včasnost od hlavního těla softwaru umožňuje méně zkušeným implementátorům vytvořit kód, který neohrozí bezpečnost uživatelů.

Kombinace funkcí v reálném čase také zjednodušuje analýzu potřebnou k prokázání dodržování termínů.

Krok 4: Design orientovaný na test

Testování je klíčové pro každý vestavěný systém. Provádění testování na více úrovních je povinné a velmi důležité. Mezi hlavní úrovně testování patří:

1. Systémové testy ověřují, zda produkt splňuje nebo překračuje stanovené požadavky. Testy by měly být obvykle vyvíjeny mimo technické oddělení, ale mohou být také integrovány do testovacího svazku vytvořeného inženýry.

2. Integrační testy ověřují, že specifikovaná skupina subsystémů, jak je definována v architektonických diagramech, přesně interaguje a vytváří smysluplné výsledky. Nejúčinnější přístup k vývoji integračních testů je obvykle veden testovacím týmem nebo odborníkem na softwarové inženýrství.

3. Testy jednotek potvrzují, že určené softwarové komponenty, specifikované v přechodném návrhu, fungují tak, jak bylo zamýšleno vývojářem.

Unit testy hodnotí veřejné API (Application Programming Interface), které komponenta představuje ostatním prvkům. Vývojáři by měli v ideálním případě vytvářet testy jednotek pro svůj vlastní kód, aby maximalizovali jejich efektivitu.

Z těchto tří jsou systémové testy obvykle nejjednodušší na vývoj. Technický nebo tovární přejímací test může vyžadovat vytvoření testovacího svazku, ale to je obecně méně složité než integrační a jednotkové testy, které vyžadují hlubší pochopení vnitřních operací zařízení.

Pro zjednodušení vývoje, používání a údržby integračních a jednotkových testů je výhodné strukturovat firmware v souladu s rámcem testování softwaru. Optimální strategií je navrhnout komunikaci mezi všemi softwarovými prvky na úrovních, které mají být testovány.

Krok 5: Připravte se na změnu

Během fáze architektury firmwaru je zásadní upřednostnit zpracování rozmanitosti funkcí a přizpůsobení produktů. Chcete-li se připravit na potenciální změny, je nezbytné porozumět typům změn, ke kterým může dojít ve vašem konkrétním produktu.

Strukturujte firmware způsobem, který zjednoduší implementaci těchto změn. S vhodnou softwarovou architekturou lze dosáhnout rozmanitosti funkcí prostřednictvím jediného sestavení softwaru, které využívá přepínače chování při kompilaci a/nebo běhu ve firmwaru.

Podobně silnější architektura usnadňuje integraci nových funkcí hladce, aniž by byla ohrožena funkčnost produktu.