OPC UA - standard komunikacji Przemysłu 4.0

Jak widać – pierwszym krokiem przed przystąpieniem do jakichkolwiek działań jest pozyskanie danych, na bazie których stworzone zostaną procedury optymalizacji. Poważnym pretendentem do roli uniwersalnego standardu wymiany danych w zakładach przemysłowych jest OPC UA, opracowywany i usprawniany od ponad 10 lat przez OPC Foundation tak, by realizować wymagania IIoT, M2M i Industry 4.0. Standard ten może zostać zaimplementowany na różnych systemach operacyjnych, dowolnej platformie sprzętowej i przy użyciu wielu języków programowania, również w aplikacjach wykorzystujących cloud computing.

Integracja danych

Integracja danych z urządzeń zainstalowanych na maszynach, a obsługiwanych przez lokalne układy sterowania, z systemami nadrzędnymi i dalej z systemami MES i ERP, powinna być wykonywana w sposób w pełni zautomatyzowany i niewidoczny dla użytkownika. Koszt wdrożenia systemu obsługującego wymianę danych nie może przekraczać oczekiwanych korzyści, więc ważne jest zastosowanie rozwiązań wymagających jak najmniejszych nakładów na sprzęt, oprogramowanie oraz czas potrzebny na konfigurację.

Istnieje duże prawdopodobieństwo, że poprawa efektywności w zakładzie przemysłowym będzie przeprowadzana metodą prób i błędów, ponieważ trudno określić, które działania będą miały pozytywny wpływ na wyniki finansowe. Wymagana jest więc elastyczność w przetwarzaniu i interpretacji rejestrowanych danych, możliwość wyznaczania nowych wskaźników efektywności i adaptacji do zmieniającej się sytuacji w zakładzie i rosnącej wiedzy na temat przyczyn nieoptymalnej pracy. Opracowanie uniwersalnego modelu komunikacji wydaje się rozwiązaniem optymalnym z punktu widzenia kosztów wdrażania systemów służących poprawie efektywności zakładu. Integracja danych często jest niełatwym zadaniem ze względu na obecność na rynku znacznej liczby dostawców systemów automatyki, stosujących różne standardy komunikacji.

Jeśli w zakładzie przemysłowym zachowywana jest standaryzacja w zakresie na przykład sterowników PLC, układów I/O i napędów dostarczanych przez jednego producenta, komunikacja pomiędzy tymi urządzeniami zwykle jest ułatwiona dzięki możliwości zastosowania standardowego dla urządzeń danego producenta protokołu komunikacji. Łatwiej też wypracować dobre praktyki w zakresie adresacji urządzeń i nazewnictwa zmiennych. W praktyce nie jest możliwe zastosowanie jednego protokołu komunikacji, ponieważ pewna liczba urządzeń nie będzie obsługiwać standardowego protokołu preferowanego w zakładzie. Mogą to być na przykład liczniki energii lub inne urządzenia pomiarowe. W zakładzie przemysłowym, w którym dane ze wszystkich urządzeń miałyby być dostępne w systemach MES lub ERP, zawsze będzie występować konieczność konwersji przynajmniej części danych na inny protokół komunikacji. Docelowym rozwiązaniem jest możliwość przekazywania danych z czujników, napędów, itp. bezpośrednio do systemów, które będą wykorzystywać zebrane dane za pośrednictwem jak najmniejszej liczby urządzeń pośrednich, które są kosztowne i wymagają konfiguracji. Dotyczy to również wymiany danych pomiędzy maszynami (na przykład wchodzącymi w skład jednej linii produkcyjnej). W idealnej sytuacji dane powinny być dostępne dla wszystkich uprawnionych do ich przetwarzania odbiorców, zarówno na poziomie zakładu przemysłowego (wymiana danych między maszynami), jak i na poziomie zarządzania produkcją (przesyłanie danych np. do systemu MES).

 

