Podstawy Systemów Wbudowanych

Systemy wbudowane (inaczej systemy embedded) to urządzenia zawierające w sobie mikroprocesor, które posiadają dedykowane oprogramowanie ściśle związane ze sprzętem (rodzajem procesora, komponentami na płytce PCB, sensorami itd). System wbudowany tworzony jest w celu sterowania konkretnym urządzeniem.

System Wbudowany to Hardware + szyty dla niego na miarę Software.

Razem mają realizować konkretną, bardzo specyficzną funkcjonalność.

Przykłady urządzeń zawierających w sobie system wbudowany:

• Cyfrowe aparaty fotograficzne
• Wszystko co jeździ w samochodzie
  • komputery pokładowe
  • radia samochodowe
  • panele klimatyzacji
  • przełączniki świateł
  • … i wiele więcej
• Komponenty stosowane w samolotach
• Smart-zegarki
• Drony
• Rakiety ziemia-powietrze
• Bankomaty
• Telefony komórkowe i systemy łączności
• Konsole do gier
• Pralki, zmywarki, lodówki (sterowanie komponentami)
• Drukarki
• Sprzęt medyczny
• Urządzenia sieciowe (routery, switche)
• Odbiorniki GPS
• …. wiele, wiele, wiele innych.

Projektowanie systemów wbudowanych

Projektowanie owych jest procesem szycia na miarę sprzętu i oprogramowania. Kluczowe jest zapewnienie oprogramowaniu wszystkich niezbędnych zasobów sprzętowych, jak również optymalizacja. Często programiści są mocno ograniczeni dostępnymi zasobami i muszą kombinować jak się zmieścić w wyznaczonych ramach, jak zoptymalizować kod tak, aby zachować wymagane czasy działania itd.

Przy wolumenie urządzeń idącym powyżej setek tysięcy, ważna jest radykalna optymalizacja zasobów sprzętowych urządzenia

Tylko tyle i aż tyle. Jeżeli kod da się napisać tak, żeby zamiast procesora wartego $10 dolarów użyć takiego za $8 dolarów, nikt się nie będzie dwa razy zastanawiał. Będą to setki tysięcy dolarów zaoszczędzone na jednym tylko komponencie.

Im wyższy wolumen oraz im niższa marża, tym większe pojawia się ciśnienie na optymalizację. Niejednokrotnie zdarza się, że w trakcie życia produktu dokonuje się zmiany pojedynczego komponentu (czujnika, kondensatora, układu scalonego). Wiąże się to z jednej strony z ogromnymi kosztami (np. drobna zmiana w kodzie aby obsłużyć nowy rodzaj czujnika + testy + walidacja). Mimo wszystko oszczędność kilkudziesięciu centów na sztuce sprawia, że jest to logiczne biznesowo.

Programowanie Systemów wbudowanych

Nie ma co owijać w bawełnę:

Programowanie systemów wbudowanych odbywa się najczęściej w języku C.

Do tego w C niskopoziomowym istotna jest znajomość przerwań, rejestrów, stosów, timerów, protokołów komunikacyjnych, jak również podstaw elektroniki – aby wiedzieć czym się różni pamięć flash od eepromu.

Co do samych języków – bywają wyjątki, takie jak programowanie w C++ (często aplikacji wyższego poziomu abstrakcji, takich jak obsługa interfejsów graficznych), lub microPython. Ten ostatni jest jednak pewną egzotyką ze względu na sprzeczność: python w zamyśle jest prostym językiem do szybkiego tworzenia działającego kodu bez kładzenia nacisku na optymalizację zasobów, czasu egzekucji programu itd. Jak wiemy, w systemach wbudowanych jest odwrotnie: możemy długo pracować nad oprogramowaniem, jednak docelowo ma ono działać sprawnie przy wykorzystaniu minimalnej niezbędnej ilości zasobów.

Testowanie Systemów Wbudowanych

Pytanie: Czy testowanie Systemów Wbudowanych różni się od zwykłego testowania, np. aplikacji webowych?

Odpowiedź: jak jasna cholera.

Przez to, że systemy embedded to połączenie HW i SW, ich testowanie jest bardzo specyficzne. Funkcje zawarte w oprogramowaniu zarówno mają wpływ na zachowanie sprzętu, jak również od niego bezpośrednio zależą.

Bugi mogą występować na pograniczu HW i SW i niejednokrotnie zrozumienie działania obu tych dziedzin jest konieczne do znalezienia przyczyny błędu, lub zasymulowania odpowiednich testów aby przetestować odporność systemu.

Dla przykładu:

Przygotowywałem kiedyś test sprawdzający scenariusz – jak się zachowa urządzenie jeśli przy jego start-upie (uruchomienie programu po podaniu zasilania) nie będzie w stanie odczytać danych kalibracyjnych z pamięci?

Był to istotny scenariusz, ponieważ pamięć znajdowała się na osobnym układzie scalonym z płytce PCB, zaś mikrokontroler komunikował się z nim za pomocą interfejsu i²c. Test typu fault-injection (wstrzyknięcie błędu) polegał na podlutowaniu przewodu w odpowiednim miejscu na płytce PCB, tam gdzie przebiegała jedna z linii komunikacyjnych i²c i zwierania jej w odpowiednich momentach przez przekaźnik do masy.

Black box, white box

Testy systemów wbudowanych możemy podzielić zasadniczo na dwie grupy:

Black box

Testy czarnoskrzynkowe. Oznacza to, że traktujemy wnętrze systemu jako niewiadomą. Nie mamy dostępu do aktualnych wartości zmiennych używanych w oprogramowaniu oraz nie możemy określić występowania żadnych zdarzeń wewnętrznych (jak przerwania procesora).

Bierzemy wtedy taki moduł, dostarczamy coś na jego wejście (zasilanie, sygnały z czujników, dostarczone dane po protokołach) i obserwujemy to, co pojawia się na jego wyjściu (stany wyjść cyfrowych i analogowych, wiadomości wychodzące na interfejsach komunikacyjnych, itd.)

To, co się dzieje w środku jest dla nas nie istotne

White box

W testowaniu białoskrzynkowym rzecz się ma zupełnie inaczej. “Pudełko” jest otwarte, a my mamy dostęp do wszystkiego, co się w nim znajduje. Możemy nie tylko na bieżąco w trakcie trwania testu odczytywać wartości zmiennych i obserwować występowanie zdarzeń, ale również możemy te zdarzenia i zmienne stymulować – czyli wymuszać ustawiania ich konkretnych wartości.

Testy takie są niezbędne przy testowaniu scenariuszy, których nie możemy, lub nie chcemy fizycznie zaimplementować, np. spalenie komponentu lub przegrzanie się go powyżej określonej temperatury. Zamiast doprowadzać komponent do zniszczenia, do zmiennej liczbowej przechowującej wartość odczytu z czujnika temperatury wpisujemy “z palca” zawyżoną wartość, obserwując jak zachowa się wtedy system.

Grey box

Dla przyzwoitości wspomnę o trzecim podejściu – szaroskrzynkowe. Jak można się domyślić, jest to połączenie obu tych metodologii, to znaczy tester ma niepełną wiedzę o systemie. W mojej praktyce jednak nie spotkałem się z potrzebą zastosowania takiego podejścia. Jeśli używałeś tej metodologii – proszę podziel się tym ze mną w komentarzu!