Koncepcja Przemysłu 4.0 jako narzędzia szybkiej, zindywidualizowanej produkcji zakłada połączenie wszystkich urządzeń w jedną sieć umożliwiającą bezpośrednią komunikację poszczególnych komponentów. System takich powiązanych ze sobą urządzeń, w skład którego wchodzą czujniki, maszyny pomiarowe, chipy RFID, sterowniki PLC, panele HMI oraz systemy MES i ERP, powinien dostarczać wszechstronnych danych na temat parametrów i przebiegu procesu produkcyjnego. W klasycznym modelu architektury systemu sterowania sygnały inicjujące generowane są bądź cyklicznie, bądź na podstawie danego zdarzenia – zawsze jednak „z góry”, tj. z poziomu klienta. Dolna warstwa pełni natomiast funkcję serwera reagującego: sygnały elektryczne z czujników przekształcane są najpierw w cyfrowe informacje, które – po alokacji znacznika czasu w sterowniku – przesyłane są dalej do warstwy MES – IT (ilustracja 1).

Wraz z nadejściem ery Przemysłu 4.0 ów jasny podział na warstwy oraz struktura przepływu informacji góra-dół przestały być tak klarowne. W inteligentnej sieci każde urządzenie oraz system może bowiem samodzielnie inicjować komunikację z innymi elementami sieci.

B2B – B2M – M2M
W ujęciu ogólnym wszystkie scenariusze komunikacji w ramach Przemysłu 4.0 i Internetu Rzeczy można podzielić na dwa konteksty architektury: usługi tzw. twardego czasu rzeczywistego (kontekst środków automatyzacji, np. deterministycznych sterowników PLC o funkcji regulacyjnej) i tzw. lekkiego czasu rzeczywistego (kontekst IT). Struktura ta determinuje trzy modele komunikacji między poszczególnymi warstwami procesu komunikacyjnego:

• komunikacja B2B (ang. business to business), w której uczestniczą dwa procesy biznesowe, np. wymiana informacji między systemami ERP i MES, HMI i MES, MES i MES, czujnikiem i chmurą w czasie od milisekundy do kilku minut;

• komunikacja B2M (ang. business to machine), w której proces lekkiego czasu rzeczywistego wchodzi w interakcję z procesem twardego czasu rzeczywistego, np. wymiana informacji między warstwą biznesową i maszyną, systemem HMI/MES i sterownikiem PLC w czasie od milisekundy do kilku minut;

• komunikacja M2M (ang. machine to machine), w której dwa procesy automatyzacji porozumiewają się ze sobą w twardym lub lekkim czasie rzeczywistym, np. wertykalna wymiana danych między platformą sterowania a systemem ręcznego sterowania robotem (twardy czas rzeczywisty: mili- bądź mikrosekundy) lub horyzontalna wymiana danych między dwoma systemami sterowania (miękki czas rzeczywisty).

Niezależnie od stosowanego w tym przypadku nazewnictwa, komunikacja w ramach Internetu Rzeczy i Przemysłu 4.0 nie bazuje już wyłącznie na surowych danych i interoperacyjności ich przesyłu, lecz także na wymianie modeli systemów danych, a więc interoperacyjności semantycznej. Kluczowe znaczenie mają w tym przypadku także bezpieczeństwo przesyłu i prawa dostępu do poszczególnych danych i usług. Zagadnienia te znalazły odzwierciedlenie w procesie projektowania standardu OPC Unified Architecture (OPC UA), który definiuje języki opisu i usługi dla poszczególnych modeli systemów danych. Jako zgodny z normą IEC 62541 OPC UA ma za zadanie integrować modele stosowane przez różne organizacje, takie jak BACnet, PLCopen, IEC 61850, AIM AutoID czy MES-DACH. Standard został od początku zaprojektowany z uwzględnieniem wysokich wymogów bezpieczeństwa i dlatego uznawany jest za bezpieczniejszy od innych protokołów, co ma istotne znaczenie w kontekście jego wdrożenia w środowisku Przemysłu 4.0 i Internetu Rzeczy.

