Wprowadzenie do technologii OPC

Transkrypt

1 Wprowadzenie do technologii OPC Łódź styczeń 2008

2 Copyright CAS The information contained here in is confidential and proprietary to CAS. It may not be disclosed or transferred, directly or indirectly, to any third party without the explicit written permission of CAS. All rights reserved. No part of this document may be reproduced, stored in a retrieval system, translated, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without prior written permission of CAS. Release 1.10 Document R WSTEPDOOPC Date Authors Mariusz Postół PH.D.Eng. (project director) Maciej Zbrzezny M. Sc. Eng. Version FINAL Type User Manual Document History Document Version V1.0 Date Author Product release version Comment CAS Łódź ul. Chodkiewicza 1A tel/fax: ; mailto:techsupp@cas.eu

3 SPIS TREŚCI: Spis treści:... 1 OPC... 2 Krótka historia OPC... 2 Porównanie sposobów komunikacji pomiędzy elementami systemu automatyki... 3 Architektura OPC... 4 Specyfikacje OPC... 6 OPC Data Access (OPC DA)... 6 OPC Historical Data Access (OPC HDA)... 7 OPC Alarms & Events (OPC A&E)... 7 OPC Security... 8 OPC Unified Architecture (OPC UA)... 8 Bezpieczeństwo OPC UA Wykorzystane Technologie COM Interfejsy DCOM DCOMCNFG OFERTA Otwórz swoje systemy... dodaj kolejną opcję CAS Łódź ul. Chodkiewicza 1A Page: 1 Document: R WstepDoOPC

4 OPC OPC OPC jest przemysłowym standardem komunikacji stworzonym przez producentów sprzętu i oprogramowania. Utworzyli oni organizację OPC Foundation, której zadaniem jest rozwijanie tego standardu. W chwili jej członkami jest ponad trzysta firm, wśród nich: CAS, Microsoft, GE, Siemens, Rockwell, ABB. Standard OPC definiuje sposoby komunikacji między urządzeniami przemysłowymi, przez co pozwala uniezaleŝnić oprogramowanie monitorujące i sterujące od producentów sprzętu. Do wielu zalet technologii OPC moŝna zaliczyć m.in.: standaryzację komunikacji i wymiany danych przemysłowych, duŝą uniwersalność i skalowalność rozwiązań, znaczne obniŝenie kosztów integracji duŝych systemów przemysłowych. Krótka historia OPC Wraz z rozwojem oprogramowania i potrzebą wykorzystania go w systemach automatyki przemysłowej, pojawiała się konieczność stworzenia standardowych modułów programowych, gotowych do wykorzystania w wielu systemach i zapewniających komunikację pomiędzy róŝnymi urządzeniami i oprogramowaniem. Brak standardu, jakim jest OPC, powodował konieczność stosowania sterowników dedykowanych. KaŜdy twórca oprogramowania musiał stworzyć własne sterowniki do wszystkich urządzeń, z którym dany program miał współpracować. Wynikało z tego wiele problemów wybór oprogramowania dla danego sprzętu był bardzo ograniczony, a jego tworzenie wymagało większych nakładów czasu i pracy. Wprowadzenie standardu stało się koniecznością. Dynamiczny rozwój systemów z rodziny Windows umoŝliwił powstawanie technologii pozwalających na komunikację komponentów programowych za pośrednictwem standardowych interfejsów. Pierwszym krokiem była technologia DDE (Dynamic Data Exchange), która pojawiła się na przełomie lat 80. i 90. Dzięki niej wymiana danych między aplikacjami stała się łatwiejszą, częściowo uniezaleŝniając oprogramowanie od sprzętu. Szybko okazało się jednak, Ŝe DDE to za mało. Przede wszystkim technologia była mało wydajna, nie oferowała teŝ komunikacji za pośrednictwem sieci. W efekcie opracowane zostały róŝne rozszerzenia dla DDE (np. NetDDE, FastDDE autorstwa Wonderware, czy AdvanceDDE autorstwa Rockwell Software). Nie były one jednak standardem, a jedynie kolejnymi rozwiązaniami autorskimi. W 1992 roku wprowadzono technologię OLE 2.0, która miała z czasem zastąpić większość zastosowań DDE. W tym samym czasie działalność rozpoczęła grupa WinSEM (Windows in Science, Engineering and Manufacturing), zainteresowana wykorzystaniem OLE w systemach przemysłowych czasu rzeczywistego. Mimo przedstawienia paru ciekawych propozycji, nie udało się jej jednak wypracować standardu. W 1995r. uformowała się grupa OPC Task Force, w skład której weszły firmy: Fisher- Rosemount, Intellution, Intuitive Technology, Opto22, Rockwell i Siemens AG. Po intensywnych pracach, w sierpniu 1996 roku opublikowano pierwszą specyfikację OPC. We wrześniu 1996r. powołano do Ŝycia OPC Foundation, która od tamtego czasu koordynuje działania mające na celu utrzymywanie i publikowanie nowych specyfikacji OPC. CAS Łódź ul. Chodkiewicza 1A Page: 2 Document: R WstepDoOPC

