Przemysł 4.0: Zbieranie danych na przykładzie obrabiarki część 2/2

160

Wstęp W poprzedniej części opisałem sposób podejścia do monitorowania obrabiarek pod kątem dobrania czujników i zdefiniowania obszarów, które są dla nas najbardziej istotne. Poniższy opis pisałem z myślą o obrabiarkach, lecz wtrąciłem również parę przykładów z innych maszyn.

W projektach często posiłkuję się specjalistami z różnych dziedziń: wibrodiagnostyki, mechaniki, hydrauliki, elektryki, automatyki, informatyki. Nie potrzebuję angażować ich na pełen etat do danego zagadnienia ile tylko uzyskać potwierdzenie, poradę, że tego typu rozwiązanie na tej konkretnej maszynie jest prawidłowe. Tutaj cenię sobie wsparcie osób z ifm electronic, gdyż do każdej grupy produktowej jest przydzielony przynajmniej jeden specjalista, a znam wiele przypadków, że poprzez niewłaściwe zamontowanie czujnika (zły dobór albo nieprawidłową parametryzację) otrzymywane dane były bezużyteczne.

W momencie gdy już wykonamy montaż czujników na maszynie pojawia się kolejne wyzwanie: w jaki sposób dane z czujnika analizować albo co istotniejsze w jaki sposób mogę się przekonać, że te parametry są rzeczywiście istotne i w jaki sposób powinienem reagować na to co się dzieje? Za każdym razem jak się przymierzamy z klientem do tematu monitorowania to owszem muszą zaistnieć pewne podstawy do tego, że warto to robić (patrz cześć pierwsza) niemniej wymagane jest potwierdzenie, że tak się naprawdę się dzieje. Dlaczego? Ponieważ ja mogę posiłkować się doświadczeniami z podobnej aplikacji (może nawet takiej samej) niemniej nigdy nie dam sto procent pewności, że to rozwiązanie w tym szczególnym otoczeniu zadziała tak samo. Wpływ na ten stan rzeczy ma nie tylko sposób budowy maszyny ale również jej otoczenie. Inaczej należy podejść do maszyny pracującej w strefie aseptycznej (np. rotoklaw), inaczej maszynie pracującej w chłodni, czy normalnej hali. W przypadku stosowania wibrodiagnostyki również należy wziąść pod uwagę pracę maszyn stojących obok lub przejeżdżających pojazdów (jak wózki widłowe) mogących generować drgania. Uff kto mówił, że będzie łatwo…

Jeden z innych przykładów jaki przychodzi mi na myśl to monitorowanie przepływu czynnika chłodzącego za pomocą mechatronicznych przepływomierzy (z IO-Link – symbol SBY246), które zastąpiły kryzy (optyczna metoda sprawdzania). Powód zmiany był następujący: kryzy “lubiły” się czasem przyblokować (mimo wszystko ciecz chłodząca w tym wypadku borygo nie jest idealnie czysta a warunki sprzyjają rozwojowi grzybów, bakterii czy pojawianiu się innych zanieczyszczeń). Przepływ głównie spada z tego względu, że blokują się kanały chłodnicze na maszynie, jeśli nie zostanie to w porę zauważone to maszyna zaczyna produkować odpad i może trwać to nawet całą zmianę! Na samym początku też były wątpliwości czy czujniki przepływu SBY246 się sprawdzą ale istniały pozytywne przesłanki do tego, że tak (obecnie pracują pół roku bez zarzutu).

Takich przykładów mamy całkiem sporą ilość. Wspomniany przepływ to tylko jeden z wielu istotnych parametrów maszyny.

1. Żródła danych

Obrabiarka może się składać z kilkunastu różnych podzespołów, które są ze sobą powiązane i ich stan będzie wpływał na funkcjonowanie maszyny oraz co istotniejsze na jakość, szybkość i efektywność produkowanych elementów. Poprzez odpowiedni dobór czujnikówmożemy mieć te informacje w postaci cyfrowej.

Dane mogą pochodzić również z innych urządzeń jak sterowniki PLC, regulatory, urządzenia mierzące pobór energii elektrycznej i inne. Każdy z nich jest wyposażony w inny protokół komunikacyjny co powoduje dodatkowe implikacje.

Brak alternatywnego tekstu dla tego zdjęcia

Sterownik maszyny też jest dobrym źródłem danych (przykład DB z Sinumerik)

