Dans ce troisième article de cette série sur KNX IoT, Bruno Johnson et Wouter van der Beek expliquent les principes fondamentaux des appareils KNX IoT.
Depuis quelques années déjà, la transformation numérique est l’un des principaux sujets stratégiques à l’ordre du jour des conseils d’administration des entreprises. La possibilité de développer des services numériques à partir d’applications infonuagiques nécessite des connexions réseau basées sur le protocole Internet (IPv6) qui relient les périphériques et deviennent l’interface client. Pour y parvenir, les entreprises de toutes formes et tailles œuvrant dans le domaine de l’automatisation des bâtiments commerciaux ont demandé des solutions IoT sans fil, et l’association KNX a répondu à ces demandes avec l’API KNX IoT Point (KNX IoT).
Les bases
Pour assurer la rétrocompatibilité avec d’autres médias KNX (les installations KNX Classic), la spécification KNX IoT dans le groupe de spécifications système KNX (3_10_5 KNX IoT Point API) décrit :
• une nouvelle couche de transport basée sur IPv6, par exemple les réseaux Wi-Fi, Ethernet et basés sur Thread ;
• un nouveau protocole de communication et de message qui permet les modes de communication suivants :
- Point à multipoint, sans connexion (multidiffusion).
- Point à point, sans connexion.
- Point à point, orienté connexion.
En outre, le nouveau transport doit utiliser les mêmes points de données que les couches de transport KNX existantes telles que définies dans les spécifications des descriptions d’application (volume 7).
La conception d’un nouveau moyen de transport ayant ces contraintes ne changera pas la façon dont KNX est actuellement appliqué. Il aura toujours la même approche ETS dans la configuration des appareils, et les appareils communiqueront toujours entre eux au moyen de messages en S-mode.
La pile technologique
Les appareils doivent pouvoir communiquer en utilisant IPv6, quelle que soit la couche physique utilisée, ce qui signifie qu’Ethernet (y compris PoE), Wi-Fi et Thread sont pris en charge. En effet, Thread est intrinsèquement basé sur IPv6.
Découverte
Pour communiquer sur IP, il faut connaître l’adresse IP et le port de l’appareil KNX. Pour obtenir ces données, deux mécanismes de découverte différents sont utilisés.
1) mDNS discovery est un protocole qui utilise le DNS multicast (mDNS) pour trouver des appareils et des services sur le réseau local sans connaître leur adresse IP. Il est également connu sous le nom de configuration zéro, Bonjour, ou Avahi. Il est largement implémenté pour les appareils domestiques intelligents, les appareils Arduino sans fil, les imprimantes, les haut-parleurs, les périphériques de stockage réseau, etc. Il fonctionne en envoyant des paquets à chaque nœud du réseau pour résoudre les noms d’hôte et interroger les services. Il peut être utilisé avec « DNS Service Discovery » (DNS-SD) pour parcourir et résoudre les services en fonction du nom d’hôte ou du service. Il ne fonctionne que pour le domaine de premier niveau (TLD) .local.
mDNS discovery permet la découverte par :
– numéro de série ;
– adresse individuelle ;
– modalité de programmation.
2) La requête CoAP (Constrained Application Protocol) discovery est une requête CoAP spéciale permettant de découvrir les ressources d’un hôte connu. Pour découvrir l’hôte, une demande de multidiffusion peut être utilisée, mais elle doit être prise en charge par le serveur.
CoAP discovery permet la découverte par :
– numéro de série ;
– adresse individuelle ;
– modalité de programmation.
– découverte d’un appareil qui contient un point de données spécifique ;
– découverte d’un appareil contenant un bloc fonctionnel spécifique.
Transports de télégrammes
Le niveau supérieur consiste à communiquer sur IPv6 à l’aide de CoAP. C’est la couche qui transporte les télégrammes KNX de l’expéditeur à la destination. Ceci est réalisé en utilisant des URL. La façon la plus simple d’envisager CoAP est de le voir comme un équivalent à HTTP, implémentant l’envoi de messages à l’aide du paradigme de requête et de réponse, entre un client (initiateur) et un serveur (répondeur). La principale différence entre HTTP et CoAP est que les en-têtes CoAP sont au format binaire et que CoAP fonctionne sur UDP.
Les verbes pour émettre les messages sont les mêmes :
- GET : récupération des données.
- POST : mise à jour partielle des données.
- PUT : mise à jour complète des données.
- DELETE : suppression d’une ressource.
De plus, OBSERVE est une nouvelle fonction similaire à l’interrogation longue HTTP. La requête « Observe » peut être utilisée pour obtenir plusieurs réponses. Par exemple, lorsque les données changent, une nouvelle réponse est envoyée à la requête « Observe ». Pour avoir la même fiabilité que HTTP sur TCP, le protocole CoAP mis en place confirme les transferts. Le renvoi des paquets, lorsqu’ils ne sont pas reconnus, fait partie de CoAP et, par conséquent, les demandes confirmées par CoAP sont aussi fiables que HTTP sur TCP. La charge utile d’un message est déterminée par le type de contenu, c’est-à-dire que différents formats peuvent être pris en charge, un peu comme HTTP.
Types de charge utile
La spécification KNX IoT utilise deux formats de contenu, chacun pour une fonction différente. Le premier sert à répertorier les URL (points de données/blocs fonctionnels) avec lesquelles interagir, et le second à interagir avec les URL.
Le format Application-Link
Ce format de contenu permet la description des ressources hébergées, de leurs attributs et d’autres relations entre les liens. Basé sur le champ d’en-tête de lien HTTP défini dans RFC 5988, le format de lien « Constrained RESTful Environments » (CoRE) est transporté en tant que charge utile et se voit attribuer un type de média Internet. Une URL bien connue est définie comme point d’entrée par défaut pour demander les liens hébergés par un serveur.
Typical response
Voici un exemple de réponse type :
Chaque ligne contient :
– l’URL hébergée (entre ) ;
– le type de ressource (rt), désignant de quoi il s’agit ;
– le type de contenu, par ex. 60 pour CBOR et 40 pour le format Application-Link.
Cela permet au client d’interagir avec l’appareil sur la base d’une URL.
Interagir avec un appareil
L’URL peut être considérée comme un point de données avec lequel il est possible d’interagir via des paires clé-valeur. Les paires clé-valeur sont décrites avec « Concise Binary Object Representation » (CBOR). CBOR est un format de sérialisation de données binaires vaguement basé sur JSON. Comme JSON, il permet la transmission d’objets de données contenant des paires nom-valeur, mais de manière plus concise. Cela augmente les vitesses de traitement et de transfert au détriment de la lisibilité humaine. Cependant, cela ouvre la documentation : définissez les charges utiles en JSON pour augmenter la lisibilité humaine de la spécification et disposer du format binaire sur le fil.
Les données d’un message en mode S peuvent être définies dans JSON comme suit :
{ « s »: { « st »: « la valeur st » , « ga »: « la valeur ga », « value »: « la valeur » } }
Les clés JSON peuvent être remplacées par des valeurs entières pour réduire encore plus la taille du message comme suit :
{ 5: { 6: « la valeur st » , 7: « la valeur ga », 1: « la valeur » } }
Sécurité
Le protocole standard OSCORE RFC 8613 (« Object Security for Constrained RESTful Environments ») qui fournit une sécurité de bout en bout pour les messages CoAP au niveau de la couche application, chiffre les messages de demande/réponse de la couche application entre les points de terminaison. Non seulement la charge utile contenant la valeur associée à une ressource est chiffrée, mais c’est aussi le cas de la méthode de requête, de l’identifiant de la ressource et du format de contenu de la charge utile. Cela signifie que les données pertinentes pour l’application et la sémantique de la requête/réponse peuvent être protégées d’une manière qui est découplée du transport des messages, tout en restant légère.
En plus de CoAP, OSCORE utilise également la Concise Binary Object Representation (Représentation concise des objets binaires – CBOR) pour un codage compact, et la the CBOR Object Signature and Encryption (Signature et chiffrement d’objet CBOR – COSE) pour les structures de cryptage et de dérivation de clé, toutes deux conçues pour les opérations de périphérique contraintes, et compressées avec OSCORE en omettant les informations redondantes. OSCORE dispose d’identifiants intégrés permettant des opérations de bout en bout sur plusieurs chemins différents, avec ou sans IP.
La surcharge de message est ainsi minimale, car OSCORE protège uniquement les informations pertinentes de la couche application, et la quantité de données ajoutées à la taille du message CoAP d’origine peut être aussi faible que 11 à 13 octets avec des identifiants intégrés. OSCORE a joué un rôle déterminant dans la définition du niveau de surcharge pour la sécurité des communications légères et surpasse la sécurité de la couche de transport à la pointe de la technologie.
Tout mettre ensemble
Alors maintenant, tous les mécanismes de communication ont été expliqués. L’appareil KNX IoT dispose d’un ensemble d’URL pour répertorier les blocs fonctionnels et les points de données qui sont implémentés et ont des URL pour configurer l’appareil.
Par exemple, il existe des ressources (points de données) pour configurer l’appareil. Les concepts existants tels que « Load State Machine » (LSM), le mode de programmation (PM), l’adresse individuelle (IA) et « Group Object Table » sont modélisés avec les mécanismes décrits ci-dessus.
Par conséquent, les spécifications IETF (« Internet Engineering task Force ») suivantes sont référencées dans la spécification de l’API KNX IoT Point :
Résumé
L’avantage de KNX IoT est que la nouvelle technologie est basée sur IP et peut donc être utilisée sur des réseaux informatiques. Elle a été développée de façon à garantir l’interopérabilité avec la technologie KNX existante, et utilise les dernières technologies sous-jacentes basées sur Internet dans ses spécifications, ce qui fait que KNX IoT est, dans sa conception même, sécurisé.
La spécification a été conçue avec des dispositifs embarqués à l’esprit, et la pile open source mettant en œuvre KNX IoT s’est avérée être assez petite, fonctionnant avec à peine 512 ko de mémoire de stockage et 96 ko de mémoire.
Bruno Johnson et Wouter van der Beek sont respectivement PDG et chef des opérations de Cascoda Limited. Cascoda est une société de communication qui fabrique des radios et des modules à semi-conducteurs IoT sécurisés et s’emploie à développer des normes de communication IoT sécurisées pour les bâtiments intelligents et les villes intelligentes. Ses produits résolvent les problèmes de portée, de fiabilité, de sécurité, de puissance et d’évolutivité pour l’IoT industriel et commercial grâce à des innovations brevetées et aux dernières normes les plus sécurisées, le tout intégré dans des modules IoT peu coûteux et à très faible consommation.