5 OPC Porównanie sposobów komunikacji pomiędzy elementami systemu automatyki Dedykowane sterowniki DDE Standaryzacja Brak Brak Tak Przenośność Wydajność Zdalny dostęp Brak DuŜa wydajność ze względu na optymalizację sterownika dla konkretnego urządzenia / rozwiązania. Brak Interakcja Zwykle brak Brak ZłoŜoność Udział w rynku Inne platformy Wielu dostawców oprogramowania zapewnia dodatkowe moduły umoŝliwiające dostosowanie sterownika do określonego zastosowania, jednak utrudnia to wdroŝenie i wymaga dodatkowego czasu na poznanie narzędzi. Coraz mniejsze zainteresowanie dla takich rozwiązań. Dany driver jest dostępny zawsze tylko dla określonej platformy. Ograniczona - zarówno w standardowym DDE, jak i w rozszerzeniach (np. FastDDE, AdvancedDDE). Mała wydajność. DDE opiera się na wymianie wiadomości. Tak - przez rozszerzenia, takie jak NetDDE. Programowanie DDE jest bardzo trudne bez toolkit'ów oferowanych przez róŝnych producentów. Serwery DDE w przyszłości znikną z rynku. Dostępne tylko dla Windows. OPC Tak Bardzo duŝa wydajność Tak Tak OPC definiuje wiele metod, które mogą być uŝyte do wymiany dodatkowych informacji między klientem i serwerem. Programowanie DCOM moŝe być skomplikowane. Dostępne są jednak róŝne toolkit'y znacznie ułatwiające tworzenie oprogramowania OPC. Rozwiązania OPC zdominują rynek. Dostępne dla systemów z DCOM. Tworzona jest specyfikacja XML, która uniezaleŝni OPC od DCOM. CAS Łódź ul. Chodkiewicza 1A Page: 3 Document: R WstepDoOPC

6 OPC W styczniu 2004 roku OPC Foundation stworzyła grupę roboczą, której zadaniem było przygotowanie nowej architektury, zapewniającej dalszy rozwój technologii OPC przez przynajmniej 10 kolejnych lat. Nowa wersja OPC została nazwana OPC Unified Architecture. Pierwsze części jej specyfikacji zostały opublikowane w czerwcu 2006r.; praca nad dokończeniem specyfikacji trwa nadal. Nowa architektura ma bazować na usługach internetowych, łączyć w sobie zalety wszystkich dostępnych aktualnie specyfikacji i odejść od interfejsu opartego o DCOM (przez co stanie się łatwiejsza do implementacji na innych platformach niŝ MS Windows). Architektura OPC OPC zostało zbudowane w oparciu o architekturę klient-serwer. Aplikacja wymagająca dostępu do określonego urządzenia, komunikuje się przez wbudowanego w nią klienta OPC z serwerem OPC, który jest odpowiedzialny za bezpośrednią komunikację z urządzeniem. Rysunek 1 OPC jako rozwiązanie typu klient-serwer Bez OPC kaŝdy klient musiałby posiadać sterownik odpowiedni do komunikacji z danym urządzeniem. Przykładowo, jeśli mamy 3 róŝne urządzenia i chcemy, aby trzech róŝnych klientów pobierało z nich dane, musimy dla kaŝdego klienta zaimplementować sterownik właściwy dla protokołu komunikacji z kaŝdym urządzeniem. Ponadto, jeśli trzech klientów będzie potrzebowało tych samych danych, kaŝde urządzenie wyśle dane wielokrotnie. Rozwiązanie to przedstawia poniŝszy schemat: CAS Łódź ul. Chodkiewicza 1A Page: 4 Document: R WstepDoOPC

