TwinCAT SOA-PLC podstawą architektury Przemysłu 4.0

Rys. 1. Tradycyjna architektura systemów sterowania i zarządzania w przemyśle - poszczególne warstwy są połączone ze sobą odrębnymi sieciami komunikacyjnymi

Przemysł 4.0 zapewnia możliwości dynamicznego rozwoju produkcji, aczkolwiek wymaga on korzystania z rozwiązań pozwalających na komunikację pomiędzy usługami, urządzeniami i oprogramowaniem. Te ostatnie to przykładowo czujniki, urządzenia pomiarowe, systemy RFID, sterowniki PLC, HMI oraz systemy MES i ERP - wszystkie one przekazują istotne dane z punktu widzenia efektywności procesów produkcyjnych i muszą być odpowiednio ze sobą skomunikowane.

W tradycyjnych architekturach systemów automatyki i sterowania, takich jak przedstawiona na rysunku 1, usługi i procesy wywoływane są zdarzeniami lub rozpoczynane cyklicznie. Typowo jednak komunikację inicjują wyższe warstwy systemu, zaś poziomy niższe pełni rolę wykonawczą - przykładowo system wizualizacji może zażądać podania informacji o stanie sterownika PLC. Na najniższym poziomie następuje konwersja sygnałów czujników elektrycznych na informacje cyfrowe, następnie dane te, wraz ze znacznikami czasowymi, są przetwarzane przez sterowniki i, za pośrednictwem różnych usług, przesyłane do poziomu MES/IT.

W epoce Przemysłu 4.0 omawiany schemat staje się coraz mniej aktualny, bowiem w inteligentnych systemach produkcyjnych każde urządzenie bądź usługa muszą mieć możliwość autonomicznego nawiązywania łączności z innymi.

KOMUNIKACJA PRZEMYSŁOWA PRZECHODZI FUNDAMENTALNE ZMIANY

Rys. 2. W przyszłości dotychczasowa architektura zostanie zastąpiona przez sieć usług, która będzie bazowała na wielopoziomowej integracji z wykorzystaniem OPC UA; urządzenia i usługi będą bezpośrednio wymieniały ze sobą informacje korzystając z SOA

W automatyce przemysłowej wykorzystywanych jest bardzo wiele technologii komunikacyjnych. W pierwszym przybliżeniu można je podzielić na: deterministyczne (hard real-time), które stosowane są w procesach sterowania czy przykładowo synchronizacji pracy układów napędowych, jak też miękkie, niedeterministyczne. Użycie tych ostatnich obejmuje zastosowania związane choćby z pomiarami, przekazywaniem danych do wyższych warstw systemu zarządzania oraz różnymi usługami.

Tradycyjnie przyjęło się również dzielić komunikację pod kątem aplikacji biznesowych (B) oraz maszynowych/sterowania (M). W tym przypadku spotkać się można z wymianą danych B2B, tj. przykładowo pomiędzy systemami ERP oraz MES czy też MES i chmurą obliczeniową, komunikacją B2M - przesyłaniem danych do/z systemu zarządzania produkcją do sterowników oraz HMI, oraz komunikacją M2M. Ta ostatnia dotyczy np. sterowania pracą robota przez jego kontrolera, co odbywać się musi w sposób deterministyczny, zwykle z milisekundowymi lub krótszymi czasami cyklu.

Niezależnie od przyjętej kategoryzacji, można zauważyć, że dzisiaj zachodzi fundamentalna zmiana, której przyczyną jest upowszechnianie się koncepcji Przemysłu 4.0 oraz Internetu Rzeczy. W ich przypadku komunikacja nie będzie już rozpatrywana w kontekście wymiany danych czy zgodności interfejsów, ale przede wszystkim modeli informacyjnych oraz interoperacyjności semantycznej. Kluczowe będą też bezpieczeństwo oraz integralność transmisji, a także zarządzanie prawami dostępu do danych i usług.

Wszystkie wymienione elementy są kluczowymi dla architektury OPC UA (OPC Unified Architecture). Zawiera ona język opisu modeli informacyjnych oraz usług komunikacyjnych. Jako norma IEC 62541, OPC UA jest przeznaczona do mapowania różnorodnych modeli - przykładowo takich jak BACnet, PLCopen, IEC 61850, AIM AutoID, itd.

Dzięki wbudowanemu bezpieczeństwu oraz standaryzacji w zakresie danych, OPC UA doskonale nadaje się do wykorzystania w rozproszonych, inteligentnych aplikacjach - takich jak te w Przemyśle 4.0. Standard ten zapewnia dużą skalowalność, dzięki czemu jego obszar zastosowań rozciąga się od czujników i komponentów automatyki do poziomu oprogramowania takiego jak SAP.

PLCOPEN: KLIENT OPC UA W STEROWNIKU PLC

Rys. 3. Bloki programowe PLCopen/OPC UA zapewniają szybką komunikację, która jest niezależna od zastosowanej sieci transmisyjnej; jest ona wspierana przez oprogramowanie TwinCAT PLC ze zintegrowanym klientem OPC UA

Równo dekadę temu firma Beckhoff zaproponowała zdefiniowanie bloków komunikacyjnych PLCopen dla standardu OPC UA. Doprowadziło to do utworzenia wspólnej grupy roboczej PLCopen i OPC UA, a po kilku latach - stworzenie specyfikacji modelu informacyjnego IEC 61131-3 w ramach serwera OPC UA.

