Załamanie wydajności SCADA podczas zmiany zmiany: diagnozowanie jednoczesnego skoku obciążenia na GE HMI i Honeywell Experion

Alarm Management, DCS, GE Proficy iFIX, HMI Performance, Honeywell Experion PKS, Industrial Automation, Root Cause Analysis, SCADA, Shift Change
kwiecień 13, 2026

SCADA Performance Collapse at Shift Change: Diagnosing the Concurrent Load Spike on GE HMI and Honeywell Experion

Objaw: SCADA Zawiesza Się Tylko Podczas Zmiany Zmiany

Operatorzy zgłaszają, że system SCADA staje się nieodpowiadający podczas zmiany zmiany. Strony z grafikami ładują się powoli. Potwierdzenia alarmów zajmują 5–10 sekund. Wartości tagów chwilowo zamrażają się na wykresach trendów. Sterownik PLC działa normalnie. Przyrządy polowe pokazują poprawne wartości. Zawieszenie ustępuje samoistnie po 15–20 minutach.

Ten wzorzec wskazuje na skok obciążenia po stronie serwera, a nie na problem z komunikacją w polu. Systemy GE HMI Proficy iFIX oraz Honeywell Experion PKS doświadczają tego problemu, gdy wiele zdarzeń nakłada się na granicy zmiany. Zrozumienie każdego zdarzenia pomaga wyizolować dominującą przyczynę.

Przyczyna 1: Równoczesny Restart Stanowiska Roboczego i Ponowne Subskrybowanie Tagów

Podczas zmiany zmiany operator wychodzący zamyka aplikację SCADA. Operator wchodzący uruchamia ją na nowo. W GE HMI Proficy iFIX każdy restart stanowiska roboczego powoduje pełne pobranie subskrypcji tagów z serwera SCADA. Jeśli 8 stanowisk restartuje się w ciągu 2 minut, serwer przetwarza 8 równoczesnych żądań subskrypcji.

Każda subskrypcja obejmuje zapytanie do bazy danych, wyszukiwanie tagów oraz konfigurację przesyłania danych w czasie rzeczywistym. Usługa GE Proficy Cim-Manager obsługuje te żądania. Przy dużym obciążeniu głębokość kolejki przekracza limit bufora. Nowe żądania subskrypcji czekają w kolejce. Opóźnienie objawia się jako wolne ładowanie grafik po stronie klienta.

Środki zaradcze: Skonfiguruj stanowiska robocze tak, aby używały wznowienia aplikacji zamiast pełnego restartu. W Proficy iFIX ustaw opcję Auto-Resume w właściwościach przestrzeni roboczej iFIX. To pozwala ponownie wykorzystać istniejące subskrypcje tagów zamiast budować je od nowa. Czas uruchomienia spada z 45 sekund do poniżej 10 sekund.

Przyczyna 2: Wybuch Potwierdzeń Alarmów i Burza Zapisów w Bazie Danych

Podczas przekazania zmiany operator wychodzący potwierdza nagromadzone alarmy. Typowa zmiana generuje 200–400 zdarzeń alarmowych. Jeśli 80% pozostaje niepotwierdzonych, operator wchodzący potwierdza je zbiorczo. Każde potwierdzenie generuje transakcję w bazie danych, rejestrującą nazwę operatora, znacznik czasu, ID alarmu i komentarz.

W Honeywell Experion PKS zdarzenia alarmowe zapisują się w Bazie Alarmów (ADB). Każdy zapis wymaga aktualizacji indeksu. Przy obciążeniu wybuchowym kolejka aktualizacji indeksu rośnie szybciej niż dysk I/O może ją obsłużyć. Serwer Alarmów Experion reaguje zwiększonym opóźnieniem. Okienka alarmów pojawiają się z opóźnieniem 3–5 sekund. Nasze moduły kart kontrolerów Honeywell oraz komponenty systemu C300 są zaprojektowane tak, aby utrzymać stabilność w tych warunkach obciążenia.

W GE Proficy iFIX potwierdzenia alarmów zapisują się do bazy historycznej przez SCU (System Configuration Utility). Jeśli historian działa na tym samym serwerze, konkurencja o dysk I/O pogarsza sytuację. Proficy Process Historian może w tym czasie utracić dane.

Środki zaradcze: Włącz odkładanie alarmów o niskim priorytecie przed końcem zmiany. W Experion PKS skonfiguruj funkcję odkładania alarmów w zakładce Konfiguracja Alarmów. Odkładaj do 50% niepotwierdzonych alarmów niskiego priorytetu. To zmniejsza wybuch potwierdzeń eliminując zdarzenia niekrytyczne.

