Przewodnik po systemie zbierania danych przemysłowych dla zakładów

Pod koniec zmiany kierownik produkcji nadal próbuje złożyć w całość, co się wydarzyło tego dnia, korzystając z papierowych dokumentów, dzienników maszyn i wielu arkuszy Excel. Ile wynosił rzeczywisty czas przestoju? Które zamówienie jest opóźnione? Dlaczego wzrósł wskaźnik braków? przewodnik po systemie zbierania danych przemysłowych jest przydatny, jeśli nie zaczyna się od czujników czy ekranów, ale od tych pytań.

W wielu zakładach dane są już dostępne w jakiejś formie. PLC obsługują sygnały, maszyny rejestrują zdarzenia, w ERP znajdują się dane o zamówieniach i zapasach, a dział utrzymania ruchu prowadzi własną ewidencję. Problemem niekoniecznie jest brak danych. Raczej to, że informacje są rozproszone, aktualizowane w różnych momentach, a ludzie muszą łączyć te części.

Co powinien rozwiązać system zbierania danych przemysłowych?

Zbieranie danych samo w sobie nie jest celem biznesowym. To, że linia produkcyjna przechowuje setki wartości na sekundę, nie oznacza, że produkcja będzie szybsza, mniej będzie braków czy dostawy będą bardziej przewidywalne. Wartość systemu polega na tym, czy odpowiedzialny kierownik lub operator może na jego podstawie podejmować decyzje w odpowiednim czasie i wiarygodnie.

Warto więc najpierw wyznaczyć konkretną sytuację operacyjną. Na przykład plan produkcji wydaje się być realizowany rano, ale po południu okazuje się, że z powodu powtarzającej się awarii maszyny zmiana nie może być nadrobiona. Albo firma wie, że jest wiele krótkich przestojów, ale nie wie, który produkt, narzędzie, surowiec lub operacja za tym stoi.

Dobre pytania wyjściowe mogą być:

• Do których decyzji trzeba dziś ręcznie zbierać dane z wielu źródeł?
• Gdzie powstają takie straty, które są zauważane dopiero później?
• Które dane są wprowadzane wielokrotnie do różnych systemów?
• Wokół których wskaźników regularnie powstają spory, ponieważ nie ma jednolitego źródła danych?

Jeśli nie ma jednoznacznej odpowiedzi na te pytania, nie warto rozpoczynać projektu od listy narzędzi. Najpierw trzeba zbadać proces: gdzie powstają informacje, kto je wykorzystuje, kto je modyfikuje i gdzie tracą swoje znaczenie.

Jakie dane warto zbierać?

Najczęstszym błędem jest zbyt szerokie rozpoczęcie. Z nowym systemem łatwo jest zacząć przechowywać wszystkie dostępne sygnały maszyn, temperatury, czasy cykli i zmiany stanu. Może to mieć uzasadnienie techniczne, szczególnie w środowisku zapewnienia jakości, śledzenia lub utrzymania ruchu. Jednak dla celów operacyjnych zbyt wiele, nieprzetworzonych danych często tworzy jedynie nowe obciążenie raportowe.

W większości firm produkcyjnych kilka podstawowych kategorii już zapewnia znaczną przejrzystość: stan maszyny lub komórki, ilość wyprodukowana, braki i ich przyczyny, przyczyny przestojów, czas cyklu oraz produkt lub zamówienie przypisane do danego okresu. W razie potrzeby można je uzupełnić o zużycie energii, dane środowiskowe, stan narzędzi lub identyfikator surowca.

Nie wszystkie dane można zbierać z jednakową wiarygodnością. Na przykład sygnał stanu pochodzący z maszyny automatycznie wydaje się obiektywny, ale nadal trzeba wyjaśnić, co oznacza. Czy sygnał „działa” faktycznie oznacza produkcję, czy maszyna działa na biegu jałowym? Czy sygnał „błąd” oznacza konkretne zakłócenie, czy łączy różne zdarzenia? Model danych musi dokładnie opisywać proces fizyczny, a nie tylko kopiować etykiety z kontrolera.

Jest również realistyczne, że pewne przyczyny można zrozumieć tylko na podstawie ludzkiej informacji zwrotnej. Automatyczne wykrywanie przestoju i rzeczywista przyczyna operacyjna przestoju to dwie różne informacje. Operator potrzebuje więc krótkich, jednoznacznych i dopasowanych do pracy opcji wyboru. Jeśli musi szukać kategorii na terminalu przez dziesięć minut, jakość danych również się pogarsza, a opór wobec systemu rośnie.

Przewodnik po systemie zbierania danych przemysłowych: mapowanie procesu

Skuteczne wdrożenie zazwyczaj nie zaczyna się od tego, jaki SCADA, system zarządzania produkcją czy platforma chmurowa ma być używana. Najpierw trzeba prześledzić obecny przepływ informacji przez całą zmianę lub cykl zamówienia.

Kto sygnalizuje, że maszyna się zatrzymała? Gdzie rejestrowana jest przyczyna? Kiedy informacja trafia do planu produkcji, działu utrzymania ruchu lub kierownika zmiany? Kiedy i jak ilość produkcji trafia do ERP? Jeśli istnieje rozbieżność między rzeczywistością fizyczną a systemem, kto ją poprawia i na jakiej podstawie? Te pytania często mówią więcej o kierunku rozwoju niż karta danych urządzenia.

