Van sensor tot dashboard: de MQTT-pijplijn via Azure IoT Hub

Wanneer een machine stilvalt, heeft een planner meer nodig dan een rode lijn op een dashboard. Ze moeten weten wat er is stilgevallen, waarom het is stilgevallen, welke order op die lijn zit en of het productieplan nog steeds haalbaar is. Het verplaatsen van ruwe signalen van de fabrieksvloer naar cloudanalyse vereist een betrouwbare architectuur die veldsensoren, industriële gateways, message brokers en cloud-ingestielagen omvat.

HET SIGNAAL VASTLEGGEN AAN DE RANDA sensorsignaal is nog geen productie-informatie. Stel je een verpakkingslijn voor waarin de motortemperatuur van een transportband boven de normale bedrijfsgrenzen stijgt. Op dat moment bevat de programmeerbare logische controller (PLC) een ruwe tagwaarde, zoals een temperatuurmeting, een tijdstempel en een kwaliteitsstatus.

Oudere fabrieken draaien echter vaak meerdere generaties apparatuur met propriëtaire protocollen of OPC UA, wat betekent dat PLC's zelden rechtstreeks cloud-MQTT spreken. Een industriële gateway, uitgerold op het operationele technologie (OT)-netwerk, overbrugt deze kloof door:

• Gegevens normaliseren: Het vertalen van uiteenlopende formaten, schalen en engineeringtags naar een gemeenschappelijke berichtstructuur.
  
• De verzamelfrequentie beheren: Het samenvoegen van hoogfrequente scans tot zinvolle intervallen, terwijl statuswijzigingen onmiddellijk worden doorgestuurd.
  
• Lokaal bufferen: Gegevens veilig opslaan tijdens netwerkstoringen en ze veilig opnieuw afspelen zodra de verbinding terugkeert.
  

BERICHTEN VERPLAATSEN MET MQTTZodra de gateway een bericht heeft gevormd, publiceert deze het via MQTT (Message Queuing Telemetry Transport), een lichtgewicht publish-subscribe-protocol dat goed geschikt is voor beperkte apparaten en onbetrouwbare verbindingen.

• Publish-subscribe-ontkoppeling: Publishers sturen berichten naar een bekend onderwerp zonder te hoeven weten welke downstream-systemen of toepassingen ze consumeren.
  
• Onderwerpstructuur: Onderwerpen fungeren als transportadressen voor categorieën van berichten, maar ze mogen niet overbelast worden om als volledig fabrieksassetmodel te dienen.
  
• Payloadcontracten: De eigenlijke berichtinhoud moet expliciet stabiele bron-asset-identificaties, gemeten waarden, eenheden, tijdstempels en kwaliteitsvlaggen bevatten.
  

DE ROL VAN AZURE IOT HUBTerwijl lokale MQTT-brokers het interne fabrieksverkeer afhandelen, fungeert Azure IoT Hub als de beheerde cloudverbindingslaag voor bedrijfsvloten.

• Apparaatidentiteit en authenticatie: Elke gateway vereist een beveiligde, geregistreerde apparaatidentiteit in IoT Hub, via Shared Access Signatures (SAS) of X.509-certificaten.
  
• Transportbeveiliging: Verbindingen vertrouwen op TLS (Transport Layer Security) om gegevens onderweg te beschermen over netwerkgrenzen en firewalls heen.
  
• Ingebouwde eindpunten: IoT Hub accepteert apparaat-naar-cloud-berichten, voorziet ze van vertrouwde verbindingsmetadata en bewaart ze tijdelijk voordat ze verder worden gerouteerd.
  

ROUTEREN, STREAMEN EN LANGETERMIJNOPSLAGBinnenkomende telemetrie dient meerdere consumenten binnen de organisatie, waardoor berichtrouting nodig is om het verkeer over verschillende paden te verdelen:

1. Opslag van ruwe historie: Het routeren van berichten naar Azure Blob of Data Lake Storage behoudt een onveranderd auditspoor voor technische reviews en herverwerking.
   
2. Streamverwerking: Eindpunten zoals Event Hubs voeden bijna-realtime streamingconsumenten en waarschuwingsregels om onderhoudsteams te informeren over afwijkende situaties.
   
3. Analytische modellen: Het integreren van datastromen in platforms zoals Microsoft Fabric helpt telemetrie te combineren met enterprise-planning- en uitvoeringscontext.
   

Word supporter van deze podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.