Architektura sterowana zdarzeniami w produkcji to wzorzec danych, w którym maszyny publikują komunikat tylko wtedy, gdy następuje coś istotnego, zamiast być wielokrotnie pytanymi o status według stałego interwału.
Na nowoczesnej hali produkcyjnej setki czujników, sterowników PLC i kontrolerów maszyn chcą raportować stan, a sposób, w jaki przesyłasz te dane, decyduje o tym, czy Twoje pulpity są naprawdę w czasie rzeczywistym, czy cicho mają opóźnienie rzędu minut.
Sondowanie (polling), tradycyjne podejście, polega na tym, że każde urządzenie jest odpytywane według harmonogramu niezależnie od tego, czy cokolwiek się wydarzyło. Systemy sterowane zdarzeniami odwracają przepływ: źródło wypycha aktualizację w chwili jej wystąpienia, co skalowalnie sprawdza się o wiele lepiej wraz z dodawaniem maszyn.
Sondowanie wydaje się proste. Serwer pyta każde urządzenie „Jaka jest teraz twoja wartość?” co kilka sekund, zapisuje odpowiedź i powtarza. Problem w tym, że większość tych odpowiedzi jest identyczna z poprzednią. Silnik przenośnika, który pracuje stabilnie przez godzinę, i tak jest pytany setki razy, a każde zapytanie zużywa przepustowość sieci, CPU i zapis do bazy danych, mimo że stan się nie zmienił.
Koszt kumuluje się na trzy sposoby. Po pierwsze, opóźnienie jest ograniczone przez interwał sondowania: jeśli sondujesz co 5 sekund, mikropowstrzymanie, które zaczyna się jedną milisekundę po sondzie, jest niewidoczne przez prawie pełne 5 sekund. Po drugie, obciążenie sieci rośnie liniowo wraz z liczbą urządzeń razy częstotliwość sondowania.
Po trzecie, generujesz ogromne wolumeny redundantnych danych, które zwiększają koszty przechowywania i spowalniają każde zapytanie, które musi przez nie przesiać. Dla każdego, kto śledzi Overall Equipment Effectiveness , te pomijane krótkie przestoje bezpośrednio zaniżają Twoje straty dostępności.
Systemy sterowane zdarzeniami opierają się na dwóch wzajemnie się wzmacniających pomysłach:
Właśnie do tego celu zaprojektowano lekkie protokoły takie jak MQTT (często w parze ze specyfikacją Sparkplug dla przemysłowych ładunków). Broker siedzi pomiędzy brzegiem a przedsiębiorstwem, więc dodanie nowego konsumenta, na przykład aplikacji jakości monitorującej naruszenia reguł Nelsona, nie wymaga żadnych zmian po stronie maszyny. Różni się to od modelu żądanie-odpowiedź tradycyjnego systemu SCADA, gdzie logika sondowania i mapa tagów są ściśle powiązane z każdym klientem.
Załóżmy zakład z 200 maszynami, z których każda udostępnia 50 tagów i interwałem sondowania 1 sekundy. Sondowanie dotyka każdego tagu w każdym cyklu:
Teraz przełączmy się na raportowanie przez wyjątek przy tym samym wskaźniku zmian 2 procent, plus heartbeat raz na minutę na maszynę:
Wersja sterowana zdarzeniami nie tylko zmniejsza obciążenie, ale poprawia wierność danych. Ponieważ zmieniające się 2 proc. jest wysyłane natychmiast, opóźnienie spada z „do 1 sekundy” do milisekund i w końcu rejestrujesz zdarzenia podsekundowe, które sondowanie uśrednia. Mniej zapisów to także szybsza analiza Pareto największych przyczyn przestojów.
Metryki produkcyjne są tak wiarygodne, jak dane, które je zasilają. Mikro-przestoje krótsze niż 5 minut to klasyczna „ślepa plama”, i bezpośrednio przekładają się na straty prędkości i dostępności. Gdy sondowanie wygładza 3-sekundowe zablokowanie, które powtarza się 400 razy na zmianę, tracisz 20 minut udokumentowanego czasu przestoju, który nigdy nie trafia do Twojej analizy wskaźnika odpadów ani przepustowości.
Strumienie zdarzeń niosą też dokładne znaczniki czasu u źródła, dzięki czemu możesz odtworzyć dokładną sekwencję awarii: czujnik zadziałał, osłona otwarta, silnik zatrzymany, operator potwierdził. Taka uporządkowana oś czasu to surowiec do sensownych metryk MTBF i MTTR oraz do skrócenia czasu reakcji między wykryciem warunku a działaniem konserwacyjnym, które powinno być wyzwolone.
Zdarzenie ma wartość tylko wtedy, gdy coś je konsumuje. Najbardziej użytecznym konsumentem downstream jest często system utrzymania ruchu. Gdy przekroczony zostanie próg drgań lub maszyna opublikuje kod błędu, subskrybent może automatycznie otworzyć zlecenie pracy, dołączyć dane zdarzenia i skierować je do właściwego technika. To praktyczny most między sygnałami z hali a CMMS.
To także sposób, w jaki zespoły przechodzą od czysto reaktywnych praktyk w kierunku dyscyplin opisanych w utrzymaniu reaktywnym kontra proaktywnym oraz w utrzymaniu opartym na stanie. Warstwa sterowana zdarzeniami dostarcza sygnał o stanie; Twoje reguły i workflowy decydują, co z nim zrobić. Zauważ, że przekształcanie surowych zdarzeń w niezawodne prognozy awarii pozostaje zaawansowaną, opartą na modelach dyscypliną w całej branży, a nie czymś, co sama architektura automatycznie dostarcza.
Fabrico to baza danych w czasie rzeczywistym dla tego wzorca. Dostarcza OEE i monitorowanie produkcji w czasie rzeczywistym, dzięki czemu zdarzenia płynące z Twojej hali stają się żywymi danymi o dostępności, wydajności i jakości, a nie raportami po fakcie.
Tam, gdzie maszyna nie ma PLC, z którego mogłaby publikować, Fabrico dodaje wizję komputerową na maszynie, aby generować zmiany stanu bezpośrednio, co rozszerza widoczność sterowaną zdarzeniami na sprzęt, którego w żaden sposób nie dałoby się sondować.
Po stronie akcji, Fabrico to gotowy do użycia w terenie CMMS: zlecenia pracy, rejestry aktywów, harmonogramowanie prewencyjne i zarządzanie częściami zamiennymi, więc wykryty warunek może stać się zaplanowanym lub dystrybuowanym zadaniem. Fabrico jest zaprojektowane i zbudowane w UE z rezydencją danych w UE, co ma znaczenie, gdy Twój strumień zdarzeń niesie wrażliwe dane operacyjne.
Możesz zobaczyć, jak monitorowanie i utrzymanie łączą się w przeglądzie rozwiązania MES i OEE oraz w przeglądzie rozwiązania CMMS .
Nie uniwersalnie. Dla kilku wolno zmieniających się tagów, gdzie opóźnienie rzędu kilku sekund jest akceptowalne, sondowanie jest prostsze do zbudowania i zrozumienia. Architektura sterowana zdarzeniami wyraźnie wygrywa w miarę wzrostu skali, liczby urządzeń i potrzeby wierności podsekundowej, co opisuje większość nowoczesnych fabryk śledzących krótkie przestoje i szczegółowe przyczyny strat.
Dlatego sygnał życia jest obowiązkowy. Każde urządzenie publikuje okresowy komunikat liveness, aby system mógł odróżnić „wartość niezmieniona” od „urządzenie offline”. Buforowanie na brzegu z mechanizmem store-and-forward dodatkowo chroni przed krótkimi przerwami sieciowymi, przechowując komunikaty do czasu przywrócenia połączenia.
Tak. Maszyny bez PLC lub dostępnych tagów nie mogą publikować samodzielnie, ale wizja komputerowa może obserwować maszynę i emitować zdarzenia zmiany stanu (pracuje, zatrzymana, zablokowana) na podstawie tego, co widzi. To wprowadza sprzęt legacy i autonomiczny do tego samego strumienia czasu rzeczywistego, co zasoby sieciowe.
Gotowi, by zmienić zdarzenia z hali produkcyjnej w OEE na żywo i automatyczne zlecenia pracy? Zarezerwuj demo Fabrico i zobacz monitorowanie w czasie rzeczywistym oraz gotowy do użycia CMMS działające na Twoich maszynach.
Zaloguj
Blog
