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.