http://www.commsvr.com/Home.aspx
OPC
OPC jest otwartym standardem komunikacyjnym stosowanym w automatyce przemysłowej i
informatycznych systemach wyższych warstw, a mianowicie biznesowej i zarządzania,
przedsiębiorstw przemysłowych. Interoperacyjność aplikacji jest zapewniona dzięki utworzeniu i
utrzymywaniu specyfikacji otwartych standardów.
OPC powstał i został tak zaprojektowany, aby łączyć aplikacje bazujące na systemach operacyjnych
ogólnego stosowania (np. Windows) ze sprzętem i oprogramowaniem aplikacyjnym automatyki
przemysłowej (urządzenia procesowe), nadzorującym i sterującym procesem technologicznym. Jest
to otwarty standard komunikacji, który pozwala używać jednolitych metod dostępu i opisu danych
(interfejsu) dla procesu technologicznego. Metody te są niezależne od typu oraz z
ródła danych.
Dla wielu pakietów oprogramowania serwer OPC dostarcza w jednolity sposób danych z urządzeń
sterujących i nadzorujących proces technologiczny (dane procesowe) takich, jak sterowniki PLC, czy
systemy DCS. Tradycyjnie, jeżeli jakieś oprogramowanie ma mieć dostęp do danych procesowych,
musi zostać zaimplementowany specjalny drajwer. Zadaniem OPC jest zdefiniowanie wspólnego
interfejsu, który  utworzony raz - może być wykorzystywany przez dowolnego klienta biznesowego,
oprogramowanie SCADA, HMI lub dowolny pakiet oprogramowania. Jeżeli serwer OPC zostanie
stworzony dla konkretnego urządzenia, może być wykorzystany ponownie przez dowolną aplikację,
która pełni rolę klienta OPC.
Bazując na standardach Microsoft OLE (ang. Object Linking and Embedding), COM (ang. Component
Object Model) i DCOM (ang. Distributed Component Object Model), technologia OPC definiuje
interfejsy przeznaczone do komunikacji z urządzeniami przemysłowymi, przez co pozwala
uniezależnić oprogramowanie monitorujące od różnorodnych rozwiązań stosowanych przez
producentów sprzętu procesowego. Technologie COM/DCOM dostarczają infrastrukturę i środowisko
programistyczne dla tworzenia i rozwoju oprogramowania. Obecnie są dostępne setki serwerów i
klientów OPC.
CommServer jest zgodny z wymaganiami specyfikacji OPC w zakresie dostępu do danych
procesowych przez klientów OPC. Zaimplementowano w nim interfejsy zgodne z OPC Data Access
(DA) dla wersji 2.0a i 3.0. Ponadto CommServer jest zoptymalizowany pod kątem wysokiej
wydajności komunikacji i użycia wielowątkowej technologii, aby zagwarantować maksymalnie
wydajny czas odpowiedzi na żądania klienta. To podejście pozwala na podłączenie wielu klientów i
efektywne używanie zasobów serwera.
Koncepcja
Warstwa procesowa stanowi z
ródło danych dla procesów zarządzania. Zbudowana jest z różnorodnych
urządzeń procesowych, które udostępniają dane w różnych protokołach (językach). Każdy protokół to
składnia, semantyka, uzależnienia czasowe, przestrzeń adresowa, medium komunikacyjne. Aby dwa
urządzenia mogły ze sobą współpracować, muszą używać jednego protokołu określającego
jednoznacznie wszystkie powyższe elementy. Często używa się (a często nadużywa) sformułowania:
muszą używać jednego standardu, gdzie standard jest magicznym wytrychem gwarantującym sukces
w procesie integracji, co jednak często dopiero weryfikuje praktyka. Tak jak w życiu, nie zawsze
dwóch ludzi rozmawiających tym samym językiem jest się w stanie  dogadać . Dodatkową trudnością
jest to, że znamy setki owych standardów, niezależnie od tego, co dokładnie rozumiemy pod słowem
standard.
1
http://www.commsvr.com/Home.aspx
Rysunek 1: Różnorodność- metoda, czy przeszkoda?
Mamy zatem różnorodność standardów połączoną z różnorodnością rozwiązań proponowanych przez
poszczegól-nych producentów (Rysunek 1). Z punktu widzenia możliwości dopasowania rozwiązań do
naszych - zawsze przecież indywidualnych  potrzeb, ten fakt wydaje się dobrą nowiną, pod
warunkiem, że łącząc elementy stosujemy wyłącznie rozwiązania jednego producenta. Z punktu
widzenia większych systemów różnorodność bywa niestety zaporą nie do przebycia i to co najmniej z
dwóch powodów:
Prowadzi do rozwiązań  totalitarnych i dyktatu producenta ze wszystkimi tego
konsekwencjami- bariera biznesowa i prawna.
Jest funkcjonalnie ograniczone do oferty wybranego producenta  bariera rozwoju i
otwartości.
Architekci systemów przemysłowych od początku ery komunikacji i sterowania cyfrowego próbują
znalez
ć rozwią-zanie pozwalające obejść te bariery. Firma General Motors na początku lat
dziewięćdziesiątych policzyła, że koszty integracji dla jednej z nowych linii montażowych przekroczyły
koszty jej wyposażenia. Więc dodatkowo sprawa dotyczy sporych pieniędzy.
Upraszczając nieco, można stwierdzić, że architekci próbują odpowiedzieć na to pytanie na dwa znane
sposoby:
1. Metodą  z góry na dół (ang. top-down);
2. Metodą  z dołu do góry (ang. bottom-up).
Przykładem pierwszej był projekt Manufacturing Automation Protocol (MAP), w którym pod
wielopłaszczy-znowym przywództwem wspomnianej firmy GM grupa producentów z różnych branż
próbowała zdefiniować protokół na bazie istniejących i często tworzonych dopiero norm ISO. Projekt
zakończył się całkowitą porażka.
Przykładem drugiej metody jest projekt OPC, który bazuje na bardzo prostym spostrzeżeniu, a
mianowicie posta-wiony powyżej problem wydaje się bardzo podobny do problemu komunikacji z
urządzeniami peryferyjnymi w bardzo powszechnym w okresie tworzenia pomysłu systemie
operacyjnym DOS. W systemie tym, aby program aplikacyjny mógł skorzystać z drukarki, musiał mieć
do niej własny drajwer komunikacyjny. W nowszych systemach rozwiązano go, poprzez wbudowanie
2
http://www.commsvr.com/Home.aspx
funkcji drukowania do interfejsu systemu operacyjnego (ang. Application Programming Interface) i
umożliwienie dodawania do systemu nowych komponentów, które wspierają ten interfejs. W kolejnej
generacji systemów operacyjnych pojawiła się nowa możliwość samodzielnego rozszerzania API
systemu operacyjnego poprzez instalowanie własnych komponentów, które publikują interfejs, jako
pewną ofertę swojej funkcjonalności i implementują tę funkcjonalność.
Rysunek 2: OPC- drajwer procesu?
Innymi słowami, w rozważanym przypadku - nie oglądając się na producenta systemu operacyjnego -
możemy sami rozszerzyć jego funkcjonalność o  drajwer do procesu technologicznego (Rysunek 2).
Wydawało się, że powyższa koncepcja ma dwie istotne zalety i jedną wadę. Pierwsza zaleta, to
relatywnie łatwiejsza implementacja, ponieważ taki komponent jest jedynie kawałkiem wielkiego
puzzle a, a nie - jak MAP - tysiącem kawałeczków, z których dodatkowo można było ułożyć kilka
różnych obrazków. Druga zaleta, to z definicji oferowana architektura klient - serwer, a zatem
możliwość komunikacji z urządzeniem procesowym wielu klientów jednocześnie, co jest niemożliwe w
przypadku większości oferowanych poprzednio, a nawet obecnie, protokołów komunikacyjnych.
Podstawową wadą rozwiązania jest uzależnienie od systemu operacyjnego, ponieważ rodzi
konieczność wyboru i żąda lojalności na dobre i złe w przyszłości. Przetarg wygrał bez trudu Microsoft
Windows. Ta wada szybko okazała się motorem sukcesu, ze względu na popularność systemu i, co
może ważniejsze, pojawienie się nowego obszaru do zagospodarowania przez producenta systemu
Windows. Rezultat: kilkanaście tysięcy oficjalnych implementacji OPC oferowanych i konsumowanych
przez ponad 450 firm zrzeszonych w organizacji OPC Foundation, w tym tylko jedna z Polski, ale
większość z Europy. Oczywiście, żeby implementować i używać OPC nie trzeba być członkiem żadnej
organizacji, co oznacza, że wymienione liczby nie oddają w żadnej mierze skali popularności.
Tu jednak warto rozwiać dwa mity. Specyfikacja OPC - dostępna wyłącznie dla członków  to zestaw
dokumentów dedykowanych wyłącznie dla programistów implementujących OPC i jej znajomość nie
jest potrzebna użytkownikowi do pełnego korzystania z produktów wspierających OPC. Ponadto, z
uwagi na szczegółowość sięgającą znaczenia poszczególnych bitów i hermetyczność języka, w jakim
została napisana, próba wykorzystania jej w roli podręcznika dla użytkownika OPC nie jest zalecana.
Drugi mit to fakt, że paradoksalnie OPC nie jest protokołem komunikacyjnym, co czyni bezpodstawną
każdą dyskusję o wyższości innych protokołów komunikacyjnych nad OPC i odwrotnie.
3
http://www.commsvr.com/Home.aspx
Okazuje się, że OPC to zupełnie nowa jakość, która daleko odbiegła od oczekiwań twórców i
przykładowo pozwoli-ła na utworzenie platformy integracyjnej niezbędnej do wdrożenia systemu
optymalizacji pracy trzech elektrociepłowni o łączne mocy cieplnej 2,5 GW zasilających łódzki system
ciepłowniczy i zarządzającej infrastrukturą komunikacyjną utworzoną z dwóch systemów radiowych i
kilku rozległych segmentów światłowodowych. Jedynie dzięki tak rozbudo-wanej infrastrukturze i
centralnemu zarządzaniu nią możliwe jest zapewnienie odpowiednio bezpiecznej komunikacji
pomiędzy urządzeniami procesowymi i systemami zarządzania procesem i przedsiębiorstwem. Wydaje
się, że - jak na prosty drajwer - jest to dość odpowiedzialna funkcja.
Skoro OPC nie jest ani protokołem komunikacyjnym, ani drajwerem, to czym zatem jest i co trzeba
wiedzieć, aby skutecznie planować wdrożenie i wykorzystywać OPC? Próbą znalezienia odpowiedzi na
te pytania poświęcony jest ten artykuł.
Co to jest OPC?
Z przedstawionej powyżej koncepcji wynika, że konkretna implementacja, tzn. produkt
implementujący serwer OPC, to dwa w jednym (Rysunek 1):
1. Komponent (program) realizujący funkcjonalność opisaną w specyfikacjach OPC.
2. Implementacja wybranego protokołu komunikacyjnego.
Z punktu widzenia specyfikacji OPC najistotniejsze są też dwa, ale zupełnie inne elementy:
1. Interfejs OPC.
2. Środowisko, w którym ten interfejs zostanie opublikowany (udostępniony).
Rysunek 1: OPC ściana dzieląca dwa światy ?
Interfejs to formalna definicja zbioru metod i struktur danych oferowanych przez komponent.
Dodatkowo jest to definicja abstrakcyjna, bo oderwana od konkretnej implementacji. Innymi słowy,
interfejs jest rodzajem instrukcji obsługi wspominanego komponentu - to informacja dla klienta (też
pewien program), jak ma go używać i dla programisty co (ale nie jak) ma zaimplementować.
Opublikowanie oznacza udostępnienie samej definicji i umożliwienie wykorzystania oferowanej
funkcjonalności. Dlatego często używa się skrótu myślowego  komponent OPC jest dostępny
wyłącznie za pośrednictwem interfejsu OPC. Oczywiście nie można używać pralki za pośrednictwem jej
instrukcji obsługi. W tym celu potrzebujemy gałek, przycisków, wtyczek, wyświetlaczy, itd.
W przypadku korzystania z komponentu, ich rolę spełniają funkcje oferowane przez system
operacyjny. Te funkcje stanowią pewną wydzieloną część systemu operacyjnego, do której też
zdefiniowano pewien interfejs zgodny z opracowanym modelem swobodnego publikowania i
wykorzystywania komponentów COM (ang. Component Object Model). Ponieważ mechanizm ten ma
zastosowanie wyłącznie lokalne, tzn. komponenty mogą być wykorzystywane tylko przez aplikacje
uruchomione na tym samym komputerze, w następnym kroku rozszerzono go o dostęp zdalny i tak
powstał DCOM (ang. Distributed Component Object Model).
4
http://www.commsvr.com/Home.aspx
Publicznie dostępne dokumenty opisujące DCOM - podobnie jak w przypadku OPC - opisują, co model
ten oferuje, a nie jak oferowana funkcjonalność jest zaimplementowana. Ponieważ trudno jest
zbudować pralkę na podstawie instrukcji obsługi, przenoszenie tej funkcjonalność na inne platformy
systemowe jest bardzo utrudnione, co dziś uważane jest za istotne zagrożenie dla samego OPC.
Świadomość tego zagrożenia spowodowała rozpoczęcie przez OPC Foundation prac nad rozwiązaniem
alternatywnym. Ale nie ma to być ścieżka ewakuacyjna, tylko całkowicie nowa jakość  rozwiązanie
zbudowane z uwzględnieniem dotychczas zebranych doświadczeń. Projekt otrzymał nazwę OPC
Unified Architecture (OPC UA). Tym razem zrezygnowano z osadzania definiowanej funkcjonalności w
ramach konkretnej platformy systemowej. Zamiast tego przyjęto, że bazą będzie zbiór norm
bazujących na języku znacznikowym XML (ang. eXtensible Markup Language) i opracowanych przez
konsorcjum W3C (World Wide Web Consortium). Normy te powszechnie oznaczane są symbolem WS-
*. Ponieważ standardy WS-* tworzone są bez wstępnego założenia co do platformy systemowej, na
której będą implementowane, zatem muszą precyzować to, co finalnie ma znalez
ć się w umownym
 drucie , więc wrócono do koncepcji tworzenia protokołu.
