Protocoles pour l'Internet des objets
Que signifie la phrase internet des objets (Internet of Things) ? Cela dépend beaucoup de votre position dans la chaîne d'approvisionnement. Beaucoup ont essayé de la définir, et les définitions sont souvent influencées par les besoins et intérêts des différents secteurs économiques. Mais en tant qu'ingénieur matériel ou logiciel, vous comprenez déjà l'élément essentiel : construire des produits qui sont interconnectés. Et les systèmes intégrés vont jouer - et jouent - un rôle crucial dans le développement de l'IoT. Dans cet article, nous allons nous intéresser à internet et ses protocoles existants et nouveaux à l'appui des efforts de l'IoT. Avant de nous pencher sur ces protocoles, nous allons définir ce qu'est un objet parce que les tâches des appareils utilisateurs dicteront la plupart des exigences à utiliser par les protocoles.
Les exigences en matière de logiciels pour les appareils IoT industriels et grand-public peuvent être un peu différentes. Bien qu'ils puissent partager un noyau commun et des services de bas niveau, le middleware requis par leurs applications peut être radicalement différent.
Dans le cas de l'IoT industriel, un nœud de WSN représente une pile de logiciel pour un appareil IoT industriel, par exemple un nœud de capteurs sans fil (WSN). L'appareil de faible puissance, de coût faible, peut fonctionner entièrement sur batterie. Un tel appareil peut généralement utiliser un
processeur 32 bits. Il peut également utiliser un processeur 8 ou 16 bits, mais avec des piles de communications fonctionnant sur un module additionnel. Il utiliserait un protocole de réseau très efficace comme 6LoWPAN pour réduire le temps de transmission et économiser l'énergie. Il pourrait également communiquer sur de courtes distances sans fil via Bluetooth. En tant que nœud de périphérie, nous avons besoin de transférer les données à partir du réseau sans fil vers un réseau IP (Internet local ou public) et en utilisant une faible puissance Wifi ou Ethernet.
De toute évidence, les exigences en matière de logiciels pour cet appareil sont beaucoup plus importantes. Il pourrait avoir besoin d'une machine virtuelle Java. Il pourrait aussi bien utiliser un protocole de marché vertical. Malheureusement, l'IoT grand-public est très fragmenté en termes de protocoles de marché verticaux (de protocole d'application). Beaucoup d'entreprises proposent des solutions propriétaires. Dans le cas du marché domestique du consommateur, par exemple :
Il y a d'autres exemples comme la communication par courant porteur de ligne électrique : HomePlug et HomeGrid.
Sur le marché vertical médical, des organisations comme l'Alliance Continua, IHE (Integrating the Healthcare Enterprise) ou IEEE sont également en train d'élaborer et de proposer des normes.
Ces protocoles ne sont pas proposés par Micrium. Un fabricant d'équipement nécessitant que ses produits soient compatibles avec l'un de ces protocoles IoT grand-public doit s'inscrire auprès de ces organisations et ensuite intégrer ces protocoles dans le cadre de l'application de son produit.
Dans l'IoT industriel, il y a moins d'initiatives axées sur le marché. Il existe une initiative majeure appelée Consortium Internet Industriel (IIC, Industrial Internet Consortium) avec AT&T, Cisco, GE, Intel et IBM en tant que membres fondateurs. Mais, en dehors de l'IIC, le développement d'appareils et de systèmes pour l'internet des objets est essentiellement propriétaire. Voilà pourquoi la connaissance d'internet et du protocole internet (IP) est si importante désormais pour les développeurs de systèmes intégrés. Protocole internet (IP, Internet Protocol)
L'utilisation de la technologie IP est fondamentale pour l'IoT. IP permet l'interopérabilité des systèmes. Cette fonction peut ne pas sembler importante aujourd'hui, mais comme l'IoT évolue, l'interopérabilité des systèmes deviendra une fonctionnalité importante générant des revenus. Ethernet/Wifi et 6LoWPAN dépendent tous deux fortement d'IPv4 et d'IPv6.
Il est certainement possible de construire un système IoT avec les technologies web existantes, même si elles ne sont pas aussi efficaces que les nouveaux protocoles. HTTP(S) et Websockets sont des normes couramment utilisées pour la charge utile, de même que XML ou JavaScript Object Notation (JSON). En utilisant un navigateur web standard (client HTTP), JSON fournit une couche d'abstraction aux développeurs web pour créer une application web comportant un état avec une connexion duplex persistante à un serveur web (serveur HTTP) en maintenant ouvertes deux connexions HTTP.
HTTP est le fondement du modèle client-serveur utilisé pour le web. La méthode la plus sûre pour mettre en œuvre HTTP dans votre appareil IoT est de n'inclure qu'un client, pas un serveur. En d'autres termes, il est plus sûr que l'appareil IoT puisse initier des connexions vers un serveur Web, mais ne soit pas en mesure de recevoir de demandes de connexion. Après tout, nous ne voulons pas permettre aux machines de l'extérieur d'avoir accès au réseau local où les appareils IoT sont installés.
WebSocket est un protocole qui permet une communication full-duplex sur une seule connexion TCP sur laquelle les messages peuvent être envoyés entre le client et le serveur. Il fait partie de la spécification HTML5. La norme WebSocket simplifie beaucoup la complexité entourant la communication bi-directionnelle et la gestion des connexions web. L'utilisation de Websockets en conjonction avec HTTP est une bonne solution pour les appareils IoT s'ils peuvent supporter les charges utiles HTTP.
XMPP (Extensible Messaging and Presence Protocol) est un bon exemple de technologie web existante qui trouve un nouvel emploi dans l'espace IoT.
XMPP prend ses racines dans les informations de messagerie instantanée et de présence, et s'est étendu aux appels vocaux et vidéo, à la collaboration, au middleware léger, à la syndication de contenu, et au routage généralisé de données XML. C'est un concurrent pour la gestion à grande échelle des produits blancs de consommation tels que les lave-linge, les sèche-linge, les réfrigérateurs, et ainsi de suite.
Les atouts de XMPP sont son adressage, sa sécurité et évolutivité. Cela le rend idéal pour les applications IoT grand-public.
HTTP, Websocket et XMPP ne sont que des exemples de technologies sollicitées en tant que services pour l'IoT. D'autres groupes travaillent également avec acharnement pour développer des solutions pour les nouveaux défis auxquels nous confronte l'IoT.
De nombreux experts se réfèrent aux appareils IoT en tant que systèmes contraints parce qu'ils pensent que les appareils IoT devraient être aussi bon marché que possible et utiliser les plus petits MCU disponibles, tout en exécutant une pile de communication.
Actuellement, l'adaptation de l'Internet à l'IoT est l'une des principales priorités de la plupart des organismes internationaux de normalisation.
Si votre système n'a as besoin des caractéristiques de TCP, et peut fonctionner avec les capacités plus limitées d'UDP, supprimer totalement le module PCM contribue largement à réduire l'impact total de votre produit sur le code. C'est pourquoi 6LoWPAN (pour le WSN) et CoAP (protocole internet léger) contribuent à l'univers IoT.
Bien que l'infrastructure du web soit disponible et utilisable par les appareils IoT, elle est trop lourde pour la majorité des applications de l'IoT. En juillet 2013, l'IETF a publié le Protocole d'application contrainte (CoAP, Constrained Application Protocol) pour utilisation avec une faible puissance et des nœuds et réseaux à pertes (limitées) (LLNs). CoAP, comme HTTP, est un protocole REST.
CoAP est sémantiquement aligné sur HTTP, et comporte même une correspondance un-un vis-à-vis de l'émission et réception HTTP. Les périphériques réseau sont limitées par de petits microcontrôleurs avec de petites quantités de mémoire flash et de RAM, tandis que les contraintes sur les réseaux locaux, tels que 6LoWPAN sont dues à des taux d'erreurs de paquets élevés et à un débit faible (de dizaines de kilobits par seconde). CoAP peut être un bon protocole pour les appareils fonctionnant sur batterie ou sur captage d'énergie.
Dans la mesure où CoAP utilise UDP, quelques-unes des fonctionnalités de TCP sont répliquées directement dans CoAP. Par exemple, CoAP opère une distinction entre les messages confirmables (nécessitant un accusé de réception) et non confirmables.
MQ Telemetry Transport (MQTT) est un protocole open source qui a été développé et optimisé pour les appareils limités et à faible bande passante, à latence élevée, ou pour les réseaux non fiables. Il s'agit d'un transport de messages de publication/d'abonnement qui est extrêmement léger et idéal pour le raccordement à des réseaux de petits appareils avec une bande passante minimale. MQTT utilise efficacement la bande passante, accueille toutes les données, et est en permanence informé de l'état de la session, car il utilise le protocole TCP. Il est destiné à minimiser les besoins en ressources de l'appareil tout en essayant d'assurer une fiabilité et un certain degré d'assurance de livraison avec des niveaux de service.
MQTT cible de grands réseaux de petits appareils qui doivent être surveillés ou contrôlés à partir d'un serveur back-end sur Internet. Il n'a pas été conçu pour le transfert d'appareil à appareil. Il n'a pas non plus été conçu pour « diffuser de manière multiple » des données vers de nombreux récepteurs. MQTT est simple, offrant seulement quelques options de contrôle. Les applications utilisant MQTT sont généralement lentes dans le sens que la définition du « temps réel » dans ce cas est généralement mesurée en secondes.