OPC - Nowoczesny standard komunikacji przemysłowej

Zarządzanie produkcją we współczesnym zakładzie przemysłowym wymaga zintegrowania wielu różnych systemów informatycznych. Komunikacja między nimi – np. układami monitorującymi procesy produkcyjne i sterującymi poszczególnymi urządzeniami jest z kolei warunkiem sprawnego zarządzania całością produkcji. Ze względu na różnorodność istniejących rozwiązań jeszcze do niedawna wymianę danych pomiędzy wieloma platformami trudno było zrealizować w praktyce. 

Rys. 1.Integracja różnych urządzeń i systemów automatyki przed i po wprowadzeniu specyfikacji OPC

Sytuacja uległa zmianie wraz z wprowadzeniem OPC, który jest otwartym standardem komunikacyjnym wykorzystywanym w automatyce przemysłowej. W artykule opisujemy elementy tej specyfikacji, w tym najnowszą wersję OPC UA, która może stać się w przemyśle rozwiązaniem globalnym, uniezależniającym komunikację od konkretnej platformy systemowej. 

Aby zobrazować, jakim problem przed pojawieniem się specyfikacji OPC było zintegrowanie w systemach automatyki różnych urządzeń i systemów, często przywołać można jako analogię instalację drukarki w systemach DOS i Windows. W przypadku DOS dostawca aplikacji musiał przygotować sterowniki wszystkich drukarek, które miały współpracować z daną aplikacją. W branży automatyki sytuacja była podobna (rys. 1). 

Przykładowo twórca oprogramowania dla HMI zobowiązany był dostarczyć wraz z nim sterowniki do każdego urządzenia – np. PLC różnych producentów. Rozwiązanie takie było dalekie od optymalnego, ponieważ w znacznym stopniu ograniczało współpracę między sprzętem i oprogramowaniem. W środowisku Windows usunięto ten problem, włączając obsługę drukarek do systemu operacyjnego. Obecnie jeden sterownik dostarczany przez producenta wykorzystywany jest przez wszystkie aplikacje.

Podobne rozwiązanie stało się możliwe w przemyśle właśnie za sprawą specyfikacji OPC. Od tej pory producenci dostarczają jedynie tzw. serwery OPC, czyli oprogramowanie zgodne ze standardem, które umożliwia wielu zewnętrznym systemom dostęp do informacji z danego urządzenia. Działanie OPC oparte jest na architekturze klient/serwer (rys. 2). Klientem OPC jest aplikacja wykorzystująca dane, np. systemy HMI i SCADA, z kolei serwer OPC jest źródłem danych. 

Rys. 2. Architektura klient/serwer w OPC

W praktyce ten ostatni to program związany z konkretnym urządzeniem, który pobiera z niego informacje i przetwarza w taki sposób, aby stały się one dostępne dla klientów OPC. Interakcja między klientem i serwerem zachodzi za pośrednictwem określonego interfejsu. Dzięki temu klient może komunikować się z dowolnym serwerem OPC, bez względu na rodzaj współpracującego z nim urządzenia.

RODZINA OPC

Dokładniejsze omówienie standardu wymaga cofnięcia się do początków jego rozwoju. Prace nad OPC rozpoczęto w latach dziewięćdziesiątych ubiegłego wieku. Powołano wówczas działającą do dziś organizację OPC Foundation, której zadaniem jest koordynacja i nadzór nad działaniami prowadzącymi do tworzenia i publikacji kolejnych specyfikacji OPC. 

Obecnie OPC Foundation liczy ponad 300 członków na całym świecie. Pierwsza specyfikacja, OPC DA (Data Access) opublikowana w 1996 roku, dotyczyła głównie akwizycji danych procesowych. Definiowała standardowy zestaw obiektów, interfejsów i metod wykorzystywanych w sterowaniu procesami i automatycznej produkcji. 

