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)

Usługi w OPC Unified Architecture (OPC UA service sets)

OPC Unified Architecture specyfikuje pewien abstrakcyjny opis usług (głównie w specyfikacji OPC UA części 4). Opis usług nie jest związany z żadnym konkretnym sposobem komunikacji lub technologią komunikacyjną. W poprzednich częściach przedstawiłem jak usługi są mapowane na odpowiednią infrastrukturę komunikacyjną, a teraz przyjrzymy się jakie to usługi oferuje OPC Unified Archtecture.

Dostęp do danych zawartych w serwerze jest zapewniony przez tzw. zbiory usług (ang. service sets). OPC UA specyfikuje następujące zbiory usług:

• zbiór Discovery Service - służy do znajdywania(odkrywania) serwera w sieci. Znajdowanie punktu przyłączenia (endpointu), czyli informacji jak podłączyć się do serwera,

• zbiór Secure Channel Service - niskopoziomowe i zależne od wykorzystywanego protokołu usługi mające na celu utworzenie (otwarcie) lub zamknięcie bezpiecznego kanału do przesyłania danych,

• zbiór Session Service - służy do tworzenia i zamykania sesji,

• zbiór Attribute Service – zajmuje się odczytem i zapisem danych (aktualnych bądź historycznych),

• zbiór Subscription Service – wykorzystywany do zarządzania subskrypcjami,

• zbiór Monitored Item Service – odpowiedzialny za zarządzenie elementami monitorowanymi w subskrypcjach,

• zbiór View Service – służy do przeglądania przestrzeni adresowej,

• zbiór Query Service – ma na celu tworzenie zapytań o przestrzeń adresową,

• zbiór Node Management Service – stosowany do zmieniania struktury i referencji w przestrzeni adresowej,

• zbiór Method Service – odpowiedzialny za wywoływanie i zarządzanie metodami (programami).

Następne części pokażą wykorzystanie usług z wybranych zbiorów.

Więcej na temat zbiorów usług OPC UA można również przeczytać w ebook’u pod adresem:

http://www.commsvr.com/UAModelDesigner/Index.aspx

(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)

Kodowanie i mapowanie w OPC Unified Architecture (OPC UA)

Specyfikacje OPC Unified Architecture (OPC UA) definiują warstwy, które izolują bazową funkcjonalność od wykorzystanej infrastruktury transportowej. Takie podejście niesie za sobą konieczność specyfikacji kodowania przesyłanych informacji i mapowania usług na odpowiednią infrastrukturę komunikacyjną. Mapowanie i kodowanie jest opisane jest w szóstej części specyfikacji OPC UA.

Aktualnie specyfikacja definiuje dwa sposoby kodowania:

• tekstowe oparte o XML

• binarne UA

Dodatkowo, przewidziane są dwa mapowania usług na warstwę transportową:

• TCP – strumień binarny TCP

• SOAP Web Services over HTTP – usługi internetowe wykorzystujące protokół SOAP i HTTP do transportu.

Wymienione tutaj sposoby przesyłania i kodowania danych pozwalają na stworzenie czterech dróg komunikacyjnych (przedstawionych na rysunku poniżej). Klient lub serwer OPC UA w przypadku gdy wpierają one więcej niż jedną drogę mogę one dokonać wyboru, którą drogą ma się odbywać komunikacja. Na wybór powinny mieć wpływ czynniki takie jak: wydajność, bezpieczeństwo (szyfrowanie), urządzenia pośredniczące (np. firewalle) lub inne.

Pierwsza droga (na rysunku pierwsza z prawej strony) bazuje na strumieniach TCP, binarnym kodowaniu oraz zabezpieczeniach wbudowanych w OPC UA (które są rozwiązaniem zaadaptowanym specjalnie dla OPC UA i są podobne do tych w specyfikacji WS-Secure Conversation oraz TLS). Wykorzystanie binarnych strumieni danych pozwala na stworzenie wydajnego sposobu przesyłania danych.

Druga droga oparta jest o kanał bazujący na HTTP lub HTTPS, protokół SOAP, w którym dane przesyłane są jako zakodowane binarnie. Do ustanowienia bezpiecznego kanału wykorzystywane są zabezpieczenia stworzone specjalnie dla OPC UA (podobnie jak w przypadku pierwszej drogi).

Trzecia droga oparta jest o kanał bazujący na HTTP lub HTTPS, protokół SOAP, w którym dane przesyłane są jako zakodowane binarnie.. Do ustanowienia bezpiecznego kanału wykorzystywane są specyfikacje WS-Secure Conversation . Droga druga i trzecia są oczywiście do siebie bardzo podobne i różnią się metodami zabezpieczeń.

