Szybkość, blokowanie w czasie rzeczywistym oraz nienaruszalna łączność to podstawowe wymagania, jakie trzeba spełnić przy wdrażaniu systemu sterowania ruchem. Najczęściej stosowane interfejsy skupione są wokół architektur sieci sterowania opartych na takich protokołach, jak Profibus, DeviceNet, SERCOS, Profinet, EtherCAT, Ethernet I/P i wiele innych. Korzystną pozycję w tym środowisku sieciowym zarówno obecnie, jak i w przyszłości ma standard OPC.
Sterowanie ruchem to podstawowa technologia na liniach pakowania. Bazując na zaletach standardu OPC w dziedzinie komunikacji, producenci OEM i użytkownicy mogą łączyć systemy sterowania ruchem z innymi zaawansowanymi systemami automatyki, takimi jak systemy monitorowania wydajności i zarządzania aktywami
Historia OPC
Przedstawioną w 1996 r. technologię OPC opracowała grupa firm – założycieli organizacji OPC Foundation. Ich celem było opracowanie wspólnej specyfikacji zapewniającej interoperacyjność (współoperatywność, zdolność do współdziałania) aplikacji programowych. W specyfikacjach OPC określono sposób przekazywania danych między aplikacjami w architekturze klient/serwer.
Pierwszą generację OPC opracowano w postaci trzech odrębnych specyfikacji: OPC DA – dostęp do danych czasu rzeczywistego, OPC A&E – dostęp do komunikatów o alarmach i zdarzeniach, OPC HDA – dostęp do danych historycznych. Deweloperzy rozwiązań programowalnych mogli więc wybierać spośród tych specyfikacji i wdrażać najbardziej odpowiednie funkcje OPC. Ponieważ automatyka przemysłowa w głównej mierze bazuje na dostępie do danych w czasie rzeczywistym, w projektach najczęściej wykorzystywano specyfikację OPC DA.
Zautomatyzowany ruchomy uchwyt umieszcza część nadwozia w pozycji umożliwiającej pracę robota spawalniczego
Poznanie podstaw standardu OPC pozwoli nam lepiej zrozumieć zakres jego stosowania oraz kierunek rozwoju. Już sam termin OPC zmienił z biegiem lat swoje znaczenie. Początkowo był to akronim wyrażenia OLE for Process Control (OLE w sterowaniu procesami), jednak po uaktualnieniu termin OPC oznacza OPen Connectivity – otwartą komunikację w ramach otwartych standardów. Zmiana w nazwie odzwierciedla niedawne wprowadzenie nowego zestawu specyfikacji OPC określanego mianem OPC UA.
Termin OLE – Object Linking and Embedding – to wprowadzony przez firmę Microsoft mechanizm łączenia i osadzania obiektów. Obiekty te są definiowane w ramach innej technologii Microsoftu o nazwie COM – Component Object Model (obiektowy model komponentów oprogramowania). Technologie te są stosowane w systemach operacyjnych Microsoftu w celu umożliwienia komunikacji między aplikacjami. Dzięki nim aplikacje mogą także wykorzystywać wspólne komponenty.
Technologie OLE oraz COM stanowią podstawowe „przewody”, którymi przepływają dane, co zapewnia interoperacyjność różnych aplikacji. Przystosowanie tych technologii do użytku w automatyce wymagało jedynie zdefiniowania obsługi różnych rodzajów danych oraz metod dostępu do danych. Metody dostępu do danych w technologii OPC zapewniają takie funkcje, jak odpytywanie w oczekiwaniu na dane, subskrypcja zmian danych, synchroniczny i asynchroniczny odczyt i zapis oraz zdolność odczytu z pamięci podręcznej lub wymóg odczytu ze źródła. Zakres tych funkcji wydaje się dość szeroki – i tak jest w istocie. Funkcje te spełniają wszystkie wymogi zarówno uniwersalnej komunikacji, jak i wysokowydajnej komunikacji w czasie rzeczywistym do porozumiewania się aplikacji w obrębie komputera PC.
Komunikacja między kilkoma komputerami PC wymaga rozszerzenia technologii COM o nazwie DCOM (Distributed COM – rozproszony obiektowy model komponentów). W idealnych warunkach mechanizm DCOM zapewnia doskonałą łączność między rozproszonymi składnikami sieci. Niestety DCOM opracowano z myślą o systemach biznesowych, a nie o współdziałaniu rozproszonych urządzeń w czasie rzeczywistym.
Przy zastosowaniu architektury OPC możliwe jest przesyłanie informacji z przyłączonych do sieci ruchomych uchwytów, robotów i innych urządzeń do transportu bliskiego. Przekazywane informacje obejmują m.in. dane o przezbrojeniu i pozycji uchwytów, co pozwala na montaż wielu modeli samochodów na tej samej linii
Z tego względu takie zjawiska, jak symptomy uszkodzenia czy opóźnione wykrywanie i naprawianie przerw w sieci, wykluczają zastosowanie technologii DCOM jako „przewodu” łączącego komputery w czasie rzeczywistym w układzie nieidealnym. Na szczęście istnieją inne, dostosowane do potrzeb automatyki opcje skomunikowania komputerów PC (patrz: tunelowanie). Na tym etapie znajomości architektury OPC możemy przyjrzeć się możliwości jej zastosowania w odniesieniu do systemów sterowania ruchem.
Zastosowanie OPC w systemach sterowania ruchem
Systemy sterowania ruchem zwykle wymagają ścisłego sprzężenia elementów napędu i kontrolera. Dla zapewnienia interoperacyjności urządzeń na poziomie sterowania prawie zawsze stosuje się sieci sterowania konkretnego dostawcy. Jednakże obecnie coraz częściej wymaga się, aby sterowane urządzenia funkcjonowały z maksymalną niezawodnością i optymalną wydajnością, gwarantując możliwie najwyższą jakość produkcji.
Od dostawców systemów sterowania ruchem coraz częściej oczekuje się, że systemy te będą zintegrowane z systemami nadzoru, wyposażonymi w funkcje analizy wydajności maszyn. Systemy nadzorcze powinny dostarczać informacje o całkowitej efektywności maszyn i urządzeń (OEE) oraz dane służące do zarządzania tymi aktywami, umożliwiające użytkownikom np. prowadzenie planowej konserwacji i obliczanie całkowitego kosztu posiadania. Rozwiązania te zwykle dostarczane są przez inne firmy, specjalizujące się w tym zakresie działalności.
Obecnie klienci coraz częściej wymagają, aby systemy sterowania ruchem współdziałały z aplikacjami innych producentów. Taka integracja wymaga instalacji sterownika komunikacyjnego obsługującego z jednej strony protokół stosowany w danym systemie sterowania ruchem, a z drugiej – standardowy interfejs OPC do komunikacji z aplikacjami zewnętrznych dostawców. Wprawdzie dostępne są sterowniki dla protokołów systemów sterowania ruchem, jednak częściej za komunikację odpowiada kontroler ruchu – zwykle sterownik PLC lub CNC – przy użyciu protokołu komunikacyjnego wyższego poziomu.
Tego rodzaju kontrolery często dostarczają więcej informacji, niż można uzyskać z sieci sterowania: zsumowane dane z kilku źródeł danych, zsumowane liczniki, czasy cykli, prędkości robocze itp.
Z uzyskiwanych w ten sposób zmiennych można zrobić znacznie większy użytek przy użyciu analitycznych funkcji systemów nadzoru. Z tego względu zastosowanie standardu OPC jako interfejsu dla systemów nadzoru stało się normą w automatyce przemysłowej. Większość dostawców prowadzi partnerską współpracę z określoną firmą z branży komunikacyjnej, dzięki czemu nie muszą oni sami oferować obsługi różnych protokołów, ani też trudzić się złożonymi problemami komunikacji. OPC stanowi wspólną warstwę, w ramach której systemy nadzoru mogą komunikować się z niemal każdą maszyną w zakładzie produkcyjnym, a w szczególności z układami sterowania ruchem.
OPC – cała naprzód!
W dziedzinie OPC nastąpił niedawno znaczący postęp. W 2009 r. organizacja OPC Foundation opublikowała nowy zestaw specyfikacji o nazwie OPC UA (OPC Unified Architecture). Nowa specyfikacja stanowi ujednolicenie dawniejszych specyfikacji w ramach jednej uniwersalnej specyfikacji. OPC UA ma zapewnić jeszcze wyższy stopień współdziałania urządzeń i aplikacji.
Specyfikację OPC UA opracowano na bazie technologii zwanej architekturą ukierunkowaną na usługi – Service Oriented Architecture (SOA). Dla automatyków imperatywem jest wysoka niezawodność i jakość działania – każdy interfejs musi działać maksymalnie niezawodnie. Istotną kwestią jest również bezpieczeństwo: interfejs musi zarówno umożliwiać bezpieczny dostęp, jak i być odporny na złośliwe ataki, które mogłyby wykluczyć przydatność zastosowanego systemu automatyki.
Implementacja standardu OPC UA funkcjonuje jako usługa internetowa. Dzięki temu zachowuje się jak każda inna usługa internetowa, m.in. współpracuje z zaporami i może być zarządzana przez administratorów systemu. Umożliwia to proste i przewidywalne zdefiniowanie portów dostępu do usług oraz do zarządzania ruchem w sieci. Jest to też główne usprawnienie w stosunku do architektury OPC bazującej na starszych specyfikacjach COM i DCOM, które w przypadku pracy w środowisku rozproszonym wymagały wielu zmian w konfiguracji zabezpieczeń systemu Windows. Ponadto specyfikacja DCOM nie zapewniała dostatecznej kontroli nad komunikacją między komputerami PC w obszarze portów, co utrudniało inżynierom i informatykom organizowanie komunikacji na zaporach.
Dzięki tym zmianom standard OPC UA oferuje jeszcze większe korzyści w środowisku rozproszonych aplikacji, jeśli serwer komunikacyjny zlokalizowano na jednym komputerze PC oraz zastosowano zdalny system nadzoru, który może być dostępny nawet jako usługa hostingowa. O ile architektura OPC pierwszej generacji bazowała na standardach Microsoftu, architekturę OPC UA celowo opracowano z myślą o potrzebach automatyki przemysłowej i wykorzystaniu powszechniej stosowanych technologii. Efektem tego podejścia jest wysoki poziom pod względem łatwości obsługi, jakości działania i bezpieczeństwa. Produkty oparte na specyfikacji OPC UA są już dziś dostępne na rynku i należy się spodziewać, że w ciągu 2009 r. jej popularność wzrośnie.
Więcej informacji o standardach OPC i OPC UA można uzyskać na stronie www.opcfoundation.org
Artykuł pod redakcją Michała Andrzejczaka
Autor: Roy Kok