Rozproszone systemy sterowania wczoraj i dziś Rozproszone systemy sterowania (DCS – Distributed Control Systems) są ważnym elementem współczesnych zakładów przemysłowych już od ponad trzydziestu lat. W tym czasie wprowadzono trzy kolejne generacje tego typu rozwiązań. Pierwsze wersje DCS, oparte na mikrokomputerach, wdrażane były w zakładach przemysłowych już przed 1980 rokiem, głównie w postaci układów sterowania z pojedynczą pętlą sprzężenia zwrotnego. Technologia ta szybko rozwinęła się jednak w kierunku zwielokrotnionych układów kontrolnych, zwiększania możliwości obsługi coraz większej liczby wejść/wyjść oraz systemów HMI.  W porównaniu do wcześniejszych rozwiązań systemy DCS pierwszej generacji stanowiły olbrzymi krok naprzód. Ograniczeniem systemów DCS pierwszej generacji był fakt, że projektowano je dla określonych technologii komunikacyjnych. Wynikały stąd problemy z łączeniem systemów oferowanych przez różnych dostawców. Ten stan rzeczy zaczął ulegać zmianom w latach 90. ubiegłego wieku. DCS zaczęły być wówczas postrzegane jako optymalne narzędzie do integracji danych procesowych pochodzących z różnych platform sterowania instalowanych w obrębie jednego zakładu, co poszerzało możliwości zarządzania całym przedsiębiorstwem.  Możliwe stało się m.in. zdalne monitorowanie procesów, analiza wyopcdajności oraz koordynacja pracy poszczególnych węzłów. Rozwijanie technologii sieciowych i wykorzystanie komponentów opartych na rozwiązaniach firmy Microsoft oraz specyfikacji OPC sprzyjało rozpowszechnianiu się DCS. Z czasem ewoluowały one w kierunku systemów trzeciej generacji, w których wprowadzono narzędzia pozwalające monitorować efektywność procesu wytwórczego, np. awarie maszyn i przestoje z innych powodów. Dodatkowo, uzupełnieniem najnowszych rozwiązań DCS są zaawansowane technologie optymalizacji procesów. Przykłady powszechnie wdrażanych rozproszonych systemów sterowania to DeltaV firmy Emerson Process Management czy 800xA oferowany przez ABB i inne. Wraz z wymienionymi systemami producenci dostarczają oprogramowanie serwerów OPC umożliwiające dostęp do danych z DCS innym aplikacjom.

DeltaV OPC History Server Serwer DeltaV OPC History jest dostępny na stacjach Professional Plus oraz Application Station Serwer OPC History firmy Emerson jest, obok OPC Data Server i OPC Events Server, jedną z trzech aplikacji systemu DeltaV. Pierwsza z wymienionych, OPC Data Server, zapewnia dostęp do danych procesowych z systemu, z kolei serwer OPC Events realizuje dostęp do informacji o alarmach i zdarzeniach – np. systemowych czy akcjach operatora.  Serwer OPC History zgodny jest z najnowszą wersją specyfikacji OPC HDA i zapewnia zewnętrznym aplikacjom dostęp do danych archiwalnych systemu DeltaV. Pozwala on na przesłanie informacji z programu DeltaV Continuous Historian równocześnie do 25 różnych aplikacji klienckich, które uzyskują w ten sposób dostęp do danych historycznych przechowywanych w pamięci i wyników obliczeń na nich wykonywanych.  Aplikacja klienta OPC HDA może przeglądać wszystkie lub wybrane dane dostępne w DeltaV Continuous Historian, który ma możliwość akwizycji i przechowywania do dalszej analizy 250 analogowych, dyskretnych lub tekstowych parametrów wraz z ich statusem. Serwer DeltaV OPC History jest dostępny na stacjach roboczych Professional Plus oraz Application Station po zainstalowaniu oprogramowania DeltaV Continuous Historian.

