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)

Implementacja serwera OPC w C#

W poprzedniej części zasygnalizowałem co należy zrobić by stworzyć w C# (na platformie .NET) klienta OPC, nie były to proste zagadnienia, niestety stworzenie serwera niesie za sobą jeszcze większe wymagania.

W tym przypadku należy stworzyć i zarejestrować odpowiedni komponent jako obiekt COM. Zagadnienie to opisane było w części .NET i COM, dlatego nie będę go teraz dalej rozwijał. Niestety to nie wystarczy, gdyż okazuje się, że nie możliwa jest implementacja w pełni zgodnego ze specyfikacją serwera OPC wykorzystując tylko rozwiązania oparte o platformę .NET.

Cóż można więc zrobić? Należy wykorzystać tak zwany serwer wrapper, czyli element pośredniczący. Server Wrapper należy przygotować tak by był to plik wykonywalny i który po rejestracji jako obiekt COM/DCOM udostępnia wszystkie interfejsy wymagane przez standard OPC i jego specyfikacje. Serwer wrapper nie musi realizować żadnej funkcjonalności poza połączeniem się do obiektu COM, który jest plikiem DLL i realizuje całą funkcjonalność serwera, ten plik DLL może już być przygotowany w C#, w oparciu o platformę .NET.

Opisywane tutaj rozwiązanie przedstawia rysunek poniżej:

Na rysunku widać jak "OPC Wrapper.exe" łączy się poprzez COM i wykorzystuje interfejsy zbliżone do tych ze specyfikacji OPC, by wykorzystać implementację serwera OPC występującego jako plik DLL (skompilowany na platformie .NET). "OPC Wrapper.exe" natomiast jest OPC serwerem, do którego dostęp mają klienci OPC i implementuje wszystkie potrzebne do tego interfejsy.

Brzmi to dość skomplikowanie, pytanie więc czy można w ten sposób zrobić OPC serwer w pełni zgodny ze specyfikacją? Okazuje się że tak, właśnie taką konstrukcję wybrało m.in. OPC Foundation do przygotowania swojego pakietu SDK wspierającego tworzenie oprogramowania zgodnego z OPC.

Kolejne pytanie może brzmieć: czy jest to rozwiązanie odpowiednio wydajne? Z doświadczenia mogę powiedzieć, że tak. A dodatkowa komunikacja odbywająca się wewnątrz komputera ma mały wpływ na wydajność całego serwera.

Implementacja klienta OPC w C#

Po wcześniej przytoczonej teorii (COM , DCOM , .NET , Marshalling , .NET i COM) chyba każdy już wie od czego zacząć, by napisać klienta OPC w C#. Niestety nie obędzie się tutaj bez znajomości specyfikacji. Dodatkowo potrzebne będzie spore doświadczenie w korzystaniu z .NET Platform Invocation Services (czyli m.in marshalling'u i umiejętność konwersji definicji wywołań bibliotek kodu niezarządzalnego na definicję języka C#).

Spójrzmy na definicję przykładowej metody AddItems (z interfejsu OPC Item Management: "IOPCItemMgt"):

HRESULT AddItems(
[in] DWORD dwCount,
[in, size_is( dwCount)] OPCITEMDEF * pItemArray,
[out, size_is(,dwCount)] OPCITEMRESULT ** ppAddResults,
[out, size_is(,dwCount)] HRESULT ** ppErrors );

Ta definicja napisana w C# będzie wyglądała następująco:

int AddItems(
[In] int dwCount,
[In] IntPtr pItemArray,
[Out] out IntPtr ppAddResults,
[Out] out IntPtr ppErrors );

