OPC - cas.internetdsl.pl · Skoro OPC nie jest ani protokołem komunikacyjnym, ani drajwerem, to...

doc: 08010104-OPC-Artykul/Ver:1 1

dr inż. Mariusz Postół 1

Samodzielny Zakład Sieci Komputerowych

Politechnika Łódzka

OPC - PLATFORMA INTEGRACJI ZARZĄDZANIA Z PRODUKCJĄ

ROLA KOMUNIKACJI W NOWOCZESNYM ZARZĄDZANIU

Aby sprostać wymaganiom konkurencji, proces produkcji musi być nadzorowany przez nowoczesne systemy automatyki

oraz systemy informatyczne zlokalizowane odpowiednio w warstwie procesowej i biznesowej. To jednak często już nie wy-

starcza i - aby dalej zwiększać efektywność procesu w rezultacie synergii i makro-optymalizacji - wymienione systemy muszą

być zintegrowane.

Ze względu na dużą złożoność, współczesne systemy automatyki przemysłowej wymagają odpowiedniej dystrybucji za-

dań do rozproszonych podsystemów współpracujących ze sobą tak, aby osiągnąć określoną dla danego procesu technologicz-

nego funkcję celu. Niezależnie od struktury, która silnie zależy od kultury organizacyjnej przedsiębiorstwa, rodzaju procesu i

postawionej funkcji celu, komponenty tworzące system muszą się wzajemnie komunikować. Komunikacja ma za zadanie

wymianę danych potrzebnych do analizy stanu produkcji, planowania działań operacyjnych, wyznaczenia odpowiednich ste-

rowań i synchronizacji zdarzeń występujących w całym procesie. Budowanie systemów współdziałających z pewnym proce-

sem fizycznym oznacza, że realizowane przez nie algorytmy – a w tym komunikacja – muszą uwzględniać fakt, że zjawiska fi-

zyczne procesu przebiegają w czasie rzeczywistym. W systemach czasu rzeczywistego poprawność programu zależy również

od występujących w nim i otoczeniu uzależnień czasowych. Konsekwencją jest konieczność uwzględnienia pojęcia czasu do

budowy algorytmu działania systemu. Algorytmy tworzą programiści pod dyktando architektów z uwzględnieniem zaleceń

technologów. Czy zatem użytkownik - przykładowo operator -musi mieć świadomość zależności algorytmów od czasu? Za-

gadnienie nie jest banalne i zasługuje na osobny artykuł, ale odpowiedź jest jednoznaczna – tak, ponieważ algorytmy mają pa-

rametry, którymi użytkownik dostraja zachowanie systemu do aktualnych potrzeb otoczenia.

W dziedzinie sterowania procesami, najczęściej dokonywany jest podział systemów informatycznych w przedsiębiorstwie

na tzw. klasy, zgodnie z funkcjami, jaką one realizują (Rysunek 1). Na potrzeby artykułu można ten podział jeszcze bardziej

uogólnić, grupując klasy systemów w następujące war-

stwy:

Biznesowa: gdzie znajdują się systemy wspomagające

zarządzanie przedsiębiorstwem, a w tym: zasobami, re-

lacjami z klientem, łańcuchem dostaw, produktami.

Głównym zadaniem tych systemów jest wykonywanie

analiz, wspieranie decyzji biznesowych, parametryzacja

procesu, administrowanie infrastrukturą oraz pomoc

w planowaniu działań operacyjnych. Tu często stosuje

się systemy klasyfikujące się do jednej z następujących

grup: ERP (ang. Enterprise Resource Planning), SAP

(ang. Systems Analysis and Product), CRM (ang. Cus-

tomer Relationship Management), SCM (ang. Supply

Chain Management), PLM (ang. Product Lifecycle

Management), GIS (ang. Geographical Information Sys-

tem).

Operacyjna: odpowiada za wykonanie planów opera-

cyjnych, widząc proces technologiczny (produkcję) jako

pewną całość – złożenie procesów składowych. Warstwę

operacyjną tworzą wszelkiego typu systemy wizualizacji

i nadzoru produkcji, a ich głównym zadaniem jest zarzą-

dzanie procesem technologicznym. Naturalnie warstwa ta jest bardzo często łącznikiem (pośrednikiem) w przetwarzaniu da-

nych z produkcji do warstwy biznesowej. Tu często stosuje się systemy klasyfikujące się do jednej z następujących grup: MES

(ang. Manufacturing Execution Systems), SCADA (ang. Supervisory Control And Data Acquisition) oraz HMI (ang. Human

Machine Interface).

1 Autor dziękuje dr inż. Sławomir Wróblewskiemu (DMCS Politechnika Łódzka) oraz mgr inż. Maciejowi Zbrzeznemu (CAS)

za pomoc i cenne uwagi.

Rysunek 1: Struktura systemów zarządzania


Produkcyjna (procesowa): Trudno mówić o warstwie, raczej jest to archipelag złożony z autonomicznych wysp systemów au-

tomatyki odpowiedzialnych za bezpośrednie sterowanie urządzeniami produkcyjnymi. Innymi słowy, jest to zbiór urządzeń

bezpośrednio przetwarzających fizyczne sygnały opisujące stan procesu i generujących sygnały sterujące, kontrolujące lokal-

nie jego przebieg. Głównym zadaniem systemów tej warstwy jest zapewnienie bezpiecznego przebiegu procesu technologicz-

nego i realizacja poleceń warstwy operacyjnej. Typowym przedstawicielem systemów tej warstwy są sterowniki PLC (ang.

Programmable Logic Controller) oraz systemy DCS (ang. Distributed Control System).

