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 ŁodziZajmują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.