Oczywiście postępując w ten sposób i deklarując parametry jako IntPtr, tracimy wiele informacji. Kolejna sprawa, to standardowe mapowanie błędów zwracanych przez obiekt COM (jako HRESULT), które są konwertowane przez mechanizm marszalingu .NET (.NET marshaller) na wyjątek: COMException. Dodatkowo niektóre metody dostępne poprzez COM zwracają kody wyników: zwykle S_OK (ale czasami inne, np. S_FALSE). Z domyślnym mapowaniem, ta informacja może zostać zagubiona. Aby ominąć te problemy można zadeklarować funkcję interfejsu korzystając ze specjalnego atrybutu PreserveSig . Spójrzcie na kod poniżej:

 [ComVisible(true), ComImport,
Guid("39c13a54-011e-11d0-9675-0020afd8adb3"),
InterfaceType( ComInterfaceType.InterfaceIsIUnknown )]
internal interface IOPCItemMgt
{
[PreserveSig]
int AddItems(
[In] int dwCount,
[In] IntPtr pItemArray,
[Out] out IntPtr ppAddResults,
[Out] out IntPtr ppErrors );
...

W tej części będzie to już wszystko. Dla tych, którzy chcą rozszerzyć opisane tutaj zagadnienia, polecam artykuł: http://www.codeproject.com/KB/COM/opcdotnet.aspx

Specyfikacje OPC Unified Architecture (OPC UA) wreszcie opublikowane jako skończone

Ostatnio (9 lutego 2008) na stronach OPC Foundation, wreszcie pojawiły się ostateczne wersje specyfikacji OPC Unified Architecture (OPC UA). Aktualnie opublikowane zostały części od 1 do 8, specyfikacje mają status „release”, czyli już nie powinny się zmienić lub mogą zmienić się nieznacznie):

• OPC UA Part 1 - Overview and Concepts 1.01 Specification

• OPC UA Part 2 - Security Model 1.01 Specification

• OPC UA Part 3 - Address Space Model 1.01 Specification

• OPC UA Part 4 - Services 1.01 Specification

• OPC UA Part 5 - Information Model 1.01 Specification

• OPC UA Part 7 - Profiles 1.00 Specification

• OPC UA Part 6 - Mappings 1.00 Specification

• OPC UA Part 8 - Data Access 1.01 Specification

Prace nad specyfikacją trwały od 2004 i było w nie zaangażowanych wiele film (w tym jedna z Polski: CAS). Fakt, że te specyfikacje otrzymały wreszcie status zakończonych otwiera drogę dla producentów oprogramowania zgodnego z nową technologią. Wraz ze specyfikacjami opublikowana została kolejna (stabilna) wersja pakietu SDK ułatwiająca tworzenie zgodne z technologią OPC Unified Architecture.

Pracę nad tą technologią nadal trwają (aktualnie zakończona została pierwsza faza prac) i m.in. do opublikowania zostały:

Part 9 - Alarms and Conditions

Part 10 - Programs

Part 11 - Historical Access

Part 12 – Discovery

Ponadto w grupach roboczych trwają prace nad wykorzystaniem tej technologii, jako standardowego sposobu dostępu do urządzeń (grupa: DI – Device interface) oraz analizatorów (grupa ADI – Analyser Device Interface).

OPC Foundation, gratulacje zakończenia pierwszej fazy prac nad OPC UA i powodzenia w dalszych pracach. Dla osób pragnących rozszerzyć swoją wiedzę na temat OPC UA polecam artykuły:

• OPC Unified Architecture (OPC UA), czyli krok na przód.
• Infrastruktura komunikacyjno-usługowa OPC Unified Architecture (OPC UA)

.NET i COM

Wcześniej opisałem już wspomniane w tytule technologie i wskazałem problemy i potencjalne rozwiązania używane podczas tworzenia oprogramowania, w którym należy wykorzystać komunikację pomiędzy kodem zarządzalny i niezarządzalnym. W przypadku interakcji komponentu COM i kodu powstałego w oparciu o technologię .NET należy poruszyć jeszcze dwie sprawy:

• jak dostać się do obiektu COM z poziomu .NET Framework
• jak udostępnić obiekt .NET Framework poprzez COM

Z pierwszą sytuacją mamy do czynienia, gdy chcemy napisać aplikację, która realizuje funkcjonalność klienta COM (np. klient OPC). Jest to prosty przypadek wystarczy zaimportować odpowiedni interfejs dostępny poprzez COM.

W tym celu definicję odpowiedniego interfejsu w języku C# poprzedzamy odpowiednimi atrybutami:

 [ComVisible(true), ComImport,
Guid("/*odpowiedni guid*/"),
InterfaceType( ComInterfaceType.InterfaceIsIUnknown )]

