Dr inŝ. Krzysztof Skura, Dr inŝ. Zbigniew Smalec Instytut Technologii Maszyn i Automatyzacji Politechniki Wrocławskiej PROBLEMY INTEGRACJI SYSTEMÓW STEROWANIA I SYSTEMÓW INFORMATYCZNYCH OPARTYCH O TECHNIKĘ KOMUNIKACJI OPC Integracja systemów informatycznych oraz systemów sterowania i nadzorowania instalacji technologicznych wciąŝ przysparza wiele problemów w szczególności, kiedy poszczególne systemy pochodzą od róŝnych dostawców lub są oparte o róŝne platformy sprzętowe i programowe. Prace nad otwartą i niezaleŝną od dostawcy platformą komunikacyjną, umoŝliwiającą elastyczną integrację systemów sterowania procesów produkcyjnych z systemami informatycznymi przedsiębiorstwa, są prowadzone od wielu lat. W szczególności platforma OPC (ang. OLE for Process Control) zasługuje na uwagę ze względu na jej szerokie rozpowszechnienie w przemyśle procesowych, takim jak chemiczny czy teŝ spoŝywczy. W artykule tym przedstawiono metodę integracji opartą o technologię OPC oraz tzw. tunelowanie OPC. Spośród informatycznych systemów zarządzania przedsiębiorstwem oraz wspomagania i sterowania produkcji wyróŝnia się obecnie systemy takie jak: ERP (ang. Enterprise Resource Planning), SCM (ang. Supply Chain Management), P/PE (ang. Product and Process Engineering), MES (ang. Manufacturing Execution Systems), SCADA (ang. Supervisory Control and Data Acquisition) i wiele innych. Integracja informatyczna tych systemów bezpośrednio z układami sterowania procesami produkcyjnymi jest zadaniem skomplikowanym w szczególności, kiedy mamy do czynienia ze środowiskiem rozproszonym, tzn. poszczególne systemy są geograficznie oddalone od siebie i są one połączone za pomocą infrastruktury sieci LAN lub WAN. Prace nad otwartą platformą komunikacyjną integrującą systemy sterowania linii produkcyjnych z systemami informatycznymi zaowocowały w 1996 roku powstaniem pierwszej specyfikacji OPC nazywanej Data Access Specification. OPC szybko stał się de facto standardem komunikacyjnym integrującym systemy sterowania z systemami informatycznymi przedsiębiorstw. SCADA/HMI Web HMI ERP, MES, Data Base Client for ODBC LAN PLC IPC/SlotPLC I/O Rys. 1. Środowisko komputerowe połączone poprzez OPC Obecnie istnieją następujące specyfikacje OPC: OPC Data Access wymiana danych procesowych pomiędzy systemami DCS lub PLC a systemami monitorowania nadrzędnego HMI, SCADA (rys.1). Aktualnie udostępniona jest wersja 3 specyfikacji wprowadzająca język XML do specyfikacji Data Access. OPC Alarms & Events zawiadamianie o alarmach i zdarzeniach występujących na obiekcie. OPC Batch definiuje interfejs dostępu do danych wymaganych w przetwarzaniu wsadowym (tzw. batch processing) Specyfikacja ta opiera się na specyfikacji Data Access i rozszerza ją o funkcje obsługi procedur wsadowych. OPC Data exchange wymiana danych procesowych pomiędzy serwerami OPC poprzez sieć obiektową Ethernet. Specyfikacja ta obejmuje takŝe zdalne konfigurowanie OPC, diagnostykę, zarządzanie oraz monitorowanie serwera OPC.
OPC Historical Data Access archiwizacja danych bieŝących i historycznych oraz udostępnianie tych danych w zunifikowanej formie. OPC Security bezpieczny dostęp do danych procesowych mających duŝe znaczenie dla przedsiębiorstwa. Specyfikacja ta określa sposób dostępu do danych i zabezpiecza przed nieautoryzowanymi zmianami tych danych. OPC XML-DA specyfikacja określająca jednolity i spójny sposób eksponowania danych z uŝyciem do tego celu języka XML. Technika OPC przyniosła wiele korzyści zarówno integratorom systemów automatyki przemysłowej jak i uŝytkownikom końcowym tych systemów zakładom produkcyjnym. NaleŜy tu podkreślić, Ŝe komunikacja na bazie technologii OPC znacznie ograniczyła nakład pracy wymagany w fazie projektowej i wdroŝeniowej systemu sterowania oraz spowodowała, Ŝe integracja systemu sterowania złoŝonego z urządzeń pochodzących od wielu producentów stała się moŝliwa i prosta do wykonania. Wraz z rozpowszechnieniem OPC odnotowano wiele korzyści takich jak: producenci sterowników i urządzeń automatyki, np. sterowników PLC, opracowali i dostarczają przetestowane i zgodne z zaleceniami specyfikacji oprogramowanie OPC, producenci oprogramowania do nadzorowania procesów przemysłowych oraz akwizycji danych SCADA nie muszą juŝ opracowywać sterowników programowych (ang. driver s)do urządzeń automatyki - obowiązek ten spadł na producentów tych urządzeń, wszelkie zmiany funkcji urządzeń automatyki, sterowników są natychmiast przenoszone przez ich producentów na oprogramowanie OPC. NaleŜy dodać, Ŝe udostępnienie specyfikacji OPC spowodowało powstanie wielu małych firm zdecydowanie konkurujących z wielkimi firmami i opracowujących własne oprogramowanie OPC, np. integrujące systemy sterowania z bazami danych czy oprogramowaniem biurowym takim jak arkusze kalkulacyjne. TUNELOWANIE DANYCH POPRZEZ OPC TUNNELLER Standard OPC opiera się na opracowanej przez firmę Microsoft technologii COM (ang. Component Object Model) I DCOM (ang. Distributed Component Object Model). Technologie ta stanowią pewnego rodzaju platformy komunikacyjne, która definiują w jaki sposób aplikacje OPC wzajemnie się komunikują i współdzielą dane procesowe. Aplikacje OPC mogą pracować w środowisku lokalnym jednego komputera lub w środowisku rozproszonym, tzn. na wielu komputerach połączonych siecią komputerową. W warunkach pracy sieciowej ujawniają się niestety takie wady komunikacji opartej o COM/DCOM jak trudności w skonfigurowaniu połączenia oraz problemy z utrzymaniem połączenia pomiędzy klientem a serwerem. W skrajnych przypadkach mogą wystąpić przerwy w wymianie danych procesowych, co z kolei moŝe doprowadzić do zatrzymania procesu produkcyjnego. Wadą modelu DCOM jest takŝe Ŝmudna konfiguracja zabezpieczeń w szczególności po zainstalowaniu tzw. dodatku SP 2 w systemie operacyjnym Windows XP. Konfiguracja DCOM dla aplikacji zainstalowanych w róŝnych domenach systemu operacyjnego Windows takŝe przysparza wiele problemów konfiguracyjnych. W takiej sytuacji domeny muszą współdzielić przynajmniej jedną wspólną nazwę uŝytkownika (ang. Username) i hasło (ang. Password). Jest to rozwiązanie kłopotliwe jeŝeli wspomniane domeny i aplikacje OPC są własnością róŝnych grup roboczych, róŝnych producentów albo nawet całkowicie róŝnych firm. Dane procesowe OPC pochodzące od jakiejś konkretnej grupy mogą być zablokowane i nie docierać do odbiorcy (klienta OPC) chyba, Ŝe kwestie bezpieczeństwa DCOM zostaną przezwycięŝone. Konfiguracja DCOM stoi więc bezpośrednio na drodze budowy otwartych połączeń typu plug and play, a więc jednego z podstawowych załoŝeń technologii OPC. Typowe przyczyny błędów w komunikacji DCOM to: problemy sprzętowe, takie jak wadliwa karta sieciowa, router lub przełącznik (ang. switch), kwestie systemowe, takie jak przeciąŝenia sieci, kwestie niestabilności architektury sieciowej (połączenia satelitarne, WAN, komunikacja radiowa itp.). Niestety producenci aplikacji OPC nie mają moŝliwości programowej kontroli nad DCOM i dlatego teŝ są uzaleŝnieni od jego ograniczeń. W wyniku tego większość konfiguracji duŝych systemów wiąŝe się ze znacznymi nakładami finansowymi i niepotrzebną stratą czasu. Alternatywnym rozwiązaniem dla DCOM jest technologia tzw. tunelowania OPC, która całkowicie eliminuje zagroŝenia utraty danych związane z DCOM (rys.2). Przykładem rozwiązań opartych o tunelowanie mogą być OPC Tunneller firmy Matrikon lub OPC Tunel firmy Softing. W typowej konfiguracji aplikacja OPC Tunneller jest zainstalowana na wszystkich komputerach biorących udział w wymianie danych poprzez sieć (klient i serwer OPC). Jej głównym zadaniem jest konwersja wiadomości OPC, pobieranych przy uŝyciu COM z lokalnie zainstalowanej aplikacji OPC na stosowny, wydajny standard komunikacji sieciowej taki jak: TCP/IP, HTTP, HTTPS, XML itp. Następnie dane są przesyłane przez sieć, a aplikacja OPC Tunneller zainstalowana na komputerze odbiorczym dokonuje konwersji odwrotnej. Tak więc, kaŝdy OPC Tunneller ma dwa zadania: transferować dane do innego obiektu OPC Tunneller w najbardziej niezawodny i pewny sposób oraz z powrotem tłumaczyć wszystkie dane na podstawowy, standardowy format komunikatu OPC. Wybór technologii transportu danych moŝe zostać dokonany przez uŝytkownika albo przez programistę przystosowującego aplikację OPC Tunneller do indywidualnych potrzeb danego systemu komunikacyjnego. W ten sposób wyeliminowana jest potrzeba uŝycia DCOM. Nazwy uŝytkowników i hasła są
natychmiastowo uniewaŝnione, a tym samym fakt pracy poszczególnych aplikacji OPC na komputerach naleŝących do róŝnych domen czy teŝ grup roboczych (ang. Workgroup) staje się nieistotny. Wyszczególnienie numeru portu i adresu IP (lub nazwy komputera), na którym zainstalowano daną aplikację OPC jest wszystkim, co jest wymagane. OPC Tunneller oferuje następujące korzyści: uniknięcie początkowych problemów związanych ze Ŝmudną konfiguracją zabezpieczeń DCOM, umoŝliwia dzielenie danych pomiędzy aplikacjami OPC naleŝącymi do róŝnymi domen czy teŝ grup roboczych przy jednoczesnej minimalnej konfiguracji sieci, znacznie redukuje wymagania dotyczące przepustowości i niezawodności sieci, wykorzystuje tylko pojedynczy port do komunikacji. Klasyczne rozwiązanie oparte o DCOM WAN lub róźne domeny Systemu Windows OPC Tunneller CSC Rozwiązanie oparte o tzw. Tunneling OPC OPC Tunneller SSC WAN lub róźne domeny Systemu Windows KONFIGURACJA MATRIKON OPC TUNNELLER Rys. 2 Schemat połączenia za pośrednictwem OPC Tunneller W celu tzw. tunelowania transmisji pomiędzy klientem a serwerem OPC konieczna jest prawidłowa konfiguracja dwóch aplikacji: odległej bramy OPC Tunneller po stronie serwera, czyli w skrócie SSC (ang. Server Side Component) i lokalnej bramy OPC Tunneller po stronie klienta, czyli w skrócie CSC (ang. Client Side Component). Te dwie aplikacje odpowiadają za upakowanie danych OPC wewnątrz innego protokołu komunikacyjnego (np. protokołu TCP/IP), przesłanie ich przez sieć, a następnie dokonanie translacji odwrotnej. W ten sposób powstaje tytułowy tunel, który z zewnątrz wygląda jak typowy strumień danych, a jednak wewnątrz zawiera wszystkie waŝne dane produkcyjne. Format danych jest zgodny ze specyfikacją OPC VTQ (ang. Value, Time, Quality), a więc zawiera informacje na temat wartości zmiennej procesowej, czasu ostatniej zmiany wartości zmiennej oraz wiarygodności (pewności) tej informacji. Odległa aplikacja OPC Tunneller (SSC) rezyduje na odległym komputerze, na którym zainstalowano oprogramowanie serwerów OPC (rys. 3). Brama ta zarządza komunikacją z lokalnymi serwerami OPC i jest typową aplikacją uruchamianą jako usługa na zdalnej maszynie. Rys. 3 Model bramy OPC
Oprogramowanie bramy OPC Tunneller po stronie serwera otrzymuje wiadomości, bazujące na TCP/IP, wysyłane przez bramę OPC Tunneller po stronie klienta, a następnie przekształca je na Ŝądania OPC i komunikuje się z lokalnie zainstalowanym serwerem OPC. Lokalna aplikacja OPC Tunneller (CSC) jest instalowana na komputerze, na którym działa oprogramowanie klientów OPC (rys. 3). Brama ta dostarcza identyfikatory ID (stunelowanych aplikacji OPC) dla odległych serwerów i zarządza komunikacją z klientami OPC. W domyślnych ustawieniach jest ona automatycznie uruchamiana zawsze wtedy, gdy klient OPC próbuje uzyskać dostęp do stunelowanego serwera OPC. Zadaniem oprogramowania bramy OPC Tunneller po stronie klienta jest wychwytywanie i przekształcanie całej lokalnej komunikacji klienta OPC w szybkie i wydajne wiadomości bazujące na TCP/IP. Następnie brama transmituje wiadomości do aplikacji bramy OPC Tunneller po stronie serwera (rys.3). ANALIZA WYDAJNOŚCIOWA OPC W praktyce przemysłowej spotyka się aplikacje OPC pracujące zarówno w środowisku lokalnym komputera jak i pracujące w środowisku sieci komputerowej. JednakŜe jedynie w środowisku sieci komputerowej OPC przysparza szeregu problemów w czasie jego wdraŝania oraz eksploatacji. Rozwiązaniem tych problemów jest zastosowanie opisanego wcześniej tunelowania OPC. Pakowanie danych procesowych w ramki protokołu IP i transmisja ramek poprzez sieć komputerową wnosi pewne dodatkowe obciąŝenie sieci. Rys. 4 przedstawia obciąŝenie sieci lokalnej Ethernet 100Mb/s podczas transmisji danych procesowych, tzw. Items pomiędzy dwoma komputerami w oparciu o platformę DCOM oraz tunelowanie OPC. Jak wynika z wykresu dodatkowe obciąŝenie sieci dla transmisji z tunelowaniem IP jest nieznaczne i wynosi średnio 1%. ObciąŜenie sieci dla transmisji 20000 item ow w czasie jednej sekundy wnosi 12%. Obciązenie sieci IEEE 802.3 w % 14,00 12,00 Obciązenie sieci % 10,00 8,00 6,00 4,00 2,00 0,00 10 100 1000 5000 10000 20000 items/s Tuneller DCOM Rys. 4 Procentowe wykorzystanie sieci Ethernet 100Mb/s porównanie przypadków. Uczestniczące w wymianie danych procesowych aplikacje OPC wnoszą pewne obciąŝenie jednostek centralnych komputerów tzw. CPU. Rys. 5 przedstawia obciąŝenie CPU dla komputera Pentium III 400MHz transmitującego dane procesowe w środowisku lokalnym oraz poprzez sieć w oparciu o platformę DCOM oraz tunelowanie OPC. Porównując poszczególnych wykresy łatwo zauwaŝyć, Ŝe we wszystkich przypadkach, obciąŝenie procesora serwera OPC wzrastało wraz ze wzrostem liczby transmitowanych zmiennych tzw. Items. W porównaniu do testów w środowisku lokalnym, nastąpił takŝe wzrost uŝycia CPU podczas testów zdalnego połączenia DCOM i OPC Tunneller. RóŜnica ta ma związek z faktem uŝycia dodatkowych mechanizmów koniecznych do zapewnienia prawidłowej obsługi transmisji sieciowej (przypadek DCOM) oraz z dodatkowym pośrednictwem w wymianie danych OPC przez aplikacje bram OPC Tunneller. Jednocześnie naleŝy zwrócić uwagę na fakt, iŝ w symulacji obciąŝenia CPU uŝyto aŝ 20 000 item ów, co w praktyce przemysłowej ma miejsce w niewielkiej liczbie aplikacji. W realiach przemysłowych, uŝywając zawiadamiania opartego o tzw. mechanizm obsługi zdarzeń, ilość rzeczywiście transmitowanych danych w jednostce czasu stanowi zaledwie mały odsetek wszystkich monitorowanych przez system nadrzędny danych. PODSUMOWANIE
UŜycie CPU [%] 35,00 30,00 25,00 CPU [%] 20,00 15,00 10,00 5,00 0,00 10 100 1000 5000 10000 20000 Tuneller DCOM Lokalne items/s Rys. 5 Procentowe wykorzystanie procesora porównanie przypadków. Opisane zalety OPC sprawiły, Ŝe jest to obecnie jedna z najdynamiczniej rozwijających się technologii informatycznych do automatyzacji procesów przemysłowych. Nieprzerwanie trwają prace mające na celu dalsze ulepszanie i popularyzację wykorzystanych w technologii OPC rozwiązań. Ogólna dostępność zastosowanych, otwartych interfejsów komunikacyjnych sprawia, Ŝe producenci oprogramowania i sprzętu tworzą coraz doskonalsze konstrukcje, umoŝliwiające implementację rozległych i bardziej zintegrowanych systemów automatyzacji. Zastosowanie technologii OPC jest więc gwarantem tego, Ŝe realizowane obecnie instalacje równieŝ w przyszłości będą miały moŝliwości rozszerzenia i modyfikacji. Sprawia to, Ŝe kaŝdy konkurencyjny zakład produkcyjny, który chce się liczyć na rynku nie powinien obojętnie przejść obok tego rozwiązania. Do niedawna jednym z zarzutów kierowanym do twórców technologii OPC było zbyt mocne powiązanie z firmą Microsoft i jej rozwiązaniami takimi DCOM. Dlatego teŝ organizacja OPC Foundation opracowuje nowe specyfikacje oparte o standard XML i usługi Web. Rozwój technologii OPC postępuje w kierunku tzw. Zunifikowanej Architektury OPC opartej na WSDL (ang. Web Service Description Language), SOAP i XML dla wymiany danych. Od 2003 r. jest dostępna specyfikacja OPC XML DA, która uwzględnia architekturę zorientowaną na usługi. Koncepcja ta pozwala aplikacjom na komunikowanie się niezaleŝnie od dostawcy sprzętu i oprogramowania (tzw. platformy). Aktualnie standard OPC Unified Architecture jest zorientowany na usługi i wspiera takie specyfikacje jak: OPC DA, AE i HDA. JednakŜe OPC UA nie zajął miejsca pierwotnej specyfikacji OPC DA lecz ją uzupełnia. Rozwiązania oparte na OPC i DCOM będą wciąŝ rozwijane i dlatego teŝ inwestycje poczynione w modernizacje systemów sterowania/nadzorowania pozostaną bezpieczne. OPC UA rozszerza aktualną technologię OPC o znaczący aspekt funkcjonalny. W oparciu o XML oraz usługi Web, niezaleŝne od technologii COM/DCOM, OPC US pozwala na bezpieczny i pewny transport danych i wstępnie przetworzonych informacji z działu produkcyjnego do systemów planowania produkcji i ERP. Nowa specyfikacja definiuje niezaleŝną platformę i unifikuje uŝycie róŝnych serwerów i klientów takich jak DA, AE i HDA dla komunikacji poziomej i pionowej w przedsiębiorstwie. Serwery OPC UA umoŝliwiają dostęp do bieŝących i historycznych danych, jak równieŝ zdarzeń takich jak alarmy, zmiany wartości lub wyniki wywołania programów. Zdaniem specjalistów specyfikacja OPC UA jest rozwiązaniem doskonale nadającym się do zastosowań w aplikacjach biznesowych. Wynika to głównie ze względu na fakt, Ŝe jest ona duŝo wolniejsza niŝ DCOM. JeŜeli jednak wymagana jest duŝa wydajność systemu (transfer danych), to optymalnym rozwiązaniem wydaje się być przedstawione w tym artykule tunelowanie OPC. BIBLIOGRAFIA 1. Iwanitz F., Lange J., OPC - Fundamentals, Implementation and Application, Hüthig Verlag, 2002. 2. Matrikon, OPC client for ODBC User s Manual, www.matrikon.com, 2002. 3. Tindill, D. OPC considerations for network security, The Industrial Ethernet Book, Issue 38, 2007 4. Weber J., How United Architecture fits into the existing world of OPC, The Industrial Ethernet Book, Issue 38, 2007