Optymalizacja wydajności

Według zamysłu twórców WebHMI miał być dedykowany do małych aplikacji, ale z czasem klienci zaczęli je stosowali także do coraz większych projektów. Z drugiej strony stale rośnie funkcjonalność części front-endowej, która także pochłania zasoby sprzętowe. W związku z tym jeśli zamierzasz użyć WebHMI w projekcie z tysiącami tagów, to powinieneś pamiętać o ograniczonych zasobach platformy sprzętowej, które posiadasz. Poniżej znajdziesz kilka wskazówek, które musisz wziąć pod uwagę, aby aplikacja była szybka i responsywna, a WebHMI spełniło swoje zadanie.

Chcąc lepiej zrozumieć uzasadnienie poszczególnych wskazówek i wytycznych polecamy zapoznanie się z artykułem na temat cyklu pracy WebHMI.

 

Połączenia

  1. Używaj funkcji odczytu grupowego.
  2. Ustaw odpowiedni limit czasu (Timeout) i liczbę błędów do pominięcia skanowania połączenia w połączeniach zewnętrznych. Przykładowo jeśli urządzenie przeciętnie odpowiada w ciągu 30 ms, to ustaw Timeout na ok. 40 ms. Jeśli zostanie utracona komunikacja z urządzenie, które ma większy limit czasu ustawiony na 100 ms, to każde skanowanie zajmie dodatkowe 60 ms przy próbach odczytu.
  3. W przypadku niestabilnych połączeń użyj opcji „Wyłącz odczyt przy pojawieniu się błędów”.
  4. Organizuj i ustaw różne interwały odczytu dla zmiennych.Przykładowo:
    1. Pomiary wolnozmienne takie jak np. temperatura zewnętrzna odczytuj np. co 1 minutę.
    2. Nastawy PID, parametry o charakterze konfiguracyjnym, kalendarze i harmonogramy skonfiguruj jako czytane na żądanie.
    3. Parametry szybkozmienne takie jak np. ciśnienie w zbiorniku odczytuj co 200 ms, 500 ms lub 1 s, w zależności od pojemności zbiornika i dynamiki procesu.
  5. Dla licznych urządzeń zewnętrznych posiadających dużo parametrów, które tak naprawdę nie muszą być odczytywane na bieżąco, używaj metody multipleksowania połączeń.
  6. Używaj komunikacji zdarzeniowej.
  7. Jeśli w topologii Twojej sieci przemysłowej znajduje się dużo urządzeń, rozważ czy jedno z nich (np. sterownik PLC) nie może posłużyć jako koncentrator danych dla WebHMI. W ten sposób WebHMI nie będzie obciążone nawiązywaniem połączenia z X urządzeń tylko z jednym, a także będzie sprawniej się komunikowało dzięki możliwości upakowania w pojedynczej ramce komunikacyjnej większej ilości informacji.

Rejestry

  1. Zachowaj liczbę rejestrów w projekcie poniżej 2-3K.
  2. Uporządkuj swoje drzewo rejestrów według kategorii. Każdy rejestr w projekcie ma wiele powiązanych z nim danych konfiguracyjnych, co wiąże się z tym że im większe drzewo rejestrów, tym większe obciążenie systemu podczas pracy na nim.

Wizualizacja

  1. Używaj ekranów opartych na technologii widżetów do wizualizacji wszędzie tam gdzie jest to możliwe, nie buduj swojej aplikacji w oparciu o tradycyjne pulpity. WebHMI jest zdecydowanie lepiej zoptymalizowane do pracy z ekranami niż z pulpitami.
  2. Używaj pulpitów jako widżety na ekranach w celu wykonania tego, czego nie można zrobić używając ekranów.
  3. Unikaj używania pulpitów o dużych rozmiarach – zbyt bogatych w elementy, z dużymi obrazami itp. Pulpit powinien mieć rozmiar rzędu kilkudziesięciu kB, a nie kilku MB. Możesz sprawdzić rozmiar pulpitu eksportując go do zewnętrznego pliku.
    Używanie zbyt dużych pulpitów niezgodnie z zaleceniami producenta może prowadzić nie tylko do spowolnienia działania projektu, ale także do braku możliwości uruchomienia aplikacji po przywróceniu kopii zapasowej! 
  4. Ustaw odpowiedni czas odświeżania ekranu. Zwykle nie jest potrzeby krótszy niż 1 sekunda, dla wizualizacji które nie wymagają częstych działań operatorów systemu SCADA z wolnozmiennymi pomiarami dłuższe czasy też będą wystarczające.
  5. Używaj szablonów pulpitów.

