À mesure que le secteur connaît un développement rapide, le nombre d'appareils nécessaires à la gestion et à la réception des données augmente également. Afin de résoudre le problème de la communication entre de nombreux appareils et celui de leur regroupement au sein d’un même réseau, le concept d’Internet des objets (IoT) a été créé : il s’agit d’un regroupement d’appareils au sein d’un même réseau, basé sur certaines fonctions. Ce réseau est ensuite combiné à d’autres réseaux similaires, créant ainsi un réseau plus vaste, et ainsi de suite.
Dans un tel réseau, les appareils interagissent entre eux par le biais de diverses interfaces et de différents protocoles de communication. Puisque nous nous intéressons à la mise en œuvre industrielle du concept d’IoT, qui devrait faire appel à des équipements industriels dotés de leurs propres protocoles et matériel, commençons par explorer le concept d’IIoT (Internet industriel des objets).
Pour communiquer, les appareils peuvent utiliser divers protocoles industriels. À cet effet, le protocole MQTT est très répandu.
Qu'est-ce que le protocole MQTT ?
MQTT (Message Queuing Telemetry Transport) est un protocole de messagerie léger et ouvert utilisé pour le transfert de données dans des environnements distants où une “ faible empreinte logicielle ” est requise ou lorsque la bande passante réseau est limitée. Ces avantages permettent la mise en œuvre de ce protocole dans les systèmes M2M (Machine to Machine) et les systèmes IIoT (Internet industriel des objets).
Il existe également une variante du protocole appelée MQTT-SN (MQTT pour les réseaux de capteurs), anciennement connue sous le nom de MQTT-S, qui est conçue pour être utilisée avec des appareils sans fil embarqués ne prenant pas en charge les réseaux TCP/IP, tels que ZigBee.
Fonctionnalités du protocole MQTT
Les principales fonctionnalités du protocole MQTT :
● Protocole asynchrone
● Messages courts
● Fonctionne lorsque la connexion de la ligne de transmission de données est instable
● Prise en charge de plusieurs niveaux de qualité de service (QoS)
● Intégrer facilement de nouveaux appareils
Au niveau de la couche application, le protocole MQTT s'appuie sur le Protocole TCP/IP et utilise le port 1883 par défaut (le port 8883 en cas de connexion via SSL).
Dans le protocole MQTT, l'échange de messages s'effectue entre un client (qui peut être un émetteur ou un abonné) et un courtier de messages (tel que Mosquitto MQTT).
L'éditeur transmet les données concernant le Courtier MQTT avec un sujet explicitement spécifié dans le message. Les abonnés peuvent recevoir diverses données provenant de plusieurs éditeurs, en fonction de leurs abonnements aux sujets correspondants.
Les appareils MQTT utilisent certains types de messages pour communiquer avec les brokers. Les principaux types sont les suivants :
● Connexion – Établir une connexion avec Message Broker
● Déconnexion – Se déconnecter du courtier de messages
● Publier – publier des données sur un sujet dans Message Broker
● Abonnement – S'abonner à un sujet sur le courtier de messages
● Se désabonner – Se désabonner de ce sujet
La structure du message
Les messages MQTT comportent les éléments suivants :
● En-tête fixe (apparaît dans tous les messages)
● En-têtes variables (apparaissent dans certains messages)
● Données, charge utile (présente dans certains messages)
1. Tête fixe
Type de message – par exemple : CONNECT, SUBSCRIBE, PUBLISH, etc.
Indicateurs propres à chaque paquet MQTT – Ces 4 bits sont utilisés pour des indicateurs auxiliaires, dont la présence et l'état dépendent du type de message.
Longueur restante – Longueur actuelle du message (données d'en-tête variables), taille comprise entre 1 et 4 octets.
Au total, le protocole MQTT comporte 15 types de messages :
| Type de message | Valeur | Direction | Description |
|---|---|---|---|
| Réservé | 0000 (0) | Interdit | Réservé |
| CONNECTER | 0001 (1) | C → S | Demande de connexion émanant du client |
| CONNACK | 0010 (2) | S → C | Accusé de réception de la connexion |
| PUBLIER | 0011 (3) | C ↔ S | Publier un message |
| PUBACK | 0100 (4) | C ↔ S | Publier les remerciements |
| PUBREC | 0101 (5) | C ↔ S | Publication reçue (QoS 2, étape 1) |
| PUBREL | 0110 (6) | C ↔ S | Publier la version (QoS 2, étape 2) |
| PUBCOMP | 0111 (7) | C ↔ S | Publication terminée (QoS 2, étape 3) |
| S'ABONNER | 1000 (8) | C → S | Demande d'abonnement d'un client |
| SUBACK | 1001 (9) | S → C | Accusé de réception de l'abonnement |
| SE DÉSABONNER | 1010 (10) | C → S | Demande de désabonnement |
| UNSUBACK | 1011 (11) | S → C | Accusé de réception de la désinscription |
| PINGREQ | 1100 (12) | C → S | Requête Ping |
| PINGRESP | 1101 (13) | S → C | Réponse Ping |
| DÉCONNECTER | 1110 (14) | C → S | Demande de désabonnement de la part du client |
| Réservé | 1111 (15) | Interdit | Réservé |
Les 4 premiers bits les plus significatifs de l'en-tête fixe sont utilisés comme indicateurs spécifiques :
DUP – L'indicateur « Duplicate » est activé lorsqu'un client ou un courtier MQTT envoie un paquet retransmis (utilisé dans les commandes PUBLISH, SUBSCRIBE, UNSUBSCRIBE et PUBREL). Si cet indicateur est activé, l'en-tête « variable » doit contenir l'ID du message (identifiant du message).
QoS – Qualité de service (0, 1, 2)
Fidélisation – Lorsque des données sont publiées avec l'indicateur de conservation, elles sont stockées par le courtier. Ce dernier envoie un message comportant cet indicateur dès qu'un nouvel abonnement au sujet est établi. Utilisé uniquement dans les messages de type PUBISH.
2. Titre de la variable
Certains en-têtes comportent des en-têtes variables. Ceux-ci contiennent les données suivantes :
● Identifiant de paquet – présent dans tous les types de messages, à l'exception des suivants : CONNECT, CONNACK, PUBLISH (avec QoS < 1), PINGREQ, PINGRESP, DISCONNECT
● Nom du protocole – n'apparaît que dans le type de message CONNECT
● Version du protocole – n'existe que dans le type de message CONNECT
● indicateurs de connexion – indicateurs qui définissent le comportement du client lors d'une connexion
Nom d'utilisateur – Si cet indicateur est activé, un nom d'utilisateur doit figurer dans la charge utile (pour l'authentification du client)
Mot de passe – Si cet indicateur est activé, le mot de passe doit figurer dans la charge utile (utilisée pour l'authentification du client)
Sera conservé – Si cet indicateur est défini sur 1, le courtier enregistrera un message « Will ».
Will QoS – Qualité de service « Will Message ». Si l'indicateur « Will » est activé, les paramètres « Will QoS » et « Will Reservation » doivent être présents.
À signaler – Si cet indicateur est activé, lorsqu’un client se déconnecte du courtier sans envoyer de commande DISCONNECT (en cas d’arrêt imprévisible, de panne, etc.), le courtier en informera tous les clients connectés au moyen d’un message dit « will ».
Session propre – Si cet indicateur est défini sur 0, le broker enregistre une session ; tous les abonnements du client seront transmis lors de la prochaine connexion de ce dernier, et lorsque le client se déconnectera, le broker recevra tous les messages provenant de QoS1 et QoS2. Par conséquent, si cet indicateur est défini sur 1, lors de sa prochaine connexion, le client devra s'abonner à nouveau à tous les sujets.
● Existence de la session – utilisé dans les messages de type CONNACK. Si le Broker accepte les connexions avec le paramètre « Clean Session » défini sur 1, le paramètre « Session Present » (SP) doit être défini sur 0. Si le courtier accepte une connexion avec « Clean Session » défini sur 0, la valeur définie pour SP dépend du fait que le courtier ait ou non stocké l’état de session pour ce client (si c’est le cas, SP doit être défini sur 1, et inversement). L’indicateur d’existence de session permet au client de déterminer si l’état de session a été stocké.
● Code de retour de connexion – Si, pour une raison quelconque, le proxy ne parvient pas à recevoir un paquet CONNACK correctement formé de la part du client, il doit définir la valeur appropriée dans le deuxième octet du paquet CONNACK, conformément au tableau suivant :
| Valeur | Code de retour de la réponse | Description |
|---|---|---|
| 0 | 0x00 – Connexion acceptée | Connexion établie |
| 1 | 0x01 – Connexion refusée : version de protocole non acceptée | Le courtier ne prend pas en charge la version du protocole demandée |
| 2 | 0x02 – Connexion refusée : identifiant rejeté | L'identifiant client n'est pas valide ou n'est pas autorisé |
| 3 | 0x03 – Connexion refusée : serveur indisponible | Le courtier n'est pas disponible |
| 4 | 0x04 – Connexion refusée : nom d'utilisateur ou mot de passe incorrect | Nom d'utilisateur ou mot de passe incorrect(e) |
| 5 | 0x05 – Connexion refusée : non autorisée | Le client n'est pas autorisé à se connecter |
| 6–255 | Réservé à un usage futur |
Le contenu et le format des données transmises via des messages MQTT sont définis dans l'appareil. La taille des données peut être calculée en soustrayant la longueur de l'en-tête variable de la longueur restante.
3.Données, charge utile
La charge utile correspond aux données de niveau application contenues dans un message MQTT. Elle n'est incluse que dans certains types de messages spécifiques, tels que les messages PUBLISH, CONNECT (champs d'authentification) et Will. La norme MQTT ne définit pas de structure fixe pour la charge utile : son contenu et son format sont déterminés par l'appareil ou l'application.
Selon le cas d'utilisation, la charge utile peut contenir des données de capteurs, des objets JSON, des données de télémétrie binaires, des valeurs de commande ou des informations d'authentification telles que le nom d'utilisateur, le mot de passe ou le message « Will ». La longueur de la charge utile est calculée en soustrayant la taille de l'en-tête variable du champ « Longueur restante » de l'en-tête fixe.
Qualité de service dans le protocole MQTT (QoS)
MQTT prend en charge trois niveaux de qualité de service (QoS) lors de l'envoi de messages.
QoS 0 : une seule fois au maximum. À ce niveau, l'éditeur envoie un message à la fois au courtier et n'attend aucune réponse ; en d'autres termes, il l'envoie et ne s'en soucie plus.
QoS 1 au moins une fois. Ce niveau garantit que les messages sont transmis au broker, mais ceux-ci peuvent être copiés depuis l'éditeur. Une fois la copie reçue, le courtier renvoie le message à l’abonné et transmet l’accusé de réception du message à l’éditeur. Si l’éditeur ne reçoit pas de message PUBACK de la part du courtier, il tentera de renvoyer ce paquet en définissant DUP sur 1.
QoS 2 : « une seule fois ». À ce niveau, la transmission du message au client est garantie et aucune duplication n'est possible.
L'éditeur envoie un message au courtier. Le message contient un identifiant de paquet unique, QoS=2 et DUP=0. L'éditeur stocke les messages non acquittés tant qu'il n'a pas reçu de réponse PUBREC de la part du courtier. Le proxy répond par un message PUBREC contenant le même identifiant de groupe. Après avoir reçu ce message, l'éditeur envoie un PUBREL avec le même identifiant de paquet. Le courtier doit stocker une copie du message jusqu'à ce qu'il reçoive un PUBREL. Une fois le PUBREL reçu, le courtier supprime la copie du message et envoie à l'éditeur un message PUBCOMP indiquant que la transaction est terminée.
