Les outils de développement et de prototypage actuels (Arduino, Raspberry Pi, Beaglebone, Galileo) permettent de proposer des solutions innovantes à faible coût ayant pour conséquence un foisonnement de projets dans le domaine de l’IoT.

En effet, pour une centaine d’euros, il est possible aujourd’hui de déployer quelques capteurs, de collecter les données de ces capteurs, de les analyser et de construire des services à partir de ces données.

Cette démocratisation de l’IoT ne peut que nous réjouir chez Frugal Prototype ! 

Cependant, pour un déploiement massif de l’IoT, les chantiers sont encore nombreux : éthique et vie privée, sécurité, autonomie des équipements, analyse des masses de données générées (Big Data), sans oublier la standardisation qui demeure encore aujourd’hui le talon d’Achille de l’IoT.

Avec la quantité de protocoles qui gravitent autour de l’IoT, il est très difficile pour un néophyte de s’y retrouver et de savoir par où commencer.

Je vais donc vous présenter dans cet article quelques protocoles applicatifs utiles pour la réalisation de vos prototypes. Ces protocoles sont conçus spécifiquement pour les équipements à ressources limitées en capacité mémoire, en puissance de calcul et en énergie .

Je ne traiterai ici que de quelques protocoles applicatifs : CoAP, MQTT, XMPP et AMQP ; sachant qu’il y en a pléthore !

Les protocoles radio (LoRa, SigFox, etc.), quant à eux, feront l’objet d’un prochain article.

Le choc des architectures

Les protocoles présentés dans cet article reposent sur deux types distincts d’architecture : l’architecture Request/Response et l’architecture Publish/Subscribe.

La première est l’architecture traditionnelle, celle que vous utilisez lorsque vous consultez ce blog : le client (votre navigateur) émet des requêtes à destination du serveur qui héberge ce blog, lequel lui répond le contenu demandé. Le protocole HTTP, largement utilisé pour l’Internet, repose sur cette architecture.

La seconde architecture, Publish/Subscribe, permet, quant à elle, à un client – un capteur de température par exemple – de publier un message sur le réseau sans se soucier des destinataires du message ; le client est alors ce qu’on appelle un « publisher ». Le client « publisher » publie son message sur un topic auquel peuvent être abonnés les clients qui souhaitent recevoir le message. Les clients abonnés au topic sont les « subscribers » de ce topic. Des mécanismes permettent de réserver la souscription aux topics aux seuls clients autorisés. Le lien entre les « publishers » (ceux qui publient) et les « subscribers » (ceux qui souscrivent) est assuré par un « broker » dont la principale fonction est de distribuer les messages publiés sur un topic aux abonnés de ce topic (les subscribers).

Architecture Request/Response

CoAP (Constrained Application Protocol)

Le CoAP est un protocole conçu par l’IETF (Internet Engineering Task Force) basé sur une architecture Request/Response.

Ce protocole reprend en partie les concepts et la terminologie du protocole HTTP (GET, PUT, POST et DELETE) en allégeant considérablement les échanges, notamment en s’appuyant sur le protocole UDP plutôt que sur le protocole TCP.

Cette proximité avec le protocole HTTP rend le développement de passerelles entre ces deux protocoles relativement aisé.

Les paquets CoAP sont beaucoup plus petits que les paquets HTTP ; l’en-tête d’un message traditionnellement utilisé pour les messages HTTP est remplacé par un en-tête fixe de 4 octets plus adapté aux faibles ressources des équipements de l’IoT.

Dans l’en-tête de chaque paquet, deux bits indiquent le type de message et la qualité de service souhaitée pour la transmission du message.

  • Confirmable: Message envoyé avec une demande d’acquittement.
  • Non-Confirmable: Message envoyé sans demande d’acquittement.
  • Acknowledgment: Confirmation de la réception d’un message de type « confirmable ».
  • Reset: Confirmation de la réception d’un message qui n’est pas exploitable.

 

Principe de fonctionnement du protocole CoAP
Principe de fonctionnement du protocole CoAP

 

Je n’ai pas encore utilisé ce protocole pour un prototypage, je n’ai donc malheureusement pas de retour d’expérience à partager avec vous ; mais ça ne saurait tarder.

Quelques ressources pour prototyper avec CoAP :

 

Architecture Publish/Subscribe

MQTT (Message Queuing Telemetry Transport)

Le MQTT, développé à l’origine par Arcom et IBM (pour une « smarter planet ») dans la fin des années 90, est un protocole de messagerie simple et léger, basé sur une architecture « publish/subscribe » spécifiquement conçu pour des applications M2M (Machine To Machine).

