Routing wiadomości w IoT Hub a Event Grid — dlaczego telemetria i zdarzenia to nie ten sam problem

Temperatura, próbka wibracji, cykl maszyny i odłączenie urządzenia mogą wszystkie być opisywane jako zdarzenia, ale nie reprezentują tego samego problemu architektonicznego. W przemysłowym IoT i środowiskach produkcyjnych pomylenie ciągłej telemetrii z dyskretnymi zdarzeniami może prowadzić do zaszumionych przepływów pracy, niekompletnej historii produkcji, zbędnego przetwarzania oraz systemów reagujących bez wystarczającego kontekstu.

W tym odcinku rozkładamy na czynniki pierwsze architektoniczną różnicę między Azure IoT Hub Message Routing a Azure Event Grid, śledząc realistyczny scenariusz produkcyjny. Linia prasowa w sposób ciągły wysyła temperaturę, wibracje, licznik cykli, zużycie energii i informacje o stanie maszyny za pośrednictwem przemysłowej bramy (gateway). Te pomiary tworzą historię operacyjną, którą inżynierowie, zespoły danych, zespoły utrzymania ruchu i systemy produkcyjne mogą później analizować. Odłączenie urządzenia jest czymś innym, ponieważ reprezentuje zmianę, która może wymagać reakcji innego systemu lub osoby.

TELEMETRIA JEST ZAPISEM, NIE ALERTEM
Telemetria reprezentuje powtarzające się pomiary w czasie. Pojedyncza wartość temperatury czy pomiar wibracji zazwyczaj mówi bardzo niewiele sama w sobie. Prawdziwa informacja tkwi w sekwencji: jak szybko zmieniały się wartości, co maszyna robiła w danym momencie, co wydarzyło się przed zatrzymaniem, czy pomiary zniknęły podczas przerwy w sieci i czy to samo zachowanie pojawiło się w wcześniejszych cyklach produkcyjnych.


Typowa telemetria przemysłowa obejmuje:
• Temperaturę, wibracje, ciśnienie, zużycie energii i pobór prądu
• Stany maszyny, takie jak praca, bezczynność, zatrzymanie lub awaria
• Liczniki cykli, liczniki produkcji i pomiary procesowe
• Znaczniki czasu źródła, identyfikatory urządzeń, numery sekwencyjne i informacje korelacyjne

Te rekordy mogą później wspierać monitorowanie stanu, dochodzenia jakościowe, analizę energii, obliczenia OEE, analitykę Microsoft Fabric, raportowanie w Power BI oraz optymalizację produkcji. Dlatego telemetria wymaga retencji, odtwarzania, obsługi duplikatów, niezależnych konsumentów oraz niezawodnego sposobu rekonstrukcji osi czasu produkcji.

IOT HUB MESSAGE ROUTING JAKO PŁASZCZYZNA DANYCH TELEMETRYCZNYCH
Azure IoT Hub zapewnia kontrolowaną granicę komunikacji urządzenie-chmura. Urządzenia i bramy uwierzytelniają się za pomocą własnych tożsamości, wysyłają komunikaty urządzenie-chmura, utrzymują stan zarządzania urządzeniami i mogą uczestniczyć w kontrolowanej komunikacji chmura-urządzenie.

Gdy komunikat telemetryczny dotrze do IoT Hub, Message Routing określa, dokąd powinny trafić dane. Routing może sprawdzać właściwości komunikatu, właściwości systemowe, fragmenty treści komunikatu oraz informacje z device twin. Dzięki temu można rozdzielić klasy komunikatów, takie jak telemetria produkcyjna, pomiary energii czy diagnostyka, zanim dotrą do konsumentów.
Typowa architektura może wyglądać następująco: Przemysłowa brama → Azure IoT Hub → Message Routing → Event Hubs lub Storage → Przetwarzanie → Microsoft Fabric.

Jeden konsument może wykonywać analizę niemal w czasie rzeczywistym, a inny przechowuje surowe archiwum. Trzeci konsument może przygotowywać wyselekcjonowane dane operacyjne dla Microsoft Fabric. Każdy konsument może działać niezależnie, bez zamieniania każdego odczytu telemetrycznego w wywołanie przepływu pracy.

DLACZEGO KOLEJNOŚĆ MA ZNACZENIE
Telemetria przemysłowa jest szczególnie wrażliwa na sekwencję. Wyobraźmy sobie maszynę zgłaszającą wejście w stan pracy, następnie kilka liczników cykli, po nich odchylenie procesowe i w końcu stan zatrzymania. Jeśli te rekordy zostaną błędnie zrekonstruowane, system dalszego etapu może dojść do wniosku, że maszyna produkowała części podczas zatrzymania lub że odchylenie procesowe wystąpiło po zakończeniu produkcji.

Ten sam problem dotyczy obliczeń przestojów, OEE, liczników produkcji i monitorowania stanu. Dlatego trzeba rozróżniać, kiedy źródło zaobserwowało zdarzenie, kiedy IoT Hub otrzymał komunikat i kiedy system dalszego etapu go przetworzył.

