Rozwiązania niskobudżetowe dla automatyzacji testowania sprzętu w pętli

W dzisiejszym szybkim świecie, gdzie iteracje elektroniki są tworzone z prędkością błyskawicy, często zapominamy o jednym z najważniejszych aspektów rozwoju: testowaniu. Zawsze łatwo jest przeoczyć testowanie, ponieważ to ostatni etap, który stoi na drodze do wypuszczenia naszego produktu. W rozwoju produktu ciągle znajdujemy się w obozie "wystarczająco dobry" versus "wyczerpująco przetestowany". Ta sytuacja zazwyczaj ma miejsce, ponieważ nie mamy czasu na testowanie, ponowne testowanie, a następnie jeszcze więcej testowania. 

W najlepszej z możliwych sytuacji, zatrudnilibyśmy pełny zespół testowy, który jest wyposażony do przeprowadzania wyczerpujących testów. Nawet jeśli mamy ten luksusowy zespół testowy, czy naprawdę jesteśmy w stanie wykorzystać go przy każdej modyfikacji, każdej małej i nieistotnej zmianie, którą wprowadzamy do naszych prototypów? W większości przypadków odpowiedź brzmi nie, i w tym artykule chciałbym podejść do problemu z rozwiązaniem, które pozwoli ci mieć ciastko i zjeść ciastko. W tym artykule przeanalizujemy bardzo niskokosztowy, a jednak wysoce efektywny i dość wyczerpujący system testowy, który da ci ten efekt za swoje pieniądze, którego szukałeś.

Testowanie ręczne versus testowanie automatyczne

W branży dość powszechne jest posiadanie zautomatyzowanego zestawu do testów (głównie dla testów na poziomie produkcji). Jednakże, w przypadku rozwoju produktu, nie jest to praktyka powszechna. Jak wspomniano powyżej, koszt i czas rozwoju potrzebny do ustawienia zaawansowanego zautomatyzowanego sprzętu do testów wymaga dużego wysiłku. Tego rodzaju koszt i wysiłek są uzasadnione tylko dla produkcji w dużych ilościach lub małych ilościach z bardzo zaawansowanymi konfiguracjami testowymi (np. systemy kosmiczne produkowane w małych ilościach, które muszą być testowane środowiskowo wiele razy). Dla reszty świata uciekamy się do podstawowych, żmudnych testów manualnych. Tego rodzaju testy mogą obejmować walidację ADC/DAC, sprawdzanie protokołów, testy zużycia energii itp. Bez względu na typ testu, nadzieją jest, że będzie musiał być wykonany tylko raz lub dwa, a następnie można go przekazać grupie testującej.

Niezamierzone Konsekwencje i Automatyzacja

Rzeczywistość jest taka, że podczas naszego rozwoju, czy to w fazach projektowania/ponownego projektowania sprzętu, czy w rozwoju oprogramowania wbudowanego, nieumyślnie powodujemy, że coś się psuje. Przykładami mogą być mostek lutowniczy między padami lub kod sterownika, który przenika do innych kodów sterowników, co może spowodować awarię. Niezależnie od wyniku, jasne jest, że testowanie nie odbywa się tylko raz czy dwa. Pojawiają się problemy, a wyczerpujące testowanie zazwyczaj staje się zbyt męczące po dziesiątym razie przerabiania płytki. Oczywistą odpowiedzią na problem jest zastosowanie zautomatyzowanych systemów do przeprowadzania wyczerpujących testów regresyjnych. Ale jakie jest rozwiązanie dla inżyniera systemów wbudowanych, który ma mało pieniędzy i czasu na opracowanie wyczerpującego zautomatyzowanego systemu testowego?

Tanie Rozwiązanie

Dla systemów wbudowanych istnieje niskokosztowe, a jednak bardzo skalowalne i praktyczne rozwiązanie do automatycznego testowania. Chociaż nie jest doskonałe, zapewni projektantowi najwyższy zwrot z inwestycji. Koncepcja polega na użyciu prostego urządzenia, które może generować sygnały analogowe, odczytywać sygnały analogowe, generować różne strumienie protokołów szeregowych oraz analizować przebiegi. Przykładem niskokosztowego urządzenia, które posiada takie specyfikacje, jest Analog Discovery 2. Chociaż jest to urządzenie 5V, to nadal oferuje znaczne możliwości. Uważam je za mój szwajcarski scyzoryk do rozwoju systemów wbudowanych. Istnieją inne porównywalne produkty, ale to urządzenie szczególnie dobrze sprawdziło się w moich zastosowaniach. Urządzenie to może być obsługiwane z komputera stacjonarnego lub nawet Raspberry Pi. Posiada również bibliotekę Python, która umożliwia użytkownikowi szybkie tworzenie testów wykonawczych. Dla wygody zadokeryzowałem pełną konfigurację i zbudowałem ją dla wszystkich architektur.

