Im dritten Teil dieser Artikelserie ü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, erfordert Internetprotokoll (IPv6) basierte Netzwerkverbindungen 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 darauf mit der Veröffentlichung der KNX IoT Point API (KNX IoT) reagiert.
Die Grundlagen
Um die Rückwärtskompatibilität zu anderen KNX Medien (KNX Classic Installationen) zu gewährleisten, beschreibt die KNX IoT Spezifikation in der KNX System Specifications Group (3_10_5 KNX IoT Point API):
- Eine neue Transportschicht basierend auf IPv6, z.B. Wi-Fi, Ethernet und Thread-basierte Netzwerke.
- Ein neues Kommunikations-/Nachrichtenprotokoll, das die folgenden Kommunikationsmodi ermöglicht:
- Point-to-Multipoint, verbindungslos (Multicast).
- Point-to-Point, verbindungslos.
- Point-to-Point, verbindungsorientiert.
Außerdem muss der neue Transport dieselben Datenpunkte verwenden wie die bestehenden KNX Transportschichten, wie sie in den Spezifikationen für Anwendungsbeschreibungen (Band 7) definiert sind.
Die Entwicklung des neuen Transportmediums mit diesen Einschränkungen wird die derzeitige Anwendung von KNX nicht verändern. Es hat immer noch den gleichen Ansatz der ETS bei der Konfiguration der Geräte, und die Geräte kommunizieren immer noch mit Hilfe von S-mode Nachrichten miteinander.
Der Technologie-Stack
Geräte müssen in der Lage sein, mit IPv6 zu kommunizieren, unabhängig von der verwendeten physikalischen Schicht, was bedeutet, dass Ethernet (einschließlich PoE), Wi-Fi und Thread unterstützt werden. Thread ist in der Tat von Haus aus IPv6-basiert.
Erkennung
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 Erkennungsmechanismen verwendet.
1) mDNS discovery ist ein Protokoll, das Multicast DNS (mDNS) verwendet, um Geräte und Dienste im lokalen Netzwerk zu finden, ohne deren IP-Adresse zu kennen. Es ist auch bekannt als Null-Konfiguration, Bonjour, oder Avahi. Es wird häufig 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 Netzwerk sendet, um Hostnamen aufzulösen und Dienste abzufragen. Es kann mit DNS Service Discovery (DNS-SD) verwendet werden, um Dienste auf der Grundlage des Hostnamens oder des Dienstes zu suchen und aufzulösen. Es funktioniert nur für die .local Top-Level-Domain (TLD).
Die mDNS-Erkennung ermöglicht die Erkennung durch:
- Seriennummer.
- Individuelle Adresse.
- Programmiermodus.
2) Das 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-Erkennung ermöglicht die Erkennung durch:
- Seriennummer.
- Individuelle Adresse.
- Programmiermodus.
- Auffinden eines Gerätes, das einen bestimmten Datenpunkt enthält.
- Auffinden eines Geräts, das einen bestimmten Funktionsblock enthält.
Telegrammtransporte
Die nächsthöhere Ebene ist die Kommunikation über IPv6 mit CoAP. Dies ist die Schicht, die die KNX Telegramme vom Absender zum Ziel transportiert. Dies wird durch die Verwendung von URLs erreicht. Am einfachsten lässt sich CoAP als Äquivalent zu HTTP betrachten, das den Versand von Nachrichten nach dem Request- und Response-Paradigma zwischen einem Client (Initiator) und einem Server (Responder) implementiert. Der Hauptunterschied zwischen HTTP und CoAP besteht darin, dass die CoAP-Header im Binärformat vorliegen und dass CoAP über UDP funktioniert.
Die Verben zum Absetzen der Nachrichten sind die gleichen:
- GET - zum Abrufen von Daten.
- POST - zur teilweisen Aktualisierung von Daten.
- PUT - zur vollständigen Aktualisierung von Daten.
- DELETE - zum Löschen einer Ressource.
Außerdem ist OBSERVE eine neue Funktion, die dem HTTP long poll ähnelt. Observe 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 eine Übertragungsbestätigung implementiert. Daher ist das erneute Senden der Pakete, wenn sie nicht bestätigt werden, Teil von CoAP, und daher sind CoAP-bestätigte Anfragen genauso zuverlässig wie HTTP über TCP. Die Nutzlast 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. Das erste ist für die Auflistung der URLs (Datenpunkte/Funktionsblöcke), mit denen interagiert werden soll, und das zweite für die Interaktion mit den URLs.
Das Application-Link-Format
Dieses Inhaltsformat ermöglicht die Beschreibung der gehosteten Ressourcen, ihrer Attribute und anderer Beziehungen zwischen Links. Basierend auf dem HTTP Link Header-Feld, das in RFC 5988 definiert ist, wird das Constrained RESTful Environments (CoRE) Link Format als Payload übertragen und erhält einen Internet-Medientyp. Eine bekannte URL wird als Standard-Einstiegspunkt für die Abfrage der von einem Server gehosteten Links definiert.
Typische Antwort
Ein Beispiel für eine typische Antwort lautet wie folgt:
<auth/at>;rt="urn:knx:fb.at";ct=40,
<dev>;rt="urn:knx:fb.0";ct=40,
<swu>;rt="urn:knx:fb.swu";ct=40,
<f/rts>;rt="urn:knx:fb.321";ct=40
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.
Dies ermöglicht es dem Client, mit dem Gerät auf URL-Basis zu 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 lose auf JSON basiert. Wie JSON ermöglicht es die Übertragung von Datenobjekten, die Name-Wert-Paare enthalten, jedoch in einer prägnanteren Form. Dies erhöht die Verarbeitungs- und Übertragungsgeschwindigkeit auf Kosten der menschlichen Lesbarkeit. Es eröffnet jedoch die Möglichkeit der Dokumentation: Definieren Sie die Nutzdaten in JSON, um die Lesbarkeit der Spezifikation zu erhöhen und das binäre Format auf dem Draht 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 ganzzahlige Werte ersetzt werden, um die Nachricht noch weiter zu verkleinern:
{ 5: { 6: "der st Wert" , 7: "der ga Wert", 1: "der Wert" } }
Sicherheit
Das OSCORE RFC 8613 (Object Security for Constrained RESTful Environments) Standardprotokoll, das eine Ende-zu-Ende-Sicherheit für CoAP-Nachrichten auf der Anwendungsschicht bietet, verschlüsselt die Anfrage/Antwort-Nachrichten der Anwendungsschicht zwischen den Endpunkten. Dabei wird nicht nur die Nutzlast, die den mit einer Ressource verbundenen Wert enthält, verschlüsselt, sondern auch die Anforderungsmethode, der Bezeichner der Ressource und das Inhaltsformat der Nutzlast. 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 ist und gleichzeitig einen geringen Overhead verursacht.
Neben CoAP verwendet OSCORE auch die Concise Binary Object Representation (CBOR) zur kompakten Kodierung und die CBOR Object Signature and Encryption (COSE) für Verschlüsselungs- und Schlüsselableitungsstrukturen - beide für eingeschränkte Geräteoperationen konzipiert - und mit OSCORE durch Weglassen redundanter Informationen weiter komprimiert. OSCORE verfügt über integrierte Identifikatoren, die Ende-zu-Ende-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 maßgeblich dazu beigetragen, die Höhe des Overheads für eine leichtgewichtige Kommunikationssicherheit zu definieren und übertrifft den Stand der Technik bei der Sicherheit der Transportschicht.
Alles unter einen Hut bringen
Nun sind alle Kommunikationsmechanismen erklärt. Das KNX IoT Gerät hat eine Reihe von URLS, um aufzulisten, welche Funktionsblöcke und Datenpunkte implementiert sind und hat URLs, um das Gerät zu konfigurieren.
Zum Beispiel gibt es 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.
Als Ergebnis werden die folgenden IETF (Internet Engineering Task Force) Spezifikationen in der KNX IoT Point API Spezifikation referenziert:
Zusammenfassung
Der Vorteil von KNX IoT ist, dass die neue Technologie IP-basiert ist und daher über IT-Netzwerke genutzt werden kann. Sie wurde mit garantierter Interoperabilität mit der bestehenden KNX Technologie entwickelt und verwendet die neuesten internetbasierten Technologien in ihrer Spezifikation, wodurch KNX IoT von vornherein sicher ist.
Die Spezifikation wurde mit Blick auf eingebettete Geräte entwickelt, und der Open-Source-Stack, der KNX IoT implementiert, hat sich als recht klein erwiesen und läuft mit nur 512kB Speicher und 96kB 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.
