GAMP 5 i predykcyjne utrzymanie ruchu: kategoria oprogramowania i walidacja

W skrócie: GAMP 5 to oparte na ryzyku ramy ISPE do walidacji systemów skomputeryzowanych w środowiskach regulowanych. Skonfigurowana platforma analityczna do predykcyjnego utrzymania ruchu to produkt skonfigurowany kategorii 4 (ta sama kategoria co SCADA, MES i LIMS), a nie infrastruktura kategorii 1. Walidacja jest proporcjonalna do ryzyka GxP, a przeprowadzasz ją Ty, w ramach własnego systemu jakości.

Przegląd zakupowy, który utyka na jednym pytaniu

Twój zespół ds. niezawodności przeprowadził już pilotaż. Detektor anomalii wychwycił degradujące się łożysko trzy tygodnie przed jego zatarciem, a trend drgań to potwierdził. Wszyscy w pokoju (utrzymanie ruchu, inżynieria, nawet kierownik zakładu) chcą przejść do wdrożenia w całym zakładzie.

Potem wniosek trafia na biurko kierownika ds. walidacji i spotkanie przybiera inny obrót. „Jaka to kategoria GAMP?" to nie taktyka zwlekania: to pytanie decyduje, czy będzie to dwutygodniowe ćwiczenie konfiguracyjne, czy projekt wymagający własnej linii budżetowej i głównego planu walidacji systemów skomputeryzowanych (CSV). Zbyt często uczciwą odpowiedzią dostawcy jest wzruszenie ramion, marketingowy PDF głoszący „pełną zgodność" albo pewna siebie odpowiedź, która po prostu jest błędna.

Błędnie określona kategoria prowadzi do jednej z dwóch sytuacji. Nazwij skonfigurowaną platformę analityczną „infrastrukturą kategorii 1", a nie docenisz przeglądu, jakiego wymaga: walidacja infrastruktury weryfikuje instalację, a nie to, czy wyniki modelu nadają się do podjęcia decyzji utrzymaniowej. Nazwij ją „oprogramowaniem dedykowanym kategorii 5", a poddasz konfigurowalny produkt wysiłkowi walidacyjnemu właściwemu dla oprogramowania na zamówienie, którego wcale nie potrzebuje. Błędna klasyfikacja to jeden z najczęstszych powodów, dla których dobre narzędzie utyka w procesie zakupowym, a można tego uniknąć, gdy się wie, gdzie faktycznie plasuje się oprogramowanie PdM.

(Ten artykuł zakłada znajomość podstaw środowiska regulowanego, omówionych w naszych artykułach o produkcji wyrobów medycznych i farmaceutycznym GMP, a także szersze spojrzenie na ocenę dostawców z artykułu Jak wybrać platformę do predykcyjnego utrzymania ruchu. Ten tekst zagłębia się w jedno konkretne pytanie: do jakiej kategorii GAMP 5 należy oprogramowanie PdM i kto faktycznie je waliduje.)

Czym jest GAMP 5?

GAMP 5 (Good Automated Manufacturing Practice, obecnie w drugim wydaniu) to oparte na ryzyku ramy ISPE do walidacji systemów skomputeryzowanych w środowiskach regulowanych GxP (GxP: dobra praktyka wytwarzania, laboratoryjna, kliniczna i dystrybucyjna). To nie jest sama w sobie regulacja prawna: to model referencyjny, który zgodnie z oczekiwaniami organów nadzoru powinien stosować dojrzały system jakości, skalujący wysiłek walidacyjny do ryzyka, zamiast testować wszystko z tą samą dokładnością.

GAMP 5 jest publikowany przez ISPE, International Society for Pharmaceutical Engineering, a jego centralnym założeniem jest dźwignia: wykorzystać dokumentację rozwojową i jakościową dostawcy zamiast dowodzić wszystkiego od podstaw, oraz skalować własny wysiłek do faktycznego ryzyka systemu, zamiast testować każdą funkcję z tą samą wyczerpującą dokładnością (ISPE GAMP 5 Guide, 2nd Edition).

Ramy te wykonują jednocześnie dwa zadania, a ich mylenie jest dokładnie tym, skąd bierze się opisany wyżej zastój w przeglądzie zakupowym: klasyfikują, jaki rodzaj oprogramowania waliduje się (kategorię, od infrastruktury po w pełni dedykowany kod) oraz klasyfikują, jak oprogramowanie jest używane, czy bezpośrednio wykonuje, czy tylko informuje decyzję GxP, co decyduje o tym, jak głęboka musi być walidacja. Kategoria określa podejście do walidacji; wpływ GxP określa głębokość walidacji. Sprowadzenie tych dwóch osi do jednego pytania jest właśnie tym, skąd bierze się błędne przypisanie „kategorii 1" do skonfigurowanej platformy analitycznej.