Rys. 1. Czujnik/Element wykonawczy

Można wyobrazić sobie model, w którym konfiguracja komunikacji i przypisywanie zmiennych będzie ograniczać się tylko do wybrania konkretnej nazwy z rozwijanej listy, zamiast żmudnego przepisywania adresów rejestrów, przypisywania nazw zmiennych i pilnowania kolejności adresowania przy konwersji pomiędzy kolejnymi protokołami. Krokiem w tę stronę jest zastosowanie w OPC UA modelu obiektu, wprowadzenie klas i metod. Dzięki architekturze zorientowanej na usługi wykorzystywane są tylko te funkcje, które są aktualnie potrzebne.

Celem jest sytuacja, w której sukcesem nie jest poprawna konfiguracja, integracja i uruchomienie systemu, ale realizacja postawionych mu zadań w jak najkrótszym czasie, przy jak najniższych nakładach finansowych i z możliwie najlepszym skutkiem. Przesunięcie w tło i minimalizacja zadań związanych z projektowaniem, realizacją i uruchomieniem systemu na rzecz zwiększonej pracy nad osiągnięciem wymaganego rezultatu jest jednym z podstawowych problemów dostawców rozwiązań Przemysłu 4.0.

Architektura PubSub

Jednym z podstawowych założeń IIoT jest wymiana danych pomiędzy wieloma inteligentnymi urządzeniami z zastrzeżeniem, że nie muszą to być urządzenia mające dużą moc obliczeniową, na przykład inteligentne czujniki. Konsekwencją ograniczonej mocy obliczeniowej jest konieczność minimalizacji zużycia pamięci i mocy procesora. W 2018 roku OPC Foundation opublikowała specyfikację modelu wymiany danych Publish-Subscribe (PubSub), w której w odróżnieniu od architektury klient/serwer nie jest wymagane utrzymywanie stałego połączenia, co pozwala na zmniejszenie zużycia pamięci. W architekturze PubSub wiadomości są rozgłaszane do całej sieci, a urządzenia lub programy, które mają je wykorzystać, subskrybują się na dany typ wiadomości. To dobre rozwiązanie w sytuacji, w której jedna aplikacja gromadzi dane z wielu publikujących je urządzeń. Obsługiwane są protokoły MQTT, AMQP lub UDP. Zachowana jest kompatybilność z modelem klient/serwer.

Standard TSN

Niedoskonałości klasycznego Ethernetu w zakresie niezawodności i determinizmu doprowadziły do powstania pewnej liczby standardów Ethernetu przemysłowego. Niestety technologie te, opracowywane przez niezależnych od siebie dostawców systemów automatyki, nie są ze sobą kompatybilne. Współczesne przemiany w podejściu do rejestracji i obsługi danych z maszyn zmuszają do integracji systemów różnych producentów. Konwersja danych jest związana z opóźnieniami w transmisji, obniżoną niezawodnością i jest kosztowna ze względu na konieczność stosowania dodatkowego sprzętu i oprogramowania oraz poświęcenia czasu potrzebnego na konfigurację komunikacji.

Rozwiązaniem może stać się TSN (Time-Sensitive Networking) – opracowywany przez IEEE nowy uniwersalny standard przemysłowego Ethernetu o dużej niezawodności, nastawiony na determinizm i dostarczanie komunikatów w określonym z góry czasie z niewielkim opóźnieniem i bez strat. Jest to istotne w zastosowaniach przemysłowych, gdzie synchronizacja w czasie danych pochodzących z różnych urządzeń może mieć kluczowe znaczenie dla prowadzonego procesu. Zastosowanie TSN do transmisji danych za pomocą OPC UA ma stanowić sposób na umożliwienie komunikacji w systemach IIoT pomiędzy urządzeniami różnych producentów, niezależnie od platformy sprzętowej i stosowanego oprogramowania. Użycie modelu PubSub umożliwi tworzenie systemów działających w czasie rzeczywistym. Standard TSN ma zachowywać kompatybilność ze standardowym Ethernetem, dzięki czemu możliwe będzie wykorzystanie istniejących sieci.

