Alarmy i powiadomienia w systemie SCADA od ICONICS - poradnik konfiguracji cz. 1

Alarmy to jeden z podstawowych elementów w systemach SCADA. Właściwe alarmowanie oraz generowanie powiadomień o usterkach stoi u podstaw bezawaryjnego działania zakładów produkcyjnych. Co więcej, szybkie zawiadomienie o usterce pozwala często skrócić czas przestoju niezbędny do jej usunięcia. ICONICS dostarcza rozwiązań z zakresu zarówno monitorowania sygnałów pod względem awarii, jak i wizualizacji cennych danych alarmowych.

Z systemem ICONICS:

• ustawisz 6 rodzajów alarmów zgodnych ze standardem ISA 18.2,
• nadasz priorytety alarmom i uporządkujesz je w logicznej hierarchii,
• zarchiwizujesz alarmy do baz relacyjnych SQL,
• zwizualizujesz alarmy archiwalne i czasu rzeczywistego - również na urządzeniach mobilnych,
• wyślesz powiadomienia e-mail lub SMS o dowolnej zmiennej treści do wskazanych użytkowników,
• zintegrujesz system SCADA z zewnętrznymi platformami komunikacyjnymi (np. Twilio),
• zbudujesz aplikację zgodną z normą FDA 21CFR11.

 

---

 

Wstęp - projektowanie efektywnego systemu zarządzania alarmami

Praktyczne wskazówki jak zaprojektować system zarządzania alarmami – zgodnie z wytycznymi standardu ISA 18.2 – „Sygnały z przyrządów i alarmy”

Aby wdrożyć i utrzymywać efektywny system zarządzania alarmami, użytkownicy końcowi muszą już w fazie projektowania rozumieć wymagania, jakie stawia się tego typu rozwiązaniom, oraz zdawać sobie sprawę z użytecznych funkcji, które one oferują. W artykule zaprezentowano sześć wskazówek ułatwiających efektywne zarządzanie alarmami.

W zautomatyzowanym środowisku sterowania procesami – takimi jak produkcja lub utrzymanie ruchu w fabryce – zarządzanie alarmami staje się koniecznością. Chociaż monitorowane procesy mają nieco inny przebieg w poszczególnych zakładach, to jednak da się wyodrębnić wśród nich pewne cechy wspólne. Osoba zainteresowana implementacją i posiadaniem systemu zarządzania alarmami zaczyna od stworzenia głównej idei przyświecającej jego działaniu. Idee te są często kreowane na podstawie wewnętrznych rozwiązań, specyficznych dla danej firmy. Bardziej kompleksowe sposoby zarządzania alarmami, nawet spełniające wymagania norm przemysłowych, takich jak ISA 18.2 – „Sygnały z przyrządów i alarmy” („Instrument Signals and Alarms”), wymagają dodatkowego nakładu pracy i zaangażowania ze strony użytkownika końcowego.

 

Wdrażanie systemu

 

Zakłady rozpoczynające analizę systemów zarządzania alarmami lub dokonujące przeprojektowania już istniejącego i wdrożonego systemu, powinny na początku fazy planowania poświęcić nieco czasu na przeanalizowanie tego, które z alarmów są priorytetowe, jaka powinna być ich częstotliwość oraz co robić po ich ogłoszeniu. Bez tego wczesnego planowania operatorzy w fabrykach mogliby zostać przytłoczeni nieoczekiwanymi alarmami, wynikającymi z braku ustawienia wyraźnych priorytetów lub nieskonfigurowania prawidłowych procedur działań. Z drugiej strony trzeba cały czas pamiętać, że jeśli właściwe sygnały alarmowe nie zostaną wysłane, może dojść do utraty kluczowych danych operacyjnych.

Istnieją podstawowe wymagania dla fazy projektowej systemu alarmowego. Przede wszystkim jest to proces powtarzalny i cykliczny, obejmujący dodawanie lub usuwanie informacji z trzech zakresów: generacji, historii i prezentacji alarmów. W początkowej fazie projektowania trzeba znaleźć równowagę między pragnieniem uwzględnienia wszystkich możliwych zdarzeń wywołujących alarmy a niezbędnym ograniczeniem liczby informacji, które muszą być przetworzone. Jeśli bowiem pojawia się zbyt dużo komunikatów alarmowych, system staje się nieużyteczny, a gdy z kolei liczba komunikatów alarmowych jest niewystarczająca, mogą zniknąć kluczowe dane. Zaleca się jednak, aby na początku system zbierał raczej zbyt wiele danych niż zbyt mało, ponieważ łatwiej jest odfiltrować później ich nadmiar, niż próbować odgadnąć, których danych brakuje.

Podczas początkowych faz wdrażania systemu mogą się pojawiać pewne przeszkody, np. brak wystarczających zasobów komputerowych wyznaczonych do zarządzania alarmami lub ekranów dostosowanych do potrzeb użytkownika. Jednym z rozwiązań może być opracowanie i uruchomienie kilku ekranów ogólnych, dopasowanych do potrzeb użytkownika na podstawie specyficznych operacji (takich jak aliasing, filtrowanie, logowanie się użytkowników itd.), zamiast prób zmodyfikowania wszystkich ekranów. Oszczędza to czas przy wdrożeniu i utrzymywaniu aplikacji.

 

Ocena i analiza

 

Co jakiś czas użytkownicy powinni oceniać alarmy wysyłane przez system, aby stwierdzić, czy wszystkie są konieczne do zarządzania procesem. Pomaga to zorientować się, którym alarmom obniżyć priorytet, a które odfiltrować w podsumowaniach alarmów, czasowo wyłączyć lub całkowicie usunąć.