Nadmiarowość danych Redundancja sprzętowa i programowa serwerów OPC DA Redundancja sprzętowa i programowa jest często wykorzystywana w komunikacji przemysłowej dla zapewniania niezawodności transmisji. Jest to szczególnie ważne w aplikacjach, w których przerwanie transmisji jest niedopuszczalne – np. ze względów bezpieczeństwa. Takie rozwiązanie jest m.in. możliwe z użyciem oprogramowania DeltaV OPC Data Access (DA) Server zainstalowanego na dwóch stacjach roboczych. Dodatkowy serwer OPC DA zapewnia nieprzerwaną transmisję w przypadku np. awarii jednej ze stacji.  W czasie normalnej pracy działa tylko jeden z serwerów, a w razie awarii drugi automatycznie przejmuje jego zadania, bez konieczności interwencji operatora. Wymagane jest jedynie zapewnienie komunikacji między tymi dwoma serwerami. Dzięki takiemu połączeniu można też automatycznie aktualizować oprogramowanie na obu stacjach. Pomimo że nadmiarowość dotyczy nie tylko samych serwerów, ale też stacji roboczych, systemy te widziane są przez aplikacje klientów OPC DA jako jedna stacja.  Połączenie to jest realizowane automatycznie, a ewentualna awaria jednej ze stacji również nie ma wpływu na komunikację z klientem. Aby aplikacje klienckie mogły komunikować się w ten sposób na zmianę z dwoma serwerami OPC, na stacji roboczej klienta należy jedynie zainstalować dodatkowy program.

Tab. 1. Porównanie klasycznego standardu OPC i jego nowe wersji OPC UA

Podobnie jak kolejne wersje OPC, w całości bazowała na technologii COM/DCOM firmy Microsoft . Pomimo początkowych obaw dotyczących wydajności, bezpieczeństwa transmisji i uzależnienia od technologii Microsoftu, specyfikacja OPC DA szybko stała się popularnym standardem komunikacji przemysłowej. Wpłynęło na to bez wątpienia rozpowszechnienie się komputerów opartych na systemie operacyjnym Windows, które są obecnie również standardem przemysłowym.

Szybko też uznano, że standaryzacja w dziedzinie wymiany innych informacji, np. danych o alarmach i danych archiwalnych, może być użyteczna. Przyspieszyło to prace nad kolejnymi częściami standardu OPC. Wszystkie używane aktualnie, a także rozwijane specyfikacje w związku z tym obejmują wersje OPC takie jak:

• Data Access (DA),
• Alarms&Events (A&E), czyli mechanizm powiadamiania klientów OPC o wystąpieniu określonych sytuacji,
• Batch odpowiadający za dostęp do danych w przetwarzaniu wsadowym,
• Data eXchange pozwalający na wymianę danych między serwerami OPC za pośrednictwem sieci Ethernet,
• Historical Data Access (HDA), czyli dostęp do informacji archiwalnych,
• Security – określający sposób kontroli dostępu do danych serwera w celu ochrony przed nieautoryzowaną modyfikacją danych procesowych przez aplikacje klientów,
• XML-DA, określający przetwarzanie danych procesowych z wykorzystaniem języka XML,
• Complex Data, który związany jest z obsługą złożonych typów danych,
• Commands,
• Unified Architecture, czyli nowy zestaw specyfikacji, uniezależniony od wykorzystywanej platformy systemowej.

OPC UA, CZYLI ARCHITEKTURA OBIEKTOWA I USŁUGI W AUTOMATYCE

Dostawcy oprogramowania użytkowego już od dawna wykorzystują programowanie obiektowe (OOP – Object Oriented Programming) i architektury zorientowane na usługi (SOA – Services-Oriented Architecture). Technologie te były jednak jak do tej pory rzadko wykorzystywane w aplikacjach przemysłowych. Opóźnienie ich adaptacji spowodowane było m.in. faktem, że aplikacje przemysłowe nie były zazwyczaj projektowane z myślą o przetwarzaniu złożonych informacji, gdzie lepiej jest jednak stosować model obiektowy. Z czasem sytuacja zaczęła ulegać zmianie i techniki OOP oraz SOA wkroczyły do przemysłu, w tym wpłynęły na OPC, czego skutkiem jest najnowsza wersja standardu – OPC UA.