Kategorie oprogramowania w GAMP 5

GAMP 5 zastąpił pięciopoziomowy schemat GAMP 4 czterema kategoriami (1, 3, 4 i 5, bez kategorii 2), uszeregowanymi według tego, w jakim stopniu zachowanie oprogramowania jest unikalne dla Twojej instalacji. Infrastruktura znajduje się na jednym końcu spektrum, w pełni dedykowany kod na drugim, a wysiłek walidacyjny skaluje się wzdłuż tego samego spektrum.

| Kategoria | Co obejmuje | Prosty przykład | Implikacja dla walidacji | |---|---|---|---| | 1: Infrastruktura | Systemy operacyjne, silniki baz danych, komponenty sieciowe, middleware: platforma, na której działa inne oprogramowanie | Windows Server, PostgreSQL, zarządzany klaster Kubernetes | Walidowana poprzez kwalifikację infrastruktury i kontrolę zmian, a nie pełną walidację systemu | | 3: Produkty nieskonfigurowane | Gotowe oprogramowanie komercyjne (COTS) używane w stanie, w jakim zostało dostarczone, bez konfiguracji logiki biznesowej | Oprogramowanie raportujące samodzielnego przyrządu laboratoryjnego, używane od razu po rozpakowaniu | Weryfikacja instalacji plus testy funkcji istotnych dla GxP, które faktycznie wykorzystujesz | | 4: Produkty skonfigurowane | Pakiety komercyjne skonfigurowane pod Twoje środowisko (role użytkowników, przepływy pracy, parametry, integracje) bez dedykowanego kodu | SCADA, MES, LIMS, DCS oraz platforma monitorująco-analityczna skonfigurowana z Twoimi zasobami, czujnikami i progami | Testy oparte na ryzyku dla Twojej konfiguracji: czy działa zgodnie z konfiguracją, dla Twojego zamierzonego zastosowania | | 5: Aplikacje dedykowane | Kod pisany na zamówienie, aplikacje tworzone niestandardowo, systemy mocno dostosowane, wewnętrzne skrypty i makra | Wewnętrzny interfejs LIMS, dedykowany kalkulator zwolnienia partii | Pełny cykl życia wytwarzania oprogramowania: specyfikacje projektowe, przegląd kodu, testy strukturalne i funkcjonalne |

Warto zauważyć dwie rzeczy. Po pierwsze, kategorie odzwierciedlają spektrum tego, w jakim stopniu zachowanie oprogramowania jest unikalne dla Ciebie: infrastruktura jest identyczna wszędzie, gdzie jest zainstalowana, dedykowany kod nie istnieje nigdzie indziej. Po drugie, wysiłek walidacyjny odzwierciedla to samo spektrum: kategoria 1 opiera się na rygorze rozwojowym samego dostawcy oraz na Twojej instalacji i kontroli zmian; kategoria 5 zakłada, że nic nie zostało wcześniej zbudowane ani przetestowane, więc ten dowód budujesz sam.

Gdzie plasuje się oprogramowanie predykcyjnego utrzymania ruchu

Platforma analityczna do predykcyjnego utrzymania ruchu (Prevly nie jest wyjątkiem) to produkt skonfigurowany kategorii 4. Konfigurujesz ją pod swoje środowisko (hierarchia zasobów, mapowania czujników, progi alarmowe, role), zamiast uruchamiać ją bez zmian lub pisać dedykowany kod, a to dokładnie profil, który GAMP 5 przypisuje kategorii 4: tej samej kategorii, którą zajmują SCADA, MES i LIMS.

Oto błędne przekonanie, które warto nazwać po imieniu, bo jest na tyle powszechne, że stanowi powód powstania tego artykułu: oprogramowanie predykcyjnego utrzymania ruchu nie jest kategorią 1 GAMP 5. Kategoria 1 to infrastruktura: system operacyjny i baza danych, na których działa skonfigurowana aplikacja, walidowana poprzez zarządzanie konfiguracją, ponieważ nie ma tu specyficznego dla aplikacji zachowania do przetestowania. Platforma PdM ma dokładnie takie zachowanie: pobiera dane z Twoich czujników, uruchamia na nich modele oraz udostępnia alarmy i prognozy, na podstawie których działa Twój zespół. To właśnie umieszcza ją w kategorii 4, a nie poniżej niej, w kategorii 1.

