Τι είναι το MQTT και γιατί το χρειαζόμαστε στο IIoT; Περιγραφή του πρωτοκόλλου MQTT

Παράλληλα με την ταχεία ανάπτυξη της βιομηχανίας, αυξάνεται ο αριθμός των συσκευών που απαιτούνται για τη διαχείριση και την παραλαβή των δεδομένων. Για την επίλυση ενός προβλήματος επικοινωνίας μεταξύ των πολυάριθμων συσκευών, καθώς και του προβλήματος συνδυασμού συσκευών σε ένα ενιαίο δίκτυο, δημιουργήθηκε η έννοια Internet of Things (IoT) – συνδυασμός των συσκευών σε ένα ενιαίο δίκτυο βάσει κάποιων χαρακτηριστικών, με αυτό το δίκτυο να συνδυάζεται περαιτέρω με παρόμοια δίκτυα, δημιουργώντας έτσι ένα μεγαλύτερο δίκτυο.

Σε τέτοια δίκτυα, οι συσκευές αλληλοεπιδρούν μεταξύ τους μέσω διαφόρων διεπαφών και πρωτοκόλλων επικοινωνίας. Δεδομένου ότι εξετάζουμε τη βιομηχανική εφαρμογή της έννοιας IoT, στην οποία πρέπει να χρησιμοποιούμε τον βιομηχανικό εξοπλισμό με δικά του πρωτόκολλα και hardware, ας χρησιμοποιήσουμε την έννοια IIoT (Industrial Internet of Things).

Για την επικοινωνία μεταξύ τους, οι συσκευές μπορούν να χρησιμοποιούν διάφορα βιομηχανικά πρωτόκολλα. Για αυτό το σκοπό, το MQTT είναι ένα από τα πιο δημοφιλή.

Τι είναι το MQTT;

MQTT ή Queue Telemetry Transport είναι ένα ελαφρύ συμπαγές πρωτόκολλο ανταλλαγής μηνυμάτων για την μεταφορά δεδομένων σε απομακρυσμένες τοποθεσίες όπου απαιτείται "αποτύπωμα μικρού κώδικα" ή το εύρος ζώνης του δικτύου είναι περιορισμένο. Αυτά τα πλεονεκτήματα επιτρέπουν την εφαρμογή αυτού του πρωτοκόλλου στα συστήματα M2M (Machine to Machine) και IIoT (Industrial Internet of Things).

Υπάρχει επίσης μια παραλλαγή του πρωτοκόλλου MQTT-SN (MQTT για τα δίκτυα αισθητήρων), γνωστή ως MQTT-S, η οποία έχει σχεδιαστεί για τις ενσωματωμένες ασύρματες συσκευές χωρίς υποστήριξη δικτύων TCP / IP, για παράδειγμα ZigBee.

Χαρακτηριστικά του πρωτοκόλλου MQTT

Βασικά χαρακτηριστικά του πρωτοκόλλου MQTT:

• Ασύγχρονο πρωτόκολλο
• Συμπαγή μηνύματα
• Λειτουργία σε συνθήκες ασταθούς σύνδεσης της γραμμής μετάδοσης των δεδομένων
• Υποστήριξη διαφόρων επιπέδων ποιότητας υπηρεσιών (QoS)
• Εύκολη ενσωμάτωση νέων συσκευών

Στο επίπεδο της εφαρμογής, το πρωτόκολλο MQTT λειτουργεί πάνω από το πρωτόκολλο TCP / IP και χρησιμοποιεί την θύρα 1883 (8883 εάν συνδέεται μέσω SSL) ως προεπιλογή.

Στο πρωτόκολλο MQTT, η ανταλλαγή των μηνυμάτων πραγματοποιείται μεταξύ του Client, που μπορεί να είναι Publisher ή Subscriber των μηνυμάτων, και Broker των μηνυμάτων (π.χ. Mosquitto MQTT).

Ο Publisher στέλνει τα δεδομένα σε Broker MQTT ορίζοντας ένα συγκεκριμένο θέμα στο μήνυμα. Οι Subscribers μπορούν να λαμβάνουν διάφορα δεδομένα από πολλούς Publishers, ανάλογα με τη συνδρομή σε αντίστοιχα θέματα.