Dziedziczenie Dziedziczenie pozwala tworzyć nowe obiekty na bazie już istniejących. Obiekty klasy Koło, Kwadrat i Trójkąt dziedziczą z klasy Figura metody takie jak Przesuń(), PobierzKolor() i UstawKolor(), przedefiniowują metody Rysuj() i Usuń(), a dodatkowo w klasie Trójkąt zdefiniowano dwie nowe funkcje do obracania figury. Podobnie jest w drugim przypadku. Obiekty klasy Klimatyzator i Pompa ciepła dziedziczą z klasy bazowej metodę Chłodzenie(), a w klasie Pompa ciepła zdefiniowano dodatkowo metodę Grzanie().

DLACZEGO PROGRAMOWANIE OBIEKTOWE?

Początkowo w oprogramowaniu używanym w systemach sterowania wykorzystywano głównie programowanie proceduralne. Podejście takie sprawdzało się dobrze w rozwiązywaniu prostych zadań. W miarę wzrostu komplikacji systemów kontrolnych pisanie nowych procedur do realizacji kolejnych zadań stawało się coraz bardziej kłopotliwe. Kod programu napisanego w taki sposób stawał się bardziej złożony, a co za tym idzie mniej czytelny i coraz trudniej rozszerzalny. 

Wadą takiego podejścia był też brak możliwości wielokrotnego wykorzystania raz napisanego kodu w innych aplikacjach ze względu na jego silne powiązanie z konkretnym problemem. Przełomem okazało się wprowadzenie techniki programowania zorientowanego obiektowo. W podejściu tym wykorzystywane są klasy i obiekty, których zbiór reprezentuje konkretny problem. Każdy obiekt ma określony stan oraz metody, które pozwalają na realizowanie określonych zadań. 

Ma to odniesienie do rzeczywistych urządzeń – przykładowo ze sterowaniem pracą kotła związanych jest szereg informacji, które lepiej jest analizować w odniesieniu do całego obiektu niż tylko jako kombinację oddzielnych parametrów, takich jak temperatura i ciśnienie. Wspomniany kocioł jest obiektem, który można włączyć lub wyłączyć, zmienić zadaną temperaturę oraz wpływać na pewne cechy. 

Wszystkie te działania i informacje są ze sobą powiązane i powinny być analizowane jednocześnie. Dlatego pisząc program, można, posługując się dalej tym przykładem, utworzyć obiekt klasy Kocioł, a jego parametrami będą temperatura i ciśnienie, metody takie jak „włącz” i „wyłącz” oraz reakcja na zdarzenia takie jak zbyt wysoka temperatura czy zbyt wysokie ciśnienie. Takie podejście w programowaniu jest bliskie sposobowi postrzegania świata przez człowieka.

TRZY KROKI DO OBIEKTOWOŚCI

Ważną zaletą programowania obiektowego jest również to, że raz powstałe rozwiązanie może być używane wielokrotnie. Tworząc aplikację serwera OPC dla wybranego systemu DCS, stworzyć można obiekty, które następnie, ze względu na swoją uniwersalność, ponownie wykorzystywane mogą być w tworzeniu serwera dla innego rozproszonego systemu sterowania. 

Jest to realizowane głównie dzięki trzem podstawowym mechanizmom programowania obiektowego: hermetyzacji, dziedziczeniu oraz polimorfizmowi. Hermetyzacja pozwala ukryć pewne cechy obiektu i w ten sposób kontrolować dostęp do nich ze strony innych obiektów. Dziedziczenie z kolei umożliwia tworzenie nowych obiektów na bazie już istniejących, ale rozszerzonych o dodatkowe cechy. Polimorfizm pozwala natomiast przedefiniowywać istniejące metody w zależności od potrzeb. Połączenie tych trzech mechanizmów zapewnia dużą elastyczność programowania.