L’intérêt majeur d’utiliser ce protocole dans vos applications est la notification en temps réel de la publication des nouvelles données sans devoir constamment interroger un serveur : cela apporte de la réactivité à vos applications sans surcharger le serveur de requêtes inutiles.

 

Principe de fonctionnement du protocole MQTT
Principe de fonctionnement du protocole MQTT

 

Trois niveaux de qualité de service « QoS » sont prévus pour la transmission des messages :

  • – Fire and forget: le message est envoyé une fois et aucun acquittement n’est exigé.
  • – Delivered at least once : le message est envoyé au moins une fois et un acquittement est exigé.
  • – Delivered exactly once : un mécanisme en quatre temps assure la délivrance du message une seule et unique fois.

Encore plus léger, une version optimisée du protocole MQTT, adaptée aux objets à très faibles ressources communiquant sans fil, est spécifiée sous le nom MQTT-SN (MQTT for Sensor Network).

Pour la petite histoire, j’ai initié en 2011, un projet de maison intelligente qui s’est matérialisé par trois éditions, chacune amenant des évolutions et des innovations supplémentaires. Pour la dernière édition (la SmartHome 3.0), j’avais fait le choix d’utiliser le protocole MQTT pour l’intégralité des communications entre les objets et les applications. Très facile à déployer, il a permis aux partenaires du projet de recevoir les données des capteurs de la SmartHome et de construire des services autour de ces données. Je l’ai depuis souvent utilisé pour plusieurs de mes prototypes.

Quelques ressources pour prototyper avec MQTT :

 

XMPP (Extensible Messaging and Presence Protocol)

Le XMPP est un protocole conçu à l’origine pour la messagerie instantanée (Google Talk, Jabber, iChat).

Comme son nom l’indique, XMPP est extensible, offrant ainsi la possibilité d’ajouter un certain nombre d’extensions pour réaliser des applications diverses ( VOIP, transfert de fichiers, ..). Ces extensions lui permettent de supporter aussi bien l’architecture request/response que publish/subscribe.

Ce protocole repose sur l’échange décentralisé de flux d’éléments et de données au format XML entre clients en quasi-instantané.

xmppschema
Principe de fonctionnement du protocole XMPP

 

Pour l’avant dernière édition de la Smarthome (la Smarthome 2.0), j’avais fait le choix de ce protocole pour la communication entre les applications et pour l’interconnexion avec les applications des partenaires du projet.

Pour ne rien vous cacher, j’ai une préférence pour le MQTT, beaucoup plus léger et simple à mettre en œuvre pour la communication entre objets.

Quelques ressources pour prototyper avec XMPP :

 

AMQP (Advanced Message Queuing Protocol)

Enfin le protocole AMQP, originaire du monde de la finance, est dans son principe de fonctionnement assez proche du protocole MQTT.

AMQP apporte un mécanisme supplémentaire de « files d’attente ». En effet, les clients qui émettent des messages sont appelés des « producers ». Ces messages sont dirigés vers une ou plusieurs files d’attente. Une fois le message « déposé » dans la file d’attente, il est prêt à être consommé par les clients que l’on appelle les « consumers ». Sur le même principe que pour le protocole MQTT, les « consumers » reçoivent les messages des files d’attente auxquelles ils sont abonnés.

Il permet, comme les autres, d’indiquer la qualité de service souhaitée dans la transmission du message :

  • Au plus une fois : le message est transmis une fois, peu importe qu’il soit délivré ou non.
  • Au moins une fois : le message est transmis et délivré au moins une fois : il peut l’être plusieurs fois.
  • Une seule et unique fois : le message est transmis et délivré une seule et unique fois;

Les fonctionnalités et notamment la fiabilité de ce protocole sont au détriment de sa performance dans des environnements très limités en ressources.

AMQP est plus adapté aux situations exigeant fiabilité et sécurité.

Ce protocole était utilisé en partie dans la SmartHome 3.0 pour des applications spécifiques pour lesquelles la fonctionnalité de file d’attente était requise.

 

Principe de fonctionnement du protocole AMQP
Principe de fonctionnement du protocole AMQP

Quelques ressources pour prototyper avec AMQP:

Cet article présente très succinctement quelques protocoles applicatifs de l’Internet des Objets, d’autres articles vous seront proposés par la suite pour pratiquer ces protocoles dans le cadre d’exemples concrets.

Si des erreurs se sont glissées dans l’article, n’hésitez pas à nous en faire part.

Merci, et à très bientôt sur Frugal Prototype