Integracja z systemami Industry 4.0

Posiadanie danych i możliwość przesyłania ich w bezpieczny sposób to jednak dopiero początek. Do pełnego wykorzystania gromadzonych informacji potrzebne są narzędzia do ich przetwarzania i prezentacji w formie umożliwiającej wykorzystanie zdobytej wiedzy. Mogą być to na przykład systemy informatyczne klasy ERP lub MES oraz przemysłowe systemy diagnostyczne lub eksploatacyjne.

Standard OPC UA jest wspierany przez Microsoft, chociaż nie jest już, tak jak poprzednia wersja, ściśle związany z systemem operacyjnym Windows. Komunikacja za pośrednictwem OPC UA jest podstawowym sposobem połączenia urządzeń automatyki przemysłowej z usługami Microsoftu stworzonymi do cyfryzacji zakładów przemysłowych przy użyciu platformy Azure. Dzięki Azure IoT Connected Factory możliwe jest połączenie urządzeń znajdujących się w zakładzie z usługami Microsoft Azure. Jest to zestaw rozwiązań pozwalający na połączenie z chmurą, dzięki współpracy Microsoftu z kilkoma renomowanymi dostawcami gatewayów IoT. Dostępne są narzędzia pozwalające na szybkie przeprowadzenie symulacji w celu identyfikacji potencjalnych korzyści, następnie połączenie danych z urządzeń z chmurą i finalnie wizualizację gromadzonych danych.

 

Rys. 2

Standard OPC UA jest również wykorzystywany przez SAP jako sposób na implementację rozwiązań IIoT i M2M w oprogramowaniu tej firmy. Zestaw narzędzi SAP Plant Connectivity umożliwia przesyłanie danych pomiędzy maszynami mającymi odrębne systemy sterowania oraz na połączenie z narzędziami zawartymi w pakiecie SAP Manufacturing. W zależności od potrzeb jednostki podłączone do Plant Connectivity mogą być serwerami lub klientami OPC UA, ewentualnie pełnić obie funkcje jednocześnie, jeśli jest to wymagane. Dzięki temu możliwa jest wymiana tagów, zdarzeń i wywoływanie metod, a w praktyce przesyłanie zleceń produkcyjnych, danych do receptur, wartości zadanych z systemu MES do maszyn, a także wymiana danych pomiędzy maszynami i urządzeniami, na przykład pomiędzy systemem wizyjnym a robotem.

OPC UA jest wykorzystywane przez czołowych dostawców oprogramowania przemysłowego korzystającego z IIoT. Zastosowanie standardu, którego twórcom przyświecała idea jak najszerszego upowszechnienia, może być też sposobem na przyspieszenie i zmniejszenie kosztów wdrożenia dla mniejszych firm opracowujących swoje rozwiązania Industry 4.0. Czas i koszty mogą być w wielu przypadkach poważną barierą.

 

Rys. 3

Zastosowanie poza PLC

Implementacja serwera OPC UA wydaje się najbardziej naturalna na sterownikach PLC i wyspach I/O jako jedna z opcji komunikacji, ponieważ są to elementy pośredniczące pomiędzy sprzętem zainstalowanym na maszynach – takim jak urządzenia pomiarowe, zabezpieczające i sygnalizacyjne, a systemami nadrzędnymi, wykorzystującymi informacje pochodzące z maszyny. Sterowniki mają do dyspozycji pewną moc obliczeniową i zwykle są wyposażone w przynajmniej jeden interfejs komunikacyjny, a obsługa protokołów przemysłowych jest jedną z ich podstawowych funkcji. W tradycyjnej architekturze do sterownika podłączone są wszystkie sygnały wejściowe i wyjściowe obsługiwane w systemie sterowania zarówno bezpośrednio, jak też za pomocą protokołów komunikacji z oddalonych modułów I/O lub innych urządzeń. Wymagana jest odpowiednia infrastruktura łącząca wszystkie elementy składowe systemu. Ponadto każdy sygnał wejściowy czy wyjściowy musi być obsłużony przez sterownik, co związane jest z czasem potrzebnym na napisanie programu, a każda zmiana pociąga za sobą konieczność wgrania do PLC przynajmniej części kodu. To ostatnie wiąże się z ryzykiem popełnienia błędu i, w skrajnym przypadku, spowodowaniem zatrzymania procesu lub wywołaniem awarii.