7 OPC Rysunek 2 Rozwiązanie bez OPC OPC likwiduje ten problem oddzielając warstwę klienta od urządzenia. W wymianie danych pośredniczy serwer OPC. Nie ma konieczności pisania osobnych sterowników dla kaŝdego klienta, znika teŝ problem wielokrotnego wysyłania danych przez urządzenie, które moŝe korzystać z dowolnego protokołu, np. MODBUS. Rysunek 3 Rozwiązanie z wykorzystaniem OPC CAS Łódź ul. Chodkiewicza 1A Page: 5 Document: R WstepDoOPC

8 OPC Reasumując, z zastosowania standardu OPC płyną następujące korzyści: Zmniejszenie obciąŝenia urządzeń Zwiększenie Ŝywotności urządzeń Zwiększenie skalowalności systemów Serwery OPC mogą przechowywać dane w pamięci podręcznej Klienci OPC nie muszą korzystać ze sterowników urządzeń Standaryzacja Specyfikacje OPC W ramach projektu zajmującego się standaryzacją OPC powstały róŝne specyfikacje, z których kaŝda definiuje odrębną funkcjonalność. Wśród istniejących specyfikacji moŝemy wyróŝnić: OPC Data Access (OPC DA)OPC Historical Data Access (OPC HDA)OPC Alarms & Events (OPC A&E)OPC Security OPC BatchOPC Unified Architecture (OPC UA) OPC Data Access (OPC DA) OPC Data Access umoŝliwia dostęp do aktualnych danych generowanych w czasie rzeczywistym. Przy pomocy OPC DA do serwera OPC kierowane są zapytania o aktualne wartości zmiennych procesowych - temperatur, ciśnień itp. Komunikacja z kaŝdym serwerem odbywa się w taki sam sposób, z wykorzystaniem tego samego formatu. Klient nie musi wiedzieć, w jaki sposób serwer komunikuje się z urządzeniem. Wielu klientów moŝe korzystać jednocześnie z tych samych danych udostępnianych przez serwer. OPC DA daje dostęp (moŝliwość odczytu lub zapisu) do pojedynczych elementów (tagów), z których kaŝdy posiada wartość, znacznik czasowy, typ i jakość. Znacznik czasowy moŝe być generowany przez urządzenie lub przez serwer OPC (jeŝeli dane urządzenie nie generuje znacznika). Przy pomocy OPC DA nie jest moŝliwe przeglądanie wartości wcześniejszych, a jedyne aktualnych. OPC KLIENT GRUPA TAG 1 TAG 2 OPC SERWER URZĄDZENIE TAG 3 WARTOŚĆ ZNACZNIK CZASOWY JAKOŚĆ TYP WŁAŚCIWOŚCI Rysunek 4 Architektura dostępu do zmiennych procesowych przez OPC DA Klient OPC moŝe logicznie podzielić odczytywane dane na grupy, charakteryzujące się np. róŝnymi czasami skanowania (czasem pomiędzy dwoma kolejnymi odczytami), trybem odczytu, itp. Charakterystyczną cechą grupy jest jej odczyt w jednej transakcji. W zaleŝności od wersji OPC DA moŝliwe są dwa tryby odczytu danych: CAS Łódź ul. Chodkiewicza 1A Page: 6 Document: R WstepDoOPC

