Integracja Systemów Sterowania OPC

Transkrypt

1 1

2 Plan Potrzeba Wymiana danych między aplikacjami COM /DCOM Data Access Specification Automation Interface DA DML UA Demo 2

3 Komunikacja niezestandaryzowana Potrzeba standardu 3

4 Potrzeba standardu 4

5 Wymiana danych między aplikacjami Schowek (clipboard) wprowadzony przez Microsoft (1987) wymiana danych poprzez bufor pamięci; przenoszenie danych ma charakter statyczny; zmiany nie są automatycznie przenoszone; DDE (1987) pochodzi od Microsoftu serwer i klient wymieniające dane i komendy; dynamiczne połączenie umożliwiające powiadamianie klienta o zmianach danych w serwerze OLE 1 (1992, Object Linking and Embedding) żyjące połączenie między obiektami aplikacji; zmiany są automatycznie transferowane (linking) i mogą być edytowane przez aplikację docelową (embedding); wykorzystywał DDE do transferu informacji OLE 2 (1995) nazywany też COM; zdefiniowany nie tylko do interakcji między dokumentami tekstowymi, ale między dowolnymi programami DCOM (1996) wymiana danych miedzy komponentami różnych komputerów W systemach UNIX RPC Protokoły sieciowe np. TCP/IP Wymiana danych między aplikacjami 5

6 COM (Component Object Model) Struktura informatyczna umożliwiająca budowę aplikacji z komponentów różnych producentów Binarny standard zapewniający wzajemną komunikację komponentów niezależnie od tego na jakim pracują komputerze, pod kontrolą jakiego systemu operacyjnego oraz w jakim języku były tworzone i są wykorzystywane, dostępny dla wielu platform (MSWindows, Apple, Unix), Dynamiczne ładowanie komponentów Komunikacja z komponentami również poprzez sieć (DCOM) Powyżej COM zdefiniowane są usługi wyższego poziomy jak np. OLE lub. Geneza: możliwość powtórnego użycia (ang. reusebility) komponentów binarnych Obiekty COM są enkapsulowane nie ma dostępu do szczegółów implementacyjnych komponentu. COM ma cechy czarnej skrzynki gdzie szczegóły implementacyjne są ukryte wewnątrz komponentu binarnego Definicje: obiekt fragment skompilowanego kodu dostarczający pewnych usług; w przypadku COM używany zamiennie z obiekt komponentu lub komponent COM / DCOM 6

7 COM (Component Object Model) Problem współpracy komponentów tworzonych przez różnych producentów: Jak twórca ma utworzyć unikalny komponent zdolny do współpracy z komponentami innych producentów? Jak uaktualnić komponent bez uaktualniania całego systemu? Jak zapewnić niezależność od języka programowania? Jak zbudować komponent pracujący jednocześnie in-process, crossprocess i cross-network Jak zapewnić wysoką wydajność tak aby można był tworzyć małe komponenty typu elementów GUI? C++ reusable ale w formie źródeł, LIB binaria ale wymagają kompilacji, DLL binaria ale nie eksponuję eksportowany funkcji. LIB/DLL zależą od języka programowania oraz sposobu kompilacji. Nazewnictwo funkcji w DLL zawiera wiele dekoracji szczególnie dla polimorficznych funkcji w językach obiektowych. Uaktualnianie DLL może doprowadzić do załamania aplikacji. Istnieją komponenty binarne Java ale mogą być używane tylko w Java. COM / DCOM 7

8 COM (Component Object Model) Podstawowe zasady COM/DCOM: Binarny standard wywoływania funkcji między komponentami, Grupowanie funkcji w interfejsy Aplikacja dynamicznie wykrywa interfejsy komponentów Zliczanie odwołań, umożliwiające śledzenie cyklu życia komponentu i samodzielne usuwanie Unikalna identyfikacja komponentów i interfejsów Ładowacz komponentów zarządzający ich iteracjami COM / DCOM 8

9 Binarny standard wywoływania funkcji między komponentami Zdefiniowany sposób ułożenia funkcji wirtualnych w tablicy (vtables) i ich wywołania przez tę tablicę. Taki sposób (zapożyczony wprost z C++) umożliwia implementacje funkcji wirtualnych powtórnie implementowanych w pochodnych interfejsach (funkcja wirtualna może być powtórnie realizowana w klasach pochodnych). Zmienna klienta Obiekt komponentu VTBL pointer Dane prywatne VTBL pointer to function pointer to function pointer to function function(pobj, a1, a2) {... } Podwójne odwołanie (wskaźnik do tablicy wskaźników na funkcje) umożliwia współdzielenie tablicy vtable między wystąpienia tego samego obiektu. Nie są współdzielone dane prywatne. COM / DCOM 9

10 Grupowanie funkcji w interfejsy Interfejs grupuje metody udostępniane przez komponent. Całkowita enkapsulacja dostęp do danych prywatnych wyłącznie przez funkcje interfejsu. Komponent może posiadać wiele interfejsów. Nazwy interfejsów zaczynają się od litery I. Klient ma do dyspozycji tylko wskaźnik przez który może się dostać do metod interfejsu. Każdy interfejs ma swój globalnie unikalny ID (GUID). Nowa wersja interfejsu (np. po dodaniu nowych funkcji) to całkiem nowy interfejs bo ma nowy GUID. Wywołanie interfejsu na zdalnym komputerze jest całkowicie przezroczyste dla klienta i nie ma różnicy w wywołaniu zdalnym oraz lokalnym. Identyfikatory GUID są 128-bitowe i są globalnie unikalne. Dla wygody każdy ma dodaną lokalnie czytelną nazwę. Odpowiednie narzędzia generują GUID (guidgen.exe używa adresu Ethernetowego karty, czasu, itp.). CLSID to GUID odnoszący się do komponentów a IID for GUID dla interfejsów. const IID BASED_CODE IID_DRTDAC4PCIEvents = { 0x20cad05c, 0x8464, 0x4b01, { 0x82, 0xcf, 0x41, 0x85, 0x87, 0x4, 0x30, 0xa7 } }; Jeżeli nie jest znany CLSID do obiektu można odwoływać się przez ProgID. COM / DCOM 10

