W pierwszej części artykułu na temat integracji systemów automatyki z informatycznymi przedstawiliśmy specyfikację standardu OPC, który jest bardzo dobrym narzędziem do takich operacji. Tym razem omówimy kwestię komunikacji oraz danych procesowych.
Klient, który chce nawiązać połączenie z wybranym serwerem, musi umieć go zaadresować. W tym celu musi znać dwa istotne szczegóły: adres stacji roboczej w sieci (zwykle adres IP) oraz unikalny w skali globalnej identyfikator dla serwera (GUID).
W najprostszym przypadku obie informacje mogą być wpisane ręcznie w konfigurację klienta. Wtedy do nawiązania połączenia nie jest potrzebny żaden dodatkowy mechanizm. Dzięki DNS (Domain Name System) posługiwanie się numeryczną postacią adresu sieciowego nie jest konieczne. Możemy używać łatwiejszych do zapamiętania adresów tekstowych. Ponadto sam system operacyjny pozwala uzyskać listę komputerów podłączonych do segmentu lokalnego sieci. W przypadku GUID, który jest liczbą 128-bitową, takiego wsparcia już nie ma. Dlatego w ramach projektu OPC powstała specyfikacja dedykowanego komponentu OPCENUM, którego zadaniem jest dostarczenie wszystkich niezbędnych 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 dostarczyć użytkownikowi listę serweró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 (rys. 1.).
OPC implementuje typową architekturę klient ? serwer, w której klient jest odpowiedzialny za zarządzanie relacjami z serwerem (rys. 2.). Oznacza to, że jest on odpowiedzialny kolejno za:
- lokalizowanie serwera,
- nawiązywanie połączenia z nim,
- generowanie żądań przysłania wybranych danych i wykonania na jego rzecz usług,
- rozłączenie połączenia.
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 obiektowego 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.
Rys. 1. Wybór serwera. Współdziałanie klient ? serwer
Dla użytkownika ma to fundamentalne znaczenie z dwóch powodów:
- bezpieczeństwa, ponieważ klient musi mieć prawo do zdalnego wykonywania operacji (nie ma uprawnień dostępu do danych),
- sekwencji zdarzeń, ponieważ klient musi poczekać, aż jakiś proces po stronie serwera zakończy żądaną operację.
Pierwsze zagadnienie było już dyskutowane wcześniej (patrz: pierwsza część artykułu we wrześniowym wydaniu Control Engineering Polska). W typowym protokole dla urządzeń procesowych stosowana jest komunikacja datagramowa, tzn. zapytanie / odpowiedź, gdzie pytający czeka na odpowiedź lub na upływ limitu czasu (ang. timeout). I znów DCOM przestaje być warstwą przezroczystą, ponieważ klient w tym zakresie nie ma wpływu na reakcję na błędy.
Rys 2. Współpraca klient ? serwer
Zdalne wywołanie procedury realizującej wybraną przez klienta operację z oczekiwaniem na jej zakończenie, nazywa się wywołaniem synchronicznym (rys. 3.). OPC, dzięki wsparciu DCOM, daje również inne możliwości. Jedną z nich jest wywołanie asynchroniczne. W tym przypadku klient wysyła tylko żądanie wywołania procedury, jej parametry wejściowe i informacje ?lokalizujące? miejsca dla rezultatu jej działania i dla informacji o jej zakończeniu. To w znacznym stopniu podnosi wydajność systemu i eliminuje 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. A to wymaga symetrycznej komunikacji sieciowej bez przeszkód w postaci tzw. zapór ogniowych.
Rys. 3. Typy operacji
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 (rys. 3.). Upraszczając, subskrypcja to rodzaj operacji asynchronicznej z jednym żądaniem i nieokreśloną liczbą odpowiedzi. Dokładnie tak, jak w przypadku 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. Żądanie klienta ma w tym przypadku 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 do danych i usług jest bez wątpienia bardzo silnym wsparciem przy tworzeniu mechanizmów napędzających strumień danych produkowanych przez urządzenia procesowe w górę struktury informacyjnej. Zasada 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 przy tym jedno ?ale?. Otóż 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, na przykład komunikaty o błędach, opisy itp. (rys. 4.). Przesyłanie klientowi tekstów wymaga uprzedniego uzgodnienia preferencji językowych użytkownika. W procesie uzgadniania klient jest wyposażony w funkcję zwracającą ustawienia regionalne dostępne po stronie serwera, spośród których może wybrać swoje 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 niezwykle trudne z wykorzystaniem DCOM), klient i serwer nie muszą 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 zawsze używa strefy uniwersalnej UTC, natomiast klient jest odpowiedzialny 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 (server state),
- podtrzymanie komunikacji (keep alive),
- komunikaty błędów.
Status serwera zwracany jest klientowi synchronicznie na żądanie i zawiera podstawowe dane identyfikacyjne oraz informacje 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? (keep alive) w regularnych odstępach czasu niezależnie od zmienności wartości zmiennych.
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 klienta. 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ą reprezentacją informacji, która określa 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 sterować przebiegiem procesu, aby osiągnąć założony cel (spełnić pewną funkcję celu). Jednak pomimo tego, że artykuł dotyczy tej właśnie tematyki, do tej pory termin ten był użyty niewiele razy. Wydawać by się mogło, że powód jest oczywisty: OPC nie jest przeznaczone do przetwarzania danych. Innymi słowy, wykorzystanie OPC nie zmienia wartości i lokalizacji danych procesowych. Ma po prostu ułatwiać swobodny dostęp do nich (rys. 5.). Podobnie jak pośredniczący między klientem i serwerem DCOM, OPC na drodze od procesu do aplikacji powinno być ?przezroczyste?. Ale tak nie jest. Aby to wyjaśnić, musimy dokonać chociaż powierzchownej analizy kilku zagadnień.
Rys. 4. Konwersja na tekst
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. ma unikalny identyfikator oraz 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 (rys. 2.). Za tworzenie grup i późniejsze zarządzanie nimi odpowiada klient. Przy większej liczbie zmiennych procesowych zarządzanie (dodawanie, usuwanie, wyszukiwanie) płaską przestrzenią adresową jest bardzo kłopotliwe i sprzeczne z naszymi przyzwyczajeniami. Dziś wzorcem jest domenowa postać adresów IP w Internecie i hierarchia folderów w systemie plikó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 (rys. 6.). 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 domenie wyznaczonej położeniem w utworzonej przez hierarchiczne powiązania strukturze drzewiastej (rys. 6.). Mechanizm ten przypomina wyszukiwanie numerycznych adresów IP w bazie DNS, korzystając z adresów domenowych ? tekstowych.
Przestrzeń adresowa w świecie OPC musi odpowiadać przestrzeni adresowej w urządzeniach procesowych (rys. 5.). Ponieważ do jednego serwera może być ? i zwykle jest ? podłączonych wiele urządzeń procesowych, przestrzeń OPC musi być pewną konkatenacją przestrzeni wszystkich urządzeń. Musi zatem istnieć pewnego rodzaju tablica konwersji definiująca jednoznaczne relacje pomiędzy zmiennymi obu przestrzeni. Relacje te zależą w dużej mierze od protokołu komunikacyjnego i samych urządzeń. Powstają w trakcie konfiguracji serwera. Konfiguracja dla każdej zmiennej wymaga podania co najmniej:
- protokołu komunikacyjnego z urządzeniem, o ile można go zmienić,
- adresu urządzenia 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 nie jest wyznaczany na podstawie nazwy i położenia zmiennej w przestrzeni (rys. 6.).
Rys. 5. OPC ? dostęp do danych
Reasumując, z każdą zmienną związany jest pewien rekord. Zawiera on wszystkie informacje potrzebne serwerowi do opublikowania jej w przestrzeni OPC i zagwarantowania klientom swobodnego dostępu do reprezentowanej przez nią danej. Użytkownik (operator procesu) zwykle nie jest świadomy tych relacji. Korzystaon 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. Wymaga ono synchronizacji prac: architektów, projektantów, integratorów, serwisantów i operatorów.
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, korzystając z wbudowanych narzędzi. Jedyne wsparcie, na jakie możemy liczyć, daje wykorzystanie właściwości, które z definicji mają 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. Jednak oferowana przez niektóre produkty funkcjonalność pokazuje, że jest ono wystarczające do wspierania centralnych usług słownikowych (ang. dictionary). Pozwala 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: usługi transportu danych wyprzedzały rozwój metod i narzędzi zarządzania zasobami. W przypadku OPC też należy spodziewać się szybkiego rozwoju, w którym OPC UA może być kamieniem milowym.
Dane procesowe ? wartość
Każda zmienna reprezentuje pewną daną procesową, ale nią nie jest (rys. 5.). Faktyczna wartość danej procesowej powstaje i jest zapisana w urządzeniu procesowym bezpośrednio podłączonym do procesu technologicznego. Zatem dla użytkownika i architekta systemu fundamentalne znaczenie ma sposób, w jaki wartość zapisana w pamięci sterownika jest transportowana do pamięci klienta i odwrotnie. Proces ten może być realizowany na wiele sposobów. Ponieważ wymaga komunikacji pomiędzy serwerem OPC i urządzeniem procesowym (z wykorzystaniem specyficznego dla niego 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 sposobów. Wzięli dodatkowo pod uwagę różnorodność mechanizmów współpracy klienta z serwerem ? dostęp: synchroniczny, asynchroniczny, bezpośredni, pośredni? Początkowo liczba możliwych kombinacji może budzić lęk. Tym bardziej, że budując system czasu rzeczywistego ? oprócz samego faktu dostępu do danych ? musimy uwzględnić czas, w jakim ten dostęp jest realizowany. I tu znów często wchodzimy w świat mitów i słyszymy: skoro DCOM (platforma dla OPC) nie jest czasu rzeczywistego, 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. Jednak nie wszystkie systemy czasu rzeczywistego muszą być zdeterminowane. W większości wystarczy jedynie uwzględnić czynnik czasu w algorytmie działania, co potwierdza praktyka, w tym przytoczony wcześniej przykład zastosowania. Szczegółową analizę tego zagadnienia zostawmy środowisku akademickiemu. Nie ulega natomiast wątpliwość, że problem ten musi być przedmiotem szczegółowej analizy oraz oceny przy projektowaniu i wdrażaniu systemów automatyki. W szczególności przy wyznaczaniu granicy ich kompetencji. Przy rozwiązywaniu problemów uzależnień czasowych nie wystarczy już niestety znajomość telefonu do zaprzyjaźnionego działu IT, jak to było w przypadku rozwiązywania problemów z DCOM. Niezbędna jest dobra znajomość fizyki zjawisk zachodzących w procesie.
Rys. 6. Nazwa i identyfikator zmiennej
W przypadku serwera OPC mamy do czynienia z typową architekturą, w której zastosowano komponent pośredniczący, w celu dystrybucji funkcji (ang. middleware archetype). W takim modelu dostęp do danych możemy uzyskać na dwa sposoby (rys. 5.): 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).
Dostęp pośredni: wartość zmiennej dostarczanej klientom pochodzi z buforowej pamięci pośredniej (ang. cache), gdzie wcześniej został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ń komunikacyjnych. 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ść jest już przez 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 dobór parametrów operacji wykonywanych na serwerze do zmiennej.
W koncepcji OPC dana procesowa zasadniczo składa się z trzech elementów (rys. 7.):
- wartości (ang. value) ? określa stan procesu,
- znacznika czasu (ang. timestamp) ? określa chwilę, 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 typów. Typ zależy od postaci, w jakiej występują pierwotnie w urządzeniu i w protokole komunikacyjnym pomiędzy serwerem i urządzeniem. Klient może zażądać konwersji pierwotnego typu danej procesowej ? nazywanego typem kanonicznym (ang. canonical). Konwersja jest bardzo wygodnym mechanizmem dopasowania reprezentacji do potrzeb. Z tego jednak względu, że 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 miejsce jego powstania ? a zatem precyzja reprezentowania chwili powstania wartości ? zależy w dużej mierze od konkretnego rozwiązania technicznego. Jeśli precyzja jest istotna dla algorytmów realizowanych 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. W praktyce daje to pełną swobodę dostawcy serwera i powoduje zmniejszenie poziomu ufności użytkownika w stosunku do przydatności tego parametru.
Dane procesowe ? właściwość
Rys. 7. Dana=wartość+jakość+znacznik+…
Zarządzanie procesem przemysłowym wymaga dwóch rodzajów informacji: omówionych wcześniej danych procesowych i metadanych (ang. metadata). Metadane to ulubione słowo kluczowe informatyków, ponieważ brzmi poważniej niż ?dane opisujące dane?. Tak jak dane procesowe reprezentują fizyczny stan procesu, metadane opisują sam proces. Dlatego w OPC określane są mianem właściwości (ang. properties) (rys. 7.). 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 skanowania (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 mechanizmó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.
Wysoko zawieszona poprzeczka
OPC to technologia informatyczna opisana w kilkudziesięciu specyfikacjach. Pozwala producentom urządzeń procesowych dostarczać wraz z nimi komponent programowy, który zapewnia swobodny i zunifikowany dostęp do danych procesowych przetwarzanych przez te urządzenia. Dzięki unifikacji komunikacji i zastosowaniu architektury klient- -serwer OPC pozwala na znacznie szerszy dostęp do danych procesowych przez aplikacje warstw wyższych oraz łatwe wykorzystanie ich w zarządzaniu procesem i przedsiębiorstwem.
Obecnie OPC to dwie technologie oparte na dwóch niezależnych platformach komunikacyjnych: 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,
- 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 metadane w celu realizacji wybranej funkcji celu.
Wdrożenie OPC wymaga od wszystkich interdyscyplinarnej wiedzy w zakresie: technologii, automatyki, komunikacji oraz informatyki. Bez OPC wszyscy mają łatwiejszą i mniej wymagającą pracę. Krótko mówiąc: OPC podnosi wszystkim poprzeczkę, co powoduje pewien naturalny opór środowiska we wdrażaniu tej technologii. Szczególnie mocno da się go wyczuć wśród niektórych dostawców rozwiązań kompleksowych. W ich przypadku OPC stwarza groźbę utraty pozycji monopolisty. Jednak dzięki temu, że oferuje zupełnie nowe możliwości w zakresie integracji, technologia ta na trwałe weszła do systemów automatyki.
Dziś praktycznie nie ma produktów przeznaczonych do automatyzacji bez dostępnej funkcjonalności OPC. Natomiast wśród produktów do zarządzania przedsiębiorstwem OPC nie jest jeszcze tak popularne. Proces integracji dopiero się rozpoczął. Jako że pozwala osiągnąć przewagę w bardzo konkurencyjnym środowisku, będzie silnym stymulatorem rozwoju wszystkich rozwiązań wspierających integrację, a w tym OPC.
Dr inż. Mariusz Postół
jest pracownikiem Samodzielnego Zakładu Sieci Komputerowych Politechniki Łódzkiej.
Autor dziękuje
drowi inż. Sławomir Wróblewskiemu (DMCS Politechnika Łódzka) oraz
mgrowi inż. Maciejowi Zbrzeznemu (CAS) za pomoc i cenne uwagi.