Sterownik PLC nie jest potrzebny w każdej aplikacji, a nawet jeśli jego zastosowanie jest wymagane, to niekoniecznie musi on obsługiwać wszystkie dostępne w systemie sygnały. Z tego względu optymalnym rozwiązaniem z punktu widzenia IIoT jest maksymalne skrócenie pionowej drabiny kolejnych urządzeń pośredniczących pomiędzy maszyną a systemem informatycznym wykorzystującym dane. OPC UA jest standardem umożliwiającym osiągnięcie tego celu. Niezależnie od tego, czy urządzenia są spięte fizycznie w jedną sieć, czy też komunikują się ze sobą za pośrednictwem bramek sieciowych i chmury, zastosowanie OPC UA pozwala na to, że każdy odbiorca danych może dowolnie z nich korzystać bez konieczności konfiguracji dodatkowych konwerterów.

Bezpieczeństwo

Integracja urządzeń przemysłowych z systemami znajdującymi się fizycznie poza terenem hali produkcyjnej lub w ogólności poza zakładem rodzi obawy o bezpieczeństwo danych, zwłaszcza w przypadku systemów wykorzystujących cloud computing. Bezpieczeństwo danych to kwestia często poruszana w kontekście Przemysłu 4.0. Specjaliści od cyberbezpieczeństwa są szczególnie wrażliwi na wszelkie ingerencje w sieci zakładowe i wpuszczanie do nich ruchu z zewnątrz za pośrednictwem chmury. Wyzwaniem stojącym przed twórcami standardów komunikacji jest zabezpieczenie sieci zakładowych przed potencjalnymi cyberatakami i stworzenie u użytkowników poczucia bezpieczeństwa wrażliwych danych.

OPC Foundation postawiła sobie za cel sprostanie tym wymogom i stworzenie rozwiązania zapewniającego bezpieczeństwo danych poprzez uwierzytelnianie dostępu i szyfrowanie komunikatów. W warstwie transportowej zapewniana jest spójność i autentyczność przez wykorzystanie cyfrowych podpisów. W tej samej warstwie dzięki szyfrowaniu osiągana jest poufność. W warstwie aplikacji stosowane jest uwierzytelnianie za pomocą nazwy użytkownika i hasła lub certyfikatu X.509. Autoryzacja do odczytu i zapisu danych uzyskiwana jest na podstawie uprawnień dostępu użytkownika lub przyznanej mu roli. Należy pamiętać, jak podkreśla OPC Foundation, że zapewnienie poziomu bezpieczeństwa wynikającego ze specyfikacji OPC UA zależy od właściwej konfiguracji aplikacji.

Niemiecki Federalny Urząd Bezpieczeństwa Teleinformatycznego (BSI) przeprowadził już dekadę temu analizę bezpieczeństwa OPC UA. Protokół został określony jako zaprojektowany w sposób zapewniający bezpieczeństwo (secure by design). W raporcie opublikowanym przez BSI zgłoszono tylko niewielkie uwagi, nie stwierdzono błędów systematycznych. Zalecono używanie trybu "Sign" lub "SignAndEncrypt" i sposobu szyfrowania "Basic256Sha256". Kolejna analiza została przeprowadzona w roku 2017 przez Kaspersky Labs, a jej wyniki były mniej optymistyczne. Zidentyfikowano kilkanaście zagrożeń dla bezpieczeństwa. W obydwu przypadkach OPC Foundation odpowiedziała na wszystkie uwagi i zapewniła, że zgłoszone zagrożenia zostały wyeliminowane lub trwają prace nad ich usunięciem.