OPC w Zespole Elektrociepłowni w Łodzi Zajmująca się wdrażaniem systemów automatyki przemysłowej firma CAS zrealizowała w łódzkim Zespole Elektrociepłowni projekt, którego głównym celem było zintegrowanie systemu GIS Smallworld z systemami telesterowania i telemetrii. Zapewniło to dostęp za pośrednictwem GIS do danych z trzech elektrociepłowni, systemu zdalnego sterowania zaworami w 19 komorach ciepłowniczych łódzkiego systemu ciepłowniczego wymiennikowni Smulsko, która dostarcza ciepło do osiedla domków jednorodzinnych, oraz systemu zdalnego sterownia drogą radiową dwoma stacjami obniżania ciśnienia (SOC). Struktura systemu Stacja klienta systemu GIS pobiera dane z serwerów OPC zainstalowanych w poszczególnych systemach telemetrii. Są to serwery OPC uruchomione na aplikacjach Wizcon, serwer OPC komputera BUSSniffer oraz stacji bazowej zbierającej dane z systemów telemetrii komór ciepłowniczych wymiennikowni Smulsko i stacji obniżania ciśnienia opartej na serwerze OPC Commserver. Wymiana informacji pomiędzy systemem GIS i systemem telemetrii i telesterowania jest kilkuczęściowa. Polega ona na odczycie aktualnych wyników pomiarów, sterowaniu systemem oraz aktualizacji bazy danych systemu GIS o zmiany w stanach armatury w poszczególnych komorach. Struktura systemu  Na rysunku przedstawiono połączenia, które zrealizowano w celu zintegrowania wymienionych systemów. Wykorzystując transmisję radiową, utworzono połączenie między stacją bazową i komorami ciepłowniczymi oraz między stacją bazową i wymiennikownią Smulsko. W oparciu o łącze RS232 i protokół SBUS zrealizowano też połączenie między stacją bazową i stacją bazową SOC. W połączeniu między stacją bazową i EC2 i EC3 wykorzystano skonfigurowane wcześniej połączenie OPC oparte na serwerach OPC aplikacji Wizcon.  Z kolei do realizacji połączenia stacja bazowa – EC4 wykorzystano komputer i oprogramowanie BUSSniffer pozyskujące i udostępniające dane przez serwer OPC. Połączenie stacja bazowa – aplikacja GIS – baza danych Oracle zrealizowano, wykorzystując klienta OPC DataPorter z modułami OPC2GISSMALWORLD oraz OPC2SQL. Opracowano na podstawie informacji na stronie internetowej firmy CAS

MODEL OBIEKTU W OPC UA

Rys. 3. Model obiektu w OPC UA

Prace nad OPC UA rozpoczęto już kilka lat temu, a pierwsze wersje standardu przedstawiono w 2006 roku. Znacząco rozszerzono w nim wykorzystanie metod zarządzania obiektami w aplikacjach przemysłowych, co pozwala tworzyć jeszcze bardziej skomplikowane, a zarazem bardziej elastyczne modele danych. 

Jednocześnie twórcy OPC UA starali się zachować zgodność nowej specyfikacji z poprzednimi wersjami standardu. Dlatego zawiera ona w sobie funkcje realizowane we wcześniejszych wersjach OPC, które jednak w dużym stopniu przeniesiono do systemu opartego na architekturze SOA i OOP. 

Podstawą do zdefiniowania uniwersalnego zestawu usług w OPC UA jest integracja różnych właściwości obiektów, które były niezależnie definiowane w innych specyfikacjach OPC. Wynikiem tego jest model, w którym obiekt jest opisywany za pomocą zmiennych, zdarzeń, metod i związanych z nim usług, co zostało zilustrowane na rysunku 3. Kolejną ważną zmianą wprowadzoną w OPC UA jest inna organizacja przestrzeni adresowej.

PRZESTRZEŃ ADRESOWA W OPC UA

