Comment un hub Azure IoT interagit-il avec les appareils Embedded / IoT?


13

Je travaille sur la plate-forme Azure IoT et je comprends comment les appareils envoient des données au hub IoT (si je ne me trompe pas, il s'agit simplement d'un appel de service Web ou de quelque chose de similaire).

Mais je me demande comment le hub IoT envoie des données / commandes / entrées aux appareils, car nous ne travaillons pas sur le hub IoT pour la communication entre appareils (nous n'avons aucune obligation de pousser les données vers les appareils). Le hub IoT peut-il interagir directement avec les appareils? (En utilisant l'identifiant unique de l'appareil ou en utilisant une identité unique comme IP, adresse Mac, etc.).

Quelque part, j'ai lu que les appareils continuent de demander au hub IoT si le hub IoT a une entrée pour eux, et le hub IoT envoie ensuite des données / commandes / entrées aux appareils en réponse. Est-ce vrai? Sinon, veuillez expliquer.

Réponses:


14

Le modèle utilisé par les appareils connectés IoT Hub est qu'ils n'accepteront jamais les connexions entrantes. Les appareils IoT Hub n'agissent jamais comme un `` serveur '', et c'est une partie cruciale du modèle de sécurité dans Azure IoT. Le modèle définitif à ce sujet est résumé dans la communication assistée par service de Clemens Vasters .

Par conséquent, les appareils «interrogent» toujours un service externe afin d'envoyer des données ou de recevoir des commandes. Les API donnent l'impression que des données sont envoyées à un appareil, mais c'est toujours l'appareil qui établit la connexion sortante.

Le hub IoT le fait de deux manières:

  1. En envoyant des données au terminal de l'appareil /devices/{deviceId}/messages/devicebound. Il s'agit d'un point de terminaison de messagerie AMQP, semblable à un abonnement de file d'attente ou de rubrique. L'appareil, lors de la lecture des commandes, doit accuser réception si nécessaire, ce qui fait partie du protocole AMQP sous-jacent. Cela fonctionne de la même manière avec MQTT, et https est une solution de rechange valide. L'API résume tout cela pour vous. Il existe des concepts supplémentaires, tels que les «méthodes directes» qui sont un wrapper API autour essentiellement du même protocole de message sous-jacent
  2. En utilisant le jumeau d'appareil côté serveur, qui est un moyen de maintenir logiquement les propriétés synchronisées entre l'appareil et le serveur. Vous définissez une propriété sur le jumeau d'appareil, et lorsque l'appareil se synchronise, cette propriété sera synchronisée avec l'appareil. Ceci est moins basé sur les messages et construit sur le protocole de gestion des périphériques LWM2M.

Une grande partie de l'interrogation, de la connexion, du partage des connexions, des reçus, etc. devrait être prise en charge dans le cadre du protocole AMQP (ou MQTT), qui à son tour est intégré au SDK IoT Hub. Donc, ce qui précède est très simplifié, mais pour réitérer, IoT Hub ne peut pas et n'essaiera (jamais) d'envoyer des données à une adresse / port IP sur votre appareil.


Merci @Simon, maintenant je suis clair à ce sujet, les appareils ne sont responsables que d'appeler le hub IoT pour envoyer ou recevoir des données. Vous avez mentionné «Azure IoT» dans votre réponse, alors vous voulez juste confirmer cela, votre application de réponse sur toutes les plateformes IoT? ou pour Azure IoT uniquement.
Shri

@ShrikantBhusalwad La réponse ne peut pas s'appliquer à toutes les plateformes, car beaucoup n'ont pas encore été développées. Il s'agit d'un modèle courant , il est bon pour la sécurité, mais d'autres modèles peuvent être justifiés - en particulier dans un nouvel environnement.
Sean Houlihane

2
Je ne connais pas toutes les plateformes, mais la plupart des plateformes cloud seront similaires. AWS utilise MQTT, qui est essentiellement le même. Comme l'observe @sean, il ne peut pas s'appliquer à toutes les plates-formes, mais très peu de plates-formes cloud impliqueront des pratiques de sécurité risquées. Les méthodes qui utilisent des modèles d'appareil en tant que serveur seront soit héritées, soit plus rigoureuses en termes de sécurité (à mesure que les modèles de bord ou de maillage se développent). Azure IoT prend en charge de manière architecturale les passerelles de terrain et de cloud pour contourner les problèmes avec les appareils hérités ou basés sur les périphéries
Simon Munro

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.