OPC UA w systemach wbudowanych

Dzięki odejściu od stworzonego przez Microsoft interfejsu DCOM, standard OPC UA może być implementowany na sprzęcie, który nie jest obsługiwany przez system operacyjny Windows. Otwiera to furtkę dla całej gamy systemów wbudowanych opartych na dowolnej architekturze. OPC UA jest dostępne również dla systemów wykorzystujących stosunkowo proste mikrokontrolery. W tego typu systemach głównym ograniczeniem są skromne zasoby pamięci i procesora.

Jednym z istotnych zagadnień rozważanych przy wyborze standardu komunikacji jest również czas potrzebny na implementację serwera OPC w urządzeniu. Firmy od lat zajmujące się komunikacją przemysłową wychodzą naprzeciw producentom sprzętu, udostępniając zestawy narzędzi służących do wyposażenia urządzeń w serwer OPC UA. Oferowane przez nich Software Development Kity (SDK) usprawniają proces dodawania obsługi OPC do urządzenia. SDK można znaleźć w ofercie takich firm jak Matrikon OPC, Prosys, Softing, Unified Automation. Swój zestaw udostępnia również OPC Foundation. SDK od Matrikon OPC stworzony został z myślą o urządzeniach o dużych ograniczeniach mocy obliczeniowej. Dostępne są narzędzia wykorzystujące różne języki i platformy C/C++, .NET i Java. Zaletą wykorzystania SDK jest przyspieszenie procesu implementacji OPC UA. Software Development Kity mają certyfikaty OPC Foundation, co również jest istotne przy wprowadzaniu produktu na rynek.

Skalowanie złożoności do potrzeb aplikacji

Specyfikacja OPC UA jest rozbudowana i zawiera wiele funkcji. Część z nich jest niepotrzebna w najprostszych aplikacjach, a ich wykorzystanie wymagałoby zbyt dużej mocy obliczeniowej, niedostępnej w prostych urządzeniach o małym poborze energii. Z tego względu w specyfikacji zawarto kilka profili różniących się między sobą liczbą obsługiwanych funkcji i usług. Dla najprostszych rozwiązań stworzono Nano Embedded Device Server Profile umożliwiający tylko odczyt i zapis wartości bez żadnego sposobu zabezpieczenia komunikacji. Kolejnym jest Micro Embedded Device Server Profile obsługujący wszystkie funkcje zawarte w Nano oraz dodatkowo model PubSub i obsługę więcej niż jednej sesji. Kolejny, Embedded Device Server Profile, obsługuje dodatkowo funkcje zabezpieczania danych. Pełny zestaw funkcji, które można znaleźć na przykład w serwerach na komputerach PC, jest zawarty w profilu Standard UA Server Profile.

Skalowanie funkcjonalności OPC UA do potrzeb i mocy obliczeniowej urządzenia rozszerza zakres zastosowań dla tego standardu komunikacji. Implementacja OPC UA w niewielkich i prostych urządzeniach, jak na przykład przetworniki pomiarowe, pozwoliłaby na ułatwienie i przyspieszenie integracji danych pomiarowych z oprogramowaniem przemysłowym wykorzystującym IIoT. Urządzenia takie jak przetworniki pomiarowe mogłyby mieć na stałe przypisane tagi, alarmy i wartości diagnostyczne (bez możliwości konfiguracji), a z punktu widzenia klienta obsługującego dane z przetwornika funkcjonować jako jeden z wielu obiektów danej klasy, identyfikowanych na przykład po numerze seryjnym.