To nie jest też kategoria 5. Konfigurowanie hierarchii zasobów, mapowań czujników i routingu alarmów w żaden sposób nie stanowi pisania dedykowanego kodu: nie tworzysz autoenkodera LSTM ani modelu RUL wzmacnianego gradientowo; kierujesz gotowy, wcześniej przetestowany potok modeli na swoje urządzenia. Umieszczenie tego w kategorii 5 oznaczałoby walidowanie tego tak, jakby było oprogramowaniem dedykowanym zbudowanym od zera dla Twojego zakładu, co zarówno przecenia potrzebny wysiłek, jak i pomija to, gdzie faktycznie leżą prawdziwe pytania walidacyjne: nie „czy ten kod działa", lecz „czy ta konfiguracja daje wiarygodne wyniki dla naszych urządzeń".

Kategoria a wpływ GxP: oś, o której się zapomina

Kategoria oprogramowania odpowiada na pytanie, czym dana rzecz jest; nie odpowiada na pytanie, jak bardzo istotne jest to, że oprogramowanie się myli. GAMP 5 łączy kategorię z opartą na ryzyku oceną wpływu: bezpośrednim wpływem GxP (system wykonuje działanie lub podejmuje decyzję) w porównaniu z pośrednim, informacyjnym wpływem (informuje decyzję, którą przegląda i za którą odpowiada wykwalifikowana osoba).

Platforma predykcyjnego utrzymania ruchu plasuje się bliżej tego drugiego, lżejszego końca. Analizuje dane z czujników i rekomenduje działanie: sygnalizuje łożysko, które wygląda na degradujące się, szacuje pozostały czas pracy, ujawnia, które czujniki zdecydowały o tym wskazaniu. Nie zwalnia partii ani nie zmienia nastawy. To zastosowanie informacyjne, o pośrednim wpływie GxP, więc wysiłek walidacyjny powinien być proporcjonalny: lżejszy niż w przypadku systemu ewidencyjnego, ale niezerowy, ponieważ błędna prognoza prowadząca do błędnej decyzji utrzymaniowej wciąż jest realnym ryzykiem, którym warto świadomie zarządzać.

To również miejsce, w którym ma zastosowanie 21 CFR Part 11, albo nie ma. Part 11 reguluje zapisy elektroniczne i podpisy elektroniczne, ale tylko dla zapisów spełniających regułę źródłową (predicate rule): istniejące wymaganie, np. zobowiązania dotyczące zapisów utrzymaniowych zawarte w 21 CFR 211.67(c) (pharma cGMP), lub jego odpowiednik po stronie wyrobów w ramach QMSR (21 CFR Part 820, który od lutego 2026 inkorporuje ISO 13485:2016), prowadzonych w formie elektronicznej. To, czy alarm PdM staje się zapisem w rozumieniu Part 11, zależy od tego, czy jest wykorzystywany jako dowód dla decyzji regulowanej, a nie od kategorii GAMP oprogramowania. Ten mechanizm (ścieżki audytu, podpisy elektroniczne, ALCOA+) omawiamy w artykule 21 CFR Part 11 a integralność danych predykcyjnego utrzymania ruchu; ten artykuł pozostaje przy kategoryzacji.

Cykl życia walidacji i przejście od CSV do CSA

Dla produktu kategorii 4 o pośrednim wpływie GxP walidacja przebiega według tego samego schematu, niezależnie od tego, czy zbiorem zasad jest tradycyjne CSV (walidacja systemów skomputeryzowanych) czy nowsze CSA (Computer Software Assurance): zdefiniuj wymagania, oceń ryzyko, a następnie zakwalifikuj instalację, działanie i wydajność. To, co zmieniło się wraz z CSA, to ilość skryptowanej dokumentacji, jakiej ten schemat wymaga.

Klasyczna sekwencja:

1. URS (User Requirements Specification): co system ma robić, w Twoim środowisku, dla Twojego zamierzonego zastosowania.
2. FS (Functional Specification): jak skonfigurowany system spełnia te wymagania: które zasoby, które progi, które role.
3. Ocena ryzyka: miejsce, w którym mieszka prawdziwa dyscyplina GAMP 5: uszereguj każde wymaganie według wpływu GxP i złożoności, i odpowiednio skaluj rygor testów, zamiast testować wszystko z tą samą wyczerpującą dokładnością.
4. IQ/OQ/PQ: Installation Qualification (czy zostało poprawnie zainstalowane), Operational Qualification (czy działa zgodnie ze specyfikacją w całym zamierzonym zakresie), Performance Qualification (czy działa niezawodnie w Twoich rzeczywistych warunkach eksploatacji, na Twoich rzeczywistych urządzeniach).

