Przyszłość oprogramowania IIoT w przemyśle produkcyjnym

Artykuł wyjaśnia pojęcia oraz opisuje wykorzystanie standardów DDS, TSN i OPC UA w zaawansowanych aplikacjach w przemyśle produkcyjnym.

Najważniejszymi standardami platformy sieciowej Przemysłowego Internetu Rzeczy (IIoT) są: OPC UA (OPC Unified Architecture) Fundacji OPC oraz DDS (Data Distribution Service, usługa dystrybucji danych) konsorcjum OMG (Object Management Group). Obydwa te standardy są obecnie coraz częściej adaptowane w systemach automatyki przemysłowej, jednak nie w tych samych sektorach.

Każdy z tych dwóch standardów różni się od wielu dzisiejszych dyskretnych systemów automatyki, które wykorzystują prostą architekturę. Programowalny sterownik logiczny (PLC) łączy się z urządzeniami przemysłowymi za pomocą magistrali obiektowej. PLC steruje tymi urządzeniami i zarządza ich dalszymi połączeniami – z oprogramowaniem wyższego poziomu, takim jak interfejsy operatorskie (HMI), albo służącym do archiwizacji danych.

Zadania wykonywane przez oprogramowanie wykorzystywane w zakładach przemysłowych są proste. Odczyt danych z czujników, realizacja logiki sterującej oraz wysyłanie sygnałów wyjściowych do elementów wykonawczych, czyli wykonywanie powtarzalnych operacji. W fabrykach znajduje się szereg gniazd produkcyjnych, z których każde ma kilkadziesiąt urządzeń.

Fot. 1. Standard OPC UA koncentruje się na integracji urządzeń i wykorzystuje powszechnie wykorzystywane modele urządzeń, które umożliwiają interoperacyjność produktów pochodzących od różnych dostawców.

Przyczyny zmian w konstrukcjach sterowników PLC oraz interfejsów HMI

Tradycyjne konstrukcje sterowników PLC oraz interfejsów HMI służyły dobrze w przemyśle w ciągu ostatnich trzydziestu lat. Jednak kolejnej dekady mogą już nie przetrwać. Dlaczego? Coraz większe szybkości procesorów oraz łatwość połączeń poprzez sieci wyższego poziomu, teleinformatyczne, oferują możliwość wykorzystania zasobów obliczeniowych o większych możliwościach. Systemy oparte na gnieździe produkcyjnym, obsługiwane przez sterowniki PLC, mogą być niezawodne, wykonujące bez przerwy powtarzalne operacje. Jednak tak naprawdę nie są one „inteligentne”. Nie przystosowują się dobrze do zmian. Nie są w stanie wykorzystać zalet obserwowanej obecnie eksplozji możliwości procesorów oraz sieci. Krótko mówiąc, nie są one dobrą drogą do budowania bardziej inteligentnego i zarazem rozbudowanego, złożonego oprogramowania.

Technologia IIoT ma olbrzymi potencjał transformacji systemów przemysłowych. W tym celu jednak musi obsługiwać przesył danych na wszystkich poziomach: w gniazdach produkcyjnych, na hali fabrycznej oraz w biurze firmy przemysłowej. Oczywiście nie jest to proste. Powszechne wykorzystywanie danych wymaga nowej architektury sieci oraz nowego podejścia do organizacji architektury połączeń sieciowych.

Standardy OPC UA oraz DDS rozwiązują całkowicie różne problemy. Inżynierowie sprzętowi (hardware engineers) wykorzystują OPC UA, ponieważ upraszcza ona połączenia sieciowe urządzeń. Natomiast architekci systemów wykorzystują DDS, ponieważ łączy on warstwy systemu ze spójnym modelem zarządzania sieciami. Standardy DDS i OPC UA są różne, jednak nie chodzi tu o wybór właściwego. Standardy te nie rywalizują ze sobą.

