La conception MQTT doit définir l’identité des appareils, la hiérarchie des sujets, les horodatages, la qualité, la QoS et la relecture hors ligne. Une meilleure QoS n’est pas automatiquement plus fiable car le stockage, les sessions et la déduplication de la plateforme comptent aussi.
Points clés
- Les sujets doivent être stables et évolutifs
- La télémétrie et les commandes doivent être séparées
- Les données hors ligne doivent conserver le temps d’acquisition initial
Principe technique et valeur du projet
La conception MQTT doit définir l’identité des appareils, la hiérarchie des sujets, les horodatages, la qualité, la QoS et la relecture hors ligne. Une meilleure QoS n’est pas automatiquement plus fiable car le stockage, les sessions et la déduplication de la plateforme comptent aussi. Dans un projet réel, les sujets doivent être stables et évolutifs, et la télémétrie ainsi que les commandes doivent être séparées doivent être considérées dans la même architecture. Commencez par la charge de travail, les dispositifs de terrain et le modèle opérationnel plutôt que par une seule spécification marketing.
Paramètres à confirmer lors de la mise en œuvre
Une séquence pratique consiste à confirmer le courtier, l’authentification et la convention du sujet, puis à vérifier le choix de la qualité de qualité et la taille/fréquence du message, et enfin tester les données hors ligne qui devraient conserver le temps d’acquisition initial avec l’équipement réel. Enregistrer les critères de réussite afin que la conception puisse être répétée sur plusieurs sites.
Pourquoi les tests à charge réelle sont nécessaires
Des files d’attente et des tentatives illimitées peuvent créer une rafale de récupération qui retarde les messages en temps réel. Le contenu public et les documents de projet doivent donc indiquer le modèle, le firmware, le réseau régional, les options et les conditions environnementales, et éviter des affirmations non vérifiables telles que « fonctionne pour chaque projet » ou « fiabilité absolue ».
Comment Tespro s’ajuste
Tespro TG-424 peut organiser les données de périphérie et les publier via des protocoles réseau liés au MQTT. Confirmez TLS, QoS, sessions persistantes et tampon par version logicielle.
Table de décision et de vérification
| Facteur de décision | Que vérifier |
| Les sujets doivent être stables et évolutifs | Confirmez contre le courtier et l’authentification et documentez les critères de réussite/échec lors du test pilote ou sur site. |
| La télémétrie et les commandes doivent être séparées | Confirmez contre la convention des sujets et documentez les critères de réussite/échec lors du test pilote ou sur site. |
| Les données hors ligne doivent conserver le temps d’acquisition initial | Confirmez contre le choix de la qualité de service et documentez les critères de réussite/échec dans le test pilote ou sur site. |
Liste de contrôle de compatibilité et de sélection
- ✓ Courtier et authentification
- ✓ Convention thématique
- ✓ Choix de QoS
- ✓ Taille/fréquence du message
- ✓ Fenêtre hors ligne
- ✓ Sécurité de commandement
Questions fréquemment posées
Q : Toutes les données industrielles doivent-elles utiliser la QoS 2 ?
R : Non. QoS 2 a une surcharge plus élevée et devrait correspondre aux besoins de déduplication et de fiabilité.
Q : La relecture hors ligne peut-elle créer des données dupliquées ?
R : Oui. La plateforme doit dédupliquer en utilisant l’identifiant de l’appareil, l’horodatage et la séquence.
Q : Les commandes MQTT peuvent-elles contrôler directement l’équipement ?
R : Ils ont besoin d’authentification, d’autorisation, de validation et de logique de sécurité locale avant toute action dangereuse.
