MQTT, HTTP, Modbus TCP ou OPC UA pour les passerelles IoT industrielles

Réponse courte

Le même capteur peut être livré de différentes façons

Un capteur ne détermine pas le protocole cloud final ou SCADA. RS485 Modbus RTU est couramment utilisé dans la couche terrain, tandis que la passerelle traduit ou reconditionne les données pour la couche d'application. Le bon protocole en amont dépend de le système qui déclenche la communication, où les données sont stockées, si les commandes doivent revenir vers l'équipement et quel logiciel le client utilise déjà.

MQTT: Meilleur pour les systèmes de publication et d'abonnement en cloud

MQTT sépare l'expéditeur et le destinataire par un courtier. La passerelle publie des données de capteur sur un sujet, tandis qu'une ou plusieurs applications s'y inscrivent. Ceci est utile pour les sites de surveillance distribués parce que la passerelle n'a pas besoin de connaître chaque consommateur final des données.

Une configuration MQTT correcte comprend normalement l'adresse du courtier, le port, l'ID du client, l'authentification et les règles de sujet. Une erreur courante est de supposer que le dispositif en ligne signifie que les données sont arrivées. Le statut de connexion MQTT prouve seulement qu'une session a été établie. La passerelle peut toujours publier sur le mauvais sujet, le serveur peut s'abonner à un autre sujet, ou la couche d'acquisition du capteur peut n'avoir aucune donnée valide.

Publier et s'abonner ne doit pas être confondu

Le sujet de publication est où l'appareil envoie la télémétrie. Le sujet d'abonnement est normalement utilisé pour les commandes ou les messages envoyés depuis la plateforme vers l'appareil. Si un serveur veut recevoir des mesures, il doit s'abonner au thème de publication de la passerelle. L'utilisation du même thème de publication et d'abonnement peut créer des boucles indésirables dans certaines implémentations et ne doit pas être traitée comme une configuration par défaut.

MQTTS et Port 8883

MQTTS signifie habituellement MQTT sur TLS. Port 8883 est un port TLS commun, mais l'utilisation réussie dépend de plus que le numéro de port. La bibliothèque TLS, la méthode de validation CA, le certificat serveur, le certificat client optionnel et la version MQTT doivent être compatibles. Dans le test réel tiers-cloud, une passerelle peut parfois se connecter à un courtier TLS mais échouer contre un autre jusqu'à ce que le firmware soit mis à jour.

Pour les projets de production, tester le courtier exact, le mode de certificat et le firmware avant d'expédier un grand lot. Les certificats doivent provenir ou correspondre au serveur du client ou à la plateforme cloud; ils ne sont pas des fichiers génériques qu'un fabricant de passerelles peut inventer indépendamment du serveur.

HTTP POST : Meilleur lorsque le client possède un point d'extrémité Web

HTTP est souvent l'option la plus simple lorsque le client a une application serveur qui peut recevoir des requêtes POST. La passerelle peut être configurée comme un client HTTP et envoyer périodiquement JSON vers une URL cible. Cela s'adapte aux backends web personnalisés et aux environnements où l'équipe du logiciel préfère le traitement direct des demandes/réponses au lieu d'exploiter un courtier MQTT.

Une charge utile typique peut contenir un horodatage, un identifiant de station et un objet params avec des valeurs de capteur. Les noms de champ exacts sont une convention de projet. L'étape importante consiste à convenir des types de données, des unités, du comportement des données manquantes et de la réponse du serveur avant le déploiement.

Modbus TCP: Meilleur quand SCADA ou PLC Si les données sont recueillies

Modbus TCP porte le modèle de registre Modbus familier sur Ethernet. Il convient souvent lorsqu'un système PLC, HMI ou SCADA est déjà conçu comme un maître Modbus. La passerelle peut relier les périphériques RTU RS485 Modbus vers le côté Ethernet ou exposer les valeurs collectées à travers une carte de registre définie.

Si le client dit : « Donnez-nous une adresse IP et indiquez-nous où chaque signal est stocké ; notre système le lira, » Modbus TCP est généralement plus proche de l'architecture requise que MQTT ou HTTP.

OIAC UA: Meilleur pour l'intégration industrielle plus riche