Rys. 4. Niezależne przestrzenie adresowe

Każdy serwer OPC udostępnia obiekty jako węzły w zorganizowanej hierarchicznie przestrzeni adresowej. We wcześniejszych specyfikacjach standardu przestrzenie adresowe były całkowicie niezależne, co uniemożliwiało odniesienie węzłów w jednej przestrzeni do węzłów w innej i wymagało od aplikacji klienckiej kojarzenia punktów w obu przestrzeniach. Do zilustrowania koncepcji przestrzeni adresowej może posłużyć przykład przetwornika temperatury. 

Przekazuje on do systemu informację o aktualnej temperaturze oraz alarmuje w przypadku, gdy temperatura przekroczy określoną wartość maksymalną lub spadnie poniżej zadanego minimum. Przed wprowadzeniem OPC UA do wykorzystania danych w aplikacji klienta konieczne było zastosowanie dwóch interfejsów: OPC DA i OPC A&E oraz odpowiadających im przestrzeni adresowych. 

Mariusz Postol CAS Czy istnieją alternatywne do OPC sposoby lub standardy komunikacji, które wykorzystywane są w przemyśle? Większość urządzeń procesowych pozwala na dostęp do danych za pośrednictwem protokołów komunikacyjnych, więc pewnego opisu tego, co dzieje się w kanale komunikacyjnym. OPC Classic jest raczej instrukcją obsługi opisującą, jak wykorzystać system operacyjny do udostępnienia danych procesowych – ta fundamentalna różnica powoduje, że trudno jest wskazać bezpośrednią alternatywę. Jakie są przykładowe, krajowe wdrożenia systemów, gdzie do komunikacji użyto OPC? Unikalnym w skali światowej jest zastosowanie OPC jako platformy do integracji i sterowania siecią cieplną Zespołu Elektrociepłowni Dalkia Łódź. System ten pozwala na swobodne sterowanie dystrybucją ciepła produkowanego w trzech elektrociepłowniach o łącznej mocy 2,5GW zasilających wspólną sieć o długości ponad 800km. Czy sądzić można, że OPC jest w Polsce standardem znanym, czy wciąż jest on traktowany jako relatywnie specjalistyczny? Chociaż nie mam danych statystycznych, przytoczyć mogę opinię kolegi, który jako osoba odpowiedzialna za realizację programów partnerskich, odpowiedział na pytanie o postępy na tym polu. „Wydaje się, że OPC zostanie zaadaptowane na uczelniach za 5 lat, natomiast w przemyśle za 10 lat – stwierdził – jak dobrze pójdzie” – dodając. Krótko mówiąc, dzieli nas epoka. My wkroczyliśmy w świat OPC Unified Architecture w zeszłym roku, natomiast publikacja w APA to od kilkunastu lat dopiero drugi znany mi tego typu artykuł pojawiający się w polskiej prasie fachowej!

Aplikacja, chcąc uzyskać dostęp do informacji o aktualnej temperaturze, nawiązywała połączenie z serwerem OPC DA oraz oddzielne połączenie z OPC A&E, tak aby uzyskać dane o alarmach. Skorelowanie tych danych z konkretnym przetwornikiem było uzależnione od metody zaimplementowanej w aplikacji klienta, co zostało zilustrowane na rysunku 4. 

Rys. 5. Zintegrowana przestrzeń adresowa w OPC UA

OPC UA łączy te dwie oddzielne przestrzenie adresowe w jedną (patrz rys. 5). W tym przykładzie klient może „poruszać” się w jednej przestrzeni adresowej, tak aby zlokalizować zmienne i alarmy dotyczące przetwornika temperatury. Dodatkowo, korzystając z odnośników wprowadzonych w najnowszej specyfikacji, może on też odczytać, że urządzenie znajduje się w obszarze 3. 

