Dr inŝ. Krzysztof Skura Instytut Technologii Maszyn i Automatyzacji Politechniki Wrocławskiej ZAGADNIENIA INTEGRACJI SYSTEMÓW INFORMATYCZNYCH W AUTOMATYZACJI PROCESÓW PRODUKCYJNYCH W OPARCIU O TECHNOLOGIĘ OPC Integracja systemów informatycznych w przedsiębiorstwie produkcyjnym jest zadaniem niełatwym ze względu na róŝnorodność stosowanych standardów sieci i protokołów komunikacyjnych oraz interfejsów komunikacyjnych oprogramowania aplikacyjnego i baz danych. W artykule tym przedstawiono aktualne rozwiązania komunikacyjne dla systemów automatyki przemysłowej oraz systemów baz danych takie jak OPC. Szczególną uwagę zwrócono na problem integracji urządzeń automatyki przemysłowej z bazami danych na potrzeby systemów SCADA oraz MES. Przedstawiono wyniki badań systemów komunikacyjnych OPC oraz interfejsów ODBC, które wskazały na słabe punkty w procesie integracji systemów informatycznych. Zbieranie oraz zarządzanie informacjami w przedsiębiorstwie produkcyjnym stanowi kluczowy element w procesie podejmowania decyzji, prowadzących do zwiększenia efektywności produkcji, poprawy jakości produktów oraz wyeliminowania zakłóceń w realizacji zleceń produkcyjnych. Systemy informatyczne wspomagają funkcjonowanie przedsiębiorstwa produkcyjnego na wszystkich jego poziomach od maszyn i linii produkcyjnych, poprzez działy inŝynieryjne aŝ do działów administracyjnych. 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. Systemy ERP Systemy MES Systemy SCADA/HMI Sterowniki przemysłowe PLC, CNC, IPC itp. Urządzenia automatyki Rys. 1. Systemy informatyczne przedsiębiorstwa produkcyjnego Na niŝszych poziomach przedsiębiorstwa produkcyjnego stosowane są od wielu lat nadrzędne systemy sterowania i akwizycji danych SCADA, przemysłowe układy sterowania CNC (ang. Computer Numerical Control), PLC (ang. Programmable Logic Controller), IPC (ang. Industrial PC), czujniki, elementy wykonawcze i inne urządzenia automatyki przemysłowej. Stanowią one swoisty system informatyczny działający w czasie rzeczywistym, którego podstawowym zadaniem jest sterowanie maszynami i liniami produkcyjnymi w celu realizacji zadań produkcyjnych. Historycznie rzecz ujmując systemy sterowania maszyn oraz linii produkcyjnych są stosowane w zakładach produkcyjnych od kilku dekad, podczas gdy systemy ERP powstały w ciągu ostatnich dziesięciu lat. Ta róŝnica doprowadziła do powstania luki technologicznej pomiędzy tymi systemami, która dodatkowo została powiększona poprzez odmienne wymagania końcowych uŝytkowników tych systemów inŝynierów procesu produkcyjnego oraz managerów zarządzających przedsiębiorstwem. Powstałą w ten sposób lukę technologiczną wypełniają obecnie systemy MES. Rys. 1 przedstawia względną pozycję systemów MES w hierarchii systemów informatycznych w typowym przedsiębiorstwie produkcyjnym. Podstawowym zadaniem systemu MES jest efektywne i skuteczne prowadzenie procesu produkcyjnego na podstawie precyzyjnych i aktualnych danych produkcyjnych pochodzących z układów sterowania i systemów akwizycji danych. Systemom MES przypisuje się funkcje takie jak: zbieranie i archiwizacja danych produkcyjnych, monitorowanie i kontrolowanie przebiegu procesu wytwórczego,
harmonogramowanie zadań produkcyjnych, zarządzanie zasobami (maszyny, pracownicy) oraz ich alokacja, zarządzanie przeglądami i remontami maszyn i linii produkcyjnych, analiza efektywności produkcji i generowanie raportów, zarządzanie jakością i wiele innych. Niezbędnym elementem nowoczesnego systemu MES jest moŝliwość łatwej integracji z systemami automatyki przemysłowej (sterowniki, SCADA) oraz z bazami danych, które przechowują istotne dla procesu podejmowania decyzji dane produkcyjne. Systemy MES łączą sterowanie wydziału produkcyjnego, działy utrzymania ruchu, działy jakości i inne źródła danych w jednolity system informatyczny, uŝywając standardowych komponentów oprogramowania takich jak: OPC Client, i ActiveX. Te nowoczesne technologie informatyczne w znaczny sposób redukują całkowity koszt integracji MES z systemami automatyki i bazami danych oraz zabezpieczają inwestycje IT na przyszłość. JednakŜe projektowanie systemu komunikacyjnego nie jest zadaniem łatwym i wymaga uwzględnienia wielu parametrów technicznych sieci i protokołów komunikacyjnych, interfejsów łączących systemy informatyczne, a takŝe uwzględnienia wymagań czasowych, bezpieczeństwa transmisji danych i ograniczeń wynikających z przepustowości sieci i wymagań technicznych klienta. TECHNIKA KOMUNIKACJI OPC W AUTOMATYZACJI PROCESÓW PRZEMYSŁOWYCH 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 OPC Client Web HMI OPC Client ERP, MES, Data Base Client for ODBC LAN PLC IPC/SlotPLC I/O Rys. 2. Ś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 INTEGRACJA BAZ DANYCH Z SERWERAMI OPC POPRZEZ OTWARTY INTERFEJS KOMUNIKACYJNY ODBC PLC Baza danych OPC Client for ODBC OPC ODBC OPC IPC/SlotPLC MS SQL MS Access Oracle MySQL DCS Rys. 3. Połączenie bazy danych z OPC poprzez interfejs ODBC Integracja systemów sterowania linii produkcyjnych z systemami planowania produkcji oraz systemami zarządzania przedsiębiorstwem stanowi istotny element w procesie skracania cyklu produkcyjnego oraz poprawy efektywności i jakości produkcji. Systemy baz danych oraz technika komunikacji oparta na OPC to dwa podstawowe rozwiązania informatyczne ułatwiające integrację przepływu danych produkcyjnych. Nowoczesne systemy MES korzystają z obu wymienionych tu rozwiązań, czego doskonałym przykładem moŝe być oprogramowanie InTrack oraz IndustrialSQL Server firmy Wonderware. Jak juŝ wcześniej wspomniano podstawowym zadaniem serwera danych OPC (tzw. OPC Data Access Server) jest wymiana danych pomiędzy urządzeniem automatyki przemysłowej takim jak PLC, IPC a aplikacją klienta OPC np. systemem SCADA. JednakŜe często powstaje takŝe konieczność wymiany danych procesu produkcyjnego z bazą danych dla systemów klasy MES lub ERP. Jednym z rozwiązań tego problemu jest zastosowanie standardowego interfejsu ODBC (ang. Open Data Base Connectivity) komunikującego się z bazą danych z jednej strony oraz z serwerem OPC z drugiej strony. Przykładem takiego rozwiązania jest program OPC Client for ODBC firmy Matrikon lub OPC Client for SQL Server firmy Integration Objects. Podstawowym zadaniem programu OPC Client for ODBC jest umoŝliwienie przesyłania danych z procesu produkcyjnego pomiędzy serwerami OPC a bazami danych kompatybilnych z interfejsem ODBC. Interfejs ten uŝywa standardowych zapytań języka SQL (ang. Structured Query Language). Istnieją dwa podstawowe zastosowania interfejsu OPC Client for ODBC: archiwizacja danych procesowych z serwerów OPC do bazy danych poprzez ODBC. Baza danych staje się w takiej aplikacji tzw. bazą danych historycznych (ang. Process Historian) i aplikacja moŝe składować dane w tabelach baz danych. Następnie mogą być uŝyte narzędzia do analizy i odczytywania danych, rozsyłanie danych pochodzących z baz danych do serwerów OPC w celu sparametryzowania układu sterowania.
Interfejs OPC Client for ODBC wspiera następujące bazy danych kompatybilne z ODBC: Microsoft Access, Microsoft SQL, Oracle, Sybase, MySQL etc. Interfejs ten umoŝliwia takŝe: komunikację pomiędzy wieloma baza danych ODBC i wieloma serwerami OPC włączając w to sesje równoległe z tym samym serwerem, definiowanie i zadawanie zapytań SQL, pozwalając na odczytywanie wartości z tabel oraz zapisywanie do tabel, edytowanie zapytań SQL w czasie pracy aplikacji, prostą konfigurację i parametryzację interfejsu ODBC, dokonywanie uaktualnień tabel poprzez transakcje, pracę jako usługa Windows NT, zapisywanie konfiguracji systemu w formacie XML. BADANIE OBCIĄśENIA JEDNOSTKI CENTRALNEJ CPU W KOMUNIKACJI POMIĘDZY SERWEREM OPC A BAZĄ DANYCH MS SQL SERVER ORAZ MYSQL 70% UŜy cie procesora CPU dla komunikacji OPC - MS SQL Serv er [%] UŜycie procesora CPU [%] 60% 50% 40% 30% 20% 10% 0% 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500 Liczba transmitow any ch zmienny ch ty pu INT4 UŜy cie CPU dla MS SQL Serv er, update time - 1s UŜy cie CPU dla MS SQL Serv er, update time - 2s Rys. 4. ObciąŜenie procesora CPU dla komunikacji OPC - MS SQL Server Rysunek 3 przedstawia model komunikacyjny pomiędzy serwerem OPC a bazą danych. W modelu tym przyjęto, Ŝe wymiana danych procesowych będzie się odbywała poprzez interfejs ODBC. Aplikację serwera OPC zainstalowano na komputerze klasy PC z systemem operacyjnym Windows XP, procesorem AMD 1,8 GHz i pamięcią operacyjną RAM 512MB. Jako serwer danych zastosowano ver. 1.2.4 firmy Matrikon. Aplikację OPC Client for ODBC uruchomiono na drugim komputerze PC (INTEL 2,4GHz, RAM 512MB) połączonym z serwerem OPC siecią Ethernet 100Mb/s. Skonfigurowano platformę komunikacyjną DCOM z protokołem komunikacyjnym TCP/IP. W modelu tym załoŝono, Ŝe komunikacja w środowisku rozproszonym pomiędzy komputerami odbywać się będzie w oparciu o model obiektów rozproszonych DCOM (ang. Distributed Common Object Model). W praktyce jest moŝliwe uruchomienie OPC Client for ODBC na komputerze serwera OPC. Komunikacja z bazą danych w środowisku rozproszonym odbywa się w takim przypadku bezpośrednio poprzez protokół TCP/IP. Jak wykazały doświadczenia przedstawione w pracy [6], platforma komunikacyjna DCOM obciąŝa sieć Ethernet 100 Mb/s w nieznaczny sposób. Natomiast, jak to zostanie wykazane w tym artykule, czas procesora (obciąŝenie procesora) wymagany na obsługę komunikacji pomiędzy OPC i bazą danych jest elementem kluczowym podczas projektowania systemów komunikacyjnych. W badaniach przyjęto następujące załoŝenia: komunikacja pomiędzy komputerami odbywać się będzie poprzez sieć Ethernet 100Mb/s, protokół TCP/IP został wybrany jako podstawa komunikacji dla obiektów DCOM, aplikacja interfejsu ODBC będzie zainstalowana na komputerze z bazą danych, czas uaktualnia danych (tzw. Update Rate) w tabelach baz danych przyjęto 1s oraz 2s. załoŝono transmisję danych OPC typu INT4.
W badaniach tych uwzględniono komunikację poprzez interfejs ODBC dla bazy danych firmy Microsoft MS SQL Server oraz dla bazy danych MySQL. Wyniki badań obciąŝenia procesora CPU dla komunikacji pomiędzy OPC a bazą danych MS SQL serwer przedstawiono na rys.4. W badania celowo przyjęto krótki czas uaktualniania danych, tzw. Update Rate (1s, 2s) w bazie danych aby wskazać na graniczne parametry pracy komputerów z zainstalowaną bazą danych. 90% UŜycie procesora CPU dla komunikacji OPC - MySQL Server [% ] UŜycie procesora CPU [%] 80% 70% 60% 50% 40% 30% 20% 10% 0% 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500 Liczba transmitowanych zmiennych typu INT4 UŜycie CPU dla MySQL Server, update time - 1s UŜycie CPU dla MySQL Server, update time - 2s Rys. 5. ObciąŜenie procesora CPU dla komunikacji OPC - MySQL Server Jak łatwo zauwaŝyć na rys. 4, przy załoŝonym czasie uaktualnia danych na poziomie 1s, (uŝycie) czas procesora wymagany na przesyłanie danych przekracza poziom 50% przy transmisji 900 zmiennych dla bazy MS SQL. W przypadku bazy MySQL czas procesora przekracza 50% przy transmisji 500 zmiennych (500 zmiennych/s) (rys.9). Wynika z tego wniosek, Ŝe zastosowany interfejs ODBC (MyODBC 3.51) dla bazy MySQL jest mniej efektywny od interfejsu ODBC dla MS SQL. Przy załoŝonym czasie Update Rate na poziomie 2s znacząco spada czas (uŝycie) procesora wymagany na wykonanie zadania komunikacyjnego i uaktualnienie tabeli danych w bazie danych. W praktyce w aplikacjach wymagających transmisji duŝej liczby danych procesowych (np. powyŝej 1000) do baz danych poprzez ODBC naleŝy unikać krótkich czasów uaktualniania tzw. Update Rate (na poziomie 1s). Czas ten powinien wynosić minimum kilka sekund. 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.6). 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. KONFIGURACJA MATRIKON OPC TUNNELLER Rys. 6 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. 7). Brama ta zarządza komunikacją z lokalnymi serwerami OPC i jest typową aplikacją uruchamianą jako usługa na zdalnej maszynie. Rys. 7 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. 7). 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.7). 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 ANALIZA WYDAJNOŚCIOWA OPC Rys. 8 Procentowe wykorzystanie sieci Ethernet 100Mb/s porównanie przypadków. 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. 8 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%. Uczestniczące w wymianie danych procesowych aplikacje OPC wnoszą pewne obciąŝenie jednostek centralnych komputerów tzw. CPU. Rys. 9 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ólne 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. 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. 9 Procentowe wykorzystanie procesora porównanie przypadków. PODSUMOWANIE Punktem wyjścia w procesie projektowania systemów komunikacyjnych do automatyzacji produkcji są zastosowane systemy informatyczne, aplikacje, interfejsy, systemy sterowania, sieci komputerowe, bazy danych oraz wymagania funkcjonalne końcowych uŝytkowników. Ze szczególną starannością powinny być przeanalizowane wymagania dotyczące ilości oraz czasu przesyłania danych pomiędzy aplikacjami. Jak wykazały wyniki badań przedstawionych w tym artykule przemysłowe systemy komunikacyjne takie jak OPC doskonale spełniają swoje zadanie w obszarze produkcyjnym, gdzie wymaga się transmisji duŝej liczby danych w krótkim czasie np. 1s. JednakŜe te wysokie wymagania czasowe nie mogą być spełnione w aplikacjach informatycznych takich jak MES czy ERP przy zastosowaniu uniwersalnych i standardowych rozwiązań, takich jak interfejs do bazy danych OPC/ODBC. Zastosowanie specjalizowanych rozwiązań informatycznych tzw. niestandardowych niesie ze sobą z kolei duŝe koszty wdroŝenia i utrzymania. Dlatego teŝ w procesie projektowania systemów komunikacyjnych integrujących świat automatyki ze światem systemów zarządzania i sterowania produkcją szczególną uwagę naleŝy zwrócić na rzeczywiste wymagania tych systemów w odniesieniu do czasu i ilości przesyłanych danych 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 UA 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 5. Frase J., Boost Business Results and Gain Quick ROI with Manufacturing Execution Systems, Industry Directions www.industrydirections.com. 2004. 6. Skura K., Analiza i badania wybranych rozwiązań systemów komunikacyjnych do automatyzacji procesów przemysłowych, Praca doktorska, Politechnika Wrocławska, 2002.