Co się dzieje z danymi OEE, gdy sieć przestaje działać?

Najważniejsze wnioski

• Awaria traci zapisy, nie minuty. Linia i tak się zatrzymała; pytanie brzmi, czy ktoś o tym wie.
• Store and forward oznacza buforowanie na brzegu, a potem wysyłkę później, w kolejności.
• Stempluj czas u źródła, inaczej odtworzone zdarzenia trafią w złym czasie.
• MQTT ze Sparkplug informuje serwer, że bramka padła, nawet jeśli ktoś przeciął jej kabel.
• Przetestuj to w pilocie: odłącz kabel na godzinę i sprawdź raport.

Gdy łącze między linią a systemem OEE przerywa się, linia nadal pracuje i zatrzymuje się. Pytanie, czy te zatrzymania nadal są rejestrowane. Odpowiedź zależy od jednej funkcji bramki — store and forward. Bez niej raport zmiany ma dziurę lub fałszywe zatrzymanie.

Fabrico, OEE i lekki MES z kamerami AI, loguje przestoje automatycznie z sygnału maszyny. Jak bramka w twojej sieci radzi sobie z awarią, to pytanie do zespołu technicznego Fabrico. Ten przewodnik obejmuje, co pytać każdego dostawcę i jak testować odpowiedź.

Co idzie nie tak z danymi OEE, gdy sieć pada?

Bez bufora awaria może wyginać liczby na dwa przeciwne sposoby.

• Dziura czytana jest jako praca. Nie przychodzą żadne zdarzenia zatrzymania, więc zmiana wygląda lepiej niż była.
• Dziura czytana jest jako jedno długie zatrzymanie. Cała przerwa jest zaliczana jako przestój, więc zmiana wygląda gorzej.
• Późne zdarzenia mają zły czas. Jeśli serwer stempluje zdarzenia przy przyjściu, zatrzymanie o 10:05 pojawia się o 12:01.
• Wysłane ponownie zdarzenia się dublują. To samo zatrzymanie jest policzone dwa razy.
• Operatorzy nie mogą potwierdzić powodów, jeśli tablet na linii potrzebuje serwera do działania.

Każde z tych narusza zaufanie. Po jednym złym raporcie zmiany ludzie przestają wierzyć ekranowi.

Co to jest store and forward?

Store and forward oznacza, że bramka przechowuje każde zdarzenie w lokalnym magazynie, dopóki łącze jest przerwane. Gdy łącze wraca, wysyła zaległości w pierwotnej kolejności, z oryginalnymi znacznikami czasu.

Wiele przemysłowych bramek edge oferuje buforowanie offline, czasem jako płatny dodatek. Funkcja pomaga tylko, jeśli znaczniki czasu są ustawione u źródła. Zdarzenie oznaczone zegarem bramki jako 10:05 pozostaje zdarzeniem 10:05, kiedykolwiek przybędzie.

Jak MQTT mówi, że bramka jest offline?

MQTT to lekki protokół publish-subscribe, który wiele bramek używa do wysyłania danych z zakładu. Sparkplug B dodaje stałe nazwy tematów, stały format wiadomości i stan sesji na wierzch. Sparkplug 3.0 stał się standardem ISO/IEC 20237 w listopadzie 2023 r.

Dwie idee Sparkplug mają znaczenie przy awariach:

• Wiadomości birth i death. Bramka ogłasza się, gdy się łączy. Jej wiadomość o śmierci jest zarejestrowana u brokera z wyprzedzeniem jako MQTT "Will". Jeśli bramka upadnie bez pożegnania, broker wysyła tę wiadomość za nią, nawet jeśli kabel został przecięty.
• Report by exception. Bramka wysyła wartość tylko wtedy, gdy się zmienia, nie na stałym timerze. To utrzymuje backlog małym.

Dzięki temu serwer zawsze wie, która bramka jest milcząca i od kiedy. Nasze przewodniki po MQTT w produkcji i OPC UA vs MQTT omawiają protokoły bardziej szczegółowo.

Przykład: dwugodzinna awaria w jednej zmianie

Przykładowa linia (liczby ilustracyjne, nie klient). Napełniacz pracuje 480-minutową zmianę. Łącze do serwera OEE jest nieaktywne od 10:00 do 12:00. W tych 120 minutach napełniacz miał 9 zatrzymań o łącznej długości 26 minut. Poza awarią miał jeszcze 30 minut zatrzymań, czyli 56 minut przestoju w sumie.

Prawdziwa dostępność to (480 minus 56) / 480 = 424 / 480 = 88.3%. Oto co pokazuje raport w każdej konfiguracji:

Jedna awaria przesuwa liczbę o więcej niż 5 punktów w jedną lub drugą stronę. Tylko buforowana konfiguracja daje zmianie prawdziwy wynik i zachowuje wszystkie 9 zatrzymań dla kroku przyczyny.

