Kopia zapasowa projektu WebHMI służy do przechowywaniu struktury aplikacji SCADA utworzonej na WebHMI. Jest to jej podstawowe zadanie, ale prawdziwe możliwości się otwierają w momencie gdy się nauczymy ją przeglądać oraz edytować.
Struktura kopii zapasowej
Kopia zapasowa jest archiwum TAR i można ją otworzyć za pomocą darmowego oprogramowania 7-zip. Po otwarciu zobaczymy następujące pliki i foldery
- Folder „images” – Przechowuje grafiki załadowane do projektu. Struktura folderu odpowiada strukturze biblioteki obrazów.
- Folder „tmp” – Zawiera pliki wsadowe do załadowania bazy danych, w oparciu o którą działa aplikacja SCADA. Jest to serce kopii zapasowej, któremu przyjrzymy się bliżej w dalszej części artykułu.
- Pliki zawierające grafiki z logiem.
- Plik TAR zawierający cztery ostatnie cyfry numeru wersji firmware w jakiej został wykonany projekt.
W środku znajdziemy trzy pliki:
- ”db.sql” – Plik przechowujący strukturę aplikacji SCADA.
- „storage.sql” – Plik przechowujący wartości zapisane w rejestrach w momencie utworzenia kopii zapasowej.
- „version” – Pierwszorzędny i drugorzędny numer wersji firmware, w której została utworzona kopia zapasowa.
Do przeglądania i edycji plików polecamy darmowe narzędzie Notepad++ wraz z wtyczką JSON Viewer.
Jak analizować pliki kopii zapasowej?
W plikach znajduje się zbiór zapytań INSERT w języku SQL. Wszystkie występują w wersji:
|
1 |
INSERT INTO table (column1 [, column2, column3 ... ]) VALUES (value1 [, value2, value3 ... ]) |
Dzięki temu, że w zapytaniu są wprost wskazane nazwy kolumn w tabelach, będzie łatwo rozczytać która wartość gdzie będzie wpisana.
Kopiując dany wiersz do Excela (lub innego arkusza kalkulacyjnego) po rozdzieleniu tekstu po przecinkach oraz transpozycji (przekształceniu kolumn w wiersze) nie powinniśmy mieć problemu z rozszyfrowaniem znaczenia poszczególnych pól zapytania.
Typy danych
W pliku znajdziemy typy danych zgodne z specyfiką języka SQL. Będą to (w dużym uproszczeniu):
- liczby,
- ciągi znaków.
Warto zwrócić uwagę, że jako ciągi znaków spotkamy też ciągi w formacie JSON. Używając oprogramowania Notepad++ wraz z wspomnianą wcześniej wtyczką JSON Viewer można je wygodnie analizować i edytować.
Edycja i zapis zmian
Kopię zapasową można modyfikować bez potrzeby rozpakowywania archiwum. Wystarczy w tym celu otworzyć w 7-zip plik archiwum i kliknąć dwukrotnie LPM na plik, który chcemy edytować. Po edycji i zamknięciu użytego edytora (np. wspomnianego Notepad++) 7-zip zapyta się czy zaktualizować archiwum.
Całą odpowiedzialność za takie operacje ponosi twórca aplikacji na WebHMI, dlatego zalecamy daleko posuniętą ostrożność – są to metody przeznaczone dla doświadczonych i świadomych użytkowników.
Praktyczne zastosowania możliwości edycji kopii zapasowej
W tym akapicie przedstawimy nasze sposoby na błyskawiczną edycję projektu modyfikując plik archiwum kopii zapasowej.
Masowe dodawanie alarmów i innych elementów aplikacji
Pierwszym zastosowaniem możliwości ręcznej edycji pliku kopii zapasowej jest masowe dodawanie elementów aplikacji SCADA. Poniżej rozważamy sytuację gdy chcemy dodać masowo alarmy, ale w analogiczny sposób można też dodawać wydarzenia, zadania kalendarza itd.
Rozważymy sytuację, w której WebHMI ma odpowiadać za monitorowanie stanu 30 identycznych maszyn. Dla każdej maszyny jest zdefiniowanych 15 warunków alarmowych, które mają być sygnalizowane w naszym systemie.
Daje nam to w sumie 450 alarmów. Można je oczywiście dodać ręcznie, jednak samo klikanie w tym przypadku zajmie przynajmniej kilka godzin, zakładając oczywiście że alarmy nie są rozbudowane (a w WebHMI mamy dużo możliwości żeby je rozbudować) i na jeden poświęcimy optymistycznie 45 sekund. Do tego dołóżmy ryzyko błędów oraz frustrację kiedy któryś będzie trzeba zmodyfikować. Można to zrobić lepiej i szybciej.
Pierwszym krokiem będzie zapoznanie się ze strukturą zapytania INSERT, które dodaje alarm do aplikacji podczas wgrywania kopii zapasowej. Po zastosowaniu metody pokazanej w akapicie „Jak analizować pliki kopii zapasowej?” otrzymamy następującą tabelę:
W naszym przypadku będziemy edytowali tytuł alarmu, opis, warunek wystąpienia oraz kategorię (założyliśmy, że alarmy będą pogrupowane w kategorie odpowiadające maszynom). Należy zwrócić uwagę, że warunek wystąpienia alarmu jest zapisany w formacie JSON, dlatego też w tym wypadku podczas wstawiania tekstu kreator importu w Excel’u z powodu wybrania przecinka jako znaku do rozdzielenia kolumn rozdzielił także elementy struktury warunku.
Poniżej utworzony w ten sposób fragment arkusza Excela (obraz został zmniejszony ze względu na zbyt duży rozmiar):
Przeanalizujmy krok po kroku co zostało tutaj zrobione.
W pierwszych kolumnach (1) zamieściłem tytuły kolumn z zapytania INSERT, które mogliśmy wyczytać w poprzednim kroku. W każdej z komórek tych kolumn znajdują się formuły, które składają w całość tekst danego pola – przyjrzymy się im za chwilę. W następnej kolumnie (2) znajduje się formuła łącząca teksty wcześniejszych komórek w kompletne zapytanie INSERT, które będziemy mogli wkleić do pliku „db.sql” w pliku archiwum kopii zapasowej. W kolejnych kolumnach, które nie są pokazane, znajdują się komórki, z których będą składane teksty w powyższych kolumnach.
W kolumnie „id” (1) znajdują się numery ID alarmów, po których są rozróżniane wszystkie obiekty w strukturze projektu WebHMI. Istotne jest żeby każdy alarm miał swój niepowtarzalny numer.
Kolumny „title” oraz „category” (2) zawierające nazwę alarmu oraz kategorię powstały w wyniku prostych formuł (4) łączących teksty z kolumnami zawierającymi teksty cząstkowe.
Kolumny „level”, „sound”, „canack”, „dict_id” oraz group_id” (3) wypełniam albo tymi samymi znakami wpisanymi na sztywno, albo zostawiam pustę – w przypadku tych właściwości nie będzie różnicy pomiędzy poszczególnymi alarmami.
Kolumna „description” (1) zawierająca opis alarmu, który zobaczy operator w oknie alarmów. Warto tutaj zwrócić uwagę, że poza samym tekstem pole to zawiera też w sobie formatowanie na podstawie znaczników HTML (2), które w przypadku alarmów WebHMI jest dość rozbudowane. Możemy je podejrzeć w edytorze alarmu w zakładce „Informacja” (3) po kliknięciu na przycisk „Kod źródłowy” (4). Warto na to zwrócić uwagę, ponieważ w przypadku bardziej rozbudowanych opisów alarmów czy też np. raportów ilość tych znaczników będzie proporcjonalnie większa.
Ostatnia kolumna – i najciekawsza – to warunek alarmu. W nim w formacie JSON zakodowany jest warunek wywołania alarmu (1). Przyjrzyjmy się najpierw prostszemu warunkowi, czyli uzależnionemu od jednej zmiennej. W przypadku tego pola powstała dość rozbudowana formuła (2) łącząca na sztywno teksty, które nie ulegają zmianie oraz te, które ulegają, jak typ warunku (wartość rejestru mniejsza niż …, większa niż … itd.), ID rejestru, którego wartość będzie porównywana z wartością progową (w tym przykładzie minimalna).
Dla porównania do jednego z alarmów przypisaliśmy trochę bardzie rozbudowany warunek, uzależniony od dwóch zmiennych. Jak widać, w zapytaniu jest on potraktowany jako dwa osobne elementy w tablicy JSON.
Po skopiowaniu do Notepad++, zapisaniu oraz wgraniu kopii zapasowej do WebHMI utworzonych zostało 100 alarmów przypisanych do 10 maszyn:
Zmiana poziomu uprawnień do elementów
Podczas tworzenia aplikacji może się okazać, że należy dodać nową rolę użytkownika, czyli grupę uprawnień do czego będzie miał dostęp użytkownik. Na późnym etapie realizacji może być to o tyle kłopotliwe, że domyślnie po utworzeniu nowej roli wszystkie elementy wizualizacji takie jak ekrany, pulpity czy same elementy pulpitów nie zmieniają przypisanych ról, które mają do nich dostęp. W takim wypadku może to oznaczać że należy przeklikać czasem setki (lub nawet tysiące) elementów i w każdym zmieniać przypisane role. Można to też zrobić szybciej, edytując plik kopii zapasowej.
Elementy, do których można przypisać role, można podzielić na dwie grupy:
- Elementy SCADA dostępne z poziomu ustawień takie jak pulpity, ekrany, receptury, wydarzenia, wykresy itd. W ich przypadku należy w pliku szukać kolumn „allowed_for_roles” (1) oraz odpowiadającym im wartości w formie ciągu znaków zawierającego numery ID ról (2).
- Elementy sterujące pulpitów. Role, które są do nich przypisane można odnaleźć w opisujących strukturę pulpitów ciągach znaków w formacie JSON. Znajdują się one jako elementy „permission”.
Mając te informację możemy w Notepad++ wyszukać te teksty za pomocą opcji „Szukaj” i wyedytować wszystkie miejsca, gdzie są opisane role przypisane do danego obiektu.
Edycja pulpitów
Analogicznie do powyższych przykładów możemy w ten sam sposób masowo edytować i dodawać pulpity. W tym celu polecamy się zapoznać z naszym artykułem na temat struktury kopii zapasowej pulpitu.
Podsumowanie
Edycja plików znajdujących się w kopii zapasowej projektu to dla doświadczonych użytkowników niezwykle potężne narzędzie, które pozwala nie tylko na lepsze zrozumienie działania WebHMI, ale także na błyskawiczne wprowadzanie zmian czy dodawanie elementów.
Największą wartość dodaną może to wnieść dla producentów maszyn oraz systemów, którzy dzięki temu mogą napisać własne skrypty czy makra generujące aplikację na WebHMI na podstawie zadanych parametrów.