Skrypty Lua

  1. Unikaj używania dużej ilości niewielkich skryptów – nie powinno być ich więcej niż kilka-kilkanaście. Lepszym sposobem jest użycie kilku dużych skryptów oraz skryptów używających bibliotek zamiast wielu małych skryptów, ponieważ każde wywołanie skryptu wymaga pewnych zasobów środowiska operacyjnego.
    Używanie zbyt wielu skryptów niezgodnie z zaleceniami producenta może prowadzić nie tylko do spowolnienia działania projektu, ale także do kompletnego zatrzymania aplikacji bez możliwości jej edycji!
  2. Zminimalizuj liczbę skryptów, funkcji i instrukcji uruchamianych w każdym cyklu. Lepszą metodą jest ich wywoływanie w reakcji na zadany warunek przy pomocy instrukcji warunkowych „if”.
  3. Zminimalizuj ilość skryptów wywoływanych przy zmianie wartości rejestru. Lepiej jest je zgrupować w dużym skrypcie monitorując zmianę wartości rejestru i wywołując stosowne instrukcje odpowiednich warunkach instrukcji „if…elseif”.
  4. Zminimalizuj ilość skryptów pulpitu. Zamiast tego do elementów sterujących pulpitów przypisz funkcję zapisu wartości do rejestru, a w dużym skrypcie wykonuj stosowne działania w zależności od wartości tego rejestru.
  5. W przypadku dużych pętli rozważ czy muszą być wykonywane w każdym cyklu, a nie cyklicznie np. co 10 sekund albo co minutę. Inna opcja – czy muszą być wykonywane w całości w jednym cyklu i nie da się ich podzielić tak, żeby zadanie się wykonywało przez kilku kolejnych cykli. Przykładowo chcemy generować informację o średnim czasie cyklu pracy maszyn z ostatnich 1000 cykli, a takich maszyn mamy 10. Wykonanie tego w jednym cyklu może się okazać zbyt obciążające, ale można podzielić je np. tak, że w każdym cyklu jest aktualizowana średnia tylko dla jednej z maszyn albo średnie aktualizowały się na zasadzie bufora cyklicznego.
  6. Zminimalizuj ilość użycia instrukcji „WriteReg” podczas każdego skanowania. Instrukcje „WriteRegs” każdorazowo są umieszczane w kolejce zapisu podczas wykonywania pętli głównej WebHMI, co w nieprzemyślanej pętli lub przy użyciu 100 instrukcji „WriteReg” do aktualizacji rejestrów powoduje utworzenie kolejki zapisu dla 100 tagów w każdym skanie (pamiętajcie, że każdy rejestr w rzeczywistości oznacza strukturę dużych zbiorów danych). Lepiej jest użyć funkcji opakowującej „UpdReg ()” w następujący sposób:

Edycja projektu

  1. Zachowaj minimalną liczbę otwartych kart w przeglądarce w bieżącej sesji. Jeśli potrzebujesz wielu kart, użyj pola wyboru automatycznego zamykania sesji, aby zapobiec nienadzorowanemu dostępowi.
  2. Unikaj wprowadzania wielu zmian jedna po drugiej, takich jak wyłączanie i włączanie rejestrów, połączeń, skryptów, dodawanie i edycja pulpitów itp. Użyj funkcji „Zapisz + aplikuj” z wersji firmware 4.0.7307 i nowszych, która powoduje zastosowanie wszystkie zmiany naraz zamiast tworzenia kolejkę zmian).
  3. Zachowaj ostrożność podczas edycji aplikacji na działającym obiekcie. Każda edycja powoduje chwilowe zwiększenie obciążenia systemu operacyjnego.

Obciążenie systemu operacyjnego

  1. Śledź parametry średniego obciążenia systemu operacyjnego podczas rozbudowy i działania aplikacji. W liście rejestrów wewnętrznych można odnaleźć rejestry pokazujące średnią liczbę procesów oczekujących w kolejce w stosunku do liczby uruchomionych procesów. W WebHMI są dostępne średnie z 1, 5 oraz 15 minut. W stanie ustalonym metryka 15 minut powinna być poniżej 1. Więcej o tym jak interpretować te parametry można przeczytać np. tutaj.

Logi

  1. Zminimalizuj ilość zmiennych zapisywanych do logów.
  2. Ustaw dla rejestrów zapisywanych do logów odpowiednią częstotliwość zapisu za pomocą parametrów „Tolerancja”, „Minimalny interwał zapisu” i „Maksymalny interwał zapisu”.
  3. Ustawiając opcję „Użyj danych z dziennika” dla wykresów, upewnij się, że ograniczasz ilość danych zapisywanych do logu za pomocą ustawień opisanych w poprzednim punkcie.

Wykresy i trendy

  1. Trendów używaj tylko do wykreślania przebiegów o oknie czasowym do 2-3 minut. Każdy trend powoduje przesyłanie całości danych, tj. każdego pojedynczego punktu, pomiędzy częścią back-end i front-end aplikacji, które dla dłuższych przedziałów czasowych mogą stanowić zbyt duże obciążenie dla procesora.
  2. Dla dłuższych przebiegów stosuj wykresy, które wyświetlają dane będące średnią arytmetyczną wartości rejestru dla kolejnych odcinków czasu (linia ciągła wykresu) oraz wartościami minimalnymi i maksymalnymi dla nich (przeźroczyste tło).

Duże i wymagające projekty

  1. Pamiętaj, że WebHMI co do zasady nie jest system czasu rzeczywistego i zgodnie z informacją na stronie producenta jest raczej dedykowany do małych instalacji/maszyn o niekrytycznym znaczeniu dla bezpieczeństwa procesowego oraz w charakterze systemu do monitorowania i nadzoru niż bieżącego sterowania. WebHMI nie gwarantuje czasu odpowiedzi ani wykonania zadania oraz ma prawo „się zawiesić”.
  2. W przypadku większych systemów należy rozważyć użycie większej ilości WebHMI oraz ich wzajemną komunikację i powiązanie poprzez wzajemne linkowanie w adresach URL przypisanych do przycisków czy menu kontekstowego.
  3. Rozważ, czy część zadań o charakterze obliczeniowym czy innym obciążającym zasoby WebHMI (np. wyznaczanie statusów i zdarzeń na podstawie rozbudowanych warunków logicznych, linearyzacja, obsługa kalendarza/harmonogramu) nie może zostać wykonane na innym urządzeniu, np. sterowniku PLC.
Wróć na początek