Jak krok po kroku przeprowadzić FAT i SAT systemu automatyki, od konfiguracji po końcowe testy odbiorowe

Różnice między FAT a SAT i po co je robić

Intencją inżyniera, który przygotowuje testy FAT i SAT systemu automatyki, jest zapanowanie nad ryzykiem – technicznym, czasowym i finansowym. Dobrze przygotowany i przeprowadzony FAT (Factory Acceptance Test) oraz SAT (Site Acceptance Test) pozwala spokojnie obronić zakres, jakość i wyniki uruchomienia przed klientem, audytorem czy działem jakości.

Testy FAT systemu automatyki i testy SAT na obiekcie pełnią różne role. Razem tworzą logiczną całość: od sprawdzenia, czy sterownik, HMI i oprogramowanie PLC działają zgodnie z założeniami, po weryfikację całego procesu, okablowania i bezpieczeństwa maszyn podczas testów w realnych warunkach.

Definicje i zakres – co wchodzi w FAT, a co w SAT

FAT (Factory Acceptance Test) to formalny zestaw testów odbiorowych wykonywanych po stronie integratora lub producenta maszyny, zanim system trafi na docelowy obiekt. FAT dotyczy głównie:

• logiki sterowania (walidacja oprogramowania PLC),
• interfejsów operatora HMI i SCADA,
• komunikacji z napędami, modułami I/O, nadrzędnymi systemami,
• symulacji sygnałów I/O i podstawowych scenariuszy procesowych,
• wstępnego sprawdzenia funkcji bezpieczeństwa w zakresie możliwym na stanowisku testowym.

FAT ma charakter laboratoryjny: instalacja jest częściowo lub w pełni zmontowana w warunkach warsztatowych, część urządzeń procesowych jest zastąpiona symulatorami lub atrapami. Tu testuje się, czy system sterowania robi dokładnie to, co opisuje FDS/SDS, zanim zacznie sterować prawdziwą linią produkcyjną.

SAT (Site Acceptance Test) to odbiór systemu już na obiekcie docelowym – z prawdziwymi maszynami, rzeczywistym procesem i pełnym okablowaniem. SAT obejmuje z reguły:

• weryfikację poprawności instalacji (okablowanie, przyłącza, adresacja),
• testy integracyjne sygnałów I/O „na żywo”,
• testy procesowe z medium, produktem lub ruchem (w zależności od branży),
• pełne testy systemów bezpieczeństwa, zatrzymań awaryjnych, blokad,
• sprawdzenie wszystkich scenariuszy przewidzianych w planie testów odbiorowych na obiekcie.

Różnicę można podsumować prosto: FAT sprawdza, czy system został zrobiony zgodnie z założeniami, SAT – czy działa poprawnie tam, gdzie ma pracować.

Perspektywa integratora, klienta i producenta maszyn

Każda strona uczestnicząca w projekcie patrzy na FAT i SAT przez nieco inny pryzmat:

Integrator systemu sterowania postrzega FAT jako ostatnią szansę, aby:

• wyeliminować błędy w logice i konfiguracji komunikacji,
• ustalić z klientem interpretację wymagań URS,
• przetestować nietypowe scenariusze awaryjne w bezpiecznych warunkach,
• zredukować czas uruchomienia na obiekcie.

Dla integratora SAT jest testem jego przygotowania oraz jakości. Nowe błędy wykryte na SAT to zwykle koszt dodatkowych godzin, stres ekipy i napięcia w relacji z użytkownikiem.

Klient / użytkownik końcowy widzi FAT jako okazję do:

• sprawdzenia, czy system odpowiada jego procesowi i przyzwyczajeniom operatorów,
• wprowadzenia ostatnich, drobnych korekt ergonomii HMI, raportów, alarmów,
• potwierdzenia, że wymagania URS/FDS są faktycznie implementowane,
• nauczenia się systemu jeszcze przed jego dostawą.

Podczas SAT klient ocenia przede wszystkim przydatność i niezawodność w praktyce. Liczy się czas rozruchu, stabilność procesu i brak „niespodzianek”, które zatrzymają produkcję.

Producent maszyny (jeśli jest oddzielny od integratora) traktuje FAT jako:

• weryfikację, że jego urządzenie poprawnie współpracuje z systemem sterowania,
• okazję do złapania błędów mechanicznych, hydrauli- czy pneumatycznych przed wysyłką,
• moment formalnego przekazania odpowiedzialności za część zakresu.

Główne różnice: miejsce testów, integracja, ryzyko zmian

Najbardziej praktyczne różnice między FAT a SAT sprowadzają się do trzech osi: lokalizacji, poziomu integracji oraz .

• Miejsce wykonania: FAT – u integratora/producenta, SAT – u klienta na obiekcie.
• Stopień integracji: w FAT często używa się symulatorów i częściowego okablowania; SAT to pełen proces z realnymi mediami, produktami, ruchem.
• Ryzyko i koszt zmian: błędy odkryte w FAT są zwykle tanie do poprawy; błędy odkryte w SAT bezpośrednio wpływają na harmonogram uruchomienia i przestoje, a więc kosztują realne pieniądze.

Wpływ FAT i SAT na harmonogram, budżet i podejście testowe

Mechanizm jest prosty: im mocniejszy i lepiej przygotowany FAT, tym krótszy i spokojniejszy SAT. Są jednak branże i projekty, w których trudno o bardzo rozbudowany FAT – na przykład tam, gdzie proces jest silnie zależny od trudnych do zasymulowania mediów (przemysł chemiczny, niektóre linie pakujące).

Można wyróżnić dwa skrajne podejścia:

• Mocny FAT + krótki SAT – polecany, gdy:
  • da się zbudować pełne stanowisko FAT (szafa, większość napędów, symulowane procesy),
  • system ma złożoną logikę i dużo scenariuszy awaryjnych,
  • koszt przestoju obiektu jest bardzo wysoki (np. procesy ciągłe).
• Minimalny FAT + rozbudowany SAT – stosowany, gdy:
  • sprzęt jest trudno przenośny lub nietestowalny poza obiektem (duże linie, ciężkie maszyny),
  • logika sterowania jest stosunkowo prosta,
  • klient dysponuje oknem przestojowym i akceptuje dłuższy rozruch.

W praktyce najlepiej sprawdza się rozwiązanie pośrednie: maksymalnie silny FAT w obszarach, które da się dobrze zasymulować (logika, sekwencje, komunikacja, HMI) i świadomie zaplanowany rozbudowany SAT w obszarach zależnych od realnego procesu (media, produkt, warunki pracy).

Przygotowanie do FAT – od wymagań do planu testów

Udane testy FAT systemu automatyki zaczynają się na długo przed pierwszym podaniem napięcia na szafę. Kluczowe są: prawidłowe przełożenie wymagań użytkownika na plan testów odbiorowych oraz wczesne uzgodnienie zakresu z klientem, tak aby na sali testowej nie pojawiły się spory interpretacyjne.

Interpretacja specyfikacji użytkownika (URS) i wymagań funkcjonalnych

Dokumenty stanowiące punkt wyjścia:

• URS (User Requirements Specification) – język użytkownika: co system ma robić, jakie są cele procesu, ograniczenia, ergonomia.
• FDS (Functional Design Specification) – opis funkcjonalny: jak system ma realizować wymagania URS, struktura sekwencji, logika sterowania.
• SDS (Software Design Specification) lub odpowiednik – szczegóły implementacyjne: moduły programowe, bloki funkcyjne, struktura zmiennych.

Pierwszy krok to mapowanie wymagań URS na konkretne testy FAT. Dla każdego wymagania warto odpowiedzieć na kilka pytań:

• Jakie zachowanie systemu potwierdza spełnienie tego wymagania?
• Jakie warunki początkowe muszą być spełnione, by test miał sens?
• Jakie sygnały I/O i ekrany HMI biorą udział w tym wymaganiu?
• Czy wymóg lepiej sprawdzić w FAT, w SAT, czy w obu etapach?

Przykład z praktyki: URS mówi „linia ma zatrzymywać się w sposób kontrolowany w przypadku utraty komunikacji z falownikiem podajnika głównego”. Dla FAT interpretacja może wyglądać tak:

• w FDS opisano scenariusz: wykrycie błędu komunikacji → alarm → zatrzymanie sekwencji,
• w FAT: zasymulowanie błędu komunikacji (np. odłączenie przewodu sieciowego w warunkach testowych lub wymuszenie błędu w symulatorze napędu),
• w SAT: powtórzenie testu na obiekcie z faktyczną komunikacją i pracującym napędem.

Warto, aby już na etapie analizy URS pojawiła się lista wymagań krytycznych bezpieczeństwa i wymagań procesowych, które obligatoryjnie muszą być testowane zarówno w FAT, jak i w SAT – by nie pozostawiać tych punktów bez potwierdzenia w realnych warunkach.

Tworzenie planu FAT – struktura i minimalna zawartość

Dobry plan FAT jest jednocześnie szczegółowy i czytelny. Najczęściej zawiera:

• Cel i zakres – czego dotyczy FAT, jakie moduły systemu wchodzą w testy, czego nie obejmuje.
• Odniesienie do dokumentów – URS, FDS, SDS, schematy elektryczne, P&ID, listy I/O.
• Lista funkcji do przetestowania – zwykle w formie tabeli lub listy przypadków testowych.
• Kryteria akceptacji – dla całego FAT i dla poszczególnych testów.
• Rola i odpowiedzialność – kto testuje, kto obserwuje ze strony klienta, kto zatwierdza wyniki.
• Harmonogram – orientacyjne czasy na poszczególne bloki FAT, ewentualne powiązanie z dostawami sprzętu.
• Procedura zgłaszania niezgodności – jak rejestrowane są błędy, kto decyduje o ich klasyfikacji.

Struktura przypadków testowych powinna być powtarzalna. Przykładowy rekord:

• ID testu (np. FAT-LT-001)
• Opis funkcji (np. „Ręczne sterowanie podajnikiem 1 z HMI”)
• Powiązane wymagania (URS-12, FDS-4.3)
• Warunki początkowe (napięcie załączone, brak alarmów, tryb RĘCZNY)
• Kroki testu (1–3 jasnych poleceń)
• Oczekiwane wyniki (z zachowaniem mierzalności: „podajnik startuje w czasie < 1 s od kliknięcia”, „ikonka zmienia kolor na zielony”)
• Miejsce na wynik (OK / NIE OK + komentarz)

Taki poziom szczegółowości planu FAT pozwala nowej osobie w zespole zrozumieć, jak przeprowadzić konkretny test bez zgadywania intencji projektanta.

Dobór poziomu szczegółowości – testy modułowe, integracyjne, scenariusze procesowe

Plan FAT powinien łączyć trzy typy testów:

1. Testy modułowe – sprawdzają pojedyncze elementy:
   • wejścia/wyjścia fizyczne,
   • pojedyncze ekrany HMI,
   • pojedyncze bloki funkcyjne (np. sterowanie jednym napędem).
2. Testy integracyjne – sprawdzają współpracę modułów:
   • komunikacja PLC–napędy–I/O,
   • kompletny podukład linii (np. strefa podawania, strefa sortowania).
3. Scenariusze procesowe – odwzorowują realne sytuacje:
   • rozruch linii z zimnego startu,
   • planowane zatrzymanie produkcji,
   • typowe zakłócenia (brak materiału, zadziałanie wyłącznika awaryjnego, utrata czujnika).

Przy doborze proporcji między tymi poziomami testowania dobrze zadziała proste kryterium: im bardziej krytyczna funkcja (bezpieczeństwo, jakość produktu, ciągłość procesu), tym więcej warstw testów powinna przejść – od modułowych, przez integracyjne, aż po pełny scenariusz procesowy. Dla mniej istotnych funkcji (np. pomocnicze ekrany raportowe) zwykle wystarczy test modułowy i krótki test integracyjny z resztą systemu.

Inaczej rozkładają się akcenty w projektach typu „brownfield” i „greenfield”. W modernizacji istniejącej linii (brownfield) zwykle jest mało czasu na SAT, więc opłaca się mieć więcej testów integracyjnych już w FAT i mocno rozbudowane scenariusze procesowe z symulacją. W nowych instalacjach (greenfield), gdzie rozruch i tak będzie długi, można część scenariuszy zostawić na SAT, a na FAT skupić się na testach modułowych i integracyjnych krytycznych podukładów.

Dobrym wyznacznikiem jakości planu jest to, czy osoba z zewnątrz, patrząc jedynie na listę testów, potrafi odgadnąć, jak wygląda typowy cykl pracy instalacji. Jeśli scenariusze procesowe są na tyle pełne, że „opowiadają” dzień pracy operatora (start, produkcja, zmiana receptury, planowany postój, awaria i restart), zwykle oznacza to, że plan uderza w realne ryzyka, a nie tylko „odhacza” pojedyncze funkcje.

Ostatecznie skuteczność FAT i SAT zależy mniej od samej technologii, a bardziej od poziomu przygotowania: jasnych wymagań, przemyślanego planu testów i świadomego podziału, co sprawdzamy na sali testowej, a co dopiero na obiekcie. Im wcześniejsze błędy wyłapane przy biurku i w kontrolowanych warunkach, tym spokojniejszy rozruch, mniej nerwowych decyzji pod presją czasu i większe zaufanie między integratorem a użytkownikiem końcowym.

Konfiguracja środowiska do FAT – sprzęt, oprogramowanie i symulacja procesu

Sam plan testów nie wystarczy, jeśli środowisko FAT jest przypadkową zlepioną całością „tego, co akurat stoi na magazynie”. Im bardziej środowisko zbliżone jest do docelowej instalacji, tym mniej niespodzianek podczas SAT. Z drugiej strony każda dodatkowa zgodność to koszt i czas. Dlatego sensownie jest rozróżnić, co musi być odwzorowane 1:1, a gdzie wystarczy przybliżenie.

Konfiguracja sprzętowa – pełne szafy, „rigi” testowe i sprzęt zastępczy

Na poziomie sprzętu spotyka się trzy główne modele przygotowania do FAT:

1. Pełne szafy i docelowe urządzenia – najwierniejsze odwzorowanie:
   • kompletne szafy sterownicze jak na obiekcie,
   • docelowe sterowniki, moduły I/O, sieci komunikacyjne,
   • część napędów z docelowymi silnikami (np. małe przenośniki, pompy testowe).

   Sprawdza się głównie w średnich i dużych projektach, gdzie koszt błędu przewyższa koszt rozbudowanego FAT. Pozwala wyłapać problemy z okablowaniem, kompatybilnością modułów, zasilaniem, zakłóceniami EMC. Wadą są gabaryty i logistyka – trzeba zapewnić miejsce, zasilanie, często chłodzenie.

2. „Rig” testowy – skrócona wersja instalacji:
   • faktyczne szafy sterownicze, ale ograniczona liczba napędów i urządzeń,
   • jedna reprezentatywna oś napędowa zamiast kilkunastu,
   • fizyczne czujniki tylko dla kluczowych funkcji, reszta symulowana.

   Dobre rozwiązanie, gdy instalacja jest duża i powtarzalna (np. wiele identycznych sekcji). Pozwala przetestować logikę i typowe problemy integracyjne bez konieczności przenoszenia całej linii do hali testowej.

3. Środowisko mocno symulowane – minimum „żelaza”:
   • jedna szafa z PLC i komunikacją,
   • brak fizycznych napędów, I/O podpięte do emulatorów lub symulatorów,
   • HMI i system nadrzędny w wersji docelowej.

   Pasuje do projektów rozproszonych, systemów SCADA, BMS, gdzie większość logiki dotyczy komunikacji i przetwarzania danych, a nie sterowania ruchem. Słabiej wychwytuje problemy związane z czasami reakcji i zachowaniem się urządzeń fizycznych.

Dobór modelu zależy głównie od trzech czynników: stopnia złożoności procesu, ograniczeń logistycznych (przestrzeń, zasilanie, transport) i wymagań klienta. W systemach bezpieczeństwa maszyn częściej wygrywa pełne odwzorowanie, natomiast przy rozproszonych systemach pomiarowych sensowne jest pójście w kierunku symulacji.

Okablowanie, zasilanie i sieci – poziom odwzorowania a ryzyko

Drugim poziomem konfiguracji jest to, jak wiernie odwzorowane są połączenia. Można rozróżnić dwa podejścia:

• Okablowanie produkcyjne – takie jak trafi na obiekt:
  • docelowe długości przewodów,
  • realne przepusty, listwy, elementy EMC,
  • docelowe topologie sieci (ring, linia, gwiazda) z przełącznikami przemysłowymi.

  Daje szansę na wyłapanie zakłóceń, problemów z adresacją, błędnym opisem kabli czy zasilaczy niedoszacowanych względem obciążeń.

• Okablowanie testowe – skrócone, „laboratoryjne”:
  • krótkie przewody, brak długich tras kablowych,
  • czasem uproszczona struktura sieci (np. jedno „drzewo” zamiast ringa),
  • tylko wybrane sekcje okablowania w konfiguracji docelowej.

  Szybsze i tańsze do uruchomienia. Nie ujawni jednak problemów z opóźnieniami w sieciach, pętlami mas czy spadkami napięć przy długich odcinkach przewodów.

W praktyce korzysta się z rozwiązania mieszanego: okablowanie produkcyjne utrzymuje się co najmniej od wyjść PLC do listw zaciskowych w szafach oraz w części najbardziej narażonej na błędy montażowe (np. komunikacja między szafami), natomiast po stronie urządzeń końcowych dopuszcza się uproszczone połączenia testowe.

Środowisko programowe – wersje, repozytorium i konfiguracje

Na poziomie oprogramowania kluczowe jest, aby środowisko FAT nie było „tymczasową” wersją systemu, tylko bazą pod docelową konfigurację SAT. Stąd kilka zasad, które ograniczają chaos:

• Kontrola wersji – kod PLC, konfiguracje HMI, projekty SCADA w systemie typu Git/SVN lub przynajmniej z ręcznie prowadzoną historią:
  • jasny numer wersji dla kodu testowanego w FAT (np. v1.3-FAT),
  • oznaczenie commitów związanych z poprawkami z FAT,
  • zamrożenie wersji na czas kluczowych testów z klientem.