Choć wybór platformy systemowej zostawiono dostawcom oprogramowania, tym razem optymizm
twórców opiera się na fakcie ogromnej popularności, jaką cieszą się wymienione specyfikacje, czego
wymiernym dowodem jest duża ilość ich implementacji. Dodatkowo implementacje te powstają dla
platform wirtualnych, więc przynajmniej z teorii łatwo przenośnych. Natomiast pewnym niepokojącym
faktem jest to, że prace w ramach projektu wciąż trwają, a termin ich zakończenia ciągle się oddala.
Jak wspomniano, OPC UA to protokół, więc nie ma już żadnych formalnych przeszkód, aby
porównywać go z in-nymi znanymi i masowo stosowanymi w automatyce od lat protokołami. I tu
mamy kolejny powód do pewnego zaniepokojenia. Mianowicie, stosując dobrze znany, powstały w
początkach ery sterowania cyfrowego protokół MODBUS do przesłania jednego bitu reprezentującego
pewną wielkość procesową (np. stan przekaz
nika) potrzebujemy przesłać przez umowny  drut
strumień kilku bajtów. Trudno policzyć, ile potrzeba w przypadku OPC UA, ponieważ zanim prześlemy
ten bit, musimy wpierw wymienić się podpisanymi cyfrowo certyfikatami angażując w to infrastrukturę
klucza publicznego (ang. Public Key Infrastructure). Ale kto dziś, w dobie zintegrowanego zarządzania
procesem i przedsiębiorstwem, przesyła tak proste informacje? Z drugiej strony, pomysł budowy
zintegrowanego zarządzania na bazie protokołów klasy MODBUS jest pozbawiony jakiegokolwiek
sensu, o ile w ogóle realizowalny.
Reasumując, OPC to definicja pewnego interfejsu, a precyzyjnie - zbioru interfejsów pogrupowanych
na kategorie, oraz wymaganie osadzenia określonej tymi interfejsami funkcjonalności w technologii
DCOM. Podobnie, OPC UA jest zestawem interfejsów oraz definicją sposobu udostępnienia określonej
nimi funkcjonalności w postaci usług za pośred-nictwem protokołu komunikacyjnego bazującego na
standardach z grupy WS-*. W obu przypadkach, niezależnie od istotnych różnic koncepcyjnych, używa
się skrótowego określenia "technologia OPC" do określenia wszystkich przed-stawionych powyżej
uwarunkowań.
Niezależnie od definicji, w obu przypadkach cel jest taki sam, a mianowicie stworzyć ujednolicony
mechanizm swobodnego dostępu do danych znajdujących się w urządzeniach odpowiedzialnych za
odczyt i generowanie sygnałów określających stan pewnego procesu technologicznego. Jego realizacja
pozwala w pełni uniezależnić oprogramowanie wyższych warstw od producentów sprzętu i otwiera
drogę do budowy systemów otwartych.
COM
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.
5
http://www.commsvr.com/Home.aspx
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.
COM - Interfejsy
Obiekty COM udostępniają swoje funkcje obiektom zewnętrznym za pośrednictwem interfejsów.
Interfejs stanowi zbiór wskaz
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 wskaz
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 1: 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.
6
http://www.commsvr.com/Home.aspx
Rysunek 2: 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] wskaz
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
OPC wymaga platformy DCOM zarówno po stronie klienta, jak i serwera. Teoretycznie - zgodnie z
pierwotną kon-cepcją - istnienie DCOM dla użytkownika technologii OPC powinno być przezroczyste,
podobnie jak dla użytkownika arkusza kalkulacyjnego istnienie systemu operacyjnego. Tak jednak nie
jest. Aby to wyjaśnić, konieczne jest doprecyzowanie definicji komponentu, którym jest każdy serwer
OPC.
Aby komponent mógł być wykorzystany, musi zostać zainstalowany. Instalacja to proces
automatyczny, przebiegający bez ingerencji użytkownika. W jego wyniku komponent, a właściwie
potrzebna informacja o nim, jest umieszczana w usłudze katalogowej DCOM. W tym stanie komponent
pełni rolę biblioteki i jest całkowicie pasywny  nie zajmuje czasu procesora i miejsca w pamięci
operacyjnej, a jedynie jego kod umieszczany jest na dysku twardym.
7
http://www.commsvr.com/Home.aspx
Z punktu widzenia użytkownika bardzo istotnym momentem jest chwila, w której pierwszy klient
próbuje wykorzystać komponent, ponieważ wcześniej kod komponentu musi zostać załadowany do
pamięci i otrzymać zarezerwowaną dla jego potrzeb pewną przestrzeń roboczą. W efekcie tworzony
jest obiekt, który oprócz kodu i przydzielonej mu pa-mięci ma jeszcze jedną kluczową cechę, a
mianowicie tożsamość. Oznacza to, że komponent, analogicznie jak zwykły interaktywny użytkownik,
musi posiadać przypisane do niego konto systemowe, aby umożliwić autoryzację wykonywanych przez
niego operacji. Sposób, w jaki komponent i tworzone obiekty uzyskują tożsamość, zależy od
konfiguracji, czyli użytkownika. Użytkownik (używając programu narzędziowego dcomcnfg.exe) oprócz
sposobu określania tożsamości, czyli konta wykorzystywanego przez tworzone obiekty, ma jeszcze
wpływ na to, kto ma prawo do ładowania, korzystania z jego metod i konfiguracji uprawnień
komponentu. W efekcie daje to spory poziom komplikacji, co często jest bardzo kłopotliwe, nawet dla
zaawansowanych administratorów. A to nie koniec kłopotów, ponieważ - zgodnie ze specyfikacją - po
zainicjowaniu obiekt serwera tworzy pewien nowy obiekt przeznaczony do obsługi jego żądania
zakończenia sesji, tym razem po stronie klienta (Rysunek 1).
Rysunek 1: Współpraca klient - serwer
Z doświadczenia wiadomo, że rozwiązywanie tych problemów może trwać od pojedynczych minut
nawet do kilku dni w skomplikowanych przypadkach. Dlatego przy uruchamianiu instalacji warto mieć
zagwarantowane wsparcie odpowiedniego specjalisty.
Ponadto, ze względu na wzajemnie symetryczną komunikację (tworzenie obiektów po obu stronach),
nie można stosować półprzezroczystych zapór ogniowych (ang. firewall) na drodze pomiędzy klientem
i serwerem.
Jeśli struktura sieci i polityka bezpieczeństwa zostaną staranie zaplanowane i poprawnie wdrożone, to
faktycznie dla użytkownika istnienie platformy DCOM staje się całkowicie przezroczyste, a dowodem
 życia serwera jest wskaz