Οι συσκευές MQTT χρησιμοποιούν ορισμένους τύπους μηνυμάτων για την επικοινωνία τους με τον Broker. Εδώ είναι οι βασικοί τύποι:

• Connect - δημιουργία σύνδεσης με το Broker μηνυμάτων
• Disconnect - διακοπή σύνδεσης με το Broker μηνυμάτων
• Publish - δημοσίευση δεδομένων σχετικά με κάποιο θέμα μέσα στο Broker μηνυμάτων
• Subscribe - Εγγραφή σε ένα θέμα στο Broker μηνυμάτων
• Unsubscribe - διαγραφή του θέματος

Σχέδιο απλής επικοινωνίας του Subscriber, του Publisher και του Broker

Σημασιολογία των θεμάτων

Τα θέματα είναι χαρακτήρες με κωδικοποίηση UTF-8. Η ιεραρχία των θεμάτων έχει μορφή δέντρου, διευκολύνοντας έτσι την οργάνωση και την πρόσβαση στα δεδομένα. Τα θέματα μπορούν να αποτελούνται από ένα ή περισσότερα επίπεδα που χωρίζονται με το σύμβολο «/».

Ακολουθεί παράδειγμα ενός θέματος, στο οποίο ένας αισθητήρας θερμοκρασίας που βρίσκεται στο υπνοδωμάτιο δημοσιεύει τα δεδομένα για τον Broker:

/home/living-space/living-room1/temperature

Ο συνδρομητής μπορεί επίσης να λαμβάνει δεδομένα από διάφορα θέματα ταυτόχρονα. Για αυτούς τους σκοπούς, δημιουργήθηκαν wildcards. Υπάρχουν δύο τύποι wildcards, ενός επιπέδου και πολυεπίπεδο. Για την καλύτερη κατανόηση, ας εξετάσουμε τα παραδείγματα καθενός από αυτούς:

• Wildcard ενός επιπέδου. Το σύμβολο συν «+» χρησιμοποιείται για την δημιουργία

  Για παράδειγμα, πρέπει να λάβουμε τα δεδομένα σχετικά με τη θερμοκρασία σε όλα τα υπνοδωμάτια:

  /home/living-space/+/temperature

  Ως αποτέλεσμα, λαμβάνουμε τα δεδομένα από τα θέματα:

  /home/living-space/living-room1/temperature

  /home/living-space/living-room2/temperature

  /home/living-space/living-room3/temperature

• Πολυεπίπεδο wildcard. Το σύμβολο «#» χρησιμοποιείται για την δημιουργία

  Για παράδειγμα, πρέπει να λάβουμε τα δεδομένα από διάφορους αισθητήρες σε όλα τα υπνοδωμάτια του σπιτιού:

  /home/living-space/#

  Ως αποτέλεσμα, λαμβάνουμε τα δεδομένα από τα θέματα:

  /home/living-space/living-room1/temperature

  /home/living-space/living-room1/light1

  /home/living-space/living-room1/light2

  /home/living-space/living-room1/humidity

  /home/living-space/living-room2/temperature

  /home/living-space/living-room2/light1

  …

Δομή των μηνυμάτων

Το μήνυμα MQTT αποτελείται από:

• Σταθερή κεφαλίδα (εμφανίζεται σε όλα τα μηνύματα)
• Μεταβλητή κεφαλίδα (εμφανίζεται σε μερικά μηνύματα)
• Δεδομένα, ωφέλιμο φορτίο (εμφανίζεται σε μερικά μηνύματα)

Σταθερή κεφαλίδα

Message Type – Τύπος μηνύματος, για παράδειγμα: CONNECT, SUBSCRIBE, PUBLISH, κλπ.

Flags specific to each MQTT packet – αυτά τα 4 δυφία χρησιμοποιούνται για βοηθητικές σημαίες, η παρουσία και η κατάσταση των οποίων εξαρτάται από έναν τύπο μηνύματος.

Remaining Length – τρέχον μήκος του μηνύματος (μεταβλητή κεφαλίδα + δεδομένα), το μέγεθος είναι από 1 έως 4 byte.

Συνολικά, υπάρχουν 15 τύποι μηνυμάτων στο πρωτόκολλο MQTT:

*C – Client, **S – Server

Ενδείκτες (Flags)

Τα πρώτα 4 πιο σημαντικά bits της σταθερής κεφαλίδας χρησιμοποιούνται ως συγκεκριμένοι ενδείκτες:

DUP – Το αντίγραφο ορίζεται όταν ένας client ή Broker MQTT πραγματοποιεί την επαναποστολή του πακέτου (χρησιμοποιείται σε PUBLISH, SUBSCRIBE, UNSUBSCRIBE, PUBREL). Εάν έχει οριστεί ο ενδείκτης, η μεταβλητή κεφαλίδα πρέπει να περιέχει Message ID (αναγνωριστικό μηνύματος).

QoS – Ποιότητα Υπηρεσιών (0,1,2)

RETAIN – κατά τη δημοσίευση των δεδομένων με ενδείκτη Retain, ο Broker θα το αποθηκεύσει. Όταν δημιουργηθεί μια νέα συνδρομή σε αυτό το θέμα, ο Broker θα στείλει αμέσως ένα μήνυμα με αυτόν τον ενδείκτη. Χρησιμοποιείται μόνο σε μηνύματα τύπου PUBISH.

Μεταβλητή κεφαλίδα

Η μεταβλητή κεφαλίδα υπάρχει σε ορισμένες κεφαλίδες.

Περιέχει τα ακόλουθα δεδομένα:

• Packet identifier - Αναγνωριστικό πακέτου, παρούσα σε όλους τους τύπους μηνυμάτων, εκτός από τα εξής: CONNECT, CONNACK, PUBLISH(с QoS <1), PINGREQ, PINGRESP, DISCONNECT
• Protocol name - Όνομα πρωτοκόλλου, εμφανίζεται μόνο στον τύπο μηνύματος CONNECT
• Protocol version - Έκδοση πρωτοκόλλου, εμφανίζεται μόνο στον τύπο μηνύματος CONNECT
• Connect flags - Ενδείκτες που απεικονίζουν τη συμπεριφορά ενός Client κατά τη σύνδεση

User name – αν ο ενδείκτης έχει οριστεί, θα πρέπει να υπάρχει ένα όνομα χρήστη στο ωφέλιμο φορτίο (χρησιμοποιείται για λόγους επαλήθευσης του Client)

Password – αν ο ενδείκτης έχει οριστεί, πρέπει να υπάρχει ένας κωδικός πρόσβασης στο ωφέλιμο φορτίο (χρησιμοποιείται για λόγους επαλήθευσης του Client)

Will Retain – εάν ο ενδείκτης έχει οριστεί σε 1, ο Broker αποθηκεύει ένα μήνυμα Will.

Will QoS– Ποιότητα εξυπηρέτησης για το μήνυμα Will. Εάν έχει οριστεί η σημαία Will, θα πρέπει να είναι παρόντες οι Will QoS και Will.

Will Flag - εάν ο ενδείκτης έχει οριστεί, τότε ο Πελάτης αποσυνδέει τον Broker χωρίς να αποστείλει την εντολή DISCONNECT (σε περίπτωση απρόβλεπτου τερματισμού λειτουργίας, σφάλματος κλπ.), ο Broker θα ενημερώσει όλους τους συνδεδεμένους Clients μέσω του αποκαλούμενου Will Message.

Clean Session – εάν αν ο ενδείκτης έχει οριστεί σε 0, ο Broker αποθηκεύει μια συνεδρία, όλες τις συνδρομές του Client και, με την επόμενη σύνδεση ο ενδείκτης, θα στείλει όλα τα μηνύματα από το QoS1 και QoS2 που ελήφθησαν από τον Broker ενώ αποσυνδέθηκε ένας Client. Συνεπώς, εάν ο Client έχει οριστεί σε 1, τότε από την επόμενη σύνδεση, ο Client θα πρέπει να εγγραφτεί ξανά σε όλα τα θέματα.

• Session Present – εφαρμόζεται σε ένα μήνυμα τύπου CONNACK. Εάν ο Broker δέχεται μια σύνδεση με το Clean Session = 1, θα πρέπει να ορίσει «0» bit στο Session Present (SP). Εάν ο Broker δέχεται μια σύνδεση με το Clean Session = 0, η τιμή που έχει οριστεί στο bit SP εξαρτάται από το αν ο Broker είχε ήδη αποθηκεύσει την συνεδρία με αυτόν τον Client (αν ναι, τότε το SP πρέπει να είναι 1 και αντίστροφα). Ο Session Present ενδείκτης επιτρέπει στον Client να γνωρίζει εάν υπάρχει ήδη μια αποθηκευμένη κατάσταση της περιόδου λειτουργίας.