9 OPC synchroniczny odczyt występuje zawsze w jednakowych odstępach czasowych, asynchroniczny odczyt występuje wtedy, gdy pewne dane ulegną zmianie moŝliwa jest definicja progów, po przekroczeniu których powinien nastąpić odczyt. Dostęp do danych przy pomocy OPC DA moŝe odbywać się na trzy sposoby: z wykorzystaniem COM/DCOM, z wykorzystaniem XML (extensible Markup Language) i protokołu SOAP (Simple Object Access Protocol), za pośrednictwem technologii.net Remoting, posiadającej szersze moŝliwości niŝ DCOM (obsługa róŝnych formatów i protokołów komunikacji, łatwa komunikacja za pośrednictwem Internetu). OPC DA występuje w wielu wersjach, z których najnowszą jest wersja 3.0. (kaŝda wersja zapewnia inny zestaw interfejsów, jednak powinna być zachowana kompatybilność wsteczna). W celu zapoznania się z przykładowym programowaniem wspierającym OPC DA zapraszamy do przyjrzenia się: CommServer otwarty serwer komunikacji, OPC Client Transporter. OPC Historical Data Access (OPC HDA) OPC HDA umoŝliwia przeglądanie i analizę zgromadzonych danych historycznych, np. w celu oceny wydajności systemu, bądź przewidywania błędów. Klient uzyskuje dostęp do zarchiwizowanych danych (odczytów jakiegoś urządzenia itp.) poprzez zgłaszanie zapytań do serwera OPC HDA. Specyfikacja OPC HDA zakłada dwa typy serwerów: Prosty serwer trendów - zapewniający implementację interfejsów koniecznych do dostępu do surowych (nieprzetworzonych) danych pomiarowych. Zaawansowany serwer analiz zapewniający operacje analizy danych (takich jak liczenie średnich, wartości minimalne, maksymalne), odtwarzanie danych, adnotacje, historię odczytów i zmian danych. Specyfikacja zapewnia dostęp do następujących operacji: Odczyt Klient odczytuje dane i informacje z serwera. Zapis/Aktualizacja Klient zapisuje dane lub informacje do serwera. Adnotacje Klient odczytuje lub zapisuje adnotacje do danych w serwerze. Odtwarzanie (Playback) Klient otrzymuje odtwarzane dane historyczne. OPC Alarms & Events (OPC A&E) OPC A&E słuŝy do informowania o występujących w systemie zdarzeniach i zgłaszanych alarmach. Przez alarm rozumiany jest nienormalny stan jakiegoś obiektu, wymagający szczególnej uwagi. Zdarzenie moŝe być związane ze stanem, jak np. zdarzenie przejścia danej wartości do poziomu alarmowego lub niezwiązane ze stanem, jak zmiany konfiguracji, czy błędy systemowe. Serwery OPC A&E mogą pobierać dane bezpośrednio z urządzenia lub z serwera OPC DA. Serwer OPC A&E moŝe być samodzielnym modułem lub teŝ wchodzić w skład serwera OPC DA. Specyfikacja definiuje zdarzenie, którego wystąpienie jest rejestrowane (do zdarzeń mogą np. naleŝeć: awaria urządzenia, przekroczenie wartości granicznej dla pewnej zmiennej procesowej, akcja operatora). RóŜne zdarzenia mogą być przypisywane to pewnej zmiennej, mogą być definiowane róŝne wartości progowe. Specyfikacja zapewnia moŝliwość tworzenia warunków i podwarunków wystąpienia zdarzenia. Serwer OPC A&E powinien zapewniać następujące typy zdarzeń: Zdarzenia zorientowane warunkowo (condition-related events) klient jest informowany o wystąpieniu zdarzenia. Warunki mogą być aktywowane i dezaktywowane. Serwer CAS Łódź ul. Chodkiewicza 1A Page: 7 Document: R WstepDoOPC

10 OPC implementuje równieŝ mechanizm potwierdzania zdarzeń. Zdarzenia śledzone (tracking-related events) są wykorzystywane w celu zapewnienia informacji o wystąpieniach danego zdarzenia (np. interwencji operatora). Zdarzenia proste (simple events) uŝywane w celu powiadomienia klienta o wystąpieniu zdarzenia (np. awarii urządzenia). OPC Security Specyfikacja OPC Security ma słuŝyć zapewnieniu bezpieczeństwa dostępu do danych oferowanych przez serwery OPC. UmoŜliwia poprawną weryfikację klienta, który chce uzyskać dostęp i weryfikację poprawności transmisji (czy dane nie zostały zmienione). Specyfikacja określa trzy poziomy bezpieczeństwa: Disabled security Zabezpieczenia są wyłączone, kaŝdy posiada prawo dostępu. DCOM Security Ustawienie domyślne. Działają jedynie zabezpieczenia DCOM, określające, kto ma prawo dostępu i do jakich aplikacji. Nie ma kontroli nad dostępem do poszczególnych obiektów na serwerze. OPC Security Serwer OPC kontroluje dostęp do poszczególnych obiektów. OPC Unified Architecture (OPC UA) OPC Unified Architecture jest niezaleŝnym od platformy systemowej standardem, który pozwala na komunikację pomiędzy róŝnymi typami systemów i urządzeń poprzez wysyłanie wiadomości pomiędzy klientem a serwerem Poprzednie wersje specyfikacji OPC bazowały na modelu COM/DCOM, co praktycznie uniemoŝliwiało komunikację pomiędzy róŝnymi platformami. Architektura ta została przedstawiona na poniŝszym rysunku (Rysunek 5). OPC Foundation zdecydowała, Ŝe XML moŝe zostać uŝyty do definiowania wiadomości przesyłanych pomiędzy klientem a serwerem. W rezultacie OPC Foundation rozpoczęła pracę nad nową wersją specyfikacji OPC DA nazwaną OPC XML. XML stał się językiem szeroko stosowanym w Internecie i właśnie o ten standard został oparty protokół komunikacyjny SOAP, który bardzo szybko upowszechnił się wśród producentów oprogramowania. Nowa strategia rozwoju OPC została oparta właśnie o język XML i protokół SOAP. Strategia ta została przyjęta juŝ kilka lat temu. Od tego czasu upowszechniły się usługi internetowe, które musiały zostać uwzględnione w nowej strategii rozwoju. Dzięki zastosowaniu ogólnie przyjętych standardów Rysunek 5 Architektura OPC oparta o model COM/DCOM. CAS Łódź ul. Chodkiewicza 1A Page: 8 Document: R WstepDoOPC

