Dlaczego testy FAT i SAT decydują o opłacalności projektu automatyki
W projektach automatyki przemysłowej to nie sam montaż czy programowanie generują największe koszty, lecz poprawki po wdrożeniu. Błędy wykryte już po uruchomieniu linii, maszyny czy systemu sterowania oznaczają przestoje, nerwowe gaszenie pożarów i dodatkowe faktury od dostawców. Testy FAT i SAT są po to, aby te koszty zminimalizować, a najlepiej wyeliminować. Dobrze przygotowane i przeprowadzone pozwalają odebrać system bez drogich niespodzianek.
FAT (Factory Acceptance Test) i SAT (Site Acceptance Test) to nie „formalność dla dokumentacji”, ale konkretne narzędzie zarządzania ryzykiem technicznym i finansowym. W praktyce różnica między projektem zakończonym spokojnym rozruchem, a projektem z ciągłymi awariami przez pierwsze miesiące, bardzo często leży w jakości tych dwóch etapów.
Żeby testy FAT i SAT miały sens, trzeba wiedzieć co dokładnie sprawdzać, jak to dokumentować, kogo zaangażować i kiedy postawić twardą granicę: „system nie jest gotowy do odbioru”. Sama obecność w harmonogramie punktów „FAT” i „SAT” niczego nie gwarantuje – liczy się ich treść, zakres i konsekwencja wykonania.
FAT vs SAT w automatyce – definicje, cele, różnice
Co to jest test FAT w automatyce przemysłowej
FAT (Factory Acceptance Test) to testy odbiorowe prowadzone u dostawcy systemu: integratora, producenta maszyny, dostawcy szafy sterowniczej czy systemu sterowania. Celem jest potwierdzenie, że dostarczony system spełnia wymagania funkcjonalne, jakościowe i dokumentacyjne, zanim opuści fabrykę dostawcy.
W automatyce przemysłowej FAT najczęściej obejmuje:
- sprawdzenie szaf sterowniczych, okablowania, zasilania, zabezpieczeń,
- weryfikację konfiguracji sterowników PLC, paneli HMI, systemów SCADA,
- testy logiki sterowania na symulatorach, emulatorach lub z wykorzystaniem części rzeczywistych urządzeń,
- testowanie funkcji bezpieczeństwa (np. zatrzymania awaryjne, blokady, kurtyny), o ile warunki pozwalają,
- kontrolę kompletności dokumentacji technicznej i powykonawczej.
FAT powinien być zorganizowany tak, aby wyłapać jak najwięcej błędów jeszcze przed wysyłką. Im więcej problemów zostanie złapanych w trakcie FAT, tym mniej nerwów i kosztów pojawi się na etapie rozruchu u klienta.
Co to jest test SAT na obiekcie
SAT (Site Acceptance Test) to testy odbiorowe prowadzone na docelowym obiekcie – w zakładzie produkcyjnym, magazynie automatycznym, stacji procesowej. Ich celem jest potwierdzenie, że system w warunkach rzeczywistych, podłączony do docelowych mediów, maszyn i procesów, działa zgodnie z wymaganiami biznesowymi i technicznymi.
W ramach SAT sprawdza się między innymi:
- poprawność podłączeń do instalacji zasilania, pneumatyki, hydrauliki, sieci przemysłowych,
- współdziałanie z innymi systemami (linie sąsiednie, systemy nadrzędne, MES/ERP, wagi, etykieciarki),
- parametry pracy w realnych warunkach: czasy cykli, wydajność, jakość produktu,
- zachowanie w sytuacjach awaryjnych, przy zaniku zasilania, błędach komunikacji,
- ergonomię obsługi, dostępność do serwisu, zgodność z procedurami BHP.
Podczas SAT wychodzą na jaw wszystkie różnice między „idealnym” środowiskiem u dostawcy a realnym światem zakładu: inne media, inne przyzwyczajenia operatorów, ograniczenia przestrzenne, zakłócenia komunikacji, niestandardowe scenariusze pracy.
Najważniejsze różnice między FAT a SAT
W praktyce FAT i SAT badają często podobne funkcje, ale w odmiennym kontekście. Dobrze pokazuje to proste porównanie:
| Obszar | FAT – u dostawcy | SAT – na obiekcie |
|---|---|---|
| Środowisko | Kontrolowane, częściowo symulowane | Rzeczywiste warunki pracy zakładu |
| Zakres testów | Logika, hardware, bezpieczeństwo, dokumentacja | Integracja, wydajność, obsługa, scenariusze produkcyjne |
| Cel biznesowy | Ograniczenie ryzyka technicznego przed wysyłką | Odbiór końcowy i dopuszczenie do pracy produkcyjnej |
| Decyzje | Gotowość do wysyłki / konieczność poprawek u dostawcy | Gotowość do produkcji / konieczność modyfikacji na miejscu |
Obydwa etapy są kluczowe. Dobry FAT ogranicza ilość poprawek podczas SAT, ale nigdy nie zastąpi testów w realnym środowisku. Z kolei rzetelny SAT zamyka projekt technicznie i formalnie, dając podstawę do gwarancji i rozliczeń.
Planowanie testów FAT i SAT – fundament bezproblemowego odbioru
Zakres testów w umowie i specyfikacji technicznej
Większość problemów przy odbiorach zaczyna się na etapie, gdy testy FAT i SAT są opisane w umowie jednym zdaniem: „Dostawca przeprowadzi FAT i SAT”. To otwarta droga do konfliktów. Kluczowe jest, by zakres, kryteria i sposób prowadzenia testów były opisane precyzyjnie w dokumentacji kontraktowej.
W specyfikacji technicznej lub załączniku do umowy powinny znaleźć się co najmniej:
- szczegółowy opis, co będzie testowane podczas FAT i SAT (lista funkcji, modułów, scenariuszy),
- jakie są kryteria akceptacji – np. maksymalny czas cyklu, dopuszczalna liczba błędów, czas reakcji systemu,
- jak będą mierzone parametry: jakie narzędzia, jaka dokładność, kto dostarcza urządzenia pomiarowe,
- podział zadań: co przygotowuje dostawca, a co użytkownik (np. materiały testowe, media, dostęp do innych systemów),
- wymogi dokumentacyjne: protokoły testów, check-listy, wzory raportów z FAT i SAT.
Im bardziej konkretne i mierzalne wymagania, tym mniej przestrzeni na uznaniowość przy odbiorze. Ogólnikowe sformułowania typu „system ma działać poprawnie” generują wyłącznie spory.
Harmonogram i powiązanie z kamieniami milowymi projektu
Testy FAT i SAT muszą być wplecione w harmonogram projektu jako osobne kamienie milowe, a nie jako przypisy. Brak jasnych dat i rezerw czasowych kończy się ściskaniem testów „na siłę” w dwa dni, bo już przyjeżdżają montażyści kolejnego dostawcy.
Przy planowaniu warto zadbać o:
- realistyczny czas na przygotowanie się do FAT po stronie dostawcy (montaż, wstępne uruchomienie, autotesty),
- czas na poprawki po FAT – tak, by nie wpływały dramatycznie na termin wysyłki,
- bufor między transportem a SAT – uwzględniający montaż mechaniczny, podłączenia mediów, testy powykonawcze,
- właściwą kolejność: SAT systemu sterowania ma sens dopiero, gdy infrastruktura (media, linia, inne systemy) są gotowe.
Dobry harmonogram zawiera też informację, kto ze strony klienta i dostawcy ma być obecny przy poszczególnych etapach testów: automatycy, utrzymanie ruchu, operatorzy, BHP, jakościowcy.
Rola użytkownika końcowego w przygotowaniu testów
Jednym z częstych błędów jest całkowite zrzucenie odpowiedzialności za scenariusze testowe na dostawcę systemu. Integrator potrafi świetnie sprawdzić funkcje techniczne, natomiast nie zna wszystkich niuansów procesu produkcyjnego czy lokalnych obejść stosowanych od lat.
Dlatego po stronie użytkownika powinny powstać:
- lista typowych scenariuszy produkcyjnych (różne formaty, receptury, zmiany asortymentu),
- lista trudnych przypadków: awarie, zmiany partii surowca, przerwy w dostawach mediów,
- wymagania działu jakości i BHP dotyczące sposobu rejestracji danych, raportowania, blokad,
- opis obecnych „bolączek” procesu, które nowy system ma rozwiązać (dobry punkt odniesienia przy SAT).
Jeżeli użytkownik nie wniesie swojej wiedzy do przygotowania FAT/SAT, testy będą jedynie sprawdzeniem poprawności działania PLC i HMI, a nie realnej przydatności systemu w produkcji.
Co sprawdzić podczas FAT – lista krytycznych obszarów
Kontrola hardware: szafy sterownicze, okablowanie, zabezpieczenia
FAT to najlepszy moment, aby sprawdzić jakość wykonania części elektrycznej i automatyki. Wszystko, co da się poprawić na stole, jest tańsze niż poprawki na hali produkcyjnej.
Podczas kontroli hardware warto zwrócić uwagę na:
- zgodność z dokumentacją elektryczną (schematy, listy kablowe, layout szafy),
- oznaczenia przewodów, zacisków, aparatów – czy są czytelne, trwałe, zgodne z numeracją w schematach,
- porządek w szafie: prowadzenie przewodów, odseparowanie zasilania mocy od sygnałowego, promienie gięcia,
- dobór zabezpieczeń: wyłączniki, bezpieczniki, przekaźniki bezpieczeństwa, ich charakterystyki i selektywność,
- dostępność elementów do serwisu – czy kluczowe aparaty da się wymienić bez demontażu połowy szafy.
Praktyczny test to wspólne przejście po szafie ze schematem i sprawdzenie losowo wybranych obwodów: zasilanie, wyjścia, wejścia, sygnały bezpieczeństwa. Każde rozbieżności należy od razu oznaczać i wpisywać do listy uwag FAT.
Testowanie logiki PLC i wizualizacji HMI/SCADA
Najwięcej problemów w automatyce wynika z błędów w logice sterowania oraz niedopracowanej wizualizacji. FAT pozwala przetestować większość scenariuszy bez ryzyka uszkodzenia sprzętu, wykorzystując symulatory, emulatory lub częściowo zmontowany układ.
Zakres testów logiki PLC powinien obejmować m.in.:
- sekwencje startu i zatrzymania linii, w tym start po różnych typach zatrzymań (normalne, awaryjne, E-Stop),
- przejścia między trybami pracy: ręczny, półautomatyczny, automatyczny, serwisowy,
- obsługę sygnałów z czujników, enkoderów, krańcówek – także w przypadkach wartości błędnych,
- działanie blokad wzajemnych (interlocków) między napędami, urządzeniami, modułami linii,
- sposób realizacji receptur, parametrów, limitów – czy zmiany parametrów są bezpieczne i logicznie spójne.
W przypadku HMI/SCADA w trakcie FAT należy zweryfikować:
- logikę ekranów – czy operator łatwo znajdzie najważniejsze funkcje i informacje,
- czytelność komunikatów alarmowych (konkretne opisy, wskazanie miejsca problemu, podpowiedzi działań),
- dostęp do historii alarmów i trendów, możliwość diagnozy bez udziału programisty,
- role i poziomy uprawnień użytkowników (operator, mistrz, utrzymanie ruchu, automatyk),
- konfigurację języków, jednostek, formatów daty, jeśli system działa w środowisku międzynarodowym.
Bardzo dobrym podejściem jest przeprowadzenie krótkiej „symulowanej zmiany” – przejście krok po kroku procesu tak, jak zrobiłby to operator, i obserwowanie, czy interfejs go wspiera, czy raczej przeszkadza.
Bezpieczeństwo funkcjonalne i reakcje awaryjne
Nawet jeśli pełnych testów bezpieczeństwa nie da się wykonać w całości u dostawcy, FAT powinien pokrywać logikę i strukturę systemu bezpieczeństwa. Zaniedbania w tym obszarze generują nie tylko koszty, ale i realne ryzyko wypadków oraz kary ze strony inspekcji.
Podczas FAT należy przetestować co najmniej:
- działanie wszystkich wyłączników awaryjnych (E-Stop) – czy odcinają właściwe obwody i powodują oczekiwany stan bezpieczny,
- logikę kurtyn bezpieczeństwa, skanerów, wyłączników krańcowych na drzwiach osłonowych,
- integrację systemu bezpieczeństwa z PLC standardowym (np. blokady trybów pracy, reset, potwierdzenia),
- reakcję na przerwanie pętli bezpieczeństwa, zwarcia, zaniki sygnałów,
- zachowanie systemu po zaniku i powrocie zasilania – czy nie następuje automatyczny restart bez kontroli.
Ważne jest także sprawdzenie, czy logika bezpieczeństwa jest udokumentowana: schemat blokowy, opis funkcji, lista wejść i wyjść bezpieczeństwa. Przy ewentualnych audytach lub modyfikacjach będzie to nieoceniona pomoc.
Testy komunikacji i integracji z innymi systemami
Coraz rzadziej system sterowania działa w oderwaniu od reszty fabryki. FAT powinien więc uwzględniać jak najpełniejszą symulację środowiska docelowego: nadrzędnych systemów IT, innych sterowników, wag, drukarek, skanerów czy systemów traceability.
Przygotowując i realizując testy komunikacji, skoncentruj się na kilku obszarach:
- protokoły i topologie – konfiguracja EtherNet/IP, Profinet, Modbus TCP/RTU, OPC UA, Profibus itp., adresacja, VLAN-y, sposób redundancji,
- mapa danych – zgodność struktur, typów zmiennych, skalowania sygnałów z ustalonym interfejsem,
- odporność na błędy – reakcja systemu na utratę łączy, opóźnienia, nieprawidłowe ramki, brak odpowiedzi serwera lub klienta,
- integracja z MES/ERP/WMS/LIMS – poprawność przesyłania zleceń, wyników produkcji, śledzenia partii, prac serwisowych,
- bezpieczeństwo sieciowe – uprawnienia, separacja sieci produkcyjnej od biurowej, obsługa użytkowników domenowych (jeśli dotyczy).
Jeżeli w czasie FAT fizycznie nie ma wszystkich urządzeń, stosuj symulatory i emulatory: wirtualne serwery OPC, generatory sygnałów z wag czy drukarek etykiet. Ważne, by logika reagowała na typowe i nietypowe sytuacje komunikacyjne, a nie tylko na idealnie działającą sieć.
Dobrym nawykiem jest również przygotowanie macierzy interfejsów – tabeli pokazującej, który system wymienia jakie dane, w jakim kierunku i z jaką częstotliwością. Na jej podstawie łatwo zaplanować konkretne przypadki testowe.
Symulacja typowych i skrajnych scenariuszy procesu
Sam test sekwencji „start – produkcja – stop” to zdecydowanie za mało. FAT powinien obejmować możliwie szeroki wachlarz scenariuszy – od codziennych po skrajne, które zdarzają się kilka razy do roku, a generują największy bałagan.
Podczas przygotowania FAT połącz siły integratora i użytkownika. Wspólnie wybierz zestaw scenariuszy, które odzwierciedlają realne życie linii:
- zmiana formatu, receptury, paletyzacji w trakcie trwania zmiany produkcyjnej,
- planowy postój na czyszczenie i ponowne uruchomienie z buforami pełnymi półproduktu,
- brak surowca w jednym z kluczowych punktów (np. pusta waga, brak etykiet w aplikatorze),
- odmienne partie surowca, zmiana dostawcy, różne parametry wejściowe,
- symulacja „prawie awarii” – np. zakłócenia na enkoderze, niestabilny sygnał z czujnika, chwilowe wahania ciśnienia.
Kluczowe jest, aby podczas FAT dokładnie opisać zaobserwowane zachowania: czasy reakcji, liczbę komunikatów, czytelność informacji dla operatora, wpływ na jakość produktu. Te zapisy stają się później odniesieniem dla SAT – wiadomo, czy to, co działało na stole, działa tak samo w realnych warunkach.
Walidacja raportów, archiwizacji danych i śledzenia produkcji
W wielu zakładach to właśnie raporty i dane z systemu decydują o możliwości sprzedaży produktu i spełnieniu wymogów klienta lub audytora. Sprawdzenie ich dopiero w trakcie SAT kończy się nerwową przepinką baz danych i gorączkowym szukaniem brakujących pól.
Podczas FAT zweryfikuj, czy system zapewnia:
- kompletność danych – wszystkie wymagane przez jakość, BHP i klienta końcowego parametry są rejestrowane (temperatury, czasy, identyfikatory partii, użytkownicy, wersje receptur),
- spójność i czytelność raportów – nazwy pól, jednostki, sposób grupowania danych, możliwość filtrowania po kluczowych kryteriach,
- ciągłość archiwizacji – co dzieje się z danymi przy braku łączności z serwerem bazodanowym, po restarcie systemu, przy przełączaniu redundancji,
- traceability – możliwość odtworzenia dla dowolnej partii historii parametrów procesu i zdarzeń (alarmy, zmiany receptur, interwencje operatora).
Dobrym pomysłem jest przejście konkretnego, zamkniętego zlecenia produkcyjnego przez system podczas FAT, a następnie wygenerowanie wszystkich kluczowych raportów, które będą używane w zakładzie. Dzięki temu szybko widać braki w polach, nazewnictwie czy strukturze danych.
Dokumentacja po FAT i zarządzanie listą uwag
Nawet najlepiej przygotowany FAT generuje uwagi i drobne poprawki. Sposób ich zapisu i rozliczenia decyduje, czy po kilku tygodniach wszyscy pamiętają, co uzgodniono, czy rozgorzeje dyskusja „mieliśmy tak ustalić czy inaczej?”.
Po stronie dostawcy i użytkownika powinien powstać spójny zestaw dokumentów związanych z FAT:
- protokół FAT z listą wykonanych testów (odwołanie do scenariuszy, check-list, raportów),
- lista uwag / niezgodności, z priorytetem i klasyfikacją (krytyczne, istotne, kosmetyczne),
- plan działań korygujących – kto, do kiedy i w jakim zakresie wprowadza zmiany,
- uzgodniony sposób potwierdzenia poprawek (zrzuty ekranu, test zdalny, dodatkowy mini-FAT, akceptacja mailowa).
Sprawdzonym narzędziem jest prosta tabela „action list” prowadzona wspólnie, najlepiej w narzędziu, do którego obie strony mają bieżący dostęp. Każdy punkt z listy powinien mieć status (otwarty, w trakcie, do weryfikacji, zamknięty) oraz osobę odpowiedzialną. Przy SAT można łatwo odfiltrować pozycje „do weryfikacji” i w ciągu krótkiego czasu sprawdzić, czy wszystko zostało wykonane.
Jak przygotować się do SAT – warunki, bez których testy się nie udadzą
Minimalne wymagania techniczne i organizacyjne przed startem SAT
Spora część nieudanych SAT wynika nie z błędów systemu sterowania, lecz z tego, że linia i otoczenie nie są gotowe do testów. Brak mediów, niedokończony montaż, nieuzgodnione receptury – i cały harmonogram SAT się rozpada.
Przed wyznaczeniem wiążącej daty SAT ustal i zapisz w umowie listę warunków brzegowych, np.:
- kompletność montażu mechanicznego, w tym osłon, wygrodzeń, dojść serwisowych,
- dostępność i stabilność mediów: zasilanie elektryczne, sprężone powietrze, woda, para, próżnia itp. w wymaganych parametrach,
- wykonane i udokumentowane próby szczelności, próby ciśnieniowe i inne testy powykonawcze po stronie instalacji,
- dostępność materiałów produkcyjnych i opakowaniowych (także słabszej jakości, aby odwzorować gorsze partie),
- gotowość systemów nadrzędnych (MES, ERP, WMS) do połączeń testowych lub przygotowane tryby offline.
Na tym etapie przydaje się prosta check-lista SAT, którą podpisuje kierownik projektu po stronie użytkownika. Jeżeli którykolwiek z kluczowych punktów nie jest spełniony, lepiej przesunąć SAT, niż tracić kilka dni specjalistów na próby uruchomienia linii „na pół gwizdka”.
Skład zespołu SAT i podział odpowiedzialności
SAT to moment, w którym spotykają się różne perspektywy: automatyka, utrzymanie ruchu, produkcja, jakość, BHP, IT, a czasem także przedstawiciel klienta końcowego. Jeśli na hali pojawi się tylko kierownik projektu i programista PLC, testy szybko skręcą wyłącznie w stronę technikaliów.
Warto z wyprzedzeniem ustalić, kto jest decyzyjny w jakich obszarach oraz jak długo ma być obecny na SAT:
- automatyk / integrator – odpowiedzialny za logikę, HMI/SCADA, diagnozę problemów, wprowadzanie drobnych korekt,
- utrzymanie ruchu – ocena serwisowalności, dostępności do elementów, logiki diagnostyki,
- operatorzy – weryfikacja ergonomii, intuicyjności, obciążenia pracą,
- jakość i BHP – odbiór raportowania, blokad, systemu bezpieczeństwa i procedur,
- IT / OT – konfiguracja sieci, dostępów, integracja z systemami nadrzędnymi, kopie zapasowe.
Dobrą praktyką jest wyznaczenie jednej osoby po stronie użytkownika, która zbiera uwagi od wszystkich działów i formalnie przekazuje je do dostawcy. Ogranicza to ryzyko, że automatyk będzie dostawał sprzeczne życzenia od pięciu osób naraz.
Scenariusze SAT – od rozruchu na sucho do pełnej produkcji
SAT nie powinien być spontaniczną listą prób „zobaczmy, co się stanie, jak…”. Przed startem testów przygotuj i uzgodnij z dostawcą strukturyzowany plan SAT, który krok po kroku przechodzi przez kolejne poziomy obciążenia systemu.
Przykładowa sekwencja może wyglądać następująco:
- testy na sucho – sprawdzenie sygnałów wejść/wyjść, poprawności działania napędów bez produktu, test E-Stop, blokad osłon, procedur rozruchu,
- testy z produktem bez wymagań jakościowych – stopniowe zwiększanie prędkości, weryfikacja zachowania buforów, systemu sortowania, mechanizmów odrzutów,
- produkcja próbna – w warunkach zbliżonych do docelowych, z udziałem jakości i operatorów docelowej zmiany,
- testy wydajnościowe – ciągła praca przez określony czas, np. całą zmianę, z pomiarem kluczowych wskaźników (OEE, zdolność linii do pracy przy zadanym takcie),
- testy awaryjne – kontrolowane wywoływanie typowych problemów (brak etykiet, zatrzymanie jednego modułu, odłączenie jednego z systemów komunikacyjnych).
Każdy etap powinien mieć jasno określone kryteria przejścia dalej (np. maksymalna liczba awarii na zmianę, brak błędów krytycznych, akceptacja jakościowa produktu). Jeżeli kryteria nie są spełnione, zespół wspólnie decyduje, czy powtarza etap, czy modyfikuje plan.
Weryfikacja BHP i procedur operacyjnych na obiekcie
System bezpieczeństwa może działać poprawnie z punktu widzenia funkcji bezpieczeństwa (SIL/PL), a jednocześnie być zupełnie niewygodny lub wręcz prowokować obchodzenie zabezpieczeń. SAT to czas na krytyczne spojrzenie na codzienną pracę z maszyną.
Podczas odbioru na obiekcie sprawdź z zespołem BHP i operatorami m.in.:
- czy dostęp do stref niebezpiecznych jest właściwie ograniczony, a jednocześnie umożliwia sensowny serwis i czyszczenie,
- czy procedury rozruchu po zadziałaniu E-Stop lub otwarciu osłony są jednoznaczne i zrozumiałe,
- czy sposób blokowania/odblokowania drzwi, wyłączników, trybów serwisowych nie zachęca do „tymczasowych” obejść,
- czy instrukcje stanowiskowe, piktogramy i oznaczenia na panelach są czytelne dla operatorów na różnych zmianach,
- czy szkolenie operatorów i utrzymania ruchu zostało zakończone i udokumentowane, a osoby faktycznie znają procedury.
Jeśli w trakcie SAT wyjdą na jaw niebezpieczne nawyki (np. blokowanie kurtyn, czyszczenie w ruchu), lepiej zmodyfikować logikę i procedury od razu, niż liczyć na to, że „ludzie się przyzwyczają”. To również dobry moment, by doprecyzować, które prace są wykonywane w trybie serwisowym i jakie dodatkowe środki ochronne są wtedy wymagane.
Testy wydajnościowe i stabilności systemu
System, który przechodzi test dwugodzinny, niekoniecznie zachowa się tak samo po kilku dniach ciągłej pracy. Szczególnie gdy mówimy o rozbudowanych układach SCADA, wielu interfejsach czy bazach danych, testy długotrwałe są kluczowe.
Podczas SAT zaplanuj przynajmniej jeden blok testowy, którego celem jest:
- sprawdzenie stabilności komunikacji i działania aplikacji przy pracy „non-stop”,
- obserwacja zużycia zasobów systemu (RAM, CPU, miejsce na dyskach, obciążenie sieci),
- monitoring liczby alarmów i zdarzeń – czy system nie generuje „szumu alarmowego” przy długotrwałej pracy,
- weryfikacja integralności danych historycznych – czy nie ma luk w zapisach, duplikatów, niespójności.
Dobrym wskaźnikiem jest, czy po kilkunastu godzinach pracy operator i utrzymanie ruchu czują się komfortowo z systemem, czy raczej notują długą listę „drobnych poprawkach”, które w praktyce blokują płynne działanie linii.
Typowe pułapki podczas FAT i SAT – oraz jak ich uniknąć
Najczęstsze problemy podczas FAT – przyczyny i sposoby reakcji
Problemy na etapie FAT rzadko są zaskoczeniem, jeśli wcześniej poświęcono czas na doprecyzowanie wymagań. Mimo to w praktyce regularnie powtarza się kilka scenariuszy, które potrafią wykoleić harmonogram projektu.
Do najczęstszych należą:
- rozjazd oczekiwań co do funkcjonalności – użytkownik zakłada możliwość ręcznej korekty danych czy dodatkowych raportów, których nikt nie wpisał do URS / FS,
- brak spójności standardów zakładowych – różne działy mają inne oczekiwania co do nazw alarmów, standardu ekranów HMI, protokołów komunikacyjnych,
- nieprzygotowane dane testowe – brak przykładowych receptur, kart produktów, struktur partii, co blokuje testy scenariuszy „z życia”,
- niedoszacowany czas na poprawki – założenie, że wszystko „przejdzie od razu”, bez zapasu na iteracje.
Najrozsądniejszą reakcją na takie sytuacje jest rozdzielenie tego, co jest defektem w stosunku do uzgodnionej specyfikacji, od tego, co stanowi nowe życzenie funkcjonalne. W praktyce dobrze działa prosty podział:
- uwagi wynikające z niespełnienia wymagań – wchodzą na listę działań korygujących i muszą zostać załatwione w ramach kontraktu,
- propozycje usprawnień – trafiają na osobną listę „change request”, z wyceną i terminem, do decyzji biznesowej po stronie użytkownika.
Takie uporządkowanie oszczędza wiele emocji. Integrator nie jest zasypywany żądaniami „na już”, a użytkownik ma jasność, które punkty są krytyczne dla odbioru, a które można odłożyć na kolejny etap.
Pułapki podczas SAT – dlaczego działające FAT nie gwarantuje sukcesu na obiekcie
Nawet świetnie przeprowadzony FAT nie chroni przed zaskoczeniami na hali. System zaczyna działać w prawdziwym środowisku, z autentycznymi produktami, ludźmi, procedurami i ograniczeniami przestrzennymi.
Typowe problemy, które wychodzą dopiero podczas SAT:
- inne zachowanie produktu niż w testach FAT – delikatne opakowania, gorsza sztywność kartonu, wilgotność, wpływają na pracę podajników i chwytaków,
- kolizja z przyzwyczajeniami operatorów – sekwencje start/stop różnią się od istniejących linii, co prowadzi do błędów obsługi,
- niewidoczne wcześniej wąskie gardła – sprzęt pomocniczy (drukarki, wagi, etykieciarki, systemy etykiet logistycznych) nie nadąża za linią główną,
- problemy sieciowe i z uprawnieniami – inne zabezpieczenia IT/OT w zakładzie niż w środowisku FAT, ograniczenia polityk bezpieczeństwa,
- ograniczona dostępność kluczowych osób – na zmianie testowej nie ma lidera produkcji, technologa czy kluczowego operatora, który później będzie realnym „właścicielem” linii.
Dobrym nawykiem jest zaplanowanie krótkiej sesji przeglądowej po pierwszym dniu SAT. Zespół projektowy zbiera wtedy informacje z hali i dzieli problemy na trzy grupy: do szybkich poprawek na miejscu, do dopracowania po SAT oraz do zmiany organizacyjnej (np. procedury, szkolenia, zmiana layoutu).
Błędy komunikacyjne między użytkownikiem a integratorem
Wiele konfliktów przy odbiorach nie wynika z samej technologii, lecz z niedomówień. Jeśli oczekiwania nie są spisane lub zmieniają się w trakcie, napięcie rośnie po obu stronach.
Najbardziej kłopotliwe są sytuacje, gdy:
- po stronie użytkownika brakuje jednego „właściciela wymagań”, a każdy dział ciągnie w swoją stronę,
- zmiany zakresu są komunikowane ustnie na spotkaniach na obiekcie, bez śladu w dokumentacji,
- brakuje wspólnego miejsca, gdzie prowadzone są wersje dokumentów (URS, FS, listy sygnałów, specyfikacje interfejsów),
- na FAT / SAT pojawiają się osoby, które po raz pierwszy widzą system i zgłaszają fundamentalne zastrzeżenia do koncepcji.
Rozwiązaniem jest konsekwentne stosowanie kilku prostych zasad:
- wszystkie kluczowe ustalenia z przeglądów, warsztatów, FAT i SAT trafiają do protokołów,
- każda propozycja zmiany zakresu jest oznaczona numerem CR (Change Request) i opisana – co, po co, jaki wpływ na harmonogram i koszt,
- po stronie użytkownika jest jedna osoba uprawniona do akceptacji zmian, aby uniknąć wzajemnie sprzecznych decyzji.
Jak dokumentować wyniki FAT i SAT, żeby nie wracać do spornych tematów
Struktura protokołów z testów
Dobrze przygotowany protokół z FAT lub SAT to nie tylko „lista podpisów”, ale realne narzędzie zarządzania ryzykiem. Zamiast wolnej narracji na kilku stronach lepiej zastosować ustrukturyzowaną formę.
W praktyce sprawdza się podział protokołu na sekcje:
- dane ogólne – data, miejsce, uczestnicy po obu stronach, zakres testowanej części systemu,
- lista wykonanych testów – odwołanie do scenariuszy FAT/SAT z informacją: test zaliczony / niezaliczony / zaliczony warunkowo,
- opis niezgodności – powiązany z konkretnymi numerami testów, z klasyfikacją i priorytetem,
- ustalenia końcowe – czy FAT/SAT został zakończony pozytywnie, warunkowo, czy wymaga powtórzenia po korektach,
- załączniki – zrzuty ekranu, nagrania krótkich filmów (linki), raporty z systemu, wydruki etykiet, wybrane logi.
W sekcji niezgodności dobrze jest od razu zaznaczyć, czy dany punkt blokuje przejście do kolejnego etapu. Pozwala to uniknąć sytuacji, w której drobna uwaga graficzna do ekranu HMI hamuje odbiór całego systemu.
Wykorzystanie materiałów wideo i zrzutów ekranu
Przy złożonych sekwencjach sterowania sama notatka tekstowa czasem nie oddaje sedna problemu. Krótkie nagranie lub seria zrzutów ekranu pokazuje więcej niż rozbudowany opis.
Materiały wizualne przydają się szczególnie, gdy:
- zespół integratora pracuje w innym kraju i nie jest obecny na SAT,
- problem występuje tylko przy określonej kombinacji warunków (np. przy zatrzymaniu jednej sekcji i restartcie innej),
- trzeba udokumentować rzadkie, chwilowe zjawisko, które trudno odtworzyć na żądanie.
Praktyczny sposób pracy: osoba testująca ma przygotowane proste narzędzie do nagrywania ekranu i robi krótkie, opisane pliki wideo (np. z numerem z action list). Link do materiału trafia do odpowiedniego punktu protokołu, co bardzo skraca czas diagnozy.
Ślad audytowy zmian po FAT / SAT
Po każdej rundzie testów pojawia się seria poprawek. Bez kontroli wersji łatwo zgubić się w tym, co zostało już wdrożone, a co dopiero jest w planie. Przy systemach podlegających audytom (farmacja, spożywka, automotive) jest to wręcz krytyczne.
Dobry ślad audytowy obejmuje:
- rejestr zmian w oprogramowaniu – kto, kiedy i co zmienił (numery wersji projektów PLC, HMI, SCADA, skrypty bazodanowe),
- powiązanie zmian z konkretnymi uwagami z FAT / SAT – np. poprzez numer z action list lub CR,
- opis zakresu testów regresyjnych – jakie scenariusze zostały powtórzone po wprowadzeniu zmian,
- akceptację zmian – osoba po stronie użytkownika, która potwierdziła poprawność wdrożenia.
W wielu firmach tę funkcję przejmuje system kontroli wersji (np. Git) lub moduły change control w systemach GxP. Nawet jednak prosty rejestr w postaci tabeli, prowadzony konsekwentnie, znacząco ułatwia życie przy późniejszych audytach lub rozbudowie systemu.
Planowanie FAT i SAT w harmonogramie projektu
Realistyczna estymacja czasu na testy
Przy planowaniu projektu automatyki pokusa jest jedna: maksymalnie skrócić czas na testy, aby szybciej dojść do „prawdziwego” uruchomienia. Doświadczenie pokazuje, że takie oszczędności wracają w postaci długiego, bolesnego rozruchu na obiekcie.
Przy określaniu czasu na FAT i SAT warto uwzględnić m.in.:
- wielkość i złożoność systemu (liczba napędów, węzłów komunikacyjnych, interfejsów do innych systemów),
- wymagania regulacyjne i walidacyjne (dodatkowe testy, dokumentacja, przeglądy),
- dostępność kluczowych osób po stronie użytkownika – jeśli mogą być tylko kilka godzin dziennie, testy muszą trwać dłużej,
- czas na iteracje poprawek między kolejnymi „podejściami” do testów.
Przy małych aplikacjach HMI/PLC czas FAT można liczyć w godzinach, ale przy rozbudowanych liniach, wielu stacjach i interfejsach kilka dni na FAT i kilka na SAT to norma, nie luksus.
Bufor czasowy na poprawki po FAT
Między zakończeniem FAT a wysyłką sprzętu na obiekt powinien istnieć realny bufor na poprawki. Jeśli transport zaplanowany jest na „dzień po FAT”, integrator nie ma żadnego pola manewru, aby spokojnie wdrożyć uzgodnione zmiany.
Rozsądny model to:
- planowane zakończenie głównej części FAT,
- kilka dni roboczych na poprawki, uzupełnienia dokumentacji i testy wewnętrzne,
- dopiero potem demontaż, pakowanie i wysyłka.
W projektach, gdzie logistykę trzeba rezerwować z dużym wyprzedzeniem (transport ponadgabarytowy, montaż dźwigów), warto ustalić okno wysyłki zamiast sztywnej daty. Minimalizuje to presję „zaakceptowania wszystkiego jak leci”, tylko po to, aby nie stracić terminu.
Koordynacja FAT/SAT z innymi działaniami w projekcie
FAT i SAT nie dzieją się w próżni. Wokół nich toczą się prace budowlane, montaż mechaniczny, instalacyjny, migracje IT, szkolenia, walidacje jakości. Brak synchronizacji tych strumieni powoduje wielodniowe przestoje.
Podczas układania harmonogramu warto skoordynować:
- terminy FAT z dostępnością urządzeń krytycznych (np. specyficzne czujniki, serwonapędy, komponenty bezpieczeństwa),
- terminy SAT z oknami postoju produkcji i innymi projektami na tej samej linii lub w tym samym obszarze zakładu,
- plany testów z kalibracjami i kwalifikacjami urządzeń (np. w farmacji, spożywce),
- szkolenia personelu z okresami testów produkcyjnych, tak aby operatorzy uczyli się na faktycznie działającym systemie, a nie tylko na prezentacji.
Integracja FAT i SAT z wymaganiami jakościowymi i regulacyjnymi
Powiązanie testów z URS, FS i dokumentacją jakości
W branżach regulowanych (GxP, automotive, spożywcza z certyfikacją BRC/IFS) FAT i SAT to fragment szerszego łańcucha dokumentacji. Jeśli testy nie są logicznie powiązane z URS (User Requirements Specification) i FS (Functional Specification), walidacja szybko zamienia się w chaos.
Przejrzysty model to:
- każde wymaganie z URS ma swój numer i opis kryterium akceptacji,
- FS opisuje, jak wymaganie zostanie zrealizowane w systemie (np. konkretne ekrany, alarmy, sekwencje),
- scenariusze FAT i SAT odwołują się do tych samych numerów wymagań, pokazując, gdzie i jak zostały przetestowane.
Przy audycie nie trzeba wtedy gorączkowo szukać, „gdzie my to właściwie sprawdzaliśmy”. Audytor widzi ciąg: wymaganie → implementacja → test → wynik → ewentualna korekta.
Rola FAT/SAT w kwalifikacjach IQ/OQ/PQ
W projektach podlegających formalnej kwalifikacji sprzętu i oprogramowania, wyniki FAT i SAT są cennym elementem materiału dowodowego. Część testów z FAT można włączyć do kwalifikacji montażowej (IQ), a część z SAT – do kwalifikacji operacyjnej (OQ) i wydajnościowej (PQ).
Przykładowy podział:
- IQ – potwierdzenie zgodności montażu i konfiguracji z dokumentacją: listy sygnałów, topologia sieci, ustawienia serwerów, wersje oprogramowania,
- Testy FAT i SAT są kluczowym narzędziem zarządzania ryzykiem technicznym i finansowym, bo pozwalają wykryć błędy przed rozruchem i uniknąć kosztownych poprawek na działającej instalacji.
- FAT u dostawcy służy weryfikacji hardware’u, logiki sterowania, funkcji bezpieczeństwa i kompletności dokumentacji w kontrolowanych warunkach przed wysyłką systemu.
- SAT na obiekcie potwierdza poprawność działania systemu w rzeczywistych warunkach produkcyjnych, integrację z innymi systemami oraz spełnienie wymagań dotyczących wydajności, jakości i BHP.
- FAT i SAT badają często podobne funkcje, ale w innym kontekście: FAT ogranicza ryzyko techniczne przed wysyłką, a SAT decyduje o dopuszczeniu systemu do pracy produkcyjnej.
- Kluczowe jest precyzyjne zdefiniowanie zakresu FAT i SAT w umowie oraz specyfikacji technicznej (lista testowanych funkcji, scenariuszy, kryteria akceptacji, sposób pomiaru, wymagane dokumenty).
- Nieprecyzyjne, ogólnikowe zapisy typu „system ma działać poprawnie” prowadzą do sporów przy odbiorze; wymagania muszą być mierzalne i jednoznaczne.
- Dobrze zaplanowane i konsekwentnie przeprowadzone FAT i SAT są warunkiem spokojnego rozruchu, rzetelnego odbioru końcowego oraz uczciwych rozliczeń i gwarancji.
Najczęściej zadawane pytania (FAQ)
Co to jest test FAT w automatyce przemysłowej i po co się go wykonuje?
Test FAT (Factory Acceptance Test) to odbiór systemu automatyki u dostawcy – w fabryce integratora, producenta maszyny czy szafy sterowniczej. Celem jest potwierdzenie, że system spełnia wymagania funkcjonalne i jakościowe zanim zostanie wysłany do zakładu produkcyjnego.
Podczas FAT sprawdza się m.in. poprawność wykonania szaf sterowniczych i okablowania, konfigurację PLC, HMI i SCADA, działanie logiki sterowania na symulatorach oraz funkcje bezpieczeństwa, o ile pozwalają na to warunki u dostawcy. Im więcej błędów zostanie wykrytych na tym etapie, tym mniej kosztownych poprawek będzie potrzebnych na obiekcie.
Co to jest test SAT i czym różni się od FAT?
SAT (Site Acceptance Test) to testy odbiorowe prowadzone na docelowym obiekcie – w rzeczywistym środowisku pracy zakładu. Sprawdza się w nich, czy system wpięty w instalacje zasilania, media, inne linie oraz systemy nadrzędne działa zgodnie z wymaganiami biznesowymi i technicznymi.
Kluczowa różnica polega na środowisku: FAT odbywa się w warunkach kontrolowanych u dostawcy, często z użyciem symulatorów, a SAT w realnych warunkach produkcyjnych. FAT ogranicza głównie ryzyko techniczne przed wysyłką, natomiast SAT decyduje o dopuszczeniu systemu do pracy produkcyjnej.
Dlaczego testy FAT i SAT są tak ważne w projektach automatyki?
Największe koszty w projektach automatyki generują nie montaż ani programowanie, lecz poprawki po uruchomieniu systemu na produkcji. Błędy wykryte po starcie linii oznaczają przestoje, chaos organizacyjny i dodatkowe koszty serwisu.
Dobrze przygotowane i przeprowadzone FAT oraz SAT pozwalają wychwycić większość problemów zanim system zacznie pracować w trybie produkcyjnym. Dzięki temu zmniejsza się ryzyko awarii w pierwszych miesiącach eksploatacji oraz spory kontraktowe między użytkownikiem a dostawcą.
Co powinno znaleźć się w zakresie testów FAT i SAT w umowie?
Zakres FAT i SAT powinien być opisany w umowie możliwie precyzyjnie – jedno zdanie „dostawca przeprowadzi FAT i SAT” to proszenie się o konflikty. W dokumentacji kontraktowej należy określić m.in. listę funkcji i modułów podlegających testom, scenariusze testowe oraz szczegółowe kryteria akceptacji (np. czasy cykli, dopuszczalna liczba błędów, czasy reakcji systemu).
Warto też zdefiniować sposób pomiaru parametrów (narzędzia, dokładność, odpowiedzialność za ich dostarczenie), podział zadań między dostawcę a użytkownika (media, materiały testowe, dostęp do innych systemów) oraz wymagania dotyczące dokumentacji testów – protokołów, checklist i raportów.
Jak zaplanować harmonogram testów FAT i SAT, żeby uniknąć opóźnień?
FAT i SAT powinny być osobnymi kamieniami milowymi w harmonogramie projektu, z przypisanym czasem trwania i rezerwą na poprawki. Konieczne jest uwzględnienie czasu na przygotowanie FAT po stronie dostawcy (montaż, wstępne uruchomienie), czasu na usunięcie usterek po FAT oraz buforu między dostawą systemu a rozpoczęciem SAT.
Należy też zadbać o właściwą kolejność: SAT ma sens dopiero wtedy, gdy infrastruktura zakładu (media, linie, integracje z innymi systemami) jest gotowa. Już na etapie planowania trzeba określić, kto ze strony klienta i dostawcy będzie obecny na poszczególnych etapach testów (automatycy, UR, operatorzy, BHP, jakość).
Jaka jest rola użytkownika końcowego w przygotowaniu testów FAT i SAT?
Użytkownik końcowy nie powinien ograniczać się do biernego uczestnictwa w testach. To po jego stronie leży dostarczenie wiedzy o procesie: typowych scenariuszy produkcyjnych, trudnych przypadków (awarie, zmiany partii surowca, przerwy w dostawach mediów) oraz wymagań działów jakości i BHP dotyczących raportowania i blokad.
Jeśli użytkownik nie wniesie swojego doświadczenia do przygotowania FAT i SAT, testy ograniczą się do sprawdzenia poprawności pracy PLC i HMI, zamiast zweryfikować rzeczywistą przydatność systemu w codziennej produkcji i eliminację dotychczasowych problemów procesu.
