Transkrypcja odcinka podcastu LUQAM. Odsłuchaj treść odcinka tutaj:

• Spreaker
• Spotify
• Apple Podcasts
• YouTube

IoT w fabryce – czym jest i jak je rozumieć?

Dzisiaj porozmawiamy o IoT w fabryce. Powiedz, czym właściwie jest IoT? Jak powinniśmy to rozumieć?

No właśnie – IoT. Dlaczego w ogóle o nim mówimy? Dlatego, że naszym głównym zagadnieniem są dane. Tylko pytanie brzmi: skąd je brać? I tutaj dochodzimy do koncepcji IoT, czyli Internet of Things. W kontekście Przemysłu 4.0 jest to pojęcie już trochę „oswojone”, a nawet – można powiedzieć – miejscami zdewaluowane.

W praktyce mówimy o koncepcji łączenia maszyn i czujników za pomocą różnych interfejsów w taki sposób, aby mogły się one ze sobą komunikować, wymieniać dane i – tam, gdzie to możliwe – w sposób automatyczny, a nawet autonomiczny, podejmować decyzje.

Czyli chcesz mi powiedzieć, że park maszynowy w firmach, który jest już dość leciwy i nie komunikuje się ze światem zewnętrznym, może nagle stać się „smart”?

W pewnym zakresie – tak. Oczywiście musimy uważać na poziom zaawansowania tego myślenia. Nawiążę tu do tego, o czym mówiliśmy wcześniej w kontekście „magiczności AI”. Sztuczna inteligencja nie zrobi wszystkiego za nas.

Jeżeli mamy starszy park maszynowy, który nadal dobrze wykonuje swoją pracę, to niekoniecznie będziemy go wynosić na najwyższy poziom komunikacji. Natomiast możemy w odpowiedni sposób podejść do zbierania danych z tego layoutu – niezależnie od tego, jak on wygląda – i wejść w posiadanie danych, które pozwolą nam optymalizować procesy.

Dane, sensory i integracja maszyn w różnych standardach

Czyli dane, które wcześniej były dla nas niedostępne albo bardzo trudne do identyfikacji, teraz – dzięki sensorom – możemy monitorować, mierzyć i wyciągać z nich konkretne wskaźniki

Dokładnie tak. W podejściu IoT mówimy o różnych typach interfejsów, które umożliwiają zbieranie danych. Mogą to być starsze połączenia szeregowe, Ethernet, USB, a w nowszych maszynach także WiFi.

Do tego dochodzą zewnętrzne sensory i infrastruktura pomiarowa. Dzięki temu nie uzależniamy się wyłącznie od wbudowanej infrastruktury produkcyjnej. Oznacza to, że możemy opomiarować park maszynowy zewnętrznym sprzętem, który zbiera dane i publikuje je do systemów analitycznych, umożliwiając realną optymalizację procesów.

W firmach mamy mieszankę maszyn – nowe, z wbudowanymi czujnikami, i starsze, ale wciąż sprawne. Czy zawsze musimy instalować zewnętrzne sensory, czy możemy korzystać z wbudowanych? Czy jesteśmy w stanie to jakoś połączyć?

To bardzo dobre pytanie. Kluczowe jest tutaj myślenie w kategoriach modelu biznesowego i celu, który chcemy osiągnąć.

Często okazuje się, że wykorzystanie wbudowanych interfejsów i mechanizmów udostępniania danych producenta maszyny jest droższe niż instalacja zewnętrznego sensora, który zbiera analogiczne dane, ale ma już gotowy pipeline do ich akwizycji i postprocessingu tych danych.

Nowoczesne maszyny generują ogromne ilości danych. Żeby wyciągnąć z nich tylko to, co istotne, bardzo często potrzebny jest inżynier, który dopasuje i przefiltruje strumień informacji. Trzeba więc zawsze zważyć, które podejście lepiej obsłuży nasz docelowy cel.

Jakość, ilość i różnorodność danych

