Construire un client MQTT non-bloquant pour systèmes embarqués réactifs

MQTT-Reactive est un client MQTT v3.1.1 léger, non-bloquant, construit sur la librairie MQTT-C de Liam Bindle. Conçu pour systèmes embarqués réactifs, il délivre une pile de communication portable, event-driven, intégrable dans toute application C-based.

Dans cet article, nous définissons d'abord ce qui constitue un système réactif, puis décrivons une architecture logicielle embrassant concurrence et comportement state-based. Finalement, nous parcourons un exemple concret — un dispositif IoT pour une compagnie ferroviaire — montrant comment employer MQTT-Reactive via une machine d'états et paradigme event-driven.

Les systèmes réactifs répondent à des événements internes ou externes, traitent l'événement, et retournent à un état idle attendant le prochain déclencheur. Ce paradigme event-driven yields code prévisible, maintenable, surtout quand multiples objets actifs (unités concurrentes) gèrent flux d'événements distincts.

Notre dispositif cas d'étude effectuait les tâches suivantes :

1. Détectait et loggait changements sur plusieurs entrées digitales
2. Acquérait, filtrait, et stockait multiples signaux analogiques
3. Transmettait périodiquement les données stockées vers un serveur distant
4. Échangeait données avec un broker via MQTT sur GSM

MQTT était choisi pour son modèle publish/subscribe léger, idéal pour liens low-bandwidth, high-latency comme GSM.

Parce que le firmware du dispositif était construit comme système réactif, la librairie MQTT-C originale requérait adaptation pour communiquer asynchrone via événements. La librairie résultante — MQTT-Reactive — expose une API propre invocable depuis une machine d'états tout en gardant le reste du système découplé.

Machine d'états

MQTT-Reactive est piloté par l'objet actif MqttMgr, dont le comportement est décrit par la machine d'états en Figure 1. La machine démarre en WaitingForNetConnection ; une fois liaison réseau disponible, elle transitionne vers WaitingForSync, où paquets CONNECT et PUBLISH peuvent être mis en scène. Événements arrivant en Sync sont différés jusqu'à ce que le système ré-entre un état les acceptant.

Tous les SyncTime millisecondes, la machine passe à l'état composite Sync, qui poste événements Receive et Send au gestionnaire réseau. Bien que l'exemple couvre CONNECT et PUBLISH, étendre le support à SUBSCRIBE est straightforward.

Les actions de la machine d'états utilisent le mot-clé params pour lire données d'événement et la macro GEN() pour générer événements sortants. Par exemple :

Connect(clientId, keepAlive)/ me->clientId = params->clientId; me->keepAlive = params->keepAlive; me->operRes = mqtt_connect(&me->client, me->clientId, NULL, NULL, 0, NULL, NULL, 0, me->keepAlive);

Dans cette transition, l'événement Connect porte les paramètres clientId et keepAlive appliqués aux attributs de l'objet MqttMgr. De même, événements sont dispatchés vers d'autres acteurs via :

GEN(me->itsCollector, Receive());

L'action par défaut définit un callback que MQTT-Reactive invoque quand le broker acquitte un CONNECT. Le callback doit générer soit ConnAccepted soit ConnRefused événements :

static void connack_response_callback(enum MQTTConnackReturnCode return_code) { if (return_code == MQTT_CONNACK_ACCEPTED) { GEN(me->itsCollector, ConnAccepted()); } else { GEN(me->itsCollector, ConnRefused(return_code)); } }

Figure 1. Machine d'états d'un client MQTT-Reactive (Source : VortexMakes)

Implémentation du modèle

La machine d'états peut être codée en C ou C++ pur en utilisant l'un des outils suivants : framework RKH, framework QP, Yakindu Statechart Tool, ou Rational Rhapsody Developer. Tous supportent Statecharts et génération de code pour C/C++.

L'objet actif MqttMgr encapsule tous les appels MQTT-Reactive, shieldant le reste du système de l'usage direct de l'API. La concurrence est achevée par échange d'événements, éliminant les pièges de sémaphores, mutex, délais, ou event-flags.

Attributs de MqttMgr sont stockés directement dans sa structure, ex. :

struct MqttMgr { struct mqtt_client client; // instance client MQTT LocalRecvAll localRecv; // buffer réception local /* items de données additionnels */ };

Ces membres sont accédés via le pointeur me :

mqtt_recvMsgError(&me->client, &me->localRecv);

Tableau 1. Attributs MqttMgr

Le système global inclut trois acteurs clés : Collector (publie données), NetMgr (gère le réseau), et MqttMgr (gère MQTT).

Figure 2. Ébauche de structure système IoT (Source : VortexMakes)

Le diagramme de séquence Figure 3 illustre le flux quand MqttMgr initie une session avec un broker MQTT.

Figure 3. Connexion à un broker MQTT (Source : VortexMakes)

Après établissement réseau réussi, Collector envoie Connect(clientId, keepAlive) à MqttMgr. Le broker peut répondre avec ConnAccepted ou ConnRefused, ce dernier portant un code de rejet per MQTT v3.1.1 §3.2.2.3.

Figure 4. Broker rejette une requête de connexion (Source : VortexMakes)

La publication suit un pattern similaire. Collector émet des événements Publish(data, size, topic, qos). La payload data, typiquement JSON, est assemblée usando la librairie légère jWrite.

Figure 5. Publication données vers un broker (Source : VortexMakes)

Les pannes réseau sont signalées par NetMgr via événements ReceiveFail ou SendFail, permettant à MqttMgr de réagir en conséquence.

Figure 6. Échecs réseau (Source : VortexMakes)

Tableau 2. Événements impliqués dans les scénarios

Conclusion

En encapsulant MQTT-Reactive dans un objet actif et orchestrant la communication via événements, l'approche élimine les constructs bloquants et yields un design propre, testable. Le modèle machine d'états scale vers multiples tâches concurrentes, le rendant well-suited pour applications embarquées réactives modernes requérant connectivité MQTT fiable.