Stąd też w przypadku projektowania systemu do zbierania danych dobrze jest określić bazowe wymagania, jak np:

  1. zdolność do komunikacji z różnymi systemami, protokołami (często spotykane słowo w opracowaniach na temat Industry 4.0: “connectivity” – czyli łączność), przykładem może być zdolność odczytu danych z różnych źródeł jak sterowniki PLC Siemens, Beckhoff, Schneider, czujniki, odczyt danych z modułów drganiowych czy pomiaru energii elektrycznej,
  2. skalowalność – otwarta struktura zapewniająca łatwe dopinanie kolejnych elementów (np. dzisiaj potrzebujemy monitorować wrzeciono, jutro zużycie powietrza, pojutrze energię elektryczną itd.).

Zauważyłem, że niektóre firmy zaczynają zbierać dane czy też udostępniać dalej ale jeszcze nie z zamiarem ich używania, przynajmniej nie teraz. Jest to interesujące podejście gdyż firmy specjalizujące się w uczeniu maszynowym potrzebują masę danych historycznych.

2. Zbieranie danych

Przypuśćmy, że na początku wybierzemy sobie diagnostykę wrzeciona za pomocą wibrodiagnostyki, w zależności od tego co będziemy monitorować możemy mieć 4 istotne obiekty lub więcej (vRMS, aRMS, aPeak, ogólny poziom drgań itd.), po czasie dojdzie potrzeba monitorowania ciśnienia na chytaku, do tego temperatura silnika pompy, łożyska pompy plus niewyważenie, poziom oleju, ciśnienie oleju, temperatura oleju, przepływ… i się szybko okaże, że jedna maszyna generuje nam kilkadziesiąd istotnych parametrów. Ktoś się zapyta, który z tych parametrów jest istotny. Odpowiedź jest prosta: każdy..

Brak alternatywnego tekstu dla tego zdjęcia

iPhone w 2007r. zmienił sposób korzystania ze smartfonów – informacje zawsze pod ręką. Czy możemy w ten sam sposób podejść do monitorowania maszyn?

Firmy mają bardzo wiele systemów już poinstalowanych czy to na samych maszynach czy w sterowni, stąd też pojawia się pytanie “po co nam kolejny?”. Wszystko zależy od zdefiniowanych wcześniej celów, jeśli dodatkowy czujnik sprawdzi się w istniejącym systemie to czemu nie.

Natomiast jest jedna bardzo istotna zmiana, która powoli materializuje się na naszych oczach: firmy dostrzegają potrzebę posiadania systemu/rozwiązania, który jest w stanie zapewnić aktualne informacje o tym w jakim stanie są maszyny oraz co należy zrobić dalej czyli jakie maszyny powinny być serwisowane w pierszej kolejności i nie chodzi tutaj o kolejną tabelkę excel, tylko o prostą i czytelną informację w odpowiedniej chwili do odpowiedniej osoby.

“Remonty przeprowadzamy na podstawie własnych doświadczeń i informacji jakimi dysponujemy lecz zdarza się, że po wznowieniu produkcji psuje się zupełnie coś innego” – często słyszę takie informacje od osób z Utrzymania Ruchu

Posłużę się przykładem.

Brak alternatywnego tekstu dla tego zdjęcia

Zdjęcie obok przedstawia typowy panel sterujący obrabiarki opartej o Sinumerik firmy Siemens. Nie ma szans aby osoba bez specjalistycznego przeszkolenia mogła ten panel obsługiwać nawet do prostych czynności, jak uzyskanie informacji o stanie maszyny.

Klasyczna metoda pozyskiwania danych polega na podpięciu sygnałów do sterownika obrabiarki i “przepuszczenia” danych dalej poprzez sieć ethernet. Wada tego rozwiązania polega na tym, że potrzebne jest przeprogramowanie sterownika (czyli trzeba mieć aktualny program i osobę specjalistę, który jest w stanie to przeprogramować) oraz mała elastyczność w przypadku rekonfiguracji systemu. Z reguły staramy się unikać takiego rozwiązania gdyż priorytetem jest zachowanie funkcjonowania maszyny a wszelkie modyfikacje w sterowaniu zawsze obarczone są ryzykiem.

3. Topologia Y

Jakiś czas temu firma ifm zaproponowała rozwiązanie bazujące na topologii Y. Polega ona na tym, że główny strumień danych pochodzących z czujników trafia do systemów IT a informacje ważne pod kątem sterowania do sterownika PLC.

Brak alternatywnego tekstu dla tego zdjęcia

