Com o rápido desenvolvimento da indústria, o número de dispositivos necessários para a gestão e receção de dados também está a aumentar. A fim de resolver o problema da comunicação entre numerosos dispositivos e o problema da combinação de dispositivos numa única rede, foi criado o conceito de Internet das Coisas (IoT) - uma combinação ou caraterísticas de dispositivos numa única rede baseada em determinadas funções. Esta rede é posteriormente combinada com outras redes semelhantes, criando assim uma rede maior, e assim por diante.

Numa rede deste tipo, os dispositivos interagem entre si através de várias interfaces e protocolos de comunicação. Como estamos a considerar a implementação industrial do conceito de IoT, que deve utilizar equipamento industrial com os seus próprios protocolos e hardware, vamos começar a explorar o conceito IIoT (Industrial Internet of Things).
Para comunicar, os dispositivos podem utilizar vários protocolos industriais. Para este efeito, o MQTT é popular.
O que é o MQTT?
O MQTT ou Message Queuing Telemetry Transport é um protocolo de mensagens leve e aberto utilizado para a transferência de dados em locais remotos onde é necessária uma "pequena pegada de código" ou onde a largura de banda da rede é limitada. Estas vantagens permitem a implementação deste protocolo em sistemas M2M (Machine to Machine) e sistemas IIoT (Industrial Internet of Things).
Existe também uma variante do protocolo MQTT-SN (MQTT for Sensor Networks), anteriormente conhecido como MQTT-S, que foi concebido para utilização com dispositivos sem fios incorporados que não suportam redes TCP/IP, como o ZigBee.
Funções do protocolo MQTT
As principais funções do protocolo MQTT:
Protocolo assíncrono
Mensagens compactas
Funciona quando a ligação da linha de transmissão de dados é instável
Suportar vários níveis de qualidade de serviço (QoS)
Integrar facilmente novos dispositivos
Na camada de aplicação, o protocolo MQTT funciona sobre o protocolo TCP/IP e utiliza a porta 1883 por defeito (porta 8883 se a ligação for feita através de SSL).

No protocolo MQTT, a troca de mensagens ocorre entre um cliente (que pode ser um editor de mensagens ou um assinante de mensagens) e um corretor de mensagens (como o Mosquitto MQTT).
O editor envia dados para o MQTT Broker com um tópico explícito especificado na mensagem. Os subscritores podem receber vários dados de vários editores com base nas suas subscrições dos tópicos correspondentes.
Os dispositivos MQTT utilizam determinados tipos de mensagens para comunicar com os corretores. Os principais tipos são os seguintes:
Ligação - Estabelecer uma ligação ao Message Broker
Desconectar - Desconectar do corretor de mensagens
Publicar - publicar dados sobre um tópico no Message Broker
Subscrição - Subscrever um tópico no corretor de mensagens
Cancelar a subscrição - Cancelar a subscrição do tópico

A estrutura da mensagem
As mensagens MQTT contêm as seguintes partes:
Cabeçalho fixo (aparece em todas as mensagens)
Cabeçalhos variáveis (aparecem em algumas mensagens)
Dados, carga útil (presente em algumas mensagens)
cabeça fixa

Tipo de mensagem - por exemplo: CONNECT, SUBSCRIBE, PUBLISH, etc.
Sinalizadores exclusivos de cada pacote MQTT - Estes 4 bits são utilizados para sinalizadores auxiliares, cuja presença e estado dependem do tipo de mensagem.
Comprimento restante - Comprimento atual da mensagem (dados de cabeçalho variáveis), tamanho de 1 a 4 bytes.
No total, existem 15 tipos de mensagens no protocolo MQTT:
logótipo
Os primeiros 4 bits mais significativos do cabeçalho fixo são utilizados como sinalizadores específicos:

DUP - Duplicado é definido quando um cliente ou broker MQTT submete um pacote retransmitido (utilizado em PUBLISH, SUBSCRIBE, UNSUBSCRIBE, PUBREL). Se este sinalizador estiver definido, o cabeçalho da variável deve conter o ID da mensagem (identificador da mensagem).
QoS - Qualidade de serviço (0,1,2)
Retenção - Quando os dados são publicados com o sinalizador de retenção, eles serão armazenados pelo intermediário. O intermediário enviará uma mensagem com esse sinalizador assim que uma nova assinatura do tópico for estabelecida. Utilizado apenas em mensagens do tipo PUBISH.
título da variável
Existem cabeçalhos variáveis em alguns cabeçalhos.
Contém os seguintes dados:
Identificador de pacotes - presente em todos os tipos de mensagens, exceto: CONNECT, CONNACK, PUBLISH(сQoS <1), PINGREQ, PINGRESP, DISCONNECT
Nome do protocolo - mostrado apenas no tipo de mensagem CONNECT
Versão do protocolo - só existe no tipo de mensagem CONNECT
sinalizadores de ligação - sinalizadores que especificam o comportamento do cliente durante uma ligação

Nome de utilizador - Se este sinalizador estiver definido, deve estar presente um nome de utilizador na carga útil (para autenticação do cliente)
Palavra-passe - Se este sinalizador estiver definido, a palavra-passe tem de estar presente na carga útil (utilizada para autenticação do cliente)
Será retido - Se este sinalizador for definido como 1, o corretor armazenará uma mensagem Will.
QoS de Vontade - Qualidade de serviço da Mensagem de Vontade. Se o sinalizador Vontade estiver definido, a QoS Vontade e a Reserva Vontade têm de estar presentes.
Sinalizador Will - Se este sinalizador estiver definido, depois de um cliente se desligar do corretor sem enviar um comando DISCONNECT (em caso de encerramento imprevisível, falha, etc.), o corretor notificará todos os clientes ligados com uma mensagem chamada will.
Limpar sessão - Se este sinalizador for definido como 0, o broker armazena uma sessão, todas as subscrições do cliente serão enviadas na próxima ligação do cliente e, quando o cliente se desligar, o broker receberá todas as mensagens de QoS1 e QoS2. Portanto, se este sinalizador for definido como 1, na próxima ligação, o cliente terá de subscrever todos os tópicos novamente.
Existência da sessão - aplicada em mensagens do tipo CONNACK. Se o Broker aceitar ligações com Clean Session definida para 1, Session Present (SP) deve ser definida para 0. Se o Broker aceitar uma ligação com Clean Session definida para 0, o valor definido no SP depende do facto de o Broker ter armazenado o estado da sessão para este cliente (em caso afirmativo, o SP deve ser definido para 1 e vice-versa). O sinalizador de existência de sessão permite ao cliente determinar se o estado da sessão foi armazenado.
● Connection Return Code – If for some reason the proxy is unable to receive a well-formed CONNACK packet from the client, it must set the appropriate value in the second byte of the CONNACK packet in the following table:

data, payload
The content and format of data transferred via MQTT messages are defined in the device. The data size can be calculated by subtracting the length of the variable header from the remaining length.
Back to Contents
Quality of Service in MQTT Protocol (QoS)
MQTT supports three levels of quality of service (QoS) when sending messages.
QoS 0 at most once. At this level, the publisher sends one message at a time to the broker and does not wait for any response, ie send it and forget about it.

QoS 1 at least once. This level ensures that messages are delivered to the broker, but messages can be copied from the publisher. Once the copy is received, the broker sends the message to the Subscriber again and forwards the message receipt acknowledgment to the Publisher . If the publisher does not get a PUBACK message from the broker, it will attempt to re-deliver this packet, setting DUP to 1.

QoS 2 exactly once. At this level, message delivery to the client is guaranteed and duplicate copies are not possible.

The publisher sends a message to the broker. The message contains a unique packet ID, QoS=2 and DUP=0. The publisher stores unacknowledged messages unless it gets a PUBREC response from the broker. The proxy replies with a PUBREC message containing the same group ID. After receiving this message, the publisher sends a PUBREL with the same packet ID. The broker must store a copy of the message until it obtains a PUBREL. After the broker receives PUBREL, it deletes the message copy and sends a PUBCOMP message about the completed transaction to the publisher.
Keywords: Analog input and output module