• Connect Return code – αν για κάποιο λόγο ο Broker δεν μπορεί να λάβει ένα καλά διαμορφωμένο πακέτο CONNACK από τον Client, τότε στο δεύτερο byte του πακέτου CONNACK, θα πρέπει να ορίσει την κατάλληλη τιμή από τον παρακάτω πίνακα:

  Τιμή	Τιμή επιστροφής	Περιγραφή
  0	0x00 Connection Accepted	Η σύνδεση έγινε αποδεκτή
  1	0x01 Connection Refused, unacceptable protocol version	Ο Broker δεν υποστηρίζει την έκδοση του πρωτοκόλλου που ζητά ο Client
  2	0x02 Connection Refused, identifier rejected	Το Client ID για την σύνδεση δεν περιλαμβάνεται στη λίστα με επιτρεπόμενα IDs
  3	0x03 Connection Refused, Server unavailable	Το δικτύου συνδέθηκε, αλλά η υπηρεσία MQTT δεν είναι διαθέσιμη
  4	0x04 Connection Refused, bad user name or password	Λάθος το όνομα χρήστη ή ο κωδικός πρόσβασης
  5	0x05 Connection Refused, not authorized	Ο Client δεν έχει δικαίωμα σύνδεσης
  6-255		Προορίζεται για μελλοντική χρήση

• Topic Name – Όνομα θέματος

Δεδομένα, ωφέλιμο φορτίο

Το περιεχόμενο και η μορφή των δεδομένων που μεταδίδονται μέσω μηνυμάτων MQTT ορίζονται στη εφαρμογή. Το μέγεθος των δεδομένων μπορεί να υπολογιστεί αφαιρώντας το μήκος της μεταβλητής κεφαλίδας από το υπόλοιπο μήκος.

Ποιότητα εξυπηρέτησης στο πρωτόκολλο MQTT (QoS)

Το MQTT υποστηρίζει τρία επίπεδα ποιότητας εξυπηρέτησης (QoS) κατά την αποστολή των μηνυμάτων.

QoS 0 At most once. Σε αυτό το επίπεδο, ο Publisher στέλνει ένα μήνυμα στον Broker μία φορά και δεν περιμένει οποιαδήποτε απάντηση, δηλ. στέλνει και ξεχνάει γι 'αυτό.

QoS 1 At least once. Αυτό το επίπεδο εγγυάται την παράδοση του μηνύματος στον Broker, ωστόσο είναι δυνατή η επανάληψη των μηνυμάτων από τον Publisher. Μόλις ληφθεί ένα αντίγραφο, ο Broker στέλνει αυτό το μήνυμα στους Subscribers ξανά και προωθεί την επιβεβαίωση της παραλαβής του μηνύματος στον Publisher. Εάν ο Publisher δεν λάβει το μήνυμα PUBACK από τον Broker, θα προσπαθήσει να επαναποστέλλει αυτό το πακέτο, ορίζοντας DUP στο 1.

QoS 2 Exactly once. Σε αυτό το επίπεδο, η παράδοση του μηνύματος στον Subscriber είναι εγγυημένη, χωρίς την επαναποστολή αντιγράφων.

Ο Publisher στέλνει ένα μήνυμα στον Broker. Το μήνυμα περιέχει το μοναδικό πακέτο ID, QoS = 2 και DUP = 0. Ο Publisher αποθηκεύει το μήνυμα που δεν έχει αναγνωριστεί εκτός αν λάβει απάντηση PUBREC από τον Broker. Ο Broker απαντά με το μήνυμα PUBREC που περιέχει το ίδιο Packet ID. Αφού λάβετε αυτό το μήνυμα, ο Publisher στέλνει το PUBREL με το ίδιο Packet ID. Ο Broker πρέπει να αποθηκεύσει το αντίγραφο του μηνύματος μέχρι να πάρει PUBREL. Μόλις ο Broker λάβει PUBREL, διαγράφει το αντίγραφο του μηνύματος και στέλνει στο Publisher το μήνυμα PUBCOMP σχετικά με την ολοκλήρωση της συναλλαγής.