To tradycyjne CSV i nie jest ono błędne: bywa jednak zbyt często nadużywane. FDA zaproponowało lżejszą alternatywę we wrześniowym projekcie wytycznych z 2022 roku, a sfinalizowało ją we wrześniu 2025 roku jako „Computer Software Assurance for Production and Quality System Software", o zakresie ograniczonym do oprogramowania produkcji wyrobów i systemu jakości, ale jej filozofia krytycznego myślenia stała się punktem odniesienia, z którego korzysta dziś szersza społeczność CSV i GAMP 5. Kluczowy ruch CSA: zastąpienie wyczerpującego, skryptowanego testowania każdej funkcji krytycznym myśleniem zastosowanym z góry: określ zamierzone zastosowanie, oceń ryzyko i odpowiednio dobierz działania zapewniające, rezerwując skryptowane testy dla funkcji, w których wpływ GxP jest naprawdę wysoki (ISPE, "Computer Software Assurance and Critical Thinking").

Dla platformy kategorii 4 o pośrednim wpływie, takiej jak narzędzie analityczne PdM, ta zmiana ma praktyczne znaczenie: to różnica między wysiłkiem walidacyjnym trwającym proporcjonalnie kilka tygodni a takim, który trwa proporcjonalnie kilka miesięcy dla tego samego faktycznego ryzyka. Ani CSV, ani CSA nie zmieniają tego, czy walidujesz: oba zakładają, że to robisz. To, co się zmieniło, to przyzwolenie, by przestać traktować każdy przypadek testowy jako równie ważny.

Kto faktycznie to waliduje

Ty to walidujesz, w ramach własnego systemu zarządzania jakością (QMS), nie dostawca i nie pieczątka strony trzeciej, którą można kupić. Dostawca może udokumentować własny rygor rozwojowy, żebyś nie musiał odtwarzać go od zera, ale walidacja jest z natury specyficzna dla Twojego zamierzonego zastosowania, Twojej konfiguracji i Twojej oceny ryzyka.

Dostawca twierdzący „jesteśmy zwalidowani zgodnie z GAMP 5" wygłasza twierdzenie, które właściwie nie ma sensu: GAMP 5 to ramy, które się stosuje, a nie certyfikat, który produkt zdobywa raz i nosi ze sobą wszędzie.

Ten podział pracy jest dokładnie tym, dlaczego „zdolny do" i „zgodny z" to nie to samo. Platformę można zbudować tak, by walidacja była szybka i możliwa do obrony: to wybór projektowy i dokumentacyjny, nad którym kontrolę ma dostawca. Natomiast to, czy Twoja konkretna instalacja, w Twojej konkretnej lokalizacji, jest rzeczywiście zwalidowana, to fakt, który może ustalić wyłącznie Twój system jakości, bo tylko Ty dysponujesz URS, oceną ryzyka i uprawnieniem do zatwierdzenia, które czynią to prawdą.

Jak to wygląda w przypadku Prevly

Warstwa Validated Prevly dostarcza pakiet dokumentacji GAMP 5 / CSV dopasowany do zastosowania kategorii 4 o pośrednim wpływie, podpisy elektroniczne zgodne z Part 11 oraz ścieżkę audytu zorientowaną na ALCOA+ dla alarmów, prognoz i zatwierdzeń; domyślnie on-premise, z pozyskiwaniem danych tylko do odczytu, które nigdy nie zapisuje do sterownika PLC, który już zwalidowałeś.

Modele stojące za tym zachowują tę samą uczciwą granicę wszędzie indziej: autoenkoder LSTM do wykrywania anomalii, kalibrowany konforemnie na bazowej charakterystyce Twoich własnych urządzeń; model wzmacniany gradientowo (LightGBM) z atrybucją SHAP dla pozostałego czasu pracy, zwalidowany na publicznym zbiorze danych NASA C-MAPSS i raportowany jako konforemne przedziały predykcyjne, a nie pojedyncza, nadmiernie pewna siebie liczba; Integrated Gradients na sieci CNN-1D dla atrybucji usterek, która, w odróżnieniu od pozostałych dwóch, obecnie działa na syntetycznym demonstratorze, i mówimy o tym wprost w samym produkcie, nie tylko tutaj.