OIAC UA est largement utilisé dans les logiciels industriels parce qu'il peut présenter des données en tant que tags ou nœuds nommés avec structure et métadonnées au lieu de seulement adresses numériques de registre. Il peut être un bon ajustement pour SCADA, les intergiciels industriels et les applications PC qui nécessitent un comportement de découverte et d'abonnement standardisé.

Chaque passerelle ne prend pas en charge l'AU OPC dans le même rôle, alors confirmez si elle agit en tant que serveur UA OPC, client ou les deux. Dans les projets NiuBoL, des passerelles de bord plus capables sont préférées lorsque l'AU OPC est une exigence fondamentale.

Quel protocole choisir?

Ne pas mélanger le protocole de champ et le protocole en amont

Un système peut utiliser RS485 Modbus RTU depuis les capteurs jusqu'à la passerelle et MQTT depuis la passerelle jusqu'au cloud en même temps. Il peut également utiliser 4-20m Un capteur dans une passerelle ADC puis exposer ces valeurs via Modbus TCP ou OPC UA. L'interface de champ et le protocole d'application sont des couches de conception séparées.

Dépannage : MQTT connecté mais pas de données

1. Confirmer que la couche du capteur produit des données à l'intérieur de la passerelle.
2. Vérifiez l'intervalle de téléchargement et confirmez que la passerelle est publiée, pas seulement connectée.
3. Vérifier le sujet de publication exactement, y compris les principales coupures et la sensibilité des cas où le courtier/plateforme les traite différemment.
4. Utilisez un client MQTT indépendant pour vous abonner au même sujet et isoler la passerelle de la plateforme d'affaires.
5. Vérifiez l'authentification, les collisions d'ID client et si un autre client utilise les mêmes identifiants.
6. Pour TLS, vérifiez la compatibilité des certificats CA/serveur et les bibliothèques de firmware.
7. Utilisez les journaux de passerelle et, si nécessaire, la capture réseau pour déterminer si les paquets quittent le périphérique et comment le serveur répond.

Dépannage : Serveur HTTP ne reçoit rien

Première acquisition séparée du téléchargement. Si le journal de passerelle indique que le périphérique inférieur ne répond pas, corrigez la couche de communication du capteur avant de déboger le serveur. Ensuite, vérifiez l'URL cible, le port, l'accessibilité DNS/réseau, le type de contenu, le format JSON et les exigences HTTPS. La fonction HTTP passerelle de cette architecture est un client qui active les données POST ; il n'est pas automatiquement un serveur HTTP pour le client de naviguer.

FAQ

Q1. MQTT est-il meilleur que HTTP pour IoT ?

A1. Ni l'un ni l'autre n'est universellement meilleur. MQTT est fort pour les flottes de publication/abonnement; HTTP est simple lorsqu'un client a déjà un terminal de réception web.

Q2. Est-ce que MQTT "online" signifie que la plateforme a reçu des données de capteur?

R2. Non. Le statut en ligne ne confirme qu'une connexion. Le sujet, l'édition, l'abonnement et l'acquisition de capteurs doivent encore être vérifiés.

Q3. Quelle est la différence entre les thèmes de publication et d'abonnement du MQTT?

A3. Publier est l'endroit où la passerelle envoie la télémétrie; s'abonner est l'endroit où la passerelle écoute les messages ou les commandes du serveur à l'appareil.

Q4. Une passerelle IoT peut-elle envoyer JSON par HTTP POST ?

A4. Oui, sur les passerelles/firmware qui prennent en charge le téléchargement du client HTTP. D'accord sur la structure JSON exacte et la gestion des réponses avec l'équipe du serveur.

Q5. Le port 8883 est-il toujours pris en charge par MQTTS?

A5. 8883 est commun, mais le firmware de passerelle et le mode de certificat TLS doivent être compatibles avec le courtier cible.

Q6. Quand dois-je utiliser Modbus TCP au lieu de MQTT?

A6. Utilisez Modbus TCP lorsqu'un maître industriel tel que PLC ou SCADA doit s'enregistrer activement sur Ethernet.

Q7. Quand l'AU du Commissariat est-elle préférable?

R7. Utiliser l'AU du CPVP lorsque le logiciel industriel bénéficie de balises/noeuds normalisés, de métadonnées et d'une interopérabilité plus riche.

Q8. Une passerelle peut-elle utiliser plus d'un protocole en amont?

A8. Beaucoup de passerelles de bord peuvent, mais le comportement simultané multi-destination doit être vérifié pour le firmware exact et le projet.