Podczas mapowania często okazuje się, że nie brakuje pomiaru, ale granica odpowiedzialności jest niepewna. Na przykład operator maszyny prowadzi ewidencję ilości na papierze, kierownik zmiany podsumowuje w Excelu, a administracja później rejestruje wynik w systemie zarządzania przedsiębiorstwem. W takim przypadku powstają trzy różne źródła danych dotyczące tego samego zdarzenia i żadne z nich nie jest gwarantowane jako aktualne.

Dobry stan docelowy niekoniecznie oznacza pełną automatyzację. Może wystarczyć automatyczne zbieranie danych z maszyny, zatwierdzanie odchyleń przez operatora, a następnie przekazywanie zweryfikowanego wyniku do ERP. Ważne jest, aby każde dane miały jasne źródło, właściciela i cel użytkowania.

Bez integracji powstaje tylko nowa wyspa danych

Samodzielny wyświetlacz produkcyjny może być efektowny, ale mniej wartościowy, jeśli zamówienia, numery artykułów, instrukcje operacyjne i ruchy zapasów nadal są ręcznie przenoszone z jednego systemu do drugiego. System zbierania danych przemysłowych musi zatem zarządzać również relacją między systemami operacyjnymi a biznesowymi.

Rytm danych różni się między poziomem maszyny a systemem przedsiębiorstwa. PLC sygnalizuje zmianę stanu w ciągu sekund, podczas gdy ERP może potrzebować tylko zakończonej operacji, zatwierdzonej ilości i przyczyny braków. Nie jest wskazane przesyłanie wszystkich surowych sygnałów do ERP. Odpowiednia architektura oddziela dane operacyjne w czasie rzeczywistym, interpretowane zdarzenia produkcyjne i transakcje o znaczeniu finansowym lub logistycznym.

Jest to ważne, ponieważ błędy integracji pojawiają się w działaniu zakładu. Jeśli do zamówienia przypisany jest zły numer artykułu, raport będzie mylący. Jeśli informacja zwrotna z produkcji się opóźnia, zapasy i zakupy mogą opierać się na błędnych decyzjach. Jeśli przekazanie nie jest kontrolowane, ten sam element może pojawić się w systemie nawet dwa razy.

Dlatego interfejsy wymagają identyfikatorów, znaczników czasu, obsługi błędów i weryfikacji. Pytanie nie brzmi tylko, czy dane są przesyłane, ale także, czy w przypadku błędu można zauważyć brak, ponownie wysłać zdarzenie i jednoznacznie odtworzyć, co się stało.

Niezawodność, uprawnienia i bezpieczeństwo operacyjne

W środowisku produkcyjnym zbieranie danych nie może przeszkadzać w ciągłej pracy. Jeśli połączenie sieciowe zostanie przerwane, produkcja musi być kontynuowana. Jeśli centralna usługa nie jest dostępna, zdarzenia nie mogą być tracone bez kontroli. Dlatego już na etapie projektowania należy wyjaśnić, które funkcje wymagają działania w czasie rzeczywistym, które dane mogą być tymczasowo przechowywane lokalnie i jak odbywa się późniejsza synchronizacja.

Bezpieczeństwo danych nie jest wyłącznie kwestią informatyczną. Dane produkcyjne mogą być wrażliwe z punktu widzenia biznesowego, a nieautoryzowane modyfikacje mogą powodować problemy z jakością, rozliczeniami lub zgodnością. W dobrze zaprojektowanym systemie role regulują, kto może zobaczyć, rejestrować, modyfikować lub zatwierdzać dane. Krytyczne modyfikacje mogą być rejestrowane, dzięki czemu później nie trzeba ustalać z pamięci, dlaczego wartość się zmieniła.

Wybór technologii jest tutaj naprawdę zależny od sytuacji. W niektórych przypadkach lokalna infrastruktura operacyjna jest odpowiednią decyzją z powodu opóźnień, ograniczeń połączeń lub wymagań regulacyjnych. W innych firmach centralne środowisko łączące wiele lokalizacji zapewnia lepszy wgląd. Często stosuje się kombinację obu: lokalne przetwarzanie danych, centralne raportowanie i kontrolowane przekazywanie danych.

Jak zmierzyć, czy rozwój się opłaca?

Zwrot z inwestycji to nie tylko zmniejszenie liczby godzin pracy. Wartość systemu zbierania danych może objawiać się tym, że szybciej zauważa się pogarszający się trend, jest mniej pilnych uzgodnień, dokładniejszy jest czas realizacji zamówień, a utrzymanie ruchu nie reaguje wyłącznie na zgłoszenia awarii. Warto już na początku powiązać te kwestie z mierzalnymi celami.

Celem może być na przykład zwiększenie wiarygodności rejestrowania przestojów, skrócenie czasu przygotowania raportu zmiany, zmniejszenie różnic w zapasach lub wcześniejsze przewidywanie realizacji planu produkcji. Dobry wskaźnik nie pokazuje tylko, ile danych zebrano. Pokazuje, czy poprawiło się działanie.

Warto zacząć od dobrze zdefiniowanego obszaru, gdzie znany jest problem biznesowy, można zaangażować zainteresowane strony, a wynik jest porównywalny. Linia produkcyjna, krytyczna operacja lub powtarzający się problem jakościowy często są lepszym pierwszym krokiem niż pokrycie całego zakładu naraz. Na podstawie doświadczeń można następnie doprecyzować model danych, interfejs użytkownika i zasady integracji.

Najlepszy system to nie ten, który zbiera najwięcej danych. To ten, który w trakcie zmiany pokazuje, gdzie trzeba interweniować, i na którym produkcja, utrzymanie ruchu i zarządzanie mogą polegać z takim samym zaufaniem.