• Spójność narzędzi – te same wersje środowisk inżynierskich, które będą używane przy SAT:
  • te same wersje firmware kontrolerów,
  • te same biblioteki funkcji i sterowników komunikacyjnych.

  Różnica choćby jednej wersji firmware bywa źródłem trudnych do uchwycenia błędów, które wychodzą dopiero na obiekcie.

• Konfiguracje per obiekt – przy systemach wieloobiektowych:
  • osobne pliki konfiguracyjne (parametry, receptury) dla każdego obiektu,
  • mechanizm łatwej zmiany konfiguracji (np. przez pliki CSV, bazy danych),
  • jeden wzorcowy projekt z parametryzacją zamiast wielu kopii bez kontroli.

Porównując dwa typowe podejścia – „jeden wielki projekt kopiowany dla każdego obiektu” i „jeden parametryzowalny projekt z konfiguracjami” – to drugie wymaga więcej pracy początkowej, ale w FAT i SAT upraszcza testy regresyjne i ułatwia kontrolę zmian.

Symulacja procesu – od prostych wymuszeń po cyfrowe bliźniaki

Symulacja procesu to najczęściej najsłabszy lub najsilniejszy punkt FAT, zależnie od tego, ile wysiłku ktoś był gotów w nią włożyć. Można spotkać trzy podstawowe poziomy:

1. Proste wymuszenia sygnałów I/O – poziom minimum:
   • operator FAT ręcznie wymusza stany wejść (np. z poziomu PLC lub przez przyciski),
   • brak modelu procesu – liczy się tylko reakcja logiki na poszczególne kombinacje sygnałów,
   • nadawało się do testów modułowych i części integracyjnych.

   Plus: szybkie do uruchomienia. Minus: trudno odtworzyć realną dynamikę procesu, sekwencje czasowe, interakcje wielu sygnałów naraz.

2. Symulator sygnałów – poziom średni:
   • dedykowane narzędzie (własne lub dostawcy PLC) generuje stany I/O według zaprogramowanych scenariuszy,
   • można zasymulować czasy odpowiedzi czujników, stany przejściowe napędów, opóźnienia,
   • często realizowane jako osobny PLC lub PC z aplikacją symulacyjną połączoną z systemem przez sieć.

   Dobrze sprawdza się przy typowych liniach technologicznych, gdzie zależności są złożone, ale nadal możliwe do opisania loginami. Umożliwia częściową automatyzację FAT (powtarzalne scenariusze).

3. Model procesu / digital twin – poziom zaawansowany:
   • model matematyczny lub symulacyjny procesu (np. przepływy, temperatury, kinetyka reakcji),
   • sprzężenie zwrotne między PLC a modelem – sterownik steruje „wirtualnym” procesem, który generuje odpowiedzi jak realny,
   • stosowany zwykle w dużych zakładach procesowych, energetyce, farmacji.

   Najdroższe w przygotowaniu, ale zyskuje się możliwość testów scenariuszy awaryjnych, których nie wolno przeprowadzać na żywym obiekcie (np. gwałtowne przegrzanie, niekontrolowane ciśnienie).

W wielu projektach kompromis polega na tym, że najistotniejsze fragmenty procesu (np. układ dozowania czy stabilizacji temperatury) otrzymują prosty model symulacyjny, a reszta sygnałów jest wymuszana ręcznie lub przez proste scenariusze. Pozwala to przy rozsądnych nakładach przetestować krytyczne sekwencje bez tworzenia pełnego cyfrowego bliźniaka.

Symulacja napędów i urządzeń polowych – kiedy „prawdziwy” falownik, a kiedy emulator

Napędy i urządzenia polowe mają duży wpływ na zachowanie systemu, dlatego pojawia się dylemat: zabierać je fizycznie na FAT czy symulować? Porównując trzy warianty:

• Realne napędy z silnikami – najlepszy obraz zachowania:
  • testy ramp, reakcji na błędy, czasów start/stop,
  • sprawdzenie parametrów komunikacji, diagnostyki, alarmów,
  • możliwość czucia „na ucho” i wzrokiem niektórych problemów (drgania, przekoszenia).

  Sprawdza się, gdy liczba napędów jest ograniczona lub gdy istnieje jedna, szczególnie krytyczna oś (np. główny napęd linii). Przy kilkudziesięciu napędach pełne odwzorowanie zwykle jest zbyt kosztowne.

• Napędy bez obciążenia mechanicznego – kompromis:
  • falowniki z silnikami „na stole”, bez sprzęgnięcia z maszyną,
  • testy komunikacji, sterowania, alarmów, podstawowej dynamiki,
  • brak możliwości pełnej oceny przeciążeń czy charakterystyki momentu.

  Częsty wybór przy liniach transportowych, gdzie najważniejsze jest, że napęd reaguje poprawnie na polecenia i sygnalizuje błędy.

• Emulator napędu – rozwiązanie programowe:
  • symulacja odpowiedzi napędu na komendy, błędy i statusy,
  • brak elementów mechanicznych, mniejsze koszty i miejsce,
  • idealne do masowych testów komunikacji i logiki nadrzędnej.

  Wymaga dobrego przygotowania po stronie producenta napędu lub integratora. Dobrze współgra z automatycznymi testami regresyjnymi.

Praktycznie: w projektach, gdzie awaria jednego napędu zatrzymuje całą instalację, lepiej mieć choć kilka realnych napędów na FAT, przynajmniej reprezentatywnych typów. W systemach, gdzie napędy są powtarzalne i „masowe”, lepiej zainwestować w dobry emulator i szczegółowe testy komunikacyjne.

Przygotowanie danych testowych – receptury, parametry, scenariusze

Środowisko FAT to nie tylko sprzęt i kod, ale także dane, na których system pracuje. Różnica między „testami na szybko” a sensownym FAT-em często sprowadza się do tego, jak przemyślane są te dane:

• Receptury i konfiguracje procesowe:
  • zestaw kilku–kilkunastu reprezentatywnych receptur (minimum: „typowa”, „skrajna niska”, „skrajna wysoka”),
  • sprawdzenie limitów (np. minimalne i maksymalne czasy, temperatury, prędkości),
  • testy zmiany receptury „w locie”, jeśli system na to pozwala.
• Dane użytkowników i uprawnień:
  • kontakty dla różnych poziomów (operator, technolog, serwis, administrator),
  • sprawdzenie blokad funkcji w zależności od roli,
  • testy ścieżki audytowej, jeśli wymagana (przemysł spożywczy, farmacja).
• Scenariusze awaryjne:
  • symulacja stanów granicznych (brak surowca, pełny zbiornik, zanik zasilania sterowania),
  • odtwarzalne sekwencje: ten sam scenariusz wywoływany wielokrotnie w taki sam sposób,
  • przypisanie scenariuszy do konkretnych przypadków testowych w planie FAT.

W systemach z rozbudowaną parametryzacją opłaca się przygotować zestaw plików konfiguracyjnych „FAT-owych”, które później służą również jako wzorce przy SAT (np. do szybkiej diagnostyki – czy system po uruchomieniu na obiekcie zachowuje się tak samo jak na sali testowej przy tych samych danych).

Przebieg FAT krok po kroku – od kontroli podstawowej do testów procesowych

Dobrze zaplanowany FAT ma swoje etapy, które w jasny sposób przechodzą od sprawdzenia „czy to w ogóle działa” do „czy robi to, czego oczekuje użytkownik”. W zależności od wielkości projektu etapy mogą być połączone, ale logika pozostaje podobna.

Etap 1 – weryfikacja podstawowa (smoke test i kontrole formalne)

Na starcie przeprowadza się zestaw prostych, ale bezwzględnie wymaganych sprawdzeń. Chodzi o to, żeby nie marnować czasu całego zespołu na analizy przyczyn błędów, które wynikają z oczywistych braków:

• zgodność wersji oprogramowania (firmware PLC, wersje bibliotek, SCADA, bazy danych) z listą referencyjną projektu,
• sprawdzenie komunikacji w sieciach (ping, diagnostyka protokołów przemysłowych, poprawne adresacje),
• uruchomienie podstawowych usług systemowych (serwery licencji, archiwizacji, raportowania),
• kontrola obecności i poprawności wgranych projektów: PLC, HMI, SCADA, systemów nadrzędnych.

Smoke test ma charakter zero-jedynkowy: jeśli nie przechodzi, FAT nie wchodzi na wyższy poziom. Dobrą praktyką jest posiadanie krótkiej, jednostronicowej checklisty, którą można „odhaczyć” w ciągu jednej–dwóch godzin. Kiedy zestaw startowy jest powtarzalny w kolejnych projektach, ten etap bywa mocno zautomatyzowany (skrypty do weryfikacji wersji, narzędzia do masowego sprawdzenia komunikacji).

Etap 2 – testy I/O i funkcji bezpieczeństwa

Kolejny krok to upewnienie się, że każdy fizyczny punkt wejścia i wyjścia jest poprawnie odwzorowany w logice oraz na wizualizacjach, a funkcje bezpieczeństwa zachowują się przewidywalnie. Dwa podejścia pojawiają się tu najczęściej:

• Testy punkt po punkcie – klasyczna metoda:
  • osoba po stronie integratora wymusza kolejno stany na wejściach,
  • przedstawiciel klienta (lub inżynier uruchomieniowy) weryfikuje wskazania na ekranach i reakcje wyjść,
  • każdy punkt jest odnotowany w protokole razem z ewentualnymi uwagami.
• Testy oparte na skryptach automatycznych – szybsze, ale wymagają przygotowań:
  • symulator generuje sekwencje sygnałów dla całych grup I/O,
  • w tle działa mechanizm logowania, który sprawdza mapowanie tagów i odpowiedzi systemu,
  • użytkownik końcowy angażuje się głównie przy weryfikacji nietypowych lub krytycznych punktów.

W obydwu wariantach kluczowe są obwody bezpieczeństwa: przyciski STOP, kurtyny, wyłączniki awaryjne, blokady drzwi. Jeżeli pełne testy SIL/PL zostały zrobione wcześniej, na FAT sprawdza się zwykle interfejs pomiędzy systemem bezpieczeństwa i standardowym sterowaniem (sygnały diagnostyczne, reakcja logiki na zadziałanie E-Stop, poprawne blokady sekwencji). Niedoprecyzowanie zachowania po awarii (co się dzieje z recepturą, licznikiem cykli, raportami) często mści się dopiero w SAT – tu łatwiej porównać dwa warianty i zdecydować, który lepiej pasuje do filozofii pracy zakładu.

Etap 3 – testy funkcjonalne i sekwencyjne

Po potwierdzeniu, że „wszystko się świeci tam, gdzie trzeba”, przechodzi się do logiki procesowej. Z jednej strony są to testy prostych funkcji (sterowanie pojedynczym zaworem czy napędem), z drugiej – pełnych sekwencji technologicznych. Często stosuje się dwa poziomy szczegółowości:

• Testy funkcji elementarnych:
  • ręczne sterowanie napędami i zaworami,
  • sprawdzenie blokad (np. blokada startu przy otwartych drzwiach, brak medium),
  • weryfikacja stanów pośrednich i sygnalizacji (statusy „praca”, „gotowość”, „awaria”, „ręczny”).
• Testy sekwencji i trybów pracy:
  • uruchomienie automatycznych cykli w oparciu o przygotowane scenariusze,
  • przejście między trybami (ręczny/serwisowy/automatyczny) w trakcie pracy,
  • sprawdzenie reakcji na błędy w środku sekwencji (awaria napędu, brak sygnału z czujnika, utrata potwierdzenia z urządzenia nadrzędnego),
  • weryfikacja powrotu do pracy po zatrzymaniu awaryjnym lub zaniku zasilania – czy system wznawia cykl, wymaga potwierdzenia, czy startuje od początku.

Przy sekwencjach łatwo wpaść w pułapkę „przeklikania” kilku poprawnych cykli i uznania, że wszystko jest w porządku. Lepsze podejście to porównanie dwóch skrajności: scenariusza „idealnego” (bez żadnych zakłóceń) z serią scenariuszy „brudnych”, gdzie celowo wprowadza się błędy w różnych fazach cyklu. Widać wtedy, czy procedury wznowienia i czyszczenia stanów są spójne, a operator nie zostaje z ekranem pełnym alarmów bez jasnej ścieżki działania.

Im bardziej zautomatyzowana linia, tym większy sens ma półautomatyzacja testów sekwencyjnych. W prostym układzie mieszalnika wystarczy lista kroków odhaczana ręcznie. W złożonej linii pakującej lepszy efekt daje skrypt symulujący przepływ produktu, błędy etykiet, zacięcia przenośników, a do tego log z dokładnymi znacznikami czasu. Różnica jest widoczna zwłaszcza przy późniejszych poprawkach – zamiast „na oko” powtarza się te same scenariusze i łatwo ocenić, czy zmiana oprogramowania faktycznie rozwiązała problem.

Przy testach funkcjonalnych dobrze też od razu zderzać oczekiwania technologów z rzeczywistym zachowaniem systemu. Czasem logika „książkowa” okazuje się zbyt sztywna dla pracowników utrzymania ruchu (np. blokady uniemożliwiające proste czyszczenie linii), innym razem to użytkownik odkrywa, że potrzebuje dodatkowego stanu przejściowego lub komunikatu. FAT jest dużo lepszym miejscem na takie korekty filozofii pracy niż SAT, gdzie każda modyfikacja wydłuża przestoje.

Dobrze przeprowadzony FAT domyka większość niespodzianek zanim pojawią się na obiekcie. SAT staje się wtedy raczej potwierdzeniem zachowania znanego już z hali testowej niż poligonem do szukania podstawowych błędów. Zyskuje na tym każda ze stron: integrator ogranicza liczbę nerwowych poprawek „na szybko”, a użytkownik szybciej dochodzi do stabilnej, powtarzalnej pracy instalacji.

Etap 4 – testy wydajnościowe, obciążeniowe i długotrwałe

Gdy logika procesowa zachowuje się poprawnie w typowych scenariuszach, sens ma przejście do sprawdzenia, jak system działa „pod presją” – przy większym obciążeniu, dłuższej pracy i większej liczbie równoległych zadań. Na tym etapie wychodzą problemy, których nie widać przy pojedynczych cyklach: drobne wycieki pamięci, niewydolne archiwizacje, zbyt agresywne odświeżanie ekranów.

• Testy wydajności CPU i sieci:
  • monitorowanie obciążenia sterowników, serwerów SCADA/HMI i baz danych przy maksymalnej liczbie aktywnych funkcji,
  • symulacja pełnego ruchu na magistralach (np. wszystkie urządzenia polowe raportują diagnostykę, rosną archiwa),
  • porównanie czasów reakcji (np. od zmiany stanu wejścia do zmiany na wyjściu, opóźnienie aktualizacji ekranu).
• Testy długotrwałe (stability run):
  • kilkugodzinne lub kilkudniowe uruchomienie w trybie zbliżonym do docelowego obciążenia produkcją,
  • ciągłe logowanie trendów obciążenia, czasów cykli, liczby aktywnych alarmów,
  • kontrola, czy nie rośnie nieuzasadnione zużycie pamięci lub czas wykonywania pętli sterownika.
• Testy odporności na błędy komunikacji:
  • celowe wprowadzanie przerw w komunikacji (odłączenie segmentu sieci, restart urządzenia polowego),
  • obserwacja zachowania buforów danych, kolejek alarmów, mechanizmów ponownego łączenia,
  • weryfikacja, czy po powrocie łączności system nie „zalewa” operatora spóźnionymi alarmami bez logiki filtracji.

Do testów długotrwałych podchodzi się dwojako. W małych systemach wystarczy zaprogramować kilka powtarzających się cykli procesowych i uruchomić je w pętli, z okresowymi zrzutami logów. W większych instalacjach lepszy efekt daje specjalny scenariusz „obciążeniowy”: równoległe sekwencje, intensywna archiwizacja, raporty generowane co określony czas, ruch danych do systemów nadrzędnych. Kontrast między tymi dwoma podejściami często pokazuje, gdzie znajduje się prawdziwe wąskie gardło – w sprzęcie, logice, czy konfiguracji sieci.

Przy testach obciążeniowych klienci dzielą się zazwyczaj na dwa obozy. Jedni wolą „laboratoryjne” ustawienie maksymalnych parametrów (najkrótsze czasy, maksymalna częstotliwość zapisów), drudzy – konfigurację bardziej zbliżoną do realnej produkcji. Rozsądne jest połączenie: najpierw scenariusz realistyczny dla oceny codziennego zachowania, a następnie krótki, bardziej ekstremalny test, który pokaże margines bezpieczeństwa platformy sprzętowej.

Etap 5 – testy integracji z systemami nadrzędnymi i urządzeniami zewnętrznymi

Nawet najbardziej dopracowany program PLC niewiele znaczy, jeśli system nie dogaduje się z otoczeniem: MES, ERP, systemami laboratoryjnymi, magazynami automatycznymi czy sterownikami dostarczonymi przez innych dostawców. FAT to dobre miejsce, żeby wyłapać różnice interpretacji protokołów, pola danych „nie do końca tak zrozumiane” po obu stronach i niejasne reguły wymiany informacji.

• Integracja z MES/ERP:
  • weryfikacja formatów komunikatów (np. JSON, XML, tagi OPC UA, struktury DB),
  • sprawdzenie cyklu: zlecenie produkcyjne → parametry procesu → raport wykonania → zwrot statusu do systemu nadrzędnego,
  • test zachowania przy błędach: brak odpowiedzi MES, niepoprawne dane, anulowanie zlecenia w trakcie realizacji.
• Integracja z systemami jakości i laboratoryjnymi:
  • przekazywanie wyników pomiarów i próbek do LIMS lub systemu jakości,
  • sprawdzanie, czy identyfikatory partii i produktów są spójne po obu stronach,
  • weryfikacja blokad produkcji w przypadku braku potwierdzenia z systemu jakości.