Zaleca się, aby użytkownicy wybierali taki system zarządzania alarmami, który spełnia wytyczne standardu ISA 18.2. Takie normy przemysłowe z jednej strony wprowadzają pewne wymogi co do oczekiwań klientów, a z drugiej umożliwiają producentom tworzenie rozwiązań dopasowanych do użytkowników końcowych. Wykorzystanie norm daje klientom pewność, że wybrany system powinien działać optymalnie w stosunku do zgłaszanych przez nich potrzeb.

Poza zgodnością z normami przemysłowymi istnieją inne zalecane funkcje systemów zarządzania alarmami, które powinny zostać przeanalizowane przez użytkowników. Obejmują one kilka procedur pomagających w redukowaniu alarmów w systemie, bez trwałego ich usuwania z konfiguracji – takich jak: tłumienie, wyłączenie dla urządzeń usuwanych z eksploatacji, wyłączanie lub filtrowanie. Procedury te i funkcje oferują różne opcje wyboru przy redukowaniu obciążenia systemu, z zachowaniem oryginalnej konfiguracji, aby w razie potrzeby dało się cofnąć wszelkie zmiany. Klienci powinni ponadto być ostrożni w stosunku do pewnych funkcji, takich jak powiązanie alarmów z platformami popularnych mediów społecznościowych. Wiele osób zniechęca się do tej funkcji, gdy tylko dotrze do nich, że ich dane firmowe mogą być zaraz po opublikowaniu uważane za własność platformy mediów społecznościowych.

Gdy na wczesnym etapie projektowania dysponuje się odpowiednim planem, zwracając uwagę na rozmaite szczegóły (takie jak zrozumienie wspólnych zadań utrzymania ruchu, normy przemysłowe i najnowsze funkcje oszczędzania czasu), zarządzanie alarmami może stać się narzędziem przynoszącym realne korzyści i pomagającym w optymalizacji operacji realizowanych w zakładzie.

 

Sześć wskazówek dotyczących efektywnego zarządzania alarmami

 

 Wykorzystuj odpowiednią normę, taką jak ISA 18.2 – „Sygnały z przyrządów i alarmy”.

 Jeśli jesteś zaangażowany w projektowanie alarmów lub zmiany systemu zarządzania nimi, powinieneś rozumieć powtarzalną i cykliczną naturę tego typu procesów, w tym dodawanie lub usuwanie informacji z trzech zakresów: generacji, historii i prezentacji alarmów.

 Podczas oceny alarmów rozważ oczekiwania, jakie masz w związku z priorytetami alarmów, ich częstotliwością i niezbędnymi do podjęcia działaniami po ich wystąpieniu.

 Bądź ostrożny przy filtrowaniu komunikatów alarmowych. Łatwiej jest bowiem wyciąć zbędne dane, niż za późno zdać sobie sprawę z utraty kluczowych informacji.

 Stwórz kilka ekranów ogólnych, które mogą być dopasowane do potrzeb użytkownika na podstawie specyficznych operacji.

 Przeanalizuj takie funkcje systemu, jak tłumienie alarmów, wyłączanie alarmów dla urządzeń usuwanych z eksploatacji oraz wyłączanie lub filtrowanie.

 

Autorka: Melissa Topp jest dyrektorem ds. marketingu globalnego w firmie Iconics Inc.

Tekst pochodzi ze specjalnego wydania “Bezpieczeństwo 2018“. Artykuł można znaleźć również na stronie www.utrzymanieruchu.pl.

 

---

 

Zarządzanie alarmami w systemie SCADA ICONICS

Zakres tematów poruszanych we wpisie

 

Niniejsza lekcja zawiera omówienie funkcjonalności: serwera alarmowania od ICONICS – AlamWorX64, umożliwiającego konfigurację monitorowanych zmiennych, narzędzia wizualizacji – AlarmWorX Viewer używanego w celu graficznej prezentacji danych o alarmach. Efektem końcowym podejmowanych tu działań, będzie interfejs służący wygodnemu zarządzaniu alarmami. Będzie on umożliwiał m.in. łatwą filtrację oraz zatwierdzanie alarmów, co natomiast zapewniać będzie szybki oraz bezbłędny przepływ informacji w systemie.

 

Serwer alarmowania w systemie SCADA – GENESIS64

 

Pierwszy krok to utworzenie własnej konfiguracji serwera alarmów, która następnie znajdzie swoje graficzne odzwierciedlenie w projektowanym interfejsie SCADA / HMI. Konfiguracja narzędzia AlarmWorX Server przebiega w module Workbench, grupującym wszystkie narzędzia składowe ICONICS.

Zgodność z przemysłową normą ISA 18.2 dla systemów alarmowania

Serwer alarmów od ICONICS jest kompatybilny z przemysłową normą ISA 18.2 Norma ta grupuje wytyczne, które każdy integrator systemów powinien wziąć pod uwagę, aby zwiększyć bezpieczeństwo projektowanego rozwiązania.

Aby sprostać wymaganiom stawianym przez normę ISA 18.2, ICONICS udostępnia projektantom systemów następujące opcje.

• Latch on Acknowledge/Unacknowledge – utrzymuje („zamraża”) informacje o wzbudzonym stanie alarmu po jego zatwierdzeniu/niezatwierdzeniu i powrocie do stanu neutralnego. Informacja o wzbudzonym stanie alarmu utrzymuje się dopóki nie zostanie zresetowana przez operatora.
• Re-Alarming – jeśli czynnik wywołujący alarm nie ustąpi po pewnym okresie czasu, alarm zostanie wznowiony (nawet jeśli został wcześniej zatwierdzony).
• Shelved – umożliwia tymczasowe stłumienie alarmu. Projektant ustala czas tłumienia dla każdego alarmu osobno. Co więcej, tłumiony alarm wyróżnia się graficznie w oknie AlarmWorX Viewer.
• Out of Service – pozwala oznaczyć (do odwołania) pożądany alarm jako niedziałający. Może to być związane np. z naprawami podjętymi w celu usunięcia awarii, która w sposób ciągły wzbudza alarm.

To jedne z ważniejszych, choć nie jedyne opcje oferowane przez AlarmWorX Server.