11 Interface IUnknown Grupowanie funkcji w interfejsy Musi być zaimplementowany w każdym komponencie. Posiada 3 metody: interface IUnknown { } virtual HRESULT QueryInterface(IID& iid, void** ppvobj) = 0; virtual ULONG AddRef() = 0; virtual ULONG Release() = 0; AddRef oraz Release są licznikami użytkowania interfejsu. Jeżeli wewnętrzny licznik osiągnie wartość zero komponent może rozładować się z pamięci (zliczanie odwołań, umożliwiające śledzenie cyklu życia komponentu i samodzielne usuwanie ). QueryInterface umożliwia sprawdzenie czy dany interfejs jest udostępniany przez komponent oraz uzyskanie do niego wskaźnika. COM udostępnia całą wiedzę o dostępnych metodach poprzez uzyskanie wskaźników do innych funkcji interfejsu. COM / DCOM 11

12 Grupowanie funkcji w interfejsy IUnknown IMyInterface Interfejs to zbiór funkcji. Funkcje ujawniają co robią gdy są wywoływane to swoisty kontrakt między komponentem a klientem COM. Zmiana kontraktu jest niemożliwa. Raz opublikowany interfejs (z nadanym unikalnym identyfikatorem) nie może być zmodyfikowany (można zmienić implementację funkcji). Nowa wersja obiektu oznacza konieczność dodania nowego interfejsu z nowymi funkcjami. Interfejsy COM są dziedziczone nowy może uzyskać funkcje starego. COM staje się np. kontrolką ActiveX jeżeli ma zdefiniowane standardowe dla kontrolki interfejsy (>10). Podobnie OLE czy. Interfejs IUnknown jest dziedziczony do wszystkich innych interfejsów. Każdy interfejs ma więc trzy funkcje z interfejsu IUnknown. Znaczenie argumentów i wartości zwracanych przez metody zależy od aplikacji. Składnia metod interfejsów definiowana jest w języku IDL (Interface Definition Language). COM / DCOM 12

13 Ładowacz komponentów zarządzający ich iteracjami Component Object Library komponent systemowy umożliwiający zlokalizowanie oraz łączność między komponentami. Umożliwia wywołania IUnknown. Rejestracja komponentów umożliwia ich identyfikacje dzięki CLSID. Wywołania komponentów między procesami (a nawet komputerami o innych systemach operacyjnych) angażują RPC. RPC jest wywoływane przez mechanizm COM w sposób przezroczysty. Współpraca z lokalnymi lub zdalnymi komponentami przebiega identycznie. Trzy typy obiektów: in process (DLL), local (EXE w osobnym procesie na tej samej maszynie) oraz remote (DLL lub EXE na innym komputerze). Wykorzystanie obiektu COM przez klienta jest w każdym przypadku identyczne. Wpisy w rejestrach: HKEY_CLASSES_ROOT\CLSID\{AD CB9-A812-F53682F53400}] = "RTDAC4PCI Control" InprocServer32 = "C:\\RTDAC4PCI.OCX" ProgID = "InTeCo.RTDAC4PCICtrl.1" TypeLib = "{47DC927B-DC37-45AF-90FD-9FD6AAD6A04F}" [HKEY_CLASSES_ROOT\InTeCo.RTDAC4PCICtrl.1] = "RTDAC4PCI Control" CLSID = "{AD CB9-A812-F53682F53400}" COM / DCOM 13

14 Proxy / Stub DCOM wywodzi się również z potrzeby przetwarzania informacji w sieciach heterogenicznych (różne komputery, różne SO, różne języki projektowania, komunikacja po różnych sieciach). W systemach typu UNIX od lat znany jest RPC (DCOM jest obiektową wersją RPC).Przetwarzanie niezależne od ww. czynników wymaga przekazania parametrów (to tzw. marshaling/demarshaling przekształcenie parametrów z formy zależnej od procesu do formy niezależnej od procesu, SO oraz sieci)) oraz zaadresowania metod. Dwa komponenty proxy oraz stub wspierają komunikację klient-serwer (proxy po stronie klienta, stub po stronie serwera). Klient nie wywołuje bezpośrednio serwera (ze względu na potencjalne różnice między platformami) ale wywołuje metody w proxy (tutaj robiony marshaling). Następnie poprzez środowisko run-time jest to przekazywane do stub gdzie robiony jest demarshaling i wywoływana jest metoda bezpośrednio z serwera. Podczas wywoływania callback proces przebiega w odwrotnym kierunku. Proxy i stub mogą pracować na różnych komputerach wykonując np. konwersje reprezentacji liczb INTEGER (bigendian vs. little-endian). W DCOM i Windows proxy i stub mają formę DLL. Interfejsy definiowane są w języku IDL (Interface Description Language). Kompilatory IDL generują z plików IDL odpowiednie pliki C. Te pliki tworzą wspomniane DLL-e. Zaletą rozwiązania jest,że komponenty mogą być implementowane w różnych językach i wszystko czego potrzebują jest dostęp do DLL (nie muszą zapewniać wymiany i konwersji danych). COM / DCOM 14