Czyli znowu wracamy do celu – tak jak w poprzednim odcinku, do którego odsłuchania zachęcamy w pierwszej kolejności. Kluczowe jest to, że nie liczy się sama liczba sensorów IoT, ale przede wszystkim jakość pozyskiwanych danych.

Tak, chociaż dodałbym, że w praktyce znaczenie ma zarówno jakość, jak i ilość danych. Jakość danych bezpośrednio wpływa na jakość modelu. W systemach opartych o sztuczną inteligencję i uczenie maszynowe musimy pamiętać, że to dane uczą model, a nie kod. Kod odpowiada za architekturę modelu, oczywiście dopasowaną do typu zagadnienia, z którym pracujemy, natomiast w każdym przypadku to dane są absolutnie niezbędne.

Potrzebujemy danych historycznych, aby móc wytrenować dany model – niezależnie od tego, czy mówimy o klasycznych algorytmach uczenia maszynowego, czy już o sieciach neuronowych. Nie piszemy tu reguł ręcznie, tylko pozwalamy modelowi uczyć się na podstawie danych. W każdym z tych przypadków bez odpowiedniej ilości i jakości danych historycznych po prostu się nie obejdzie.

No tak, ale dochodzi tu jeszcze kwestia jasno określonego celu. Jeżeli naszym celem jest na przykład poprawa jakości produkcji, to będziemy skupiać się na takich danych, które realnie mogą nam w tym pomóc. Wtedy nie potrzebujemy innych sensorów, które monitorują parametry niezwiązane z tym celem. Wszystko zależy więc od tego, co chcemy osiągnąć na pierwszym etapie wdrożenia IoT w fabryce.

Tak, dokładnie. Natomiast niezależnie od tego, o jakim typie zagadnienia mówimy, warto mieć z tyłu głowy, że różnorodność danych pozwala uchwycić więcej zależności i odkryć więcej korelacji. Dzięki temu jesteśmy w stanie lepiej i dokładniej modelować proces, który nas interesuje, i wyciągać z danych realną wartość biznesową.

Od sensorów do realnej wartości biznesowej w fabryce

Słuchaj, mamy dziś dostępnych pewnie kilka, a nawet kilkanaście rodzajów sensorów IoT, które mogą mierzyć różne parametry pracy maszyny. Dla mnie jednak zawsze kluczowe jest spojrzenie na koniec tego procesu, czyli na to, jaką realną wartość daje to firmie. Gdy myślę o tym na starcie, pojawiają się takie obszary jak monitorowanie produkcji, statusów maszyn i tego, co faktycznie dzieje się na linii. Do tego dochodzi rozpoznawanie stanów pracy maszyny, kwestie jakościowe realizowane na przykład za pomocą kamer, a także analiza trendów. To są takie główne kierunki. Powiedz, gdzie Ty upatrujesz największych korzyści z instalacji tego typu sensorów?

W każdym z tych zagadnień, które wymieniłeś, trzeba mieć świadomość, że w praktyce mówimy o danych szeregów czasowych. W zależności od problemu dane powinny być zbierane z różną częstotliwością – czasem bardzo często, a czasem zdecydowanie rzadziej. Ma to znaczenie również z bardzo praktycznego powodu, bo przestrzeń dyskowa kosztuje.

Jeżeli chodzi o wartość biznesową, to moim zdaniem tę dyskusję należy zawsze uzależnić od charakteru przedsiębiorstwa i od tego, czym dana firma się zajmuje. W jednym przypadku sam charakter produkcji wymusi na nas zbieranie danych stosunkowo prostych, na przykład danych środowiskowych. Takie osensorowanie produkcji jest relatywnie łatwe do wdrożenia, a dodatkowo mamy tu do czynienia z dużą bezwładnością pomiaru – mówimy o temperaturze, ciśnieniu czy wilgotności. Oczywiście istnieją use case’y, w których wahania tych parametrów mogą być duże, ale w większości przypadków są to wartości zmieniające się wolno. Dzięki temu nie musimy zapychać przestrzeni dyskowej bardzo gęstymi pomiarami.