Wszechstronność systemu zarządzania alarmami

Moduł alarmów w systemie SCADA od ICONICS pozwala na dostosowanie projektowanej aplikacji do szczegółowych wymagań klienta. System powinien móc monitorować zadane wartości pod względem różnych kryteriów dlatego, że procesy produkcyjne zachodzące w różnych przedsiębiorstwach mogą znacząco różnić się od siebie

System SCADA – GENESIS64 pozwala na konfigurację alarmów następujących typów.

• Alarm Limit – alarm analogowy, który uaktywni się po przekroczeniu lub spadnięciu wartości określonej zmiennej poniżej danego progu. Użytkownik ma możliwość określenia wyżej wspomnianych progów, priorytetu dla przekroczenia każdego z nich, czy treści wiadomości wysyłanej do wizualizacji po wystąpieniu danego warunku. Co więcej, każde z powyższych pól może zawierać wartość statyczną, lub odwołanie do zmiennej.
• Digital – alarm cyfrowy, który reaguje na przyjęcie przez monitorowaną zmienną jednej określonej wartości. Oferuje on wszystkie dodatkowe funkcje wymienione wyżej.
• Alarm Deviation – monitoruje różnicę dwóch zmiennych pod takimi samymi kryteriami, co alarm analogowy. Wymaga on oczywiście podania nazwy drugiej z monitorowanych zmiennych.
• Rate of Change – alarm, który monitoruje absolutną szybkość zmian tag’u OPC. Uaktywni się wtedy, gdy szybkość ta przekroczy określony próg. Jest ona liczona jako bezwzględna różnica dwóch kolejnych wartości zmiennej w odniesieniu do 1 sekundy. Użytkownik może podać dodatkowe informacje, podobnie jak w przypadku Alarm Limit.
• Alarm Rate Limit – działa podobnie, jak powyższy typ z tym, że liczy szybkość zmian tag’u OPC nie w oparciu o bezwzględną, a rzeczywistą różnicę wartości dwóch kolejnych jego próbek. Skutkuje to tym, że pojawiają się tu wartości dodatnie oraz ujemne dla mierzonych wartości. Użytkownik może więc podać tyle samo progów wartości jak dla alarmu Alarm Limit.
• Trigger Limit – alarm, który uaktywni się przy każdej zmianie wartości monitorowanego tag’u. Użytkownik nie określa więc tu żadnych progów wartości. Może natomiast podać informacje dodatkowe, jak przy alarmie Alarm Limit.

GENESIS64 oferuje dodatkowo możliwość zdefiniowania do 20 dodatkowych zmiennych, których wartości są zapisywane do tabel SQL po wystąpieniu odpowiedniego alarmu.

 

Konfiguracja serwera alarmów w systemie SCADA GENESIS64

Dodanie nowej konfiguracji

Zarządzanie alarmami w systemie SCADA GENESIS64 zaczyna się od poczynienia odpowiednich ustawień serwera AlarmWorX w module Workbench. Po pierwsze należy odnaleźć ten komponent w drzewku projektu w Workbench oraz dodać nową (lub edytować istniejącą) konfigurację.

Użytkownik wprowadza pożądaną nazwę dla danej konfiguracji oraz oznacza ją jako aktywną. Tylko jedna konfiguracja może być aktywna w danym czasie. Następnie, dostosowuje się opcje określające odpowiednio czy: przy generowaniu alarmów serwer AlarmWorX używa próbek czasowych pochodzących z serwera OPC DA (z którego pobiera wartości zmiennych), czy generuje próbki wykorzystując wewnętrzny zegar; alarmy oznaczone jako „nieaktywne” dalej podlegają monitorowaniu; wspierane są funkcje określone w normie alarmowania ISA 18.2.

Dodatkowo, użytkownik określa częstość skanowania wartości monitorowanych tag’ów w tworzonej konfiguracji oraz zestaw motywów dla Aliasów Globalnych (jeśli zostały użyte przy konfiguracji).

Opcja Startup Squelch pozwala „wyciszyć” alarmy przez określony czas od włączenia serwera. Przydaje się ona przy starcie całego systemu, kiedy dopiero inicjalizuje się połączenia z serwerami OPC i przesyła dane ze złą jakością. Pozwala ona uniknąć wielu powiadomień serwera niezgodnych z rzeczywistością.

Dodanie nowego alarmu

Dołączenie kolejnej zmiennej podlegającej monitorowaniu następuje po wyborze PPM myszy utworzonej konfiguracji i wskazaniu opcji „Add Tag”. W przypadku alarmu w systemie GENESIS, otworzy się nowe okno konfiguracyjne złożone z kilku zakładek.

Pierwsze dwie z nich są wspólne dla każdego typu alarmu. Użytkownik powinien podać w nich m.in. adres monitorowanej zmiennej, tekst wyświetlany po wystąpieniu alarmu czy instrukcje dla operatora w razie sytuacji awaryjnej. Co więcej, w pierwszej zakładce w sekcji „Advanced Settings” określane są opcje ze standardu ISA 18.2 omówione wyżej. Druga z nich służy do przyporządkowania alarmu do określonej grupy (ang. Area). Utworzenie grup jest jednak zadaniem tak prostym, że zostało w tym miejscu pomięte.

Ostatnia z zakładek – „Other” pozwala natomiast na zdefiniowanie do 20 zmiennych powiązanych z alarmem (wspomnianych wyżej). Ich wartości w momencie wystąpienia alarmu można zapisać do baz SQL.

 

Metody wizualizacji alarmów na interfejsach SCADA / HMI

 

Zarządzanie alarmami w systemie SCADA to również, a może nawet przede wszystkim, ich skuteczna i przejrzysta wizualizacja. Moduł wizualizacji w GENESIS64 – GraphWorX oferuje narzędzie do wizualizacji informacji o alarmach – AlarmWorX Viewer.

