Komunikacja w systemie SCADA ICONICS - poradnik konfiguracji
- Zakłady przemysłowe
- Gaz i Paliwa
- Energetyka
Łączność z wieloma różnymi źródłami danych to podstawowa cecha, jaką powinien odznaczać się każdy system SCADA. ICONICS wyposażył swój system SCADA w szerokie możliwości łączności. Przede wszystkim SCADA od ICONICS posiada funkcję wymiany danych poprzez standard OPC – zarówno Classic, jak i UA. Te metody wymiany danych stały się na tyle kluczowe w obecnym przemyśle, że możliwość ich obsługi wydaje się nieodzowna.
Poza łącznością z OPC, SCADA od ICONICS posiada natywne moduły komunikacji z Modbus, SNMP, BACNet, MQTT, bazami danych: SQL Server, Oracle, OLEDB oraz ODBC, jak również z różnego rodzaju usługami sieciowymi.
Poniżej przedstawiono kilka lekcji przeprowadzających użytkownika przez konfigurację różnego rodzaju połączeń.
Spis Treści
Podstawowa obsługa Modbus w systemie SCADA ICONICS
Oprogramowanie GENESIS64 posiada wbudowaną obsługę protokołu Modbus, bez konieczności dokupowania oddzielnych sterowników komunikacji. Tę lekcję pośwęcono komunikacji Modbus TCP/IP, lecz od wersji 10.96 naszego oprogramowania dodane zostały również opcje wymiany danych po Modbus RTU/ASCII za pośrtednictwem połączeń szeregowych. Dodatkowe możliwości opisaliśmy w kolejnej lekcji.
Konfiguracja Modbus TCP
|
Konfiguracja protokołu Modbus jest niezwykle prosta i szybka dzięki przygotowanym domyślnym konfiguracjom, które możemy wykorzystać podczas konfiguracji Genesis64. Konfiguracja protokołu Modbus w pakiecie Genesis64 składa się z 3 kroków:
Konfiguracja kanału dostępu do danych polega na wprowadzeniu adresu IP urządzenia, portu oraz liczby gniazd wykorzystywanych do komunikacji za pomocą modbus TCP. Dodatkowo można skonfigurować inne ustawienia połączenia takie jak, przekroczenie czasów odpowiedzi czy opóźnienie w odbieraniu i wysyłaniu danych. Typ urządzenia możemy skonfigurować ręcznie lub wybrać z listy już przygotowanych przykładów. W tym kroku ustalamy ilość danych które mogą być przesłane w jednej wiadomości. |
 |
