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
- Używaj funkcji odczytu grupowego.
- 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.
- W przypadku niestabilnych połączeń użyj opcji „Wyłącz odczyt przy pojawieniu się błędów”.
- Organizuj i ustaw różne interwały odczytu dla zmiennych.Przykładowo:
- Pomiary wolnozmienne takie jak np. temperatura zewnętrzna odczytuj np. co 1 minutę.
- Nastawy PID, parametry o charakterze konfiguracyjnym, kalendarze i harmonogramy skonfiguruj jako czytane na żądanie.
- 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.
- 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ń.
- Używaj komunikacji zdarzeniowej.
- 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
- Zachowaj liczbę rejestrów w projekcie poniżej 2-3K.
- 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
- 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.
- Używaj pulpitów jako widżety na ekranach w celu wykonania tego, czego nie można zrobić używając ekranów.
- 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!
- 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.
- Używaj szablonów pulpitów.
Skrypty Lua
- 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!
- 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”.
- 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”.
- 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.
- 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.
- 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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
function UpdReg(reg,new_value) local cur_value = R(reg) if (not cur_value) or (cur_value == new_value) then return else WriteReg(reg, new_value) end end |
Edycja projektu
- 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.
- 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).
- 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
- Ś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
- Zminimalizuj ilość zmiennych zapisywanych do logów.
- Ustaw dla rejestrów zapisywanych do logów odpowiednią częstotliwość zapisu za pomocą parametrów „Tolerancja”, „Minimalny interwał zapisu” i „Maksymalny interwał zapisu”.
- 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
- 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.
- 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
- 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ć”.
- 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.
- 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.