Artykuł: Śledzenie i logowanie zdarzeń (tracing and logging) na platformie .NET (przykłady w oparciu o C#).

Programista często staje przed koniecznością wyboru sposobu śledzenia przebiegu aplikacji, czy logowaniu błędów. Niniejszy artykuł ma na celu przedstawienie sposobu w jaki można to zrobić w oparciu o platformę . NET. Dzięki wykorzystaniu opisanej tutaj metodologii końcowa aplikacja będzie w tym względzie w pełni konfigurowalna, co może zapewnić wygodę nie tylko programiście, ale również użytkownika końcowego. Zachęcam wszystkich do lektury:

• Część 1: Trochę teorii
• Część 2: Przykłady gotowe do wykorzystania
• Część 3: Przykładowa aplikacja
• Część 4: Podsumowanie

Śledzenie i logowanie zdarzeń (tracing and logging) na platformie .NET (część 4 - podsumowanie) (przykłady w oparciu o C#).

W poprzednich częściach (1,2,3) przedstawiłem już podstawy związane ze śledzeniem przebiegu programu i logowaniem zdarzeń na platformie .NET, a w przykładzie zostało pokazane jak można wykorzystać tą metodologię.

Oczywiście to nie wszystko co można w ten sposób osiągnąć. Interesująca wydaje się zwłaszcza możliwość implementacji własnego Trace Listener'a. Dzięki temu mamy większą swobodę w wyborze miejsca do którego będą trafiały nasze logi. Nie musi być to plik w dziwnym formacie (choć może), czy inne poza standardowym wykorzystanie rejestru zdarzeń systemu Windows. Możemy iść tutaj znacznie dalej np.:

• zapisywanie zdarzeń do bazy danych, umożliwiając użytkownikowi wpisanie dowolnego connection-string'a,
• wysyłanie zdarzeń poprzez WebService do zdalnego rejestru (chyba bardzo dobre rozwiązanie dla aplikacji, by wykorzystać połączenie sieciowe do przesłania informacji o problemach do zdalnego serwera należącego do autorów oprogramowania),
• wysyłanie informacji bezpośrednio w pakietach TCP lub UDP (przykłady można znaleźć w wortalu CodeProject: TraceTool, UDP Trace Listener),
• tworzenie serii plików z logami (np. log z każdego dnia może być w oddzielnym pliku)
• i wiele innych - w zależności od naszej wyobraźni.

Co trzeba zrobić, aby wykorzystać własny Listener?? Oczywiście stworzyć klasę dziedziczącą, po TraceListener, a następnie zaimplementować konieczne funkcje (m.in. Write, TraceEvent i inne...). Teraz wystarczy już użyć stworzony Listener w naszym programie (np. w pliku konfiguracyjnym).

W tym miejscu dotarliśmy już do końca tego artykułu. Mam nadzieję, że udało mi się przybliżyć możliwości śledzenia i logowania zdarzeń na platformie .NET. Być może w kolejnym artykule dotyczącym tej tematyki rozszerzę zagadnienie konstruowania własnego TraceListener'a.

Śledzenie i logowanie zdarzeń (tracing and logging) na platformie .NET (część 3) (przykłady w oparciu o C#).

W poprzednich częściach (pierwsza / druga) opisywałem jak można śledzić i logować zdarzenia na platformie .NET. Teraz zachęcam wszystkich do pobrania prostego programiku: LoggerSample. Logger Sample jest prostą aplikacją, która generuje zdarzenia z dwóch źródeł. Zdarzenia są zapisywane do pliku, logu systemowego i na konsole (jest to wszystko skonfigurowane w pliku konfiguracyjnym). Główne okno programu jest bardzo proste, a naciskając przyciski można generować zdarzenia dla wybranego źródła.

Zachęcam do prześledzenia pliku konfiguracyjnego, by zobaczyć jak łatwo można to konfigurować. Pobierz przykładową aplikację (kod źródłowy) tutaj. W następnej części pojawi się podsumowanie.

Śledzenie i logowanie zdarzeń (tracing and logging) na platformie .NET (część 2) (przykłady w oparciu o C#).

W poprzedniej części opisane zostało zagadnienie śledzenia zdarzeń w aplikacji od strony teoretycznej. Ta część poświęcona będzie przykładom wskazującym jak to zrealizować w praktyce. Więc do dzieła. Pierwszą czynnością, którą należy wykonać to wybrać klasę w naszej aplikacji, która będzie generowała zdarzenia. W tej klasie powinniśmy utworzyć obiekt TraceSource:

private TraceSource m_tracesource;

...

m_tracesource= new TraceSource("sourcename");

Ważna jest nazwa źródła (w powyższym przykładzie: sourcename), która jest przekazywana do konstruktora obiektu TraceSource. Ta nazwa będzie wykorzystywana później w pliku konfiguracyjnym aplikacji, a by zlokalizować źródło z którego zdarzeniami jesteśmy zainteresowani. Kolejnym krokiem jest użycie funkcji TraceEvent, w każdym miejscu programu, gdzie występuje jakieś interesujące zdarzenie. Przykład takiego wykorzystania znajduje się poniżej:

m_tracesource.TraceEvent(type, id, message);

Tutaj warte komentarza są następujące sprawy:

• type - to typ zdarzenia (według enumeracji TraceEventType), omówiony w poprzedniej części artykułu.
• id - to numeryczny identyfikator przypisany przez programistę aplikacji (czyli przez nas) do tego z darzenia

• message - wiadomość, którą chcemy przekazać użytkownikowi

Teraz przed nami najciekawszy moment, konfiguracja logowania w pliku konfiguracyjnym aplikacji. Wszystkie wpisy odnośnie ustawień logowania lub śledzenia zdarzeń opartego o mechanizm, który tutaj opisuję powinny się znaleźć w pliku konfiguracyjnym wewnątrz tagu "system.diagnostic":

<system.diagnostics>

<!-- ... other definitions place here... -->

</system.diagnostics>

Wewnątrz tagu "system.diagnostic" powinny się znaleźć następujące elementy:

• sources - czyli ustawienia odnośnie źródeł, z których zdarzeniami jesteśmy zainteresowani i dla których definiujemy "listeners", czyli do jakiego listenera mają trafiać informacje z tego źródła
• switches - tutaj definiujemy jakim poziomem logowania jesteśmy zainteresowaniu z danego źródła (czy mają to być błędy (errors), ostrzeżenia (warnings), itp...), informacje na temat konfiguracji switch'y można znaleźć w MDSN'nie.
• sharedListeners - tuaj umieszczamy definicje listener'ów, które zamieżamy wykorzystywać. Oprócz nazw i typu danego listener'a konfiugurujemy też inne elementy charakterystyczne dla danego typu Listener'a, np.: nazwę pliku, do którego mają trafić informacje o zdarzeniach.

Przykładowa definicja źródła (source) została pokazana poniżej:

<sources>

<source name="MySource1" switchName="MySource" switchType="System.Diagnostics.SourceSwitch" gt;

<listeners>

<add name="LogFile"/>

<add name="myEventLogTraceListener"/>

</listeners>

</source>

</sources>

W tym przykładzie dodano źródło "MySource1", z którego chcemy odczytywać zdarzenia. Oczywiście takie źródło musi być wykorzystane w aplikacji, abyśmy jakiekolwiek zdarzenia otrzymali. Dla tego źródła ustawiono, że switch o nazwie "MySource" ustawi poziom logowania. Dodatkowo do źródła został dodany szereg listenerów, do których będą trafiały zdarzenia. Przykładowa definicja (wykorzystanego wcześniej) switch'a znajduje się tutaj:

<switches>

<add name="MySource" value="All" />

</switches> W tym przypadku zdefiniowany switch ustawił poziom logowania na: "All", czyli interesują nas wszystkie zdarzenia. Kolejnym krokiem jest skonfigurowanie wykorzystanych Listener'ów, czyli sekcja sharedListeners:

<sharedListeners>

<add name="myEventLogTraceListener" type="System.Diagnostics.EventLogTraceListener" initializeData="TraceListenerLog" />

<add name="LogFile" type="System.Diagnostics.DelimitedListTraceListener" initializeData="Application_Main.log" traceOutputOptions="DateTime">

<filter type="System.Diagnostics.EventTypeFilter" initializeData="Warning" />

</add>

</sharedListeners>

Tutaj zostały skonfigurowane dwa listenery:

• myEventLogTraceListener, który wykorzystuje klasę EventLogTraceListner, z której zdarzenia będą trafiać do logu aplikacji systemu Windows, a źródłem zdarzenia (wpisanym do logu) będzie TraceListenerLog
• LogFile, wykorzystujący DelimitedListTraceListener, który zdarzenia będzie wpisywał do pliku o nazwie "Application_Main.log", wpisy będą oddzielane średnikami i będą zawierały datę i czas zdarzenia. Dodatkowo dla tego Listener'a ustawiony został filtr, który będzie powodował, że trafiające tutaj zdarzenia, będą przynajmniej ostrzeżeniami (warnings).

Mam nadzieję, że udało mi się przybliżyć mechanizmy śledzenia na platformie .NET, w następnej części pojawi się link i krótki opis programu, który wykorzysta opisane tutaj elementy.

Śledzenie i logowanie zdarzeń (tracing and logging) na platformie .NET (część 1) (przykłady w oparciu o C#).

Tworząc jakąś aplikację bardzo często stajemy przed koniecznością śledzenia zdarzeń jakie w niej występują. Szczególnie istotne jest to w aplikacjach, które wykonują zadania trwające dłuższą chwilę czasu. Do aplikacji tego typu zaliczyć można:

• programy przetwarzające dane (np. wykonujące skomplikowane obliczenia, kodujące materiał wideo, itp...)
• programy oferujące usługi jak serwer (np. serwer www, ftp, opc lub inny...)
• inne aplikacje, których przebiegiem jesteśmy zainteresowani

Należy pamiętać, że nie zawsze chcemy, a często nawet nie jest to możliwe, by informować użytkownika bezpośrednio przy pomocy okna dialogowego. Zastanówmy się więc jakie są inne możliwości? Najczęściej w takich przypadkach wykorzystywane jest jedno z dwóch poniższych rozwiązań:

• prywatny plik logu,
• użycie rejestru zdarzeń wbudowanego w systemu operacyjny.

Która z tych metod jest lepsza? Chyba trudno jednoznaczną odpowiedź, każde z tych wspomnianych wyżej rozwiązań ma swoje wady i zalety. Pocieszający jest fakt, że programując w oparciu o platformę .NET Framework nie trzeba wcale decydować o tym, którą drogę wybrać. Wystarczy tylko wybrać metodologię opartą o tzw. tracing, a dzięki temu decyzję o tym gdzie mają nasze logi trafić będzie można zostawić użytkownikowi końcowemu. Jak to działa? Mechanizm ten wykorzystuje klasy takie jak:

• dziedziczące po TraceListener - dzięki nim można wskazać miejsce gdzie mają trafić zdarzenia np: System.Diagnostics..::.DefaultTraceListener, System.Diagnostics..::.EventLogTraceListener, System.Diagnostics..::.TextWriterTraceListener,
• oraz TraceSource, z której wykorzystywana jest funkcja: TraceEvent do przekazania informacji o zdarzeniu do TraceListener'a

Dodatkowo można jeszcze wskazywać poziomy zdarzeń (przecież nie wszystkie zdarzenia są tak samo ważne). Platforma .Net Tracing przewiduje następujące typy zdarzeń (opisane w enumeracji TraceLevel):

• Off - logowanie jest wyłączone
• Error - logowane są tylko zdarzenia mające charakter błędów
• Warning - logowane są zdarzenia, które są ostrzeżeniami
• Info - w logu będą się pojawiały informacje
• Verbose - logowane mogą być wszystkie zdarzenia, bez względu na charakter.

Co ciekawe, to użytkownik obsługujący program może wybrać jakiego rodzajami zdarzeń jest zainteresowany, wystarczy tylko zmodyfikować plik konfiguracyjny aplikacji (z rozszerzeniem ".config"), nie potrzeba wykonywać rekompilacji kodu aplikacji. Dodatkowo użytkownik może wybierać źródła, dla których zdarzeniami jest zainteresowany, twórca aplikacji musi jedynie poinformować użytkownika jakie źródła są dostępne, a później wystarczy już tylko zmiana ustawień w pliku konfiguracyjnym (.config) i zdarzenia są otrzymywane z innego źródła. Co więcej użytkownik może zdarzenia z różnych źródeł kierować do różnych Listener'ów, a dla każdego z nich ustawiać inny poziom logowania. W kolejnej części przedstawię opisany tutaj mechanizm w praktyce.

OPC Unified Architecture (OPC UA), czyli krok na przód.

Prace nad nowym standardem OPC Unified Architecture (OPC UA) nie zostały jeszcze zakończone. Warto jednak już dzisiaj przyjrzeć się temu, co przyniesie nam przyszłość. Zachęcam wszystkich do przeczytania artukułu, w którym opisuję jak będzie wyglądało OPC według Unified Architecture. Artykuł został podzielony na części, wszystkich zachęcam do lektury:

1. Wstęp - idźmy z duchem czasu.
2. Dlaczego czas na nowy standard?
3. Co przyniesie OPC UA?
4. Typowa architektura systemów opartych o OPC Unified Architecture.
5. Jaki krok teraz? (czyli jak ma wyglądać migracja z OPC Classic do OPC Unified Architecture (OPC UA))
6. Podsumowanie (czy damy szansę technologii OPC Unified Architecture?)

Dla tych, którzy czują potrzebę rozszerzenia swojej wiedzy na temat OPC Unified Architecture (OPC UA), polecam książkę: "OPC UA e-book".

OPC UA: Część 6: Podsumowanie (czy damy szansę technologii OPC Unified Architecture?)

Część szósta (ostatnia) serii artykułów poświęconych technologii OPC Unified Architecture (OPC UA) (zobacz część piątą/pierwszą).

OPC Unified Architecture (OPC UA) jest wizją globalnej przenośności (ang. global interoperability), m.in. umożliwienia standardowej wymiany danych pomiędzy różnymi aplikacjami niezależnie od dostawców, z których one pochodzą, języka programowania, systemu operacyjnego lub konkretnego miejsca w którym dana aplikacja jest zlokalizowana. Przynosi rewolucyjne zmiany w stosunku do poprzednich specyfikacji, przez co może się wydawać trudniejsza. Ma to jednak związek przede wszystkim z koniecznością zapoznania się z nowymi technologiami i zerwaniem z niektórymi przyzwyczajeniami. Jednocześnie OPC UA wydaje się być doskonałym sposobem na przeniesienie danych poza warstwę automatyzacji, a dzięki rozbudowanemu i rozszerzalnemu modelowi danych, może stać się kompletną bazą wiedzy na temat obsługiwanego procesu. Aż chciałoby się już natychmiast wdrożyć tą technologię w swoim przedsiębiorstwie. Niestety należy jeszcze chwile poczekać. OPC Foundation nie zakończyła jeszcze prac nad specyfikacją, a status ukończonych ma niespełna połowa z podzielonej na części specyfikacji OPC UA. Ważnym krokiem ku przyszłości jest udostępniony (na razie w wersji beta) przez OPC Foundation pakiet programowy, wspomagający tworzenie oprogramowania zgodnego z OPC UA, zawierający również wrapper, który potrafi udostępniać dane z serwera OPC bazującego na DCOM, poprzez usługi OPC UA. Dostawcy oprogramowania zaczynają mieć pierwsze swoje produkty (w fazach beta) bazujące na szkicu nowej specyfikacji. Technologia prezentowana jest na targach branżowych. Trwają również prace na programem testów zgodności i certyfikacji nowych produktów.

Należy się spodziewać, że przyjdzie nam poczekać jeszcze przynajmniej rok na sfinalizowanie ostatecznej wersji specyfikacji. To ile potrwa później upowszechnienie standardu zależy już przede wszystkim od nas: inżynierów.

OPC UA: Część 5: Jaki krok teraz? (czyli jak ma wyglądać migracja z OPC Classic do OPC Unified Architecture (OPC UA))

Część piąta serii artykułów poświęconych technologii OPC Unified Architecture (OPC UA)(zobacz część czwartą/szóstą).

Kolejnym istotnym zagadaniem, które trzeba poruszyć to migracja aktualnych rozwiązań bazujących na technologii DCOM (coraz częściej nazywanych OPC Classic) do OPC Unified Architecture (OPC UA). Nie należy tutaj zapominać, że starsze, bazujące na DCOM, serwery OPC posiadają odpowiednie interfejsy pozwalające na dostęp do danych procesowych.

Twórcy OPC UA widzą dwie możliwości przejścia na nową technologię:

• stworzenie uniwersalnego serwera, który jest wrapperem dla aktualnych serwerów bazujących na DCOM,
• stworzenie dedykowanych serwerów, które bezpośrednio posiadają dostęp do danych procesowych.

Te dwa podejścia zostały porównane na poniższym rysunku:

Podejście pierwsze skraca bardzo czas implementacji i wdrożenia nowego serwera. Ma to związek z tym, że można wykorzystać istniejące już OPC serwery. W tym celu wykorzystujemy tylko gotowy wrapper serwer (np. udostępniony przez OPC Foundation serwer, który powstał w ramach projektu Early Adopter) i konfigurujemy go, by odczytywał on dane z serwerów OPC bazujących na DCOM. Oczywiście, takie rozwiązanie ma wiele wad. Najpoważniejszym problemem jest to, iż powstający w ten sposób system jest skomplikowany i trudny w utrzymaniu. Nie należy również zapominać, że w przypadku serwerów bazujących na DCOM mamy do rozwiązania zupełnie inne niż dla UA i bardziej skomplikowane zagadnienia związane z bezpieczeństwem. Nie wykorzystamy również wszystkich zalet nowej przestrzeni adresowej (takich jak meta dane, czy referencje pomiędzy obiektami).

Drugi sposób, który zakłada bezpośredni dostęp do danych procesowych, jest o wiele bardziej skomplikowany w implementacji. Wydłuża wdrożenie oraz często wymaga ponownego zaimplementowania stworzonych i wdrożonych już wcześniej mechanizmów. Niemniej jednak to podejście pozwala na uproszczenie struktury całego systemu a co za tym idzie większą niezawodność i łatwiejsze utrzymanie. Pozwala na zmniejszenie ilości zagrożeń dla danego systemu ułatwiając właściwą konfiguracje zabezpieczeń. Daje możliwość wykorzystania wszystkich zalet nowej przestrzeni adresowej, łącznie z meta danymi i referencjami pomiędzy obiektami.

Czytaj dalej.

Zaproszenie na szkolenie– „WPROWADZENIE DO OPC” – AGH Kraków

Firma, w której pracuję jest zaangażowana w różne projekty mające na celu popularyzację technologii OPC oraz OPC Unified Architecture (OPC UA). Jednym ze sposobów, który ma na celu przekazanie wiedzy na temat OPC jest działalność szkoleniowa, a ponieważ w tą działalność jestem mocno zaangażowany, chciałbym wszystkich serdecznie zaprosić na najbliższe szkolenie dotyczące technologii OPC (będę na tym szkoleniu jednym z prowadzących).

W dniach 10 i 11 luty 2009, firma CAS (polski członek OPC Foundation od 2004 roku) organizuje szkolenie pt. „Wprowadzenie do OPC”.

Szkolenie odbędzie się przy współpracy oraz na terenie Akademii Górniczo - Hutniczej w Krakowie.

Szkolenie to dogodna okazja, aby zapoznać się z zagadnieniami technologii OPC (międzynarodowego, ogólnie akceptowanego w przemyśle standardu komunikacyjnego dla systemów przemysłowych) oraz praktycznie przećwiczyć instalację, konfigurację i uruchomienie oprogramowania serwera i klienta OPC na indywidualnych stanowiskach laboratoryjnych w konfiguracji ze sterownikiem przemysłowym.

Dzięki uczestnictwu w szkoleniu będą Państwo mogli:

• zapoznać się z technologią OPC (podstawami działania, technologiami wykorzystywanymi przez OPC),
• pozyskać praktyczną umiejętność obsługi oprogramowania serwera i klienta OPC,
• zainstalować, skonfigurować i uruchomić serwer OPC dla sterownika przemysłowego,
• skonfigurować oprogramowanie do wizualizacji (SCADA) do pozyskiwania danych jako klient OPC,
• poznać możliwość realizacji własnych wdrożeń w technologii OPC, czyli jak stworzyć własny OPC serwer?

Ponadto, w ostatniej części, zostaną wstępnie przedstawione praktyczne aspekty rozwiązań obejmujących następującą problematykę budowy sieci komunikacyjnej:

• redundancja ścieżek komunikacyjnych,
• integracja danych procesowych z wykorzystaniem OPC,
• optymalne wykorzystanie przepustowości łączy do transferu danych procesowych,
• tworzenie symulatora procesu z wykorzystaniem OPC.

Więcej na ten temat można znaleźć na stronie: http://www.commsvr.com/OPCWorkshops.aspx.

Gorąco zapraszam!

OPC, OPC Unified Architecture (OPC UA), gdzie znaleźć informacje na te tematy?

Na tym blogu pojawiła się już garść informacji na temat technologii OPC Unified Architecture (OPC UA), często kontrastowana z danymi dotyczącymi technologii OPC (opartej o DCOM, coraz częściej nazywaną OPC Classic). W tym momencie może się pojawić pytanie: „Skąd brać informacje na ten temat?” lub może: „Jakie jest źródło mojej wiedzy na te tematy?”.

Firma CAS, w której pracuję jest aktywnym członkiem OPC Foundation, organizacji zajmującej się utrzymywaniem i rozwijaniem standardu OPC. Ponadto uczestniczymy w grupie roboczej, która pracuje nad specyfikacjami i oprogramowaniem wspierającym nową specyfikację, czyli OPC Unified Architecture (OPC UA). Naturalnym staje się fakt, że moją wiedzę czerpię właśnie ze stron OPC Foundation, czyli http://www.opcfoundation.org. Niestety nie mam dobrych wieści dla wszystkich zainteresowanych tą tematyką, trzeba być członkiem OPC Foundation, aby uzyskać dostęp do wszystkich zasobów (m.in. takich jak specyfikacje).Mało pocieszającym jest fakt, że znajomość specyfikacji nie jest potrzebna do korzystania z produktów opartych o technologię OPC lub OPC UA. Specyfikacje dotyczą przede wszystkim szczegółów, które opisują jak stworzyć oprogramowanie zgodne z OPC (lub OPC UA), brak w nich porad praktycznych opisujących jak z tego korzystać. Przecież to właśnie informacje na temat wykorzystania, są istotne dla inżyniera, który wdraża lub obsługuje system. Gdzie więc szukać praktycznych informacji? Niestety na rynku polskim nie ma jeszcze książek poświęconych technologii OPC, na różnych stronach internetowych można znaleźć szczątkowe informacje na ten temat, dlatego polecam materiały, które współtworzyłem. Zaliczyć można do nich:

• Baza wiedzy w wortalu CommServer (http://www.commsvr.com), szczególnie interesujący może być dokument dostępny w dziale download: „Podręcznik o OPC”: http://www.commsvr.com/DownloadCenter/Manuals/R050102WprowadzeniedotechnologiiOPC.aspx
• „OPC UA e-book”: Inteligentna książka online z instrukcją użytkownika na temat modelowania przestrzeni adresowej i technologii OPC UA: http://www.commsvr.com/UAModelDesigner/Index.aspx
• Na stronach OPC Foundation znajdują się informacje o dwóch książkach, które można zakupić.
• I oczywiście informacje, które będę zamieszczał na tym blogu :).

Zapraszam do zamieszczania komentarzy do materiałów zamieszczonych na tym blogu, pomoże mi to lepiej dobrać tematykę moich kolejnych postów.

OPC UA: Część 4: Typowa architektura systemów opartych o OPC Unified Architecture.

Część czwarta serii artykułów poświęconych technologii OPC Unified Architecture (OPC UA)(zobacz część trzecią/piątą).

Przyjrzyjmy się nieco architekturze systemów opartych o OPC UA. Przykład takiego systemu został przedstawiony na rysunku poniżej.

Na samym dole znajduje się warstwa procesowa, w której serwerami OPC UA mogą być urządzenia typu: sterowniki przemysłowe, liczniki, czujniki itp. Klientami będą natomiast systemy Typu DCS, systemy typu HMI (zarówno stacjonarne jak i mobilne).

Wyższa warstwa – warstwa operacyjna powinna być oddzielona od warstwy procesowej firewallem, który przepuszcza pakiety dotyczące komunikacji OPC UA lub który agreguje dane z serwerów OPC UA z warstwy procesowej, by następnie udostępnić je warstwom wyższym. OPC UA opisuje koncepcję agregowania danych z wielu serwerów. Serwer agregujący zbiera, łączy i udostępnia dane z jednego lub większej ilości serwerów w swojej przestrzeni adresowej. Dzięki temu klient nie musi podłączać się do wielu serwerów ale do jednego. Ten mechanizm zapewnia elastyczną architekturę, poprzez tworzenie łańcuchów serwerów dla różnych klientów z różnymi wymaganiami. Wsparcie dla agregacji zapewnione jest dzięki funkcji oznakowania pochodzenia danych.

W kolejnej warstwie zwykle znajdują się systemy typu MES lub podobne do nich które dzięki wbudowanemu klientowi OPC UA mają dostęp do danych z warstwy procesowej. Systemy tej warstwy mogą być również wyposażone w serwer OPC UA, przy pomocy którego udostępnione są dane wytworzone, przetworzone lub zagregowane przez te systemy.

Na samej górze znajduje się warstwa korporacyjna, w której konsumentami danych są systemy typu ERP. Systemy te również mają wbudowanego klienta OPC UA (by pozyskiwać dane) i serwer OPC UA (by udostępniać dane). Dzięki temu, że OPC UA może być oparte o web serwisy, możliwe jest dalsze udostępnienie danych poprzez łącze Internetowe, a dzięki zaawansowanym mechanizmom zabezpieczeń możemy mieć dużą pewność, że nikt niepowołany nie będzie miał do nich dostępu.

Czytaj dalej.

OPC UA: Część 3: Co przyniesie OPC UA?

Część trzecia serii artykułów poświęconych technologii OPC Unified Architecture (OPC UA)(zobacz część drugą/czwartą)

Standard OPC Unified Architecture (OPC UA), jest wynikiem wieloletniej współpracy liderów przemysłowych, których celem było stworzenie otwartego standardu wymiany informacji w systemach zarządzania procesem w sposób bogatszy i pełniejszy, zorientowany usługowo i bezpieczny w porównaniu do aktualnie wykorzystywanych standardów bazujących na platformie DCOM. Ten standard to odpowiedź na fundamentalne potrzeby mapowania i wymiany rzeczywistych informacji w sposób zorientowany obiektowo.

Nowy standard został opracowany tak, by nie wiązać go z żadną istniejącą technologią komunikacyjną, specyfikacja przewiduje udostępnianie usług na różne sposoby. Twórcy OPC UA zdają sobie sprawę, że to co nowoczesne dziś, za kilka lat może już wyjść z użycia. Aktualnie specyfikacja przewiduje możliwość wykorzystania jednego z dwóch sposobów komunikacji i jednocześnie pozostawia furtkę, by w przyszłości dodanie innych było możliwe. Pierwszym sposobem jest udostępnienie danych poprzez web serwisy, drugim natomiast są binarne strumienie danych.

OPC UA ma dwoistą naturę, tzn. jest zorientowana obiektowo i usługowo jednocześnie. Natura zorientowano obiektowa powoduje, że OPC UA może być wykorzystywane do wielu celów w warstwie procesowej i zapewnia wsparcie dla zaawansowanych struktur danych i elastyczny model danych. Natura zorientowana usługowo zapewnia lepsze wsparcie w dziedzinie przenośności na różnych platformach, lepszy dostęp i bezpieczeństwo.

Przyjrzyjmy się tym nowym cechom, które są kluczowe dla tego nowego rozwiązania, oto one:

• Wbudowana obsługa danych złożonych (Complex data)
• Zaawansowana przestrzeń adresowa (ang. Address space) – OPC UA pozwala na bardzo dokładne reprezentowanie procesu, które zawiera jego strukturę, opis występujących w nim informacji oraz aktualne wartości określające jego stan..
• Bogaty zbiór usług – Bazowa część specyfikacji OPC UA definiuje podstawowe usługi do przeglądania i tworzenia zapytań o przestrzeń adresową, odczyt i zapis danych, publikowanie i subskrybowanie zdarzeń lub zmian danych. Bazowe specyfikacje OPC UA mają charakter ogólny. Pozostałe funkcje opisane przez aktualne specyfikacje OPC są rozszerzeniami specyfikacji bazowych.
• Skalowalność – w porównaniu do aktualnych (bazujących na DCOM) implementacje OPC UA charakteryzują się większą skalowalności, ponieważ pozwala na reprezentowanie modeli systemów danych o dowolnej wielkości i komplikacji, od modelu całego przedsiębiorstwa lub ich grupy, aż po małe systemy zawierające dane tylko z jednego urządzenia.
• Odporność – OPC UA ma wbudowane rozbudowane mechanizmy diagnostyczne oraz reakcji na błędy z wykorzystaniem redundancji.
• Bezpieczeństwo – szyfrowanie i uwierzytelnianie na poziomie danych z wykorzystaniem infrastruktury klucza publicznego gwarantuje bardzo wysoki poziom bezpieczeństwa.

Należy się spodziewać, że dzięki tym cechom technologia OPC UA będzie dostępniejsza dla systemów ERP czy MES, pozwalając na wyjście OPC poza płaszczyznę automatyzacji.

Brak konieczności wykorzystywania technologii DCOM, która jest komponentem systemu Windows, otwiera możliwości implementacji technologii OPC UA w urządzenia procesowych, takich jak sterowniki przemysłowe, analizatory i inne.

Ostatnim, ale nie najmniej ważnym elementem jest to, że OPC UA oferuje wspólny zestaw usług dla wszystkich istniejących dotąd specyfikacji. Inaczej mówiąc: jeden serwer OPC UA może jednocześnie pełnić rolę serwera DA, HDA, A&E, itp...

Rysunek: Porównanie zakresu oferowanych usług OPC DCOM i OPC UA

Czytaj dalej.

OPC UA: Część 2: Dlaczego czas na nowy standard.

Część druga serii artykułów poświęconych technologii OPC Unified Architecture (OPC UA)(zobacz część pierwszą/trzecią)

Technologia OPC narodziła się w latach 90’tych i zdobyła od tego czasu dużą popularność. Jej dojrzały wiek oraz fakt wykorzystywania jej po dziś dzień, dowodzi że jest to technologia znana i o ugruntowanej pozycji. Jednak wiek ponad dziesięciu lat w systemach IT to bardzo dużo. Może warto coś zmienić?

Aktualne specyfikacje OPC bazują na technologii COM/DCOM. Jej podstawową wadą jego uzależnienie od platformy systemów Windows firmy Microsoft. Dodatkowo DCOM często sprawia szereg problemów konfiguracyjnych przy wdrażaniu nowego systemu i nie pozwalała na komunikację poprzez sieć Internet. Z tych względów technologia DCOM jest aktualnie wypierana przez nowsze technologie. Sam Microsoft, twórca platformy COM/DCOM, prezentując nowe sposoby komunikacji bazującej na technologii .NET przyznał, że dni DCOM’a zdają się być policzone. Świat wybrał inne technologie zorientowane usługowo (Service Oriented Architecture – SOA), a jaki kierunek powinien być wybrany dla OPC?

Pierwszą próbą odejścia od DCOM było powstanie specyfikacji XML DA, w tym rozwiązaniu wywołania funkcji oraz dane procesowe miały być przesyłane przy użyciu standardu XML. Ta jednak nie spotkała się z dużym zainteresowaniem. Powodów mogło być wiele, począwszy od słabej promocji nowego standardu i małej innowacyjności (nowe rozwiązanie nie wnosiło znacząco nowej funkcjonalności), a skończywszy na największej rozgłaszanej wadzie, którą była mniejsza wydajność rozwiązania opartego o XML w stosunku do tego, co oferował DCOM.

DCOM nie jest jednak jedynym mankamentem istniejących specyfikacji. Za kolejną można uznać podział na wiele nie zawsze spójnych specyfikacji (DA, HDA, A&E, DX). Istotny jest też fakt, iż żadna z nich nie pozwala na zapisanie i przedstawienie wszystkich zależności pomiędzy elementami obsługiwanego procesu i brak wsparcia dla jego modelowania. OPC opisuje wiele różnych specyfikacji, które nie mają zunifikowanej przestrzeni adresowej (informacji na temat prezentowanych danych). Dodatkowo coraz częściej użytkownicy końcowi mieli dodatkowe wymagania. Jednym z nich była możliwość utrzymywania programów (często nazywanych komendami (commands)). Kolejnym była potrzeba przechowywanie historii zdarzeń (History for Events). Kłopoty sprawiał też nieuporządkowany model danych, w którym każdy dostawca rozwiązań bazujących na OPC (w tym przypadku zarówno deweloper jak i integrator) umieszczali obiekty w sposób dowolny i wspierający tylko ich wymagania, a użytkownicy coraz częściej nie tylko zainteresowani byli odczytem bądź zapisem struktur (danych) do serwerów OPC, ale również modyfikowaniem przestrzeni adresowej serwera.

Kolejnym elementem podnoszonym podczas dyskusji na temat specyfikacji OPC jest brak związku pomiędzy funkcjonalnościami oferowanymi przez różne typy serwerów. Serwer OPC HDA zatem może udostępniać zupełnie inną przestrzeń adresową niż serwer OPC DA, mimo że oba współpracują z tym samym procesem. Przykładowo te same obiekty w przestrzeni adresowej mogą mieć różne nazwy, a związki między nimi nie są w żaden sposób reprezentowane. Szczególnie kłopotliwy jest z serwer OPC A&E ten również może operować na innej przestrzeni adresowej niż serwer OPC DA (choć w przypadku serwerów DA i A&E powiązanie pomiędzy ich przestrzeniami adresowymi jest bardzo istotne), a osoba odpowiedzialna za integrację i utrzymanie systemu, często zmuszona jest utrzymywać zupełnie różne przestrzenie adresowe dla każdego z serwerów osobno.

Mając na uwadze te wszystkie znane od dawna bolączki standardu OPC, OPC Foundation zaczęło pracę nad projektem nowej zunifikowanej architektury dla OPC (OPC Unified Architecture - w skrócie OPC UA), która zastąpi (w niedalekiej przyszłości), zmodernizuje i rozszerzy dotychczasową funkcjonalność aktualnych interfejsów OPC.

Czytaj dalej.

OPC UA: Część 1: Wstęp - idźmy z duchem czasu.

Część pierwsza serii artykułów poświęconych technologii OPC Unified Architecture (OPC UA)(zobacz część drugą).

Praca inżyniera zajmującego się systemami i informatycznymi lub automatyki przemysłowej wymaga ciągłego dopasowywania się do zmieniającej się rzeczywistości. Trzeba więc ciągle trzymać rękę na pulsie i śledzić pojawiające się nowinki techniczne. Zastanówmy się więc nad odpowiedziami na następujące pytania:

• Jakie są aktualne trendy w tworzeniu systemów informatycznych?
• Czy powinny one zagościć w obszarach związanych z systemami automatyki przemysłowej?

W ostatnim dziesięcioleciu dostawcy oprogramowania tworząc swoje systemy opierają je na architekturze zorientowanej obiektowo i serwisowo (Object Oriented Architecture i Service Orientem Architecture). Dzięki takiemu podejściu systemy te są łatwo skalowalne i łatwo dowodzą swojej niezawodności. Role tych systemów mogą być przeróżne, np. zarządzanie produkcją lub łańcuchem dostaw, wspomaganie planowania i wiele innych. Co ciekawe, wciąż mało z nich korzysta z danych pochodzących z warstwy procesowej. Powodem tego jest fakt, iż aplikacje i systemy najniższej warstwy z dużym opóźnieniem korzystają ze zdobyczy nowych rozwiązań i technologii. Ma to związek z tym, iż ludzie wdrażający takie systemy, najczęściej podchodzą nieufnie do nowych rozwiązań, argumentując, że widzieli już setki podobnych, które się nie sprawdziły. Ponadto często słychać stwierdzenie, że jeśli coś od wielu lat działa i spełnia swoje podstawowe funkcje, to poco to zmieniać, a nuż coś zepsujemy. Dodatkowo aplikacje tej warstwy najczęściej zostały utworzone do akwizycji i przetwarzania prostych informacji, a nie konsumpcji, czy transformacji danych o charakterze złożonym (ang. complex data)). Przecież informacje o pewnym obiekcie, czy procesie to nie tylko surowe i mierzalne dane. Do pełnej analizy potrzebne są informacje o wszystkich związkach wewnątrz danego obiektu, różnego rodzaju meta dane (czyli informacje o danych) oraz informacje o operacjach, jakie można na obiekcie wykonać. Gdyby spróbować opisać złożoną daną w języku specjalistów IT, to obiekt jest zbiorem właściwości (ang. properties) (np. temperatura, ciśnienie, itp.), metod (np. włącz/wyłącz) i zdarzeń (ang. events) (np. temperatura zbyt wysoka). Obiekty takie tworzą hierarchię, te wyżej położone często zawierają w sobie obiekty niższego szczebla itp.

Zaprezentowane wkrótce przeze mnie artykuły mają na celu przybliżyć jedno z rozwiązań, które umożliwia udostępnienie danych procesowych do warstw wyższych: technologii OPC w swej nowej odsłonie, czyli OPC Unified Architecture (OPC UA).

Czytaj następną część

Wstępniak (czyli czego dotyczy ten blog: C#, .NET, OPC i inne) - autor: Maciej Zbrzezny

Nazywam się Maciej Zbrzezny ten blog chciałbym poświęcić aspektom związanym z różnymi technologiami oraz programowaniem. Nie będzie to klasyczny blog, w którym będę opisywał moje codzienne poczynania, a raczej zbiór artykułów w których będę opisywał różne rozwiązania (podejmowane będą różne zagadnienia od bardzo prostych, do bardziej zaawansowanych). Pracuję w firmie CAS (www.cas.eu), w której jestem architektem oprogramowania i programistą. W firmie tworzymy oprogramowanie oparte przede wszystkim o platformę .NET (głównie w języku C#), dlatego przytaczane przeze mnie przykłady będą dotyczyć przede wszystkim C# i .NET. Firma CAS jest aktywnym członkiem OPC Foundation. Tworzone przeze mnie oprogramowanie bardzo często wykorzystuje technologię OPC, dlatego wiele artykułów będzie poświęcone właśnie technologii OPC i jej właśnie powstającego następcy, czyli OPC Unified Architecture (OPC UA). Pewne przykłady będą również dotyczyć oprogramowania z rodziny CommServer (www.commsvr.com) ponieważ jestem współtwórcą tego oprogramowania. Będę poruszał jednocześnie tematy związane z automatyką przemysłową i sposobami jej integracji z systemami warstwy wyższej jak ERP, GIS lub inne, dlatego należy się spodziewać również, że będą się pojawiały zagadnienia związane z ogólnie pojętymi bazami danych i web-serwisami.