Użytkownik ma możliwość skorzystania z trzech sposobów przedstawiania tych danych:

• za pomocą dynamicznej tabeli,
• przy użyciu wykresu,
• z wykorzystaniem dynamicznej listy,
• za pomocą przewijanej listy (wygodnego dla dotykowych urządzeń mobilnych).

Aby lepiej opisać możliwe rozwiązania, zamieszczono poniższe zdjęcie.

Dlatego, że dynamiczna tabela oferuje najwięcej opcji konfiguracyjnych, to ona zostanie szerzej opisana w dalszej części artykułu.

Konfiguracja dynamicznej tabeli alarmów

Po otworzeniu okna GraphWorX, należy w zakładce „Controls” wyszukać AlarmWorX Viewer, a następnie wskazać miejsce na projektowanym interfejsie – za pomocą LPM narysować prostokąt. Po dwukrotnym kliknięciu na nowo utworzony element pojawi się jego okno konfiguracyjne. W lewej części tego okna widnieje małe drzewko elementów. Na samym jego szczycie znajduje się obiekt „AlarmWorX64 Viewer”. Symbolizuje on nowo dodaną instancję tego narzędzia. Element „Tab” natomiast pełni rolę zakładki. Do niego podpięty jest następnie komponent „Grid” będący omawianą dynamiczną listą.

Poprzez klikanie PPM na obiekty nadrzędne oraz użycie prostej opcji „Add ..” użytkownik może dodać wiele zakładek do danej instancji AWX Viewer’a, jak i również wiele różnych elementów to jednej zakładki. Hierarchia komponentów jest na bieżąco uaktualniana w opisywanym drzewku. Omawiane narzędzie oferuje też wiele opcji dostosowujących tytuły, podtytuły oraz kolorystykę wykorzystywanych obiektów.

Ustawienia dynamicznej tabeli

Wybierając z drzewka przedstawionego na zdjęciu powyżej element typu „Grid” ukazują się nowe zakładki zawierające jego opcje. Dlatego, że przykładową konfigurację zobrazowano na filmie podsumowującym ten wpis, w tym miejscu ograniczono się do krótkiego opisu najbardziej kluczowych zakładek.

„Source” – pozwala na wybór, z którego serwera alarmowania (w przypadku posiadania ich większej liczby) nastąpi wyświetlanie danych. Można tu również wskazać tylko pewien obszar („Area”) zdefiniowany w obrębie serwera lub źródło danych historycznych, czy serwer zdarzeń systemowych („Events”). „Appearance” – za jej pomocą następuje dostosowanie szaty graficznej tabeli (kolorystyka, obecność linii itp. …).

• „Behavior” – odpowiada za ustawienia interakcji z tabelą. Tu określa się, czy dozwolona jest zmiana wielkości kolumn, wierszy oraz ich filtrowanie. Użytkowniki definiuje i aktywuje różnego rodzaju filtry. Decyduje również, czy zatwierdzeniu danego alarmu musi towarzyszyć komentarz operatora, a jeśli tak, to którym alarmom.
• „Column” – pozwala na dostosowanie zawartości, wyglądu, nazwy oraz widoczności kolumn przechowujących informacje o rekordach – tu: alarmach.
• „Condition” – za jej pomocą można dostosować wygląd poszczególnych rekordów tabeli, w zależności od informacji, jaką ze sobą niosą. Ten wygląd zmienia się dynamicznie, wraz ze zmianą danych dotyczących poszczególnych alarmów.
• „Status Indicator” – odpowiada za definiowanie dynamicznych symboli wizualnych, obecnych dla danego rekordu w zależności od zadanych warunków. W konsekwencji zapewnia to jeszcze większą przejrzystość i uporządkowanie prezentowanych danych.

Nie są to jedyne, lecz jedne z ciekawszych zakładek konfiguracyjnych, których funkcjonalności zobrazowano na filmie podsumowującym ten wpis.

 

Zarządzanie alarmami w systemie SCADA na przykładzie dynamicznej tabeli

 

Aby jak najlepiej zobrazować treści zamieszczone w tym artykule przygotowano przykładowy projekt wykorzystujący znaczną część z opisywanych funkcjonalności. Na jego potrzeby stworzono nową konfigurację serwera alarmowania AlarmWorX64.

Składa się ona z dwóch obszarów:

• EastPowerStation,
• WestPowerStation.

Obszary te grupują alarmy rożnych typów, do których przyporządkowano różne typy funkcji ISA 18.2, priorytety, teksty oraz podpowiedzi. Są one wizualizowane za pomocą tabeli dynamicznej w programie GraphWorX.

Aby wizualizacja przebiegała sprawniej i była bardziej czytelna, każdy alarm monitoruje zmienną statyczną symulowaną wewnątrz systemu GENESIS64. Wartości poszczególnych zmiennych są zmieniane ręczne.

Poniższa tabela stanowi zestawienie posiadanych w systemie alarmów. Dla uproszczenia, każdy obszar zawiera analogiczne alarmy, tzn. alarmy o odpowiadających sobie nazwach są takiego samego typu oraz realizują takie same funkcje standardu ISA 18.2. Ich nazwy różnią się ostatnią literą:

• „E” – odpowiada obszarowi EastPowerStation,
• „W” – WestPowerStation.

Poniższy film wizualizuje przedstawione tu informacje, począwszy od pokazania konfiguracji AWX Server’a w Workbench, po symulacje działania zaprojektowanego systemu.

Elmark Automatyka udostępnia wersję demo oprogramowania GENESIS64 w celu osobistego przetestowania funkcjonalności pakietu. Skontaktuj się z nami na iconics@elmark.com.pl w celu otrzymania wersji testowej lub oferty handlowej.

 

---

 

SCADA ICONICS zgodna z FDA 21CFR11. Zdarzenia systemowe, archiwizacja alarmów, zabezpieczenia.  