Interfejs powinien mieć definicję wszystkich potrzebnych funkcji. Zwykle informacje na temat, co to za funkcje znajdziemy w odpowiedniej specyfikacji. Do ich definicji następnie można już wykorzystać zasady marshallingu opisanego w poprzedniej części.

Oprócz definicji interfejsów należy zaimportować jeszcze pewne funkcje, np.:

CoCreateInstanceEx z biblioteki ole32.dll:

      [DllImport("ole32.dll")]
      private static extern void CoCreateInstanceEx(
          ref Guid         clsid,
          [MarshalAs(UnmanagedType.IUnknown)]
          object           punkOuter,
          uint             dwClsCtx,
          [In]
          ref COSERVERINFO pServerInfo,
          uint             dwCount,
          [In, Out]
          MULTI_QI[]       pResults);

Ewentualnie można również wykorzystać metodę CreateComInstanceFrom z klasy System.Activator.

Odrobinę trudniejsze jest udostępnienie komponentu napisanego w C# poprzez mechanizm COM (z takim przypadkiem mamy do czynienia chcąc napisać serwer OPC). W tym celu należy:

1. Wybrać typy i procedury które mają być dostępne poprzez COM. Wszystkie one muszą być publiczne, typy (klasy) muszą mieć publiczny domyślny konstruktor (który jest jedynym konstruktorem, który może być wywołany poprzez COM).
2. Ustawić odpowiednie atrybuty, które rozszerzą przenośność komponentu.
3. Zarejestrować assembly wśród komponentów typu COM. Czynność ta może być wykonana w momencie tworzenia komponentu, instalacji lub później przy użyciu narzędzia Regasm.exe