• Komunikacja z urządzeniami zewnętrznymi różnych dostawców:
  • testy protokołów producenta (np. sterowniki napędów, wagi, skanery kodów, roboty),
  • sprawdzenie reakcji na niepełne lub opóźnione telegramy,
  • symulacja aktualizacji firmware jednego z urządzeń i wpływu na komunikację (przynajmniej na poziomie testu wersji i identyfikatorów).

W praktyce pojawiają się dwa główne podejścia do integracji na FAT. Pierwsze zakłada pełną obecność systemów nadrzędnych (np. testowa instancja MES/ERP podłączona do środowiska FAT). Zyskuje się realizm, ceną jest złożona logistyka i uzależnienie od innych zespołów. Drugie opiera się na symulatorach – generatorach zleceń i odbiornikach raportów, które naśladują zachowanie pozostałych systemów. Takie podejście jest prostsze organizacyjnie i łatwiej powtarzalne, ale część subtelnych problemów (np. różnice w obsłudze błędów po stronie MES) może wyjść dopiero przy SAT.

Etap 6 – testy ergonomii HMI/SCADA i wsparcia operatora

Funkcjonalnie system może być bez zarzutu, a mimo to w codziennej eksploatacji staje się źródłem frustracji. Przyczyną bywa interfejs, który jest logiczny dla programisty, lecz mało czytelny dla operatora na zmianie nocnej. FAT to dobre miejsce na wspólną „przejażdżkę” po ekranach z udziałem docelowych użytkowników.

• Nawigacja i struktura ekranów:
  • ocena liczby kliknięć potrzebnych do dotarcia do najczęściej używanych funkcji,
  • sprawdzenie, czy widok synoptyczny rzeczywiście pomaga zrozumieć stan linii,
  • weryfikacja spójności schematów kolorów i symboli dla wszystkich stacji.
• Alarmy i komunikaty:
  • czytelność opisów alarmów: co się stało, gdzie i co operator ma zrobić,
  • odróżnienie alarmów krytycznych od informacyjnych (wizualnie i dźwiękowo),
  • test scenariuszy „burzy alarmowej” – czy operator jest w stanie zareagować w sensownej kolejności.
• Ekrany serwisowe i diagnostyczne:
  • dostępność kluczowych informacji dla utrzymania ruchu (liczniki, stany wejść/wyjść, status komunikacji),
  • oddzielenie funkcji operatorskich od serwisowych za pomocą uprawnień,
  • ocena, czy do typowych interwencji nie jest konieczne angażowanie programisty.

W jednym z projektów różnica między podejściami była bardzo wyraźna: integrator przygotował rozbudowane ekrany diagnostyczne, które inżynierowie chwalili przy FAT, ale operatorzy zgłosili, że do codziennej pracy potrzebują jednego prostego widoku: „czy linia jest gotowa, co ją blokuje i gdzie mam iść”. Po krótkiej sesji roboczej powstał nowy ekran „pierwsza pomoc”, a szczegółowa diagnostyka trafiła w głąb menu. FAT pozwolił spokojnie przeprowadzić tę korektę, zamiast przerabiać wizualizację w trakcie SAT pod presją czasu.

Rejestrowanie niezgodności i zarządzanie zmianą w trakcie FAT

FAT zawsze generuje listę usterek, uwag i pomysłów na usprawnienia. Różnica między projektem chaotycznym a uporządkowanym leży głównie w sposobie, w jaki ta lista jest tworzona, porządkowana i domykana. Dwa składniki są kluczowe: spójny rejestr niezgodności oraz jasny tryb podejmowania decyzji o zmianach.

Struktura rejestru niezgodności – co i jak zapisywać

Najprostszy rejestr można zbudować w arkuszu, bardziej rozbudowane zespoły korzystają z narzędzi typu systemy ticketowe lub moduły zarządzania defektami. Niezależnie od narzędzia, liczy się konsekwentna struktura wpisów.

• Minimalny zestaw pól w zgłoszeniu:
  • unikalny identyfikator (numer niezgodności/defektu),
  • data i osoba zgłaszająca (integrator, przedstawiciel klienta, technolog),
  • opis problemu w języku operacyjnym, nie tylko technicznym,
  • krok testu / odniesienie do punktu planu FAT,
  • priorytet (np. krytyczny, wysoki, średni, niski),
  • kategoria (błąd funkcjonalny, ergonomia HMI, wydajność, integracja, dokumentacja).
• Informacje wymagane przy analizie i naprawie:
  • przyczyna źródłowa (root cause) – choćby w skróconej formie,
  • opis zastosowanej poprawki lub decyzji o jej odrzuceniu,
  • wersja oprogramowania/konfiguracji, w której błąd został usunięty,
  • osoba odpowiedzialna i data zamknięcia.

Rejestry można prowadzić w dwóch skrajnie różnych stylach. Jeden to „minimalistyczny”: jedynie numer, opis, status. Drugi to „przesadnie rozbudowany”: kilkanaście pól, których nikt rzetelnie nie uzupełnia. Praktyka pokazuje, że najlepiej sprawdza się podejście pośrednie – kilkanaście kluczowych pól, z których część można wybierać z list rozwijanych (priorytet, kategoria, moduł systemu). Integratorzy nie traci wtedy czasu na opisywanie oczywistości, a klient otrzymuje dane, które da się analizować po zakończeniu projektu.

Priorytetyzacja niezgodności – co musi być naprawione przed końcem FAT

Nie każdy błąd ma ten sam ciężar. Od sposobu kategoryzacji zależy, czy projekt zmierza do realistycznego zakończenia, czy do niekończącej się listy poprawek „kosmetycznych”. Dobrym punktem wyjścia jest rozdział na trzy główne klasy:

• Niezgodności krytyczne – wpływają na bezpieczeństwo, możliwość uruchomienia procesu lub zgodność z kluczowymi wymaganiami prawnymi:
  • awarie powodujące niekontrolowany ruch napędów,
  • błędy uniemożliwiające zatrzymanie linii przez E-Stop,
  • brak rejestracji i archiwizacji danych wymaganych przez regulacje (np. w farmacji).
• Niezgodności istotne – nie blokują całkowicie działania, ale powodują ryzyko błędów operacyjnych, nadmierne przestoje lub nieakceptowalną ergonomię:
  • niejasne komunikaty alarmowe w ważnych punktach procesu,
  • niedokładne liczniki, które wpływają na raportowanie produkcji,
  • niewłaściwe blokady sekwencji po powrocie z E-Stop.
• Niezgodności drobne / usprawnienia – kosmetyka, zmiany tekstów, dodatki „nice to have”:
  • zmiany kolorystyki ekranów,
  • dodatkowe pola na raportach, które nie są wymagane formalnie,
  • uproszczenia nawigacji, jeśli obecny układ jest poprawny, choć mniej wygodny.

Przy krytycznych i istotnych niezgodnościach nie ma zazwyczaj pola do dyskusji – muszą zostać rozwiązane przed formalnym zakończeniem FAT lub wyraźnie opisane jako warunki, bez których nie można rozpocząć SAT. Spór zwykle dotyczy kategorii trzeciej: drobnych poprawek. Tu pojawiają się dwa podejścia. Część klientów preferuje doprowadzenie wszystkiego do docelowego kształtu już na FAT, kosztem dłuższych testów. Inni wolą zakończyć FAT po domknięciu funkcji krytycznych, a drobne zmiany przekazać do zaplanowanych „pakietów modyfikacyjnych” po SAT. Kluczowa jest jasna zasada ustalona przed testami – inaczej każda mała uwaga przeradza się w długą dyskusję.

Workflow obsługi niezgodności – obieg zgłoszeń podczas FAT

Nawet dobrze zdefiniowany rejestr nie wystarczy, jeśli zgłoszenia „wiszą w powietrzu” bez przypisanego właściciela i terminu. Potrzebny jest prosty, ale konsekwentnie stosowany obieg.

• Przyjęcie zgłoszenia:
  • zgłoszenie trafia do rejestru z opisem i pierwotnym priorytetem,
  • koordynator FAT (ze strony integratora lub wspólny) weryfikuje kompletność danych,
  • przypisanie do odpowiedniej osoby lub zespołu (PLC, SCADA, dokumentacja, integracja MES).
• Analiza i korekta:
  • ocena, czy zgłoszenie jest rzeczywistym błędem, czy wnioskiem o zmianę wymagań,
  • propozycja rozwiązania, ewentualnie alternatywnych wariantów,
  • wprowadzenie modyfikacji w kodzie/konfiguracji z oznaczeniem wersji.

• Weryfikacja i ponowny test:
  • po wdrożeniu poprawki zgłoszenie wraca do osoby testującej,
  • wykonanie ponownie tego samego kroku testowego (lub krótkiego scenariusza regresji, jeśli zmiana była szersza),
  • aktualizacja statusu: zaakceptowane / wymaga dalszych poprawek.
• Zamknięcie i dokumentacja:
  • uzgodnienie, czy błąd został usunięty w całości, czy częściowo (np. „obejście” zaakceptowane do czasu kolejnej wersji),
  • oznaczenie zgłoszenia jako zamknięte, z krótkim komentarzem biznesowym („nie wpływa na wydajność”, „warunek uruchomienia SAT spełniony”),
  • powiązanie zgłoszenia z wersją oprogramowania i datą instalacji na obiekcie.