Dzięki ujednoliconemu systemowi konsolidacji danych oraz ich strukturze (metadane) standard OPC UA świetnie sprawdzi się w rozproszonej, inteligentnej komunikacji między maszynami – bez konieczności angażowania specjalistów. Komponenty OPC UA są w pełni skalowalne i adaptowalne we wszystkich warstwach komunikacyjnych – od czujników po systemy SAP.

PLCopen: funkcja klienta OPC UA w sterowniku PLC
Wysłanie żądania zainicjowania komunikacji wymaga jednak zainstalowania komponentu klienta OPC UA w sterowniku PLC – najlepiej w formie standardowego interfejsu. Dlatego w 2006 r. firma Beckhoff wystąpiła z propozycją zdefiniowania głównych bloków komunikacyjnych PLCopen w oparciu o OPC UA. Powołana trzy lata później pod jej przewodnictwem wspólna grupa robocza organizacji PLCopen i OPC UA w pierwszej kolejności zdecydowała o mapowaniu modelu systemu danych zgodnego z normą IEC 61131-3 w OPC UA (serwer): oznacza to, że ten sam zgodny z normą program dla sterownika PLC może zostać w niezmienionej postaci załadowany na sterowniki PLC innych producentów z wykorzystaniem narzędzi inżynierskich ich produkcji. Same sterowniki mogą zaś za pośrednictwem OPC UA przekazywać dane na zewnątrz (np. na potrzeby wizualizacji czy systemów MES/ERP) w sposób semantycznie identyczny, co znacznie redukuje nakład pracy inżynierów. Zamiast bowiem podłączać kolejne bloki danych do maski wizualizacyjnej lub systemu MES, muszą oni teraz zintegrować z nimi jeden obiekt – także w przypadku rozwiązań pochodzących od różnych producentów.

W wyniku dalszych prac nad stworzeniem wspólnego standardu w kwietniu 2014 r. ogłoszona została specyfikacja organizacji PLCopen „Bloki funkcyjne klienta OPC UA według normy IEC 61131-3”. Otworzyło to drogę do rozszerzenia zakresu funkcji kontrolera: obecnie może on zarówno odgrywać wiodącą rolę w komunikacji między urządzeniami, jak i nadal realizować podstawowe zadania sterowania i obsługi danych dolnej warstwy systemu (ilustracja 2).

W ramach nowego standardu sterownik PLC może komunikować się w wymiarze horyzontalnym i wertykalnym: wymieniać złożone struktury danych z innymi kontrolerami, jak również uruchamiać metody na serwerze OPC UA systemu MES/ERP, aby np. pobrać nowe zamówienia produkcyjne lub zapisać dane w chmurze. To z kolei umożliwia niezależne aktywne działanie linii produkcyjnej.

Bloki funkcyjne szybko zostały docenione przez klientów: Przedsiębiorstwo Wodociągowe Vogtland w Niemczech wykorzystało wbudowane sterowniki CX9020 firmy Beckhoff, aby połączyć 300 rozproszonych instalacji w jedną inteligentną sieć. Wyposażone w zgodne z normą kontrolery PLC realne obiekty (np. pompy) utworzyły złożony system o szerokich możliwościach interakcji poszczególnych komponentów. Dzięki zintegrowanemu serwerowi OPC UA obiekty te są automatycznie dostępne dla klienta w formie kompleksowej, cechującej się semantyczną operacyjnością struktury danych świata zewnętrznego. W efekcie powstaje rozproszona inteligencja, która samodzielnie podejmuje decyzje oraz przekazuje informacje do swoich „sąsiadów” bądź pobiera dane statystyczne i procesowe niezbędne do zapewnienia niezakłóconego przebiegu procesów produkcyjnych.

Dzięki standaryzowanym blokom funkcyjnym PLCopen urządzania mogą – jako klient OPC UA – samodzielnie inicjować komunikację z innymi uczestnikami procesu, a jednocześnie – jako serwer OPC UA – reagować na ich żądania lub żądania systemów nadrzędnych (SCADA, MES, ERP).