nik zajętości procesora i ewentualnie zużycia pamięci.
8
http://www.commsvr.com/Home.aspx
Specyfikacje OPC
OPC to pewien zbór interfejsów pogrupowanych w kategorie, z których każda dedykowana jest
pewnej funkcjonal-ności. Kategoria służy również do wyróżnienia kolejnych wersji poszczególnych
grup interfejsów. Każda grupa jest opisana w osobnym dokumencie  specyfikacji, któremu nadano
jednoznaczną nazwę symboliczną (np. OPC DA) i numery wersji. Niezależnie od nazw dla każdej
kategorii zdefiniowany jest globalnie jednoznaczny identyfikator cy-frowy, którym posługuje się klient i
serwer w fazie nawiązywania połączenia. Połączenie jest możliwe, jeśli identyfikator kategorii używany
przez klienta i serwer są identyczne, chyba że serwer wspiera kilka kategorii. Jednak nawet wtedy
tworzony jest obiekt serwera tej kategorii, która została użyta przez klienta w żądaniu nawiązania
połączenia. Do naj-ważniejszych kategorii objętych specyfikacjami OPC należą:
OPC DA (ang Data Access)  zapewnia swobodny dostęp do aktualnych danych procesowych
w czasie rzeczywi-stym. Przy pomocy OPC DA do serwera OPC kierowane są zapytania o
aktualne wartości zmiennych procesowych.
OPC HDA (ang. Historical Data Access)  zapewnia dostęp do ciągów danych archiwalnych,
np. w celu wyznacze-nia trendów, oceny przebiegu procesu w czasie, itp. Klient uzyskuje
dostęp do zarchiwizowanych danych (odczytów jakiegoś urządzenia itp.) poprzez zgłaszanie
zapytań do serwera OPC HDA.
OPC A&E (ang. Alarms & Events)  umożliwia generowanie przez serwer - po stronie klienta -
rodzaju przerwań informujących o występujących w procesie zdarzeniach i zgłaszanych
alarmach.
OPC Security  pozwala dodatkowo - niezależnie od mechanizmów wbudowanych w DCOM -
podnieść poziom bezpieczeństwa dostępu do danych procesowych publikowanych przez
serwer OPC poprzez uwierzytelnienie i auto-ryzację klienta.
OPC UA (ang. Unified Architecture)  zbiór kilkunastu dokumentacji zawierających
specyfikację dla komunikacji pomiędzy różnymi typami systemów i urządzeń, bazującą na
standardach dla Internetu z grupy WS-*.
Specyfikacje dla poszczególnych grup ulegały zmianom w wyniku gromadzonych doświadczeń. Każde
wydanie specyfikacji oznaczane jest nowym numerem wydania (wersji), np. kategoria Data Access
posiada wersję 1.0a, 2.XX oraz 3.0. Każda wersja zapewnia inny zestaw interfejsów i stanowi nową
kategorię.
9