Od czujnika do pulpitu: potok MQTT przez Azure IoT Hub

Gdy maszyna się zatrzymuje, planista potrzebuje czegoś więcej niż czerwonej linii na pulpicie. Musi wiedzieć, co się zatrzymało, dlaczego się zatrzymało, które zlecenie znajduje się na tej linii i czy plan produkcji nadal może zostać zrealizowany. Przeniesienie surowych sygnałów z hali produkcyjnej do analityki w chmurze wymaga niezawodnej architektury obejmującej czujniki w terenie, przemysłowe bramy komunikacyjne, brokery komunikatów oraz warstwy wprowadzania danych do chmury.

PRZECHWYTYWANIE SYGNAŁU NA BRZEGU SIECI (EDGE)Sygnał z czujnika nie jest jeszcze informacją produkcyjną. Wyobraźmy sobie linię pakującą, na której temperatura silnika przenośnika przekracza normalne limity pracy. W tym momencie sterownik PLC przechowuje surową wartość znacznika — odczyt temperatury, znacznik czasu i stan jakości.

Starsze zakłady często działają na kilku generacjach urządzeń, korzystając z zastrzeżonych protokołów lub OPC UA, co oznacza, że sterowniki PLC rzadko komunikują się bezpośrednio przez MQTT w chmurze. Przemysłowa brama komunikacyjna wdrożona w sieci technologii operacyjnych (OT) wypełnia tę lukę, ponieważ:

• Normalizuje dane: tłumaczy różne formaty, skale i znaczniki inżynierskie na wspólną strukturę komunikatu.
  
• Zarządza częstotliwością zbierania: agreguje skany o wysokiej częstotliwości do sensownych interwałów, a zmiany stanu przekazuje natychmiast.
  
• Buforuje lokalnie: bezpiecznie przechowuje dane podczas awarii sieci i odtwarza je po przywróceniu łączności.
  

PRZESYŁANIE KOMUNIKATÓW Z MQTTGdy brama uformuje komunikat, publikuje go za pomocą MQTT (Message Queuing Telemetry Transport), lekkiego protokołu publikuj-subskrybuj dobrze przystosowanego do urządzeń o ograniczonych zasobach i niestabilnych łączy.

• Rozprzęgnięcie publikuj-subskrybuj: nadawcy wysyłają komunikaty do znanego tematu, bez potrzeby wiedzy o tym, które systemy lub aplikacje je odbiorą.
  
• Struktura tematów: tematy pełnią rolę adresów transportowych dla kategorii komunikatów, ale nie należy ich przeciążać, aby zastępowały pełny model zasobów fabryki.
  
• Kontrakty ładunku: treść komunikatu musi jednoznacznie zawierać stabilne identyfikatory zasobów źródłowych, wartości pomiarowe, jednostki, znaczniki czasu i flagi jakości.
  

ROLA AZURE IOT HUBPodczas gdy lokalne brokery MQTT obsługują ruch wewnętrzny zakładu, Azure IoT Hub pełni funkcję zarządzanej warstwy połączeń chmurowych dla flot przedsiębiorstwa.

• Tożsamość urządzeń i uwierzytelnianie: każda brama wymaga bezpiecznej, zarejestrowanej tożsamości urządzenia w IoT Hub, opartej na sygnaturach dostępu współdzielonego (SAS) lub certyfikatach X.509.
  
• Bezpieczeństwo transportu: połączenia opierają się na TLS (Transport Layer Security), chroniącym dane w trakcie przesyłu przez granice sieci i zapory.
  
• Wbudowane punkty końcowe: IoT Hub przyjmuje komunikaty urządzenie-chmura, opatruje je zaufanymi metadanymi połączenia i tymczasowo je przechowuje przed dalszym routingiem.
  

ROUTING, STRUMIENIOWANIE I DŁUGOTERMINOWE PRZECHOWYWANIEPrzychodzące dane telemetryczne obsługują wielu odbiorców w całej organizacji, dlatego routing komunikatów musi rozdzielać ruch na osobne ścieżki:

1. Przechowywanie surowej historii: kierowanie komunikatów do Azure Blob lub Data Lake Storage zachowuje niezmieniony ślad audytowy do przeglądów inżynierskich i ponownego przetwarzania.
   
2. Przetwarzanie strumieniowe: punkty końcowe takie jak Event Hubs zasilają konsumentów strumieniowych działających w czasie zbliżonym do rzeczywistego oraz reguły alertów informujące zespoły utrzymania ruchu o nieprawidłowych warunkach.
   
3. Modele analityczne: integracja strumieni danych z platformami takimi jak Microsoft Fabric pomaga połączyć telemetrię z kontekstem planowania i realizacji w przedsiębiorstwie.
   

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