W praktyce spotyka się dwa skrajne modele pracy ze zgłoszeniami. W pierwszym zespół poprawia wszystko „od ręki”, na bieżąco przerywając testy – daje to szybki feedback, ale mocno rozbija rytm FAT i utrudnia śledzenie wersji. W drugim poprawki robi się paczkami, np. raz dziennie po zakończeniu sesji testowej; testy są wtedy bardziej uporządkowane, ale użytkownicy dłużej czekają na efekt. Przy bardziej rozbudowanych systemach zwykle lepiej sprawdza się podejście mieszane: poprawki krytyczne wdrażane od razu, reszta w zaplanowanych oknach serwisowych w trakcie FAT.

Przydatnym kompromisem jest tzw. „okno zamrożenia” pod koniec FAT. Przez ustalony okres wprowadza się wyłącznie poprawki usuwające błędy krytyczne i istotne, a wszystkie wnioski typu „usprawnienie” trafiają na listę z etykietą „po SAT”. Dzięki temu zespół unika sytuacji, w której każdego dnia przybywa nowych pomysłów, a system nigdy nie osiąga stabilnego punktu odniesienia do testów końcowych.

Zarządzanie zmianą – kiedy poprawka staje się zmianą zakresu

Nie każda uwaga z FAT to defekt. Część zgłoszeń wynika z dojrzewania wymagań użytkowników – w trakcie oglądania działającego systemu łatwiej zauważyć, że przydałby się dodatkowy raport czy inna logika priorytetów alarmów. Różnica między „błędem” a „zmianą zakresu” ma bezpośrednie przełożenie na harmonogram i budżet, dlatego granica powinna być zdefiniowana wcześniej, a nie ustalana ad hoc w sali testowej.

Praktycznym podejściem jest prosty filtr pytań: czy system zachowuje się niezgodnie z zaakceptowanymi wymaganiami, czy tylko inaczej niż obecne przyzwyczajenia użytkownika? Czy błąd uniemożliwia spełnienie parametrów odbioru, czy jedynie poprawiłby wygodę pracy? Odpowiedzi kierują zgłoszenie jedną z dwóch ścieżek: korekty w ramach kontraktu (defekt) albo formalnej zmiany (change request) z osobnym zatwierdzeniem, wyceną i planem wdrożenia.

Duże organizacje często budują dwa równoległe rejestry: jeden na niezgodności blokujące odbiór, drugi na propozycje rozwoju systemu. Mniejsze zespoły zwykle korzystają z jednego arkusza, ale z wyraźnym polem „charakter zgłoszenia” i innym trybem decyzyjnym. W obu podejściach liczy się przejrzystość: klient widzi, które punkty muszą być domknięte przed SAT, a które realizowane będą w ramach osobnych zadań rozwojowych po uruchomieniu linii.

Dobrze przeprowadzony FAT z jasno ustawionymi priorytetami, prostym obiegiem zgłoszeń i rozróżnieniem między defektem a zmianą zakresu pozwala wejść w SAT bez zaskoczeń: z ustaloną listą otwartych punktów, przewidywalnym planem poprawek i systemem, który zachowuje się stabilnie mimo kolejnych iteracji modyfikacji.

Przygotowanie do SAT – przeniesienie systemu z sali testowej na obiekt

Po zakończonym FAT zespół zwykle wpada w pokusę „szybkiego” przeniesienia rozwiązań na instalację. Im większy system, tym boleśniej wychodzą wtedy na wierzch różnice między warunkami testowymi a rzeczywistymi. Przejście z fabryki integratora na obiekt warto potraktować jako osobną, zaplanowaną fazę, a nie tylko logistykę.

Plan transferu – co musi się zgadzać przed wyjazdem na SAT

Dobrym punktem startowym jest prosty dokument „plan transferu na SAT”, który scala ustalenia z FAT z realiami obiektu. Zwykle obejmuje on kilka grup zagadnień:

• Zakres funkcjonalny na SAT:
  • lista funkcji przetestowanych i zaakceptowanych na FAT,
  • lista funkcji świadomie przesuniętych na SAT (np. integracje z systemami zewnętrznymi),
  • otwarte punkty z FAT z jasno określonym wpływem na testy na obiekcie.
• Zakres sprzętowy i sieciowy:
  • porównanie konfiguracji sprzętu użytego na FAT z docelową konfiguracją na obiekcie (modele sterowników, kart, przełączników, serwerów),
  • mapa segmentów sieciowych: VLAN-y, podsieci, reguły firewall, adresacja IP,
  • uzgodnienie, czy na SAT system będzie pracował w docelowej domenie IT, czy w wydzielonej „bańce” OT.
• Plan migracji wersji:
  • określona wersja kodu PLC/SCADA/MES, która ma być podstawą do SAT,
  • wskazanie, jakie poprawki z końcówki FAT nie zostały jeszcze scalone i kiedy będzie to zrobione,
  • procedura odtworzenia konfiguracji (backup/restore, import projektów, licencje).
• Warunki brzegowe na obiekcie:
  • dostępność mediów (zasilanie, sprężone powietrze, media procesowe) w trakcie testów,
  • ograniczenia wynikające z BHP i ruchu produkcyjnego (okna testowe, strefy wyłączone),
  • zespół po stronie użytkownika: kto będzie obecny przy SAT, z jakimi uprawnieniami.

Plan transferu bywa lekceważony przy mniejszych systemach – „i tak się dogadamy na miejscu”. W praktyce nawet przy niewielkiej linii pakującej różnica w konfiguracji sieci lub wersji firmware napędu potrafi zatrzymać SAT na kilka godzin, a czasem na kilka dni, jeśli na obiekcie nie ma wsparcia IT lub serwisu producenta.

Synchronizacja konfiguracji – trzy typowe podejścia

Najczęściej występują trzy modele przeniesienia konfiguracji z FAT na SAT. Każdy z nich ma inne ryzyka i inne wymagania dokumentacyjne.

• 1. Kopia 1:1 projektu – przeniesienie dokładnie tego samego projektu PLC/SCADA na serwery obiektowe:
  • Plusy: najmniejsze ryzyko błędów w logice, łatwe odtworzenie błędów z SAT w środowisku FAT, proste porównanie wersji.
  • Minusy: wymaga bardzo konsekwentnego zarządzania parametryzacją (np. adresami IP, nazwami serwerów, ścieżkami do archiwów),
  • Kiedy stosować: przy systemach z wysoką złożonością logiki i stosunkowo prostą infrastrukturą sieciową.
• 2. Instalacja „czysta” z przeniesieniem ustawień – na obiekcie instalowany jest świeży system, a z FAT migruje się jedynie konfiguracje, receptury, szablony ekranów:
  • Plusy: mniejsze ryzyko przeniesienia „śmieci” z fazy prototypowania, lepsza zgodność z polityką IT klienta,
  • Minusy: większa pracochłonność i ryzyko pomyłek przy ręcznym odtwarzaniu konfiguracji, trudniejsze porównywanie z FAT.
  • Kiedy stosować: gdy klient narzuca sztywne standardy instalacji oprogramowania, obrazów systemów, politykę bezpieczeństwa.
• 3. Model hybrydowy – kluczowe komponenty (np. projekty PLC, aplikacje HMI) są kopiowane 1:1, natomiast komponenty infrastrukturalne (bazy danych, serwery raportowe) są instalowane zgodnie z procedurami IT:
  • Plusy: dobry balans między powtarzalnością logiki a zgodnością z infrastrukturą klienta,
  • Minusy: konieczność bardzo jasno opisanej granicy: co jest elementem powtarzalnym, a co instalowanym lokalnie.
  • Kiedy stosować: przy złożonych systemach, gdzie osobne zespoły odpowiadają za logikę automatyki i za warstwę IT.

Kluczowym elementem jest tu dokument „lista różnic między FAT a SAT”: zestawienie tych parametrów, które muszą być inne w środowisku obiektowym (adresy IP, nazwy serwerów, lokalne ścieżki, konta użytkowników). Brak takiego dokumentu to jeden z najczęstszych powodów pozornie tajemniczych błędów podczas SAT.

Planowanie i zakres SAT – od testów „na sucho” po produkcję próbną

Jeżeli FAT weryfikuje system „w idealnych warunkach”, SAT odpowiada na zupełnie inne pytania: jak system radzi sobie z rzeczywistą zmiennością procesu, ograniczeniami utrzymania ruchu, zachowaniami operatorów. Dobrze ułożony plan SAT łączy wymagania formalne (parametry odbioru) z praktycznymi scenariuszami pracy.

Struktura planu SAT – trzy poziomy szczegółowości

Plany SAT można podzielić na trzy charakterystyczne style, często wynikające z kultury organizacyjnej użytkownika końcowego.

• Plan „wysokopoziomowy”:
  • kilkanaście–kilkadziesiąt scenariuszy opisanych hasłowo („uruchomienie linii od zera”, „przejście na tryb ręczny przy awarii sekcji X”),
  • duża swoboda prowadzącego testy,
  • opiera się mocno na doświadczeniu użytkowników.
  • Sprawdza się tam, gdzie linia jest dobrze znana, a system automatyki jest głównie modernizacją istniejącego rozwiązania.
