Projektując oprogramowanie sprzętowe, kierujemy się pięcioetapowym procesem

W ostatnich latach spędziliśmy dużo czasu na doradztwie i szkoleniu zespołów tworzących oprogramowanie. Odegraliśmy także zasadniczą rolę w opracowywaniu oprogramowania sprzętowego dla udanych i trwałych produktów i linii produktów.

Opanowanie tworzenia solidnej architektury oprogramowania sprzętowego i jednoczesne przeprojektowanie starszego oprogramowania może być trudnym i czasochłonnym procesem.

Jednakże usprawniliśmy tę podróż w pięciu odrębnych krokach, co stanowi podstawę do poprowadzenia naszego zespołu na dobry start.

Krok 1: Określ niezbędne specyfikacje.

Jasne wymagania są kluczowe przed rozpoczęciem projektowania architektury systemu wbudowanego lub jego oprogramowania sprzętowego. Precyzyjnie określone wymagania określają niezbędne atrybuty i cechy produktu.

Co produkt oferuje użytkownikowi? Należy zauważyć, że dobrze sformułowane wymaganie koncentruje się na „co”, unikając szczegółów dotyczących „jak” osiągnąć określoną funkcję w szerszym kontekście.

Każde oświadczenie wymagań powinno charakteryzować się przejrzystością i testowalnością, aby było łatwe do zrozumienia i sprawdzenia. Jasne oświadczenie jest zwięzłe i proste i nie wymaga dalszych wyjaśnień.

Kluczowym elementem jest testowalność. Dobrze napisane wymaganie pozwala na łatwe utworzenie zbioru testów w celu sprawdzenia, czy wymaganie zostało spełnione.

Kompletny zestaw wymagań składa się z pisemnych stwierdzeń rozpoczynających się od frazy kluczowej „[produkt] powinien…”.

W stwierdzeniach tych unika się określania szczegółów implementacji, zapewniając, że pozostają one jasne, jednoznaczne i możliwe do przetestowania. W rezultacie solidna architektura zależy od dobrze zdefiniowanych wymagań.

Krok 2: Odróżnij architekturę od designu

Z biegiem czasu zaobserwowaliśmy, że wielu inżynierów i ich menedżerów ma trudności z rozróżnieniem różnych komponentów lub poziomów inżynierii oprogramowania sprzętowego.

Architektura systemu jest wierzchnią warstwą funkcjonalności produktu. Warstwa ta określa długotrwałe cechy, przez co trudno je zmienić. W rezultacie ważne jest, aby dokładnie ocenić docelowe i zatwierdzone cele produktu.

Projekt systemu stanowi warstwę pośrednią wdrożeniową. Należy zauważyć, że architektura nie uwzględnia specyfiki nazw funkcji ani zmiennych. Szczegóły te są udokumentowane w dokumencie projektu oprogramowania sprzętowego.

Przykłady tych szczegółów obejmują nazwy zadań i powiązane obowiązki w wyznaczonych podsystemach lub sterownikach urządzeń, wybraną markę RTOS (jeśli ma to zastosowanie) oraz specyfikacje interfejsów między podsystemami.

Wdrożenie jest najbardziej szczegółowym etapem procesu. Przejrzyste interfejsy opracowane na etapie projektowania umożliwiają inżynierom jednoczesne wykonywanie poszczególnych części składowych.

Znaczenie tych wyzwań może być różne w różnych branżach, ale konsekwentnie wiążą się z trzema kluczowymi przeszkodami, które wymagają szczególnej uwagi: dotrzymywaniem napiętych terminów, przeprowadzaniem dokładnych testów i skutecznym zarządzaniem różnorodnością. Rozwiązanie tych problemów to trzy ostatnie kroki.

Krok 3: Zarządzanie czasem

Specyfikacje produktu będą zawierać ramy czasowe. Zazwyczaj produkty mają mieszankę wymagań czasu nierzeczywistego, czasu rzeczywistego miękkiego i czasu rzeczywistego trudnego.

