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

Maszyna wysyła odczyty temperatury, dane o drganiach, liczniki cykli, zużycie energii i stany pracy co kilka sekund. Następnie brama nagle się rozłącza. Czy wszystkie te komunikaty to po prostu „zdarzenia”? Technicznie można je tak opisać. Architektonicznie może to prowadzić do poważnych problemów. Azure IoT Hub Message Routing i Azure Event Grid rozwiązują różne problemy. Jedna ścieżka jest zaprojektowana z myślą o zachowaniu i dystrybucji danych operacyjnych. Druga – o powiadamianiu systemów, że coś się zmieniło i może wymagać reakcji. Traktowanie ich jako wymiennych może skutkować kosztownymi przepływami pracy, które przetwarzają rutynowe dane z czujników, albo ważnymi sygnałami ukrytymi w potoku telemetrii, którego nikt aktywnie nie monitoruje. W tym odcinku M365 FM śledzimy maszynę produkcyjną w rzeczywistej architekturze Azure IoT i wyjaśniamy, gdzie faktycznie znajdują się IoT Hub, Event Grid, Event Hubs, Microsoft Fabric, Power BI, MES, ERP, Functions i Logic Apps.

CZEGO SIĘ NAUCZYSZ
W tym odcinku omawiamy:

• Dlaczego telemetria maszyn i dyskretne zdarzenia biznesowe lub cyklu życia wymagają różnych wzorców architektonicznych
• Jak Azure IoT Hub Message Routing działa jako część płaszczyzny danych telemetrycznych
• Gdzie Azure Event Grid pasuje w architekturach zdarzeniowych i reaktywnych
• Dlaczego kolejność komunikatów ma znaczenie dla telemetrii produkcyjnej
• Dlaczego Event Grid nie powinien stać się głównym magistralą telemetrii o dużej objętości
• Dlaczego routing IoT Hub nie powinien być wymuszany w każdym przepływie powiadomień
• Jak IoT Hub i Event Grid mogą współpracować w tej samej architekturze
• Jak Event Hubs może obsługiwać niezależnych konsumentów przetwarzania strumieniowego
• Dlaczego surowe dane telemetryczne powinny być często przechowywane w celu zapewnienia identyfikowalności i późniejszego badania
• Jak Microsoft Fabric i Power BI mogą wykorzystywać przygotowane dane operacyjne
• Dlaczego MES, ERP i modele zasobów zapewniają kontekst, którego same dane z urządzeń nie dostarczą
• Jak interpretować zdarzenia rozłączenia urządzenia bez automatycznego zakładania, że produkcja się zatrzymała
• Jak duplikaty dostaw, ponowne próby, znaczniki czasu i idempotentność wpływają na niezawodność przemysłowych architektur
• Jak projektować przepływy monitorowania stanu, utrzymania predykcyjnego, identyfikowalności jakości i zakłóceń produkcji
• Jak zdecydować, czy komunikat należy do płaszczyzny danych, ścieżki reakcji, czy obu

TELEMETRIA TO ZAPIS W CZASIE
Telemetria nie jest cenna dlatego, że nadszedł jeden odczyt temperatury. Staje się cenna, gdy tysiące odczytów razem opisują, co się wydarzyło. Maszyna produkcyjna może w sposób ciągły raportować:

• Pomiary temperatury i drgań
• Prąd silnika i zużycie energii
• Liczniki cykli i liczniki produkcji
• Stany pracy, bezczynności, zatrzymania lub awarii
• Znaczniki czasu źródła i informacje o sekwencji
• Informacje diagnostyczne i o stanie technicznym urządzenia

Pojedyncza wartość temperatury może wiele nie znaczyć. Historię opowiada sekwencja wokół tego odczytu. Czy maszyna się rozgrzewała? Czy już produkowała? Czy jednocześnie rosły drgania? Czy czas cyklu zaczął się wydłużać? Czy maszyna zatrzymała się krótko potem? Telemetria wymaga zatem ścieżki zaprojektowanej wokół sekwencji, retencji, odtwarzania, niezależnych konsumentów i identyfikowalności.

ZDARZENIA ISTNIEJĄ PO TO, BY URUCHOMIĆ REAKCJĘ
Zdarzenie służy innemu celowi. Zdarzenie mówi: coś się zmieniło. System lub osoba mogą potrzebować zareagować. Przykłady obejmują:

• Zarejestrowano nowe urządzenie
• Brama rozłączyła się z IoT Hub
• Urządzenie ponownie się połączyło
• Urządzenie zostało usunięte
• Proces monitorowania wykrył stan wymagający analizy
• Inspekcja została zakończona i może rozpocząć się kolejny przepływ pracy

Odbiorca zwykle nie potrzebuje godzin telemetrii, zanim rozpocznie pierwszy krok. Potrzebuje wystarczających informacji, aby określić, co się stało, i ustalić odpowiednią reakcję. Ta reakcja może obejmować:

• Uruchomienie Azure Function
• Wywołanie Logic App
• Otwarcie zgłoszenia do analizy
• Aktualizację rekordu zasobu
• Sprawdzenie bieżącego stanu urządzenia
• Wywołanie zewnętrznej aplikacji przez webhook
• Powiadomienie zespołu odpowiedzialnego za dotknięty system

Zdarzenie rozpoczyna analizę. Niekoniecznie zawiera wszystkie fakty potrzebne do podjęcia ostatecznej decyzji operacyjnej.

DLACZEGO „WSZYSTKO JEST ZDARZENIEM” SIĘ NIE SPRAWDZA
Wysyłanie każdego pomiaru z czujnika do przepływów wyzwalanych zdarzeniami może wyglądać atrakcyjnie podczas proof of concept. Następnie pojawia się skala produkcyjna. Każdy odczyt uruchamia kolejną Function. Kolejna Logic App ocenia coś innego. Kolejna integracja otrzymuje kolejny komunikat. Utrzymanie ruchu tworzy własną subskrypcję. Jakość tworzy kolejną. Zarządzanie energią – jeszcze jedną. Wkrótce każdy zespół ma nieco inne filtrowanie, obsługę stanu, ponowne próby i logikę przechowywania. Pomiar temperatury nie jest automatycznie incydentem. Może przyczynić się do incydentu później, ale ciągłe pomiary powinny pozostać dostępne jako dowód. Gdy rutynowa telemetria zaczyna generować stałe powiadomienia, użytkownicy mogą też zacząć ignorować alerty, ponieważ system nauczył ich oczekiwać szumu zamiast informacji wymagających działania.

CO FAKTYCZNIE ROBI AZURE IOT HUB
Azure IoT Hub zapewnia granicę chmury skierowaną do urządzeń. Obsługuje obszary takie jak:

• Bezpieczne tożsamości urządzeń
• Komunikację urządzenie-chmura
• Komunikację chmura-urządzenie
• Zarządzanie urządzeniami
• Device twins
• Kontrolowany dostęp między połączonym sprzętem a usługami Azure

IoT Hub wie, że uwierzytelnione urządzenie wysłało komunikat. Nie rozumie automatycznie, co ten komunikat oznacza dla produkcji. Brama może zgłosić: state = running Ale „running” może oznaczać:

• Produkcję zatwierdzonych części
• Suchy cykl
• Pracę ustawczą
• Wykonywanie przeróbki
• Ruch bez materiału

Ten kontekst zwykle pochodzi z dodatkowych systemów, takich jak MES, ERP, model zasobów lub aplikacja produkcyjna.

Zostań sympatykiem tego podcastu: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.