Szkolenie: WNT 6: Wymiana danych pomiędzy standardami OPC-SQL-XML

Chciałbym wszystkich zaprosić na szkolenie, które będę współprowadził. Dotyczyć ono będzie zagadnień związanych z technologią OPC (otwartego standardu komunikacyjnego stosowanego w automatyce przemysłowej i informatycznych systemach służących do integracji zarządzania procesem i biznesem), komunikacji z procesem technologicznym oraz praktycznym zastosowaniem produktów z rodziny CommServer .

Tym razem hasłem przewodnim spotkania będzie „Wymiana danych pomiędzy standardami OPC-SQL-XML oraz Integracja systemów GIS z telemetrią”.

Oprócz ogólnych zagadnień dotyczących technologii OPC poruszone zostaną zagadnienia dotyczące:

• Modeli integracji oraz przyczyn jej wykorzystania.
• Metod pozyskiwania danych z procesu.

Więcej informacji na temat szkolenia jest dostępnych na wortalu CommServer.

http://www.commsvr.com/OPCWorkshops.aspx

Podsumowanie dla artykułu na temat infrastruktury komunikacyjno-usługowej OPC Unified Architecture (OPC UA)

Mam nadzieję, że w tym artykule udało mi się przybliżyć czytelnikom sposoby komunikacji i usługi dostępne w OPC Unified Architecture. Wydaje mi się, że dla pewnych czytelników artykuł mógł okazać się zbyt ogólny, dla innych zbyt szczegółowy. Zapraszam do komentowania lub wymiany korespondencji poprzez email, abym mógł pewne elementy przedstawić w inny, może jaśniejszy sposób.

W ramach podsumowania chciałbym wymienić najważniejsze informacje, które są istotne dla opisywanej infrastruktury komunikacyjno-usługowej:

1. Specyfikacje OPC UA definiują usługi w sposób abstrakcyjny, mapowanie na konkretną technologię komunikacyjną odbywa się niezależnie od definicji usługi, przestrzeni adresowej i modelu informacji.

2. Specyfikacje OPC UA przedstawiają aktualnie dwie technologie przesyłowe:

• Web Serwisy oparte o protokół HTTP/HTTPS i SOAP

• binarne strumienie danych przesyłane poprzez protokół TCP

3. Specyfikacje OPC UA przedstawiają dwa sposoby kodowania

• binarne (opisane w specyfikacji)

• XML

4. Zabezpieczenia wbudowane w OPC UA wykorzystują mechanizmy WS- Secure Conversation (WS-SC) lub mechanizmy opracowane na bazie WS-SC i TLS (w przypadku binarnych strumieni danych)

5. Mechanizm publikowania dla elementów monitorowanych subskrypcji umożliwia optymalizację komunikacji i wywołania pseudo-asynchroniczne.

   (To tylko jedna z części artykułu zobacz pozostałe: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, autor: Maciej Zbrzezny)

Mechanizm publikowania w OPC Unified Architecture (czyli jak zrealizować mechanizm asynchroniczny w synchronicznym świecie OPC UA).

W poprzedniej części opisałem ustawienia subskrypcji i elementów monitorowanych, teraz kontynuując przytoczony przykład chciałbym przybliżyć mechanizm publikowania.

Po stworzeniu subskrypcji i elementów monitorowanych oraz ustawieniu wszystkich potrzebnych parametrów, klient może przejść do obsługi mechanizmu publikowania. Zagadnienie mogłoby się wydawać proste: klient wywołuje funkcję Publish() (jak na poniższym rysunku), ale tak na prawdę wykorzystywana jest bardziej skomplikowana maszyneria.