Z drugiej strony, jeżeli mówimy o przewidywaniu awaryjności, zużycia maszyn czy na przykład łożysk, to tutaj pojawia się zupełnie inna klasa sensorów. Dobrym przykładem są sensory wibracji oparte na akcelerometrach, które są stosunkowo łatwe w instalacji, ale w ich przypadku częstotliwość pomiaru ma już kluczowe znaczenie. Warto też zwrócić uwagę na to, że możemy analizować nie tylko surowe dane, ale również parametry pochodne względem wartości pierwotnych.

Wibracja jest tu dobrym przykładem. Sam pomiar przyspieszeń może być dostarczany bezpośrednio przez sensor lub wyliczany analitycznie. Natomiast wartość określana jako „wibracja”, czyli na przykład odchylenie średniokwadratowe przyspieszenia w każdej osi pomiarowej, jest już dla nas wartością pochodną, którą możemy skutecznie monitorować. Idąc krok dalej, możemy analizować także częstotliwości charakterystyczne, wyliczane na podstawie transformaty Fouriera i spektrum pomiarowego.

W tym momencie wchodzimy już w obszar bardziej zaawansowanej matematyki i inżynierii pomiarowej, która jednak służy bardzo prostemu celowi: monitorowaniu, czy dane łożysko nie zaczyna wchodzić w poziom wibracji świadczący o jego zużyciu. Kluczową rolę odgrywają tu również dane historyczne, zbierane przez sensor w dłuższym okresie. To one pozwalają przesuwać granicę momentu zatrzymania maszyny i wymiany komponentu jak najdalej w przyszłość.

I właśnie o takich realnych zyskach mówimy, niezależnie od tego, czy rozważamy pomiary środowiskowe, czy mechaniczne – zawsze w kontekście konkretnego celu biznesowego.

Instalacja sensorów i predykcja awarii

Fajnie, że wspomniałeś o przykładzie wykrywania i zapobiegania awariom, bo uchyliłeś tym samym rąbka technicznych aspektów, pokazując, że „pod spodem” naprawdę dużo się dzieje. Powiedz więc, jak to wygląda w praktyce. Załóżmy, że chcemy opomiarować jedną maszynę, z którą mamy problem pod względem awaryjności. Po analizie wiemy już, jakie sensory będą kluczowe, zamawiamy je i… co dalej?

Przy założeniu, że już zbieramy dane?

Nie, jeszcze tych danych nie zbieramy. Mamy paczkę sensorów i co dalej? Wiemy, że taka firma zewnętrzna jak na przykład LUQAM może to zrealizować. Sensory trzeba zainstalować, one muszą się komunikować z jakąś bazą danych, więc pojawia się pytanie: czy robi to zespół wewnętrzny, czy zewnętrzny? I co dzieje się w kolejnych krokach?

No właśnie, w tym momencie pojawia się wyzwanie integracji systemu pomiarowego z serwerem oraz z siecią wewnętrzną firmy. Kluczowe jest to, aby – nie ingerując w bieżącą produkcję – wdrożyć system pomiarowy. Co do zasady jest to możliwe i do tego właśnie bym zachęcał, szczególnie wtedy, gdy instalujemy zewnętrzne systemy pomiarowe.

Oczywiście, jeżeli mówimy o instalacji czujników wibracji, to w pewnym momencie musimy wykonać fizyczną ingerencję w dane stanowisko. Natomiast w ogólnym rozrachunku instalacja i wdrożenie systemu mogą być przeprowadzone niezależnie od bieżącej produkcji, co jest bardzo istotne i nie powinno być barierą.

Dalej pojawia się kwestia zbierania i przechowywania danych. Niezależnie od tego, czy uznamy dane produkcyjne za wrażliwe, czy nie – co często jest też kwestią subiektywnego podejścia firmy – musimy zdecydować, gdzie te dane będą trafiać. Czy chcemy przechowywać je na wewnętrznym serwerze i udostępniać naszym analitykom odpowiedni dostęp? Czy integrujemy system akwizycji danych z dedykowanym serwerem systemu pomiarowego? A może sensory komunikują się bezpośrednio z zewnętrzną chmurą, do której publikują dane?