Z tej lekcji dowiesz się, dlaczego system SCADA ICONICS jest zgodny z przepisami FDA dla Twojego systemu.

 

Czym jest FDA?

 

FDA to akronim od nazwy: „Food and Drug Administration”. Oznacza ona amerykańską instytucję rządową zajmującą się kontrolowaniem oraz określaniem norm obowiązujących dla podmiotów w przemyśle farmaceutycznym, spożywczym, czy kosmetycznym.

Opinia FDA również poza Stanami Zjednoczonymi stanowi wyznacznik jakości oraz bezpieczeństwa dla danych wyrobów spożywczych, farmaceutycznych, czy systemów SCADA kontrolujących ich produkcję.

CFR oznacza „Code of Federal Regulations” – zbiór przepisów federalnych obowiązujących w USA. Oznaczenie 21CFR11 wskazuje pewien podrozdział w tym obszernym kodeksie, traktujący o wytycznych na temat:

• kontroli dostępu,
• przepływu informacji,
• archiwizacji danych o aktywnościach użytkowników systemów zarządzających procesami w wyżej wymienionych gałęziach przemysłu.

 

System SCADA od ICONICS zgodny z FDA

 

Rozporządzenia FDA z zakresu 21CFR11 odnoszą się głównie do zapewnienia administratorom systemów kontroli nad:

• dostępem poszczególnych użytkowników do systemu oraz prowadzeniem właściwej polityki w tym zakresie,
• bieżącym powiadamianiu na temat aktywności poszczególnych operatorów,
• archiwizacji informacji na temat działań podejmowanych przez pracowników,
• generowaniu raportów na temat sytuacji awaryjnych, które wystąpiły w systemie.

64 bitowy system SCADA od ICONICS – GENESIS64 – posiada moduły umożliwiające integratorom odpowiednie dostosowanie oprogramowania do potrzeb firmy wymagającej zgodności z normami FDA. Narzędzia ICONICS, będące tematem tego wpisu to:

• Security Server,
• GenEvent Server,
• AlarmWorX Logger,
• Audit Log (narzędzie składowe w Workbench).

Kontrola dostępu do systemu – Security Server

Dzięki temu narzędziu, integrator może stworzyć wielu użytkowników posiadających swoje własne unikatowe hasło oraz login.

Administrator systemu nadający uprawnienia posiada szerokie możliwości odnośnie kreowania polityki bezpieczeństwa w systemie GENESIS. Może on automatycznie wymuszać okresową zmianę haseł przez użytkowników, udostępnić im możliwość logowania tylko w określonych porach, zezwalać (lub nie) na jednoczesne logowanie kilku użytkowników na jednym koncie, wskazać minimalną moc hasła lub ustawić auto-wylogowanie po określonym czasie.

W celu zdobycia większej ilości informacji, zaleca się przeczytanie wyżej wspomnianego wpisu. Niżej zamieszczony film pokazuje działanie ciekawej funkcji Security Server – czasowy dostęp do pewnych krytycznych zasobów zdefiniowanych przez użytkownika. Administrator definiuje które zasoby (np. zmienne) są krytyczne i ustala czas dostępu do nich (po którym staną się zablokowane). W wyniku tego możliwość manipulacji nad tymi elementami jest możliwa zawsze tylko po podaniu odpowiedniego loginu i hasła.

GenEvent Server – bieżące powiadomienia o zdarzeniach

GenEvent Server to narzędzie pracujące w podobny sposób jak serwer alarmowania – AlarmWorX Server. Jednak zamiast zbierać i przetwarzać informacje o alarmach zdefiniowanych przez użytkowników, gromadzi ono dane o zdarzeniach zachodzących w samym systemie i zapisuje je również jako tagi typu OPC A&E (Alarms and Events).

 

Informacje o akcjach systemowych mogą zostać wyświetlone tak samo jak alarmy. W tym celu można posłużyć się narzędziem AlarmWorX Viewer dostępnym w module graficznym GraphWorX. Jedyne, co trzeba zrobić, to zasubskrybować odpowiedni serwer powiadomień – w tym przypadku GenEvent Server. Następnie po przejściu do trybu symulacji w oknie AlarmWorX Viewera powinny pojawiać się na bieżąco kolejne rekordy zawierające informacje o zdarzeniach – pogrupowane w kolumny. Użytkownik może wybrać, które kolumny spośród dostępnych mają się ukazywać na interfejsie.

Powyższy film przedstawia wygląd rekordów pojawiających się w module wizualizacji po zalogowaniu danego użytkownika oraz po zablokowaniu jego konta (w wyniku 3 – krotnego błędnego wprowadzenia hasła).

AlarmWorX Logger – zapis zdarzeń do baz SQL

Narzędzie AlarmWorX Logger jest konfigurowane z poziomu aplikacji Workbench – części systemu GENESIS64. Pozwala ono na zapis informacji dotyczących zarówno alarmów skonfigurowanych przez użytkownika, jak i zdarzeń systemowych, wyświetlanych w poprzednim podrozdziale, do baz danych SQL.

W systemie SCADA od ICONICS można wyróżnić 3 typy zdarzeń systemowych:

• Simple Event – proste powiadomienie o zdarzeniu systemowym będące wynikiem wyłączenia lub włączenia Serwera Hyper Historian czy dodaniu nowego tagu do jego konfiguracji;
• Tracking Event – zdarzenie z dodaną informacją o jego wykonawcy,
• Condition Events – warunkowe (takim zdarzeniem może być alarm analogowy z kilkoma dopuszczalnymi progami wartości, itp.).

Wśród zdarzeń Tracking Events istnieje kilka kategorii, np. „Operator Process Change” – która odnosi się m.in do zmian wartości zmiennych OPC przez danego operatora lub logowań do systemu przez użytkowników.

Po wyszukaniu elementu symbolizującego AWX Logger w oknie Workbench, możliwe jest dodanie pod nim nowej konfiguracji. W jej ustawieniach użytkownik określa m.in.

