Testowanie sprzętu w pętli: Wprowadzenie

Jeśli poszukasz informacji na temat testowania "Hardware-in-the-Loop", często znajdziesz przykłady złożonych systemów działających w czasie rzeczywistym. Ten artykuł z National Instruments, na przykład, dostarcza dobre wyjaśnienie i tło na temat tego, czym jest hardware-in-the-loop (HIL), oraz przedstawia przykład testowania elektronicznych jednostek sterujących w samochodzie. W tym artykule skupimy się na mniejszej, bardziej przystępnej wersji koncepcji testowania HIL.

Co to jest testowanie Hardware-in-the-Loop?

W celach niniejszego artykułu zdefiniujemy testowanie hardware-in-the-loop nieco inaczej niż jest to przedstawiane konwencjonalnie (np. w zastosowaniach samochodowych). Przyjrzyjmy się trzem różnym poziomom złożoności, jeśli chodzi o testowanie produktu.

Format testu 1: Podstawowe testowanie ręczne

W tej formie testowania inżynier będzie ręcznie testować urządzenie. Może to obejmować sondowanie punktów testowych na płytce za pomocą cyfrowego multimetru, obserwowanie przebiegów na oscyloskopie lub ręczne przeglądanie odczytów telemetrii na ekranie komputera. Inżynier będzie testować produkt za pomocą ręcznego testowania weryfikacji projektu.

Format testu 2: Testowanie automatyczne

Ten zestaw testowy wykonuje te same pomiary i weryfikacje, które zwykle wykonuje inżynier, ale są one wykonywane przez komputer w sposób zautomatyzowany. Komputer gospodarz komunikuje się bezpośrednio z instrumentami (np. multimetrami, oscyloskopami itp.), analizuje telemetrię z urządzenia, a następnie weryfikuje zestaw testowy na podstawie kryteriów określonych przez inżyniera.

Format testu 3: Testowanie sprzętu w pętli

Testowanie sprzętu w pętli podnosi automatyczne testowanie na nowy poziom, dodając dodatkowe bodźce do symulacji rzeczywistych zastosowań. Na przykład, testowane urządzenie (DUT) może mieć serię czujników, które wymagają pobudzenia. Sprzęt testowy symulowałby drugi koniec tych czujników, aby pobudzić stronę czujnika DUT. Innym przykładem może być coś tak prostego, jak wprowadzanie ruchu RS-422 do odbiornika RS-422 na DUT. Idea polega na tym, że jesteśmy w stanie wprowadzić nowy bodziec do DUT, odczytać telemetrię z komputera gospodarza i odpowiednio dostosować nasze testy, jeśli jest to potrzebne (np. generować szybszy i większy ruch RS-422 po zaliczeniu wstępnego testu).

Korzyści z wdrożenia testowania sprzętu w pętli

Na podstawie zastosowania można łatwo zrozumieć, dlaczego ktoś mógłby zdecydować się na przyjęcie testowania sprzętu w pętli (hardware-in-the-loop) zamiast automatycznego testowania (a już na pewno manualnego). Jeśli ktoś próbuje zintegrować skomplikowany system lub systemy systemów, z wieloma wymaganymi zewnętrznymi bodźcami, podstawowy test sprawdzający automatyzacji nie będzie wystarczający. Rozważmy podstawową ładowarkę do baterii. Chociaż można symulować źródło zasilania, obciążenie i baterię, aby przetestować układ sterujący (fizycznie lub za pomocą oprogramowania), bardziej realistyczne byłoby użycie rzeczywistego zasilacza, baterii i obciążenia do przetestowania projektu. Co więcej, jeśli można zautomatyzować ten proces, inżynierowie mogą teraz poświęcić swój czas na rozwój zamiast testowania.

Analiza kosztów: Czy warto?

Decydując się na przyjęcie testowania sprzętu w pętli, należy wziąć pod uwagę następujące czynniki:

1. Czas testowania: Ile czasu będziesz poświęcać na testowanie urządzenia? Czy będzie to podstawowe sprawdzenie, a potem koniec, czy będzie wymagało miesięcy testów?
2. Powtarzalność testu: Jak często będziesz przeprowadzać ten sam test? Czy to ustawienie testowe (tj. sprzęt i skrypty automatyzacji) może być używane w przyszłych projektach?
3. Sprzęt do testów: Jakie są koszty uzyskania niezbędnego sprzętu do testów automatycznych w porównaniu z testami manualnymi?

Po rozważeniu tych i innych czynników, możesz zacząć podejmować decyzję, czy pozostać przy testowaniu manualnym, czy zainwestować w testowanie automatyczne / sprzętowe w pętli.

Rozpoczęcie

Na podstawie mojego doświadczenia stwierdziłem, że zdecydowanie najłatwiejszym sposobem na rozpoczęcie testowania sprzętowego w pętli jest użycie kompleksowego frameworka do testów, takiego jak ten oferowany przez National Instruments (NI). NI posiada kompleksową platformę sprzętowo-programową, która jest gotowa do użycia od razu po wyjęciu z pudełka. Oto kilka zalet i wad, które warto rozważyć, decydując się na kompleksowy framework:

Przez czas, który spędziłem pracując nad skomplikowanymi systemami, LabVIEW był moim pierwszym wyborem do automatycznego testowania — włączając w to budowanie pełnego ciągu integracji i wdrażania ciągłego dla projektów i VI w LabVIEW. Gdy przeszedłem do mniejszych systemów, które wymagały prostszego wsparcia sprzętu w pętli, zacząłem migrować w kierunku niestandardowego lub gotowego sprzętu komercyjnego oraz skryptów Pythona (używając pytest framework). Ponownie, wszystko zależy od zastosowania i, jak wcześniej wspomniano, czas testu, częstotliwość testów i sprzęt testowy to główne czynniki, które kierują tą decyzją.

Podsumowanie

W tym artykule przeglądaliśmy koncepcję testowania sprzętu w pętli i jak różni się ono od testowania ręcznego i automatycznego. Omówiliśmy również korzyści płynące z przyjęcia testowania sprzętu w pętli oraz jak ocenić, czy jest to rzeczywiście to, czego użytkownik potrzebuje. Na koniec omówiliśmy kilka sposobów na rozpoczęcie. Chociaż testowanie sprzętu w pętli nie jest dla każdego, jest jasne, że dla odpowiedniego zastosowania inwestycja bardzo szybko się zwróci.

Czy chciałbyś dowiedzieć się więcej o tym, jak Altium może pomóc Ci w Twoim następnym projekcie PCB? Porozmawiaj z ekspertem w Altium lub dowiedz się więcej o najważniejszych problemach DFM i ich rozwiązaniach.