OPC UA: Część 2: Dlaczego czas na nowy standard.

Część druga serii artykułów poświęconych technologii OPC Unified Architecture (OPC UA)(zobacz część pierwszą/trzecią)

Technologia OPC narodziła się w latach 90’tych i zdobyła od tego czasu dużą popularność. Jej dojrzały wiek oraz fakt wykorzystywania jej po dziś dzień, dowodzi że jest to technologia znana i o ugruntowanej pozycji. Jednak wiek ponad dziesięciu lat w systemach IT to bardzo dużo. Może warto coś zmienić?

Aktualne specyfikacje OPC bazują na technologii COM/DCOM. Jej podstawową wadą jego uzależnienie od platformy systemów Windows firmy Microsoft. Dodatkowo DCOM często sprawia szereg problemów konfiguracyjnych przy wdrażaniu nowego systemu i nie pozwalała na komunikację poprzez sieć Internet. Z tych względów technologia DCOM jest aktualnie wypierana przez nowsze technologie. Sam Microsoft, twórca platformy COM/DCOM, prezentując nowe sposoby komunikacji bazującej na technologii .NET przyznał, że dni DCOM’a zdają się być policzone. Świat wybrał inne technologie zorientowane usługowo (Service Oriented Architecture – SOA), a jaki kierunek powinien być wybrany dla OPC?

Pierwszą próbą odejścia od DCOM było powstanie specyfikacji XML DA, w tym rozwiązaniu wywołania funkcji oraz dane procesowe miały być przesyłane przy użyciu standardu XML. Ta jednak nie spotkała się z dużym zainteresowaniem. Powodów mogło być wiele, począwszy od słabej promocji nowego standardu i małej innowacyjności (nowe rozwiązanie nie wnosiło znacząco nowej funkcjonalności), a skończywszy na największej rozgłaszanej wadzie, którą była mniejsza wydajność rozwiązania opartego o XML w stosunku do tego, co oferował DCOM.

DCOM nie jest jednak jedynym mankamentem istniejących specyfikacji. Za kolejną można uznać podział na wiele nie zawsze spójnych specyfikacji (DA, HDA, A&E, DX). Istotny jest też fakt, iż żadna z nich nie pozwala na zapisanie i przedstawienie wszystkich zależności pomiędzy elementami obsługiwanego procesu i brak wsparcia dla jego modelowania. OPC opisuje wiele różnych specyfikacji, które nie mają zunifikowanej przestrzeni adresowej (informacji na temat prezentowanych danych). Dodatkowo coraz częściej użytkownicy końcowi mieli dodatkowe wymagania. Jednym z nich była możliwość utrzymywania programów (często nazywanych komendami (commands)). Kolejnym była potrzeba przechowywanie historii zdarzeń (History for Events). Kłopoty sprawiał też nieuporządkowany model danych, w którym każdy dostawca rozwiązań bazujących na OPC (w tym przypadku zarówno deweloper jak i integrator) umieszczali obiekty w sposób dowolny i wspierający tylko ich wymagania, a użytkownicy coraz częściej nie tylko zainteresowani byli odczytem bądź zapisem struktur (danych) do serwerów OPC, ale również modyfikowaniem przestrzeni adresowej serwera.

Kolejnym elementem podnoszonym podczas dyskusji na temat specyfikacji OPC jest brak związku pomiędzy funkcjonalnościami oferowanymi przez różne typy serwerów. Serwer OPC HDA zatem może udostępniać zupełnie inną przestrzeń adresową niż serwer OPC DA, mimo że oba współpracują z tym samym procesem. Przykładowo te same obiekty w przestrzeni adresowej mogą mieć różne nazwy, a związki między nimi nie są w żaden sposób reprezentowane. Szczególnie kłopotliwy jest z serwer OPC A&E ten również może operować na innej przestrzeni adresowej niż serwer OPC DA (choć w przypadku serwerów DA i A&E powiązanie pomiędzy ich przestrzeniami adresowymi jest bardzo istotne), a osoba odpowiedzialna za integrację i utrzymanie systemu, często zmuszona jest utrzymywać zupełnie różne przestrzenie adresowe dla każdego z serwerów osobno.

Mając na uwadze te wszystkie znane od dawna bolączki standardu OPC, OPC Foundation zaczęło pracę nad projektem nowej zunifikowanej architektury dla OPC (OPC Unified Architecture - w skrócie OPC UA), która zastąpi (w niedalekiej przyszłości), zmodernizuje i rozszerzy dotychczasową funkcjonalność aktualnych interfejsów OPC.

Czytaj dalej.