• token połączenia z odpowiednią bazą danych,
• nazwy dla tworzonych tabel oraz parametry, takie jak np. maksymalna ilość rekordów, po wystąpieniu których tworzona jest nowa tabela,
• token połączenia z zapasową (redundantną bazą danych),
• subskrypcję odpowiedniego serwera zdarzeń systemowych oraz określenie pożądanego typu zdarzeń.

Wszystkie wyżej wymienione opcje (i wiele innych) zgrupowanych jest w 4 zakładkach. W tym przypadku najbardziej godna uwagi jest ostatnia zakładka odpowiedzialna za ustawienie w/w subskrypcji serwera. To w tym miejscu określa się jakie typy zdarzeń oraz jakie kategorie poszczególnych typów będą archiwizowane w bazach SQL. Zamieszczony niżej krótki film pokazuje jak skonfigurować AWX Logger by zapisywał informacje o zmianach wartości tagów OPC przez poszczególnych operatorów.

Ostatnim etapem jest dodanie pod nową konfiguracją AWX Loggera własnych elementów symbolizujących kolejne kolumny rekordów zapisywanych w bazach SQL. Użytkownik ma możliwość wyboru spośród wielu rodzajów informacji. W tym przypadku ograniczono ich ilość do kilku kluczowych (w tym „ActorID” będącej nazwą użytkownika wprowadzającego zmianę ), w celu zachowania przejrzystości tłumaczonych reguł.

 

Rejestrowanie zmian konfiguracji Workbench – Audit Log

System SCADA od ICONICS – GENESIS64 posiada dwa główne moduły: Workbench (moduł konfiguracji) oraz GraphWorX (kreator interfejsów graficznych). W pierwszym z nich istnieje ciekawa funkcja pozwalająca na automatyczne zapisywanie wszelkich informacji o zmianach wprowadzanych w obrębie Workbench.

Do obsłużenia omawianej funkcji („Audit Log”) wystarczą jedynie dwie opcje:

• Audit Log Enabled/Disabled – włącza/wyłącza funkcjonalność,
• Show Audit Log – daje dostęp do posiadanych rekordów.

Obydwie opcje znajdują się na górnym pasku narzędzi Workbench w zakładce „Tools”.

Po przejściu do okna wyświetlania rekordów możliwy jest wybór przedziału czasowego, z którego mają zostać wyświetlone informacje. Po ukazaniu się danych możliwe jest wykorzystanie opcji powodującej skopiowanie ich do schowka. GENESIS umożliwia ich skopiowanie wraz z automatyczną konwersją do formatu JSON. Film przedstawia użycie funkcji Audit Log na przykładzie manipulowania stanem pracy AWX Loggera przez użytkownika „admin”.

Elmark Automatyka udostępnia wersję demo oprogramowania GENESIS64 w celu osobistego przetestowania funkcjonalności pakietu. Skontaktuj się z nami na iconics@elmark.com.pl w celu otrzymania wersji testowej lub oferty handlowej.

 

---

 

Archiwizacja alarmów w systemie SCADA ICONICS – przegląd funkcji

Poznaj sposób, w jaki funkcjonuje archiwizacja alarmów w systemie SCADA ICONICS. Zobacz jak przebiega zapis danych o awariach do baz danych SQL.

 

Wykorzystywane narzędzie

 

Komponent służący do zapisywania informacji o alarmach do baz danych SQL to AlarmWorX Logger. Jest on częścią serwera alarmowania dostępnego w podstawowym systemie SCADA od ICONICS. Zapewnia on pełną archiwizację danych o sytuacjach awaryjnych, czy zdarzeniach systemowych, jak również pozwala użytkownikowi na precyzyjne dostosowanie parametrów zapisu.

Wstępem teoretycznym do tego narzędzia jest wcześniejsza lekcja o FDA 21CFR11 znajdująca się na tej stronie (dokładnie, jej sekcja „AlarmWorX Logger – zapis zdarzeń do baz SQL”). Mimo, że omawia ona jedynie zdarzenia systemowe, AWX Logger może też archiwizować informacje o alarmach - w analogiczny sposób.

 

Funkcje archiwizacji udostępniane przez AlarmWorX Logger

 

Wyzwalanie archiwizacji alarmów

AlarmWorX64 Logger archiwizuje dane, regularnie sprawdzając, czy:

• liczba rekordów w aktywnej tabeli SQL znajduje się powyżej maksymalnej ich liczby („Max Records”),
• maksymalny zakres czasowy rekordów w tabeli został przekroczony („Max Interval”),

a następnie przenosi nadmiar wierszy do tabel archiwalnych SQL.

Po wyzwoleniu archiwizacji, AWX Logger przesunie wystarczająco dużo wierszy z aktywnej tabeli do archiwalnej, aby sprowadzić liczbę rekordów aktywnej tabeli (lub ich zakres czasowy) do zdefiniowanego Max Records (lub Max Interval). Oznacza to, że może wystąpić sytuacja, gdy tabela aktywna posiada więcej rekordów niż wartość parametru Max Records (Max Interval). Jednak zaraz po wyzwoleniu archiwizacji wróci w zakres bardzo bliski skonfigurowanym limitom.

Zarządzanie archiwalnymi tabelami SQL

Jeśli AWX Logger wykryje, że liczba tabel archiwalnych przekracza zdefiniowany parametr Max Archive Tables, usunie najstarszą tabelę. Należy pamiętać, że aby usługa archiwizacji była aktywna, wymaga się większej od zera wartości parametru Max Archive Tables. Co więcej, odznaczenie opcji „Max Archive Tables” całkowicie wyłączy proces archiwizacji, a aktywna tabela będzie mogła rosnąć w nieskończoność.