Realny scenariusz wywołania metody OPC UA został zaprezentowany już w 2013 r. podczas Targów Hanowerskich: sterownik PLC firmy Beckhoff – działając jako klient OPC UA – wywołał metodę w systemie MES firmy iTAC: jako parametry wejścia podano kod RFID i dane procesowe –zapisane, sprawdzone i opatrzone informacją zwrotną „OK” lub „Failure” przez system MES. Zachowano przy tym określony sposób prezentacji i spójność danych.

Wszystkie moduły w jednym
Mapując zgodne z normą IEC 61131-3 modele systemów danych na serwerze OPC UA oraz tworząc bloki funkcyjne PLCopen producenci sterowników PLC poczynili ważny krok na drodze do stworzenia jednolitego standardu komunikacyjnego zgodnego z ideą Przemysłu 4.0. Uruchomienie usług OPC UA na innych urządzeniach za pośrednictwem sterowników PLC oferuje możliwość rozwijania komunikacji typu B2M: sterownik PLC może np. uruchomić usługę w aplikacji systemu wizyjnego/ kamery lub czytniku RFID, porozumiewać się bezpośrednio z innym kontrolerem lub przesłać informacje z aplikacji Big Data do chmury.

Zarządzanie tym procesem – zwłaszcza w sposób prosty i intuicyjny – wymaga jednak zainstalowania odpowiedniego oprogramowania, np. TwinCAT3 firmy Beckhoff, które oferuje możliwość zaimplementowania modułów standardu IEC 61131-3, C++ i MATLAB/Simulink, załadowania ich na różne dyski CPU i niezależnego uruchomienia w czasie rzeczywistym przy zachowaniu pełnej integracji danych. Funkcjonalność taką zapewnia język modułu TwinCAT, który opisuje cechy poszczególnych modułów m.in. w zakresie parametrów procesowych i metod.

Programowanie sterowników PLC przy pomocy TwinCAT jest proste i sprowadza się do dodania prostego wiersza polecenia, który pozwala na uruchomienie danej metody w sterowniku PLC (o dowolnych parametrach wejścia/wyjścia) jako usługi na serwerze UPC UA zintegrowanym z tymże sterownikiem. Każdy klient OPC UA może dowolnie przeszukiwać serwer TwinCAT OPC UA i uruchomić odpowiednią usługę – niezależnie od systemu operacyjnego, języka programowania i z zachowaniem spójności danych.

Zdalne wywołanie procedury
Wymiana danych między warstwą MES i sterownikiem PLC następuje dziś z reguły przy wykorzystaniu przewlekłej procedury handshake, w której system MES sygnalizuje przekazanie algorytmu do kontrolera, a ten deklaruje gotowość jego odbioru, aby następnie – po realizacji transferu – potwierdzić zakończenie procesu. W przeciwieństwie do standardowego kontrolera sterownik PLC SOA – dzięki zdalnemu wywołaniu procedury (ang. Remote Procedure Call – RPC) – umożliwia przesył danych w ramach jednej operacji – usługi o określonych parametrach wejściowych (algorytm) i wyjściowych (potwierdzenie odbioru). Opcja ta umożliwia redukcję czasu obiegu informacji między kontrolerami a systemem MES, a tym samym zwiększa efektywność realizacji procesów produkcyjnych. Co więcej, ogranicza również koszty konsolidacji danych dolnej i górnej warstwy systemu sterowania.

Architektura SOA jest czymś więcej niż tylko usługą sieciową z zabezpieczeniami VPN. Umożliwia bowiem zorientowaną obiektowo wymianę bieżących i historycznych danych, a także informacji o alarmach i usługach (metodach) – łącznie z odnośnymi metadanymi – z uwzględnieniem niezbędnych zabezpieczeń, możliwości modelowania, a także modeli systemów danych zgodnych z międzynarodową normą IEC. OPC UA – jako jedyna architektura SOA spełniająca wymogi owej normy – ma szansę stać się nowym standardem wymiany danych w aplikacjach Przemysłu 4.0 i Internetu Rzeczy. Już dziś oferuje bowiem możliwość bezpiecznej horyzontalnej i wertykalnej komunikacji pomiędzy wszystkimi warstwami systemu – od czujników po systemy IT.