Przemysł 4.0 i Internet Rzeczy to koncepcje rozwojowe technologii użytkowych, wymagające dobrze zintegrowanych sieci i komunikacji między poszczególnymi, różnego typu jednostkami. Drugim niezbędnym do ich realizacji czynnikiem jest architektura zorientowana na usługi (SOA) programowalnego sterownika logicznego (PLC). Komunikowanie sterowników PLC przez Internet nie jest niczym nowym. Czym zatem jest SOA i co nowego wprowadza SOA-PLC?
Sensory, mierniki, RFID, sterowniki PLC, interfejsy człowiek-maszyna (HMI), system realizacji produkcji (MES) i system planowania zasobów przedsiębiorstwa (ERP) dostarczają istotnych danych produkcyjnych. W klasycznych architekturach systemów sterowania dane są kierowane zdarzeniami lub cyklami, ponadto priorytetem dla nich jest zawsze odpowiedź napytania „z góry”, z poziomu klienta. Urządzenia na niższym poziomie pełnią zazwyczaj rolę serwera i dostarczają informacji. System wizualizacji może na przykład zażądać danych statusu od sterownika PLC albo przesłać nowe dane do tego sterownika. Pierwszym krokiem w takiej sytuacji jest zawsze przetworzenie elektronicznych sygnałów sensora na dane cyfrowe. Następnie dokonuje się alokacji znacznika czasu w sterowniku PLC i przesyła informacje do MES-IT, zwykle przez inne usługi sieciowe (rys. 1).
Dzięki tzw. koncepcji Przemysł 4.0 poziomy dostępu i hierarchii systemowej w sieciowych systemach przemysłowych nie będą już tak rygorystycznie przestrzegane, ponadto zajdą zmiany w odgórnym podejściu do przepływu informacji. W inteligentnej sieci każde urządzenie czy usługa będą mogły autonomicznie zainicjować rozpoczęcie komunikacji z innymi usługami.
Zasadniczo, przy pewnym uproszczeniu, wszystkie scenariusze komunikacji i przypadki użycia, które zostały zdefiniowane w grupach koncepcji Przemysł 4.0 i Internetu Rzeczy, można sprowadzić do dwóch kontekstów architektury zorientowanej na komunikację: z jednej strony mamy do czynienia z usługami tzw. twardego czasu rzeczywistego (jak kontekst automatyzacji czy deterministyczny sterownik PLC służący do celów kontroli), a z kolei z drugiej strony mamy do czynienia z usługami tzw. słabego czasu rzeczywistego, np. w kontekście IT (rys. 2).
Zgodnie z definicją komitetu wykonawczego koncepcji Przemysł 4.0 WG2, prowadzi to do trzech obszarów zmian w dziedzinie komunikacji:
- komunikacji B2B (ang. business to business) – jest to komunikacja na poziomie dwóch procesów biznesowych, np. aplikacja ERP wymienia się informacjami z aplikacją MES. Wymiana danych, tak jak w przypadku wymiany pomiędzy HMI i MES czy MES i MES albo sensorem i usługą w chmurze, może zająć od kilku milisekund do kilku minut,
- komunikacji B2M (ang. business to machine) – jest to komunikacja procesu „słabego czasu rzeczywistego” z procesem „twardego czasu rzeczywistego”, np. wymiana informacji między aplikacją biznesową i maszyną. Czas niezbędny do wymiany np. bieżących danych pomiędzy HMI i PLC czy MES i kontrolerem sterownika PLC może zająć od kilku milisekund do kilku minut,
- komunikacji M2M (ang. machine to machine) – jest to komunikacja dwóch procesów w kontekście automatyzacji w systemie zarówno „słabego”, jak i „twardego” czasu rzeczywistego, np. kontroler platformy robota wymienia informacje o kontroli z ręcznym kontrolerem robota. Wymiana informacji musi się odbywać w systemie twardego, deterministycznego cyklu czasu rzeczywistego i trwać pomiędzy mikrosekundami a milisekundami. Dla przykładu: oba kontrolery wymieniają dane szybko (w systemie „słabego czasu rzeczywistego”), cyklicznie i niezależnie od magistrali danymi w systemie horyzontalnym.
W tym wypadku determinizm można postrzegać jako dbałość o jakość usług (and. quality of service – QoS) z pewnymi wymaganiami, które dany proces komunikacji może spełnić lub nie. Spełnienietych wymagań może zostać zagwarantowane ustaleniem progu czasowego oczekiwania na odpowiedź, a wynoszącego 100 mikrosekund.
Termin M2M jest już wykorzystywany w mobilnej komunikacji radiowej, w której odnosi się do współdziałania urządzeń z wykorzystaniem komunikacji mobilnej i procesów IT. W tym kontekście rozpowszechniony jest pogląd, że z M2M mamy do czynienia zawsze wtedy, kiedy używana jest karta SIM.
Niezależnie od tego, jak nazwiemy opisane kategorie, faktem jest, iż komunikacja w Internecie Rzeczy i systemach zgodnych z koncepcją Przemysł 4.0 nie będzie już oparta na samych danych i interoperacyjności komunikacji danych. Będzie ona polegała na wymianie modeli informacji, a zatem na interoperacyjności semantycznej. Istotnym czynnikiem będzie integralność przesyłu danych, a także bezpieczeństwo prawa dostępu do poszczególnych danych i usług. Wszystkie te wymogi stanowią kluczowe aspekty OPC Unified Architecture (OPC UA), która zawiera język opisu i usługi komunikacji dla modeli informacyjnych. OPC UA, która spełnia standardy IEC 62541, została zaprojektowana do mapowania modeli informacyjnych innych organizacji, takich jak BACnet, PLCopen, IEC 61850, AIM AutoID, i MES-DACH. Zgodnie ze stanowiskiem niemieckiego Federalnego Urzędu Bezpieczeństwa w dziedzinie Technologii Informacyjnych (niem. Bundesamt für Sicherheit in der Informationstechnik – BSI), „security by design” (bezpieczeństwo projektu), które zostało wprowadzone do OPC UA, jest zdecydowanie lepsze niż w innych protokołach i oceniane pod kątem obecnego projektu, ze względu na to, jak istotne jest w Przemyśle 4.0.
Architektura OPC UA dzięki swojemu ujednoliconemu systemowi konsolidacji danych oraz strukturze (metadane) jest szczególnie odpowiednia do wykorzystania w dystrybuowanych, inteligentnych zastosowaniach pomiędzy maszynami, bez konieczności angażowania specjalistów czy zawiadamiania centrali. Funkcjonalność komponentów OPC UA można dostosować do potrzeb systemu i użytkownika już na poziomie sensora (jak w przypadku producenta turbin wiatrowych Areva, u którego obecne użycie pamięci sensora zaczyna się od 240 kB flash i 35 kB RAM), a skończywszy na systemach SAP.
PLCopen: klient OPC UA w sterownikach PLC
By móc wykonać zadanie tzw. nieskończonej komunikacji, kontrolery sterowników PLC wymagają komponentu klienta, w warunkach idealnych stanowiącego ujednolicony interfejs. W październiku 2006 r. firma Backhoff Automation zaproponowała zdefiniowanie bloków komunikacyjnych PLCopen w oparciu o architekturę OPC UA. To działanie zaowocowało trzy lata później stworzeniem wspólnej grupy roboczej PLCopen i OPC UA. W 2010 r. zaadaptowano do standardowej specyfikacji mapowanie modelu informacji EC 61131-3 w OPC UA (która stała się serwerem). W praktyce oznacza to, iż jeden program dla sterownika, zgodny z normą IEC 61131-3, może zostać załadowany w niezmienionej formie do wielu sterowników PLC, przy wykorzystaniu narzędzi różnych producentów. Kontrolery udostępniają na zewnątrz dane i informacje w jednolitej semantycznie formie poprzez OPC UA, tak jak w przypadku wizualizacji i zadań MSP/ERP. To z kolei pozwala na zaangażowanie wykwalifikowanych kadr inżynierskich. W przypadku bloku funkcyjnego mającego 20 punktów danych wystarczy, zamiast podłączać każdy kolejny blok do maski wizualizacyjnej czy systemu MES, podłączyć pojedynczy obiekt, również w przypadku sprzętu i urządzeń pochodzących od różnych producentów.
Dalsza praca wspomnianej grupy roboczej zaowocowała przyjęciem specyfikacji PLCopen „Bloki funkcyjne klienta OPC UA dla IEC 61131-3” („OPC UA client function blocks for IEC 61131-3”). Dzięki temu rozwiązaniu kontroler może z jednej strony odegrać wiodącą rolę w komunikacji między urządzeniami, a z drugiej wciąż realizować podstawowe zadania sterowania i obsługi danych na niskim poziomie systemu.
W związku z tym sterownik PLC może horyzontalnie wymieniać się skomplikowanymi strukturami danych z innymi kontrolerami czy wertykalnie wywoływać metody z serwera OPC UA, a to wszystko w ramach systemu MES/ERP – może np. pobierać nowe zamówienia produkcyjne czy wprowadzać dane do chmury. To z kolei umożliwia niezależne działanie linii produkcyjnej. Klienci zdają już sobie sprawę z potencjału tych rozwiązań, oferowanych przez ujednolicone bloki funkcyjne.
SOA-PLC
Producenci sterowników PLC przetarli już szlak przez mapowanie zasad normy IEC 61131-3 w serwerze OPC UA i przez wykorzystanie bloków funkcyjnych PLCopen. Zdolność wywołania usług OPC UA w innych urządzeniach z poziomu sterownika PLC umożliwia technologii rozwijanie scenariusza B2M. Na przykład sterownik PLC może wywołać usługę w aplikacji kamery wizyjnej danej maszyny lub czytnika RFID, skomunikować się bezpośrednio ze sterownikiem PLC czy przesłać dane aplikacji Big Data do chmury. Sterownik PLC jest w stanie wywołać te metody, ale w jaki prosty sposób może je sam udostępnić?
Zunifikowane oprogramowanie oferuje możliwość implementacji programów w językach normy IEC 61131-3, C++ i Mathlab/Simulink (Mathworks), załadowania ich do różnych rdzeni procesora i wykorzystywania w różnych systemach czasu rzeczywistego, a jednocześnie gwarantuje ich niezawodną interakcję. Podstawę stanowi moduł języka oprogramowania, który opisuje charakterystykę poszczególnych modułów na potrzeby parametrów procesowych i metod.
Dla programistów sterowników PLC implementacja jest bardzo łatwa: metoda PLC (z możliwością dowolnego wybrania parametrów wejścia/wyjścia) jest dostępna jako wywołanie usługi w serwerze OPC UA i jest zintegrowana z kontrolerem sterownika PLC poprzez dodanie prostego wiersza instrukcji „Pragma”. W oparciu o kwestie bezpieczeństwa informatycznego, jak również zezwolenia zintegrowane w protokole OPC UA, każdy klient OPC UA ma dostęp do serwera OPC UA i może wywołać wymaganą usługę, niezależnie od systemu operacyjnego i języka programowania, co z kolei zapewnia jednolitość danych.
Zalety SOA-PLC
Obecnie wymiana danych pomiędzy MES a sterownikiem PLC zwykle zachodzi w ramach czasochłonnej procedury wymiany potwierdzeń. System MES sygnalizuje kontrolerowi transmisję nowych danych, a sterownik PLC potwierdza gotowość. Gdy dane zostaną dostarczone, transfer jest potwierdzany. SOA-PLC umożliwia jednorazowe przesłanie danych sterownikowi: wartości danych nie są już wymieniane podczas różnych transmisji, ale są traktowane jako jedna usługa, zawierająca parametry wejścia (dane) i parametry wyjścia (potwierdzenie sterownika PLC). Innymi słowy, OPC UA umożliwia zdalne wywołanie procedury (RPC), co jest dostępne już z poziomu bloku funkcyjnego sterownika PLC. Prowadzi to do zdecydowanego skrócenia czasu komunikacji pomiędzy sterownikiem PLC a systemem MES, a także może wpłynąć na zwiększenie wydajności produkcji. Co więcej, zmniejsza to znacząco koszty związane z pracami inżynieryjnymi, niezbędnymi do utworzenia sprawnej komunikacji pomiędzy poziomem produkcyjnym i zarządczym zakładu.
Autor: Stefan Hoppe jest menedżerem ds. produktów TwinCAT w firmie Beckhoff Automation, a także prezesem PLCopen, OPC Working Group oraz OPC Europe.
Fort. Wikimedia Commons/Ordercrazy
Rys. Beckhoff Automation