Ustalenie miękkich terminów często może stanowić wyzwanie. Po ustaleniu terminów pierwszym krokiem jest przeniesienie jak największej liczby wymagań dotyczących terminowości z oprogramowania na sprzęt.

Utrzymanie wyraźnego rozróżnienia między funkcjonalnością czasu rzeczywistego a resztą oprogramowania ma wielką wartość z dwóch powodów. Po pierwsze, upraszcza projektowanie i wdrażanie oprogramowania działającego nie w czasie rzeczywistym.

Oddzielenie wymagań dotyczących aktualności od głównego oprogramowania umożliwia mniej doświadczonym wdrażającym tworzenie kodu, który nie będzie zagrażał bezpieczeństwu użytkownika.

Połączenie funkcjonalności czasu rzeczywistego upraszcza także analizę wymaganą do wykazania dotrzymania terminów.

Krok 4: Projektowanie zorientowane na testy

Testowanie ma kluczowe znaczenie dla każdego systemu wbudowanego. Przeprowadzanie testów na wielu poziomach jest obowiązkowe i bardzo ważne. Główne poziomy testowania obejmują:

1. Testy systemowe sprawdzają, czy produkt spełnia lub przekracza określone wymagania. Zazwyczaj testy powinny być opracowywane poza działem inżynieryjnym, ale można je również zintegrować z wiązką testową stworzoną przez inżynierów.

2. Testy integracyjne weryfikują, czy określona grupa podsystemów, zgodnie z definicją na diagramach architektonicznych, dokładnie współdziała, dając znaczące wyniki. Najbardziej efektywne podejście do opracowywania testów integracyjnych jest zwykle prowadzone przez zespół testowy lub eksperta w dziedzinie inżynierii oprogramowania.

3. Testy jednostkowe potwierdzają, że wyznaczone komponenty oprogramowania, określone w projekcie pośrednim, działają zgodnie z zamierzeniami programisty.

Testy jednostkowe oceniają publiczny interfejs API (interfejs programowania aplikacji), który komponent prezentuje innym elementom. W idealnym przypadku programiści powinni stworzyć testy jednostkowe dla własnego kodu, aby zmaksymalizować ich skuteczność.

Spośród tych trzech testy systemowe są zazwyczaj najłatwiejsze do opracowania. Test odbiorczy inżynieryjny lub fabryczny może wymagać stworzenia wiązki testowej, ale jest to generalnie mniej skomplikowane niż testy integracyjne i jednostkowe, które wymagają głębszego zrozumienia wewnętrznych operacji urządzenia.

Aby uprościć tworzenie, używanie i konserwację testów integracyjnych i jednostkowych, korzystne jest ustrukturyzowanie oprogramowania sprzętowego zgodnie ze strukturą testowania oprogramowania. Optymalną strategią jest zaprojektowanie komunikacji pomiędzy wszystkimi elementami oprogramowania na poziomach, które mają być testowane.

Krok 5: Przygotuj się na zmianę

Na etapie architektury oprogramowania sprzętowego niezwykle ważne jest nadanie priorytetu obsłudze różnorodności funkcji i dostosowywaniu produktu. Aby przygotować się na potencjalne zmiany, konieczne jest zrozumienie rodzajów zmian, które mogą wystąpić w konkretnym produkcie.

Zbuduj oprogramowanie sprzętowe w sposób ułatwiający wdrażanie tych zmian. Przy odpowiedniej architekturze oprogramowania różnorodność funkcji obsługi można osiągnąć poprzez pojedynczą kompilację oprogramowania, która wykorzystuje przełączniki zachowań w czasie kompilacji i/lub działania w oprogramowaniu sprzętowym.

Podobnie silniejsza architektura ułatwia płynną integrację nowych funkcji bez pogarszania funkcjonalności produktu.