OPC UA przewiduje możliwość definiowania w przestrzeni adresowej podzbiorów zwanych widokami, które można przeglądać niezależnie. Klient uzyskuje dostęp do widoków tak jak do oddzielnych przestrzeni adresowych. Widoki można definiować do określonych celów oraz ograniczać dostęp do nich wybranym grupom użytkowników.

ZINTEGROWANE USŁUGI W OPC UA

OPC UA charakteryzuje także nowe podejście do usług zapewniających dostęp do obiektów w przestrzeni adresowej. Dzięki określeniu ich pojedynczego, działającego w oparciu o zunifikowaną przestrzeń adresową zestawu, wyeliminowano tu występujące we wcześniejszych wersjach standardu zjawisko dublowania się zdefiniowanych usług. 

Przykładem jest możliwość przeglądania danych zdefiniowana w specyfikacji OPC DA – podobna usługa jest dostępna w OPC A&E. Korzystając jednak z obu tych usług, klient nie może stwierdzić jednoznacznie, że wyniki są związane z tym samym obiektem. OPC UA określa z kolei jedną usługę związaną z przeglądaniem, która pozwala aplikacji klienta „poruszać” się po przestrzeni adresowej oraz identyfikować poszczególne obiekty i związane z nimi zmienne, zdarzenia i metody.

W KIERUNKU ROZWIĄZAŃ WBUDOWANYCH

Wszystkie opisywane zmiany wprowadzone w OPC UA (a także inne, zebrane w tabeli 1) otwierają nowe możliwości wykorzystania tej specyfikacji w komunikacji przemysłowej, także w zastosowaniach dotychczas leżących poza jej zasięgiem. Przykładem jest stosowanie OPC UA w systemach wbudowanych. Możliwość tę otwiera fakt uniezależnienia się od platformy, co w tym wypadku oznacza nie tylko niezależność od systemu operacyjnego, ale także od używanego języka programowania i środowiska. Stos komunikacyjny OPC UA może być stworzony w językach ANSI C, C# lub Java. W wersji ANSI C OPC UA może być zaimplementowany bezpośrednio w systemie wbudowanym.

Case study: OPC w automatyce budynkowej OPC w automatyce budynkowej Problem: Dostawca systemów automatyki budynkowej miał za zadanie zintegrować kilka paneli dotykowych z interfejsem Modbus master z głównym systemem kontrolnym w budynku. Jak się jednak okazało, system zarządzania budynkiem również funkcjonował w standardzie Modbus jako master.  Możliwym rozwiązaniem było wyposażenie paneli w sterownik typu slave lub znalezienie innej metody na włączenie interfejsu slave do głównego systemu zarządzania. Okazało się jednak, że główny system kontrolny ma interfejs serwera OPC, co pozwoliło na rozwiązanie problemu w prostszy i tańszy sposób. Rozwiązanie: Skorzystano z komputera rozbudowanego o dodatkowe porty szeregowe. Połączono z nimi wszystkie panele dotykowe, wykorzystując łącze RS-422. Na komputerze zainstalowano też serwer OPC Modbus slave skonfigurowany do odbioru na poszczególnych portach, do których przyłączono panele.  Aby połączyć serwer OPC Modbus Slave z serwerem OPC systemu zarządzania budynkiem, wykorzystano oprogramowanie typu OPC-to-OPC bridge, które odwzorowuje punkty danych między dwoma serwerami. Jednorazowa konfi- guracja zapewniła szybką i niezawodną dwukierunkową transmisję pomiędzy panelami i systemem zarządzania budynkiem.

PODSUMOWANIE

Twórcy OPC UA określają tę specyfikację jako przełomową. Czas pokaże, czy spełni ona pokładane w niej nadzieje. Rozważając jednak technologie, na których oparto OPC UA i ich dotychczasowe sukcesy odnotowywane w innych dziedzinach, głównie w zakresie oprogramowania użytkowego (techniki OOP) oraz Internetu (architektura SOA), można oczekiwać, że choć w części uda się przenieść tę funkcjonalność na grunt aplikacji używanych w przemyśle.

Monika Jaworowska