In dieser dritten Serie von Artikeln über KNX IoT erklären Bruno Johnson und Wouter van der Beek die Grundlagen von KNX IoT Geräten.
Die digitale Transformation ist seit einigen Jahren eines der wichtigsten Strategiethemen auf den Tagesordnungen von Unternehmensvorständen. Die Möglichkeit, digitale Dienste aus Cloud-basierten Anwendungen zu entwickeln, verlangt Internetprotokoll (IPv6)-basierte Netzverbindungen zu Edge-Geräten, die zur Kundenschnittstelle werden. Unternehmen aller Formen und Größen in der kommerziellen Gebäudeautomation haben nach drahtlosen IoT-Lösungen gefragt, um dies zu ermöglichen, und die KNX Association hat mit der Veröffentlichung der KNX IoT Point API (KNX IoT) reagiert.
Die Grundlagen
Um die Rückwärtskompatibilität mit anderen KNX Medien (KNX Classic Installationen) zu gewährleisten, beschreibt die KNX IoT Spezifikation in der KNX System Spezifikationsgruppe (3_10_5 KNX IoT Point API):
• Eine neue Transportschicht auf der Basis von IPv6, z. B. Wi-Fi, Ethernet und Thread-basierte Netze.
• Ein neues Kommunikations-/Nachrichtenprotokoll, das die folgenden Kommunikationsmodi ermöglicht:
- Point-to-Multipoint, Connectionless (Multicast).
- Point-to-Point, Connectionless.
- Point-to-Point, Connection-Oriented.
Darüber hinaus muss der neue Transport dieselben Datenpunkte verwenden wie die bestehenden Kommunikationsschichten von KNX, wie sie in den Spezifikationen der Anwendungsbeschreibungen (Band 7) definiert sind.
Die Entwicklung des neuen Transportmediums mit diesen Randbedingungen wird nichts daran ändern, wie KNX zurzeit angewendet wird. Die Konfiguration der Geräte erfolgt nach dem gleichen Ansatz wie bei der ETS, und die Geräte kommunizieren weiterhin über S-mode Nachrichten miteinander..
Der Technologie-Stack
Die Geräte müssen in der Lage sein, mit IPv6 zu kommunizieren, unabhängig von der verwendeten physikalischen Schnittstelle, was bedeutet, dass Ethernet (einschließlich PoE), Wi-Fi und Thread unterstützt werden. Thread basiert von Haus aus auf IPv6.
Discovery
Um über IP zu kommunizieren, muss man die IP-Adresse und den Port des KNX-Geräts kennen. Um diese Daten zu erhalten, werden zwei verschiedene Entdeckungsmechanismen verwendet.
1) mDNS-Ermittlung ist ein Protokoll, das Multicast-DNS (mDNS) verwendet, um Geräte und Dienste im lokalen Netz zu finden, ohne deren IP-Adresse zu kennen. Es ist auch als Null-Konfiguration Bonjour, oder Avahi bekannt. Sie wird weitgehend für Smart-Home-Geräte, drahtlose Arduino Geräte, Drucker, Lautsprecher, Netzwerkspeichergeräte usw. eingesetzt. Es funktioniert, indem es Pakete an jeden Knoten im Netz sendet, um Hostnamen aufzulösen und Dienste abzufragen. Es kann mit DNS Service Discovery (DNS-SD) verwendet werden, um Dienste auf der Basis des Hostnamens oder des Dienstes zu suchen und aufzulösen. Sie funktioniert nur für die Top-Level-Domain (TLD) .local.
mDNS-Erkennung ermöglicht die Erkennung durch:
– Seriennummer.
– Individuelle Adresse.
– Programmiermodus.
2) Die CoAP (Constrained Application Protocol) Discovery ist eine spezielle CoAP-Anfrage, um die Ressourcen eines bekannten Hosts zu ermitteln. Um den Host zu ermitteln, kann eine Multicast-Anfrage verwendet werden, die jedoch vom Server unterstützt werden muss.
CoAP-Ermittlung ermöglicht die Erkennung durch:
– Seriennummer.
– Individuelle Adresse.
– Programmiermodus.
– Entdeckung eines Geräts, das einen bestimmten Datenpunkt enthält.
– Entdeckung eines Geräts, das einen bestimmten Funktionsblock enthält.
Telegramm Transporte
Die nächsthöhere Ebene ist die Kommunikation über IPv6 mit CoAP. Dies ist die Ebene, welche die KNX-Telegramme vom Absender zum Ziel transportiert. Dies wird mit Hilfe von URLs erreicht. Am einfachsten lässt sich CoAP als Äquivalent zu HTTP betrachten, das den Versand von Nachrichten nach dem Request-Response-Paradigma zwischen einem Client (Initiator) und einem Server (Responder) ermöglicht. Der Hauptunterschied zwischen HTTP und CoAP besteht darin, dass die CoAP-Header im Binärformat vorliegen und dass CoAP über UDP arbeitet.
Die Verben für den Versand der Nachrichten sind identisch:
- GET – zum Abruf von Daten.
- POST – für die teilweise Aktualisierung von Daten.
- PUT – für die vollständige Aktualisierung der Daten.
- DELETE – zum Löschen einer Ressource.
Zusätzlich gibt es mit OBSERVE eine neue Funktion, die der HTTP-Long-Poll ähnelt. Die Observe-Funktion kann verwendet werden, um mehrere Antworten zu erhalten. Wenn sich zum Beispiel die Daten ändern, wird eine neue Antwort auf die Observe-Anfrage gesendet. Um die gleiche Zuverlässigkeit wie HTTP über TCP zu erreichen, hat das CoAP-Protokoll bestätigte Übertragungen implementiert. Daher ist das erneute Senden der Pakete, wenn sie nicht bestätigt werden, Teil von CoAP, und daher sind Anfragen mit CoAP-Bestätigung genauso zuverlässig wie HTTP über TCP. Die Payload einer Nachricht wird durch den Inhaltstyp bestimmt, d.h. es können verschiedene Formate unterstützt werden, ähnlich wie bei HTTP.
Payload-Typen
Die KNX IoT-Spezifikation verwendet zwei Inhaltsformate, jedes für eine andere Funktion. Die erste ist für die Auflistung der URLs (Datenpunkte/Funktionsblöcke), mit denen interagiert werden soll, und die zweite für die Interaktion mit den URLs.
Das Application-Link Format
Dieses Inhaltsformat ermöglicht die Beschreibung von gehosteten Ressourcen, ihrer Attribute und anderer Beziehungen zwischen Links. Auf der Basis des in RFC 5988 definierten HTTP-Link-Header-Feldes wird das CoRE-Link-Format (Constrained RESTful Environments) als Payload übertragen und erhält einen Internet-Medientyp. Eine bekannte URL wird als Standard-Einstiegspunkt für die Abfrage von Links definiert, die von einem Server gehostet werden.
Typische Antwort
Ein Beispiel für eine typische Antwort lautet wie folgt:
Jede Zeile enthält:
– Die gehostete URL (zwischen ).
– Der Ressourcentyp (rt), der angibt, worum es sich handelt.
– Der Inhaltstyp, z.B. 60 für CBOR und 40 für Application-Link Format.
Dadurch kann der Client mit dem Gerät auf URL-Basis interagieren.
Interaktion mit einem Gerät
Die URL kann als ein Datenpunkt betrachtet werden, mit dem über Schlüssel-Wert-Paare interagiert werden kann. Die Schlüssel-Wert-Paare werden mit Concise Binary Object Representation (CBOR) beschrieben. CBOR ist ein Format zur Serialisierung von Binärdaten, das dem JSON-Format sehr nahe kommt. Wie JSON ermöglicht es die Übertragung von Datenobjekten, die Name-Wert-Paare enthalten, jedoch in einer präziseren Form. Dies erhöht die Verarbeitungs- und Übertragungsgeschwindigkeit auf Kosten der menschlichen Lesbarkeit. Es eröffnet jedoch die Dokumentation: Definieren Sie die Payloads in JSON, um die menschliche Lesbarkeit der Spezifikation zu verbessern und das Binärformat auf dem Kabel zu haben.
Die Daten für eine S-Mode-Nachricht können in JSON wie folgt definiert werden:
{ „s“: { „st“: „the st value“ , „ga“: „the ga value“, „value“: „the value“ } }
Die JSON-Schlüssel können durch Integer-Werte ersetzt werden, um die Nachricht noch weiter zu verkleinern, wie folgt:
{ 5: { 6: „the st value“ , 7: „the ga value“, 1: „the value“ } }
Sicherheit
Das Standardprotokoll OSCORE RFC 8613 (Object Security for Constrained RESTful Environments), das End-to-End-Sicherheit für CoAP-Nachrichten auf der Applikationsebene bietet, verschlüsselt die Anfrage/Antwort-Nachrichten der Applikationsebene zwischen den Endpunkten. Nicht nur die Payload, die den mit einer Ressource verbundenen Wert enthält, wird verschlüsselt, sondern auch die Anfragemethode, der Bezeichner der Ressource und das Inhaltsformat der Payload. Dies bedeutet, dass die anwendungsrelevanten Daten und die Semantik der Anfrage/Antwort auf eine Art und Weise geschützt werden können, die vom Transport der Nachrichten entkoppelt und gleichzeitig leichtgewichtig in Bezug auf den Overhead ist.
Neben CoAP verwendet OSCORE auch die Concise Binary Object Representation (CBOR) für eine kompakte Kodierung und die CBOR Object Signature and Encryption (COSE) für Verschlüsselungs- und Schlüsselableitungsstrukturen – beide wurden für eingeschränkte Geräteoperationen entwickelt und mit OSCORE durch Weglassen redundanter Informationen weiter komprimiert. OSCORE verfügt über integrierte Identifikatoren, die End-to-End-Operationen über mehrere verschiedene Pfade mit oder ohne IP ermöglichen.
Der Nachrichten-Overhead ist minimal, da OSCORE nur die relevanten Informationen der Anwendungsschicht schützt, und die Datenmenge, die der ursprünglichen CoAP-Nachricht hinzugefügt wird, kann mit eingebauten Identifikatoren nur 11-13 Byte betragen. OSCORE hat wesentlich dazu beigetragen, die Höhe des Overheads für leichtgewichtige Kommunikationssicherheit zu definieren, und übertrifft den Stand der Technik bei der Sicherheit auf der Transportschicht.
Alles zusammenbringen
Damit sind alle Kommunikationsmechanismen erklärt. KNX IoT-Geräte verfügen über eine Reihe von URLS, die auflisten, welche Funktionsblöcke und Datenpunkte implementiert sind und über URLs zur Konfiguration des Geräts.
So gibt es beispielsweise Ressourcen (Datenpunkte) für die Konfiguration des Geräts. Bestehende Konzepte wie Load State Machine (LSM), Programming Mode (PM), Individual Address (IA) und Group Object Table werden mit den oben beschriebenen Mechanismen modelliert.
Infolgedessen werden die folgenden IETF (Internet Engineering Task Force) Spezifikationen in der KNX IoT Point API Spezifikation referenziert:
Fazit
Der Vorteil von KNX IoT ist, dass die neue Technologie IP-basiert ist und daher über IT-Netzwerke genutzt werden kann. Es wurde mit garantierter Interoperabilität mit bestehender KNX Technologie entwickelt und verwendet die neuesten internetbasierten Technologien in seiner Spezifikation, wodurch KNX IoT von Anfang an sicher ist.
Die Spezifikation wurde mit Blick auf eingebettete Geräte ausgelegt, und der Open-Source-Stack, der KNX IoT implementiert, ist recht klein und benötigt nur 512 kB Speicherplatz und 96 kB Arbeitsspeicher.
Bruno Johnson und Wouter van der Beek sind der CEO bzw. COO von Cascoda Limited. Cascoda ist ein Kommunikationsunternehmen, das sichere IoT-Halbleiter-Funkgeräte und -Module herstellt und die Entwicklung von sicheren IoT-Kommunikationsstandards für intelligente Gebäude und intelligente Städte anführt. Die Produkte des Unternehmens lösen Probleme in Bezug auf Reichweite, Zuverlässigkeit, Sicherheit, Stromverbrauch und Skalierbarkeit für industrielles und kommerzielles IoT durch patentierte Innovationen und die neuesten, sichersten Standards, die alle in kostengünstige IoT-Module mit extrem niedrigem Stromverbrauch integriert sind.