Archiwalne tabele na serwerze SQL noszą nazwę tabeli aktywnej, po której następuje znacznik czasu (ang. Timestamp) – data utworzenia tabeli. Kiedy wyzwala się archiwizacja, AWX Logger sprawdza najnowszą taką tabelę pod względem ilości rekordów a także ich zakresu czasowego. Jeśli wielkości te przekraczają wartości parametrów (odpowiednio: Max Archive Records lub Max Archive Interval), AWX Logger tworzy nową tabelę archiwalną na serwerze SQL.

Pomiędzy tabelami dane zawsze transportuje się w „kawałkach”. Parametr „Max Records Size” oznacza maksymalną liczbę rekordów (wierszy), które migrują z aktywnej do archiwalnej tabeli w jednym kawałku. Wiele takich „kawałków” może być przetwarzanych w jednym okresie (za jednym wyzwoleniem) archiwizacji.

Tryby archiwizacji alarmów w AWX Logger

Archiwizacja alarmów w systemie SCADA od ICONICS opiera się w całości o bazy SQL i można wyróżnić dla niej 3 tryby.

• SQL Only – Jest to domyślne zachowanie systemu archiwizacji. W wyniku tej opcji, proces archiwizacji (sprawdzanie warunków opisywanych wyżej) przebiega w tempie określonym przez ustawienie parametru Archive Period.
• Archive Daily – proces archiwizacji uruchamia się raz dziennie. Co więcej, po uruchomieniu cały zestaw rekordów w aktywnej tabeli migruje do nowej, archiwalnej. Ponadto, AWX Logger nie bierze pod uwagę ustawień Max Records, Max Interval, Max Archive Records i Max Archive Interval. Parametr Max Archive Tables nadal obowiązuje (teraz można go interpretować jako liczbę dni, z których dane o alarmach znajdują się w tabelach SQL). Zamiast korzystać z okresu archiwizacji, użytkownik określa porę dnia (godzinę w zakresie (0, 23) – parametr Archive On Time), o której następuje wyzwolenie archiwizacji. Należy pamiętać, że proces archiwizacji wyzwoli się o tej porze dnia lub później. Jeśli ustawiono go np. na 22:00, a serwer AWX Logger rozpoczął pracę o godzinie 23:00, wszystkie działania zostaną przeprowadzone o 23:00. Stanie się tak, ponieważ AWX Logger wykryje, że pora archiwizacji minęła, ale jest wciąż ten sam dzień.

• Create Tables Daily – działa tak samo jak tryb Archive Daily, z wyjątkiem częstszych kontroli. Tryb Archive Daily działa tylko o określonej godzinie, natomiast Create Tables Daily wyzwala się zgodnie z okresem archiwizacji (Archive Period). Mimo wszystko, tryb ten nadal powoduje przeniesienie całego zestawu alarmów z aktywnej tabeli do bieżącej tabeli archiwalnej. Dodatkowo, raz dziennie o godzinie skonfigurowanej jako parametr Archive on Time, zostanie utworzona nowa tabela SQL. Podobnie jak w przypadku trybu Archive Daily, tutaj też ignoruje się parametry Max Records, Max Interval, Max Archive Records i Max Archive Interval. Natomiast nadal spełniane są wymagania stawiane przez wielkość: Max Archive Tables.

Podsumowanie opcji archiwizacji alarmów

Aby lepiej zrozumieć powyższe treści zamieszczono niżej zdjęcie obrazujące okno konfiguracyjne AWX Logger’a. Aby dostać się do tej lokalizacji należy otworzyć program Workbench (środowisko konfiguracyjne systemu SCADA od ICONICS). Dalsze działania obrazuje zamieszczone zdjęcie.

 

Porównanie trybów archiwizacji

W zdecydowanej większości przypadków, użytkownicy powinni korzystać z domyślnego trybu archiwizacji – SQL Only. Zarówno metoda Archive Daily, jak i Create Tables Daily jest zalecana dla użytkowników, którzy oczekują rejestrowania dużej ilości rekordów dziennie. Zaleca się pozostanie przy metodzie SQL Only, chyba że okaże się ona zbyt wolna w działaniu względem przyrostu danych w systemie. Niemniej jednak, SQL Only jest jedyną metodą, która zawsze pozostawia pewną ilość rekordów w aktywnej tabeli. Jest to zachowanie, którego oczekuje większość użytkowników.

Tryb Create Tables Daily jest wydajniejszy niż Archive Daily, ponieważ aktywuje się częściej i dlatego pracuje za każdym razem z mniejszym zestawem danych. Będzie on jednak usuwać aktywną tabelę częściej niż tryb Archive Daily. Co za tym idzie, użytkownik powinien wziąć to pod uwagę przed dokonaniem wyboru pomiędzy nimi.

 

Redundantna archiwizacja danych alarmowych

 

Archiwizacja alarmów w systemie SCADA ICONICS może zostać skonfigurowana jako lokalnie redundantna. Oznacza to w tym przypadku wprowadzenie łańcuchów połączeń z dwiema oddzielnymi bazami danych. Jeśli łączność zniknie, zapis realizuje się do zapasowej lokalizacji. Oczywiście dalej jest on zgodny z regułami ustalonymi według powyższych opisów. Rozwiązanie to nie zapewnia jednak ciągłości zapisu do tabel SQL w przypadku awarii całego serwera GENESIS64.

Ustawienia redundancji widoczne są na zdjęciu dodanym wyżej. Jest tam też dodatkowo pole o nazwie „Enable Store and Forward”. Pozwala ono na specyfikację lokalizacji na dysku komputera, w której utworzy się plik z danymi, nie mogącymi trafić do bazy SQL w wyniku utraty połączenia.

Przy korzystaniu z zapasowej bazy danych, powinno się również skorzystać z funkcji store-and-forward. Funkcja ta buforuje dane w przypadku utraty połączenia z bazą danych ustawioną dla Logger’a. Kiedy połączenie z nią zostanie przywrócone, zawartość tych plików zostanie wyczyszczona, a dwie (podstawowa i zapasowa) bazy danych zostaną automatycznie zsynchronizowane.

 