Ciekawy artykuł na ten temat (rozwijające zagadnienia wspomniane w powyższych krokach) dostępny na stronach MSDN to: "Exposing .NET Framework Components to COM" (http://msdn.microsoft.com/en-us/library/zsfww439(VS.80).aspx).

.NET Platform Invocation Services

Wiele tradycyjnie tworzonych bibliotek (w tym biblioteki wchodzące w skład dostarczanego przez OPC Foundation: "OPC Core Components") stworzone zostały w tradycyjnych językach programowania jak C lub C++ i skompilowane są do kodu maszynowego. Aby wykorzystać stworzoną w ten sposób bibliotekę potrzebne są odpowiednie pliki nagłówkowe (zwykle dostarczone przez producenta biblioteki), które dodawane są do kodu źródłowego tworzonej aplikacji i które powodują wywołanie odpowiednich procedur z biblioteki. Wykorzystanie takich bibliotek w programie napisanym w języku C++ jest dość proste i wystarczy bazować na dołączonych plikach. Inaczej wygląda sprawa wykorzystywania takich biblioteki w zarządzanym kodzie, jakim są programy napisane w języku C#. W takim przypadku nie wystarczy dołączyć odpowiednich plików nagłówkowych (trzeba ew. napisać własne odpowiedniki pewnych plików), ponadto trzeba wykonać pewne dodatkowe zabiegi zapewniające współpracę kodu zarządzanego i niezarządzanego. Problemy te rozwiązuje się przy pomocy .NET Platform Invocation Services, która to usługa pozwala wywoływanie procedur z bibliotek DLL lub komponentów COM (które nie są skompilowane do kodu zarządzanego). Dla każdej wykorzystywanej funkcji z biblioteki należy napisać odpowiednią deklarację. Przykładowo dla funkcji systemu Windows odczytującej wartość licznika procesora, która oryginalnie jest w postaci:

BOOL QueryPerformanceCounter( LARGE_INTEGER *lpPerformanceCount );

napiszemy:

[DllImport("kernel32")] public static extern bool QueryPerformanceCounter(ref Int64 lpPerformanceCount);

Przy pisaniu nowych deklaracji można zauważyć wiele prawidłowości np. *zmienna najczęściej zamieniamy to na IntPtr zmienna (wyjątek stanowi char *zmienna – gdyż to zamieniamy na string lub StringBuilder), **zmienna – zamieniamy na ref IntPtr. Klasa IntPtr służy najczęściej do wskazywania miejsca w niezarządzanym obszarze pamięci. Jeżeli istnieje potrzeba to można zaalokować sobie pamięć w obszarze niezarządzanym, robi się to funkcją Marshal.AllocCoTaskMem(int length) (wykorzystywane jest to np. przy tworzeniu pakietów do wysłania). W zaalokowanym obszarze można pisać i czytać (np. Marshal.WriteByte(pointer, byte)) W przypadku gdyby zaistniał problem przeniesienia struktury lub klasy z obszaru niezarządzanego do zarządzanego, można wykonać to funkcją PtrToStructure(pointer,structure). Ponieważ wykorzystywane tutaj mechanizmy bazują na klasach z przestrzeni nazw: "Marshall", dlatego często do określenia takiego podejścia jest używany termin marszaling (ang. "marshalling").

Platforma .NET Framework

Platforma .NET jest dość nową technologią opracowaną przez Microsoft i opiera się na mechanizmie opartym o uruchamianie skompilowanego kodu w czymś podobnym do maszyny wirtualnej. Microsoft nazywa środowisko uruchomieniowe: Common Language Runtime (w skrócie CLR). Środowisko CLR kompiluje i wykonuje zapisany w standardowym języku pośrednim Microsoft (MSIL) kod aplikacji zwany kodem zarządzanym (ang. managed code), zapewniając wszystkie podstawowe funkcje konieczne do działania aplikacji.

Mhmm, jakkolwiek skomplikowanie to brzmi, oznacza to, że sposób w jaki uruchamiane są aplikacje bazujące na platformie .NET jest odmienne od tego, jak uruchamiane są aplikacje kompilowane do kodu maszynowego.

Odmienny sposób uruchamiania aplikacji bazujących na .NET Framework niesie za sobą wiele zalet. Programista może przenieść na system operacyjny problemy związane z zarządzaniem pamięcią (niepotrzebne obiekty, zajmujące pamięć, usunie automatycznie tzw. Garbage Collector). .NET Framework zapewnia bogatą bibliotekę komponentów, ułatwiające pisanie aplikacji. Docelowy plik wykonywalny jest zwykle mniejszy od pliku wygenerowanego tradycyjnym sposobem. Języki wykorzystywane do pisania programów na platformę .NET (np. coraz bardziej popularny C#) zostały tak opracowane, by wiele błędów można było wykryć już na poziomie kompilacji. System operacyjny może odizolować uruchomioną aplikację (dla aplikacji tworzona jest tzw. domena aplikacji, dla której można konfigurować odpowiednie zabezpieczenia, poziom izolacji, itp...). Ciekawy jest też nowy sposób zdalnego wywoływania procedur, Microsoft nazwał go ".NET Remoting" oraz jego następca "Windows Communication Foundation" (WCF) . Przewidziane jest kilka sposobów przekazywania danych, m.in: przesyłane binarne (strumienie oparte o protokół TCP), strumienie XML, binarne potoki (zwane w języku ang. "named pipes").

Poza wspomnianymi zaletami niestety pojawiają się również pewne problemy, zwłaszcza w przypadku komunikacji na granicy "kod niezarządzalny" (ang. "unmanaged code" - czyli aplikacje lub biblioteki powstałe w tradycyjny sposób i skompilowane do kodu maszynowaego), a "kod zarządzalny" (ang. "managed code", czyli skompilowany do MSIL). W tym przypadku dostępne są następujące możliwości:

• wykorzystanie technologii COM,
• zaimportowanie odpowiedniego pliku DLL i wykorzystanie tzw. .NET Platform Invocation Services

W kolejnych częściach opiszę jak można te dwie możliwości wykorzystać.

Technologie, na których bazuje OPC Classic. Część 2: Technologia DCOM.

Technologia DCOM jest rozszerzeniem technologii COM (opisanej wcześniej), umożliwiającym wymianę danych za pośrednictwem sieci, podczas gdy COM dotyczył jedynie komunikacji na lokalnym komputerze. DCOM zastępuje protokołem sieciowym lokalną komunikacje między procesami, korzystając z technologii DCE RPC (Distributed Computing Environment / Remote Procedure Call). W rzeczywistości z punktu widzenia klienta bądź serwera nie ma różnicy, czy druga strona znajduje się na tej samej maszynie czy zdalnie.

Komunikacja realizowana jest to za pośrednictwem tzw. RPC stubs oraz obiektów Proxy, istniejących po obu stronach. Przykładowa komunikacja wygląda następująco:

1. Klient wywołuje lokalnie pewną funkcję.
2. Proxy przejmuje wywołanie i tworzy wiadomość do przesłania przez sieć.
3. Wiadomość jest przesyłana.
4. System operacyjny serwera otrzymuje wiadomość i przekazuje ją do stub'a serwera. Stub rozpakowuje wiadomość i lokalnie wywołuje funkcję na serwerze.

Aby umożliwić interakcję zdalnych aplikacji za pośrednictwem DCOM należy skonfigurować DCOM na każdym komputerze, np. przy pomocy programu DCOMCNFG.

Technologie, na których bazuje OPC Classic. Część 1: Technologia COM.

OPC Classic, czyli OPC bazujące na aktualnie wykorzystywanych i opublikowanych specyfikacjach, do transportu i wymiany danych wykorzystuje technologię DCOM. DCOM jest technologią opracowaną przez Microsoft, która służy do zdalnego wywoływania procedur pomiędzy różnymi komputerami. DCOM jako skrót oznacza Distributed COM (Distributed Component Object Model).

COM, jest opracowaną przez Microsoft technologią umożliwiającą efektywną komunikację między aplikacjami. COM definiuje komponenty programowe niezależne od języka programowania, co umożliwia włączanie do tworzonych aplikacji elementów należących do innych programów i wymianę danych między poszczególnymi obiektami za pomocą tzw. interfejsów.

W następnej części opisana zostanie technologia DCOM.

OPC, DCOM, .NET i C# w jednym stali domu

Przeglądałem ostatnio zapytania, które są wpisywane do wyszukiwarki Google, a powodują, że ktoś trafia na tego bloga. Jeden z tematów to "C# i DCOM". Chciałby wyjść na przeciw zainteresowaniom czytelników i pokazać jak można połączyć te dwa elementy. Ponieważ na co dzień zajmuję się technologią OPC, więc właśnie o tej technologii dotyczyć będzie ten artykuł ten artykuł.

Artykuł omawia różnice pomiędzy kodem zarządzalnym i niezarządzalnym oraz sposoby komunikacji między nimi. Tekst jest podzielony na części i po teoretycznym wstępie przedstawione są przykłady wywołań między-platformowych. Artykuł opisuje również możliwości tworzenia i obsługi elementów COM/DCOM z poziomu platformy .NET, a kończy się przykładami opisującymi możliwości implementacji technologii OPC na platformie .NET.

W celu ułatwienia czytania, artykuł został podzielony na następujące części:

1. Technologie, na których bazuje OPC Classic. Część 1: Technologia COM.
2. Technologie, na których bazuje OPC Classic. Część 2: Technologia DCOM.
3. Platforma .NET Framework
4. .NET Platform Invocation Services
5. .NET i COM
6. Implementacja klienta OPC w C#
7. Implementacja serwera OPC w C#
8. Podsumowanie

Zapraszam do lektury.

Blog jednego z twórców OPC Unified Architecture (OPC UA) - Randy'iego Armstrong'a

Niedawno jeden z twórców standardu OPC Unified Architecture i pakietu SDK poświęconego tej technologii: Randy Armstrong, rozpoczął tworzenie bloga kierowanego do inżynierów i programistów chcących wykorzystywać technologię OPC Unified Architecture (OPC UA). Blog jest dostępny pod adresem:

http://lists.opcfoundation.org/RandyBlog/default.aspx

Zgodnie z tym co napisał w swym pierwszym post'cie, Randy Armstrong deklaruje, że jego blog będzie poświęcony podstawom implementacji technologii OPC UA. Jego posty będą pokrywały rożne techniczne tematy i zapewnią lepszy start prac nad oprogramowaniem wspierającym technologię OPC UA, bez konieczności przeczytania wszystkich specyfikacji "od deski do deski". Ponadto uzupełnieniem bloga będzie przykładowy kod, który nie będzie oparty o pakiet OPC UA SDK (dostarczany przez OPC Foundation), a będzie dostępny dla wszystkich członków OPC Foundation.

Zachęcam wszystkich do lektury.