Integrowanie technologii Przemysłowego Internetu Rzeczy (ang. Industrial Internet of Things, IIoT) z tradycyjnymi informatycznymi systemami nadzorowania procesów produkcyjnych i technologicznych SCADA (ang. supervisory control and data acquisition) oraz interfejsami operatorskimi HMI (ang. human-machine interfaces), przynosi firmom z branży przemysłowej wiele korzyści.
Zwiększona skalowalność wynika z bezpiecznego dostępu do wielu lokalizacji za pośrednictwem platform wykorzystujących technologię chmury obliczeniowej, między innymi Microsoft Azure. Dzięki nim można złagodzić wpływ trudności wynikających z posiadania przestarzałego sprzętu w fabrykach, ponieważ skomplikowane obliczenia i procedury związane z analizowaniem wielkich ilości danych, intensywnie obciążające procesory sprzętu w zakładzie, mogą być przerzucona do serwerów w chmurze. Sama zaś infrastruktura sieciowa i skomunikowanie w zakładzie zostaje zwiększone, ponieważ coraz większa liczba urządzeń komunikuje się ze sobą za pomocą protokołów sieciowych technologii IIoT.
Jednak bez możliwości połączenia z urządzeniami znajdującymi się poza firewallami i bezpiecznego publikowania danych dla aplikacji zintegrowanych z IIoT, organizacje mogą stracić okazję do wykorzystania możliwości zaawansowanej analityki danych, opartej o technologię chmury. Jeśli organizacja rozważa wdrożenie jakiejś strategii integracji technologii IIoT, to odpowiadając sobie na zaproponowane w tym artykule pytania, uzyska ważne informacje na temat niektórych najlepszych praktyk takiej integracji.
1. Czy organizacja posiada już sprzęt gotowy do wykorzystania technologii Internetu Rzeczy (IoT) i chmury obliczeniowej?
Niektóre organizacje planowały już wcześniej przystosowanie się do nowej technologii IIoT dążąc do tego, by układy elektroniczne maszyn oraz urządzenia cyfrowe w zakładach produkcyjnych były zdolne do przesyłania danych do wybranej usługi w chmurze. Na przykład pewien producent zmodernizował maszyny montażowe, wyposażając je w urządzenia umożliwiające bardziej zaawansowaną pracę i komunikację w sieci. Takie podejście sprawdza się w firmach, które mogą pozwolić sobie na modernizację i dostosowanie wyposażenia sprzętowego, jednak może nie być to najbardziej opłacalne rozwiązanie w kierunku zapewnienia możliwości pracy w sieci IIoT.
Istniejące w przemyśle starsze maszyny mogą być podłączone do infrastruktury IIoT. Jednak niektóre opcje wyposażania tych maszyn w sprzęt sieciowy często okazują się zbyt kosztowne w porównaniu do innych rozwiązań. Tu właśnie pojawia się koncepcja wykorzystania bram sieciowych IoT (moduły tzw. gateway’ów).
Bramy sieciowe IoT to małe i lekkie urządzenia, które działają jak mosty pomiędzy fabrycznymi sieciami komunikacyjnymi a usługami w chmurze. Ich koszt jest niewielki w porównaniu z kosztem wyposażenia maszyn w dedykowane urządzenia sieciowe. Te bramy pracujące na krawędzi sieci realizują przesył danych zarówno do i z urządzeń końcowych rozmieszczonych w fabryce, jak i do infrastruktury skomunikowanej w chmurze.
Bramy sieciowe IoT spełniają ścisłe wymagania dotyczące cyberbezpieczeństwa. Służą one jako mechanizmy pośredniczące w przysyłaniu danych generowanych i przechowywanych w fabryce oraz udostępnianych na zewnątrz zakładu. Firma Intel za pomocą swojego programu IoT Solutions Alliance wspiera producentów typu ODM (ang. original-design manufacturers, przedsiębiorstwa, których produkty ostatecznie będą nosiły logo innych firm) oferując zaawansowane funkcje dla zapewnienia cyberbezpieczeństwa takie jak: unikalne identyfikatory sprzętu, bezpieczne uruchamianie systemu, białe listy oraz wyłączanie wybranych portów urządzeń, takich jak USB czy szeregowych. Zarządzanie urządzeniami brzegowymi w sieciach jest równie ważne przy rozważaniu wykorzystania bram sieciowych IoT, ponieważ wymagają one zdalnego zarządzania przez Internet i są zarejestrowane w preferowanej usłudze w chmurze.
Wymagana konfiguracja zabezpieczeń oraz inne funkcje są zawarte w sprzętowych bramach IoT i zintegrowane z kompleksowymi rozwiązaniami oprogramowania IoT.
2. Czy firma posiada już preferowanego dostawcę usług w chmurze?
Decyzje dotyczące preferowanych dostawców usług w chmurze być może zostały podjęte w organizacji na podstawie preferencji dotyczących zarówno komputerów, serwerów i systemów operacyjnych, jak i sieciowych protokołów komunikacyjnych oraz innych czynników. Wielu użytkowników w przemyśle wykorzystuje platformę Microsoft Azure, podczas gdy inni Amazon Web Services (AWS) lub Google Cloud Platform.
Organizacje, które jeszcze nie dokonały wyboru dostawcy usług w chmurze, powinny uzyskać i przeanalizować odpowiedzi na następujące pytania:
- Jaka jest struktura cenowa usług? Czy jest łatwa do zrozumienia bez możliwych ukrytych opłat?
- Jaka jest porównywalna moc obliczeniowa? Ile węzłów obliczeniowych jest dostępnych w dowolnej danej chwili czasu? Jaki jest oferowany typ integracji baz danych – SQL czy inny? Jakie typy integracji sieci są zwarte w usługach – równoważenie obciążenia, DNS, VPN czy inne?
- Jakie są ograniczenia wielkości przechowywanych danych? Jakie są możliwości i ceny archiwizacji, tak zwanego przechowywania zamrożonych danych (ang. “cold storage”)?
- Gdzie są zlokalizowane centra danych? Jaki jest spodziewany czas opóźnienia przesyłu (latencja) spowodowany odległością? Jak wpłynie on na użytkownika podłączonego do chmury?
Równie ważna jest jakość współpracy dostawcy usług w chmurze z istniejącymi lub planowanymi urządzeniami i rozwiązaniami oprogramowania IoT. Może tu pomóc wybór takich rozwiązań, które obejmują standardy otwarte. Zapewnienie natychmiastowej interoperacyjności jest ważnym pierwszym krokiem w najlepszych praktykach wykorzystania technologii chmury obliczeniowej w przemyśle.
3. Czy organizacja preferuje specyficzne protokoły komunikacyjne, zarówno do użytku wewnętrznego, jak i oparte na mechanizmie publikacji/subskrypcji?
W ważnych gałęziach przemysłu komunikacja na poziomie obiektowym pomiędzy maszynami znajdującymi się w fabryce a sieciami z usługami w chmurze, obejmuje pewną liczbę protokołów przemysłowych, w tym:
OPC Classic. Są to specyfikacje opracowane przez konsorcjum przemysłowe Fundacja OPC, oparte na technologii Microsoft Windows oraz wykorzystujące interfejs COM/DCOM (Distributed Component Object Model, interfejs programistyczny realizujący rozproszony obiektowy model składników) do wymiany danych pomiędzy komponentami oprogramowania. Specyfikacje te obejmują dostęp do danych (ang. data access, DA) w czasie rzeczywistym, dostęp do danych historycznych (ang. historical data access, HDA), alarmy i zdarzenia (ang. alarms and events, A/E), dostęp do danych XML (ang. XML data access, XML-DA), wymianę danych (ang. data exchange, DX), obsługę złożonych typów danych, cyberbezpieczeństwo i przetwarzanie wsadowe.
OPC UA (OPC Unified Architecture). Jest to otwarty standard wymiany informacji w obiektowo zorientowany i bezpieczny sposób, obejmujący bogaty zbiór usług. Dostarcza on niezależne od platformy środki do mapowania i wymiany informacji w czasie rzeczywistym, jednak nie definiuje konkretnych dostępów do danych procesów tylko format wymaganych danych, jednocześnie pozostając kompatybilnym ze specyfikacją OPC Classic.
Modbus. Jest to otwarty protokół komunikacyjny, powszechnie używany przez wielu producentów z różnych gałęzi przemysłu. Protokół ten może obejmować zarówno porty szeregowe (Modbus RTU i Modbus ASCII) jak i Ethernet (Modbus TCP).
SNMP (Simple Network Management Protocol). Jest to prosty protokół do zarządzania urządzeniami za pomocą sieci. Umożliwia on urządzeniom podłączonym do sieci wymianę użytecznych informacji. Prawie wszystkie tradycyjne urządzenia informatyczne mogą obsługiwać żądania SNMP.
BACnet. Jest to otwarty standard komunikacyjny, najczęściej stosowany przez producentów automatyki budynkowej. Niektóre organizacje mogą wykorzystywać własne metody komunikacyjne albo w połączeniu z jednym ze standardowych protokołów przemysłowych lub tylko samodzielnie.
Komunikacja z urządzeniami zewnętrznymi, wyższego poziomu, obejmuje dodatkowe protokoły, ze względu na potrzebę zapewnienia wysokiego poziomu bezpieczeństwa danych oraz często wykorzystuje mechanizmy wymiany danych publikacja/subskrypcja (“pub/sub”). Protokoły te to:
AMQP (Advanced Message Queuing Protocol). Jest to otwarty standard protokołu warstwy aplikacji dla oprogramowania pośredniczącego. Zapewnia on komunikację zorientowaną na przetwarzanie komunikatów ze sterowaniem przepływem danych oraz posiada wbudowane opcje gwarantowania dostarczania komunikatów. Uwierzytelnianie i szyfrowanie danych jest oparte na popularnych w sieci Internet protokołach uwierzytelniania oraz protokołach zabezpieczania danych, takich jak SASL (Simple Authentication and Security Layer, warstwa uwierzytelniania użytkownika i zabezpieczania danych ) i TLS (Transport Layer Security, bezpieczeństwo warstwy transportowej). Protokół AMQP, zoptymalizowany dla przesyłania komunikatów pomiędzy urządzeniami, obsługuje funkcjonalność odczytu i zapisu do zarządzania i kontroli lub urządzenia automatyki przemysłowej.
MQTT (Message Queuing Telemetry Transport). Jest to oparty o wzorzec publikacja/subskrypcja, ekstremalnie prosty, lekki protokół transmisji danych. Został on opracowany dla środowisk SCADA oraz związanych z nimi sieci. Wykorzystuje wzorzec pub/sub do zminimalizowania fragmentów przesyłanych danych, będących formą wiadomości (ang payloads) oraz ogólnie specyficzne dla aplikacji, dostosowane przez użytkownika formaty JSON (JavaScript Object Notation, formaty tekstowe bazujące na podzbiorze języka JavaScript) lub binarne. Powszechnie zaakceptowany przez działy informatyki w firmach na całym świecie, protokół MQTT oferuje wiele przykładów otwartego kodu źródłowego, opracowanego w wielu popularnych językach programowania. MQTT jest zalecany do stosowania, gdy przepustowość sieci jest zbyt mała i powinien być zawsze wykorzystywany w połączeniu z bezpieczną metodą komunikacji, taką jak TLS.
HTTPS (Hypertext Transfer Protocol Secure). Jest to szyfrowana wersja protokołu HTTP, zaprojektowana do obsługi żądań i odpowiedzi w modelu przetwarzania danych dla komunikacji na stronach internetowych. HTTPS pozwala na łatwiejsze pokonywanie zabezpieczeń typu firewall, bez potrzeby stosowania specyficznych polityk bezpieczeństwa informacji, które obsługują komunikaty z żądaniami wysyłane na serwer i odpowiedzi zwrotne w formie zasobów, takich jak pliki HTML oraz szczegóły dotyczące treści i statusu zakończenia operacji.
REST (Representational State Transfer)/JSON. Jest to protokół bezstanowy, przeznaczony do przyjaznego dla Internetu Rzeczy (IoT) dostępu do informacji. Wykorzystuje on protokół transportowy HTTP do dostarczania danych zwykle wykorzystujących JSON, który jest elastycznym i lekkim formatem takim jak XML, do zdefiniowania swojej prezentacji.
Rozważając specyfikację sprzętu do obsługi technologii IIoT oraz towarzyszące mu rozwiązania w obszarze oprogramowania należy wziąć pod uwagę wymagania organizacji dotyczące zarówno komunikacji poziomu stricte obiektowego – między urządzeniami, jak i wymiany danych z urządzeniami usługami w chmurze – komunikacja wyższego poziomu.
4. Czas na kolejne pytanie: „Jakie dodatkowe funkcje są wymagane dla rozwiązania przemysłowego, opartego o technologię chmury?”
W tym punkcie organizacja może już wiedzieć, jaki sprzęt jest potrzebny do połączenia jej zasobów elektronicznych z chmurą, kto będzie preferowanym dostawcą usług w chmurze oraz jakie protokoły komunikacyjne są uważane za najważniejsze.
Połączenie z chmurą początkowo mogło być rozważane jako środek do zabezpieczenia zwiększonej skalowalności, z zagwarantowanym cyberbezpieczeństwem, zredukowanym ryzykiem starzenia się sprzętu i rozszerzonym usieciowieniem. Dodatkowa wartość może być uzyskana za pomocą połączeń w sieci IIoT. Obejmują one aplikacje wykorzystujące połączenia sieciowe, udostępniane przez dostawcę usług w chmurze, które przesyłają dane klienta na krawędź sieci zakładowej i wykorzystują je do wizualizacji lub analizy na urządzeniach mobilnych. Przykładami są tu: zarządzanie energią, wykrywanie i diagnostyka awarii, błyskawiczny zapis i odczyt danych historycznych oraz inne zastosowania.
Niektóre rozwiązania programowe bram sieciowych IoT realizują płynną integrację tych typów aplikacji. Dostępne na rynku od ręki interfejsy SCADA i innego typu oraz programy do analizy i archiwizacji danych, mogą łączyć się z dostawcą usług w chmurze subskrybując usługę „Centrum IoT” (“IoT Hub”), skąd aplikacje te mogą przyjmować dostarczane dane. Jednym z możliwych przypadków użycia jest monitoring zużycia energii, w którym oprogramowanie bramy sieciowej IoT, uruchomione na typowej sprzętowej bramie sieciowej IoT, może łączyć się z popularnymi miernikami (licznikami) zużycia energii elektrycznej, gazu czy wody, w celu bezpiecznego monitoringu infrastruktury w czasie rzeczywistym oraz analizy tych danych w definiowanych okresach czasu. Innym przypadkiem użycia jest innowacyjne wykrywanie i diagnostyka awarii, w której pakiet oprogramowania IoT może alarmować odpowiedni personel techniczny, co zapobiega uszkodzeniom sprzętu lub nadmiernemu zużyciu energii.
Opcje przetwarzania danych w oparciu o technologię chmury, podobnie jak inne pojawiające się nowe technologie, będą nadal ewoluować. Połączony ze sobą sprzęt zintegrowany z siecią IIoT i odpowiednie rozwiązanie oprogramowania dostarczają wartość w formie monitoringu sprzętu, konserwacji predykcyjnej oraz efektywności operacyjnej. Zrozumienie i wykorzystanie proponowanych w artykule najlepszych praktyk może doprowadzić do podjęcia bardziej świadomej decyzji, dotyczącej wszelkich planów integracji organizacji z chmurą obliczeniową.
Autorka: Melissa Topp jest starszym dyrektorem marketingu globalnego w firmie Iconics.