Żadna z tych rzeczy nie sumuje się do certyfikatu. Walidację Twojej konkretnej instalacji przeprowadzasz Ty w ramach własnego systemu jakości; Prevly sam w sobie nie jest certyfikatem regulacyjnym. To, co zmienia to narzędzie, to ilość pracy dokumentacyjnej, która istnieje już, zanim Twój kierownik ds. walidacji otworzy pusty szablon: pakiet GAMP 5 / CSV, który rozpoczyna macierz identyfikowalności, zamiast zostawiać Ci budowanie jej od zera na podstawie karty danych dostawcy i modlitwy.

Najczęściej zadawane pytania

Do jakiej kategorii GAMP 5 należy oprogramowanie predykcyjnego utrzymania ruchu? Kategoria 4: produkt skonfigurowany. Platforma analityczna PdM to oprogramowanie komercyjne, które konfigurujesz (zasoby, mapowania czujników, progi, role), a nie oprogramowanie, które budujesz od zera lub uruchamiasz bez zmian. To umieszcza ją w tej samej kategorii co systemy SCADA, MES i LIMS.

Czy oprogramowanie predykcyjnego utrzymania ruchu to kategoria 1? Nie. Kategoria 1 to infrastruktura (systemy operacyjne, bazy danych, middleware), walidowana poprzez konfigurację i kontrolę zmian, ponieważ nie ma własnego, specyficznego dla aplikacji zachowania. Platforma PdM ma takie specyficzne dla aplikacji zachowanie (przetwarza dane z czujników i generuje alarmy oraz prognozy), co zamiast tego umieszcza ją w kategorii 4.

Kto odpowiada za walidację oprogramowania zgodnie z GAMP 5? Ty, w ramach własnego systemu zarządzania jakością. Dostawca może dostarczyć dokumentację własnego rygoru rozwojowego i testowego, aby wesprzeć Twój wysiłek, ale tylko Ty dysponujesz zamierzonym zastosowaniem, oceną ryzyka i uprawnieniem do zatwierdzenia, które czynią walidację prawdziwą. Żaden dostawca nie „waliduje się sam" w Twoim imieniu.

Jaka jest różnica między GAMP 5 a CSA? GAMP 5 to ogólne, oparte na ryzyku ramy walidacyjne; CSA (Computer Software Assurance) to nowsze sformułowanie FDA tej samej idei: krytyczne myślenie i proporcjonalne testowanie zamiast wyczerpującego, skryptowanego testowania każdej funkcji. Są komplementarne, a nie konkurencyjne: CSA to lżejszy sposób na spełnienie tej samej zasady GAMP 5.

Czy oprogramowanie predykcyjnego utrzymania ruchu musi być zgodne z Part 11? Tylko dla zapisów spełniających regułę źródłową (predicate rule): istniejące wymaganie, takie jak zobowiązania dotyczące zapisów utrzymaniowych z 21 CFR 211.67(c), prowadzonych elektronicznie. To pytanie o zapisy i podpisy, odrębne od kategorii GAMP, w pełni omówione w naszym dedykowanym artykule o Part 11.

Wejdź na kolejny przegląd zakupowy z kategorią, którą możesz obronić

Najszybszym sposobem na zablokowanie dobrego pilotażu predykcyjnego utrzymania ruchu jest wejście na przegląd walidacyjny bez jasnej odpowiedzi na pytanie „jaka to kategoria GAMP i kto to waliduje". Prevly to produkt skonfigurowany kategorii 4 GAMP 5, wykorzystywany do wsparcia decyzji o charakterze informacyjnym i pośrednim wpływie GxP, a warstwa Validated dostarcza dokumentację GAMP 5 / CSV, podpisy elektroniczne zgodne z Part 11 oraz ścieżkę audytu zorientowaną na ALCOA+, które przyspieszają Twój własny wysiłek walidacyjny, a nie stanowią cudzego sposobu na jego obejście.

Poproś o demo Prevly

Powiązane artykuły: 21 CFR Part 11 a integralność danych predykcyjnego utrzymania ruchu · Predykcyjne utrzymanie ruchu w produkcji farmaceutycznej GMP · Predykcyjne utrzymanie ruchu w produkcji wyrobów medycznych (IEC 62443 SL-1) · Jak wybrać platformę do predykcyjnego utrzymania ruchu