Możliwych scenariuszy jest kilka. Często spotykanym rozwiązaniem jest lokalny serwer lub host, który komunikuje się z sensorami – radiowo lub przez WiFi – z różnych stanowisk produkcyjnych, a dane są kumulowane lokalnie. W kolejnym kroku taka lokalna baza danych może być synchronizowana z serwerem firmowym lub zewnętrznym serwerem w chmurze. Wszystko zależy od polityki danych w organizacji, od tego, kto ma mieć dostęp do danych i w jaki sposób.

Załóżmy więc, że sensory są już zainstalowane i zdefiniowaliśmy bazę danych. Czy to oznacza, że następnego dnia system i sensory zaczną wykrywać i zapobiegać awariom?

Na pewno będą stwarzać pole do analizy.

Czyli chcesz powiedzieć, że nie?

To, czy system będzie przewidywał awarie, zależy od zdarzeń, które zdążyliśmy zebrać w określonym oknie czasowym. I tutaj dochodzimy do bardzo ważnej kwestii: nie chodzi o samo posiadanie danych, ale o posiadanie ciekawych danych. Co to oznacza w praktyce? Ciekawe dane to takie, w których dużo się dzieje – pojawiają się zdarzenia krytyczne, ale jednocześnie takie, które są w stanie nauczyć model reagowania na konkretne sytuacje.

Jeżeli w danych historycznych nie mamy zdarzeń, które chcemy przewidywać, to nie mamy na czym trenować modelu. Dlatego warto to powtórzyć: nie wystarczy samo zbieranie danych – musimy mieć dostęp do danych, w których występują zdarzenia dla nas istotne.

I jaki jest tutaj przedział czasowy? Ile trwa taka nauka?

To ponownie zależy od tego, jak często występują interesujące nas zdarzenia. Jeżeli dane zdarzenie pojawia się kilka razy na godzinę, to dwa dni zbierania danych mogą już wystarczyć. Natomiast jeżeli mówimy o procesach takich jak stopniowe zużywanie się maszyny, które trwają na przykład dwa dni i objawiają się systematycznym zaburzaniem mierzonego spektrum – na przykład spektrum wibracji – to sytuacja wygląda inaczej.

Nie mówimy tu o pojedynczych odchyłkach, ale o regularnej, okresowej zmianie trendu. W ciągu dwóch dni zbierania danych mamy wtedy jeden taki okres zmian. Aby móc cokolwiek sensownie modelować, potrzebujemy zebrać co najmniej kilka, a najlepiej kilkanaście takich trendów, które odzwierciedlają rzeczywiste zachowanie maszyny.

Czy system IoT uczy się sam? Rola człowieka, danych i ryzyka w projektach AI

Powiedz, czy taki system będzie w stanie nauczyć się wszystkiego sam, czy jednak potrzebuje wsparcia operatora? Na przykład operator, korzystając z tabletu skonfigurowanego do komunikacji z sensorem, mógłby wprowadzać informacje o typie awarii, tak aby system rozumiał, z jakim zdarzeniem ma do czynienia. Czy system jest w stanie sam sobie to zdefiniować?

W pewnym sensie, Arku, poruszyłeś tutaj to „magiczne” podejście do sztucznej inteligencji. Nic nie definiuje się samo. Ostatecznie to my, jako ludzie, musimy obserwować rzeczywistość i ją nazywać w sposób zrozumiały dla modelu. To my jesteśmy odpowiedzialni za to, aby dany zakres wartości sklasyfikować jako określony typ zagadnienia. Wynika to z naszych obserwacji – czy to operatorów, czy inżynierów uczenia maszynowego – którzy później przekładają to na postać modelu, który ma zostać wdrożony.

Jeżeli założymy, że nasz projekt wygląda tak, jak dotychczas opisywaliśmy, to po jakim czasie model będzie w stanie faktycznie coś przewidywać?