W rzeczywistości inżynierowie coraz bardziej doceniają możliwość współpracy standardów dedykowanych również dla poziomu obiektowego sieci przy tworzeniu przyszłej architektury przesyłu danych w przemyśle. Prawdziwym wyzwaniem jest podjęcie decyzji, który problem musi być rozwiązany. Wynika z tego, że sprawą kluczową jest zrozumienie możliwości standardów OPC UA i DDS. Ważne jest, aby zidentyfikować sytuacje, w których należy wykorzystać tylko DDS, tylko OPC UA oraz kombinację obydwu platform.

Standard OPC UA a połączenia w sieciach TSN

W sektorze produkcji dyskretnej standardy OPC UA oraz sieci wrażliwe na czas (time sensitive networking – TSN) oferują potencjalny sposób rozwiązania problemu konfliktu pomiędzy magistralami obiektowymi (fieldbus wars). OPC UA jest użyteczny przy integrowaniu w gnieździe produkcyjnym dedykowanych urządzeń, takich jak przenośniki taśmowe, czujniki, roboty wykonujące powtarzalne czynności oraz napędy. Standard ten pozwala na efektywne połączenie gniazd produkcyjnych z takim oprogramowaniem, jak interfejsy HMI oraz do archiwizacji danych. Realizuje to poprzez modelowanie urządzeń fizycznych i umożliwianie pracującym w fabryce technikom oraz inżynierom produkcji koordynowania tych urządzeń za pomocą sterownika PLC (rys.1).

Rys. 1. Lokalne połączenia sieciowe oparte na modelu publikacji/subskrypcji (pub/sub). W systemie o architekturze klient/serwer, opartym na standardzie OPC UA, wzorzec klient/serwer jest wykorzystywany do łączenia gniazd produkcyjnych z oprogramowaniem interfejsów operatorskich (HMI) oraz oprogramowaniem do archiwizacji danych. Gdy wykorzystywana jest specyfikacja OPC UA pub/sub, urządzenia i programowalne sterowniki logiczne (PLC) publikują lub subskrybują proste dane numeryczne oraz komunikują się poprzez lokalne sieci wrażliwe na czas (TSN), które zastępują magistrale obiektowe w gniazdach produkcyjnych.

Gniazda produkcyjne w większym stopniu są raczej konfigurowane niż programowane. Inżynierowie produkcji lub technolodzy wykorzystują w ich organizacji pewną paletę urządzeń do wdrożenia określonych funkcji w gnieździe. Urządzenia te są dostarczane przez ich producentów wraz ze standardowymi programami i modelami. Tak więc fabryka nie musi być przywiązana tylko do jednego producenta. Systemy OPC UA składają się z urządzeń oraz istniejących modułów, takich jak programy do archiwizacji danych oraz HMI. Taki układ sprawia, że składanie gniazd produkcyjnych z różnych urządzeń jest łatwe i wymaga niewielkiej pracy z oprogramowaniem.

W systemie wykorzystującym standard OPC UA dane z gniazd produkcyjnych łączą się z danymi całego systemu poprzez zmiany wzorca komunikacji z pub/sub na klient/serwer (pytanie/odpowiedź, request/reply). Aby otrzymywać dane, aplikacja lub klient wyższego poziomu musi odkryć serwer i połączyć się z nim. Ta architektura nie jest zaprojektowana w celu umożliwienia programowania specjalistom z zakładów przemysłowych. Na przykład translacja pub/sub i klient/serwer prezentuje niekonsekwentny model programowania na różnych poziomach. Nie pozwala też wspomnianym specjalistom na wstępne definiowanie nowych interfejsów programowych lub udostępnianie typów danych. Bez nich OPC UA nie dostarcza jednego źródła „prawdy systemowej” dla oprogramowania działającego w całym systemie.

Standard OPC UA jest optymalny do integrowania urządzeń z gniazdem produkcyjnym, chociaż może być frustrujący dla informatyków próbujących napisać kompleksowe oprogramowanie dla całego systemu.