Dodanie kompletnego połączenia polega na stworzeniu nowego obiektu w zakładce Adress Space, a następnie przypisaniu odpowiedniego typu urządzenia oraz kanału komunikacyjnego do stworzonego obiektu. Po skonfigurowaniu obiektu należy dodać zmienne, które chcemy odczytywać z urządzenia. Do dyspozycji mamy zmienne typu: cewka, wejście, rejestr wejść oraz rejestr pamięci, dodatkowo należy określić adres zmiennej w protokole modbus oraz typ zmiennej.
Tak przygotowane zmienne możemy archiwizować, przetwarzać, wyświetlać trendy oraz przygotowywać na ich podstawie alarmy. Zapraszamy do kontaktu na adres iconics@elmark.com.pl w celu uzyskania wyceny.
Rozszerzona obsługa Modbus w systemie SCADA ICONICS
Przeczytaj, aby dowiedzieć się, jakie funkcje dotyczące obsługi Modbus dodano do systemu SCADA ICONICS w jego najnowszej wersji - 10.96
Co nowego w komunikacji Modbus?
Już w poprzednich wersjach, oprogramowanie SCADA od ICONICS posiadało wbudowane narzędzie do komunikacji Modbus. Jego funkcjonalność obejmowała jednak tylko połączenia wykorzystujące model TCP/IP komunikacji. Co więcej, oprogramowanie SCADA - GENESIS64 mogło działać jedynie jako Master (Klient).
Począwszy od wersji 10.96, która ukazała się w grudniu 2019 roku, producent dodał szereg usprawnień. W ich skład wchodzą na przykład:
- obsługa komunikacji szeregowej - Modbus RTU (jako Master),
- możliwość pracy jako slave w komunikacji Modbus TCP/IP,
- obecność automatycznie generowanych zmiennych diagnostycznych, które dostarczają informacji na temat przebiegu wymiany danych.
Podstawowa funkcjonalność (SCADA jako Master dla Modbus TCP/IP) pozostała oczywiście bez zmian.
W dalszej części tego wpisu przeprowadzimy Cię przez szybką konfigurację każdego z typów połączeń. Jako urządzenie, z którym SCADA wymienia informacje, posłuży sterownik PLC serii Vision od firmy Unitronics.
PLC udostępnia dwie zmienne: całkowitą (16-bitową) oraz zmiennoprzecinkową - float (32-bitową). Nie będziemy jednak dalej wnikać w to, w jaki sposób adresuje się te zmienne w pamięci sterownika oraz, jak to przekłada się na adresy rejestrów Modbusowych. Skupimy się tylko na przykładowym nawiązaniu połączenia od strony oprogramowania SCADA.
Po szczegółowe informacje napisz do nas na adres e-mail: iconics@elmark.com.pl lub sterowniki@elmark.com.pl.
Ogólnie o Modbus w systemie SCADA ICONICS
Ppodstawach Modbus w oprogramowaniu GENESIS64 należy wiedzieć 3 rzeczy:
- musimy skonfigurować kanał komunikacji (Channel) - podajemy tam na przykład typ komunikacji (szeregowa, TCP/IP), adres IP urządzenia (lub numer portu COM)...
- definiujemy nowy typ urządzenia (lub edytujemy już istniejący) - taka definicja zawiera informacje m.in. o tym, czy urządzenie zamienia kolejność rejestrów 16-bitowych w 32-bitowym słowie lub wykonuje podobne operacje...
- dodajemy kompletne połączenie (Device) - przyporządkowujemy kanał do typu urządzenia, a następnie dodajemy pod nim zmienne, które chcemy odczytywać lub zapisywać.
SCADA ICONICS jako Modbus Master
Połączenie TCP/IP
Ten typ połączenia był już dostępny we wcześniejszych wersjach oprogramowania GENESIS64. SCADA jako Master, będzie zapisywać wartości dwóch rejestrów Modbus do pamięci sterownika. Na tym samym ekranie następował będzie również odczyt tych zmiennych w celu prezentacji bieżących efektów.
Połączenie szeregowe RS-232
Pierwszą z prezentowanych tu nowości w wersji 10.96 jest możliwość komunikacji szeregowej Modbus RTU lub ASCII po interfejsie RS-232. Od teraz nie potrzeba żadnego serwera OPC, w celu pośredniczenia w przesyle danych. Taką komunikację można ustawić bezpośrednio z poziomu systemu GENESIS64.
Wystarczy podpiąć urządzenie działające jako serwer Modbus do znanego portu COM maszyny z zainstalowanym oprogramowaniem od ICONICS.
Zmienne diagnostyczne dla komunikacji Modbus
Nowością w wersji 10.96 jest możliwość dodania zmiennych diagnostycznych do każdego połączenia Modbus. Zmienne generują się automatycznie i są takie same dla wszystkich urządzeń. Pozwalają śledzić przebieg komunikacji pokazując m.in. liczbę wykonań danych funkcji Modbus'owych, poprawnie zrealizowanych zapytań lub błędów.
Korzyści z wbudowanego narzędzia komunikacji Modbus
Co zyskujesz używając wbudowanego narzędzia Modbus TCP/IP lub RS232 zawartego w pakiecie GENESIS64? Przede wszystkim, upraszczasz infrastrukturę połączeń pomiędzy urządzeniami. Nie musisz stosować już serwerów OPC pośredniczących pomiędzy systemem SCADA, sterownikami PLC, jak również innymi urządzeniami. SCADA łączy się bezpośrednio ze sprzętem wykonawczym, dzięki czemu redukuje się czas spędzony na konfiguracji niepotrzebnych komponentów.
Pakiet GENESIS64 może ponadto obsłużyć natywną komunikację po: BACNet, OPC UA, WebServices, SNMP, MQTT oraz z wykorzystaniem baz danych (interfejsy ODBC i OLEDB). Sprawia to, że jesteś w stanie zbudować kompletną sieć połączeń jedynie za pomocą wbudowanych narzędzi.
Z drugiej strony, obecność zmiennych diagnostycznych pozwala Ci na monitorowanie przebiegu komunikacji w czasie rzeczywistym. Co więcej, istnieje możliwość prostego zbierania logów systemowych z narzędzia komunikacji Modbus - wykorzystując funkcję TraceWorX.
Po więcej informacji skontaktuj się z nami pod adresem e-mail: iconics@elmark.com.pl .
Pobieranie informacji z baz danych SQL do oprogramowania SCADA
Wpis ten będzie poświęcony narzędziu GridWorX, które jest częścią pakietu GENESIS64 i służy do łączności z bazami danych - w tym przypadku SQL.
Zawartość wpisu
Cały projekt będzie rozwiązaniem opierającym się o nawiązanie połączenia z bazą danych za pomocą GridWorX Server, którego konfiguracja odbywa się w module Workbench. W innych artykułach na tej stronie omówione zostaną sposoby efektywnej prezentacji pobranych informacji w module graficznym GraphWorX64 wykorzystując narzędzie do wizualizacji - GridWorX Viewer.
Program obsługujący bazy danych użyty przy tworzeniu projektu to Microsoft SQL Server Management Studio, instalowany wraz z pakietem GENESIS64.
Połączenie pomiędzy systemem SCADA i bazą SQL
|
Zakładając, że stworzona została już docelowa baza danych w programie SQL Server MS, należy dodać do listy jej właścicieli użytkownika, którego dane zostały wprowadzone podczas instalacji pakietu GENESIS64. Dzięki temu, baza ta będzie widoczna z poziomu Workbench. Użyta w projekcie baza danych nosi nazwę GridWorXTest, a całą procedurę dodania jej właściciela przedstawia poniższy filmik. |
Kolejnym krokiem jest odszukanie zakładki narzędzia GridWorX Server z połączeniami SQL w programie Workbench. Odpowiednia ścieżka to:
Workbench->DataConnectivity->Databases->SQLConnections
Następnie należy kliknąć PPM na tę zakładkę oraz wybrać opcję Add SQL Server Native Connection.
| Program wymaga od użytkownika aby wprowadzić nazwę nowo utworzonego połączenia oraz odpowiednią ścieżkę do bazy danych. Użytkownik nie musi tego robić sam ponieważ po wybraniu opcji Configure Connection dostępny staje się odpowiedni konfigurator. Opcja Test Connection pozwala na sprawdzenie, czy łączność z wybraną bazą danych została nawiązana pomyślnie. Cała procedura konfiguracji pokazana jest na filmie. |
Zdefiniowanie tabel dla narzędzia GridWorX Server
Następny krok to określenie źródła danych pod skonfigurowanym połączeniem. Jest to nic innego, jak określenie tabel z danymi generowanych przez GridWorX Server w oparciu o tabele pochodzące z wykorzystywanej bazy danych SQL. Użyta w projekcie baza danych GridWorXTest posiada dwie tabele: dbo.ProductionByShift oraz dbo.StationDowntime. Użytkownik ma możliwość stworzenia wielu źródeł danych będących realizacją dowolnego zapytania SQL.
Dostępne są dwa generatory zapytań SQL: zwykły i zaawansowany. Użytkownik ma też możliwość wprowadzenia zapytania ręcznie. Opcja ta jest dostępna po wybraniu zwykłego generatora (opcja: Configure Command) oraz zmianie typu zapytania na Custom.
Opcja Test Command wyświetla okno zawierające dane, które są generowane za pomocą wprowadzonego zapytania - pozwala to na sprawdzenie czy uzyskane efekty zgadzają się z zamierzonymi.
W polu Data Selection Schema dostępne są informacje na temat kolumn zawartych w tabeli bazy danych SQL, z którą następuje komunikacja oraz typu danych przechowywanych przez każdą kolumnę. Zaznaczona opcja Writable pozwala na późniejszą modyfikację danego pola z poziomu oprogramowania GENESIS64.
- Poniższy filmik prezentuje wykorzystanie zwykłego generatora zapytań SQL w celu wydobycia wszystkich danych z tabeli dbo.ProductionByShift.
- Poniższy filmik prezentuje wykorzystanie zaawansowanego generatora zapytań SQL; za jego pomocą zostaną wydobyte dane z tabeli dbo.StationDowntime. Tabela ta zwiera informacje na temat przestojów w pracy pewnych stacji. Informacje te zostaną posortowane alfabetycznie względem nazwy stacji, a następnie względem czasu przestoju.
Ważną rzeczą jest fakt, że nie trzeba tworzyć za każdym razem nowego źródła danych opierającego się o wykorzystanie tej samej tabeli, gdy zachodzi potrzeba wyświetlenia danych według tego samego szablonu. Zakładając, że użytkownik potrzebuje za każdym razem wydobyć z tabeli dane na temat przestojów w pracy jednej, określonej stacji, nie musi tworzyć kilkunastu źródeł danych i definiować dla każdego z nich osobnych zapytań.
Może on to zrobić raz, zastępując w zapytaniu wartość, która się zmienia (nazwę stacji), odpowiednim parametrem. Następnie, możliwe jest tworzenie "widoków" tych samych źródeł danych, dla każdego z nich definiując jedynie określoną wartość użytego parametru.
- poniższy filmik prezentuje w praktyce opisane wyżej rozwiązanie
GridWorX Server posiada dedykowane narzędzie służące do wyświetlania zgromadzonych przez niego danych w module graficznym GraphWorX.
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.
Bezpieczna komunikacja MQTT w systemie SCADA ICONICS
Z tego wpisu dowiesz się, w jaki sposób przebiega bezpieczna komunikacja pomiędzy systemem SCADA od ICONICS a brokerem MQTT.
Krótko o protokole MQTT
Protokół MQTT opiera się o architekturę publikacja-subskrypcja. Co to oznacza w praktyce? Urządzenia komunikujące się za jego pośrednictwem nie łączą się bezpośrednio ze sobą podczas komunikacji. W protokole MQTT występuje natomiast narzędzie pośredniczące w komunikacji - Broker. Jest to oprogramowanie, które pełni rolę serwera wiadomości.
Urządzenia klienckie (zarówno wysyłające, jak i odbierające dane) łączą się właśnie z Brokerem. Te, które wysyłają dane, publikują je na Brokerze (serwerze wiadomości) pod określonym "tematem" (ang. Topic). Klienci, którzy chcą pobrać informacje, łączą się natomiast z brokerem i podają temat, z którego docelowo nastąpi odczyt danych. Na tym właśnie polega wzorzec publikowania/subskrybowania wiadomości.
Widać więc, że urządzenie publikujące informacje nie może "wiedzieć", kto będzie ich odbiorcą, ani nawet ilu odbiorców istnieje. Tak samo, subskrybent nie posiada informacji zarówno na temat fizycznej lokalizacji urządzenia wysyłającego wiadomości, jak i jego adresu IP.
Komunikacja z wykorzystaniem MQTT nie jest jednak niebezpieczna, mimo pewnej anonimowości klientów. Bezpieczeństwo zapewnia tu oprogramowanie pełniące rolę Brokera. Może ono być skonfigurowane tak, aby przy każdym połączeniu, klient musiał podać swój unikatowy login i hasło. Ponadto, do każdego konta użytkownika przypisać można pewne dozwolone akcje, jak na przykład możliwość publikacji danych tylko pod konkretnymi tematami (Topic).
Oprócz uwierzytelniania użytkowników przy logowaniu, całą komunikację z brokerem można opcjonalnie zabezpieczyć z wykorzystaniem protokołu TLS - przy użyciu Certyfikatów X.509. Bezpieczna komunikacja oparta na certyfikatach oferuje zarówno uwierzytelnianie serwera, jak i klientów.
Ze względu na prostotę nawiązywania komunikacji pomiędzy dużą liczbą urządzeń jednocześnie oraz łatwą implementację, protokół MQTT wykorzystuje się szeroko w rozwiązaniach z zakresu Internet of Things, czy połączeniach maszyna-maszyna. Protokół ten jest wolniejszy od swoich tradycyjnych odpowiedników, lecz dzięki wbudowanym mechanizmom kontroli przepływu danych oferuje większą niezawodność.
MQTT i system SCADA od ICONICS
Przedstawione niżej działania przeprowadzono w systemie SCADA GENESIS64 w wersji 10.95 z zainstalowanym Update 5.
Komunikacja z MQTT jest realizowana zarówno za pomocą pełnej wersji systemu SCADA, jak i oprogramowania dla bram IoT od ICONICS - IoTWorX. Jako, że projekty dla bram IoT tworzy się i tak za pomocą GENESIS64, działania przedstawione dalej odnoszą się również do oprogramowania IoTWorX.
Możliwości oferowane przez GENESIS64 w zakresie komunikacji MQTT
Oprogramowanie GENESIS64 oferuje możliwość nawiązania połączenia z:
- usługą Azure IoT Hub (natywny broker platformy Azure),
- usługą Azure Event Hub (broker zdarzeń od Azure),
- usługami Platform Services na innych serwerach oprogramowania od ICONICS (natywne połączenia z innymi modułami ICONICS),
- dowolną aplikacją wykorzystującą architekturę REST,
- brokerami MQTT od dostawców trzecich.
Jeśli chodzi o ostatnie z powyższych, możliwe jest skonfigurowanie połączenia z wykorzystaniem protokołów:
- MQTT - standardowy protokół dla tego typu połączeń, działający domyślnie na porcie 1883;
- MQTTs - szyfrowana (bezpieczna) wersja powyższego protokołu wykorzystująca domyślnie port 8883;
- Web Sockets - technologia dwukierunkowej komunikacji w aplikacjach klient-serwer wykorzystująca jedno gniazdo TCP, domyślny port to 80;
- Secure Web Socket - technologia jak powyżej, z dodaną szyfrowaną transmisją (domyślny port: 443).
W celu określenia sposobu szyfrowania komunikacji dla bezpiecznych wersji powyższych protokołów, użytkownik może wybrać wersje 1.0, 1.1 oraz 1.2 protokołu TLS. Rekomendowana jest jednak tylko ta ostatnia, jako najbardziej bezpieczna.
Dodatkowo, oprogramowanie ICONICS umożliwia używanie certyfikatów X.509 w celu uwierzytelniania zarówno brokera, jak i klientów łączących się przez MQTT. Operator ma możliwość kontroli tożsamości brokera MQTT, z którym się łączy oraz aplikacji klienckich, które próbują się do tego brokera zalogować.
Ustawienia protokołu oraz szyfrowania dokonywane są jedynie w przypadku połączeń z brokerami MQTT od dostawców trzecich. W przypadku rozwiązań np. od platformy Azure, połączenie następuje z wykorzystaniem tzw. "Connection Strings" pozyskiwanych bezpośrednio od administratorów danego konta na platformie.
Dalsza część wpisu będzie dotyczyć połączenia GENESIS64 z dowolnym brokerem MQTT. Zakończy się ona krótkim filmem instruktażowym. Więcej informacji o integracji produktów od ICONICS z chmurą Azure można natomiast znaleźć w innych artykułach na tej stronie poświęconym rozwiązaniom IoT.
W jaki sposób dane wysyłane są do brokerów?
Pierwszą rzeczą, którą wykonuje użytkownik jest określenie listy danych do publikacji (Publish List). Wprowadza się tam szereg parametrów, jak na przykład częstość próbkowania i wysyłania danych, w celu dostosowania transmisji do indywidualnych wymagań. Następie operator określa, które zmienne system wyśle do brokera. Co więcej, dane można publikować okresowo, jak i po aktywacji określonego "triggera".
Ostatni krok to zdefiniowanie kompletnego połączenia (Publisher Connection), gdzie użytkownik podaje m.in. typ połączenia (MQTT, Azure, Platform Services), jego parametry, używany broker oraz temat, pod którym udostępnia się dane.
Jeśli wymiana danych zachodzi pomiędzy aplikacjami ICONICS, istnieje możliwość zaznaczenia opcji kompatybilności z tego rodzaju klientami. Wtedy system SCADA udostępni do wyboru 4 domyślne enkodery danych (binarne lub JSON). W przypadku publikacji/odbioru danych od zewnętrznych systemów, możliwe jest zbudowanie własnego enkodera JSON w osobnej zakładce w Workbench.
Przy publikacji danych do brokerów MQTT lub usług Azure IoT Hub, wysyłane informacje są czasu rzeczywistego. Przy wykorzystaniu połączenia typu Platform Services (np. z modułem Hyper Historian) procującym na osobnym serwerze, możliwe jest również utworzenie list publikacji z danymi historycznymi lub pochodzącymi z narzędzi analitycznych od ICONICS.
Odbiór danych z brokera MQTT
Odczyt danych z brokera MQTT następuje na podobnych zasadach, co ich publikowanie. To, co użytkownik musi wykonać, to dodanie odpowiedniej subskrypcji (Subscriber Connection). Opcje dotyczące kompatybilności z klientami ICONICS, czy nazwy brokera są analogiczne jak wcześniej. Z oczywistych przyczyn użytkownik nie wybiera tu np. listy publikacji.
Odpowiednie konfiguracje przedstawia krótki film pokazowy zamieszczony na końcu tego wpisu.
Przykład projektu transmisji po MQTT
Oprogramowanie SCADA od ICONICS będzie łączyć się z popularnym brokerem MQTT - Mosquitto. Działa on na osobnej maszynie pod systemem z rodziny Linux/Ubuntu.
Obydwa połączenia (publikacji i subskrypcji) realizuje jedna aplikacja SCADA. Co więcej, połączenia nawiązywane są z wykorzystaniem:
- uwierzytelniania użytkownika za pomocą loginu i hasła,
- uwierzytelniania serwera i szyfrowania transmisji przy użyciu certyfikatów X.509.
Pierwszym krokiem jest oczywiście instalacja i odpowiednia konfiguracja brokera MQTT Mosquitto na zdalnej maszynie. Nie jest to jednak działanie charakterystyczne dla systemu ICONICS, więc nie zostanie tutaj opisane. Wiele instrukcji na ten temat można znaleźć natomiast w internecie.
Do tworzenia własnych certyfikatów w projekcie użyto środowiska openssl. Certyfikaty wykorzystane podczas tego projektu podpisano przez własny lokalny "Urząd Certyfikacji", tak więc rozwiązanie to nadaje się do lokalnych systemów komunikacji, np. dla aplikacji działających w ramach firmy. O tym, jak wdrożyć wykorzystanie certyfikatów do serwera Mosquitto można również przeczytać w artykułach zamieszczonych w internecie.
Jak działa uwierzytelnianie serwera w tym przypadku? Wykorzystując certyfikaty oraz dane logowania klientów do brokera, proces ustanawiania połączenia jest dwustopniowy. Najpierw, oprogramowanie GENESIS64 prosi broker o wysłanie jego certyfikatu. Po jego otrzymaniu, sprawdza go poprzez weryfikację prawdziwości podpisu "Urzędu Certyfikacji" widniejącego na tym certyfikacie. Do tego procesu potrzebna oczywiście jest wcześniejsza instalacja samego certyfikatu "Urzędu Certyfikacji", w katalogu zaufanych urzędów w konsoli MMC Windows. Jeśli oprogramowanie GENESIS64 potwierdzi prawdziwość certyfikatu, wyśle do serwera swoje dane logowania - login i hasło. Jeśli dane te będą poprawne, serwer zezwoli aplikacji SCADA na publikację danych pod określonym tematem.
Nawiązywanie połączenia w celu subskrypcji informacji z brokera przebiega w analogiczny sposób.
Bezpieczny MQTT w systemie SCADA - konfiguracja
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.
OPC UA w systemie SCADA
Wpis ten przedstawia sposób komunikacji oprogramowania GENESIS64 ze sterownikiem PLC, na którym działa serwer OPC UA.
Opis nawiązywania połączenia pomiędzy wyżej wymienionymi komponentami zostanie omówiony na przykładzie aplikacji, w której sterownik PLC zapala i gasi diodę LED z częstotliwością zmienianą z poziomu oprogramowania SCADA.
Ustanowienie komunikacji z PLC
Posiadając odpowiednio skonfigurowany serwer OPC UA udostępniający zmienne należące do programu kontrolera, należy upewnić się, jak brzmi jego identyfikator URI. Jest to łańcuch znaków umożliwiający identyfikację zasobów w sieci. Może określać on nazwę zasobu - wtedy definiowany jest jako URN, lub jego adres - URL.
W przypadku sterownika BEDROCK jest to adres dostępu URL do jego serwera OPC UA i składa się on z IP nadanego kontrolerowi w obrębie połączenia lokalnego z komputerem oraz odpowiedniego portu (dla kontrolerów BEDROCK domyślny port to 4840).
Przykład identyfikatora URI, wykorzystywanego w projekcie: opc.tcp://192.168.100.100:4840.
Aby uzyskać dostęp do danych tego serwera z poziomu oprogramowania GENESIS64, należy w module Workbench dodać symbolizujące go połączenie. Dokonuje się tego przechodząc kolejno do zakładek:
PlatformServices -> FrameWorX -> NetworkSettings -> OPC UA Network
W ostatniej lokalizacji należy nazwać konfigurowane połączenie i wprowadzić odpowiedni identyfikator URI, aby uzyskać efekt podobny jak na zdjęciu poniżej.
Po wprowadzeniu odpowiednich ustawień powinno być możliwe wyszukanie zmiennych należących do serwera OPC w panelu "Data Browser", po prawej stronie okna Workbench.
Na potrzeby projektu dodano do serwera jedną zmienną wykorzystywaną w programie sterownika. Symbolizuje ona okres czasu mierzony w milisekundach, w którym dioda pozostaje kolejno w stanie zapalonym i zgaszonym.
Prezentacja rezultatów
Zmiana nastawy sterownika odbywać się będzie z poziomu graficznego interfejsu stworzonego w module wizualizacji pakietu GENESIS64, jakim jest GraphWorX. Interfejs składa się z "suwaka" będącego standardowym modelem 2D wchodzącym w skład bibliotek modeli GraphWorX oraz z pola wyświetlającego aktualną wartość nastawy.
| Do "suwaka" przypisano odpowiednią zmienną znalezioną za pomocą wyszukiwarki danych ''Data Browser". Wyszukiwarka ta wygląda identycznie dla modułów Workbench i GraphWorX. Wspomniana zmienna znajduje się pod elementem BedrockConnection (por. zdj. 1). |
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.
Bezpieczne połączenie z OPC UA
Co należy zrobić, aby nawiązać bezpieczne połączenie pomiędzy oprogramowaniem od ICONICS a serwerem OPC UA? Wykorzystanie certyfikatów X.509
Używane zasoby
W tym przypadku zaprezentowano konfigurację bezpiecznego połączenia oprogramowania SCADA od ICONICS - GENESIS64 z serwerem OPC UA działającym na sterowniku PLC od Unitronics.
Wersja oprogramowania SCADA, na której przygotowano wpis to 10.95. Jest to standardowa instalacja pakietu GENESIS64 od ICONICS.
Jeśli chodzi o sterownik PLC - wykorzystywana jest tu seria UniStream od Unitronics. Na sterowniku PLC działa standardowy serwer OPC UA. Przy nawiązywaniu połączenia z klientami "legitymuje" się on własnym certyfikatem "X.509" w formacie DER. Co więcej, jest to certyfikat stworzony poza sterownikiem, który następie zaimportowano do PLC, podczas jego konfiguracji.
Tego, jak skonfigurować serwer OPC UA na sterowniku PLC od Unitronics wykorzystując własny certyfikat, dotyczy osobny wpis na stronie Elmark Automatyka, w sekcji poświęconej tym urządzeniom.
Bezpieczne połączenie z OPC UA - konfiguracja
Zakładając, że serwer OPC UA działa już na sterowniku PLC oraz, że posiadamy certyfikat tego serwera (bez klucza prywatnego) na dysku komputera, przystępujemy do konfiguracji oprogramowania SCADA.
Definicja połączenia z OPC UA
Aby wykonać to zadanie, należy otworzyć program do konfiguracji GENESIS64 - Workbench. Tam, w drzewku "Project Explorer", należy odszukać element "OPC UA Network". Znajduje się on w lokalizacji pokazanej na zdjęciu.
|
Po wybraniu wspomnianego elementu, należy dodać koleją pozycję na liście połączeń z serwerami OPC UA. Użytkownik musi wprowadzić co najmniej:
|
 |
