Wprowadzenie do technologii OPC

Transkrypt

Wprowadzenie do technologii OPC
Łódź marzec 2016
Copyright CAS 2016.
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
Document
Date
Authors
Version
Type
Document History
Document
Date
Version
1.10
R-05010204-WSTEPDOOPC
29-03-16
Mariusz Postół PH.D.Eng. (project director)
Maciej Zbrzezny M. Sc. Eng.
FINAL
User Manual
Author
Product
release Comment
version
V1.0
CAS
90-527 Łódź ul. Wólczańska 128/134
tel/fax: +48 42 686 25 47; +48 42 686 50 28
www.cas.eu www.commsvr.com
mailto:[email protected]
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............................................................................................................... 10
Wykorzystane Technologie ............................................................................................ 12
COM ...................................................................................................................................................... 12
Interfejsy......................................................................................................................................... 12
DCOM ................................................................................................................................................... 13
DCOMCNFG ................................................................................................................................. 14
OFERTA .......................................................................................................................... 21
Otwórz swoje systemy ... dodaj kolejną opcję ....................................................................................... 21
CAS 90-527 Łódź ul. Wólczańska 128/134
Page: 1
Document: R-050102P05-WstepDoOPC
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: FisherRosemount, 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.
Page: 2
OPC
Porównanie sposobów komunikacji pomiędzy elementami systemu automatyki
Dedykowane sterowniki DDE
OPC
Brak
Brak
Tak
Przenośność
Brak
Ograniczona - zarówno
w standardowym DDE,
jak i w rozszerzeniach
(np. FastDDE,
AdvancedDDE).
Tak
Wydajność
Duża wydajność – ze
względu na optymalizację Mała wydajność. DDE
sterownika dla
opiera się na wymianie
konkretnego urządzenia / wiadomości.
rozwiązania.
Zdalny dostęp
Brak
Standaryzacja
Bardzo duża
wydajność
Tak - przez rozszerzenia,
Tak
takie jak NetDDE.
Brak
Tak
OPC definiuje wiele
metod, które mogą
być użyte do
wymiany
dodatkowych
informacji między
klientem i serwerem.
Programowanie DDE
jest bardzo trudne bez
toolkit'ów oferowanych
przez różnych
producentów.
Programowanie
DCOM może być
skomplikowane.
Dostępne są jednak
różne toolkit'y
znacznie ułatwiające
tworzenie
oprogramowania
OPC.
Interakcja
Zwykle brak
Złożoność
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.
Udział w rynku
Coraz mniejsze
Serwery DDE w
zainteresowanie dla takich przyszłości znikną z
rozwiązań.
rynku.
Rozwiązania OPC
zdominują rynek.
Dany driver jest dostępny
Dostępne tylko dla
zawsze tylko dla
Windows.
określonej platformy.
Dostępne dla
systemów z DCOM.
Tworzona jest
specyfikacja XML,
która uniezależni
OPC od DCOM.
Inne platformy
Page: 3
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:
Page: 4
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
Page: 5
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:
Page: 6
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
Page: 7
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.
Page: 8
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)
Page: 9
OPC
Obiekt
Powiadomienie
o zmianie wartości
Odczyt/zapis
Wywołanie metody
Powiadomienie
o zdarzeniu
Zmienne
____________
____________
____________
Referencje do
innych obiektów
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)
Page: 10
OPC
Klient OPC
Serwer OPC
Warstwa aplikacji:
 Autoryzacja
użytkownika
 Autentykacja
użytkownika
Warstwa komunikacyjna:
 Poufność
 Integralność
 Autentykacja aplikacji
Sesja
Bezpieczny kanał
Warstwa aplikacji:
 Autoryzacja
użytkownika
 Autentykacja
użytkownika
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.
Page: 11
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.
Page: 12
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.
Page: 13
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):
Page: 14
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
Page: 15
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:
Page: 16
Rysunek 14 Zakładki ustawień DCOM dla aplikacji
DCOMCNFG – Właściwości domyślne
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.
Page: 17
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
Page: 18
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
Page: 19
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
Page: 20
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
www.opcfoundation.org.
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 1000000 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
[email protected] .
Page: 21

Wprowadzenie do technologii OPC

Transkrypt

Podobne dokumenty