W architekturach zorientowanych obiektowo (SOA) typowe jest, to że klient łączy się z serwerem, najczęściej jest to prosta operacja. Natomiast niespotykana jest (i często niemożliwa) sytuacja, w której to serwer nawiązuje połączenie do klienta, a przecież z takim mechanizmem mieliśmy do czynienia w subskrypcjach OPC Classic (opartych o technologię DCOM). Pamiętajmy jednak, że takie połączenia były co prawda doskonałym rozwiązaniem usprawniającym komunikację (oferując możliwość uzyskiwania odpowiedzi w sposób asynchroniczny), ale jeśli chodzi o konfiguracje połączenia to były bolączką tamtej specyfikacji, a powodów dla których takie połączenie mogło być nie możliwe bywało wiele (np. firewall, NAT lub np. problem związany z uprawnieniami). Jak więc są przysyłane powiadomienia o zdarzeniach czy nowych danych? Otóż klient używa funkcji Publish, wtedy serwer zbiera dane konieczne do wysłania i wysyła je. Następnie klient wykonuje Publish raz jeszcze. Teraz serwer (jeśli nowe dane się nie pojawiły) czeka z odpowiedzią, aż będzie miał gotowe dane. Oczywiście takie oczekiwanie nie może trwać wiecznie, a czas oczekiwania powinien być zależny od wybranego sposobu transmisji, jednak jeśli nowe dane się nie pojawią serwer powinien odpowiedzieć wiadomością KeepAlive. W ten sposób serwer potwierdza, że „żyje” i odpowiada. KeepAlive jest po prostu pustą odpowiedzią na wywołanie Publish. Metoda Publish jest więc pewnego rodzaju tokenem, który jest przesyłany od klienta do serwera i serwer dzięki niemu wie że może przy pomocy tokenu przesłać do klienta jakieś dane. Oczywiście klient musi czekać z kolejnym wywołaniem Publish, dopóki nie otrzyma odpowiedzi na poprzedni Publish. Taka strategia sprawdza się oczywiście w przypadku, gdy sieć (medium) poprzez którą przesyłamy dane jest szybka, a czas przesyłania jest bardzo krótki. Reasumując ta metoda działa więc jak pewnego rodzaju callback (na rysunku nazwane: "Quasi Callback"), chociaż oczywiście to klient wysyła token do serwera, umożliwiając serwerowi przesłanie danych razem z tokenem.

(To tylko jedna z części artykułu zobacz pozostałe: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, autor: Maciej Zbrzezny)

Subskrypcje (OPC UA) – przykładowe ustawienia i wykorzystanie

Wcześniej przedstawiłem co to są subskrypcje i jakie funkcje można na nich wywoływać. Teraz przeanalizujmy przykład, który pomoże zrozumieć jakie ustawienia są ważne dla tworzonych subskrypcji.

Załóżmy że jesteśmy połączeni do serwera, mamy zestawiony bezpieczny kanał i ustanowioną sesję. Stworzyliśmy subskrypcję i znane są nam (np. poprzez przeglądanie lub zapytania (Browse lub Query)) identyfikatory węzłów, z których danymi jesteśmy zainteresowani. Teraz tworzymy elementy monitorowane.

Następnie ustalamy tryb monitorowania, mamy tutaj do dyspozycji:

• DISABLED – element, jest monitorowany, ale nie jest próbkowany lub wyznaczany(evaluated), a powiadomienia nie są generowane lub kolejkowane. Raportowanie powiadomień jest wyłączone (Notification reporting is disabled).

• SAMPLING – element, jest monitorowany jest próbkowany lub wyznaczany, a powiadomienia są generowane i kolejkowane. Raportowanie powiadomień jest wyłączone (Notification reporting is disabled).

• REPORTING– element, jest monitorowany jest próbkowany lub wyznaczany, a powiadomienia są generowane i kolejkowane. Raportowanie powiadomień jest włączone (Notification reporting is enabled).

Ponadto dla każdego elementu monitorowanego ustawiamy:

• Częstotliwość próbkowania (Sampling Interval)

• Filtrowanie (np. Deadband) (filtrowanie ustawiamy, gdy nie jesteśmy zainteresowani każdą zmianą)

• Długość kolejki (Queue Size) (można wyspecyfikować, ile ostatnich zmian chcemy zachowywać)

• Ustawienie, czy chcemy pomijać najstarsze dane (Discharge Oldest)

  (To tylko jedna z części artykułu zobacz pozostałe: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, autor: Maciej Zbrzezny)

Wyszukiwarka

CodeProject: Artykuł na temat tworzenia etykiet tekstowych dla scen 3D

Wczoraj opublikowałem na portalu CodeProject artykuł pod tytułem:

"WPF: Creation of Text Labels for 3D Scene"

Artykuł dotyczy zagadnienia tworzenia napisów dla scen 3D tworzonych w oparciu o WPF. Opisuję w nim dwa podejścia, które można wykorzystać podczas generowania grafiki z takimi napisami. Artykuł jest dostępny na razie w języku angielskim, ale postaram się opublikować tutaj na blogu również jego wersję w języku polskim.

Zapraszam wszystkich do lektury!

http://www.codeproject.com/KB/WPF/WPF_Text3D.aspx

dotnetomaniak.pl

Ostatnio zauważyłem, że dużo wejść na mojego bloga pochodzi z serwisu dotnetomaniak.pl. Po sprawdzeniu co to jest, okazuje się, że jest to nowa inicjatywa, której autorzy chcą "zbudować silną społeczność .NET w Polsce". To miejsce, w którym znajdują się linki do artykułów poświęconych technologii .NET. W serwisie tym pojawiły się też dwa moje (pochodzące z tego bloga) artykuły i stąd wejścia na mój blog. Chciałbym w tym miejscu podziękować osobom które dodały linki do moich artykułów i jednocześnie zaprosić moich czytelników do odwiedzenia serwisu dotnetomaniak.pl. Sam już przeglądałem artykuły tam zgromadzone i niektóre prezentują się interesująco.

http://dotnetomaniak.pl/

Subskrypcje w OPC Unified Architecture (OPC UA subscriptions)

Opisane wcześniej funkcjonalności można zakwalifikować do warstwy sesji (wystarczy tylko zestawiona sesja by z nich korzystać), ale gdy klient potrzebuje dostępu (zapis lub odczyt) do pewnych danych w sposób ciągły należy wykorzystać mechanizm określany mianem subskrypcji.

Subskrypcje są tworzone po nawiązaniu sesji i w ramach określonej sesji, ale mogą być również transferowane do innej sesji. Subskrypcje można tworzyć (CreateSubscription), modyfikować (ModifySubscription, zmieniane są parametry subskrypcji), transferować (TransferSubscription, wykorzystywane gdy chcemy przenieść subskrypcję do innej sesji, można np. stworzyć subskrypcję, odłączyć się do serwera, a po ponownym połączeniu , uzyskać dostęp do utworzonej wcześniej subskrypcji), usuwać (DeleteSubscription). Po utworzeniu subskrypcji klient musi określić jakimi danymi jest zainteresowany. W tym celu tworzy on tzw. elementy monitorowane. Mogą to być dane, zdarzenia lub inne obiekty. Klient ma możliwość ich tworzenia (CreateMonitoredItems), modyfikowania(ModifyMonitoredItems), usuwania (DeleteMonitoredItems), określania trybu monitorowania (SetMonitoringMode) oraz ustalania triggerów (SetTriggering). Trigery są używane do przysyłania danych w sposób sterowany zdarzeniowo, np. zmiana wartości danego elementu powoduje przysłanie wartości elementów należących do pewnej grupy. Są jeszcze funkcje dot. publikowania, ale o nich szczegółowo będzie w jednej z kolejnych części. W następnej części pojawi się przykład, który pokaże pewne możliwości ustawień dla subskrypcji.

(To tylko jedna z części artykułu zobacz pozostałe: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, autor: Maciej Zbrzezny)

Połączenie, kanały i sesje w OPC Unified Architecture (OPC UA)

W poprzedniej części opisałem jak należy odnaleźć serwer, z którym można się połączyć. Teraz zajmiemy się ustanowieniem połączenia.

W celu ustanowienia połączenia na początku należy utworzyć kanał. Kanał tworzony jest z wykorzystaniem wybranej infrastruktury komunikacyjnej i sposobowi kodowania. Wyboru infrastruktury komunikacyjnej dokonuje klient z pośród dostępnych i obsługiwanych przez serwer. W tej warstwie dostępne są dwie proste procedury jedna do otwierania druga do zamykania (OpenSecureChannel, CloseSecureChannel). Otwierając kanał tworzymy drogę bezpiecznej komunikacji.