Istotna zeleta rozwiązania jest taka, że sterownik korzysta z danych potrzebnych tylko do sterowania, a system nadrzędny zbiera te dane, które go interesują w danej chwili (tak mamy dostęp do wszystkich możliwych informacji w czujniku ale bierzemy te, które są dla nas istotne).

Przy realizowanych przeze mnie projektach zawsze idziemy na pewien kompromis (pewne dane bierzemy ze sterownika PLC, inne z dodatkowych czujników, systemów itd.) z tego tytułu, że celem projektu jest rozwiązanie konkretnego problemu (monitorowanie zużycia powietrza, łożysk, oleju prowadzące do poprawy ogólnego stanu maszyny) i na tej podstawie buduje się strukturę systemu dla konkretnej maszyny. Ponadto jeśli maszyna posiada już zainstalowane czujniki to staramy się je wykorzystać.

4. Linerecorder Smartobserver

Zbieranie danych powinno czemuś służyć i najlepiej aby wdrożenie nastąpiło szybko, a efekty były natychmiastowe. Niestety praktycznie w każdej fabryce mamy do czynienia z maszynami innego typu (czasem są to maszyny przeniesione z innej fabryki, zdarza się, że z innego kraju), sposób komunikacji między nimi też jest za każdym razem inny, niestety taka sytuacja komplikuje dosyć mocno sposób działania.

Miejsce LR Smartobserver na fabryce można określić między maszynami a systemami ERP jak na poniższym rysunku:

Brak alternatywnego tekstu dla tego zdjęcia

Dane z maszyn są przesyłane do LR Smartobserver celem wizualizacji a następnie do systemów klasy ERP (opcjonalnie).

Pomimo różnorodności rozwiązań spotykanych na fabryce możliwe jest wyprowadzenie pewnego rodzaju standardu w pozyskiwaniu danych. Realizacja następuje poprzez zrobienie tzw. projektu pilotażowego, którego celem jest potwierdzenie wcześniej przyjętego założenia. Np. czy jesteśmy w stanie monitorować stan wrzeciona na obrabiarce i reagować z wyprzedzeniem na potencjalnie pojawiające się ryzyko awarii.

W przypadku gdy mamy potwierdzenie (system zgłasza problem, dokonana jest naprawa, a części zdjęte z maszyny wykazują ślady znacznego zużycia) to nie ma przeszkód aby to rozwiązanie skopiować na pozostałe maszyny tego samego typu. Tak też realizowana jest idea skalowalności: zaczynamy od jednej maszyny po czym mając doświadczenie z tą jedną możemy rozszerzyć rozwiązanie na pozostałe.

4.1. Podgląd danych

Po analizie danych jesteśmy w stanie określić w jakim punkcie się znajdujemy. Na poniższym rysunku widzimy układ w którym monitorujemy zespół maszyn: przekładnia, pompa oleju, silnik. Na wykresie obserwujemy, że łożysko na silniku najpierw zaczyna przekraczać poziomy ostrzeżenia (żółta kreska) następnie stan ten z czasem sie pogarsza (następuję przekroczenie alarmu – linia czerwona). Poziomy alarmów i ostrzeżeń są ustawiane przez specjalistę w zakresie drgań wg norm lub własnych doświadczeń, z reguły po ok. 2-3 tygodniach następuje ich weryfikacja (dopasowanie progów dla konkretnej maszyny).

Brak alternatywnego tekstu dla tego zdjęcia

Czasem trudno jest nam określić czy aktualna wartość otrzymywana z maszyny to dobrze czy źle. Inaczej jednak wygląda sprawa jeśli spojrzymy w dłuższym horyzoncie czasowym, wtedy widzimy, że wartość drgań narasta (niebieska linia trendu), poniższy obrazek idealnie to pokazuje – widać również wyraźną różnicę w otrzymywanych danych po remoncie (prawa część wykresu – poziom drgań jest niezauważalny na tle wcześniejszych problemów).

Brak alternatywnego tekstu dla tego zdjęcia

Maszyny są w stanie generować potężne ilości danych. Kluczem jest efektywne zarządzanie nimi.

4.2. Zarządzanie danymi – jak korzystać z dostępnych informacji?

Samo zbieranie danych nie przejawia większej wartości jeśli pozostają one zamknięte.

Na podstawie przejrzystych informacji wyświetlanych na ekranie obserwujemy stan maszyn (z reguły umieszczam zdjęcia z parku maszynowego – wtedy osoby, które nie znają oznaczeń na podstawie znajomości wyglądu maszyn są w stanie szybko zlokalizować miejsce problemu).