11 OPC sieciowych serwer OPC i klient OPC mogły działać na róŝnych platformach. Sytuacja ta została przedstawiona na poniŝszym rysunku (Rysunek 6). Rysunek 6 Architektura OPC UA oparta o usługi internetowe. Efektem przyjętej strategii było powstanie standardu OPC Unified Architecture, który bazuje na ogólnie przyjętych protokołach komunikacyjnych, takich jak TCP/IP, HTTP, SOAP, co zapewnia bardzo duŝą skalowalność rozwiązań implementowanych w oparciu o tę technologię. OPC Unified Architecture umoŝliwia przesyłanie danych za pośrednictwem róŝnych formatów m.in. formatu opartego o XML i formatu binarnego. Serwer OPC zbudowany w oparciu o Unified Architecture definiuje swoim klientom zestaw usług, jakie oferuje oraz format danych procesowych za pośrednictwem, którego ma odbywać się komunikacja. Model obiektowy OPC UA definiuje obiekty jako zmienne i metody, jak równieŝ pozwala na tworzenie relacji pomiędzy obiektami OPC. Model ten został przedstawiony na poniŝszym rysunku (Rysunek 7) CAS Łódź ul. Chodkiewicza 1A Page: 9 Document: R WstepDoOPC

12 OPC Powiadomienie o zmianie wartości Odczyt/zapis Obiekt Zmienne Referencje do innych obiektów Wywołanie metody Powiadomienie o zdarzeniu Metody () () () Rysunek 7 Model obiektu OPC UA. Bezpieczeństwo OPC UA Podczas tworzenia specyfikacji OPC UA połoŝono szczególny nacisk na bezpieczeństwo. Specyfikacja nowej technologii opracowanej przez OPC Foundation jest zgodna ze specyfikacjami WS-* takimi jak: WS-Security, WS-Trust, WS-Policy, WS-Secure Conversation Architektura bezpieczeństwa OPC UA dostarcza rozwiązań pozwalających na implementację rozwiązań zgodnych z następującymi wymaganiami bezpieczeństwa: Przesyłane dane są widoczne tylko dla autoryzowanych uŝytkowników. Dane procesowe mogą zostać zmienione tylko przez autoryzowanych uŝytkowników. Poufność. Śledzenie ruchu. Odporność na ataki typu DoS (ang. denial of service). Mechanizmy bezpieczeństwa OPC UA umieszczone są w warstwie aplikacji i w warstwie komunikacyjnej, na szczycie warstwy transportowej, co zostało przedstawione poniŝej (patrz Rysunek 8) CAS Łódź ul. Chodkiewicza 1A Page: 10 Document: R WstepDoOPC

13 OPC Klient OPC Warstwa aplikacji: Autoryzacja uŝytkownika Autentykacja Warstwa komunikacyjna: Poufność Integralność Autentykacja aplikacji Sesja Bezpieczny kanał Serwer OPC Warstwa aplikacji: Autoryzacja uŝytkownika Autentykacja Warstwa komunikacyjna: Poufność Integralność Autentykacja aplikacji Warstwa transportowa Rysunek 8 Mechanizm bezpieczeństwa standardu OPC UA Zarządzanie sesją uŝytkownika odbywa się w warstwie aplikacji. W warstwie tej działają mechanizmy bezpieczeństwa odpowiedzialne za uwierzytelnianie i autoryzację uŝytkowników. Sesja w warstwie aplikacji jest realizowana poprzez bezpieczny kanał transportowy, który działa w warstwie komunikacji i zapewnia bezpieczną komunikację pomiędzy klientem a serwerem. Wszystkie dane dotyczące sesji są przekazywane do warstwy komunikacyjnej, gdzie są przetwarzane. Warstwa komunikacji dostarcza mechanizmy bezpieczeństwa, które zapewniają poufność, integralność realizowaną poprzez podpisy i autentykację aplikacji dzięki certyfikatom. Dane zabezpieczone w warstwie aplikacji są następnie przesyłane poprzez warstwę transportową, która jest odpowiedzialna za transmisję danych pomiędzy klientem a serwerem. CAS Łódź ul. Chodkiewicza 1A Page: 11 Document: R WstepDoOPC