Tabela 1. Standardy DDS oraz OPC UA są niemal przeciwne. DDS jest szeroko wykorzystywany w tych gałęziach przemysłu, które wymagają zaawansowanego i rozproszonego oprogramowania. Natomiast OPC UA jest adresowany do przemysłu produkcyjnego, gdzie interoperacyjność urządzeń ma większe znaczenie. Funkcje CRUD (create, read, update and delete, utwórz, odczytaj, aktualizuj i usuń) są funkcjami 
relacyjnych baz danych.

DDS umożliwia tworzenie oprogramowania obejmującego cały system

DDS jest skierowana do pracowników działów tworzących aplikacje rozproszone. Pierwszą aplikacją DDS było sterowanie automatyczne inteligentnych robotów, przy wykorzystaniu sieci Ethernet. Następnie standard DDS rozprzestrzenił się na oparte w dużym stopniu na oprogramowaniu aplikacje rozproszone, takie jak obsługa pojazdów autonomicznych oraz zarządzanie systemem walki floty wojennej USA.

Jego podstawowym celem jest łączenie aplikacji programowych w celu uzyskania złożonego „systemu systemów” z jednym spójnym modelem. Większość systemów DDS łączy funkcjonalną sztuczną inteligencję z aplikacjami i urządzeniami w liczbie od 10 do 50. Jednak niektóre systemy DDS obejmują setki tysięcy urządzeń i aplikacji, które są pisane przez tysiące programistów.

Kluczem do zrozumienia DDS jest uświadomienie sobie, że systemy rozproszone mają z założenia architekturę równoległą, zaś architektura ta musi się dopasowywać do rzeczywistości. Nie jest to czymś nowym, sercem obecnie istniejących rozproszonych systemów sterowania (DCS) jest silnik realizacji sterowania, który zarządza odcinkami czasu i pętlami sterowania. System DCS dostarcza środowisko łączące bloki funkcyjne w równoległe, deterministyczne pętle sterowania w jednym opakowaniu.

DDS wykorzystuje tę samą koncepcję i dystrybuuje ją. Wdraża zorientowaną na dane i udostępnianą „globalną przestrzeń danych”. Oznacza to, że wszystkie dane pojawiają się tak, jak gdyby „żyły” wewnątrz każdego urządzenia i algorytmu. Jest to oczywiście iluzja – wszystkie dane nie mogą być wszędzie. DDS działa jednak śledząc, która aplikacja potrzebuje których danych i kiedy, a następnie dostarcza te dane. W wyniku tego dane aktualnie wymagane przez aplikację są dostarczane na czas do pamięci lokalnej.

Istotą oparcia na danych (data centricity) jest błyskawiczny lokalny dostęp do wszystkich potrzebnych danych przez każde urządzenie i każdy algorytm, na każdym poziomie, w ten sam sposób i w każdej chwili. Najlepiej wyobrazić sobie to jako rozproszoną pamięć współdzieloną, podobną do pamięci RAM w systemie DCS. Nie ma żadnych serwerów ani obiektów, ani specjalnych lokalizacji. Jest to równoległa architektura oprogramowania w całym systemie.

Standard DDS opiera się na danych, nie zaś na wzorcach. Podczas gdy większość standardów wykorzystuje model pub/sub, to DDS specyfikuje także zapytania/odpowiedzi, zaś oprogramowanie niektórych producentów obsługuje kolejkowanie. Aplikacje oddziałują na siebie na wiele sposobów, jednak tylko za pomocą współdzielonej pamięci rozproszonej, nie zaś bezpośrednio ze sobą. DDS ponadto definiuje interfejsy systemowe (typy danych) oraz sterowanie jakością usługi (quality of service – QoS) przepływu. Integruje moduły w transparentnej i spójnej architekturze obejmującej cały system, która jest niezależna od wzorców. Jest to usieciowienie analogiczne jak w przypadku zorientowanych na dane baz, wykorzystywanych do działalności przedsiębiorstwa.