Brak alternatywnego tekstu dla tego zdjęcia

Potem przechodząc na kolejne ekrany w strukturze hierarchicznej schodzimy punkt po punkcie do interesującego dla nas miejsca – aż do samego czujnika.

Brak alternatywnego tekstu dla tego zdjęcia

Główny cel jest taki aby informacja była jasna i czytelna a źródło problemów łatwe do określenia.

Użytkownik może sam zmodyfikować widok ekranu (dodając interesujące go zdjęcia lub wyświetlając odpowiednie parametry).

Brak alternatywnego tekstu dla tego zdjęcia

Jeśli dane, które otrzymujemy z czujników są dla nas jasne i przejrzyste możemy zrealizować kolejny krok – automatycznie powiadamiać o alarmach poprzez SMS lub email, ponadto jest możliwość wprowadzania zadań technicznych do LR Smartobserver (Maintenance Tasks) celem przekazania osobie odpowiedzialnej za dany rejon lub realizacji prac w późniejszym terminie.

4.3. Standaryzacja

Przy bardziej rozbudowanych parkach maszynowych prędzej czy później potrzebne będzie wprowadzenie standardu informującego o stanie maszyn (pod kątem predykcyjnego utrzymania ruchu). Obecnie każda maszyna ma swój własny interfejs komunikacyjny człowiek-maszyna (lokalny panel opratorski) co dosyć komplikuje sytuację. Ujednolicenie sposobu przekazywania informacji w istotny sposób wpływa na zarządzanie parkiem maszynowym. Przykładem może być obchód maszyn (celem sprawdzenia gotowości do pracy) przed rozpoczęciem produkcji. Poniżej przykład pokazujący możliwość wyświetlania stanu każdej maszyny na platformie LR Smartobserver.

Brak alternatywnego tekstu dla tego zdjęcia

Każda maszyna ma swój własny interfejs, chcemy aby każda przemawiała do nas w ten sam sposób (ok – maszyna sprawna, uwaga – maszyna wymagająca uwagi, alarm – maszyna niesprawna).

4.4. Automatyczne przekazywanie informacji do ERP

Systemy klasy ERP (Enterprise Resource Planning) zarządzają kompleksowo przedsiębiorstwem. LR Smartobserver ma na celu zebrać informacje z maszyn przedstawić je w sposób łatwy i czytelny ale również ma możliwość integracji np. z SAP ERP poprzez Plant Connectivity (np. do zbierania danych), lub poprzez wysyłanie zgłoszeń o alarmach lub pracach serwisowych.

Jeśli chcemy aby zlecenia na naprawę maszyn i zamówienia części były generowane automatycznie to musimy mieć pewność, że sygnały, które są wysyłane do ERP są prawidłowe a więc ma to związek z poprawnym oczujnkowaniem maszyny, odpowiednim przesyłem danych i ustawieniem wartości brzegowych. LR Smartobserver z ifm zapewnia taką funkcjonalność.

Brak alternatywnego tekstu dla tego zdjęcia

Podczas integracji z SAP warto upewnić się, że system przekazuje prawidłowe informacje (inaczej SAP zamówi nam części, których nie potrzebujemy)

5. Podsumowanie

W niniejszym artykule starałem się przedstawić pewne sytuacje, może wyzwania z jakimi przychodzi nam się zmierzać w przypadku monitorowania maszyn. Nawet jeśli poprawnie dobierzemy czujniki, skonfigurujemy, podłączymy to staniemy przed kolejnym problemem: jak te informacje efektywnie wykorzystać. Platforma LR Smartobserver daje możliwości zrozumienia w jaki sposób “przemawia” do nas maszyna.

Na pewno temat ten nie jest wyczerpany gdyż coraz więcej powstaje projektów związanych z uczeniem maszynowym, gdzie potrzebne są duże ilości danych. Niemniej dane te muszą być w pewien sposób określać pewne właściwości (np. spadek ciśnienia na filtrze będzie nam mówił o przytkaniu filtrów) i zanim się zdecydujemy uruchomić algorytmy to muszą za tym stać pewien cel (np. algorytm miałby informować kiedy filtr należy wymienić).

Jesli masz jakieś uwagi, sugestie pisz: marek.maciejewski@ifm.com.

Autor: Marek Maciejewski

Zapraszamy do zapoznania się z pierwszą częścią artykułu

Kliknij tutaj

ZOSTAW ODPOWIEDŹ

Wprowadź swój komentarz!
Wprowadź swoje imię