Przygotowanie do audytu bezpieczeństwa funkcjonalnego IEC 61511: Tworzenie obronnego pakietu dowodowego dla systemów bezpieczeństwa instrumentowanych Invensys Triconex

Co faktycznie sprawdzają audytorzy

Audyt bezpieczeństwa funkcjonalnego zgodnie z IEC 61511 to nie jest przegląd dokumentów — to analiza luk pomiędzy Specyfikacją Wymagań Bezpieczeństwa (SRS) a systemem zbudowanym i utrzymywanym. Audytorzy najpierw sprawdzają trzy rzeczy: kompletność dokumentacji bezpieczeństwa, integralność zapisów testów dowodowych oraz ważność deklarowanego poziomu SIL. W przypadku instalacji Invensys Triconex T3000 lub Tricon CX pakiet dowodowy musi wykazać, że SIS został zaprojektowany, zainstalowany i utrzymywany zgodnie z SRS. Luki w którymkolwiek z tych obszarów mogą obniżyć efektywny poziom SIL z SIL 2 do SIL 1 — lub w poważnych przypadkach całkowicie unieważnić dokumentację bezpieczeństwa.

Po pierwsze, zgromadź kompletny dokument SRS zawierający wszystkie opisy Funkcji Instrumentowanych Bezpieczeństwa (SIF), cele SIL oraz wskaźniki zapotrzebowania procesowego. Po drugie, potwierdź, że wszystkie konfiguracje projektu TriStation 1131 odpowiadają SRS — architektura, logika głosowania, logika obejścia oraz pokrycie diagnostyczne. Po trzecie, zweryfikuj, czy zapisy testów dowodowych są podpisane, opatrzone datą i zawierają czasy reakcji zmierzone podczas testu — nie tylko pola wyboru zaliczenia/niezaliczenia.

Przeliczenie PFDavg i weryfikacja SIL

Prawdopodobieństwo awarii na żądanie (średnie) — PFDavg — określa niezawodność SIS w okresie testu dowodowego. SIL 2 wymaga PFDavg w zakresie od 1×10⁻³ do 1×10⁻². Architektura Triconex T3000 TMR z logiką głosowania 2oo3 osiąga niskie wartości PFDavg dzięki wysokiemu pokryciu diagnostycznemu (DC ≥ 99%) i wbudowanej redundancji. Jednak opublikowane wartości PFDavg z raportów FMEDA Triconex zakładają określone interwały testów dowodowych i warunki eksploatacji.

Przelicz PFDavg dla każdego SIF, stosując uproszczony wzór dla podsystemu 1oo1: PFDavg = λDU × Ti / 2, gdzie λDU to wskaźnik niebezpiecznych awarii niewykrytych, a Ti to interwał testu dowodowego w godzinach. Dla Triconex T3000 z λDU = 2,3×10⁻⁷ na godzinę (wg FMEDA Triconex Rev 4) i Ti = 8760 godzin (test roczny): PFDavg = 2,3×10⁻⁷ × 8760 / 2 = 1,0×10⁻³. To dokładnie dolna granica SIL 2 — bez marginesu. Skrócenie Ti do 4380 godzin (test półroczny) zmniejsza PFDavg do 5,0×10⁻⁴, co plasuje SIF komfortowo w zakresie SIL 2.

Element końcowy (zawór ESD lub urządzenie wyłączające) często dominuje w PFDavg SIF, a nie logika sterownika Triconex. Typowy zawór elektromagnetyczny z λDU = 5×10⁻⁷ na godzinę i Ti = 8760 godzin generuje PFDavg = 2,2×10⁻³ — samodzielnie wystarczający, by wyczerpać budżet SIL 2. Testy częściowego skoku (PST) co 3 miesiące redukują ten wkład do 5,5×10⁻⁴ i odzyskują istotny margines PFDavg.

Usuwanie luk w zapisach testów dowodowych

Najczęstszym wynikiem audytu instalacji Triconex są niekompletne zapisy testów dowodowych. IEC 61511, punkt 16.2.5 wymaga, aby zapisy testów zawierały: datę testu, tożsamość technika, metodę testu, stan zmierzony przed testem, wynik testu oraz stan po teście. Zapisy zawierające tylko podpis i oznaczenie „PASS” są niezgodne z normą.

• Krok 1: Przeprowadź audyt wszystkich zapisów testów dowodowych SIF z ostatniego interwału testowego. Stwórz macierz luk: numer SIF, data testu, brakujące pola, odpowiedzialny technik.
• Krok 2: W przypadku braków w czasie reakcji zmierzonym przed testem, skontaktuj się z oryginalnym technikiem i poproś o oświadczenie pod przysięgą o wartości zmierzonej z pamięci — jeśli jest udokumentowana gdzie indziej (notes terenowy, system kalibracji). Dołącz oświadczenie do oryginalnego zapisu.
• Krok 3: Dla zapisów całkowicie pozbawionych danych przed testem, formalnie udokumentuj lukę jako niezgodność w systemie zarządzania bezpieczeństwem. Przydziel działanie korygujące polegające na przeprowadzeniu niezaplanowanego testu dowodowego przy najbliższej dostępnej przerwie konserwacyjnej, aby ustalić nową bazę odniesienia.
• Krok 4: Wdroż szablon testu dowodowego w systemie CMMS (SAP PM lub podobnym). Szablon musi wymuszać obowiązkowe pola — czas reakcji w milisekundach, potwierdzenie przemieszczenia elementu końcowego oraz diagnostyczny zrzut TriStation Triconex przed i po teście. Zablokuj zapis tak, aby nie można było zaznaczyć PASS bez wpisania numerycznego czasu reakcji.