• Plan „krok po kroku”:
  • szczegółowe instrukcje dla każdego przypadku testowego, łącznie z wartościami nastaw, spodziewanymi odpowiedziami i kryteriami zaliczenia,
  • łatwy do powtórzenia przez nowy zespół,
  • wymaga więcej pracy przygotowawczej, ale daje czytelny materiał dowodowy z SAT.
  • Sprawdza się w nowych instalacjach, szczególnie w branżach regulowanych (farmacja, spożywka z wymogami jakościowymi).
• Plan mieszany:
  • dla funkcji krytycznych – szczegółowe kroki testowe,
  • dla funkcji pomocniczych – ogólne scenariusze (np. „zmiana receptury”, „przezbrojenie formatu”).
  • Sprawdza się przy złożonych liniach, gdzie utrzymywanie bardzo szczegółowego opisu wszystkich funkcji byłoby nieproporcjonalnie kosztowne.

Bez względu na styl, plan SAT powinien wprost odnosić się do wymagań kontraktowych i protokołów FAT. „Ścieżki” testowe, które w FAT były symulowane, na SAT przechodzą do testów z rzeczywistym medium lub produktem – najlepiej widać to w procesach ciągłych i wsadowych.

Kluczowe kategorie testów na SAT

Dobrym sposobem uporządkowania testów SAT jest podział na kilka kategorii. Dzięki temu łatwiej ocenić, czy każda z nich została domknięta, a nie tylko „przeklikać” funkcje z listy.

• Testy instalacyjne i integracyjne:
  • sprawdzenie kompletności montażu sygnałów polowych (okablowanie, oznaczniki, kierunki napędów),
  • weryfikacja poprawności adresacji i komunikacji z urządzeniami (napędy, falowniki, wagi, czytniki kodów),
  • sprawdzenie komunikacji pomiędzy warstwami systemu (PLC–SCADA, SCADA–MES/ERP).
• Testy funkcjonalne w warunkach rzeczywistych:
  • powtórzenie kluczowych przypadków z FAT, ale już na rzeczywistym sprzęcie i z realnymi czasami odpowiedzi,
  • weryfikacja sekwencji startu/stopu z uwzględnieniem fizycznej bezwładności układu,
  • sprawdzenie reakcji na typowe sytuacje procesowe (brak materiału, przepełnienie, zanik medium).
• Testy bezpieczeństwa i interlocków:
  • sprawdzenie wszystkich obwodów bezpieczeństwa, w tym jogowania napędów, blokad osłon,
  • testy scenariuszy E-Stop, ale już z udziałem realnych napędów i mechaniki,
  • weryfikacja, czy opóźnienia wynikające z realnej instalacji nie zmieniają zakładanej „filozofii bezpieczeństwa”.
• Testy użytkowe (operator, utrzymanie ruchu):
  • weryfikacja ergonomii ekranów przy typowych operacjach (uruchamianie, przezbrojenia, reagowanie na alarmy),
  • sprawdzenie dostępności kluczowych informacji (trendy, raporty, diagnoza błędów),
  • testy typowych interwencji UR: wymiana czujnika, reset falownika, ponowne referencjonowanie osi.
• Testy wydajnościowe i stabilności:
  • pomiar czasu rozruchu do stanu produkcyjnego,
  • próba osiągnięcia zadanej wydajności przez ustalony czas,
  • obserwacja obciążenia sieci i serwerów przy nominalnym obciążeniu.

W praktyce najmocniej kolidują ze sobą dwie grupy: testy bezpieczeństwa i testy wydajnościowe. Pierwsze wymagają częstego zatrzymywania i uruchamiania instalacji, drugie – dłuższej ciągłej pracy. Uporządkowanie planu SAT tak, aby najpierw domknąć testy bezpieczeństwa, a dopiero na końcu przejść do dłuższych biegów produkcyjnych, oszczędza wiele frustracji po obu stronach.

Organizacja sesji SAT – role, komunikacja i logistyka na obiekcie

Na SAT spotykają się często trzy różne „światy”: integrator automatyki, dział utrzymania ruchu oraz produkcja. Każdy ma inne priorytety, inny język i inne ograniczenia czasowe. Dobrze przemyślana organizacja sesji decyduje o tym, czy testy idą sprawnie, czy każda zmiana wymaga kilku spotkań ad hoc.

Role w trakcie SAT – kto za co odpowiada

Podział ról bywa podobny do tego z FAT, ale na obiekcie dochodzą dodatkowe obowiązki związane z bezpieczeństwem i dostępem do instalacji.

• Koordynator SAT (zwykle po stronie klienta, czasem wspólny):
  • ustala harmonogram dzienny testów,
  • koordynuje dostęp do instalacji (lockout/tagout, zgody BHP, prace na wysokości itp.),
  • decyduje o przerwaniu testów w razie kolizji z produkcją lub innymi pracami.
• Lider techniczny integratora:
  • odpowiada za konfigurację systemu automatyki na obiekcie,
  • nadzoruje wprowadzanie poprawek w trakcie SAT,
  • udziela informacji, które testy są możliwe przy aktualnym stanie systemu.
• Przedstawiciel utrzymania ruchu:
  • zapewnia dostęp do urządzeń (napędy, rozdzielnice, zawory),
  • uczestniczy w testach diagnostycznych i awaryjnych,
  • zgłasza uwagi dotyczące serwisowalności i diagnozy błędów.
• Przedstawiciel produkcji:
  • definiuje priorytety testów z perspektywy ciągłości produkcji,
  • uczestniczy w testach wydajnościowych,
  • ocenia, czy system wspiera operatora w typowych sytuacjach (przezbrojenia, mikroprzestoje).
• Osoba odpowiedzialna za dokumentację i protokoły:
  • prowadzi rejestr wykonanych testów i ich wyników,
  • aktualizuje listę niezgodności i powiązanie z konkretnymi przypadkami testowymi,
  • zapewnia spójność podpisów, dat i wersji oprogramowania w protokołach.

W mniejszych projektach kilka z tych ról pełni jedna osoba, ale nawet wtedy warto jasne ustalić „kto decyduje o czym”. Przykładowo: kto ma prawo wstrzymać instalację nowej wersji oprogramowania w trakcie zmiany produkcyjnej, a kto zatwierdza odstępstwo od planu testów.

Harmonogram i okno produkcyjne – jak nie zablokować zakładu

Na etapie SAT najmocniej ścierają się potrzeby automatyki i produkcji. Zespół projektowy chciałby mieć linię wyłącznie do dyspozycji, produkcja – jak najszybciej wejść na stabilną pracę. Dobrze ustawiony harmonogram testów równoważy te interesy zamiast forsować tylko jedno z nich.

Najczęściej sprawdzają się dwa podstawowe modele pracy. W trybie „blokowym” rezerwuje się ciągłe, wielogodzinne okna (np. weekend lub nocne zmiany) wyłącznie na SAT. Pozwala to prowadzić testy wydajnościowe i długie sekwencje, ale wymaga odważnej decyzji o zatrzymaniu lub ograniczeniu produkcji. Drugi wariant to krótsze „sloty” wplecione między serie produkcyjne: testy bezpieczeństwa i funkcjonalne są wtedy porcjowane na mniejsze kawałki. Zespół projektowy ma mniej swobody, za to zakład łatwiej utrzymuje ciągłość dostaw.

Różnica między tymi podejściami jest szczególnie widoczna przy testach, których nie da się przerwać w połowie – jak długotrwałe rozruchy czy zmiana formatu z dużą ilością przezbrojeń. W modelu blokowym da się je wykonać jednorazowo, od początku do końca, co daje czytelny obraz zachowania systemu. W modelu „slotowym” te same testy bywają rozciągnięte na kilka dni i trudniej wyłapać subtelne problemy (np. narastające opóźnienia w komunikacji, stopniowe „puchnięcie” bazy danych alarmów).

Dobrym kompromisem jest podział zakresu SAT na pakiety funkcjonalne: najpierw zamknięty blok testów bezpieczeństwa i interlocków (często w krótkich oknach, nawet po godzinie–dwóch), następnie osobne, dłuższe sesje na testy wydajnościowe i stabilności. Produkcja z góry wie, w którym tygodniu musi „oddać” linię, a integrator może sensownie ułożyć sekwencję przypadków zamiast reagować z dnia na dzień.

Przepływ informacji i zarządzanie decyzjami na obiekcie

Na hali decyzje często zapadają spontanicznie: ktoś z UR widzi ryzyko uszkodzenia napędu, lider zmiany sygnalizuje pilne zlecenie, integrator widzi potrzebę szybkiej poprawki w PLC. Jeśli nie ma jasnej ścieżki decyzyjnej, SAT zamienia się w serię „gaszeń pożarów”, a uzgodnienia sprzed godziny przestają być aktualne.