Połączenie z serwerem alarmowania

 

Ustawienie subskrypcji (wskazanie źródła danych) serwera alarmowania, z którego pobierane są informacje o sytuacjach awaryjnych, następuje w zakładce „Alarm Subscription”. Jest ona również widoczna na zdjęciu dodanym wyżej.

Użytkownik jest w stanie wskazać odpowiedni serwer alarmów oraz określić zakres priorytetów, które wyselekcjonują interesującą grupę alarmów. Co więcej, można wskazać jakie typy alarmów mają być archiwizowane oraz ustalić które informacje na ich temat zostaną zapisane.

Ponadto, użytkownik może tworzyć własne filtry oparte na formułach matematycznych i zmiennych dostępnych w systemie SCADA. Rozwiązanie to sprawdza się wtedy, gdy wyżej wymienione opcje nie pozwalają zawęzić zbioru wszystkich alarmów do ściśle pożądanej grupy.

Zakładkę „Alarm Subscription” ukazano na krótkim filmie pokazowym zamieszczonym we wcześniejszej lekcji (o FDA 21CFR11), w sekcji "AlarmWorX Logger - zapis zdarzeń do baz SQL". 

 

---

 

AlertWorX™: wysyłanie alertów e-mail i SMS

Przed przystąpieniem do realizacji czynności opisanych poniżej należy mieć zainstalowany pakiet GENESIS64 z AlarmWorX64, a także mieć skonfigurowany alarm, którego będą dotyczyć powiadomienia wysyłane w e-mail lub SMS.

 

Wysyłanie alertów e-mail przez AlertWorX™

 

Konfiguracja narzędzia odbywa się w aplikacji Workbench - scentralizowanym środowsku do tworzenia projektów dla systmeu SCADA GENESIS64. Aby skonfigurować narzędzie AlertWorX do wysyłania powiadomień o alarmach przez e-mail należy przejść do:

(Nazwa projektu)>Alarms and Notifications> AlertWorX> Configurations> Email

Na tej zakładce należy przycisnąć PPM, aby dodać nową konfigurację (nr 1 na zdjeciu poniżej). Po stworzeniu konfiguracji należy wprowadzić ustawienia konta nadającego powiadomienia (2) - są one charakterystyczne dla posiadanej skrzynki e-mail i najczęściej można je znaleźć w jej ustawieniach. Co więcej, trzeba również upewnić się, że nasza skrzynka pocztowa dopuszcza taką automatyzację wysyłania wiadomości za pośrednictwem oprogramowania trzeciego (tu - systemu SCADA GENESIS64). Na przykład, w przypadku Gmail należy zaznaczyć dla posiadanego konta opcję zezwalającą na dostęp mniej bezpiecznych aplikacji - takich, które nie używają dwuetapowego uwierzytelniania. 

Dodatkowo, należy wprowadzić temat wiadomości (3), treść wiadomości (4) oraz odbiorcę (5). Parametry znajdujące się w tytule i treści wiadomości mogą być zmiennymi odnoszącymi się do informacji o alarmie, który wywołał wysłanie powiadomienia. Można je wstawiać za pomocą przycisku (6).

 

Jeżeli nie ma tam interesującej nas wielkości np. aktualnej wartości ("CV" - current value), należy ją znaleźć dodając odpowiednie obszary subskrypcji alarmów za pomocą przycisku (7). Sekcja "Alarm Subscription" umożliwia zarządzanie alarmami, których będą dotyczyć wysyłane powiadomienia. Tak skonfigurowane narzędzie AlertWorX będzie informować użytkownika o każdej zmianie statusu alarmu za pośrednictwem wiadomości e-mail. Adresy e-mail odbiorców oddzielamy przecinkiem. W polu tym można również dodać zmienną typu string, która przechowuje ciąg znaków symbolizujący adresy odbiorców.

 

Wysyłanie alertów SMS przez AlertWorX™

 

W opisywanym przykładzie, do wysyłania alertów SMS, używamy modemu GSM CINTERION TC65 wykorzystującego RS232 do połączenia z komputerem. Po podłączeniu modemu GSM do komputera i odczytaniu portu COM, który odpowiada za komunikację komputera z modemem, możemy przejść do konfiguracji narzędzia AlertWorX.

W tym celu przechodzimy w aplikacji Workbench do:

(Nazwa projektu)>Alarms and Notifications> AlertWorX> Configurations> SMS/Text

Podobnie, jak w przypadku konfiguracji alertów e-mail, dodajemy nową konfigurację (1). Następnie, należy ustalić co najmniej podstawowe parametry połączenia (2):

• Node – lokalizacja usługi AlertWorX, której konfigurację wprowadzamy. W przypadku tego samego komputera należy wpisać „localhost”.
• Device – nazwa portu COM, do którego podłączony jest modem GSM.
• Pin – numer pin wykorzystywanej karty sim (jeśli karta nie ma przypisanego pin – pozostawić puste pole).
• Baud rate – prędkość wymiany danych z modemem.
• Use UA points – (opcjonalnie) alarm będzie wyzwalany za pomocą zmiennej, której adres podany jest w polu „Send” na dole okna.
• Use only targeted alarms – tylko alarmy ze specjalnymi „flagami” będą brane pod uwagę przy wyzwalaniu powiadomień SMS.
• Receive commands on this node – inne narzędzia GENESIS64 będą mogły wyzwalać połączenia SMS za pomocą specjalnych komend.

Możliwe jest też ustalenie treści wiadomości (3), również w oparciu o zmienne pola alarmów, które wywołały wysłanie SMS. Tak skonfigurowane połączenie z modułem GSM Criterion TC65 wysyła wiadomości SMS na podany numer telefonu (4).

 

Zapraszamy do kontaktu na adres iconics@elmark.com.pl w celu konsultacji technicznych lub uzyskania wyceny.

 

---