Dans cette 4e partie de cette série sur KNX IoT, Bruno Johnson et Wouter van der Beek expliquent l’architecture des appareils KNX IoT et montrent de quelle façon KNX IoT est compatible avec les systèmes KNX Classic.
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).
Le débit de haut niveau
Pour assurer la rétrocompatibilité avec les systèmes KNX Classic (par exemple, KNX Twisted Pair (KNX TP)), la spécification KNX IoT a mis en œuvre deux mécanismes fondamentaux sémantiquement équivalents à KNX TP : la configuration des appareils et le comportement d’exécution. De plus, le flux de configuration dans un gestionnaire client (MAC, par exemple ETS) s’effectue selon les mêmes étapes déjà utilisées par les installateurs. Le résultat est que pour les installateurs, il n’y a aucune différence entre l’utilisation des appareils KNX TP et KNX IoT. Le flux d’utilisation des nouveaux appareils KNX IoT est illustré à la figure 1.
La configuration des appareils KNX IoT utilise toutes les mêmes informations que celle des appareils sécurisés KNX TP, à savoir :
• Mappage du numéro de série à une adresse individuelle.
• Téléchargement de la configuration de l’adresse de groupe.
• Utilisation d’un mot de passe, similaire à la clé de configuration par défaut d’usine (FDSK) pour configurer la sécurité.
De plus, une nouvelle fonctionnalité est implémentée : une identification d’installation (iid). Cela permet à plusieurs installations de fonctionner sur le même réseau de communication. Lorsque l’appareil est en mode d’exécution (c’est-à-dire lorsque son état est « chargé »), il échange des messages en mode S à l’aide des informations configurées. Ceci est représenté sur la figure 2.
Notez que la communication d’exécution peut être établie entre N appareils émetteurs et M appareils récepteurs, comme c’est le cas avec KNX TP.
Architecture de l’appareil
Les adresses Web, comme les URL, sont implémentées sur l’appareil. Chaque URL que l’appareil expose fournit des informations similaires à un serveur HTTP, et chaque URL a un objectif différent. Les URL sont définies dans la spécification, et la spécification définit ce que fait l’URL dans le système. La figure 3 montre les URL les plus courantes dans un appareil.
Les URL ont des objectifs différents dans le système. Cependant, les mêmes informations qu’avec un dispositif KNX TP sont stockées via des URL.
La figure 3 montre les URL au niveau de l’appareil, et celles-ci transmettent des données telles que :
• le numéro de série de l’appareil ;
• le mode de programmation (activé ou désactivé) ;
• l’identifiant de l’installation ;
• l’état de chargement de l’appareil (« déchargé », « chargement », « chargé », et action pour changer l’état (« déchargement », « commencer le chargement », « chargement complété ») ;
• Empreinte digitale de l’état chargé, pour savoir si quelque chose a changé.
L’URL de configuration
Les tableaux sont utilisés pour configurer la communication d’exécution, par exemple, en transmettant le mappage entre l’adresse de groupe, les indicateurs de communication, le point de données (URL), les clés de sécurité et l’adresse de multidiffusion IPv6 pour la communication de groupe.
Les tableaux suivants sont utilisés :
• tableau des objets du groupe : il contient le mappage de l’URL du point de données à l’adresse de groupe, y compris les indicateurs de communication ;
• tableau des destinataires : il contient l’adresse de groupe et le mappage d’identifiant de groupe ; l’identifiant de groupe est utilisé dans le cadre de l’adresse multidiffusion de la communication en mode S, ou pour répertorier l’adresse individuelle comme destination ;
(Communication vers l’extérieur)
• tableau de publication : il contient l’adresse du groupe et le mappage de l’identifiant de groupe ; L’identifiant de groupe est utilisé dans le cadre de l’adresse de multidiffusion de la communication en mode S ;
(Communication vers l’intérieur)
• tableau de sécurité : il contient les clés de sécurité OSCORE contenant les informations OSCORE (« osc »), ainsi que le mappage vers KNX pour la communication de groupe, par exemple, la liste des adresses de groupe ou les étendues d’accès unicast identifiées par la liste des interfaces.
Gestion des tableaux
Les nouvelles entrées sont faites en utilisant un protocole d’application Internet pour les dispositifs contraints, connu sous le nom de « Constrained Application Protocol » (CoAP – Protocole pour application contrainte). Un exemple serait un CoAP POST sur l’URL du tableau en utilisant CoAP POST « /fp/g » pour le tableau le tableau des objets de groupe. Les valeurs doivent définir une entrée correcte. L’ « id » utilisé fera partie de l’URL de la nouvelle entrée. Par exemple, l’utilisation de « id = item_1 » entraînera une nouvelle entrée avec une sous-URL, par exemple : « /fp/g/item_1 ». Par conséquent, la MAC contrôle la définition des URL d’entrée.
L’URL créée est répertoriée avec un CoAP GET déterminé sur « /fp/g » en tant qu’entrée de format de lien dans la réponse. L’entrée peut être inspectée en émettant un CoAP GET sur « /fp/g/item_1 ». La réponse donne les valeurs selon la spécification. Une entrée peut être supprimée en émettant une suppression CoAP sur « /fp/g/item_1 ». Cela a pour effet que l’entrée est supprimée de l’appareil, et ainsi, lors d’un CoAP GET ultérieur sur « /fp/g », elle ne sera plus répertoriée. Notez que la gestion des tableaux pour la communication de groupe n’est possible que dans l’état « chargement ».
L’URL pour la communication d’exécution
L’URL « /.knx » est utilisée pour la communication des messages en mode S. Les messages en mode S contiennent les informations suivantes :
• adresse de groupe (« ga ») ;
• adresse individuelle de l’expéditeur (« sia ») ;
• type de service (« st »).
L’exemple de flux en mode S illustré à la figure 5 ci-dessous se compose d’un minimum de 2 appareils, à savoir un qui crée un message en mode S, et un autre qui reçoit le message en mode S. Le dispositif d’envoi a une entrée d’objet de groupe avec l’adresse de groupe 5 et une URL représentant/contenant la valeur
Communication multidiffusion en mode S
Le tableau des destinataires et des éditeurs contient également des entrées. Ces entrées déterminent quelle adresse de multidiffusion est utilisée. Par exemple, une entrée avec ga = 5 et grpid = 1 se traduira par la valeur grpid = 1 faisant partie de l’adresse de multidiffusion d’envoi ou de réception. Par conséquent, les entrées du tableau des destinataires et des éditeurs pour la même adresse de groupe doivent correspondre, sinon l’expéditeur pourrait utiliser une adresse de multidiffusion différente de celle du destinataire.
Communication Unicast en mode S : nouveauté pour KNX IoT
La communication monodiffusion diffère en ayant une entrée différente du côté de l’envoi. L’expéditeur a une adresse individuelle de destination (« ia »). L’adresse individuelle doit être résolue en une adresse IPv6 réelle. Cela peut être fait via des protocoles informatiques courants tels que la découverte CoAP ou le DNS multicast (mDNS). Ensuite, l’adresse IPv6 réelle peut être utilisée pour la communication d’exécution.
Informations sémantiques : blocs fonctionnels et points de données (nouveau pour KNX IoT)
KNX TP et ETS fonctionnent sur des longueurs de données. Par conséquent, les informations sémantiques de ce qui est contenu dans les messages en mode S ne sont pas transférées. Cependant, avec KNX IoT, cela a été ajouté au niveau de l’appareil. Par exemple, les points de données utilisés pour récupérer ou définir la valeur disposent d’une URL (point de données). L’URL (point de données) peut être utilisée pour obtenir la valeur « dpt » en émettant un CoAP GET avec le paramètre de requête « ?m=* ». De plus, la ressource /f liste tous les blocs fonctionnels. Par exemple, CoAP GET sur /f donne une liste de tous les blocs fonctionnels implémentés au format lien. L’URL de chaque entrée de bloc fonctionnel donnera les points de données mis en œuvre sur le bloc fonctionnel.
Comme on peut le voir sur la figure 6 ci-dessus, ces informations donnent les informations sémantiques sous la même forme qu’avec KNX TP.
Résumé
L’avantage de KNX IoT est qu’il est parfaitement interopérable avec l’infrastructure KNX existante, tout en étant basé sur IP. Ainsi, plusieurs installations peuvent fonctionner simultanément sur le même réseau (IT) en utilisant une infrastructure filaire (Ethernet/PoE) et sans fil (Thread/WiFi/cellulaire). La technologie KNX IoT 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é.
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.