Ostatnia droga (na rysunku pierwsza z lewej strony) bazuje o transport bazujący na HTTP lub HTTPS, protokół SOAP, zabezpieczenia bazujące na specyfikacji WS-Secure Conversation i kodowanie XML, czyli po prostu Web Serwisy.

Osoby, które mają wątpliwości odnośnie wydajności rozwiązań bazujących na Web Serwisach mogą wybrać kodowanie binarne oparte o TCP, aby zapewnić maksymalną szybkość przesyłu danych. Warto zauważyć że w celu zapewnienia możliwości przesyłania danych z OPC UA przez różnego rodzaju zapory (firewalle) lepiej posługiwać się rozwiązaniami bazującymi na HTTP/SOAP. Aby zapewnić maksymalną prędkość przesyłu danych z jednoczesnym wykorzystaniem SOAP, OPC UA przewiduje również przesyłanie zakodowanych binarnie danych przez kanał HTTP/SOAP. W tym przypadku można wykorzystać zabezpieczenia wbudowane w OPC UA jak i oparte o WS-Secure Conversation. (Na wcześniejszym rysunku te dwa sposoby przedstawione są dwoma strzałkami po środku).

(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)

Architektura komunikacyjna OPC Unified Architecture (OPC UA)

W poprzedniej części artykułu opisane zostało podejście, przy pomocy którego abstrakcyjne opisane usługi mapowane są na określone technologie przesyłu danych i wywołań. Przyjrzyjmy się więc architekturze takiego rozwiązania.

Na samym dole znajdują się różne źródła danych, do których ma dostęp serwer OPC UA. Serwer OPC UA dysponuje pewnym interfejsem, do którego jest dostęp poprzez różne technologie i platformy programistyczne, takie jak:

• Serwisy internetowe (Web Services, WS- ), np. oparte o WSE 2.0,

• WCF,

• Java

• Stos w ANSI C

Oczywiście część z nich bazuje na przesyłaniu danych tekstowych, a część bazuje na strumieniach binarnych. Tutaj należy zwrócić uwagę na fakt, że w odróżnieniu od OPC Classic (bazującego na DCOM’ie), OPC UA definiuje dokładnie przesyłane dane (a nie interfejs programistyczny (API)).

Po stronie klienta, znajduje się zaimplementowana moduł klienta OPC UA oraz odpowiednie moduły pozwalające na skorzystanie z pewnej infrastruktury komunikacyjnej do wymiany danych.

W zasadzie nieistotne jest z jakiej infrastruktury, czy technologii komunikacyjnej korzystają klient czy serwer, ważne jest natomiast by obydwa te komponenty wpierały ten sam sposób wymiany danych.

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

OPC Unified Architecture (OPC UA) jako przykład nowoczesnego podejścia do tworzenia standardu

OPC Classic, czyli OPC bazujące na technologii DCOM, powoli odchodzi... dlaczego?? Dlatego, że to co na początku było motorem do upowszechnienia się standardu, czyli wygodny interfejs programistyczny bazujący na modelu DCOM, teraz jest raczej kulą u nogi. Dzisiaj świat zna nowsze i wygodniejsze (od COM i DCOM) sposoby komunikacji. Sam Microsoft prowadzając platformę .NET i WCF pokazał, że dni DCOM’a są policzone.

Twórcy OPC UA postanowili więc wybrać inne technologie, przy pomocy których ma się odbywać komunikacja. Wybór padł na Web Serwisy i binarne strumienie danych. Pierwsza z tych technologii jest już od kilku lat powszechnie uznanym standardem w komunikacji w sieci Internet. Jest więc ona już sprawdzona, a narzędzia pozwalające na jej wykorzystanie dostępne są na wielu platformach. Drugi sposób jest sposobem niestandardowym i polega na binarnym kodowaniu danych i wywołań, OPC UA precyzyjnie opisuje w jaki sposób kodowanie ma się odbywać.

Pojawia się jednak pytanie, na jak długo wystarczą te rozwiązania, co jeśli powstanie coś nowego, czy warto się więc na stałe wiązać z danym rozwiązaniem? Nauczka z DCOM’em daje chyba jednoznaczną odpowiedź: NIE. Twórcy OPC UA podeszli więc do tej sprawy w dość pomysłowy sposób.

Trzeba zauważyć, że OPC UA specyfikuje pewien abstrakcyjny opis usług (głównie w specyfikacji OPC UA części 4). Opis usług nie jest związany z żadnym konkretnym sposobem komunikacji lub technologią komunikacyjną. Dopiero inna część specyfikacji (specyfikacja OPC UA część 6) opisuje ich implementację z wykorzystaniem konkretnej technologii (ang technology mapping). Aktualnie specyfikacji zakłada użycie Web Serwisów i binarnych strumieni danych, ale pozostawia również furtkę, że w przyszłości wykorzystany zostanie inny sposób wymiany danych (zmieni się sposób przesyłania wiadomości, ale model usługowy i model informacyjny pozostanie bez zmian).