Wymagania dokumentacyjne zarządzania obejściem

Zarządzanie obejściem to krytyczny wymóg IEC 61511, punkt 11.9.4. Za każdym razem, gdy SIF Triconex T3000 jest umieszczany w obejściu, ryzyko resztkowe rośnie — funkcja bezpieczeństwa jest niedostępna. Rejestr obejść musi zawierać: powód obejścia, uprawnioną osobę zatwierdzającą, czas rozpoczęcia, planowany czas zakończenia oraz środki kompensacyjne zastosowane w okresie obejścia.

W TriStation 1131 warunki obejścia są realizowane przez zmienne INHIBIT lub BYPASS w programie sterującym. Każda zmienna INHIBIT musi być powiązana z fizycznym przełącznikiem kluczykowym lub tagiem autoryzacji na poziomie SCADA. Skonfiguruj program TriStation tak, aby zapisywał zdarzenie obejścia w dzienniku SOE (Sequence of Events) za każdym razem, gdy zmienna INHIBIT zmienia stan. Znacznik czasu SOE zapewnia ścieżkę audytu wymaganą przez IEC 61511.

SRS musi określać maksymalny dopuszczalny czas trwania obejścia dla każdego SIF na podstawie wskaźnika zapotrzebowania procesowego. Dla SIF chroniącego przed zagrożeniem o wskaźniku zapotrzebowania 0,1 na rok, maksymalny czas obejścia bez środków kompensacyjnych wynosi zwykle 72 godziny. Audytorzy porównają rejestr obejść w CMMS z dziennikiem SOE — rozbieżności między nimi wskazują, że proces kontroli obejścia nie działa prawidłowo i stanowią systemową niezgodność według IEC 61511, punkt 5.

Lista kontrolna weryfikacji konfiguracji przed audytem

• Eksportuj raport konfiguracji projektu TriStation 1131 i porównaj wszystkie nastawy wyzwalania SIF z SRS. Każde odstępstwo wymaga rejestru Zarządzania Zmianą (MOC) z datą przed wdrożeniem zmiany.
• Zweryfikuj, czy wersja oprogramowania Triconex T3000 odpowiada wersji zatwierdzonej w dokumentacji bezpieczeństwa. Aktualizacje oprogramowania Triconex wymagają ponownej walidacji zgodnie z IEC 61511, punkt 11.8.5, jeśli wpływają na funkcje związane z bezpieczeństwem.
• Potwierdź, że wszystkie interwały testów diagnostycznych mieszczą się w wartościach określonych w SRS. Domyślny cykl autotestu modułu T3000 to 1 godzina — sprawdź, czy nie został wydłużony, aby zmniejszyć częstotliwość alarmów SCADA DIAG_FAIL.
• Sprawdź, czy data i czas Triconex T3000 synchronizują się z serwerem NTP zakładu. Niesynchronizowane znaczniki czasu SOE to częsta niezgodność audytowa, podważająca kolejność wszystkich historycznych zdarzeń bezpieczeństwa.
• Przejrzyj dziennik zmian w TriStation pod kątem modyfikacji konfiguracji dokonanych bez powiązanego rejestru MOC. Nieautoryzowane zmiany to poważna niezgodność według IEC 61511, punkt 5.2.4 (zarządzanie bezpieczeństwem funkcjonalnym).

Podsumowanie i zalecenia

Przygotowanie instalacji Invensys Triconex do audytu bezpieczeństwa funkcjonalnego IEC 61511 wymaga systematycznego gromadzenia dowodów, a nie tworzenia dokumentów na ostatnią chwilę. Przelicz PFDavg dla każdego SIF, używając rzeczywistych interwałów testów dowodowych i danych FMEDA z instalacji — nie polegaj na opublikowanych tabelach SIL bez weryfikacji. Audytuj zapisy testów dowodowych pod kątem brakujących czasów reakcji zmierzonych przed testem i formalnie usuwaj luki. Weryfikuj zapisy zarządzania obejściem zarówno w CMMS, jak i w dzienniku SOE Triconex — rozbieżności wskazują na systemowe błędy procesowe.

Ukończ listę kontrolną weryfikacji konfiguracji na 30 dni przed audytem, aby mieć czas na dokumentację MOC dla wykrytych odstępstw. Zaangażuj kompetentnego inżyniera ds. bezpieczeństwa funkcjonalnego do przeglądu pakietu dowodowego przed przybyciem audytora. Wykrycie luki SIL 2 podczas audytu jest znacznie droższe — pod względem czasu, kosztów i ryzyka procesowego — niż wykrycie jej podczas przeglądu wewnętrznego.

Autor: Fang Haoran jest inżynierem automatyki przemysłowej z ponad 10-letnim doświadczeniem w systemach PLC, DCS i sterowania.