Nie zawsze wszystkie warstwy są dobrze zdefiniowane z wyraźnie zaznaczonymi granicami kompetencyjnymi, natomiast

zawsze występuje potrzeba komunikacji z warstwą procesową. Często zamiast używać terminu komunikacja, mówi się o inte-

growaniu systemów, ponieważ z faktu, że dane zostaną poprawnie przeniesione z umownego punktu A do punktu B nie wyni-

ka umiejętność przetworzenia ich w punkcie B. Innymi słowy komunikacja jest jedynie warunkiem koniecznym integracji.

Warto również zwrócić uwagę, iż do tej pory, pod pojęciem integracji systemów bardzo często rozumiano ujednolicanie pro-

cedur i procesów zachodzących wyłącznie w warstwie biznesowej.

Komunikacja i integracja nie są nowymi pojęciami, ale połączenie komunikacji, integracji i czasu rzeczywistego tworzy

nową dziedzinę, która rodzi całkowicie nową jakość w zakresie optymalizacji procesów wytwarzania. Tak rozumiana integra-

cja prowadzi do nowych możliwości w zarządzaniu przedsiębiorstwem, ale jednocześnie jest dużym wyzwaniem i aby mu

sprostać potrzebujemy nowych narzędzi i metod postępowania. W artykule omówiono standard OPC, który dobrze się już

sprawdził w aplikacjach należących do omawianej klasy zastosowań i wiele wskazuje za tym, że jego rola w tym zakresie bę-

dzie rosła.

OPC - INTERFEJS PROCESU

Koncepcja

Warstwa procesowa stanowi źródło danych dla procesów zarządzania. Zbudowana jest z różnorodnych urządzeń proceso-

wych, które udostępniają dane w różnych protokołach (językach). Każdy protokół to składnia, semantyka, uzależnienia czaso-

we, 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ład-

nie rozumiemy pod słowem standard.

Mamy zatem różnorodność standardów połączoną z różnorodno-

ścią rozwiązań proponowanych przez poszczególnych producentów

(Rysunek 2). Z punktu widzenia możliwości dopasowania rozwiązań

do naszych - zawsze przecież indywidualnych – potrzeb, ten fakt wy-

daje się dobrą nowiną, pod warunkiem, że łącząc elementy stosujemy

wyłącznie rozwiązania jednego producenta. Z punktu widzenia więk-

szych 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 komunika-

cji i sterowania cyfrowego próbują znaleźć rozwiązanie pozwalające

obejść te bariery. Firma General Motors na początku lat dziewięćdzie-

sią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).

Rysunek 2: Różnorodność- metoda, czy przeszkoda?


Przykładem pierwszej był projekt Manufacturing Automation Protocol (MAP), w którym pod wielopłaszczyznowym

przywództwem wspomnianej firmy GM grupa producentów z różnych branż próbowała zdefiniować protokół na bazie istnie-

ją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 postawiony

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 dru-

karki, musiał mieć do niej własny drajwer komunikacyjny. W nowszych systemach rozwiązano go, poprzez wbudowanie

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ść.

Innymi słowami, w rozważanym przypadku - nie oglądając się na pro-

ducenta systemu operacyjnego - możemy sami rozszerzyć jego funkcjonal-

ność o „drajwer do procesu technologicznego” (Rysunek 3).

Wydawało się, że powyższa koncepcja ma dwie istotne zalety i jedną

wadę. Pierwsza zaleta, to relatywnie łatwiejsza implementacja, ponieważ ta-

ki 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 ofero-

wanych poprzednio, a nawet obecnie, protokołów komunikacyjnych.

Podstawową wadą rozwiązania jest uzależnienie od systemu operacyj-

nego, 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 dedy-

kowanych 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ą dysku-

sję o wyższości innych protokołów komunikacyjnych nad OPC i odwrotnie.

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 rozbudowanej infrastrukturze

i centralnemu zarządzaniu nią możliwe jest zapewnienie odpowiednio bezpiecznej komunikacji pomiędzy urządzeniami proce-

sowymi i systemami zarządzania procesem i przedsiębiorstwem. Wydaje się, że - jak na prosty drajwer - jest to dość odpowie-

dzialna funkcja.

Skoro OPC nie jest ani protokołem komunikacyjnym, ani drajwerem, to czym zatem jest i co trzeba wiedzieć, aby sku-

tecznie planować wdrożenie i wykorzystywać OPC? Próbą znalezienia odpowiedzi na te pytania poświęcony jest ten artykuł.

Co to jest OPC?

Próbę odpowiedzi na powyższe pytanie warto za-

cząć od rozszyfrowania skrótu OPC. I to jest najprost-

sze zadanie, ponieważ skrót dziś nie oznacza nic – jest

nazwą własną. Pierwotnie oznaczał OLE for Process

Control, ale od kiedy technologia OLE nie jest wspie-

Rysunek 3: OPC- drajwer procesu?

Rysunek 4: OPC ściana dzieląca dwa światy ?


rana przez Microsoft takie znaczenie skrótu nie ma sensu.

Z przedstawionej powyżej koncepcji wynika, że konkretna implementacja, tzn. produkt implementujący serwer OPC, to

dwa w jednym (Rysunek 4):

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).

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 wspominane-

go komponentu - to informacja dla klienta (też pewien program), jak ma go używać i dla programisty co (ale nie jak) ma zaim-

plementować.

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 sta-

nowią 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ż me-

chanizm ten ma zastosowanie wyłącznie lokalne, tzn. komponenty mogą być wykorzystywane tylko przez aplikacje urucho-