Skuteczny model opiera się zwykle na dwóch równoległych kanałach. Pierwszy to szybkie decyzje operacyjne na hali: czy można uruchomić dany napęd, kto fizycznie obsługuje przyciski, czy wymagane jest dodatkowe zabezpieczenie (np. nadzór BHP przy testach z otwartymi osłonami). Tu wystarczy jasno nazwany „kierownik testów na zmianie”, który zbiera sygnały od operatorów i UR i podejmuje decyzje w czasie rzeczywistym. Drugi kanał to codzienne, krótkie spotkanie przeglądowe (np. rano lub po południu), na którym omawiane są skutki tych decyzji: przesunięcia w harmonogramie, nowe niezgodności, plan działań korygujących.

Różnicę szczególnie widać przy zmianach w oprogramowaniu. W modelu nieuporządkowanym poprawki są wgrywane „od ręki”, często bez pełnej informacji dla produkcji, co kończy się niespodziankami na kolejnej zmianie. Tam, gdzie obowiązuje prosta zasada – zgłoszenie, decyzja o priorytecie, okno na wgranie, krótka informacja zwrotna – liczba konfliktów i nieporozumień spada dramatycznie, a protokół SAT jest spójny z faktycznie testowaną wersją systemu.

Świadomie przeprowadzony FAT i SAT tworzą razem jedną, logiczną ścieżkę: od zweryfikowanego w warsztacie kodu, przez sprawdzoną instalację na obiekcie, aż po udokumentowane, działające scenariusze produkcyjne. Im lepiej te dwa światy – biurowy i „hale produkcyjne” – są ze sobą skoordynowane, tym mniej czasu i nerwów pochłaniają późniejsze poprawki, a linia szybciej zaczyna realnie zarabiać.

Najczęściej zadawane pytania (FAQ)

Co to jest FAT i SAT w systemach automatyki i czym się różnią?

FAT (Factory Acceptance Test) to testy odbiorowe prowadzone u integratora lub producenta maszyny, w warunkach warsztatowych. Koncentrują się na logice sterowania, oprogramowaniu PLC, ekranach HMI/SCADA i komunikacji z urządzeniami, zwykle z wykorzystaniem symulatorów sygnałów i atrap zamiast prawdziwego procesu.

SAT (Site Acceptance Test) odbywa się już na obiekcie docelowym – z faktycznymi maszynami, mediami i pełnym okablowaniem. Obejmuje testy instalacji, integrację sygnałów „na żywo”, próby procesowe i pełne sprawdzenie bezpieczeństwa. W skrócie: FAT sprawdza, czy system zrobiono zgodnie z założeniami, a SAT – czy działa poprawnie tam, gdzie ma pracować.

Po co robi się FAT i SAT przy uruchomieniu systemu sterowania?

Główny cel FAT i SAT to ograniczenie ryzyka technicznego, czasowego i finansowego. Dzięki FAT większość błędów w logice, komunikacji czy ergonomii HMI wychwytywana jest jeszcze przed wysyłką systemu na obiekt, co skraca i uspokaja późniejsze uruchomienie.

Podczas SAT potwierdza się, że system sterowania współpracuje prawidłowo z realnym procesem, maszynami i okablowaniem. Klient zyskuje pewność co do stabilności produkcji, a integrator – formalny dowód, że zakres i jakość dostawy odpowiadają uzgodnionym wymaganiom URS/FDS.

Jaki jest dokładny zakres FAT, a co powinno wejść w SAT?

W FAT zwykle testuje się:

• logikę sterowania i sekwencje w oprogramowaniu PLC,
• ekrany HMI/SCADA, alarmy, raporty i uprawnienia,
• komunikację z napędami, modułami I/O i systemami nadrzędnymi,
• symulowane scenariusze procesowe i podstawowe funkcje bezpieczeństwa, które da się odtworzyć w warsztacie.

W SAT zakres przesuwa się na stronę instalacji i procesu. Sprawdza się poprawność okablowania i adresacji, wykonuje testy I/O „na żywo” z prawdziwymi czujnikami i elementami wykonawczymi, prowadzi testy z medium lub produktem oraz pełne testy zatrzymań awaryjnych, blokad i innych funkcji bezpieczeństwa w realnych warunkach.

Kto uczestniczy w testach FAT i SAT i jaka jest ich rola?

W FAT kluczową rolę ma integrator systemu sterowania – przygotowuje stanowisko, scenariusze testowe i odpowiada za logikę PLC oraz konfigurację komunikacji. Po stronie klienta zwykle pojawiają się przedstawiciele utrzymania ruchu, przyszli operatorzy i dział jakości, którzy weryfikują zgodność z URS/FDS i ergonomię obsługi.

Jeśli producent maszyny jest inną firmą niż integrator, w FAT często potwierdza on poprawną współpracę swojego urządzenia z systemem sterowania. W SAT głównym „sędzią” staje się użytkownik końcowy – to on ocenia przydatność, niezawodność i wpływ systemu na rozruch oraz produkcję, a integrator odpowiada za usuwanie wykrytych niezgodności.

Jakie błędy najczęściej wychodzą na FAT, a jakie dopiero na SAT?

Podczas FAT na ogół wychodzą na jaw błędy w logice PLC, niewłaściwe sekwencje, nieintuicyjne ekrany HMI, problemy z komunikacją (adresacja, konfiguracja protokołów) oraz brak zgodności z FDS/SDS. To także dobry moment na skorygowanie tekstów alarmów, raportów czy uprawnień użytkowników.

Na SAT częściej pojawiają się problemy instalacyjne i integracyjne: zamienione przewody na zaciskach, błędne adresy I/O, zła polaryzacja sygnałów, źle ustawione czujniki, a także błędy wynikające z dynamiki procesu – np. nieoptymalne nastawy czasów, histeryz czy parametrów napędów, których nie dało się w pełni przewidzieć na symulatorach.

Jak przygotować się do FAT i SAT, żeby skrócić czas uruchomienia?

Do FAT dobrze jest wejść z kompletną, przetestowaną „na sucho” logiką PLC i w pełni skonfigurowanym HMI/SCADA. Pomaga też szczegółowa lista testowa (checklista) oparta o URS/FDS, przemyślany zestaw scenariuszy awaryjnych oraz możliwość łatwej symulacji sygnałów I/O. Dzięki temu na obiekcie nie traci się czasu na podstawowe poprawki programistyczne.

Przy SAT kluczowe jest wcześniejsze sprawdzenie dokumentacji okablowania, adresacji i schematów, a także uzgodnienie z klientem, w jakiej kolejności będą uruchamiane poszczególne części instalacji. Przy dużych liniach dobrze sprawdza się podejście etapowe: najpierw testy I/O, potem funkcje bezpieczeństwa, a na końcu scenariusze procesowe z medium lub produktem.

Czy można pominąć FAT i zrobić tylko SAT na obiekcie?

Formalnie bywa to możliwe, ale z praktycznego punktu widzenia zwykle się nie opłaca. Bez FAT większość błędów programistycznych i konfiguracyjnych wychodzi dopiero na obiekcie, gdzie każda godzina postoju i pracy ekipy uruchomieniowej jest znacznie droższa, a presja czasu znacznie większa.

FAT zmniejsza liczbę niespodzianek na SAT i skraca rozruch, szczególnie przy złożonych liniach i systemach bezpieczeństwa. Pominąć FAT można jedynie przy bardzo prostych aplikacjach lub drobnych modyfikacjach, gdy ryzyko jest niskie, a zakres zmian klarowny – i zwykle po uzgodnieniu tego podejścia z klientem.

Co warto zapamiętać

• FAT i SAT mają wspólny cel – ograniczenie ryzyka technicznego, czasowego i finansowego – ale kontrolują je w dwóch różnych momentach: przed wysyłką systemu oraz już na docelowym obiekcie.
• FAT to „laboratoryjna” weryfikacja logiki sterowania, HMI/SCADA, komunikacji i podstawowych funkcji bezpieczeństwa z użyciem symulatorów; sprawdza, czy system został wykonany zgodnie z FDS/SDS i URS.
• SAT odbywa się na rzeczywistej instalacji z pełnym okablowaniem, mediami i maszynami; potwierdza poprawność integracji, działanie procesu „na żywo” i komplet funkcji bezpieczeństwa w realnych warunkach.
• Dla integratora FAT jest ostatnią szansą na wychwycenie błędów logiki i komunikacji w bezpiecznym środowisku, a SAT staje się testem jakości jego pracy, bo każde nowe usterki oznaczają dodatkowe koszty i napięcia z klientem.
• Klient patrzy na FAT jak na moment dopasowania systemu do własnego procesu (ergonomia HMI, alarmy, raporty) i potwierdzenie wymagań URS/FDS, a na SAT – jak na sprawdzian niezawodności i czasu rozruchu produkcji.
• Producent maszyny wykorzystuje FAT do potwierdzenia poprawnej współpracy urządzenia z systemem sterowania i wyłapania usterek mechanicznych czy pneumatycznych jeszcze przed wysyłką, co ogranicza kosztowne poprawki na obiekcie.
• Kluczowa różnica praktyczna: FAT weryfikuje, czy system zbudowano „zgodnie z założeniami”, natomiast SAT – czy ten sam system działa poprawnie i bezpiecznie „tam, gdzie ma naprawdę pracować”.