Ciągłość zasilania w kopalni to coś więcej niż utrzymanie wydobycia węgla. To bezpośrednia kwestia bezpieczeństwa załogi i stabilności infrastruktury. W KWK Ruda postawiliśmy na niezależność technologiczną, budując system monitoringu oparty na autorskim rozwiązaniu klasy SCADA/OT – PERUN. Projekt wpisuje się w wymogi ustawy o krajowym systemie cyberbezpieczeństwa (KSC) i dyrektywy NIS2 oraz wykorzystuje otwarte technologie i mierzalne wskaźniki jakości.
Od niezawodności zasilania zależy praca wyciągów, wentylatorów, łączności i zabezpieczeń gazometrycznych. Zanik napięcia to nie tylko przestój, lecz przede wszystkim ryzyko dla załogi i stabilności procesu. KSC [1] i NIS2 [2] nakładają na operatorów usług kluczowych obowiązek wdrożenia środków technicznych zapewniających ciągłość usług niezbędnych do świadczenia usługi kluczowej. W odpowiedzi na te wymagania w KWK Ruda uruchomiono projekt monitoringu, którego celem było wdrożenie rozwiązania pozwalającego mierzyć
i dokumentować ciągłość zasilania odbiorów krytycznych w sposób możliwy do weryfikacji. Przyjęto trzy zasady: rozwiązania mają być otwarte, ich skuteczność – mierzalna, a dobór środków technicznych – adekwatny do oszacowanego ryzyka, uwzględniając najnowszy stan wiedzy. Rozwiązanie oparto na autorskim, wewnętrznie rozwijanym środowisku PERUN, integrującym dane z rozproszonych punktów pomiarowych.
Architektura monitoringu ciągłości zasilania w KWK Ruda Ruch Bielszowice
Układ zasilania kopalni, oparty na trzech liniach 110 kV i dystrybucji kaskadowej, potraktowano jako sieć powiązanych węzłów. Sygnały binarne i analogowe pobierane są bezpośrednio z pól, jednak nie trafiają one do bazy w formie surowej. Kluczową rolę grają tutaj agenci komunikacyjni ulokowani na dedykowanych serwerach w układzie wirtualizacji, którzy normalizują formaty, nadają precyzyjny timestamping i bezpiecznie przesyłają pakiety do bazy szeregów czasowych. Architektura monitoringu w ruchu Bielszowice obejmuje 8 rozdzielni oraz logikę przełączania rezerwy (SZR) [3]. PERUN pokazuje na wizualizacji aktualnie aktywne ścieżki zasilania, dzięki czemu dyspozytorzy szybciej wychwytują zakłócenia i mogą później odtworzyć pełną sekwencję zdarzeń krok po kroku (rys. 1). Kluczowe są mierzalne KPI całego procesu operacyjnego: np. dla przełączenia TRAFO 3 na TRAFO 1:
- czas całkowity wyniósł 84 s (SLA ≤ 90 s),
- czas pracy równoległej 55 s (SLA ≤ 70 s),
- max. odstęp między kolejnymi krokami 40 s (SLA ≤ 60 s).
Czas całkowity liczono od momentu inicjacji sekwencji SZR do potwierdzenia stabilnego zasilania na torze docelowym. Czas pracy równoległej wyznaczano jako okres jednoczesnej dostępności dwóch torów zasilania zgodnie z logiką SZR. Maksymalny odstęp to największa przerwa pomiędzy kolejnymi stanami pośrednimi sekwencji. Ta sama precyzja dotyczy odbiorów krytycznych – przykładowo dla maszyny wyciągowej system wskazuje udział czasu pracy (41,4% w ciągu 2 godz.), szczytowy prąd (289 A) oraz temperaturę przetwornicy (41,3ºC) (rys. 2). Wiarygodność KPI zapewnia synchronizacja czasu NTP z serwera wzorcowego oraz próbkowanie danych analogowych co 1 s. Za utratę ciągłości uznajemy stan, w którym zasilanie krytycznego odbioru jest niedostępne dłużej niż dopuszczalny czas przerwy dla danego systemu, wynikający z wymagań technologicznych i procedur ruchowych. Istotnym rozszerzeniem funkcjonalności systemu jest moduł cyfrowego bliźniaka (Digital Twin) rozdzielni. Pozwala on na przeprowadzanie symulacji przełączeń w środowisku wirtualnym, zanim zostaną one wykonane na realnym obiekcie
Wdrożenie wiązało się z ograniczeniami terenowymi i technicznymi. Część rozdzielni pamięta dawne modernizacje, a dostępne materiały trzeba było zweryfikować w terenie. Jednocześnie ciągłość pracy i organizacja postojów powodowały, że wejście do pól było możliwe jedynie
w krótkich oknach serwisowych, dlatego system rozwijaliśmy etapowo. Starsze sterowniki
i brak dokumentacji powodowały błędne odczyty, co wymuszało żmudną weryfikację sygnałów i kalibrację. Mimo tych ograniczeń podejście okazało się opłacalne, bo pozwoliło uniknąć kosztownej wymiany infrastruktury. Ta niezależność technologiczna oznaczała przejęcie pełnej odpowiedzialności za kod, co było jednak konieczne do spięcia tak różnorodnych urządzeń. Nie wszystkie założenia udało się wdrożyć od razu. Izolacja sieci OT odłożyła w czasie również plany dotyczące AI. Docelowo analitykę tę wdrożymy w wersji lokalnej (on-prem).
Rys. 1. Wizualizacja zależności zasilania w rozdzielni (fragment): stan aparatów oraz propagacja dostępności zasilania do odbiorów krytycznych (animacja w czasie)
Integralność danych pomiarowych – co jest chronione i przed czym
Systemy OT w infrastrukturze krytycznej muszą być odporne na konkretne scenariusze ataku opisane w macierzy MITRE ATT&CK[4], takie jak próby podmiany historii pomiarów (Data Manipulation), czy ingerencja w kanały komunikacyjne (Inhibit Response Function). Wskaźniki niezawodności są bezwartościowe, jeśli brakuje pewności co do pochodzenia danych. Należy zakładać możliwość podmiany lub manipulacji historią pomiarów, podszycia się pod urządzenie wysyłające dane, czy odtworzenia z archiwum niepełnego obrazu zdarzenia. Baza danych szeregów czasowych nie jest dostępna bezpośrednio z sieci. Komunikacja odbywa się wyłącznie poprzez warstwę pośrednią (reverse proxy), a do bazy trafiają jedynie dane dostarczone przez zaufanych agentów. Każdy rekord jest poddawany kanonizacji, podpisywany kryptograficznie (HMAC) oraz oznaczany rosnącym licznikiem pomiarów (rys. 3). Klucze HMAC oraz tokeny są generowane i przechowywane poza warstwą prezentacji, z odpowiednim rozdziałem uprawnień. HMAC zapewnia integralność i uwierzytelnienie pochodzenia danych; poufność realizowana jest niezależnie poprzez separację sieci oraz kontrolę kanałów komunikacji. Próba dopisania, usunięcia lub przestawienia pomiarów powoduje niespójność podpisów lub przerwanie ciągłości licznika, co system szybko wykrywa. Zrzuty danych są opatrywane sumami kontrolnymi, co umożliwia sprawdzenie, czy archiwum nie zostało zmodyfikowane. Informacje o integralności danych są dodatkowo zbierane przez system wykrywania włamań na hoście HIDSi prezentowane w środowisku PERUN.
Rys. 2. Wybrane sygnały telemetryczne (2 h): prąd, temperatury i praca maszyny.
KPI w oknie kroczącym 2 h; P95 jako miara odporna na piki
Architektura separacji – bezpieczny styk światów IT i OT
W obszarze technologii operacyjnej (OT) stosujemy fizycznie wydzieloną infrastrukturę, a komunikację z IT realizujemy wyłącznie przez kontrolowany punkt styku. W ruchu Bielszowice sieć OT zbudowano na oddzielnych włóknach światłowodowych oraz niezależnych urządzeniach sieciowych. Takie podejście ogranicza ryzyko, że przeciążenia, awarie lub incydenty w sieci korporacyjnej przełożą się na łączność i dostępność systemów OT obsługujących procesy krytyczne. Styk z siecią ogólną zrealizowano we współpracy z Zakładem Informatyki i Telekomunikacji (ZIT), trzymając się twardej zasady: brak bezpośredniego routingu do urządzeń wykonawczych. Użytkownik biurowy nie ma fizycznego dostępu do sterowników – firewall przepuszcza wyłącznie szyfrowany ruch do serwera PERUN. Nad zgodnością tych rozwiązań z wymogami KSC czuwa Dział Bezpieczeństwa Centrali PGG, co zapewnia spójność ze standardami całej Grupy. Kluczowy jest jednak model utrzymania, który pozwala uniknąć typowych opóźnień serwisowych. Podział kompetencji jest jasny: centralne IT (ZIT) odpowiada za szczelność styku sieciowego, natomiast lokalny zespół ma pełną kontrolę nad kodem źródłowym i logiką systemu. Dzięki temu, gdy automatyk na obiekcie wykryje problem, architekt systemu może wdrożyć poprawkę niemal natychmiast, bez konieczności zgłaszania zlecenia do zewnętrznego dostawcy, czy czekania na wsparcie serwisu. To daje krótszy czas reakcji i mniejszą zależność operacyjną od zewnętrznego serwisu, niezbędną przy utrzymaniu ruchu.
Rys. 3. Mechanizm zapewnienia integralności danych: od akwizycji przez kanonizację i podpis HMAC-SHA256, po weryfikację w środowisku PERUN
Otwarte technologie w praktyce środowiska PERUN
Środowisko PERUN zbudowaliśmy jako aplikację webową, w której panele operatorskie bazują na wektorowych wizualizacjach 2D/3D odzwierciedlających strukturę rozdzielni, pól i ścieżek zasilania, czy innego obiektu. Dane pomiarowe są gromadzone w bazie szeregów czasowych (InfluxDB) i udostępniane poprzez warstwę reverse proxy (NGINX).
W architekturze wykorzystano otwarty stos narzędziowy do wytwarzania i utrzymania (m.in. OpenJDK, Eclipse/VS Code) oraz komponenty bezpieczeństwa do monitorowania integralności danych i zdarzeń systemowych (np. Wazuh). Równolegle stosowane są autorskie moduły bezpieczeństwa fizycznego i środowiskowego, w tym kontrola dostępu. Informacje z obu warstw prezentowane są łącznie ze stanami zasilania, co pozwala w jednym miejscu analizować zdarzenia energetyczne oraz wiarygodność i kontekst danych. W realiach infrastruktury krytycznej dobór komponentów open source zwiększa kontrolę nad rozwiązaniem i ogranicza zależność od pojedynczego dostawcy (vendor lock-in), ułatwiając stopniowy rozwój funkcjonalności. Przejrzysta architektura i wersjonowanie zmian (kod oraz konfiguracje) upraszczają wyjaśnianie pochodzenia wskaźników i raportów oraz ułatwiają audyt. Ryzyko koncentracji wiedzy (bus factor) ograniczono przez standaryzację formatów danych, spójne konwencje implementacyjne, dokumentowanie kluczowych decyzji oraz procedury wdrożeniowe i odtworzeniowe. Przy niewielkim zespole wykorzystujemy narzędzia AI do wsparcia prac deweloperskich, przy zachowaniu weryfikacji przez człowieka. Doświadczenia z KWK Ruda wskazują, że taki model pozwala traktować rozwiązanie jako stały element docelowej architektury OT.
Wnioski – co z tego wynika dla innych
Choć rozwiązanie powstało dla kopalni, model monitorowania ciągłości można przenieść do innych sektorów infrastruktury krytycznej. W KWK Ruda pokazaliśmy, że ciągłość dostaw da się mierzyć i dokumentować – niezależnie od tego, czy chodzi o prąd, wodę, czy gaz. Punkt wyjścia jest zawsze ten sam: inwentaryzacja ścieżek zasilania i identyfikacja odbiorów krytycznych. Dopiero potem warto budować monitoring oparty na wskaźnikach, które pozwalają odtwarzać przebieg zdarzeń, a nie tylko generować alarmy. Model musi uwzględniać integralność danych, a technologię dobierać proporcjonalnie do ryzyka.
W warstwach krytycznych stawiamy na niezależność: audytowalność, on-prem i ograniczenie vendor lock-in. Kluczowe są też lokalne kompetencje i zespoły utrzymania.
Projekt PERUN rozwija zespół Działu Energomechanicznego KWK Ruda we współpracy z ZIT oraz Biurem Bezpieczeństwa PGG.
Literatura
1. Ustawa o krajowym systemie cyberbezpieczeństwa (KSC), 5.07.2018.
2. Dyrektywa (UE) 2022/2555 (NIS2), 14.12.2022.
3. IEC 60947-6-1:2021 – transfer switching equipment.
4. MITRE ATT&CK® – baza taktyk i technik ataku.
Źródło: Mariusz Szyguła, Główny Specjalista ds. Systemów Dyspozytorskich, Polska Grupa Górnicza S.A., Karol Góra, Nadsztygar Elektryczny ds. Teletechniki i Automatyki oraz Gazometrii, Polska Grupa Górnicza S.A.
Artykuł pochodzi z wydania 1/2026 magazynu ,,Nowa Energia”