Solidna architektura telemetrii powinna zatem uwzględniać:
• Znaczniki czasu źródła oraz znaczniki czasu odbioru w chmurze
• Stabilne partycjonowanie odpowiednie dla zasobu lub obciążenia
• Identyfikatory komunikatów lub numery sekwencyjne do wykrywania duplikatów
• Idempotentnych konsumentów zdolnych obsłużyć dostarczanie co najmniej raz (at-least-once)

Przerwy w sieci czynią to szczególnie istotnym. Brama może buforować telemetrię i wysyłać ją po powrocie łączności, co oznacza, że czas dotarcia do Azure może być znacznie późniejszy niż rzeczywisty znacznik czasu maszyny.

EVENT GRID ROZWIĄZUJE INNY PROBLEM
Azure Event Grid został zaprojektowany wokół powiadomień typu publish-and-subscribe. Zamiast nieustannie rekonstruować stan maszyny z tysięcy odczytów, Event Grid informuje zainteresowane systemy, że coś się zmieniło, i daje subskrybentom możliwość reakcji.
Przykłady w środowisku IoT obejmują utworzenie urządzenia, jego usunięcie, połączenie, odłączenie lub starannie wybrane warunki wynikające z telemetrii. Zdarzenie utworzenia urządzenia może uruchomić proces wdrożenia zasobu. Zdarzenie odłączenia urządzenia może rozpocząć dochodzenie techniczne. Wykryty warunek inżynierski może uruchomić przepływ pracy utrzymania ruchu.

Typowi subskrybenci obejmują:
• Azure Functions
• Logic Apps
• Webhooki
• Przepływy bezpieczeństwa
• Systemy zarządzania zasobami
• Aplikacje operacyjne

Fundamentalna różnica architektoniczna jest prosta: telemetria pyta, co zasób robił, podczas gdy zdarzenie pyta, co się zmieniło i czy coś powinno zareagować.

ZDARZENIA POWINNY URUCHAMIAĆ DOCHODZENIA, NIE DEFINIOWAĆ RZECZYWISTOŚCI
Event Grid należy generalnie traktować jako mechanizm powiadomień, a nie jako ostateczny, autorytatywny stan fizycznego świata. Dostarczanie zdarzeń może się powtarzać, a subskrybent nie powinien bezkrytycznie interpretować zdarzeń jako ostatecznego aktualnego stanu bez weryfikacji.
Zdarzenie odłączenia urządzenia powinno zatem zazwyczaj uruchamiać sprawdzenie stanu. Azure Function może zweryfikować bieżący stan urządzenia, przeanalizować ostatnią telemetrię, sprawdzić odpowiednie informacje w rejestrze, a następnie zdecydować, czy dochodzenie powinno pozostać otwarte.

Obsługa zdarzeń powinna być zaprojektowana wokół:
• Przetwarzania idempotentnego
• Weryfikacji stanu bieżącego
• Tożsamości zdarzenia i znaczników czasu
• Jasno określonej odpowiedzialności za wynikające z niego działanie

Ma to znaczenie, ponieważ zduplikowane zdarzenia nie powinny tworzyć zduplikowanych zgłoszeń, zduplikowanych alertów ani sprzecznych rekordów operacyjnych.

ODŁĄCZENIE URZĄDZENIA NIE OZNACZA ZATRZYMANIA MASZYNY
Jednym z najważniejszych rozróżnień w przemysłowym IoT jest różnica między łącznością z chmurą, kondycją zbierania danych a stanem produkcji. Jeśli przemysłowa brama odłączy się od IoT Hub, chmura traci widoczność tej bramy. Nie oznacza to automatycznie, że fizyczna maszyna się zatrzymała.

Sterownik PLC może nadal kontrolować urządzenie lokalnie, podczas gdy brama tymczasowo traci łączność. Produkcja może trwać normalnie, a brama może nawet buforować telemetrię i przesłać ją później. Może się również zdarzyć odwrotna sytuacja: brama pozostaje połączona z Azure, podczas gdy jej połączenie ze sterownikiem PLC lub lokalnym urządzeniem uległo awarii.

Użyteczna architektura rozdziela zatem stan połączenia z chmurą, kondycję bramy, stan produkcji maszyny i stan zlecenia w MES. Dopiero połączenie tych źródeł pozwala biznesowi ustalić, czy techniczny problem z łącznością faktycznie wpłynął na produkcję.

FILTROWANIE W IOT HUB KONTRA FILTROWANIE W EVENT GRID
Obie technologie wspierają filtrowanie, ale ich cel jest inny. Filtrowanie w IoT Hub Message Routing odpowiada na pytanie, które komunikaty operacyjne powinny trafić do konkretnej ścieżki danych. Filtrowanie subskrypcji Event Grid odpowiada na pytanie, które powiadomienia powinien otrzymać dany subskrybent.

Na przykład telemetria produkcyjna może trafiać do jednego strumienia Event Hubs, podczas gdy dane o energii trafiają do innego miejsca docelowego. Jednocześnie przepływ wsparcia może subskrybować wyłącznie zdarzenia odłączenia z określonej