To znowu zależy od skali wdrożenia, nawet jeśli mówimy tylko o proof of concept. Jeżeli zagadnienie będzie stosunkowo wąskie – czyli chcemy klasyfikować jedno lub kilka zdarzeń, które nas interesują pod kątem przewidywania ich wystąpienia – i zbierzemy odpowiednią ilość danych zawierających te zdarzenia, to stworzenie takiego modelu jest kwestią około tygodnia. Mówimy tu o zebraniu danych, ich zamodelowaniu i wytrenowaniu modelu.

Ilość danych ma tu ogromne znaczenie. Im więcej danych, tym model będzie dokładniejszy i bardziej pewny swoich predykcji. Jednocześnie nic nie stoi na przeszkodzie, aby trenować model na danych, które już posiadamy, a następnie go stopniowo dotrenowywać. Każdy kolejny dzień akwizycji danych, w których występują interesujące nas zdarzenia, ma znaczenie. Co pewien czas model może być ponownie trenowany – mówimy wtedy o fine tuningu, czyli douczaniu modelu na podstawie nowo zebranych danych.

Ja widzę tu spore korzyści i sam chciałbym monitorować wszystko, co się da, ale zapytam wprost: czy są jakieś zagrożenia? Jeżeli robimy to przy użyciu zewnętrznego systemu, bez głębokiej ingerencji w park maszynowy i infrastrukturę, to wydaje się, że jest bezpiecznie. Jakie inne ryzyka byś tu wskazał? Poza tym, że możemy przepalić trochę budżetu na sensory, które nie będą nam służyć albo nie wykryją tego, czego od nich oczekujemy, trudno mi wskazać coś więcej.

Z perspektywy kosztowej warto zauważyć, że instalacja sensorów i zbieranie danych, o ile tylko mamy taką możliwość, jest dziś relatywnie tańsze niż praca inżyniera danych czy inżyniera uczenia maszynowego, który miałby wypracować konkretne rozwiązanie. Każde takie zastosowanie jest bowiem unikalne. To nie jest produkt z półki, który instalujemy jak czarną skrzynkę i wszystko zaczyna działać.

Dlatego każdy projekt oparty o sztuczną inteligencję należy traktować jako projekt badawczo-rozwojowy (R&D). Zawsze istnieje ryzyko, że coś nie wyjdzie – nie wiemy z góry, jaką jakość danych zbierzemy, czy dany parametr faktycznie będzie odzwierciedlał charakterystykę interesującego nas zdarzenia. Bardzo często konieczne jest podejście iteracyjne, w którym kilka razy zmieniamy kierunek, testujemy różne koncepcje i próbujemy uchwycić fragment rzeczywistości w taki sposób, aby dało się go sensownie zamodelować.

Jeżeli chodzi o ryzyka, to najczęściej są one związane z nieodpowiednim sparametryzowaniem przestrzeni pomiarowej. Natomiast po stronie samych technologii – architektur uczenia maszynowego czy uczenia głębokiego – mamy dziś na tyle rozwinięte narzędzia, że zazwyczaj da się dobrać odpowiednie podejście do modelowania. W wielu przypadkach do prognozowania wystarczy nawet zwykła regresja liniowa – nie zawsze potrzebujemy sięgać po sieci neuronowe do modelowania prostych trendów.

Ryzyko może natomiast pojawić się na etapie integracji wypracowanego rozwiązania z infrastrukturą IT firmy – w kontekście polityki danych, dostępu do systemów czy cyberbezpieczeństwa. Ale to traktowałbym jako kolejny etap, wykraczający poza proof of concept. Na etapie POC samo przetestowanie i wypracowanie rozwiązania nie niesie ze sobą dużego ryzyka.

A co w sytuacji, gdy opomiarujemy wszystkie maszyny i – mówiąc kolokwialnie – zalejemy je sensorami? Czy istnieje ryzyko, że coś się „wysypie”, jak przy głośnej awarii aktualizacji Microsoftu, która uziemiła setki firm i instytucji? Czy może dojść do zatrzymania produkcji?