W praktyce oznaczało to, że dowolny program zgodny z IEC 61131-3 mógł być uruchamiany na dowolnym PLC, a do jego stworzenia - wykorzystane dowolne narzędzia projektowe. Również sterowniki udostępniające dane i informacje zapewniały ich zgodność semantyczną ze standardem poprzez OPC UA, co zagwarantowało łatwość komunikacji z urządzeniami wizualizacyjnymi czy systemami MES/ ERP. Wpłynęło to na dalsze zmniejszenie nakładów na prace projektowe i inżynieryjne.

Kolejnym ważnym krokiem było przyjęcie w kwietniu 2014 roku specyfikacji "Bloki funkcyjne klienta OPC UA dla IEC 61131-3". Dzięki niej sterowniki mogą odgrywać aktywną rolę w komunikacji, wymieniając dane w złożonych strukturach (modelach informacyjnych) zarówno w poziomie - pomiędzy innymi sterownikami i urządzeniami automatyki, jak też w pionie - do systemów MES/ ERP, a nawet chmury obliczeniowej (patrz rys. 3). PLC mogą wywoływać metody w serwerach OPC UA - przykładowo w celu pobrania nowych zleceń produkcyjnych. Taka funkcjonalność pozwala również na uniezależnianie od siebie części linii produkcyjnych.

SOA-PLC - STEROWNIK UDOSTĘPNIAJĄCY USŁUGI W CZASIE RZECZYWISTYM

Dostępność serwera OPC UA jako bloku funkcjonalnego PLCopen zapewnia zupełnie nowe możliwości aplikacyjne. Przykładowo sterownik może bezpośrednio wywoływać funkcje w innych urządzeniach i oprogramowaniu z wykorzystaniem komunikacji B2M. Może on uruchomić usługę w systemie wizyjnym, czytniku RFID, komunikować się bezpośrednio z PLC lub przesyłać dane do chmury obliczeniowej. O ile wywoływanie metod stało się proste, o tyle powstaje pytanie o to, jak samo urządzenie ma udostępniać usługi innym elementom systemu.

TwinCAT 3 zapewnia przykładowo możliwość implementacji modułów w IEC 61131-3, C++ czy środowisku MATLAB/ Simulink, które są wgrywane do procesora i wykonywane z wykorzystaniem wybranych rdzeni w czasie rzeczywistym. Ich wykorzystanie jako usług jest bardzo proste.

Metody PLC dla z dowolnie wybranych parametrów wejść/wyjść są udostępniane jako wywołania usług w serwerze OPC UA - są one integrowane w sterowniku poprzez dodanie prostej instrukcji "pragma". Każdy klient OPC UA (oczywiście z uwzględnieniem uprawnień i kwestii bezpieczeństwa) może wywoływać żądaną usługę serwera TwinCAT OPC UA - niezależnie od jego systemu operacyjnego czy języka programowania.

Dodatkową zaletą korzystania z OPC UA jest znaczne uproszczenie komunikacji pomiędzy poziomem sterowania (PLC i inne urządzenia) a zarządzania produkcją (systemy MES). Standardowo taka komunikacja wymaga czasochłonnej procedury handshakingu, natomiast w przypadku SOA-PLC wystarczy jednokrotne przesłanie danych ze sterownika. Informacje nie są już wymieniane w wielu krokach, ale traktowane jako żądanie obejmujące dane, parametry wejściowe i wyjściowe. OPC UA sprawia, że zdalne wywoływanie procedur (Remote Procedure Call) jest równie proste jak uruchamianie dowolnych innych bloków funkcyjnych PLC.

PERSPEKTYWY NA PRZYSZŁOŚĆ

SOA-PLC to znacznie więcej niż tylko usługa webowa poprzez sieć VPN dostępna bezpośrednio w sterowniku PLC. Jest to kompletna komunikacja obiektowa dla danych bieżących i historycznych, dla alarmów oraz usług, która obejmuje metadane, możliwości korzystania z różnorodnych modeli informacyjnych oraz zaimplementowane zabezpieczenia. A wszystko to poparte międzynarodową normą IEC!

Integracja funkcjonalności serwera i klienta OPC UA w sterownikach umożliwia wdrażanie inteligentnych sieci, zapewniając wysoki poziom bezpieczeństwa z możliwością dostępu do warstwy usług przez wiele aplikacji i urządzeń jednocześnie. Warto nadmienić, że wszystkie inne porty sterownika mogą być wyłączone - urządzenie będzie dostarczało usługi SOA jedynie poprzez OPC UA, z zachowaniem odpowiednich praw dostępu.

Jako jedyna architektura SOA dla Przemysłu 4.0, która została standaryzowana przez IEC, technologia OPC UA ma szansę stać się standardem dla wymiany danych w przemyśle przyszłości oraz aplikacjach Internetu rzeczy. Gwarantuje ona bezpieczną komunikację zarówno w pionie systemów (od czujników do systemów IT), jak też w poziomie - pomiędzy współpracującymi ze sobą urządzeniami.

Beckhoff oferuje funkcjonalne sterowniki SOA-PLC z wbudowanymi klientem i serwerem OPC UA. Są one dostępne w wielu wykonaniach, już od najmniejszych systemów Embedded PC z rodziny CX. Do tego dochodzi pełna oferta terminali we/wy oraz możliwości zapewniane przez oprogramowanie TwinCAT, które może być uruchamiane na praktycznie dowolnych platformach sprzętowych. W każdym z przypadków zapewnia ono dużą wydajność i bezpieczeństwo, stanowiąc architekturę spełniającą wymogi Przemysłu 4.0 dzisiaj i w przyszłości.

Beckhoff Automation
www.beckhoff.pl