Przykład działania

Rozważmy rzeczywisty przykład, który można znaleźć w tym repozytorium. Dla uproszczenia naszym docelowym systemem wbudowanym będzie Arduino Duo. Poniżej przedstawiono, jak wygląda nasze pełne ustawienie testowe:

Celem tutaj jest pokazanie:

• Komputer sterujący wysyła polecenia do Analog Discovery 2, aby ten generował sygnały analogowe do Arduino
• Arduino odczytuje i zapisuje wartości ADC
• Komputer sterujący odbiera wartości ADC przez UART (USB)
• Komputer sterujący weryfikuje, czy to, co zostało wysłane przez Analog Discovery 2, zgadza się z telemetrią wysłaną przez Arduino

Dlaczego chcielibyśmy zautomatyzować coś takiego? Załóżmy, że przeprowadzamy przeróbkę płytki w pobliżu ADC, lub ktoś zmienia sterowniki, które współpracują z ADC. Czy jesteśmy w 100% pewni, że proste ręczne odczyty ADC z kilkoma pokrętłami na zasilaczu są wystarczające do przetestowania naszego sprzętu/oprogramowania? Jeśli nie, dlaczego nie pozwolić automatyzacji pokryć każdą permutację i każdy przypadek skrajny, abyśmy nie musieli tego robić? I tak dla pewności, dlaczego by nie uruchomić tego samego 100 razy... tylko dlatego, że możemy! To może być znacznie bardziej skomplikowane i zaawansowane (np. testowanie protokołów, testy filtrowania ADC itp.), ale ten artykuł będzie trzymać się tylko podstaw.

Skrypt testowy jest dość podstawowy. Zakładając, że twoje Arduino (czyli testowane urządzenie wbudowane) zostało załadowane odpowiednimi plikami programowania i wszystko zostało prawidłowo podłączone, uruchomiłbyś skrypt testowy na swoim komputerze w następujący sposób:

python -m pytest test_arduino_hil.py

Spowoduje to, że Analog Discovery 2 przeskanuje zakres napięć ADC Arduino i zweryfikuje, czy napięcie wejściowe odpowiada napięciu wyjściowemu odczytanemu z ADC. Zamiast ręcznego przesuwania za pomocą zasilacza laboratoryjnego, skrypt zrobił to za ciebie jednym poleceniem. Dla trywialnego przykładu jak ten, może się to wydawać niepotrzebne, ale ten proces przynosi korzyści, gdy łączy się testy w sposób przypominający regresję.
Łącząc to z naszym systemem CI/CD, możemy zobaczyć następujące etapy uruchamiane i zaliczane:

Wyżej wymienione etapy to:

1. docker_build: Budowanie środowiska. W tym przypadku używamy obrazów docker na komputerach z systemem Linux i urządzeniach opartych na ARM, takich jak Raspberry Pi
2. arduino_load_test: Kompilacja i załadowanie kodu Arduino i weryfikacja, czy wszystko zadziałało.
3. arduino_hil_test: Uruchom test sprzętu w pętli na fizycznym Arduino.

Jeśli przyjrzymy się bliżej sekcji Testy, możemy zauważyć, że te testy zostały przechwycone i przetworzone przez Gitlab:

Teraz mamy konfigurację oprogramowania, która pozwala nam testować nasz projekt lokalnie i zdalnie (za pomocą naszego systemu CI/CD). To umożliwia inżynierowi projektowemu kontynuowanie skupienia się na projektowaniu zamiast na testowaniu i debugowaniu w dalszej perspektywie.

Podsumowanie

W tym artykule omówiliśmy koncepcję używania automatycznych testów do walidacji projektu równolegle i po fakcie. Niezależnie od tego, czy jest to drobna przeróbka, czy monumentalna zmiana projektu, posiadanie automatycznych testów regresyjnych przynosi korzyści, gdy chodzi o wykluczanie niezamierzonych konsekwencji (tj. naprawić jedno, zepsuć coś innego). Zachęcanym procesem jest pisanie tych skryptów testowych równolegle z procesem rozwoju projektu (podobnie jak Test Driven Development). Połączenie tych automatycznych testów z systemem CI/CD dodaje dodatkowy bonus, demonstrując, że nasze płytki działają na zdalnym celu i mogą być testowane przez każdego, w dowolnym miejscu i o każdej porze.

Czy chciałbyś dowiedzieć się więcej o tym, jak Altium może pomóc Ci w Twoim kolejnym projekcie PCB? Porozmawiaj z ekspertem w Altium lub dowiedz się więcej o największych problemach DFM i ich rozwiązaniach. Możesz pobrać darmową wersję próbną Altium Designer tutaj.