Testy jednostkowe są stosunkowo nowym (w świecie automatyków) narzędziem wpierającym tworzenie i rozwijanie istniejącego oprogramowania. Idea testów polega na tym, aby tworzyć różne scenariusze, których wykonanie powinno zakończyć się zgodnie z oczekiwaniami. W ramach dzisiejszego wpisu zajmiemy się stworzeniem scenariusza testowego dla programu kontrolującego pracę przenośnika. Do testowania naszych programów potrzebne jest oprogramowanie TIA Portal V16, a także dwa dodatkowe produkty – PLCSIM Advanced V3.0 oraz TestSuite, które mogą zostać uruchomione w wersji testowej na okres 21 dni.
Kontrola przenośnika – aplikacja do przetestowania
W środowisku TIA Portal posiadamy utworzony blok FB, którego zadaniem jest sterowanie przenośnikiem odpowiedzialnym za transport palet z wyprodukowanymi częściami. Do obsługi bloku FB wykorzystywane są następujące sygnały I/O:
- inStart – sygnał odpowiedzialny za rozpoczęcie pracy przenośnika
- inStop – sygnał zatrzymujący pracę przenośnika
- inPermission – sygnał zezwalający na uruchomienie przenośnika (warunki początkowe)
Sam program prezentuje się następująco:
Parametry testowe
Do przetestowania naszej aplikacji wykorzystujemy trzy sygnały wejściowe. Sygnały inStart oraz inStop to standardowe przyciski monostabilne (załóżmy, że oba wykorzystują styki NO). Sygnał inPermission to złożone pozwolenie sprawdzające brak alarmów i stan procesu. Wywołanie bloku FB w głównym bloku organizacyjnym znajduje się poniżej.
Scenariusz testowy – jak go stworzyć?
W celu stworzenia scenariusza testowego konieczne jest wyszukanie zakładki TestSuite, którą odnaleźć można w dolnej części drzewa projektowego. Same oprogramowanie daje nam dwie możliwości:
- Styleguide – Testowanie składni, stylu tworzenia i nazewnictwa zmiennych
- Application test – Testowanie aplikacji
Poprzez wybranie opcji Add new test case tworzymy nowy scenariusz, a następnie zmieniamy jego nazwę.
Stworzenie testu aplikacji
Pierwszą czynnością jest określenie sterownika PLC, na którym przeprowadzane będą testy (zakładka Scope w prawym górnym rogu).
Druga rzecz, to deklaracja zmiennych testowych w sekcji VAR. W ramach naszej aplikacji niezbędne są cztery sygnały, które w tym momencie możemy nazwać w oparciu o dowolny alias (inną, krótszą i wygodniejszą nazwę). Strukturę można modyfikować w dowolnym momencie. Testowane sygnały inStart, inStop oraz inPermission to dokładnie te same zmienne, które podpięte zostały jako parametry wejściowe przy wywołaniu bloku OB1. Zmienna motorState to zmienna wynikowa bloku FB, której wartość informuje o stanie pracy przenośnika.
Kolejny etap to przygotowanie procedury testu. Do tematu należy podejść tak, jak analizuje się działanie poszczególnych algorytmów. Przykład:
Procedura: Wciśnięcie przycisku Start powinno uruchomić maszynę (gdy jest na to pozwolenie, a przycisk Stop nie jest aktywny)
Oczekiwany rezultat: Przenośnik rozpoczyna pracę – zmienna motorState powinna mieć wartość TRUE.
Nic więcej. A teraz przejdziemy do realizacji. Testy przygotowywane są w etapach (krokach). W ramach pojedynczego kroku wprowadzamy wartości bieżące analizowanych sygnałów (ich układ, który w danej chwili nas interesuje), a następnie decydujemy ile cykli powinien wykonać program, a także jaki jest oczekiwany rezultat. Zamiast liczby cykli wprowadzony może zostać czas.
Scenariusz testowy #1 – włączenie maszyny
Zgodnie z powyższym opisem wprowadzamy stany sygnałów:
Następnie, za pomocą polecenia RUN określamy liczbę cykli – w zupełności wystarczy jeden cykl (aczkolwiek nic nie stoi na przeszkodzie, aby wpisać wartość typu 500).
Ostatnia czynność to określenie oczekiwanego rezultatu. Pisząc nasz program widzimy wprost – pozwolenie jest, przycisk Start wciśnięty, a przycisk Stop nie jest aktywny. Oczekujemy zatem, że nasz przenośnik zacznie pracować. Do określenie rezultatu konieczny jest rozkaz Assert. Za jego pomocą określimy, jaki warunek „zdaje nasz test”.
Uruchomienie pierwszego testu
Kompletny scenariusz testowy prezentuje się następująco:
Uruchomienie testu odbywa się poprzez naciśnięcie przycisku Run test case widocznego w prawym górnym rogu. W trakcie uruchamiania testu pracujemy z projektem offline i nie posiadamy włączonej żadnej instancji symulatora PLCSIM Advanced. Wszystko uruchamia się automatycznie, co prezentuje poniższa grafika.
Co dalej?
Przykładowa aplikacja jest bardzo prosta. Doskonale widzimy iż w podstawowym zakresie czynności przenośnik będzie pracował zgodnie z naszymi oczekiwaniami. Pytanie brzmi – czy zawsze tak będzie?
Proszę wyobrazić sobie sytuację, w której mamy pozwolenie na pracę (inPermission = TRUE), a przycisk Start się „zaklinuje” (inStart = TRUE). Znając zasadę działania instrukcji SR wiemy, że wciśnięcie przycisku Stop zatrzyma maszynę (inStop = TRUE). Lecz co w sytuacji, gdy operator puści przycisk Stop? No właśnie… skąd mogliśmy to wiedzieć, że maszyna znów ruszy?
Mogliśmy, ponieważ tego typu błąd mógł zostać wychwycony na etapie testów. Jednym z największym problemów przy programowaniu PLC jest przekonanie, że program zostanie przetestowany dopiero na maszynie, na żywym organizmie przy setkach zabezpieczeń chroniących przed potencjalnymi kolizjami czy blokadą procesu. Okazuje się, że wiele z tych konfliktów jesteśmy w stanie wychwycić już na etapie prac offline’owych – w biurze przy kawie, a nie stojąc z laptopem w jednej ręce na obiekcie piątą godzinę (gdzie wydajność i komfort tej samej pracy są odrobinę niższa) 😊