Dodatkowo OPC UA nie precyzuje natomiast konkretnego API (Application Program Interface – Intefejs programowy aplikacji), tak jak to miało miejsce w przypadku OPC Classic opartego o DCOM. OPC UA specyfikuje format przesyłanych wiadomości. Stosy komunikacyjne klienta lub serwera użyte do zaszyfrowania lub odszyfrowania danych, wywołań lub odpowiedzi również nie są definiowane. Stosy komunikacyjne różnych dostawców powinny być w stanie komunikować się, jeśli tylko używają tej samej technologii (ang. technology mapping).

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

Artykuł: Infrastruktura komunikacyjno-usługowa OPC Unified Architecture (OPC UA)

OPC Unified Architecture (OPC UA) jest niezależnym platformowo standardem, przy pomocy którego wiele różnych rodzajów systemów może się komunikować. Wiadomości wymieniane pomiędzy klientami i serwerami mogą być przesyłane z wykorzystaniem różnego rodzajów sieci. OPC UA zostało stworzone aby wymiana danych odbywała się w sposób wydajny, bezpieczny, odporny na ataki i zapewniającą wzajemną identyfikację klienta i serwera. Dodatkowo OPC UA definiuje bogaty zbiór usług, dzięki któremu klienci mogą pozyskiwać dane.

Niniejszy artykuł ma na celu przybliżenie czytelnikowi infrastruktury komunikacyjnej OPC UA oraz usług, które ten standard oferuje. W celu ułatwienia czytania artykuł został podzielony na części:

1. Wstępniak (czyli ten tekst)

2. OPC UA jako przykład nowoczesnego podejścia do tworzenia standardu.

3. Architektura komunikacyjna

4. Kodowanie i mapowanie

5. Zbiory usług

6. Mechanizm odkrywania

7. Połączenie, czyli kanały i sesje

8. Subskrypcje

9. Subskrypcje – przykładowe ustawienia i wykorzystanie

10. Mechanizm publikowania

11. Podsumowanie

Życzę wszystkim miłej lektury.

OPC – platforma integracji systemów zarządzania z produkcją

Już kiedyś pisałem na temat źródeł, skąd można czerpać wiedzę na temat OPC. Zapomniałem jednak o ciekawym artykule, który został opublikowany na łamach czasopisma: "CONTROL ENGINEERING POLSKA". Artykuł został wydany w częściach, we wrześniowym i październikowym (rok 2008) numerze i miał tytuł: "OPC – platforma integracji systemów zarządzania z produkcją". Artykuł jest dostępny na stronach wortalu ControlEngPolska:

• Część 1
• Część 2

Ponieważ pomagałem w przygotowaniu tego artykułu (na końcu jest podziękowanie dla mnie :) ), więc mogę go z czystym sumieniem polecić.

Życzę miłej lektury!

Podsumowanie (OPC, COM, DCOM, .NET i C#, co dalej?)

Mam nadzieję, że nie zanudziłem czytelników (zwłaszcza mocno teoretycznym początkiem) i udało mi się wskazać elementy, które mogą połączyć technologie z tematu (COM, DCOM, .NET i C#) i ostatecznie doprowadzić do funkcjonalnych aplikacji, takich jak serwery i klienci OPC bazujący na technologii .NET.

Oczywiście niniejszy artykuł, to tylko dotknięcie tematu i zdaję sobie sprawę, że niemożliwością jest stworzenie funkcjonalnego oprogramowania bazując tylko na przedstawionej tutaj wiedzy. Nie wystarczy również doskonała znajomość technologii z tematu i umiejętność ich programowania do stworzenia klienta, czy serwera OPC. Do tego potrzebne są jeszcze specyfikacje, które nie są jednak dostępne dla każdego chętnego, a tylko dla członków OPC Foundation.

Na pocieszenie trochę przekornie zadam pytanie: "czy warto się męczyć?". Na rynku dostępne są rozwiązania, które stosunkowo małym nakładem pracy pozwalają stworzyć aplikacje klienta lub serwera, a oprogramowanie oprzeć na platformie .NET.

Co więc proponuję?

1. Serwer można oprzeć o oprogramowanie CommServer i jedynie co trzeba zrobić to napisać prosty DataProvider , który dostarcza do OPC odpowiednie dane,a pisaniu takiego DataProvidera pomoże odpowiedni pakiet SDK .
2. Klienta można oprzeć o oprogramowanie DataPorter , a do dostępu do odczytywanych przez niego danych wykorzystać odpowiedni webserwis.

( autor: Maciej Zbrzezny)