Kolejne pola służą między innymi do:
- podania zapasowego adresu serwera - "Secondary Endpoint URI" (SCADA połączy się z nim, jeśli pierwsza lokalizacja będzie nieosiągalna);
- wprowadzenie nazwy użytkownika i hasła ("Username", "Password") w przypadku, gdy istnieje potrzeba dodatkowego logowania na serwer OPC UA.
W tym przypadku serwer OPC UA nie wymaga dodatkowego uwierzytelniania za pomocą loginu i hasła, więc pola te pozostawiono puste.
Dodanie certyfikatu do listy zaufanych
Serwer danych działający na sterowniku PLC skonfigurowano tak, by udowadniał swoją tożsamość za pomocą samo-podpisanego certyfikatu w formacie DER. Aby oprogramowanie SCADA "rozróżniało" ten serwer jako taki, któremu należy ufać, należy dodać jego certyfikat do odpowiedniego katalogu zaufanych systemu Windows.
| Można to zrobić klikając dwukrotnie LPM na certyfikat i wybierając opcję "Zainstaluj Certyfikat". Odpowiedni katalog nosi nazwę "UA Applications", sama instalacja przebiega natomiast dla komputera lokalnego. Prawidłowość importu certyfikatu można następnie sprawdzić, otwierając konsolę MMC Windows. | Instalacja certyfikatu serwera OPC |
W celu dokończenia konfiguracji, należy jeszcze skopiować powyższy certyfikat do następującej domyslnej lokalizacji:
C:\ProgramData\ICONICS\pki\trusted\certs
Wyłączenie akceptowania dowolnego certyfikatu przez FrameWorX
FrameWorX jest komponentem odpowiadającym za komunikację w obrębie systemu SCADA ICONICS oraz połączenia z zewnętrznymi aplikacjami. W tym przypadku FrameWorX pełni rolę klienta OPC UA, który łączy się z serwerem działającym na sterowniku PLC.
| Domyślnie, FrameWorX zaakceptuje każdy certyfikat takiego serwera. Aby wdrożyć bezpieczną komunikację, należy oczywiście zmienić to ustawienie. Dokonuje się tego w oknie "Platform Services Configuration", które jest dostępne z poziomu Workbench, lub po wyszukaniu w menu Start. |  |
Całość polega na wpisaniu "False" w pole opcji "AcceptAnyServerCertificate".
Wyświetlanie danych z serwera OPC UA
Wartości zmiennych udostępnianych przez serwer OPC UA (w tym przypadku działający na sterowniku PLC) są dostępne od tej pory dla wszystkich komponentów oprogramowania GENESIS64.
W najprostszy sposób można je wyświetlić za pomocą narzędzia Data Explorer.
|
Film pokazuje, w jaki sposób wyszukać dane w oknie Data Explorer oraz to, jak certyfikat FrameWorX'a jest akceptowany z poziomu panelu sterownika PLC. Dla sterowników od Unitronics konieczne jest ręczne akceptowanie certyfikatów klientów. Aby prezentacja przebiegała wygodniej, posłużono się programem - klientem VNC, w celu pokazania ekranu HMI sterownika na monitorze komputera. |
Prezentacja odczytu danych z serwera OPC UA w systemie SCADA |
Informacje dodatkowe
W przypadku problemów z nawiązaniem połączenia należy upewnić się kilku rzeczy.
Pierwszą z nich jest działanie usługi OPC UA Local Discovery Server.
Druga, to natomiast odblokowanie odpowiednich portów dla zapory ogniowej. W tym przypadku konfigurację należy przeprowadzić jedynie dla firewall'a działającego na komputerze lokalnym.
Jeśli wyszukiwanie serwerów OPC następuje poprzez rozleglejszą sieć, której ruchem zarządzają osobne router'y, wtedy również i one podlegają konfiguracji.
Dla prostej aplikacji wykorzystywanej tutaj, należy upewnić się, że ruch nie jest blokowany na porcie 48020.
Elmark Automatyka udostępnia wersję demo oprogramowania GENESIS64 (obsługującą rozproszoną archiwizację), w celu osobistego przetestowania funkcjonalności pakietu. Skontaktuj się z nami na iconics@elmark.com.pl w celu otrzymania wersji testowej lub oferty handlowej.
Produkty powiązane
Skontaktuj się ze specjalistą Elmark
Masz pytania? Potrzebujesz porady? Zadzwoń lub napisz do nas!