14 Wykorzystane technologie WYKORZYSTANE TECHNOLOGIE COM COM (Component Object Model) 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. Technologia COM jest wykorzystywana w wielu aplikacjach, jak np. Microsoft Office, gdzie umoŝliwia dynamiczne łączenie elementów np. z arkusza MS Excel do dokumentów edytora MS Word. Component Object Model definiuje: binarny standard wywoływania funkcji między komponentami, struktury interfejsów udostępnianych przez poszczególne obiekty, mechanizmy jednoznacznej identyfikacji komponentów i ich interfejsów. Interfejsy Obiekty COM udostępniają swoje funkcje obiektom zewnętrznym za pośrednictwem interfejsów. Interfejs stanowi zbiór wskaźników do funkcji składowych komponentu COM (metod), zgromadzonych w tabelach vtable (Virtual Function Pointer Table). Interfejs nie jest klasą, nie posiada własnej implementacji, to komponent COM implementuje interfejs. KaŜdy komponent moŝe implementować wiele interfejsów - oferować wiele zestawów usług. Komponenty odwołują się do interfejsów za pośrednictwem wskaźników. KaŜdy interfejs posiada własny, unikalny identyfikator (GUID). Nowa wersja interfejsu (np. z rozszerzonym zestawem funkcji) nie powoduje konfliktu ze starą wersją - otrzymuje ona inny GUID. Rysunek 9 Interfejsy obiektu COM GUID (Global Unique Identifier) jest 128-bitowym numerem jednoznacznie identyfikującym obiekty. Identyfikatory CLSID odnoszą się do obiektów COM, a IID do interfejsów. IUnknown Podstawowym interfejsem implementowanym przez kaŝdy obiekt COM jest interfejs IUnknown, udostępniający trzy funkjce: QueryInterface, AddRef, Release. CAS Łódź ul. Chodkiewicza 1A Page: 12 Document: R WstepDoOPC

15 Wykorzystane technologie Rysunek 10 Interfejs IUnknown Funkcja QueryInterface pozwala uzyskać dostęp do informacji o innych interfejsach danego obiektu. Jej składnia jest następująca: HRESULTQueryInterface(REFIIDiid,void**ppvObject); iid - [in] identyfikator Ŝądanego interfejsu ppvobject - [out] wskaźnik do Ŝądanego interfejsu Gdy interfejs jest dostępny, funkcja zwraca wartość S_OK. W przypadku, gdy interfejs nie jest zaimplementowany, zwracana jest wartość E_NOINTERFACE. Funkcje AddRef i Release zarządzają licznikiem referencji do interfejsów. AddRef jest wywoływana, gdy komponent uŝywa danego interfejsu, i zwiększa licznik o 1. Release jest wywoływana, gdy komponent nie potrzebuje juŝ interfejsu, i zmniejsza licznik. Obie zwracają nową wartość licznika referencji. Funkcje QueryInterface, AddRef i Release są dostępne w kaŝdym interfejsie COM, gdyŝ kaŝdy interfejs dziedziczy po IUnknown. Mechanizm interfejsów pozwala na łatwe dodawanie nowej funkcjonalności do istniejących obiektów poprzez implementację nowych funkcji lub całych interfejsów przy zachowaniu kompatybilności z obiektami korzystającymi ze starszych funkcji/interfejsów. Równie proste jest usprawnianie istniejącej funkcjonalności przez wprowadzanie poprawek w implementacji obecnych funkcji. DCOM Technologia DCOM jest rozszerzeniem technologii COM, 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ą komunikację 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. CAS Łódź ul. Chodkiewicza 1A Page: 13 Document: R WstepDoOPC

