Debuggowanie systemów embedded – strategie i narzędzia
| TechnikaKażdego roku magazyn Embedded System Design odnotowuje w corocznym przeglądzie duże zapotrzebowanie na narzędzia debugujące. Liczba respondentów domagających się ich ulepszenia kształtuje się od trzech lat na stałym poziomie wynoszącym około 32%. Pewną ciekawostką jest to, że zapotrzebowanie na zmiany w zakresie narzędzi programistycznych zmniejszyło się z 25% do 10%. Odpowiedzi na pytanie, dlaczego tak się dzieje, nie trzeba długo szukać – ci sami respondenci przyznają, że faza testowania i wyszukiwania błędów w projekcie pochłania 24% czasu. Przy okazji daje się zauważyć, że obecnie stosowane narzędzia do zarządzania projektami przestają być wystarczające.
Jednym z najważniejszych aspektów pracy inżyniera jest stworzenie urządzenia o wymaganej funkcjonalności, rozwiązującego konkretny problem, np. sterującego pracą innego układu lub odpowiadającego za pomiar określonej wielkości fizycznej. O ile narzędzia programistyczne pozwalają efektywnie rozwiązywać problemy, przed jakimi stają zespoły inżynierów zajmujących się oprogramowaniem, nie można tego powiedzieć o narzędziach debugujących, co pokazują oczekiwania projektantów domagających się ich dalszego rozwoju. Przestają one być prostym uzupełnieniem środowiska programistycznego, a ich rola zaczyna znacznie wykraczać poza wyszukiwanie błędów w kodzie i eliminowanie pomyłek programistów.
Dobrze przygotowane oprogramowanie nie zapewnia automatycznie poprawnej pracy całego urządzenia. Błędy mogą wynikać np. ze specyficznych warunków pracy i są niemożliwe do znalezienia tylko za pomocą programistycznych narzędzi debugujących, zwłaszcza w systemach embedded. Wykorzystywane powszechnie symulatory również mogą nie ujawniać takich zjawisk, jak ograniczona wydajność mikroprocesora, błędy powstające w czasie wymiany danych z innymi modułami, opóźnienia poszczególnych elementów czy kwestie związane z zarządzaniem poborem energii. Na pracę układu mają wpływ także niemożliwe do zasymulowania zaburzenia elektromagnetyczne. Trudno jest uwzględnić wszystkie czynniki, mając do dyspozycji skończoną liczbę scenariuszy.
Gdyby proces debugowania wymagał jedynie znalezienia i poprawienia błędów w oprogramowaniu, to symulatory umożliwiające śledzenie wykonania poszczególnych instrukcji byłyby wystarczające. Pozwalają one zatrzymanie symulacji w dowolnym momencie i dokładne zapoznanie się ze stanem rejestrów i pamięci mikroprocesora. Zapewnia to wystarczający wgląd w pracę mikroprocesora i umożliwia wyszukanie wszystkich nieprawidłowości (np. błędów logicznych). Symulatory są dostępne dla większości obecnie produkowanych mikroprocesorów. Niestety, wykazanie wszystkich zależności występujących w kompletnym systemie nie jest możliwe. Co więcej, rozszerzanie symulacji o kolejne zjawiska, takie jak opóźnienie pamięci, interakcje z urządzeniami peryferyjnymi i czujnikami czy układami wykonawczymi zwiększa złożoność symulatora i znacznie go spowalnia.
Rozwiązania pochodzące od takich firm, jak VAST (Virtual-System-Prototype Tool) czy Virtutech (Simics virtual platform – rysunek 1), stanowią rozwinięcie tradycyjnej symulacji. Wśród dostarczanych narzędzi znajduje się moduł przetwarzania instrukcji mikroprocesora oraz symulator umożliwiający badanie interakcji pomiędzy różnymi elementami systemu. Umożliwia to tworzenie oprogramowania przed wykonaniem prototypu i pozwala programistom uczestniczyć w pracach nad zapewnieniem integralności całego systemu.
Interesującą opcją jest testowanie układu poprzez wprowadzanie celowych błędów do systemu (fault injection). Narzędzia takie pozwalają na konstruowanie modelu projektowanego urządzenia ze specjalnie przygotowanych bloków funkcyjnych, a następnie jego badanie. Instalacja dodatkowych rozszerzeń jeszcze bardziej zwiększa atrakcyjność takich rozwiązań, gdyż umożliwia tworzenie własnych komponentów. Narzędzia dostarczone przez obie firmy można traktować jako symulatory pracujące w pętli sprzętowej (HILS – patrz ramka). Ich największą wadą jest koszt, który może przekraczać kilka tysięcy USD.
Systemy operacyjne
W ostatniej dekadzie dało się zauważyć mniejsze zainteresowanie systemami operacyjnymi wymagającymi zakupu licencji, na rzecz darmowych rozwiązań, takich jak Linux. Zamiana systemów komercyjnych na systemy darmowe z otwartym kodem źródłowym pozwala uzyskać spore oszczędności. Podobne tendencje są widoczne w przypadku narzędzi programistycznych dla systemów wbudowanych, które coraz częściej bazują na silniku darmowego pakietu Eclipse. Obok mniejszych kosztów pozwala to uprościć narzędzia konfiguracyjne stosowane przez końcowych użytkowników. Eliminuje też konieczność tworzenia wielu aplikacji od podstaw, gdyż są one już obecne w zapożyczonym kodzie środowiska Eclipse. Analogiczne cięcia kosztów są trudniejsze w przypadku narzędzi debugujących, ale nie oznacza to, że ich ceny nie ulegają obniżeniu. Wielu producentów dostarcza małe zestawy ewaluacyjne w cenie poniżej 100 USD, umożliwiające zapoznanie się z działaniem konkretnego elementu. Nietrudno jest też nabyć za kilkaset USD kity, które jeszcze dekadę temu kosztowały znacznie więcej.
Standardem staje się to, że architektura nowych mikroprocesorów umożliwia debugowanie na poziomie rdzenia. Obecność nowych funkcji przeznaczonych do śledzenia pracy jednostki centralnej powoduje zmniejszenie złożoności narzędzi sprzętowych i obniżenie ich ceny. Rozwiązania takie spotyka się nawet w przypadku prostych mikrokontrolerów 8-bitowych, czego przykładem mogą być popularne układy AVR firmy Atmel. Zaimplementowany w nich system debugowania jest jednym z najbardziej złożonych modułów obecnych w całym rdzeniu. Wynika to z konieczności bezinwazyjnego śledzenia pracy jednostki centralnej i wszystkich współpracujących modułów.
Paradoksalnie nie można usprawiedliwiać wzrostu ceny mikroprocesora obecnością modułu diagnostycznego, mimo jego niewątpliwej komplikacji. Wynika to z faktu, że funkcja ta nie jest wykorzystywana w końcowym produkcie, a jedynie przez producenta urządzenia na etapie testowania. Również mikroprocesory ARM wyposażone w funkcję ETM (Embedded-Trace Macrocell) wspierają projektantów w wyszukiwaniu błędów (m.in. Cortex-M3). Umożliwiają podgląd stanu mikroprocesora w trybie rzeczywistym (real-time trace). Daje to możliwość wykonywania instrukcji w odwróconej kolejności, podobnie jak w programach symulacyjnych. Po wystąpieniu błędu można więc w kolejnych krokach powrócić do jego źródła. Taki tryb wykonywania instrukcji udostępnia oprogramowanie Multi Time Machine (rys. 2) firmy Green Hills Software. Umożliwia przełączanie pomiędzy debugowaniem w systemie a pracą z symulatorem.
W związku z zapotrzebowaniem na ujednolicenie metod debugowania dla mikroprocesorów stosowanych w systemach embedded powstał standard IEEE-ISTO 5001-2003 opracowany przez Forum Nexus 5001 zrzeszające producentów półprzewodników, firmy tworzące narzędzia programistyczne i przedstawicieli przemysłu. Co prawda w pierwszej fazie było to rozwiązanie przeznaczone na użytek automatyki przemysłowej, ale ewoluowało do tego stopnia, że obecnie definiuje interfejs ogólnego przeznaczenia dla narzędzi programistycznych i debugujących. Co ciekawe, standard ten jest otwarty i możliwy do pobrania bezpłatnie ze strony Nexus 5001 Forum.
Spadek cen półprzewodników i upowszechnienie się interfejsów przeznaczonych do debugowania pozwoliły zaadaptować w „zwykłych” mikrokontrolerach rozwiązania pochodzące z zaawansowanych mikroprocesorów. W niektórych przypadkach zapewniają one znacznie lepszy wgląd w pracę mikroprocesora, niż miało to miejsce w pierwowzorze. Komplikacja współczesnych systemów wbudowanych sprawia, że takie rozwiązania są niezbędne do skutecznego i szybkiego postępu prac nad projektem.
Pakiety narzędziowe
Firma Virtutech dostarcza pakiet narzędziowy przeznaczony do symulacji całego systemu (rys. 3).
Koszt tego rozwiązania jest wyższy niż typowych symulatorów. Według zapewnień szefa zarządu firmy, zespoły projektantów po zapoznaniu się z możliwościami tego produktu w początkowej bądź końcowej fazie projektu zaczynają go stosować znacznie częściej. Pierwotne funkcje narzędzi debugujących, których celem było zapewnienie wglądu w działający system, okazują się nieraz niewystarczające. Układów zawierających złożone interfejsy komunikacyjne, czujniki czy elementy wykonawcze nie da się już w taki sposób przetestować. Wynika to z dużych trudności w wygenerowaniu odpowiednich sygnałów testowych dla wszystkich komponentów i wymaga stosowania rozwiązań bardziej kompleksowych.
Osobnym zagadnieniem jest testowanie systemów zawierających sprzężenie zwrotne, czyli takich, w których wyjścia oddziałują na wejścia. Określenie stanu systemu na podstawie symulacji jest utrudnione, bo nie zawsze znane są wszystkie parametry modelu symulacyjnego. W Internecie można odnaleźć przykłady opisujące takie problemy. Autor publikacji przedstawia swoje doświadczenia z kamerą do obserwacji nieba. Symulacja nie jest tu możliwa i konieczne staje się szukanie innych rozwiązań. W tym wypadku dobrze sprawdziły się praktyczne próby z kamerą oraz przygotowanym do tego celu programem. Zadanie polegało na określeniu, czy algorytm automatycznej regulacji wzmocnienia będzie pracował prawidłowo przy wymaganych założeniach. W czasie prób okazało się, że zachowanie kamery odbiega od oczekiwań. Dzięki temu można było wyznaczyć uprzednio nieznane charakterystyki oraz zapobiec stracie czasu i pieniędzy na projekt, który nie ma szans na prawidłowe funkcjonowanie.
Interakcja z otoczeniem
Cechą charakterystyczną systemów wbudowanych jest występowanie błędów, których nie powodują usterki w kodzie, lecz konflikty sprzętowe wynikające z zakłóceń, wzbudzeń czy zbyt dużych opóźnień. Są one często usuwane za pomocą „sztuczek” programowych, bo jest to efektywniejsze pod względem ekonomicznym i oszczędza czas projektantów. Wymaga to jednak znalezienia przyczyny nieprawidłowości.
Zespół odpowiadający za integralność systemu musi posiadać wszechstronną wiedzę obejmującą zagadnienia z zakresu programowania, sprzętu i specyfikacji projektu. Stworzenie takiego zespołu nie jest łatwe, gdyż ludzi z tak szeroką wiedzą jest niewielu. Lukę tę starają się wypełniać narzędzia debugujące, ale oferowany przez nie sposób wglądu w działanie systemu jest specyficzny i projektanci nie zawsze z niego korzystają. Ma w tym swój udział także zbyt duża liczba oferowanych funkcji i opcji, wymagająca odpowiedniej ilości czasu na zapoznanie się z nimi.
Duża presja czasu towarzysząca pracom nad nowymi produktami nie ułatwia tego zadania i wykorzystywane są głównie najprostsze możliwości narzędzi. Te bardziej zaawansowane są przyswajane dopiero stopniowo, w czasie realizacji kolejnych zadań. Problem ten zauważyła m.in. firma Green Hills Software, która dodała do swojego środowiska Multi Time Machine domyślne ustawienia pozwalające prowadzić testy w sposób optymalny bez konieczności zagłębiania się w tajniki konfiguracji. Przynosi to wymierne korzyści w postaci oszczędności czasu programistów.
| Szacowanie czasu wdrożenia projektu |
|
Dobrze przygotowana lista zadań do wykonania stanowi podstawę dobrej organizacji pracy. Jej przygotowanie nie jest łatwe, gdy czasu na opracowanie projektu jest mało i sprzyja to sprzedaży niekompletnego urządzenia. Wynika to z konieczności skupienia uwagi na najważniejszych założeniach i określenia absolutnie niezbędnych funkcji projektowanego urządzenia, bez których nie nadaje się ono do sprzedaży. Istnieją różne metody wspomagania pracy menedżerów podczas przygotowywania takiej listy zadań dla zespołu projektantów. Stanowi ona często kompromis pomiędzy walorami użytkowymi układu, kosztami oraz czasem niezbędnym do zakończenia pracy. Jedna z metod jest oparta o model Cocomo (constructive-cost model) będący algorytmem przeznaczonym do szacowania kosztów projektu. Wzory matematyczne wykorzystywane w Cocomo zostały opracowane na podstawie danych historycznych zebranych podczas realizacji różnorodnych projektów w przeszłości. Algorytm opublikował w roku 1981 inżynier oprogramowania Barry Boehm. Dostępny jest również rozszerzony model – Cocomo II, zawierający poprawki umożliwiające szacowanie oprócz kosztów także czasu pracy projektantów oraz wspomagający tworzenie listy zadań. Jest on dostępny na stronie internetowej Uniwersytetu Południowej Kalifornii [2]. Model Cocomo II uwzględnia kwestie związane z wymogami aplikacji, wczesnymi pracami projektowymi oraz architekturą, pozwalając w ten sposób zwiększyć dokładność szacunków związanych z rozwojem projektu. Algorytm ten bywa pomocny podczas planowania budżetu, przygotowania listy prac do wykonania, szacowania kosztów oprogramowania oraz pomaga lepiej ocenić ryzyko związane z zarządzaniem przedsięwzięciem. Ułatwia to znalezienie złotego środka pomiędzy jakością wykonania, funkcjonalnością i kosztami pracy. Algorytm bywa również pomocny podczas rozważania, jaką część oprogramowania zlecić do opracowania projektantom, jaką część kupić, a jaką wykorzystać ponownie. Grupa badawcza odpowiedzialna za model Cocomo II prowadzi dalsze prace mające na celu zwiększenie jakości i dokładności szacunków. Zbiera również dane statystyczne od różnych zespołów projektantów. Inną propozycję szacowania postępów nad projektem przedstawił Joel Spolsky. Przyjęty model bazuje na danych historycznych, ale uwzględnia też bieżące postępy nad projektem i włącza je do kolejnych analiz. Model znalazł zastosowanie w komercyjnym oprogramowaniu FogBugz, które pozwala menedżerom zarządzać projektem i szacować czas zakończenia prac nad nim. Ideą leżącą u podstaw tego modelu jest podział zadań realizowanych przez zespół na części mierzone czasem ich wykonania. Nie mogą być one dłuższe niż 16 godzin, aby umożliwić bieżące śledzenie postępów w pracy i wprowadzanie korekt. Po stworzeniu listy zadań i przypisaniu im czasu przeznaczonego na realizację możliwe staje się śledzenie aktualnych postępów i porównywanie ich z szacunkami (niezależnie dla każdego projektanta). Pojawia się tu jeszcze jedna korzyść oprócz bieżącego uaktualniania prognoz – metoda ta dostarcza danych niezbędnych do analizy statystycznej Monte Carlo. Dzięki temu możliwe staje się wyznaczenie przedziału czasu, w jakim projekt zostanie ukończony i ułatwia modyfikację zadań stawianych przed zespołem oraz określanie priorytetów w pracy. Co więcej, można sprawdzić w jaki sposób zmieni się termin zakończenia prac po dodaniu nowych lub usunięciu zbędnych funkcji urządzenia. |
Producenci zestawów ewaluacyjnych także zaczynają dostrzegać coraz większe obciążenie projektantów i podejmują stosowne kroki. Jest to między innymi możliwość zasilania przez port USB oraz wprowadzenie prostszych (lub bezprzewodowych) interfejsów komunikacyjnych wykorzystywanych do wymiany danych pomiędzy zestawem ewaluacyjnym i komputerem. W wielu przypadkach dostępne są programy demonstracyjne umożliwiające sprawdzenie, czy wszystkie podzespoły wchodzące w skład kitu pracują prawidłowo. Duże firmy, jak choćby Texas Instruments, dążą do opracowania narzędzi zbliżonych do platformy Intela, na której pracuje system Windows. Pozwoli to uczynić proces tworzenia oprogramowanie możliwie łatwym, intuicyjnym i szybkim w nauce.
Firma Micrium również wychodzi naprzeciw oczekiwaniom projektantów, zapewniając pomoc na etapie debugowania. Proponowane rozwiązanie mC/Probe umożliwia wizualizację stanu systemu. Jest złożone z dwóch części: oprogramowania dla komputera PC służącego do analizy i prezentacji danych oraz modułu oprogramowania ładowanego do testowanego urządzenia. Moduł ten zajmuje się kontrolowaniem przestrzeni I/O mikroprocesora, zarządzaniem jego zasobami oraz komunikacją z komputerem. Metodę taką trudno uznać za bezinwazyjną, jednak umożliwia ona badanie stanu mikroprocesora w czasie rzeczywistym bez konieczności przerywania pracy.
Koszt narzędzia mC/Probe oscyluje w granicach 1000 USD. Na rynek narzędzi debugujących wkraczają także potentaci, jak choćby National Instruments. Firma oferuje środowisko LabVIEW (Laboratory Virtual Instrument Engineering Workbench), którego cechą charakterystyczną jest graficzny język programowania i szerokie możliwości wizualizacji (rys. 4).
LabVIEW zawiera wbudowane funkcje analityczne oraz pomiarowe przeznaczone do różnych zastosowań, co zapewnia programistom duże możliwości wyboru podczas tworzenia programów testujących. Dzięki temu są one zawsze dostosowane do bieżących potrzeb. Warto zwrócić uwagę, że pakiet LabVIEW znajduje zastosowanie także w systemach realizujących potokowe przetwarzanie danych. Koszt pakietu zawierającego zintegrowane narzędzia programowe i sprzętowe zaczyna się od około 1000 USD, jednak łatwo może osiągnąć 10 000 USD, gdy potrzebny jest duży zestaw specjalizowanych, dodatkowych modułów.
Przykład LabVIEW pokazuje, że projektanci chcą płacić tylko za potrzebne im komponenty. Stanowi to wyzwanie dla firm produkujących narzędzia debugujące. Muszą się one liczyć z koniecznością dostarczenia pakietu modułowego, do którego można włączyć tylko elementy wybrane przez kupującego. Co więcej, oczekiwania są często mocno rozbieżne, gdyż część projektantów przygotowuje oprogramowanie dla wybranego systemu operacyjnego i nie zagłębia się w szczegóły architektury. Podgląd zawartości rejestrów nie jest w takiej sytuacji pożądany. Nietrudno wyobrazić sobie przeciwną sytuację, w której oprogramowanie jest tworzone pod konkretny mikroprocesor i optymalizowane w języku niskiego poziomu, a podgląd wszystkich zasobów jest niezbędny. Problem sprawia również określenie, które zmienne i rejestry oglądać, a które można pominąć.
Niestety, często niemożliwe jest przekazanie informacji o wszystkich zasobach mikroprocesora, gdyż interfejs komunikacyjny jest zbyt wolny i uniemożliwia analizę w czasie rzeczywistym. Sytuację tę pogarszają dodatkowo ukryte możliwości mikroprocesora. Zdarza się, że producenci nie podają do publicznej wiadomości informacji o wszystkich możliwościach dostarczanego układu. Jest to spowodowane najczęściej ich eksperymentalnym charakterem i trwającymi pracami badawczymi. Ponieważ uniemożliwia to świadczenie należytej pomocy technicznej projektantom, narzędzia debugujące powinny ukrywać obecność tych funkcji.
Modele UML
Układy wbudowane mogą być traktowane jako czarna skrzynka z widocznymi dla użytkownika jedynie wejściami i wyjściami. Stan wyjścia jest zależny od stanu wejścia i aktualnego stanu urządzenia. Rozwój narzędzi debugujących na przestrzeni ostatnich lat umożliwił wgląd w stan wewnętrzny takiej hipotetycznej, czarnej skrzynki. Konieczny był również rozwój metod testowania, gdyż często niepoprawne stany wyjściowe poprzedzone są bardzo długimi sekwencjami na wejściu, przez co testowanie jest utrudnione i czasochłonne.
Znajomość zawartości zmiennych i rejestrów mikroprocesora może być w niektórych wypadkach niewystarczająca do wnikliwej interpretacji pracy układu. Zastosowanie modelu przygotowanego w języku UML (Unified Modeling Language) pozwala lepiej uwypuklić interakcje zachodzące wewnątrz systemu pomiędzy poszczególnymi blokami funkcyjnymi. Na etapie badania integralności całego systemu umożliwia łatwe stwierdzenie, jakie sygnały powinny występować w poszczególnych miejscach systemu.
Język UML umożliwia modelowanie dziedziny problemu, którą realizują funkcje założone przez projektanta. Polega to na utworzeniu diagramów zawierających struktury (klasy, obiekty, pakiety) i przypisaniu im strzałek określających wzajemne zależności (rys. 5). Dziedziny takie mogą być następnie poddawane analizie lub realizowane w postaci kodu (pisanego ręcznie, dziedziczonego, importowanego z bibliotek, generowanego za pomocą innych narzędzi itp.). Dużą zaletą takiego projektowania jest możliwość niezależnej analizy poszczególnych bloków funkcjonalnych.
Model przygotowany w języku UML określa sposób funkcjonowania urządzenia oraz oferuje jeszcze jedną zaletę: może zostać automatycznie zamieniony na odpowiadający mu szablon w języku programowania. W takim przypadku zastosowanie znajduje szereg reguł, według których odbywa się proces translacji, podobnie jak ma to miejsce w kompilatorach języków wysokiego poziomu. Istnieje możliwość dodania do wygenerowanego kodu procedur umożliwiających testowanie pracy utworzonego modelu w systemie wbudowanym na poziomie abstrakcji odpowiadającym poziomowi abstrakcji samego modelu.
Procedury testowe umożliwiające weryfikację modelu UML powstają w oparciu o zdefiniowany model i są automatycznie dodawane do wygenerowanego kodu. Warto zauważyć, że nie zmieniają one funkcjonalności modelu, a jedynie rozszerzają go o elementy niezbędne do testowania. Procedury te powstają w oparciu o model UML i umożliwiają testowanie praktycznie każdego elementu aplikacji. Narzędzia te mogą być pominięte na etapie kompilacji.
| Symulator HILS |
|
Test z użyciem HILS pozwala przetestować projekt na biurku konstruktora, zapewniając złudzenia pracy w rzeczywistych warunkach. Podstawowym wymogiem prowadzenia takich badań jest zaimplementowanie możliwie wiernego modelu docelowego otoczenia. Nietrudno podać przykład zastosowania tej metody weryfikacji projektu – może to być autopilot wykorzystywany do utrzymywania założonego kursu samolotu. Z oczywistych przyczyn nie można sobie pozwolić na zainstalowanie prototypu w samolocie i sprawdzenie poprawności działania. Trudno też zadawać na wejścia kilka różnych sygnałów odpowiadających np. prędkości, przyspieszeniu czy nachyleniu maszyny. Odczytanie wartości wyjściowej i bieżące modyfikowanie stanu wejść również nie będzie łatwe. Rolę tę może jednak z powodzeniem realizować symulator HILS, który zada sygnały wejściowe, odczyta sygnał wyjściowy, obliczy zmianę parametrów wejściowych i prześle je na wejścia autopilota. Odzwierciedla to pracę w rzeczywistym samolocie, gdzie regulacja np. ciągu wektorowanego (sygnał wyjściowy) wpływa na parametry lotu, takie jak np. nachylenie (sygnał wejściowy). Moduł HILS uwzględnia wszystkie te zależności. Warto podkreślić jeszcze raz, że o jakości testu decyduje w dużej mierze wierność modelu zastosowanego w symulatorze HILS, ale również jego moc obliczeniowa przekładająca się na liczbę iteracji w czasie sekundy. W praktyce liczba iteracji powinna być 5–10 razy większa niż ta dokonywana przez projektowane urządzenie. Warto w związku z tym zainwestować w jednostkę obliczeniową i zapewnić możliwie największa szybkość przetwarzania danych. Iteracja jest w rzeczywistości procesem próbkowania sygnału analogowego pojawiającego się na wejściu urządzenia. Klasyczne kryterium Nyquista (twierdzenie o próbkowaniu) określa, że powinna być ona dwukrotnie większa od częstotliwość najwyższej harmonicznej. W rzeczywistości widma sygnału nie da się ograniczyć do określonego pasma i im mniejszy okres próbkowania, tym wierniej jest odtwarzany oryginalny sygnał. Warto zadać sobie pytanie, co odróżnia „typową” symulację od pracy z układem HILS. Pierwszym wyróżnikiem jest obecność prawdziwych sygnałów na wejściu urządzenia, w przeciwieństwie do symulacji ograniczającej się do przedstawienia wykresu. Co więcej, symulacje nie są prowadzone w czasie rzeczywistym, bo czas obliczeń zależy od mocy obliczeniowej komputera. Trzecią zaletą modułu HILS jest praca prototypu w „rzeczywistym” otoczeniu, podobnym do tego, w jakim później będzie on umieszczony. Symulacje HILS dają możliwość rejestracji sygnałów obecnych na wejściach i wyjściach testowanego urządzenia.Po podłączeniu do komputera po każdej iteracji można zapisać stany wejść i wyjść. Dane mogą być rejestrowane w formie pliku na dysku twardym lub w pamięci RAM. Co więcej, możliwe jest uruchomienie bądź zatrzymanie procesu gromadzenia pomiarów i uniknięcie w ten sposób zbierania informacji nieistotnych. Możliwość wczytania danych do pakietu Matlab czy Excel celem wykonania analizy i oceny jest również bardzo cenna. Przy obecnym rozwoju przemysłu półprzewodnikowego i swobodnym dostępnie do dedykowanych kontrolerów Ethernet nic nie stoi na przeszkodzie, aby rejestracja odbywała się na bieżąco tą właśnie drogą. Niektóre pakiety oprogramowania (np. LabVIEW) obsługują interfejs Ethernet i pozwalają na zapisywanie, obrabianie i wizualizowanie przesłanych danych za pomocą graficznego języka programowania. Mogłoby się wydawać, że moduły HILS stanowią doskonałe rozwiązanie do testowania systemów wbudowanych. Niestety, mają one swoje ograniczenia. Jednym z nich jest brak możliwości wstrzymania pracy symulatora. Zasadniczo możliwe jest zatrzymanie mikroprocesora systemu wbudowanego, ale moduł HILS będzie wciąż wykonywał swoje zadanie – stany wejść będą się cały czas zmieniać. Brak sprzężenia zwrotnego przez system wbudowany może spowodować pojawienie się skrajnych wartości na wejściach. Wada ta znacznie utrudnia śledzenie propagacji sygnału z wejścia na wyjście. Innym poważnym utrudnieniem jest brak wglądu w stan mikroprocesora systemu wbudowanego. Nie da się określić miejsca wystąpienia błędu w oprogramowaniu, gdyż symulator HILS nie analizuje zmiennych i rejestrów mikroprocesora. Nieodzowne jest wtedy drugie narzędzie, takie jak emulator czy analizator stanów logicznych, umożliwiający śledzenie danych na magistralach. Pomocny bywa również debugger sprzężony z oprogramowaniem, umożliwiający wizualizację |
Implementując model UML „ręcznie”, należy mieć na uwadze, że rodzaj i liczba wymaganych funkcji testujących zależy od złożoności projektu, metody testowania, środowiska pracy, dostępnej pamięci i czasu przeznaczonego na prowadzenie testów. Niezbędne jest rozróżnienie pomiędzy zmiennymi, atrybutami, wejściami systemu oraz punktami kontrolnymi, co wymaga zaimplementowania szeregu narzędzi do sprawdzania każdego z tych elementów. Narzędzie testujące modele UML jest podzielone na dwie części. Pierwszą stanowi dynamiczny interfejs weryfikacyjny użytkownika DVUI (Dynamic Verification User Interface) odpowiadający za wyświetlanie informacji pobranych z systemu wbudowanego oraz wykonywanie komend. Druga część pośredniczy w wymianie informacji pomiędzy DVUI oraz debugowanym oprogramowaniem.
Komunikacja z modułem odpowiedzialnym za wizualizację danych odbywa się za pomocą interfejsów, takich jak RS-232, TCP/IP, etc. Niezbędny jest jeszcze moduł pośredniczący, odpowiedzialny za organizowanie informacji testowych, komunikację z funkcjami testującymi obecnymi w kodzie aplikacji, informowanie DVUI o ścieżkach wykonania programu i zapewniający kontrolę nad wykonaniem programu. Wgląd w stan systemu jest sprawą kluczową podczas badania integralności projektu. Nieoceniona jest wtedy możliwość zapoznania się z danymi zawartymi w poszczególnych obiektach (instancjach klas), co przekłada się na konieczność zapewnienia dostępu do nich przez DVUI. Niezbędna staje się lista z wyszczególnionymi elementami decydującymi o stanie systemu. Można ją pozyskać poprzez wzbogacenie konstruktorów klas w instrukcje gromadzące takie informacje na specjalnie przygotowanej do tego celu liście. Kiedy obiekt przestaje być potrzebny i jest usuwany z pamięci, wywoływany jest destruktor usuwający go z listy.
Wyświetlenie wartości poszczególnych zmiennych wymaga ich konwersji na łańcuch znaków w kodzie ASCII. Można to osiągnąć podobnie, jak ma to miejsce w języku Java, gdzie wykorzystywana jest metoda toString() dokonująca przekształcenia. Po zamianie dane mogą zostać wysłane do modułu DVUI i zaprezentowane osobie testującej urządzenie. Łatwo wyobrazić sobie odwrotną sytuację, w której projektant musi zmienić wartość wybranego atrybutu systemu; wykorzystywana jest wówczas odwrotna metoda fromString().
Jakub Borzdyński
