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.

Case study: OPC pośredniczy w transmisji PLC-DCS

Problem: W przedsiębiorstwie z branży papierniczej przy tworzeniu systemu sterowania konieczne było wykorzystanie danych z dwóch różnych źródeł. W części zakładu, gdzie znajdował się system uzdatniania wody, wykorzystywano sterowniki PLC firmy Siemens, z których dane należało wprowadzić do systemu sterowania ABB Advant.

Początkowo planowano zrealizować komunikację w klasyczny sposób, wykorzystując sieć Profibus, jednak okazało się, że w tym przypadku ta metoda komunikacji jest kosztowna, a budowa sieci czasochłonna. Ponadto połączenie sterownika DCS z urządzeniem typu slave wymagało jego restartu, co za każdym razem wiązało się z przerwą w produkcji.

Rozwiązanie: W tym przypadku niezbędne było rozwiązanie, które zapewniłoby odpowiednią szybkość transmisji. Zdecydowano się wykorzystać serwer OPC KEPServerEX firmy KEPWare obsługujący wykorzystywane sterowniki firmy Siemens oraz proste w obsłudze oprogramowanie umożliwiające komunikację między serwerami OPC.

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

Zapytania ofertowe
Unikalny branżowy system komunikacji B2B Znajdź produkty i usługi, których potrzebujesz Katalog ponad 7000 firm i 60 tys. produktów
Dowiedz się więcej