Jeżeli bazujemy na zewnętrznym systemie, który nie ingeruje w interfejsy maszyn, to jest to rozwiązanie bezpieczne. Co może się stać? Możemy mieć przerwę w danych – pół dnia, dzień – ale nie zatrzymamy produkcji. To jest kluczowa zaleta podejścia typu read only, bez ingerencji w proces technologiczny.

Oczywiście każda technologia ma swoje ograniczenia. Jeżeli korzystamy z komunikacji radiowej lub WiFi, to przepustowość pasma jest ograniczona. W pewnym momencie możemy dojść do jego saturacji, co może skutkować przekłamaniami danych albo brakiem możliwości ich zbierania. Dlatego liczba sensorów i architektura komunikacji zawsze muszą być dopasowane do wybranej technologii.

Czyli w praktyce większą wagę musimy przykładać do systemów takich jak ERP czy MES, bez których trudno byłoby w ogóle prowadzić produkcję. W przypadku zewnętrznych systemów IoT mamy większą elastyczność – odczytujemy status, monitorujemy proces i na tej podstawie prowadzimy analizy oraz optymalizację.

Dokładnie tak. Co więcej, jeżeli systemy ERP lub MES są już wdrożone, to bardzo często warto integrować dane z sensorów z danymi pochodzącymi właśnie z tych systemów, w celu szukania korelacji i lepszego zrozumienia zdarzeń. Trzeba jednak pamiętać o jednej rzeczy: częstotliwości akwizycji danych.

Analizujemy trendy zawsze z dokładnością do najwolniejszego pomiaru. Jeżeli z systemu MES dane są zapisywane co minutę lub co pięć minut, to nawet jeśli sensory dostarczają dane co piętnaście sekund, będziemy musieli je uśredniać lub agregować, aby dopasować się do rzadszego strumienia danych. To bardzo ważny aspekt, o którym często się zapomina przy projektowaniu takich systemów.

Czy każda maszyna musi być smart?

Myślę, że zbliżamy się już do końca. Temat IoT w przemyśle jest bardzo szeroki i moglibyśmy o nim rozmawiać jeszcze długo, ale na zakończenie powiedz, Bartku – czy każda maszyna musi być smart?

Moim zdaniem nie. To jest przede wszystkim kwestia odpowiedzialnego podejścia do technologii. Nie wszystko musimy robić w sposób „inteligentny” tylko dlatego, że technologia na to pozwala. Bardzo często po prostu nam się to nie opłaca. Nakład środków, które musimy ponieść, aby najpierw zbierać dane, a później je odpowiednio przetwarzać i wykorzystywać do optymalizacji pracy maszyny, może być nieadekwatny do potencjalnych korzyści.

Może się okazać, że obecny sposób działania maszyny i sposób zarządzania procesem są wystarczające i nie wymagają dodatkowego osensorowania. Dlatego zawsze jest to sprawa indywidualna – trzeba to przeliczyć, przeskalować i spojrzeć na to przez pryzmat konkretnego przypadku.

Czyli zachęcamy do instalacji smart sensorów, aby uczynić park maszynowy bardziej inteligentnym, ale niekoniecznie na każdej maszynie?

Tak, dokładnie. I to jest znowu problem wielowymiarowy. Z jednej strony pytanie brzmi, czy dana maszyna musi być smart, ale z drugiej strony nie zawsze powinniśmy patrzeć na nią wyłącznie z perspektywy jej własnego procesu. W kontekście zarządzania całym parkiem maszynowym, liczenia wskaźników produktywności czy analizowania przepływu produkcji, może się okazać, że instalujemy sensory na konkretnym stanowisku nie po to, aby optymalizować jedną maszynę, ale po to, aby uchwycić szerszy obraz produkcji jako całości.

I wtedy kluczowe staje się to, aby system był skalowalny i nie stanowił dla nas ograniczenia w dalszym rozwoju.

Dokładnie tak, zgadzam się.