16 Wykorzystane technologie Rysunek 11 Architektura DCOM 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. DCOMCNFG Dcomcnfg jest programem pozwalającym na skonfigurowanie w rejestrze systemu ustawień dotyczących COM. Jest obecny w systemach z rodziny Microsoft Windows NT. Przy pomocy dcomcnfg moŝna: ustawić uprawnienia dla serwerów, globalnie lub dla kaŝdej aplikacji z osobna, zdefiniować konta uŝytkowników, z których będą uruchamiane serwery, skonfigurować poziom bezpieczeństwa dla połączeń między aplikacjami, dezaktywować DCOM dla całego komputera lub poszczególnych aplikacji. Po uruchomieniu dcomcnfg dostępne jest okienko z kilkoma zakładkami lub drzewem komponentów (w zaleŝności od wersji systemu): CAS Łódź ul. Chodkiewicza 1A Page: 14 Document: R WstepDoOPC

17 Wykorzystane technologie Rysunek 12 DCOMCNFG - okno główne (po stronie lewej z Windows 2000, a po stronie prawej z Windows XP i nowszych Podstawowe sprawy, o których naleŝy pamiętać: Ustawienia po stronie klienta muszą zezwalać serwerowi na dostęp, by mógł przesyłać Ŝądane dane. Ustawienia po stronie serwera muszą zezwalać klientom na dostęp i uruchamianie, aby umoŝliwić klientom dostęp do serwerów i pobieranie danych, a takŝe uruchomienie, gdy serwer nie jest aktywny. DCOMCNFG Zakładka Aplikacje Zakładka Aplikacje lub główne okno programu w przypadku Windows XP (i nowszych) pozwala na zmianę ustawień dotyczących konkretnej aplikacji. Ustawienia te przesłaniają konfiguracje domyślne. Po wybraniu interesującego nas obiektu i wciśnięciu przycisku Właściwości ukazuje się okienko konfiguracji DCOM dla danego programu. W celu zmiany ustawień naleŝy odszukać na liście wybraną aplikację, a następnie dwa razy kliknąć lub prawym przyciskiem wybrać właściwości. Pojawi się wówczas okno pozwalające na konfiguracje DCOM a dla danego komponentu. Na poniŝszym rysunku zostało przedstawione okno z Windows CAS Łódź ul. Chodkiewicza 1A Page: 15 Document: R WstepDoOPC

18 Wykorzystane technologie 2000 i XP: Rysunek 13 DCOMCNFG - okno aplikacji (po prawej stronie z Windows XP) Okno zawiera zakładki: Ogólne (General) - informacje o aplikacji, dla której ustawiamy DCOM oraz poziom uwierzytelnień. Lokalizacja (Location) - określa lokalizację, w której ma działać aplikacja, gdy klient stworzy nową instancję. Zabezpieczenia (Security) - ustawienia poziomu bezpieczeństwa dla danej aplikacji, (naleŝy wybrać, czy chcemy korzystać ze standardowych ustawień, których konfiguracja będzie opisana dalej, czy teŝ dana aplikacja ma mieć specyficzne dla niej ustawienia. ToŜsamość (Identity)- ustawienia uŝytkownika, który będzie uŝywany do uruchamiania aplikacji. Punkty końcowe (Endpoints) - zestaw protokołów, których mogą uŝywać klienci tego serwera. PowyŜsze elementy są odpowiednikami ustawień globalnych o tych samych nazwach i zostaną opisane w dalszej części. Na poniŝszym rysunku przestawiono kolejne zakładki: CAS Łódź ul. Chodkiewicza 1A Page: 16 Document: R WstepDoOPC

19 Wykorzystane technologie DCOMCNFG Właściwości domyślne Rysunek 14 Zakładki ustawień DCOM dla aplikacji W zakładce Właściwości domyślne (dla Windows 2000) oraz w oknie właściwości dla komputera (dla Windows XP i nowszych) ustawiamy globalne właściwości modelu DCOM na tym komputerze. CAS Łódź ul. Chodkiewicza 1A Page: 17 Document: R WstepDoOPC

20 Wykorzystane technologie Rysunek 15 DCOMCNFG - zakładka właściwości domyślnych UŜytkownik powinien tutaj ustawić: Czy zamierza wykorzystywać model DCOM na tym komputerze (domyślnie tak) Czy chce uruchomić usługi internetowe na tym komputerze (domyślnie nie) Wybrać domyślny poziom uwierzytelnień Wybrać domyślny poziom personifikacji CAS Łódź ul. Chodkiewicza 1A Page: 18 Document: R WstepDoOPC

21 Wykorzystane technologie DCOMCNFG Zabezpieczenia domyślne Zakładka Zabezpieczenia domyślne pozwala na zdefiniowanie domyślnych uprawnień obiektów istniejących w systemie. Podzielona jest na trzy sekcje: Domyślne uprawnienia dostępu kto będzie miał dostęp do aplikacji, które nie zapewniają własnych uprawnień. Domyślne uprawnienia uruchamiania jak wyŝej, ale dotyczy praw uruchamiania aplikacji. Domyślne uprawnienia konfiguracji kto ma uprawnienia do modyfikowania konfiguracji, instalacji nowych serwerów itp. Rysunek 16 DCOMCNFG - zakładka zabezpieczeń domyślnych CAS Łódź ul. Chodkiewicza 1A Page: 19 Document: R WstepDoOPC

22 Wykorzystane technologie Nowym elementem w przypadku systemów Windows XP SP2 i nowszych są limity. Limity mają nadrzędne znaczenie. To tam definiowane jest, kto (jaki uŝytkownik, jaka grupa) ma uprawnienia do uruchamiania lub dostępu do komponentów DCOM oraz w jaki sposób (lokalny, czy zdalny). Wszelkie ustawienia są wykonywane przy pomocy standardowych kontrolek Windows, za pomocą których konkretnemu uŝytkownikowi lub konkretnej grupie przypisujemy albo odmawiamy pewnych uprawnień. DCOMCNFG Protokoły domyślne Zakładka Protokoły domyślne określa, z jakich protokołów ma korzystać DCOM i w jakiej kolejności. W przypadku listy protokołów, DCOM będzie sprawdzał po kolei wszystkie, aŝ do ostatecznego wyczerpania limitu czasu. Rysunek 17 DCOMCNFG - zakładka protokołów domyślnych CAS Łódź ul. Chodkiewicza 1A Page: 20 Document: R WstepDoOPC

23 Wykorzystane technologie OFERTA Otwórz swoje systemy... dodaj kolejną opcję Konieczność uniezaleŝnienia się od dostawców oraz ochrona inwestycji zmusza do stosowania standardów. Technologia OPC, stworzona z wykorzystaniem dobrze znanego modelu łączenia komponentów OLE COM/DCOM, jest praktycznie jedynym powszechnie stosowanym standardem wymiany danych procesowych pomiędzy urządzeniami w systemach automatyki przemysłowej, z wykorzystaniem sieci komputerowej. Jego stosowanie gwarantuje otwartość i kompatybilność rozwiązań róŝnych producentów. Więcej informacji na temat OPC znajdziecie Państwo na stronie Poszukujemy wśród dostawców i integratorów systemów automatyki firm zainteresowanych rozszerzeniem funkcjonalności oferowanych rozwiązań o komponenty komunikacyjne zgodne ze standardem OPC. Jako aktywny członek OPC Foundation, organizacji zrzeszającej producentów i uŝytkowników produktów zgodnych ze standardami OPC, zapewniamy moŝliwość wejścia do grona dostawców tej technologii, przy minimalnych kosztach migracji. Jesteśmy zainteresowani podjęciem współpracy w zakresie konsultacji, tworzenia, testowania i certyfikacji Waszych produktów w technologii OPC. Dysponujemy wieloletnim doświadczeniem, narzędziami i bibliotekami oprogramowania zawierającymi ponad linii kodu do wykorzystania wg potrzeb. Posiadamy gotowe produkty OPC, które mogą wzbogacić Państwa ofertę w zakresie rozwiązań dla systemów automatyki. Jesteśmy gotowi do przeprowadzenia szkolenia i prezentacji moŝliwości technologii OPC. Proponujemy: Tworzenie serwerów OPC dla stacji obiektowych, sterowników i urządzeń programowalnych (OPC Data Access, OPC Historical Data Access, OPC Alarms & Events) Tworzenie specjalistycznych klientów OPC do przetwarzania, rejestracji i akwizycji danych Tworzenie specjalistycznych modułów transferu danych OPC Data exchange Tworzenie modułów uniwersalnej ekspozycji danych OPC XML-DA Prowadzenie testów OPC Compliance - kompatybilności produktu z technologią Prowadzenie procesu certyfikacji zgodności z OPC dla produktów Testowanie produktów podczas międzynarodowych spotkań OPC Interoperability Workshops Zainteresowanych prosimy o kontakt w celu omówienia moŝliwości i warunków współpracy commserver@commserver.eu. CAS Łódź ul. Chodkiewicza 1A Page: 21 Document: R WstepDoOPC