mione na tym samym komputerze, w następnym kroku rozszerzono go o dostęp zdalny i tak powstał DCOM (ang. Distributed

Component Object Model).

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 znaleźć 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 im-

plementacji. 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 innymi

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 jed-

nego bitu reprezentującego pewną wielkość procesową (np. stan przekaź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 informa-

cje? Z drugiej strony, pomysł budowy zintegrowanego zarządzania na bazie protokołów klasy MODBUS jest pozbawiony ja-

kiegokolwiek 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średnictwem protokołu


komunikacyjnego bazującego na standardach z grupy WS-*. W obu przypadkach, niezależnie od istotnych różnic koncepcyj-

nych, używa się skrótowego określenia "technologia OPC" do określenia wszystkich przedstawionych powyżej uwarunkowań.

Niezależnie od definicji, w obu przypadkach cel jest taki sam, a mianowicie stworzyć ujednolicony mechanizm swobod-

nego 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.

DCOM

OPC wymaga platformy DCOM zarówno po stronie klienta, jak i serwera. Teoretycznie - zgodnie z pierwotną koncepcją -

istnienie DCOM dla użytkownika technologii OPC powinno być przezroczyste, podobnie jak dla użytkownika arkusza kalku-

lacyjnego istnienie systemu operacyjnego. Tak jednak nie jest. Aby to wyjaśnić, konieczne jest doprecyzowanie definicji kom-

ponentu, 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.

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 po-

trzeb pewną przestrzeń roboczą. W efekcie tworzony jest obiekt, który oprócz kodu i przydzielonej mu pamięci ma jeszcze

jedną kluczową cechę, a mianowicie tożsamość. Oznacza to, że komponent, analogicznie jak zwykły interaktywny użytkow-

nik, 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 upraw-

nień 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 pe-

wien nowy obiekt przeznaczony do obsługi jego żądania zakończenia sesji, tym razem po stronie klienta (Rysunek 6).

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żyt-

kownika istnienie platformy DCOM staje się całkowicie przezroczyste, a dowodem „życia” serwera jest wskaźnik zajętości

procesora i ewentualnie zużycia pamięci.

Specyfikacje OPC

OPC to pewien zbór interfejsów pogrupowanych w kategorie, z których każda dedykowana jest pewnej funkcjonalności.

Kategoria służy również do wyróżnienia kolejnych wersji poszczególnych grup interfejsów. Każda grupa jest opisana w osob-

nym 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 cyfrowy, 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 najważniejszych kategorii objętych specyfikacjami OPC na-

leżą:

OPC DA (ang Data Access) – zapewnia swobodny dostęp do aktualnych danych procesowych w czasie rzeczywistym.

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 wyznaczenia

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ń infor-

mują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 bezpie-

czeństwa dostępu do danych procesowych publikowanych przez serwer OPC poprzez uwierzytelnienie i autoryzację klien-

ta.

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 specyfi-

kacji 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ę.

SERWER

Lokalizacja serwerów w sieci

Aby klient nawiązał połączenie z wybranym serwerem, musi umieć go za-

adresować, a w tym celu musi znać dwa istotne szczegóły:

Adres stacji roboczej w sieci (zwykle adres IP), do której serwer jest podłą-

czony.

Unikalny w skali globalnej identyfikator (GUID) dla serwera.

W najprostszym przypadku obie informacje mogą być wpisane ręcznie w

konfigurację klienta i wtedy żaden dodatkowy mechanizm do nawiązania połą-

czenia nie jest potrzebny. Dzięki DNS (ang. Domain Name System) posługiwa-

nie się numeryczną postacią adresu sieciowego nie jest konieczne i możemy

używać łatwiejszych do zapamiętania adresów tekstowych. Ponadto sam system

operacyjny pozwala uzyskać listę komputerów podłączonych do segmentu lokal-

nego sieci.

W przypadku GUID, który jest liczbą 128-bitową, takiego wsparcia już nie

ma. Dlatego w ramach projektu OPC powstała specyfikacja dedykowanego kom-

ponentu OPCENUM, którego zadaniem jest dostarczenie wszystkich niezbęd-

nych informacji dotyczących lokalnie zainstalowanych serwerów, a w tym listy serwerów wspierających wybraną kategorię.

Wykorzystując oba mechanizmy przeglądania, klient w trakcie konfiguracji może użytkownikowi dostarczyć listę serwe-

rów, które spełniają wybrane kryteria. W efekcie konfiguracja klienta w zakresie wyboru odpowiedniego serwera sprowadza

się do kliknięcia go na wyświetlonej liście (Rysunek 5).

Współdziałanie klient - serwer

OPC implementuje typową architekturę klient - serwer, w której klient jest odpowiedzialny za zarządzanie relacjami z

serwerem (Rysunek 6). Oznacza to, że jest on odpowiedzialny kolejno za:

1. Lokalizowanie serwera.

2. Nawiązywanie z nim połączenia.

3. Generowanie żądań przysłania wybranych danych i wykonania na jego rzecz usług.

4. Rozłączenie połączenia.

Rysunek 5: Wybór serwera


Rysunek 6: Współpraca klient - serwer

Tyle teoria. W odróżnieniu od typowych dla automatyki protokołów komunikacyjnych, w których bazową koncepcją jest

przesyłanie danych, w OPC – paradoksalnie - nie można żądać przesłania wybranych danych. Wynika to z modelu obiektowe-

go komponentu (COM), w którym podstawą jest żądanie wykonania operacji przez utworzony wcześniej obiekt. Tak więc, aby

odczytać dowolne dane, musimy wykonać operację, która ma parametry wejściowe i wyjściowe. Dla użytkownika ma to fun-

damentalne znaczenie z dwóch powodów:

1. Bezpieczeństwa, ponieważ klient musi mieć prawo do zdalnego wykonywania operacji (nie ma uprawnień dostępu do

danych).

2. Sekwencji zdarzeń, ponieważ klient

musi poczekać, aż jakiś proces po stronie

serwera zakończy żądaną operację.

Pierwsze zagadnienie było już dyskuto-

wane wcześniej. W typowym protokole dla

urządzeń procesowych stosowana jest komu-

nikacja datagramowa, tzn. zapyta-

nie/odpowiedź, gdzie pytający czeka na od-

powiedź lub na upływ limitu czasu (ang. ti-

meout). I znów DCOM przestaje być war-

stwą przezroczystą, ponieważ klient nie ma

wpływu na reakcję na błędy w tym zakresie.

Wywołanie zdalne procedury realizują-

cej wybraną przez klienta operację z oczeki-

waniem na jej zakończenie nazywa się wy-

wołaniem synchronicznym (Rysunek 7).

OPC, dzięki wsparciu DCOM, daje również

inne możliwości. Jedną z nich jest wywołanie

asynchroniczne. Dla tego rodzaju wywołania

klient wysyła tylko żądanie wywołania pro-

cedury, jej parametry wejściowe i informacje

Rysunek 7: Typy operacji


„lokalizujące” miejsca dla rezultatu jej działania i dla informacji o jej zakończeniu. To w znacznym stopniu podnosi wydaj-

ność systemu, eliminując potrzebę aktywnego czekania, co często jest jednoznaczne z marnowaniem zasobów. Niestety taka

funkcjonalność niesie za sobą dodatkowe koszty. Aby odpowiedzieć, tym razem to serwer musi wywołać procedurę po stronie

klienta, co wymaga symetrycznej komunikacji sieciowej bez przeszkód w postaci zapór ogniowych.

W systemach automatyki zwykle interesują nas strumienie danych uszeregowane w czasie i odczytywane w stałych odstę-

pach – okresie impulsowania. I tu OPC oferuje rozwiązanie niemal idealne – subskrypcje (Rysunek 7). Upraszczając, sub-

skrypcja to rodzaj operacji asynchronicznej z jednym żądaniem i nieokreśloną ilością odpowiedzi, dokładnie tak, jak w przy-

padku subskrypcji czasopisma. Co więcej, można żądanie sformułować w postaci: „przesyłaj mi dane ..... pod warunkiem, że

ich wartość się zmieni o więcej niż...”. W takim przypadku, jeśli nie mamy nowych danych, zakładamy, że mają wartość stałą.

Podobny mechanizm zastosowano również w przypadku informowania o zdarzeniach, np. z jakiś powodów serwer musi

zakończyć pracę, co wymaga zakończenia wszystkich sesji podłączonych klientów (Rysunek 6). Żądanie klienta w tym przy-

padku ma postać: „daj mi znać, jak będziesz chciał się rozłączyć”. Ten mechanizm jest wbudowany w każdy serwer OPC, ale

oprócz niego są również dostępne mechanizmy pozwalające bardziej ogólnie określić użytkownikowi „co to jest zdarzenie lub

alarm”.

Dostęp asynchroniczny i zdarzeniowy do danych i usług jest bez wątpienia bardzo silnym wsparciem przy tworzeniu me-

chanizmów napędzających strumień danych produkowanych przez urządzenia procesowe w górę struktury informacyjnej. Za-

sada działania protokołów datagramowch wyklucza możliwość stosowania podobnych mechanizmów, co jest dużą zaletą OPC.

Jak to się za chwilę okaże, jest tylko jedno ale: OPC nie może ich zastąpić. To kolejny powód, aby unikać porównań, choć

analizowanie relacji jest bardzo pouczające.

Ustawienia regionalne

Prezentowanie wyników użytkownikowi po stronie klienta wymaga konwersji wszystkich danych z postaci binarnej do

postaci tekstowej lub graficznej (np. wykresy). Jednak niektóre informacje są reprezentowane wyłącznie w postaci tekstowej

(np. komunikaty o błędach, opisy, itp.) lub z jakiś powodów klient żąda przesyłania ich w takiej postaci (Rysunek 8). Przesy-

łanie klientowi tekstów wymaga uprzedniego uzgodnienia preferencji językowych użytkownika. W procesie uzgadniania klient

jest wyposażony w funkcję zwracającą dostępne po stronie serwera ustawienia regionalne, spośród których może wybrać swo-

je preferencje. Aby nie wprowadzać niejednoznaczności, ustawienia

regionalne nie zawsze są efektywne.

W rozważaniach związanych z lokalizacją, należy również

uwzględnić problemy istnienia wielu stref czasowych. Choć zwykle

wymaga to komunikacji za pośrednictwem sieci rozległych (co jest nie-

zwykle trudne z wykorzystaniem DCOM), klient i serwer nie mu- szą być

zlokalizowani w tej samej strefie czasowej. To rodzi trudność przy

szeregowaniu w czasie rezultatów pochodzących z różnych źró- deł.

Rozwiązano ten problem przez przyjęcie w specyfikacji OPC, że serwer

używa zawsze strefy uniwersalnej UTC, natomiast klient jest odpowie-

dzialny za uwzględnienie różnicy czasowej i ewentualnie czasu letniego.

Diagnostyka sesji klient - serwer

Wymianie danych klienta z serwerem musi towarzyszyć wymiana danych diagnostycznych. Dane te możemy podzielić na

trzy kategorie:

Status serwera (ang. server state).

Podtrzymanie komunikacji (ang. keep alive).

Komunikaty błędów.

Status serwera jest zwracany klientowi synchronicznie na żądanie i zawiera podstawowe dane identyfikacyjne oraz infor-

macje na temat poprawności pracy serwera - jego statusu.

W przypadku korzystania z subskrypcji ze zdefiniowanym progiem czułości dla sygnałów wolnozmiennych może pojawić

się niepewność, że brak reakcji serwera jest spowodowany brakiem jego poprawnego działania (dane nie zmieniają się, więc

nie ma potrzeby ich przesyłać). OPC zawiera pewien mechanizm, który wymusza przysyłanie informacji o charakterze „dowód

życia” (ang. keep alive) w regularnych odstępach czasu niezależnie od zmienności wartości zmiennych.

Rysunek 8: Konwersja na tekst


Biorąc pod uwagę, że w każdym programie jest jeszcze jeden błąd i każda komunikacja może zostać zakłócona

w najmniej spodziewanym momencie, aplikacje wspierające OPC muszą reagować na błędy w przewidywalny sposób. Ma w

tym pomóc bogaty zestaw zdefiniowanych identyfikatorów błędów, które mogą być zgłaszane wzajemnie przez serwer i klien-

ta. Specyfikacje zawierają instrukcje dla programistów odnośnie reakcji na błędy, więc znaczna ich część powinna być obsłu-

żona programowo i niewidoczna dla użytkownika. Jednak w bardzo wielu przypadkach, oprócz podjęcia kroków zaradczych,

aplikacje informują również użytkownika o problemie i wymagają od niego zadecydowania, co dalej. Dlatego OPC wspiera

użytkownika w diagnostyce, definiując dla obiektu serwera funkcję pozwalającą zwrócić opis błędu. Zatem po wystąpieniu

błędu, klient może zapytać serwer o jego znaczenie i otrzymany tekst przekazać użytkownikowi. Nadal jednak użytkownik

musi legitymować się podstawową wiedzą w zakresie OPC, by umieć skutecznie zdefiniować problem i go usunąć.

DANE PROCESOWE

Zmienna

Dane procesowe, to na ogół wartości pomiarowe

sygnałów fizycznych i sygnałów sterujących. Są repre-

zentacją informacji określającej stan procesu i wartości

sterowań. Dane procesowe, to pojęcie podstawowe dla

sterowania i - ogólniej – zarządzania procesem. To źró-

dło wiedzy, na podstawie którego staramy się tak stero-

wać przebiegiem procesu, aby osiągnąć założony cel

(spełnić pewną funkcję celu). Jednak pomimo tego, że

tytuł artykułu dotyczy tej tematyki, do tej pory termin

ten był użyty niewiele razy. Powód jest wydawałoby się

oczywisty: OPC nie jest przeznaczone do przetwarzania

danych. Innymi słowy, wykorzystanie OPC nie zmienia

wartości i lokalizacji danych procesowych, a tylko lub

aż ma ułatwiać swobodny dostęp do nich (Rysunek 9).

Podobnie jak pośredniczący między klientem i serwerem DCOM, OPC na drodze od procesu do aplikacji powinno być prze-

zroczyste. Ale tak nie jest. Aby to wyjaśnić, musimy dokonać chociaż powierzchownej analizy kilku zagadnień.

Podstawowym terminem OPC, używanym w procesie udostępniania danych, jest zmienna procesowa (ang. tag). Jest to

minimalna porcja danych, która jest adresowalna, tzn. posiada unikalny identyfikator i może być wskazana w operacji odczytu

i zapisu. Zatem wszystkie zmienne procesowe tworzą jedną wspólną płaską (bez wzajemnych powiązań) przestrzeń adresową.

Aby umożliwić optymalizację mechanizmów dostępu do danych z wykorzystaniem zmiennej, OPC oferuje mechanizm ich

grupowania i definiuje operacje dedykowane dla tak utworzonych grup (Rysunek 6). Za tworzenie grup i późniejsze zarządza-

nie nimi odpowiedzialny jest klient.

Przy większej ilości zmiennych procesowych zarządzanie (dodawanie,

usuwanie, wyszukiwanie) płaską przestrzenią adresową jest bardzo kłopo-

tliwe i sprzeczne z naszymi przyzwyczajeniami. Dziś wzorcem jest dome-

nowa postać adresów IP w Internecie i hierarchia folderów w systemie pli-

ków. Twórcy OPC postanowili wyjść naprzeciw tym oczekiwaniom i w

nowszych wersjach specyfikacji zaoferowali dwa różne mechanizmy dla

wspomnianej adresacji i wyszukiwania zmiennych procesowych (Rysunek

10). Wyszukiwanie oznacza etapowe przeglądanie (ang. browsing) pewnej

hierarchicznej (domenowej) przestrzeni adresowej, by ostatecznie uzyskać

wspomniany wyżej identyfikator zmiennej potrzebny do jej adresowania.

Aby zapewnić taką funkcjonalność każda zmienna ma swoją ścieżkę oraz

dodatkowo nazwę (ang. name), która jest unikalna względnie, tzn. w do-

menie wyznaczonej położeniem w utworzonej przez hierarchiczne powiązania strukturze drzewiastej (Rysunek 10). Mecha-

nizm ten przypomina wyszukiwanie numerycznych adresów IP w bazie DNS korzystając z adresów domenowych - teksto-

wych.

Przestrzeń adresowa w świecie OPC musi odpowiadać przestrzeni adresowej w urządzeniach procesowych (Rysunek 9).

Ponieważ do jednego serwera może i zwykle jest podłączonych wiele urządzeń procesowych, przestrzeń OPC musi być pewną

konkatenacją przestrzeni wszystkich urządzeń. Zatem, musi istnieć pewnego rodzaju tablica konwersji definiująca jednoznacz-

ne relacje pomiędzy zmiennymi obu przestrzeni. Relacje te zależą w dużej mierze od protokołu komunikacyjnego i samych

urządzeń. Relacje te powstają w trakcie konfiguracji serwera. Konfiguracja dla każdej zmiennej wymaga podania co najmniej:

Rysunek 9: OPC - dostęp do danych

Rysunek 10: Nazwa i identyfikator zmiennej.


Protokołu komunikacyjnego z urządzeniem, o ile można go zmienić.

Adresu urządzania w segmencie łączącym go z serwerem.

Adresu danej w urządzaniu – jak tą daną można odczytać.

Nazwy zmiennej.

Ścieżki dostępu do niej (położenia) w przestrzeni adresowej serwera.

Identyfikatora zmiennej w serwerze, o ile identyfikator ten nie jest wyznaczany na podstawie nazwy i położenia zmiennej

w przestrzeni (Rysunek 10).

Reasumując z każdą zmienną jest związany pewien rekord, zawierający wszystkie informacje potrzebne serwerowi, aby

opublikować ją w przestrzeni OPC i zagwarantować klientom swobodny dostęp do reprezentowanej przez nią danej.

Użytkownik (operator procesu) zwykle nie jest świadomy tych relacji, ponieważ korzysta z ekranów synoptycznych, gdzie

wartości sygnałów spotykają się bezpośrednio z graficzną reprezentacją procesu w postaci czytelnych diagramów.

Tablica relacji adresów ma natomiast fundamentalne znaczenie dla użytkowników odpowiedzialnych za utrzymanie ruchu.

Diagramy i skojarzone wartości są przeznaczone dla operatorów odpowiedzialnych za zarządzanie procesem. Synchronizacja

tych dwóch światów w przypadku dużej liczby zmiennych i wielu serwerów może być poważnym wyzwaniem, wymagającym

synchronizacji prac architektów, projektantów, integratorów, serwisantów i operatorów. Dobrą nowiną jest fakt, że te światy są

bardzo stabilne, a relacje trwałe - mają długie - sięgające miesięcy i lat - horyzonty czasowe.

Skoro korelacja adresacji jest tak istotna, to powstaje pytanie: czy i w jakim stopniu OPC wspiera ten proces? W OPC nie

przewidziano dedykowanych dla klienta mechanizmów do modyfikacji przestrzeni adresowej. W przypadku konieczności

zmiany przestrzeni po stronie procesu, użytkownik zwykle musi dokonać rekonfiguracji tablicy konwersji adresów, korzysta-

jąc z wbudowanych narzędzi. Jedyne wsparcie, na jakie możemy liczyć, daje wykorzystanie właściwości, które z definicji ma-

ją opisywać proces, a nie jego stan. OPC oferuje skromny aparat pozwalający operować na właściwościach. Omówiono go

w kolejnym rozdziale.

Wsparcie ze strony OPC w zakresie opisu samego procesu jest niewielkie, ale oferowana przez niektóre produkty funkcjo-

nalność pokazuje, że wystarczające by wspierać centralne usługi słownikowe (ang. dictionary), które pozwalają na zarządzanie

i czytelne wizualizowanie tego rodzaju informacji oraz synchronizowanie konfiguracji poszczególnych systemów.

Dużą zmianę w tym zakresie wnosi specyfikacja OPC UA, która opis procesu traktuje na równi z odwzorowaniem jego

stanu. Posługując się analogią do rozwoju sieci komputerowych, gdzie usługi transportu danych wyprzedzały rozwój metod

i narzędzi zarządzania ich zasobami, tu też należy spodziewać się szybkiego rozwoju, w którym OPC UA może być kamie-

niem milowym.

Wartość

Każda zmienna reprezentuje pewną daną procesową, ale nią nie jest (Rysunek 9). Faktyczna wartość danej procesowej

powstaje i jest zapisana w czeluściach urządzenia procesowego, podłączonego bezpośrednio do procesu technologicznego. Za-

tem dla użytkownika i architekta systemu fundamentalne znaczenie ma, w jaki sposób wartość zapisana w pamięci sterownika

jest transportowana do pamięci klienta i odwrotnie. Proces ten może być realizowany na wiele sposobów, a ponieważ wymaga

komunikacji pomiędzy serwerem OPC i urządzeniem procesowym (z wykorzystaniem specyficznego dla urządzenia protokołu

komunikacyjnego) - nie może całkowicie podlegać procesowi ujednolicania. Dlatego definiując operacje wspierające dostęp

do danych procesowych, twórcy specyfikacji OPC uwzględnili, że proces ten może być realizowany na wiele różnych sposo-

bów. Biorą dodatkowo pod uwagę różnorodność mechanizmów współpracy klienta z serwerem (dostęp: synchroniczny, asyn-

chroniczny, bezpośredni, pośredni), początkowo liczba możliwych kombinacji może budzić lęk. Tym bardziej, że budując sys-

tem czasu rzeczywistego - oprócz samego faktu dostępu do danych - musimy uwzględnić czas, w jakim ten dostęp jest reali-

zowany. I tu znów często wchodzimy w świat mitów i słyszymy: skoro DCOM (platforma dla OPC) nie jest czasu rzeczywi-

stego, to nie może służyć do budowy systemów czasu rzeczywistego.

Faktycznie, w wykorzystanej platformie systemowej DCOM nie ma mechanizmów gwarantujących wykonanie operacji

w zadanym z góry czasie, ale nie wszystkie systemy czasu rzeczywistego musza być zdeterminowane. W większości wystar-

czy jedynie „uwzględnić czynnik czasu w algorytmie działania”, co potwierdza praktyka, w tym przytoczony wcześniej przy-

kład zastosowania. Szczegółową analizę tego zagadnienia zostawmy środowisku akademickiemu, natomiast nie ulega wątpli-

wość, że problem ten musi być przedmiotem szczegółowej analizy oraz oceny przy projektowaniu i wdrażaniu systemów au-

tomatyki, a w szczególności wyznaczaniu granicy ich kompetencji. Przy rozwiązywaniu problemów uzależnień czasowych

niestety nie wystarczy już znajomość telefonu do zaprzyjaźnionego działu IT, jak to było w przypadku rozwiązywania proble-

mów z DCOM, ponieważ niezbędna jest również dobra znajomość fizyki zachodzących w procesie zjawisk.


Na podstawie wcześniejszej dyskusji możemy stwierdzić, że w przypadku serwera OPC mamy do czynienia z typową ar-

chitekturą, w której zastosowano komponent pośredniczący w celu dystrybucji funkcji (ang. middleware archetype). General-

nie, w takim modelu dostęp do danych możemy uzyskać na dwa sposoby (Rysunek 9):

1. Dostęp bezpośredni: dostarczenie wartości zmiennej klientowi musi być poprzedzone i jest zsynchronizowane z

odczytem z pamięci urządzenia (żółta strzałka).

2. Dostęp pośredni: wartość zmiennej dostarczanej klientom pochodzi z buforowej pamięci pośredniej (ang.

cache), gdzie wcześniej zastała asynchronicznie odczytana z urządzenia (brązowe strzałki).

W pierwszym przypadku musimy uwzględnić, że dana u klienta pojawi się z opóźnieniem wynikającym z opóźnień ko-

munikacyjnych. Dodatkowo, w wyniku błędów komunikacyjnych, proces odczytu może zostać przerwany, o czym klient jest

niezwłocznie informowany. W drugim natomiast istotne jest to, że przed rozpoczęciem operacji transferu pomiędzy pamięcią

i klientem, wartość już jest jakiś czas przechowywana. Ponadto pamięć może nie zawierać wartości dla wybranej zmiennej

w ogóle, tzn. mówiąc precyzyjniej - zawartość pamięci nie reprezentuje aktualnej wartości sygnału. Tu pojawia się nowe poję-

cie „świeżości danych”, a więc newralgiczny punkt styku z systemami

czasu rzeczywistego.

OPC pozwala uwzględnić pojęcie czasu w samej wartości zmiennej i

doborze parametrów operacji wykonywanych na serwerze do zmiennej

W koncepcji OPC dana procesowa zasadniczo jest złożeniem trzech

elementów (Rysunek 11) :

Wartości (ang. value) – określa stan procesu.

Znacznika czasu (ang. timestamp) – określa chwilę czasową, w któ-

rej wartość powstała.

Jakości (ang. quality) – określa poziom zaufania, jaki można mieć

przy jej wykorzystaniu.

Wartości, reprezentujące wielkości fizyczne, mogą być różnych ty-

pów. Typ zależy od postaci, w jakiej występują pierwotnie w urządzeniu i protokołu komunikacyjnego pomiędzy serwerem i

urządzeniem. Klient może zażądać konwersji pierwotnego typu danej procesowej - nazywanego typem kanonicznym (ang. ca-

nonical). Konwersja jest bardzo wygodnym mechanizmem dopasowania reprezentacji do potrzeb, ale ponieważ niektóre są

stratne, więc ich wykorzystanie może spowodować utratę precyzji reprezentacji.

Nie wszystkie urządzania procesowe i protokoły komunikacyjne potrafią się posługiwać (generować i przesyłać) pojęciem

znacznika czasowego. Z tego powodu jego miejsce powstania - a zatem precyzja reprezentowania chwili czasowej powstania

wartości - zależy w dużej mierze od konkretnego rozwiązania technicznego. Jeśli precyzja jest istotna dla algorytmów realizo-

wanych przez klienta, to powinna być oszacowana i uwzględniona już na etapie projektu systemu.

OPC definiuje bardzo ogólnie pojęcie jakości. Jakość jest reprezentowana przez jedną z wyliczonych wartości, która w

możliwie najbardziej wiarygodny sposób powinna reprezentować poziom zaufania do skojarzonej wartości. Niestety nie ma tu,

bo i być nie może, podanych żadnych wymiernych miar, które powinny być wykorzystane do jej wyznaczenia, co daje prak-

tycznie pełną swobodę dostawcy serwera i powoduje zmniejszenie poziomu ufności użytkownika w stosunku do przydatności

tego parametru.

Właściwość

Zarządzanie procesem przemysłowym wymaga dwóch rodzajów informacji: omówionych wcześniej danych procesowych

i meta-danych (ang. metadata). Meta-dane to ulubione słowo kluczowe informatyków, ponieważ brzmi poważniej niż "dane

opisujące dane". Tak, jak dane procesowe reprezentują fizyczny stan procesu, meta-dane opisują sam proces i dlatego w OPC

określane są mianem właściwości (ang. properties) (Rysunek 11). Do typowych właściwości należą między innymi: granice

technologiczne (ang. high/low level), jednostki inżynierskie (ang. engineering unit), typ wartości (ang. type) oraz okres ska-

nowania (ang. scanning rate). Pewne zaskoczenie może budzić fakt, że wartość zmiennej, jej znacznik czasowy i jakość też są

właściwościami zgodnie z nomenklaturą OPC. Jest to spowodowane dążeniem do uproszczenia przestrzeni adresowej i me-

chanizmów jej przeglądania oraz konieczności zachowania wstecznej kompatybilności wersji. Właściwości w OPC zostały

podzielone na trzy grupy: obligatoryjne, zalecane i definiowane przez producenta.

Szczególnie cennym zastosowaniem właściwości jest wykorzystanie ich do parametryzowania systemów warstw wyż-

szych. Przykładowo zmiana granic technologicznych w jednym serwerze może spowodować zmianę wartości granicznych w

definicjach alarmów wszystkich stacji typu SCADA (ang. Supervisory Control and Data Acquisition).

Rysunek 11: Dana=Wartość+Jakość+Znacznik+...


PODSUMOWANIE

OPC to technologia informatyczna opisana w kilkudziesięciu specyfikacjach, która pozwala producentom urządzeń proce-

sowych dostarczać wraz z nimi komponent programowy zapewniający swobodny i zunifikowany dostęp do danych proceso-

wych przetwarzanych przez te urządzenia. Dzięki unifikacji komunikacji i zastosowaniu architektury klient-serwer, OPC po-

zwala na znacznie szerszy dostęp do danych procesowych przez aplikacji warstw wyższych i łatwe wykorzystanie ich w zarzą-

dzaniu procesem i przedsiębiorstwem.

W specyfikacjach OPC opisano również procedury certyfikacji produktów na zgodność z OPC, w której silny nacisk kła-

dzie się na testowanie wzajemnego współdziałania (ang. interoperability testing).

Obecnie OPC to dwie niezależne technologie komunikacyjne oparte na dwóch niezależnych platformach komunikacyj-

nych: DCOM i usługach Internetowych (WS-*). Dla starszej, opartej na DCOM, zdefiniowano precyzyjną ścieżkę migracji, co

ma zagwarantować ciągłość w rozwoju i ewolucyjne wprowadzanie nowych rozwiązań.

OPC powinno być przedmiotem zainteresowania różnych grup zawodowych, a w tym:

Architektów - odpowiedzialnych za zbudowanie odpowiedniej architektury informacyjnej przedsiębiorstwa.

Programistów - implementujących specyfikacje w konkretnych produktach.

Projektantów - kreślących puzzle z dostępnych elementów.

Integratorów - układających te puzzle, czyli połączenie, uruchomienie i testowanie wdrażanych rozwiązań.

Serwisantów - diagnozujących, lokalizujących i usuwających usterki.

Operatorów - konsumujących dane uzyskane w celu bezpiecznego prowadzenia procesu.

Twórców systemów zarządzania – konsumujących dane i meta-dane w celu realizacji wybranej funkcji celu.

Wdrożenie OPC wymaga od wszystkich w różnym stopniu interdyscyplinarnej wiedzy w zakresie: technologii, automaty-

ki, komunikacji i informatyki.

Bez OPC tylko pełne wdrożenie systemów zarządzania jest niemożliwe lub bardzo utrudnione.

Bez OPC wszyscy mają łatwiejszą i mniej wymagającą pracę.

Używając kolokwialnego języka, możemy podsumować, że OPC podnosi wszystkim poprzeczkę, co powoduje pewien na-

turalny opór środowiska we wdrażaniu tej technologii. Da się go szczególnie wyczuć wśród niektórych dostawców rozwiązań

kompleksowych, bo stwarza dla nich groźbę utraty pozycji monopolisty, Jednak, ponieważ stwarza zupełnie nowe możliwości

w zakresie integracji systemów, technologia ta na trwałe weszła do systemów automatyki i dziś praktycznie nie ma przezna-

czonych dla automatyzacji produktów bez dostępnej funkcjonalności OPC. Natomiast wśród produktów warstw zarządzania

przedsiębiorstwem OPC nie jest jeszcze tak popularne.

Celem twórców OPC było zdefiniowanie mechanizmu ułatwiającego swobodny, zunifikowany dostąp do danych proce-

sowych przez systemy warstw wyższych. Dzięki unifikacji osiągnięto więcej – umożliwiono wykorzystanie OPC, jako plat-

formy integracji różnych systemów i w efekcie wykorzystanie efektu synergii drzemiącego w systemach rozproszonych. Pro-

ces integracji dopiero się rozpoczął, a ponieważ pozwala osiągnąć przewagę w bardzo konkurencyjnym środowisku - będzie

silnym stymulatorem rozwoju wszystkich rozwiązań wspierających integrację, a w tym OPC.

CAS

90-441 Łódź al. Kościuszki 103/105

tel/fax: +48 (42) 6862547; +48 (42) 6865028

www.commsvr.com

[email protected]

http://www.commserver.eu/

mailto:[email protected]


Artykuł został opublikowany w częściach, w magazynie „Control Engineering Polska”:

Część pierwsza pt. „W poszukiwaniu złotego środka”, „Control Engineering Polska” Nr 7(50) 2008

Część druga pt. „Głównie dla orłów”, „Control Engineering Polska” Nr 8(51) 2008

OPC - cas.internetdsl.pl · Skoro OPC nie jest ani protokołem komunikacyjnym, ani drajwerem, to...

Documents

Transcript of OPC - cas.internetdsl.pl · Skoro OPC nie jest ani protokołem komunikacyjnym, ani drajwerem, to...