Przyczyna 3: Automatyczne Generowanie Raportów Zmianowych i Przeciążenie Zapytaniami

Obie platformy SCADA, GE i Honeywell, obsługują automatyczne generowanie raportów o zaplanowanych porach. Typowe raporty zmianowe obejmują sumy produkcji, podsumowania przestojów, statystyki alarmów i zużycie energii. Raporty te wykonują zapytania do bazy historycznej dla tysięcy punktów danych.

Jeśli silnik generowania raportów działa na serwerze SCADA, konkuruje o zasoby CPU i dysku z operacjami w czasie rzeczywistym. Typowe zapytanie raportu zmiany w GE Proficy Process Historian trwa 8–12 sekund. W tym czasie serwer SCADA ma ograniczoną zdolność do aktualizacji tagów i przetwarzania alarmów.

W Honeywell Experion PKS stanowisko raportowe generuje raporty przez Experion Reports Server. Jeśli stanowisko raportowe działa na tym samym serwerze co Experion Application Server, obciążenie zapytań pogarsza wydajność w czasie rzeczywistym. Monitor stanu serwera pokazuje skoki użycia CPU do 85–95% podczas generowania raportów.

Środki zaradcze: Zaplanuj raporty zmianowe na 10 minut po zmianie, a nie dokładnie w czasie przekazania. To oddziela zapytania raportowe od wybuchu potwierdzeń alarmów. Zweryfikuj harmonogram w Experion Report Designer lub w harmonogramie raportów Proficy Process Historian.

Procedura Diagnostyczna Krok po Kroku

Gdy wystąpi zawieszenie, natychmiast zbierz dane diagnostyczne. Nie czekaj do następnej zmiany.

Krok 1: Otwórz Menedżera Zadań Windows na serwerze SCADA. Zapisz użycie CPU, pamięci oraz długość kolejki dysku. Określ, czy wąskim gardłem jest CPU, RAM czy dysk I/O.
Krok 2: Sprawdź Podgląd Zdarzeń Windows pod kątem błędów zapisu do bazy danych lub przekroczeń czasu usług. Szukaj ID zdarzenia 833 (przekroczona latencja bazy) w logach Experion lub ID 4096 w logach Proficy iFIX.
Krok 3: Przejrzyj liczbę subskrypcji tagów SCADA. W Experion PKS użyj Station Manager do wyświetlenia statystyk aktywnych subskrypcji. W GE Proficy iFIX sprawdź głębokość kolejki Cim-Manager na ekranie diagnostyki systemu.
Krok 4: Zbadaj dziennik alarmów pod kątem wzorca wybuchu. Policz liczbę potwierdzeń alarmów w 5-minutowym oknie wokół zmiany. Jeśli liczba przekracza 50 na minutę, burza zapisów w bazie jest dominującą przyczyną.
Krok 5: Sprawdź harmonogram generowania raportów. Poszukaj raportów zaplanowanych na czas zmiany. Przesuń czas rozpoczęcia o 10–15 minut, aby zmniejszyć nakładanie się obciążeń.

Wnioski i Zalecenia

Załamanie wydajności SCADA podczas zmiany wynika z trzech równoczesnych zdarzeń. Po pierwsze, stanowiska robocze restartują się i jednocześnie ponownie subskrybują wszystkie tagi. Po drugie, operatorzy potwierdzają alarmy zbiorczo, generując burzę zapisów w bazie danych. Po trzecie, automatyczne raporty zmianowe wykonują zapytania do bazy historycznej w szczytowym czasie obciążenia.

W GE HMI Proficy iFIX włącz Auto-Resume, aby wyeliminować pełne odbudowywanie subskrypcji. W Honeywell Experion PKS włącz odkładanie alarmów i przeplanuj raporty na 10 minut po zmianie. Obie platformy zyskują na przeniesieniu bazy historycznej na dedykowany serwer. To oddziela przetwarzanie tagów w czasie rzeczywistym od obciążeń zapytań raportowych. Niezawodne moduły I/O Honeywell zapewniają integralność danych polowych nawet podczas skoków obciążenia po stronie serwera.

Udokumentuj wyniki diagnostyki w CMMS zakładu. Stwórz procedurę wydajności zmiany, która rozłoży trzy zdarzenia obciążeniowe na 30-minutowe okno. Monitoruj wyniki przez dwa tygodnie. Jeśli użycie CPU nadal przekracza 80% podczas zmiany, rozważ modernizację serwera SCADA lub dodanie drugiego serwera do rozłożenia obciążenia.