15 COM / DCOM uznany przez Microsoft za przestarzały (ang. depreciated). Aktualnie wspierany.net COM / DCOM 15

16 (OLE for Process Control) (Openness Productivity Collaboration) standard umożliwiający wygodny i efektywny sposób połączenia sprzętowych i programowych elementów automatyki Zarządzany przez międzynarodową organizację ( Członkami wszyscy liczący się producenci urządzeń oraz oprogramowania dla automatyki Foundation adaptuje istniejące technologie o otwartym charakterze (nie tworzy nowych) dla potrzeb automatyki. bazuje na DCOM Specification 1.0 pojawiło się w Powstało Foundation. Dostępne specyfikacje: Data Access Specification mechanizmy odczytu i zapisu danych procesowych czasu rzeczywistego (danych aktualnych). Ciągła komunikacja wyrządzeń pomiarowo wykonawczych, PLC i DCS z oprogramowaniem do bieżącej prezentacji (HMI SCADA) Alarms and Events Specification monitorowanie i przetwarzanie alarmów i zdarzeń. Strumień danych nie ma charakteru ciągłego 16

17 Historical Data Access Specification udostępnianie danych historycznych (danych które zostały już zapisane) Data exchange wymiana danych typu serwer-serwer, a nie klientserwer Security Specification strategie bezpieczeństwa w komponentach; ochrona przed nieautoryzowanym dostępem lub modyfikację danych Batch Specification zarządzanie produkcją wsadową and XML wykorzystanie XML w komponentach... i ciągle trwają prace nad nowymi 17

18 interoperatywność (zdolność wspólnego działania, ang. interoperability) dzięki standardowi komunikacji umożliwia uniezależnienie oprogramowania (SCADA, logowanie danych, sterowanie bezpośrednie) od producentów sprzętu w automatyce spełnia taką rolę jak w systemie operacyjnym sterownik drukarki 18

19 Serwer Klient Interfejs Interfejs DCOM Sieć DCOM uzależnia od Microsoft 19

20 wyróżnia dwa rodzaje interfejsów: custom oraz automation. Interfejsy typu custom są wykorzystywane w językach posiadających wskaźniki do funkcji (np.c). Języki nie posiadające wskaźników do funkcji (np. VB, PHP) wykorzystują interfejsy typu automation (tu metody nie są wywoływane przez wskaźniki do funkcji lecz przez ich nazwy). Automation Wrapper to DLL wykonujący odpowiednie konwersje. Program w VBA/PHP/... Interfejs automation Automation Wrapper Program w C++ Program w C++ Interfejs custom Lokalny/zdalny serwer Serwer cache Urządzenie 20

21 serwer musi mieć zaimplementowany interfejs typu custom oraz opcjonalnie może posiadać interfejs automation. Jeżeli nie ma interfejsu automation można wykorzystać Automation Wrapper. Interfejs automation umożliwia dostęp do serwera za pomocą składni typu Obiekt.Metoda lub Obiekt.Własność Obiekty DCOM rozpoznawane są przez CLSID. Jest mało praktyczne branie CLSID z dokumentacji serwera i przesyłanie jej do klienta. Każdy serwer posiada co najmniej trzy wpisy w rejestrze: 1. ProgID (Program Identifier) Łańcuch w formie <Producent>.<NazwaSerwera> opisujący komponent 2. CLSID 128 bitów identyfikujące serwer; zmiany w komponencie (np. dodanie obiektów) wymagają nowego CLSID 3. AppID (Application ID) opis serwera w postaci łańcucha (to praktyczny sposób odwołania do serwera) 21

22 Dodatkowo CATID (Category ID) opisują kategorie poszczególnych specyfikacji. Data Access Specification 1.0A Data Access Specification 2.0 Data Access Specification 3.0 Alarms and Events Specification 1.01 Batch Specification 1.0 Historical DA Specification 1.0 {63D5F430-CFE4-11D1-B2C BA1FB} {63D5F432-CFE4-11D1-B2C BA1FB} {CC D7-48F1-B69A-B625E73652D7} {58E13251-AC87-11D1-84D CB8A7E9} {A8080DA0-E23E-11D2-AFA7-00C04F539421} {7DE5B060-E089-11D2-A5E } W rejestrze jest komplet informacji o serwerach na danym komputerze. W przypadku zdalnych komputerów można przeczytać zdalny rejestr lub (WYGODNIEJ) wykorzystać bezpłatny DCOM o nazwie ServerBrowser. Można te operacje wykonywać również dla lokalnego komputera. 22

23 Przykładowe zależności w rejestrach dla ifix serwer. Klucz wyróżnia serwery (choć oczywiście każdy może wykonać wpis w rejestrze i utworzyć taki klucz) 23

24 Dla local server (EXE): HKEY_CLASSES_ROOT\MyVendor.ServerName.1 = My Server Description HKEY_CLASSES_ROOT\MyVendor.ServerName.1\CLSID = { Your Server s unique CLSID } HKEY_CLASSES_ROOT\CLSID\{ Your Server s unique CLSID } = My Server Description HKEY_CLASSES_ROOT\CLSID\{ Your Server s unique CLSID }\ProgID = MyVendor.ServerName.1 HKEY_CLASSES_ROOT\CLSID\{ Your Server s unique CLSID }\LocalServer32 = c:\fullpath\myserver.exe Dla Inproc server (DLL): HKEY_CLASSES_ROOT\MyVendor.ServerName.1 = My Server Description HKEY_CLASSES_ROOT\MyVendor.ServerName.1\CLSID = { Your Server s unique CLSID } HKEY_CLASSES_ROOT\CLSID\{ Your Server s unique CLSID } = My Server Description HKEY_CLASSES_ROOT\CLSID\{ Your Server s unique CLSID }\ProgID = MyVendor.ServerName.1 HKEY_CLASSES_ROOT\CLSID\{ Your Handler s unique CLSID }\InprocServer32 = c:\fullpath\myserver.dll 24

25 cechy wspólne dla wszystkich serwerów ( Common Definitions and Interfaces) Specyfikacja umożliwia lokalizacje informacji o błędach zwracanych przez serwer. Metoda QueryAvailableLocaleIDs umożliwia klientowi stwierdzenie ID języków wspieranych przez serwer. SetLocaleID wybiera język i kolejne wywołania GetErrorString zwracają komunikaty w wybranym języku. DCOM domyślnie pracuje na ciągach znakowych UNICODE może więc pracować w dowolnym zestawie znaków (wliczając symbole techniczne). Klient może zarejestrować swoją nazwę po połączeniu z serwerem funkcją SetClientName. Jeżeli serwer jest zamykany gdy występują aktywne połączenia z klientami wówczas serwer wysyła do klientów odpowiednie komunikaty. Klucz \HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs C:\WINNT\System32\PROXY.DLL=5 C:\WINNT\System32\ENUM.EXE=3 zawiera informacje o liczniku aplikacji używających wspólnych plików (np. server browser, proxy/stub, itp.) 25

26 cechy wspólne dla wszystkich serwerów ( Common Definitions and Interfaces) Komponent Server Browser Zaimplementowany w ENUM.EXE. Implementuje interfejs IServerList. Umożliwia odszukanie serwerów na danym komputerze i udostępnienie tej informacji zdalnemu klientowi. Plik ENUM.EXE wraz z odpowiednim proxy/stub COMN_PS.DLL są dostępne bezpłatnie na ENUM /RegSerwer instalacja komponentu ENUM /Service instalacja jako serwisu REGSVR32 Comn_ps.dll rejestracja proxy/stub Server Browser jest zaprojektowany w taki sposób, aby każdy użytkownik miał do niego dostęp, niezależnie od ustawień bezpieczeństwa DCOM. Kroki podczas przeglądania serwerów : 1. klient tworzy obiekt Server Browser na zdalnym komputerze podając jego CLSID (CLSID zawarty jest np. w opc_cats.c) do CoCreateInstanceEx, 2. klient otrzymuje wskaźnik do interfejsu ServerList typu IID_IServerList (zdefiniowany w opccomn_i.c) 3. metod interfejsu można użyć do przeszukania obecnych serwerów. 26

27 Data Access Specification ( Data Access Custom Interface Standard) Dwa ważne pojecia: przestrzeń nazw (namespace) wszystkie punkty produkujące i odbierające dane dostępne w serwerze. Może mieć strukturę płaską lub drzewa o dowolnej liczbie poziomów. Liście drzewa (producenci i konsumenci informacji zwane itemami) oraz węzły mogą posiadać dodatkowe właściwości (np. nazwę producenta czujnika). Z itemami związany jest również tzw. Access Path określający sposób komunikacji między urządzeniem a serwerem (np. parametry transmisji po łączu szeregowym). hierarchia obiektów ( object hierarchy) klient może tworzyć obiekty w serwerze. To Server, Group oraz Item. Przestrzeń nazw występuje tylko jednokrotnie i jest wspólna dla wszystkich klientów. Struktura obiektów jest indywidualna dla każdego klienta. Data Access 27

28 Klient Serwer Server Group Group Item Item Item Item Root Node 1 Node 3 Node 2 Item 1 Item 2 Item 3 Item 4 Item 5 Item 5 Namespace Data Access 28

29 Klient Serwer Komunikacja z serwerem tworzy grupy i itemy (możliwy zapis i automatyczne ładowanie po starcie) Sprzęt Konfiguracja serwera określa sposób przekształcenia zasobów sprzętu w namespace Data Access 29

30 W serwerze tylko Server oraz Group są rzeczywistymi obiektami DCOM. Item nim nie jest w rzeczywistości wykonuje się odczyt i zapis wszystkich wartości w grupie. Grupy strukturyzują itemy. Grupy tworzy się wewnątrz serwera. Utworzenie grupy wymaga przesłania do serwera: nazwy grupy, RequestedUpdateRate częstotliwość skanowania aktywnych itemów PercentDeadband strefa martwa dla trybu Refresh, ActiveState gdy grupa nie jest aktywna zmienne procesowe nie są czytane automatycznie. Utworzenie itemu wymaga przesłania: Full qualified item ID pełna nazwa, ActiveState RequestedDatatype serwer wykona konwersję do wymaganego typu (w miarę możliwości) AccessPath opcjonalny (np. dodatkowe parametry komunikacji z czujnikiem) ClientHandle umożliwia rozróżnienie itemów o identycznych item ID tworzonych przez różnych klientów. Serwer zawiera część niezależną od aplikacji (implementacja Server oraz Group) i część zależną od aplikacji Item fizycznie komunikujące się ze sprzętem. Data Access 30

31 Klient może pobierać dane bezpośrednio z urządzenia (device) lub z wewnętrznej pamięci serwera (cache). Dane mogą być czytane synchronicznie lub asynchronicznie (Data Access Specification 2.0 dopuszcza asynchroniczny odczyt wyłącznie z urządzenia oraz nie dopuszcza asynchronicznego zapisu). W trakcie odczytu synchronicznego klient wywołuje metodę i czeka na zwrócenie wartości. Jest stosowany tylko gdy dostęp do danych jest szybki w przeciwnym przypadku zablokuje klienta. W odczycie asynchronicznym po wywołaniu metody powrót jest natychmiastowy, a serwer po pewnym czasie powiadamia klienta o dostępności nowych danych (callback). Zapis zawsze wykonywany jest bezpośrednio do urządzenia (zapis do cache jest planowany w Data Access 3.0). Synchroniczny odczyt z cache jest możliwy gdy Group oraz Item są aktywne. Synchroniczny lub asynchroniczny odczyt dużej liczby danych może być czasochłonny. W takim przypadku pracuje się w trybie Refresh. Serwer i klient wymieniają się tu rolami. Ten tryb pracuje tylko dla zmiennych analogowych posiadających informacje EU (Engineering Units określa minimalną i maksymalną wartość sygnału). Wartość PercentDeadband wyznacza procentowy zakres wewnątrz EU po którego przekroczeniu (w stosunku do ostatnio wysłanej wartości) nowa wartość jest przesyłana od serwera do klienta. Serwer powiadamia klienta tylko w przypadkach gdy konkretna wartość (lub jej status) uległa zmianie. Data Access 31

32 Data Access Format przesyłanych danych miedzy serwerem a klientem zawiera: aktualna wartość o typie VARIANT (char, short, int, long, boolean, float, double, Array, String) znacznik czasu 8-bajtowy licznik startujący od ze skokiem 100ns status informacji 2 bajty choć aktualnie tylko jeden używany. To 2 bity jakości danych (Good, Bad, Uncertain), 4 bity statusu (np. dokładne określenie co znaczy Bad) i 2 bity limitu (dodatkowa diagnostyka w przypadku awarii czujników) Oprócz wartości zmiennych procesowych dla każdego węzła i liścia przestrzeni nazewniczej są dostępne właściwości (np. numer seryjny lub położenie urządzenia dostarczającego daną). Zwracają one informacje o charakterze statycznym. Klient może przepytać węzeł lub liść i uzyskać listę właściwości, ich wartości, typy oraz opis. Niektóre właściwości są obowiązkowe np. data type oraz access rights. Posiadając pełna ścieżkę dostępu do własności można utworzyć Item dla tej własności. Klient żąda od serwera danych w odpowiednim typie i serwer wykonuje (w miarę możliwości) odpowiednie konwersje. Dane przechowywane są jako VARIANT 32

33 Czasami korzystne jest aby Group oraz Item pozostały po zabiciu klienta. Licznik referencyjny tych obiektów podczas tworzenia ustawiany jest na 2 zabicie klienta dekrementuje ten licznik ale nie niszczy obiektów (NIEBEZPIECZNE!!!). Niszczeniu grup oraz itemów wymaga wywołania specjalnych metod. Pozostają one w serwerze mimo że nie ma aplikacji, które miała do nich uchwyty. Powtórne uzyskanie uchwytów możliwe jest dzięki wykorzystaniu enumeratorów (metod umożliwiających odszukanie) Goup oraz Server-ów. Utworzone grupy są prywatne dla tworzącego je klienta. Klient może upublicznić grupę i uwidocznić ją dla innych klientów. W stosunku do swojej kopii grupy publicznej klient może zmienić UpdateRate, PercentDeadband oraz State, a w stosunku do itemów RequestedDatatype oraz State. Nie może jednak dodawać oraz usuwać itemów. Data Server może załadować z pliku konfigurację (istnieje do tego odpowiedni interfejs) z opisem namespace lub np. z parametrami konfiguracyjnymi. Data Access 33

34 Obiekty serwera posiadają następujące interfejsy (oprócz interfejsów wymaganych przez każdy obiekt COM; interfejsy w [] nie są obligatoryjne). Klient posiada 2 interfejsy ICommon IServer IConnectionPointContainer IItemProperties [IServerPublicGroups] Server IDataCallback IServerShutdown Client [IPersistFile] [IBrowseServerAddressSpace] IItemMgt IGroupStateMgt [IPublicGroupStateMgt] ISyncIO IASyncIO2 Group IConnectionPointContainer IEnumItemAttributes IASyncIO IDataObject 34 Data Access

35 Automation Automation DLL wrapper DLL umożliwiający dostęp do serwera z poziomu dowolnego języka. Struktura wrappera widoczna poniżaj. Server Groups (Collection) Browser Group Group Group Items (Collection) Item Item Item Data Access 35

36 Automation Server Properties Methods Events StartTime GetServers ServerShutDown CurrentTime Connect LastUpdateTime Disconnect MajorVersion CreateBrowser MinorVersion GetErrorString BuildNumber QueryAvailableLocaleIDs VendorInf QueryAvailableProperties ServerState GetItemProperties LocaleID LookupItemIDs Bandwidth Groups PublicGroupNames ServerName ServerNode ClientName Data Access 36

37 Automation Data Access Browser Properties Methods Events Organization Filter DataType AccessRights CurrentPosition Count Item ShowBranches ShowLeafs MoveUp MoveToRoot MoveDown MoveTo GetItemID GetAccessPaths Groups Properties Methods Events Parent Item GlobalDataChange DefaultGroupIsActive DefaultGroupUpdateRat e DefaultGroupDeadband DefaultGroupLocaleID DefaultGroupTimeBias Count Add GetGroup Remove RemoveAll ConnectPublicGroup RemovePublicGroup 37

38 Automation Group Properties Methods Events Parent SyncRead DataChange Name SyncWrite AsyncReadComplete IsPublic AsyncRead AsyncWriteComplete IsActive AsyncWrite AsyncCancelComplete IsSubscribed AsyncRefresh ClientHandle AsyncCancel ServerHandle LocaleID TimeBias DeadBand UpdateRate Items Data Access 38

39 Automation Parent Items Properties Methods Events DefaultRequestedDataTy pe DefaultAccessPath DefaultIsActive Count Item GetItem AddItem AddItems Remove Validate SetActive SetClientHandles SetDataTypes Item Properties Methods Events Parent Read ClientHandle Write ServerHandle AccessPath AccessRights ItemID IsActive RequestedDataType Value Quality TimeStamp CanonicalDataType EUType EUInfo Data Access 39

40 Zainstalować DAAuto.DLL (regsvr32) Wykonać Tools / References ; zaznaczyć Automation 2.9 Umożliwi to podpowiadanie metod i właściwości oraz inny, łatwiejszy sposób deklarowania obiektów. Dzięki temu można tak: Dim AnServer As Server Automation w VBA Set ConnectedServer = New Server a nie tak: Dim AnServer As Object Set AnServer = _ CreateObject(".Automation.1") Automation Interfejs 40

41 Automation przykład 1 (VBA) - browsing Sub Przycisk2_Kliknięcie() Dim AnServer As Object, Browser As Object Dim Group Dim AnServerTime As Date Dim AllServers As Variant Dim i, RowNo As Integer Columns("A:G").Select : Selection.ClearContents Range("A6").FormulaR1C1 = "NoOfDetectedServers:" RowNo = 6 Set AnServer = CreateObject("NDI.Automation") AllServers = AnServer.GetServers Cells(RowNo, 2) = UBound(AllServers) - _ LBound(AllServers) + 1 RowNo = RowNo + 1 For i = LBound(AllServers) To UBound(AllServers) Cells(RowNo, 2) = AllServers(i): RowNo = RowNo + 1 Next i RowNo = RowNo + 1 AnServer.Connect (AllServers(4) ) Set Browser = AnServer.CreateBrowser Set Group = AnServer.Groups.Add Browser.MoveToRoot Call BrowseBranch(Browser, RowNo, Group) Set Browser = Nothing AnServer.Groups.Remove (Group.ServerHandle) AnServer.Disconnect Set AnServer = Nothing Range("A1").Select End Sub Data Access Sub BrowseBranch(Browser As Object, ByRef RowNo As Integer, ByVal Group As Object) Dim i As Integer, Item As Object Dim Value, Quality, TimeStamp As Variant Dim Source As Integer. Ret, ItemServerErrors Browser.ShowLeafs Source = 1 For i = 1 To Browser.Count Debug.Print Browser.CurrentPosition + "." + Browser.Item(i) Cells(RowNo, 2) = Browser.CurrentPosition + "." + Browser.Item(i) Set Item = Group.Items.AddItem(Browser.CurrentPosition + "." + Browser.Item(i), 1234) If (Item.AccessRights = 1) Or (Item.AccessRights = 3) Then can be read Ret = Item.Read(Source, Value, Quality, TimeStamp) Cells(RowNo, 6) = TypeName(Value) If (TypeName(Value) <> "Integer()") And (TypeName(Value) <> "Long()") And _ (TypeName(Value) <> "Single()") And (TypeName(Value) <> "Double()") And _ (TypeName(Value) <> "Boolean()") And (TypeName(Value) <> "String()") And _ (TypeName(Value) <> "Byte()") Then Cells(RowNo, 3) = Value: Cells(RowNo, 4) = Quality : Cells(RowNo, 5) = CDate(Item.TimeStamp) End If End If RowNo = RowNo + 1 Next Browser.ShowBranches For i = 1 To Browser.Count Browser.MoveDown (Browser.Item(i)) Call BrowseBranch(Browser, RowNo, Group) Browser.MoveUp Browser.ShowBranches ' restore Browser.Count/Item data Next End Sub 41

42 Automation przykład 2 (VBA+iFIX) browsing + odczyt danych Function DecodeQuality(Quality As Byte) As String Dim Aux As Byte Aux = Quality And &HC0 Select Case Aux Case 0: DecodeQuality = "Bad" Case 1: DecodeQuality = "Uncertain" Case 2: DecodeQuality = "N/A" Case 3: DecodeQuality = "Good" Case Else: DecodeQuality = "???" End Select End Function Sub BrowseBranch(Browser As Browser, ByRef RowNo As Integer, ByVal Group As Group) Dim i As Integer, Item As Item, Value, Quality, TimeStamp As Variant Dim Source As Integer, FirstFieldLetter As String Dim ItemServerErrors() As Long, ItemArr(1) As Long Browser.ShowLeafs Source = Device ' Device / Cache For i = 1 To Browser.Count FirstFieldLetter = Left(Browser.Item(i), 1) If (FirstFieldLetter = "A") Or (FirstFieldLetter = "F") Then Cells(RowNo, 2) = Browser.CurrentPosition + Browser.Item(i) Set Item = Group.Items.AddItem(Browser.CurrentPosition + Browser.Item(i), RowNo) If (Item.AccessRights = 1) Or (Item.AccessRights = 3) Then Call Item.Read(Source, Value, Quality, TimeStamp) Cells(RowNo, 6) = TypeName(Value) : Cells(RowNo, 3) = Value Cells(RowNo, 4) = DecodeQuality(CByte(Quality)) Cells(RowNo, 5) = CDate(Item.TimeStamp) : Cells(1, 1) = RowNo End If ItemArr(1) = Item.ServerHandle Call Group.Items.Remove(1, ItemArr, ItemServerErrors) RowNo = RowNo + 1 End If Next Data Access Browser.ShowBranches For i = 1 To Browser.Count Browser.MoveDown (Browser.Item(i)) Call BrowseBranch(Browser, RowNo, Group) Browser.MoveUp Browser.ShowBranches ' restore Browser.Count/Item data Next End Sub 42

43 Automation przykład 2 (VBA+iFIX) browsing + odczyt danych Sub DAAuto_Kliknięcie() Dim RowNo As Integer, i As Integer Dim ifixserver As Server, Browser As Browser, Group As Group, AllServers As Variant Set ifixserver = New Server Columns("A:G").Select: Selection.ClearContents ' Clear the sheet ifixserver.connect ("Intellution.EDA"): ifixserver.clientname = "Excel / ifix interface" If ifixserver.serverstate <> Running Then MsgBox ("Start ifix first"): Return: End If RowNo = 6: Cells(RowNo, 1) = "ifix Server Properties": RowNo = RowNo + 1: Cells(RowNo, 2) = "ClientName" Cells(RowNo, 3) = ifixserver.clientname: RowNo = RowNo + 1: Cells(RowNo, 2) = "ServerName" Cells(RowNo, 3) = ifixserver.servername: RowNo = RowNo + 1: Cells(RowNo, 2) = "ServerNode" Cells(RowNo, 3) = ifixserver.servernode: RowNo = RowNo + 1: Cells(RowNo, 2) = "VendorInfo" Cells(RowNo, 3) = ifixserver.vendorinfo: RowNo = RowNo + 1: RowNo = RowNo + 1: Cells(RowNo, 2) = "NoOfDetectedServers:" AllServers = ifixserver.getservers: Cells(RowNo, 2) = UBound(AllServers) - LBound(AllServers) + 1: RowNo = RowNo + 1 For i = LBound(AllServers) To UBound(AllServers) Cells(RowNo, 2) = AllServers(i): RowNo = RowNo + 1 Next i RowNo = RowNo + 1: Set Browser = ifixserver.createbrowser: Set Group = ifixserver.groups.add Browser.MoveToRoot: Call BrowseBranch(Browser, RowNo, Group) : Set Browser = Nothing ifixserver.groups.remove (Group.ServerHandle) ifixserver.disconnect Set ifixserver = Nothing Range("A1").Select End Sub Data Access 43

44 Tunelowanie Sieciowy ruch DCOM nie jest zaprojektowany dla czasu rzeczywistego DCOM trudne do konfiguracji, źle reaguje na przerwanie połączenia i ma poważne braki dotyczące bezpieczeństwa Konfigurowanie poprzez DCOM zwiększa ruch sieciowy Rozwiązaniem opracowanie metod tunelowania polegających na zastąpieniu sieciowego ruchu DCOM poprzez TCP. Zamiast sieciowo łączyć klienta i serwer łączy się je z lokalnymi aplikacjami. Lokalna aplikacja dla klienta udaje serwer, a lokalna aplikacja dla serwera udaje klienta. Lokalne aplikacje łączą się za pomocą TCP. Serwer Aplikacja tunelująca 1 TCP Aplikacja tunelująca 2 Klient Tunelowanie 44

45 Tunelowanie transakcji Serwer Aplikacja tunelująca 1 Aplikacja tunelująca 2 Klient Transakcje transmitowane są przez sieć Wywołania synchroniczne wrażliwe na parametry ruchu sieciowego Tunelowanie 45

46 Lokalne transakcje Serwer Aplikacja tunelująca 1 Aplikacja tunelująca 2 Klient Transakcje wykonywane wyłącznie lokalnie Aplikacje tunelujące utrzymują dwie kopie danych (serwera i klienta) w stanie permanentnej synchronizacji Aplikacje tunelujące mogą monitorować łącze i powiadamiać klienta/serwera o przerwaniu lub spadku jakości połączenia co może skutkować zmianą jakości danych Tunelowanie 46

47 Bezpieczeństwo Względy bezpieczeństwa najistotniejszym powodem wprowadzenia tunelowania DCOM nie był projektowany do pracy w sieciach WAN, można go tak skonfigurować ale jest to trudne Aspekty sieciowego bezpieczeństwa: Szyfrowanie danych zapobiega podsłuchaniu danych Uwierzytelnienie użytkowników każde połączenie wymaga nazwy użytkownika i hasła (lub np. oparte na publicznym i prywatnym kluczu) Autoryzacja odpowiednie uprawnienia dla każdego użytkownika Rozwiązania wykorzystywane do zapewnienia bezpieczeństwa: Opracować własne rozwiązanie od podstaw SSL (Secure Socket Layer) zapewnia wyłącznie szyfrowanie; bardzo wygodne; potrzebny klucz np. z centrum uwierzytelniania VPN (Virtual Private Network) zapewnia szyfrowanie i uwierzytelnianie; VPN jest częścią SO tunelowanie odbywa się poprzez VPN SSH (Secure Shell) - zapewnia szyfrowanie i uwierzytelnianie dla TCP; w odróżnieniu od VPN zabezpiecza tylko pojedyncze połączenie TCP Tunelowanie 47

48 Alarms and Events Mechanizm powiadamiania klienta AE o wystąpieniu zdarzenia lub alarmu (specyfikacja DA nie gwarantuje odczytania wszystkich wartości zmiennej) Alarm warunek nienormalny; warunek to nazwany stan jednego z obiektów (np. HighTemperature) Zdarzenie może ale nie musi być związane z jakimś warunkiem; to np. zakończenie stanu HighTemperature ale i działanie operatora Browser serwera AE uwidacznia wszystkie dostępne zdarzenia i alarmy Klient AE określa o jakich alarmach i zdarzeniach jest powiadamiany Klient może manipulować warunkami zaimplementowanymi na AE serwerze W odróżnieniu od DA nie dostarcza ciągłego strumienia danych Serwer AE może być podłączony bezpośrednio do źródła danych lub do serwera DA AE 48

49 Historical Data Access Rodzaje serwerów HDA: Simple trend zapis strumieni danych (typowo z serwerów DA) w postaci par [TimeStamp Value] Complex zapewniają kompesję i analizę danych; dostarczają danych w czasie jak i danych zagregowanych np. wartości minimalnej, średniej, itp. Dostępne są serwery HDA do relacyjnych baz danych lub do ODBC HDA 49

50 Data Exchange (DX) Definiuje sposób komunikacji serwer-serwer Wymiana informacji między serwerami DA bezpośrednio, bez pomocy klienta Wykorzystywane do redundancji danych DX 50

51 XML-DA Implementuje SOAP (Simple Object Application Protocol) do obiektów DA umożliwiając implementację klientów w językach wspierających SOAP (np. Java) Jako protokół transportowy używany jest HTTP lub HTTPS Czyli niezależny od platformy transfer danych Wykorzystanie XML redukuje przepustowość (nawet 10x w stosunku do DA) rzadziej używany do transportu danych czasu rzeczywistego, raczej to transferu danych między infrastrukturą sterującą i biznesową XML-DA 51

52 Unified Architekture UA SOAP wykorzystany do zapewnienia funkcjonalności DA, EA oraz HDA Dwie specyfikacje SOAP (Simple Object Access Protocol): SOAP = XML + HTTP(S) Protokół komunikacyjny wykorzystujący HTTP do przesyłania wiadomości XML Niezależność od platformy i języka Specyfikacja kodowania binarnego operująca bezpośrednio na komunikatach TCP; lepsza przepustowość od przesyłania wiadomości XML Klient może pytać serwer o metadane czyli np. o formaty w jakich udostępnia dane 52

53 Unified Architekture klient UA klient DA AE HDA DA AE HDA DA AE HDA DA AE HDA serwer UA serwer 53

54 Unified Architekture System operacyjny A Serwer Klient System operacyjny B Interfejs klienta Interfejs serwera Interfejs sieciowy klienta Interfejs sieciowy serwera Sieć Niezależność od platformy 54

55 Wykorzystanie [8] Zawsze/często Czasem Rzadko/nigdy DA 82% 13% 5% HDA 53% 15% 33% A&E 42% 18% 40% DX 25% 15% 60% XML-DA 23% 14% 63% Web Serwices 19% 12% 69% Batch 17% 18% 65% Security 15% 15% 70% UA 10% 16% 74% 55

56 Porównanie DA XML-DA UA Bazuje na DCOM Bazuje na HTTP(S) Bazuje na HTTP(S) lub binarnie zdefiniowanym stosie UA DCOM wywołuje procedury we współdzielonym serwerze. Definiuje dwa interfejsy: niskiego poziomu custom oraz automation. Serwery zwykle implementują wyłącznie interfejs custom. Interfejs automation dostępny poprzez automation wrapper. DCOM pracuje szybko szczególnie dla pracy klient-serwer w lokalnym komputerze. Standard definiuje około 60 funkcji komunikacyjnych (stosunkowo proste funkcje). Trudno skonfigurować firewall aby przepuszczały pakiety DCOM. Bazuje na XML i SOAP (transfer XML poprzez HHTP(S)). Sieciowe komunikaty XML podatne na opóźnienia w Internecie. Zdefiniowanych 8 (raczej skomplikowanych) metod. Transfer danych tekstowo, obudowanych XML-em, spowalnia transmisję. Komunikacja poprzez HTTP(S) lub binarnie poprzez TCP. Dostępne biblioteki.net ułatwiające implementację. Używa kodowanego transferu HTTPS serializując XML lub zdefiniowanego binarnego protokołu TCP. 56

57 Porównanie DA XML-DA UA DCOM pracuje przy permanentnym połączeniu zapewniając mechanizmy typu callback DCOM nie jest zalecany do komunikacji poprzez firewall-e. Nie może być kodowany. Można tunelować co rozwiązuje powyższe wady. Serwisy sieciowe są pozbawione stanu każde wywołanie jest niezależne od poprzednich. Inicjowane przez serwer callback nie są możliwe klient zawsze musi zapytać o dane. SOAP wspierany na wszystkich platformach. Prosta komunikacja międzyplatformowa. Proste jest zaimplementowanie bezpiecznej komunikacji, używając choćby zdefiniowanych standardów sieciowych. UA wykorzystuje sesję do zdefiniowania typu komunikacji. UA definiuje wewnętrzny interfejs dostępny ze stosu komunikacyjnego. 57

58 Demo Proficy ifix Matricon Simulation Server / Explorer DSxP Simulator MATLAB Toolbox 58

59 Literatura: 1. Microsoft Developer Network. Development Library 2. Williams S., Kindel Ch.: The Component Object Model: A technical Overview, MSDN. 3. Dr. GUI on Components, COM and ALT, MSDN. 4. Overview, 5. Common Definitions and Interfaces, 6. Data Access Automation Interface Standard, 7. Data Access Custom Interface Standard, 8. Security White Paper #1. Understanding and How it is Deployed, Digital Bond, British Columbia Institute of Technology, Byres Research 59