Dane z maszyn bez kontekstu to szum: przyczyny przestojów, model stanów maszyny i jakość danych
DBR77 Team · Opublikowano
Dane z maszyn zaczynają być użyteczne wtedy, gdy każdy sygnał zostaje przełożony na stan, co do którego wszyscy się zgadzają, a każdy postój ma przypisaną przyczynę. Bez modelu stanów maszyny i kodów przyczyn przestojów sygnał „zatrzymana” nie powie Ci, czy linia czekała na materiał, była w przezbrojeniu, czy uległa awarii.

Dlaczego surowy sygnał to jeszcze nie informacja
Bit w sterowniku PLC albo czujnik prądu mówi tylko, czy maszyna pracuje. Planowe mycie, zacięcie i pusty podajnik wyglądają w surowych danych identycznie.
Bez kontekstu największym słupkiem na wykresie Pareto przestojów jest „nieznane”, a na tej podstawie nikt nie może nic zrobić.
Na jednej linii opakowań z tektury falistej rejestrowanie przyczyny w dwie sekundy, w chwili zatrzymania, usunęło „nieznane” z Pareto i razem ze statusem maszyn na żywo oraz alertami z przypisanym właścicielem pomogło obniżyć średni czas reakcji na postój z 24 do 9 minut.


Prosty model stanów maszyny
Model stanów to krótka, stała lista stanów, w których może być każda maszyna, z jedną definicją dla każdego z nich. Standardy branżowe idą dalej: model OMAC PackML, przyjęty przez ISA jako TR88.00.02, daje maszynom spójne stany niezależnie od producenta. Do monitorowania linii w istniejącym zakładzie zwykle wystarcza siedem stanów.
| Stan | Definicja | Jak jest wykrywany | Czy obniża OEE? |
|---|---|---|---|
| Praca | Produkcja z prędkością idealną lub zbliżoną | Rośnie licznik cykli lub sztuk | Nie, ale wolne cykle to strata wydajności |
| Bezczynność (mikropostój) | Krótki postój usunięty przez operatora | Brak cyklu dłużej niż kilka czasów cyklu, poniżej progu przyczyny | Tak, wydajność |
| Postój nieplanowany | Awaria, zacięcie lub błąd powyżej progu | Brak cyklu dłużej niż próg, brak aktywnego zdarzenia planowego | Tak, dostępność |
| Przezbrojenie | Przejście na kolejny produkt lub format | Operator uruchamia je na tablecie albo zmienia się zlecenie | Tak, dostępność |
| Postój planowany | Mycie, planowe utrzymanie ruchu, kontrola w czasie zaplanowanej produkcji | Operator wybiera przyczynę z listy planowych albo wynika z harmonogramu | Tak, dostępność |
| Brak zasilania / zablokowanie | Maszyna gotowa, ale brak wsadu z poprzedniego etapu lub brak miejsca na następnym | Czujniki buforów lub flagi PLC albo wybrana przyczyna | Tak, dostępność, oznaczona jako przyczyna zewnętrzna |
| Poza planem | Brak zaplanowanej produkcji: przerwy, brak zmiany, brak zleceń | Kalendarz zmian | Nie, wyłączone z planowanego czasu produkcji |
Kolumna OEE opiera się na definicjach Vorne: planowany czas produkcji wyklucza tylko czas, w którym nie zamierzano produkować, a sześć wielkich strat traktuje przezbrojenia jako stratę dostępności, a mikropostoje jako stratę wydajności. Niektóre zakłady wyłączają planowe utrzymanie ruchu, a każde z tych podejść działa, jeśli stosuje się je wszędzie tak samo.
Jak zaprojektować kody przyczyn przestojów, których operatorzy naprawdę użyją
Stan pokazuje, że maszyna stanęła, a przyczyna mówi, dlaczego. Dobra lista przyczyn jest na tyle krótka, by wybrać pozycję w dwie sekundy, i na tyle konkretna, by dało się na jej podstawie działać.
- 10 do 15 przyczyn na typ maszyny. Dłuższe listy kończą się wyborem „inne”. Prasa i paletyzator potrzebują różnych list.
- Język operatora. Używaj słów takich jak „zerwana folia” i „zatkana dysza kleju”; kody centrów kosztów skopiowane z ERP przy maszynie się nie sprawdzą.
- Najwyżej dwa poziomy. Kategoria (mechanika, materiał, jakość, organizacja) i konkretna przyczyna.
- Jasny próg. Vorne podaje przykładową zasadę: każdy postój dłuższy niż dwie minuty dostaje przyczynę. Krótsze postoje liczone są jako mikropostoje.
- Rejestracja w chwili postoju. Operator wybiera przyczynę na tablecie przy maszynie, póki jest oczywista. Do tego służy aplikacja operatora.
Przeglądaj listę co miesiąc. Jeśli „inne” przekracza kilka procent czasu przestojów, operatorzy dają Ci znać, że brakuje jakiejś przyczyny.
Zobacz stany i przyczyny na działającej linii
W 30-minutowym demo online pokażemy, jak DBR77 IIoT zamienia sygnały z maszyn w stany, rejestruje przyczyny w chwili postoju i buduje Pareto, na podstawie którego można działać.
Spójne definicje na wszystkich zmianach
Dane najszybciej tracą wartość, gdy zmiany nazywają to samo zdarzenie różnymi słowami. Nocna zmiana zapisuje zacięcie jako „mechanika”, poranna jako „materiał”. Po miesiącu jeden duży problem pojawia się na Pareto jako dwa o połowę mniejsze.
Spisz model stanów i listę przyczyn, z jednym zdaniem definicji dla każdej pozycji. Przeszkol wszystkie zmiany na tej samej wersji. Zmieniaj definicje tylko w ustalonym terminie i zapisuj każdą zmianę, żeby trendy przed nią i po niej dało się porównać.
To samo dotyczy poziomu zakładu. Jednym z celów ISA-95 jest wspólna terminologia dla systemów produkcyjnych i biznesowych. W jednym zakładzie praktyczna wersja tej zasady to jeden słownik, którego używają wszystkie zmiany i systemy. Na stronie modułów widać, jak stany, przyczyny i alerty łączą się w DBR77 IIoT.
Testy jakości danych przed skalowaniem
Zanim skopiujesz konfigurację jednej linii na pięć kolejnych, sprawdź, czy dane są poprawne. Błędy, które na jednej linii są drobne, w skali zakładu się mnożą.
- Brakujące stany. Zsumuj wszystkie stany w ramach zmiany. Jeśli nie pokrywają całego czasu zmiany, któryś sygnał zanika albo jakiś stan nie jest zdefiniowany.
- Błędne idealne czasy cyklu. Vorne zauważa, że wydajność powyżej 100% zwykle oznacza zbyt wysoko ustawiony idealny czas cyklu. Sprawdź każdy produkt, nie tylko główny.
- Rozjechane zegary. Jeśli urządzenia brzegowe, sterowniki PLC i serwery pokazują różny czas, postoje trafiają do niewłaściwej zmiany, a czasy reakcji są błędne. Zsynchronizuj je, na przykład przez NTP.
- „Nieznane” i „inne”. Co tydzień śledź ich udział w czasie przestojów. Rosnący udział oznacza, że trzeba poprawić listę przyczyn albo nawyk.
Jakie sygnały w ogóle zbierać, opisujemy w artykule zbieranie danych z maszyn: co mierzyć.
Gdzie kontekst się zwraca
Przy czystych stanach i przyczynach OEE na żywo jest wiarygodne, bo liczy się je z uzgodnionych zdarzeń, a przekazanie zmiany można zbudować na danych.
Na stanowiskach ręcznych bez żadnego sygnału z maszyny stan może dostarczyć kamera. Warstwa IRIS Vision AI wykrywa cykle i obecność bez podłączania się do maszyny.
Najczęstsze pytania
Czym jest model stanów maszyny?
To stała lista stanów, w których może być maszyna, np. praca, bezczynność, postój nieplanowany i przezbrojenie, każdy z jedną definicją i jedną regułą wykrywania. Zamienia surowe sygnały w zdarzenia, które można porównywać między maszynami i zmianami.
Ile kodów przyczyn przestojów powinna mieć maszyna?
Zwykle 10 do 15 na typ maszyny, w języku, którym posługują się operatorzy. Dłuższe listy skłaniają do wybierania „inne”. Przeglądaj listę co miesiąc i dodawaj przyczynę tylko wtedy, gdy pojawi się realna luka.
Czy postoje planowane obniżają OEE?
Według definicji Vorne tak. Z planowanego czasu produkcji wyłącza się tylko czas, w którym nie zamierzano produkować, np. przerwy. Przezbrojenia, mycie i planowe utrzymanie ruchu nadal obniżają dostępność.
Co sprawdzić przed rozszerzeniem na kolejne linie?
Sprawdź, czy stany pokrywają cały czas zmiany, czy idealne czasy cyklu są poprawne dla każdego produktu, czy wszystkie zegary są zsynchronizowane i czy „nieznane” stanowi niewielki udział w przestojach.
Podsumowanie
Praktycznym pierwszym krokiem jest test brakujących stanów na jednej linii: zsumuj stany z jednej zmiany i sprawdź, czy pokrywają cały czas zmiany, a potem zobacz, jaka część przestojów trafia do „nieznane” i „inne”. Te dwie liczby pokażą, czy model stanów lub lista przyczyn wymagają poprawek, zanim skopiujesz konfigurację na kolejną linię.
Zamień sygnały z maszyn w decyzje
Umów 30-minutowe demo, aby zobaczyć model stanów, rejestrację przyczyn i Pareto na żywo w DBR77 IIoT oraz to, jak pasowałyby do Twoich linii.
Źródła
- Vorne, The Six Big Losses, 2026
- Vorne, Calculating OEE, 2026
- OMAC, PackML, 2026
- ISA, ISA-95 standard, 2026
- IETF, RFC 5905: Network Time Protocol Version 4, 2010
- Dane z pilotażu DBR77 IIoT, linia opakowań z tektury falistej (klient anonimowy), 2026