Samo buforowanie jest małe. Przy report by exception dwie godziny zmian stanów i liczników z jednej linii to krótka lista zdarzeń, nie plik wideo.

O co zapytać dostawcę OEE o awarie?

1. Na ile godzin buforuje bramka? Powinna pokryć najdłuższą prawdopodobną awarię, np. weekend prac IT.
2. Czy każde zdarzenie zachowuje znacznik czasu źródła?
3. Czy backlog jest wysyłany w kolejności i czy duplikaty są usuwane?
4. Czy operatorzy nadal mogą potwierdzać powody na linii podczas awarii?
5. Jak system pokazuje, że bramka jest offline i kto jest o tym informowany?
6. Co się dzieje po przerwie zasilania, nie tylko po przerwie sieci?
7. Jak to testujemy? Uzgodnij pociągnięcie kabla podczas pilota.

Co fabryka może zrobić po swojej stronie?

• Trzymaj zegary zsynchronizowane. Skieruj PLC i bramki na serwer czasu zakładu.
• Zasil bramkę i jej switch z UPS, aby krótka przerwa zasilania nie była luką danych.
• Okabluj bramkę tam, gdzie możesz. Zaplanuj Wi-Fi dla tabletów i kamer oddzielnie.
• Alarmuj przy ciszy. Powiadom kogoś, gdy bramka była offline dłużej niż ustalony czas.

Miejsce przetwarzania danych też ma znaczenie. Nasz przewodnik po edge vs cloud dla danych z hali produkcyjnej wyjaśnia kompromisy, a IoT gateway vs edge device wyjaśnia sprzęt.

Gdzie mieści się Fabrico?

Fabrico to platforma do monitorowania wydajności produkcji z rozpoznawaniem obrazu. Jest warstwą OEE i przestojów lekkiego MES, z kamerami AI przy zatrzymaniach.

• Automatyczne logowanie przestojów z sygnału maszyny.
• Operator potwierdza przyczynę jednym tapnięciem, więc każde zatrzymanie ma swoją przyczynę.
• OEE na żywo według linii i zmiany, z każdą stratą wycenioną w pieniądzu.
• Pilot na jednej linii, właściwe miejsce, by przetestować awarię przed skalowaniem.

Zapytać zespół techniczny Fabrico, jak bramka w twojej sieci radzi sobie z awarią, a potem przetestować to na linii pilotażowej. Nie ma darmowego planu i nie ma poziomów: każda fabryka otrzymuje ofertę.

Najczęściej zadawane pytania

Czym jest store and forward w IIoT?

To funkcja bramki, która przechowuje dane w lokalnym magazynie, gdy sieć jest przerwana. Gdy łącze wraca, bramka wysyła przechowywane dane w ich pierwotnej kolejności i z oryginalnymi znacznikami czasu. Dla OEE oznacza to, że awaria nie zostawia dziury w dzienniku zatrzymań.

Czy dane OEE giną, gdy Wi-Fi przestaje działać?

To zależy od bramki. Z buforem i znacznikami czasu źródłowymi nic nie ginie; zdarzenia przychodzą z opóźnieniem, ale zachowują prawdziwy czas. Bez bufora zatrzymania podczas awarii znikają lub cały brak staje się jednym długim przestojem. Zapytaj dostawcę, który przypadek ma zastosowanie.

Jak długo bramka OEE powinna buforować dane?

Dostatecznie długo, by pokryć najdłuższą prawdopodobną awarię. Dla wielu zakładów to cały weekend, gdy IT często pracuje nad siecią. Zapytaj dostawcę o liczbę godzin dla twojej linii i sprawdź to podczas pilota z zaplanowanym odłączeniem kabla.

Co to jest MQTT death certificate?

To wiadomość, którą bramka Sparkplug rejestruje u brokera MQTT, kiedy się łączy, jako swój "Will". Jeśli bramka padnie bez czystego pożegnania, broker publikuje tę wiadomość za nią. Serwer wtedy wie, że bramka jest offline, nawet jeśli jej kabel został przecięty.

Czy OEE powinno być liczone na edge czy w chmurze?

Wiele systemów dzieli to. Edge rejestruje stany i liczniki z ich znacznikami czasu i przechowuje je podczas awarii. Serwer lub chmura oblicza OEE dla zmian, linii i zakładów. Najważniejsze jest to, by surowe zdarzenia były stemplowane i przechowywane u źródła.

Przetestuj awarię na swojej linii

Zabierz jedną linię i jej ostatni raport zmiany. Pokażemy, jak wygląda oś czasu, zatrzymanie po zatrzymaniu.

Zamów demo · Skontaktuj się z nami