Po utworzeniu kanału można wykorzystywać funkcje ze zbioru session. Sesja działa w oparciu o utworzony wcześniej kanał, w celu połączenia sesję należy najpierw utworzyć (CreateSession), a później aktywować (ActivateSession).

Później można wykorzystywać operacje z innych zbiorów usług, np. przeglądanie przestrzeni adresowej (Browse lub z wykorzystaniem funkcjonalności przeglądania krokowego – BrowseNext oraz tłumaczenie ścieżki przeglądania na unikalny identyfikator danego węzła: TranslateBrowsePathsToNodeIds), odczytywanie (Read, HistoryRead) lub zapisywanie danych (Write, HistoryUpdate) (operacje te dotyczą zarówno danych aktualnych i historycznych). Można wysyłać zapytania do przestrzeni adresowej (QueryFirst, QueryNext ze zbioru Query Service). Dostępne są funkcje do zmiany struktury przestrzeni adresowej (dodawanie – AddNodes/AddReferences, usuwanie – DeleteNodes/DeleteReferences, operacje te pozwalają na zmianę węzłów oraz referencji i należą do zbioru NodeManagement Service) Rejestracja (RegisterNodes) lub wyrejestrowywanie(UnregisterNodes) węzłów, pozwalająca serwerowi alokować zasoby. Np. przed wywołaniem jakiejś funkcji możemy poinformować serwer, że będziemy używać danego węzła, a on go zarejestruje. Nie trzeba tego wykorzystywać ale w ten sposób można przeprowadzić optymalizację.

(To tylko jedna z części artykułu zobacz pozostałe: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, autor: Maciej Zbrzezny)

Mechanizm odkrywania w OPC Unified Architecture (OPC UA Discovery)

OPC Unified Architecture oparte jest o architekturę klient serwer, w której klient nawiązuje połączenie do serwera. Oczywiście, przed nawiązaniem połączenia, konieczne są informacje mówiące o tym jak odnaleźć serwer, jaki jest jego adres, jakie są parametry połączenia, przy pomocy jakiej infrastruktury komunikacyjnej można nawiązać połączenie. W tej sekcji zostaną przedstawione mechanizmy odnajdywania serwera przez klienta OPC UA.

W pierwszym kroku zastanówmy się jakie są typy aplikacji bazujące na technologii OPC UA? Są to klienci, serwery i serwery odkrywania (Discovery Servers). Serwery umożliwiają dostęp do danych i zdarzeń z systemu. Serwery Discovery udostępniają natomiast informacje o serwerach OPC UA dostępnych w sieci. Wśród serwerów Discovery mogą być takie, które udostępniają informacje o serwerach uruchomionych na lokalnej maszynie (Local Discovery Server, LDS) lub dostępnych w sieci (Global Discovery Server). Klienci natomiast konsumują dane udostępniane przez serwery. Należy pamiętać, że niektóre aplikacje mogą pełnić funkcje zarówno klienta, jak i serwera. Ogólną zależność pomiędzy typami aplikacji przedstawia rysunek:

Klient przed nawiązaniem połączenia najczęściej wyszukuje dostępne serwery z wykorzystaniem usług odkrywania (Discovery)(klient nie musi wyszukiwać serwera, jeśli ma odpowiednio skonfigurowane wszystkie parametry połączenia). W ten sposób klient pozyskuje listę serwerów, łącznie ze wszystkimi parametrami połączenia (tzw. ustawieniami edpointu). Taki mechanizm podobny jest do znanego z OPC Classic (bazującego na DCOM) serwisu OPCEnum. Oczywiście mechanizm Discovery w OPC UA oferuje znacznie więcej niż wysłużony OPCEnum. Klient otrzymuje informacje na temat adresu (IP) serwera, portu przy pomocy którego powinien nawiązać połączenie, infrastruktury komunikacyjnej (np. tcp, http, https), czy kodowania (xml, binarne, szyfrowane). Ponadto dzięki serwerom zarejestrowanym globalnie, możliwe jest pozyskiwanie informacji na temat serwerów dostępnych w całej sieci, a nie tylko na lokalnej maszynie.

(To tylko jedna z części artykułu zobacz pozostałe: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, autor: Maciej Zbrzezny)