Rozmowa o Przemyśle 4.0 zwykle zaczyna się od pytania „jaki system wdrożyć", a powinna od pytania „czy maszyna ma czym mówić". Sterownik, który nie liczy sztuk, nie zapisuje przyczyny zatrzymania i nie wystawia niczego poza własny pulpit, nie stanie się źródłem danych dlatego, że ktoś kupi platformę do ich zbierania. Monitoring produkcji jest najpierw zadaniem konstrukcyjnym i programistycznym, a dopiero potem informatycznym.
Przemysł 4.0 zaczyna się w sterowniku, nie w platformie
Sterownik maszyny wie znacznie więcej, niż pokazuje: zna pozycje siłowników, stany czujników, czas trwania każdego kroku cyklu i moment wystąpienia blokady. Różnica między maszyną głuchą a taką, którą da się monitorować, sprowadza się najczęściej do kilkunastu zmiennych, kilku liczników i decyzji, że te wartości mają być zapisywane i udostępniane na zewnątrz.
To dlatego akwizycja danych z maszyn jest tania, kiedy planuje się ją razem z programem sterowania, a droga, kiedy dokłada się ją później do gotowego, obcego oprogramowania — trzeba wtedy rozszyfrować cudzą logikę i znaleźć w niej miejsca, w których naprawdę kończy się cykl. Sam sprzęt bywa tu najmniejszą pozycją w kosztorysie.
Sześć rodzajów danych, które naprawdę się przydają
Kryterium jest jedno: każdy z tych sygnałów prowadzi do konkretnej decyzji. Dana, która do żadnej decyzji nie prowadzi, nie zasługuje na miejsce w rejestrze.
| Rodzaj danych | Do jakiej decyzji prowadzi |
|---|---|
| Licznik sztuk i rzeczywisty takt | Zestawienie taktu nominalnego z rzeczywistym — zwykle pierwsza rzecz, która w zakładzie zaskakuje. |
| Czas i przyczyna przestoju | Sam czas mówi mało. Dopiero rozdzielenie awarii, braku materiału, przezbrojenia i czekania wskazuje, gdzie działać. |
| Alarmy z historią | Lampka mówi, że coś dzieje się teraz; historia mówi, że ten sam czujnik zgłasza się trzeci raz w tygodniu — i na tym opiera się przegląd. |
| Kluczowe parametry procesu | Trend prądu napędu bywa wcześniejszym sygnałem tępiącego się narzędzia niż reklamacja od klienta. |
| Liczniki motogodzin i zużycia | Przeglądy planowane według rzeczywistej pracy maszyny, a nie według kalendarza, który nie odróżnia jednej zmiany od pracy ciągłej. |
| Dane jakościowe z kontroli | Liczba sztuk odrzuconych i powód odrzucenia — podstawa do wychwycenia dryfu procesu, zanim powstaną braki. |
Ostatni wiersz domyka się sam, jeżeli na linii pracuje kontrola automatyczna — piszemy o tym w artykule o systemach wizyjnych w kontroli jakości. W realizacjach z systemem THT-Scan wynik pomiaru jest jednocześnie sygnałem sterującym i zapisem, który da się zestawić z parametrami procesu.
Czego dane same z siebie nie załatwią
Rejestracja danych nie zwiększa wydajności. Wykres nie skraca przezbrojenia ani nie usuwa zatoru na przenośniku. Dane robią jedną rzecz: pokazują, gdzie szukać, i pozwalają ocenić, ile dana strata kosztuje. Wzrost wydajności przychodzi dopiero po zmianie w konstrukcji, sterowaniu albo organizacji pracy — jak ją zaplanować, opisujemy w tekście o tym, jak znaleźć wąskie gardło produkcji.
Druga pułapka to mylenie objawu z przyczyną. System pokaże, że maszyna stała, i przypisze ten czas do niej, podczas gdy rzeczywistą przyczyną bywa zdarzenie sprzed dwóch stanowisk. Dlatego dane z linii produkcyjnej czyta się w kontekście całego ciągu i dlatego warto od początku rejestrować stany buforów między maszynami.
Trzecia rzecz jest organizacyjna: dane muszą mieć adresata. Zanim padnie pytanie „co jeszcze możemy mierzyć", powinno paść pytanie „kto to przeczyta i co z tym zrobi".
Panel HMI jako pierwsze źródło informacji o produkcji
Brygadzista nie potrzebuje zewnętrznego systemu, żeby wiedzieć, jak idzie zmiana. Potrzebuje ekranu przy maszynie, na którym widzi cztery rzeczy: ile sztuk zrobiono od początku zmiany, ile powinno być o tej porze, w jakim stanie jest maszyna i jakie były trzy ostatnie zatrzymania wraz z godzinami. Taka wizualizacja produkcji na panelu HMI nie wymaga infrastruktury poza samą maszyną.
Drugi ekran, o który warto zadbać od razu, to ekran diagnostyczny dla utrzymania ruchu: stany wejść i wyjść opisane nazwą elementu i jego funkcją, a nie samym adresem. Przy dobrze opisanym ekranie diagnostyka maszyny sprowadza się do spojrzenia na panel, przy złym wymaga schematu, laptopa i osoby, która zna program. Takie ekrany powstają razem z resztą programu, dlatego projektując automatykę przemysłową traktujemy je jako standardowy element sterowania, a nie dodatek zamawiany osobno.
Maszyna nowa i maszyna sprzed lat — dwie różne drogi
Maszyna projektowana od zera
Tutaj monitoring jest wyłącznie kwestią specyfikacji. Na etapie założeń ustala się listę rejestrowanych zmiennych, sposób ich udostępniania oraz zawartość ekranów HMI. Decyzje podjęte przed napisaniem programu nic nie komplikują, bo liczniki i rejestry powstają razem z resztą logiki; podjęte po uruchomieniu oznaczają powrót do gotowego, przetestowanego programu i ponowny odbiór. W praktyce wystarczy dopisać do zapytania ofertowego kilka zdań: jakie liczniki mają być prowadzone, jaka ma być lista przyczyn przestoju i co ma pokazywać ekran zmiany.
Maszyna użytkowana od lat
Stare sterowanie zwykle nie ma czym mówić — nie prowadzi liczników i nie zapisuje historii. Naturalnym momentem na zmianę jest wymiana szafy sterowniczej i sterowania: skoro program powstaje od nowa, dołożenie liczników, rejestru alarmów i ekranów raportowych to kwestia kilku dodatkowych funkcji, a nie osobnego projektu. Dlatego przy każdym retroficie pytamy, co maszyna ma raportować po modernizacji — zanim powstanie pierwsza linijka programu.
Jeżeli wymiana sterowania nie wchodzi w grę, zostaje wariant minimalny: niezależny licznik oparty na własnym czujniku, odczytujący fakt wykonania cyklu bez ingerencji w istniejący program. Da takt, liczbę sztuk i długość przestojów — nie da przyczyn zatrzymań ani parametrów procesu, bo te istnieją wyłącznie w środku sterownika. I tak jest to znacznie więcej niż zapis w zeszycie na koniec zmiany.
Jedno zastrzeżenie: dokładanie odczytu sygnałów to zwykle zmiana nieinwazyjna, ale jeżeli prace dotykają obwodów bezpieczeństwa albo zmieniają sposób pracy maszyny, trzeba najpierw ocenić ich zakres — mogą zostać uznane za istotną modyfikację maszyny, a to pociąga za sobą obowiązki producenta.
Dlaczego zaczyna się od jednej maszyny i jednego wskaźnika
Wdrożenia obejmujące od razu cały park maszynowy najczęściej kończą się zbiorem raportów, których nikt nie otwiera. Sensowna kolejność jest odwrotna i wygląda tak:
Wybierz jedną maszynę
Tę, która najbardziej ogranicza przepustowość całego zakładu — a nie tę, którą technicznie najłatwiej podłączyć.
Zadaj jedno pytanie
Na przykład: ile godzin w tygodniu ta maszyna nie pracuje i z jakiego powodu. Pytanie ustala zakres danych, a nie odwrotnie.
Zbierz minimalny zestaw danych
Taki, który na to pytanie odpowiada. Zwykle trzy, cztery wielkości — nie więcej.
Pokaż je tam, gdzie zapada decyzja
Przy maszynie i na zmianie, a nie w zestawieniu miesięcznym oglądanym w biurze.
Po miesiącu sprawdź, czy coś się zmieniło
Jeżeli nikt nie podjął żadnej decyzji, rozszerzanie systemu na kolejne maszyny niczego nie naprawi.
Pierwszy wskaźnik uczy zakład czytania własnych danych. Dopiero kiedy brygadzista sam zaczyna pytać o liczby, dokładanie kolejnych maszyn ma sens ekonomiczny.
Najczęstszy błąd: dane, których nikt nie czyta
Cztery pozostałe pułapki są mniej dotkliwe, ale spotykamy je równie często:
- Zbieranie wszystkiego na zapas. Rejestrowanie każdego sygnału „bo może się przyda” kończy się zbiorem, w którym nie da się niczego znaleźć.
- Brak zamkniętej listy przyczyn przestoju. Jeżeli operator dostaje pole tekstowe, po miesiącu połowa zapisów brzmi „inne”, a analiza traci sens.
- Wskaźnik bez właściciela. Liczba, której nikt nie ma obowiązku przeczytać, przestaje być aktualizowana i przestaje być wiarygodna.
- Porównywanie okresów bez uwzględnienia asortymentu. Zmiana robiąca krótkie serie z częstym przezbrajaniem wypadnie gorzej od zmiany z jedną długą serią — i nie będzie to jej wina.
Wniosek? Przemysł 4.0 nie zaczyna się od zakupu systemu, tylko od decyzji podjętej przy projektowaniu sterowania: że maszyna ma liczyć, zapisywać i pokazywać. Podjęta na czas jest częścią zwykłej pracy nad programem. Podjęta po latach oznacza płacenie za rozszyfrowanie tego, co maszyna od dawna wiedziała, ale nikomu nie powiedziała.