Jednak DDS nie modeluje urządzeń. Inżynierowie i technicy w fabrykach nie mogą łączyć urządzeń w gniazda produkcyjne bez napisania kodu.

Systemy produkcyjne współzawodniczą ze sobą w ten sam sposób, w jaki czyniły to od dziesięcioleci: pod względem niezawodności, wydajności produkcji oraz kosztów wdrożenia. W niezbyt odległej przyszłości zdolni inżynierowie oprogramowania przemysłowego mogą opracować sposoby zastosowania technologii sztucznej inteligencji (AI), rozproszonego sterowania informacjami czy inteligentnej elastyczności. Aplikacje te wymagają zaawansowanego oprogramowania oraz podejścia obejmującego cały system. Jeśli uważamy, że oprogramowanie może być zakupione i pozostawać konkurencyjne, to nie musimy tego zmieniać. Jeśli jednak jest inaczej, dostrzegamy przyszłość, w której najlepsze oprogramowanie wygrywa, będziemy potrzebować innej drogi pozostawania na bieżąco z nowościami (rys. 2).

Rys 2. Platforma IICF (Industrial Internet Connectivity Framework, platforma oprogramowania dla Internetu przemysłowego), opracowana przez Konsorcjum Internetu Przemysłowego (Industrial Internet Consortium – IIC), realizuje najbardziej kompleksową analizę technologii połączeń sieciowych w przemyśle. Obejmuje ona szczegółowe oceny większości powszechnie wykorzystywanych technologii IIoT, w tym OPC UA oraz DDS. Ponadto oferuje architekturę systemu wykorzystującego wszystkie te technologie razem.

Może istnieć także potrzeba zbudowania systemu z urządzeń zapewniających interoperacyjność. Na szczęście nie musi to polegać na podjęciu jedynie słusznej i ostatecznej decyzji typu „wszystko albo nic”. Standardy DDS, OPC UA i TSN mogą współpracować ze sobą. Konsorcjum OMG, organizacja matka Konsorcjum Internetu Przemysłowego (IIC), niedawno zaaprobowała standard integracji DDS z OPC UA. Organizacje OMG i OPC Foundation pracują nad standardami wykorzystującymi sieci TSN wraz z DDS i OPC UA. Natomiast dostawcy DDS pracują nad narzędziami do łatwej konfiguracji.

Konsorcjum IIC opracowało architekturę zintegrowaną oraz posiada kilka platform testowych (testbeds), wykorzystujących standard OPC UA w aplikacjach produkcyjnych oraz standard DDS w elektroenergetyce i opiece zdrowotnej. Niektórzy wykorzystują OPC UA i DDS, takie jak platformy testowe konsorcjum IIC: Security Claims Evaluation (do testowania cyberbezpieczeństwa komponentów sieciowych) oraz Smart Factory Machine Learning for Predictive Maintenance (do testowania technologii uczenia maszynowego dla celów konserwacji prognozowanej w inteligentnej fabryce). Połączenie elastyczności urządzeń interoperacyjnych z posiadającym potężne możliwości środowiskiem deweloperskim oprogramowania nie jest już daleko przed nami.

Prawdziwym wyzwaniem pozostaje jednak pełne zrozumienie, w jaki sposób standardy OPC UA i DDS działają w zaawansowanych środowiskach produkcyjnych. Wiele osób ma trudność ze zdefiniowaniem tego, co realizują te technologie. Aby firma przemysłowa pozostała konkurencyjną w przyszłości, konieczne jest, by jej kierownictwo i specjaliści zbierali odpowiednie informacje i zadawali pytania w celu zapewnienia, że zostanie wybrana właściwa platforma lub właściwa kombinacja platform.


Dr Stan Schneider jest wiceprezesem Konsorcjum Internetu Przemysłowego (IIC, partnera CFE Media ds. treści) oraz dyrektorem generalnym (CEO) firmy Real Time Innovations (RTI).