In Teil 4 dieser Serie über KNX IoT erläutern Bruno Johnson und Wouter van der Beek die Architektur von KNX IoT Geräten und zeigen, wie KNX IoT mit KNX Classic Systemen kompatibel ist.
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.
Der High-Level-Ablauf
Zur Gewährleistung der Rückwärtskompatibilität mit KNX Classic Systemen (z.B. KNX Twisted Pair (KNX TP)) sind in der KNX IoT Spezifikation zwei grundlegende Mechanismen implementiert, die semantisch äquivalent zu KNX TP sind: Diese Mechanismen sind die Konfiguration von Geräten und das Laufzeitverhalten. Darüber hinaus folgt der Konfigurationsablauf in einem Management Client (MAC, z. B. ETS) denselben Schritten, die bereits von Installateuren verwendet werden. Das Ergebnis ist, dass es für Installateure keinen Unterschied gibt, ob sie KNX TP oder KNX IoT Geräte verwenden. Der Ablauf zur Nutzung der neuen KNX IoT-Geräte ist in Abbildung 1 dargestellt.
Zum Konfigurieren von KNX IoT-Geräten werden die gleichen Informationen wie für KNX TP sichere Geräte verwendet, nämlich:
• Zuordnung der Seriennummer zu einer individuellen Adresse.
• Herunterladen der Gruppenadresskonfiguration.
• Das Verwenden eines Passworts, ähnlich dem Factory Default Setup Key (FDSK), um die Sicherheit einzurichten.
Darüber hinaus wird ein neues Merkmal eingeführt, nämlich eine Installationsidentifikation (iid). So können mehrere Installationen über dasselbe IT-Netz laufen. Wenn das Gerät in Betrieb ist (d. h. der Status ist „geladen“), übermittelt es S-Mode-Nachrichten unter Verwendung der konfigurierten Informationen. Dies wird in Abbildung 2 dargestellt.
Zu beachten ist, dass die Kommunikation zur Laufzeit zwischen N sendenden Geräten und M empfangenden Geräten aufgebaut werden kann, wie bei KNX TP.
Gerätearchitektur
Internetadressen, z. B. URLs, werden auf dem Gerät implementiert. Jede URL, die das Gerät zur Verfügung stellt, liefert Informationen ähnlich wie ein HTTP-Server, und jede URL hat einen anderen Zweck. Die URLs sind in der Spezifikation festgelegt, und die Spezifikation definiert, was die URL im System bewirkt. Abbildung 3 zeigt die meistgenutzten URLs in einem Gerät.
Die URLs haben unterschiedliche Zwecke im System. Allerdings werden die gleichen Informationen wie bei einem KNX TP Gerät über URLs gespeichert.
Abbildung 3 zeigt die URLs auf Geräteebene, die Daten wie diese übermitteln:
• Seriennummer des Geräts.
• Programmiermodus (ein- oder ausgeschaltet).
• Installationskennzeichen.
– Status des Ladevorgangs (‚unloaded‘, ‚loading‘, ‚loaded‘) und Aktion zur Änderung dieses Status (‚unload‘, ’startLoading‘, ‚loadcompleted‘).
– Fingerabdruck des geladenen Status, um festzustellen, ob sich etwas geändert hat.
Die URL für die Konfiguration
Tabellen werden zur Konfiguration der Runtime-Kommunikation verwendet, z. B. zur Übermittlung der Zuordnung zwischen Gruppenadresse, Kommunikationsflaggen, Datenpunkt (URL), Sicherheitsschlüsseln und der IPv6-Multicast-Adresse für die Gruppenkommunikation.
Die folgenden Tabellen werden verwendet:
• Group Object Table – diese enthält die Zuordnung der Datenpunkt-URL zur Gruppenadresse, einschließlich der Kommunikationsflaggen.
• Recipient Table – diese enthält die Zuordnung von Gruppenadresse zu Gruppen-Id; die Gruppen-Id wird als Teil der Multicast-Adresse der S-Mode-Kommunikation oder zur Auflistung der individuellen Adresse als Ziel verwendet.
(Ausgehende Kommunikation)
• Publisher Table – diese enthält die Zuordnung von Gruppenadresse zu Gruppen-Id. Die Gruppen-Id wird als Teil der Multicast-Adresse der S-Mode-Kommunikation verwendet.
(Eingehende Kommunikation)
• Security Table – diese enthält die OSCORE-Sicherheitsschlüssel mit OSCORE-Informationen („osc“) und die Zuordnung zu KNX für die Gruppenkommunikation, z. B. die Liste der Gruppenadressen oder die durch die Liste der Schnittstellen identifizierten Unicast-Zugriffsbereiche.
Verwaltung der Tabellen
Neue Einträge werden mit einem Internet-Anwendungsprotokoll für eingeschränkte Geräte, dem Constrained Application Protocol (CoAP), vorgenommen. Ein Beispiel wäre ein CoAP POST auf die Tabellen-URL unter Verwendung von CoAP POST „/fp/g“ für die Gruppenobjekttabelle. Die Angaben müssen einen korrekten Eintrag definieren. Die verwendete „id“ wird Teil der URL des neuen Eintrags sein. Wenn Sie zum Beispiel id = „item_1“ verwenden, wird ein neuer Eintrag mit einer Unter-URL erstellt, z. B. „/fp/g/item_1“. Also hat der MAC die Kontrolle über die Definition der Eintrags-URLs.
Die erstellte URL wird mit einem CoAP GET auf ‚/fp/g‘ als Linkformateintrag in der Antwort aufgeführt. Der Eintrag kann durch einen CoAP GET auf „/fp/g/item_1“ aufgerufen werden. Die Antwort ergibt die Werte gemäß der Spezifikation. Ein Eintrag kann entfernt werden, indem ein CoAP Delete an „/fp/g/item_1“ gesendet wird. Dies hat zur Folge, dass der Eintrag aus dem Gerät entfernt wird, so dass er bei einem nachfolgenden CoAP-GET auf „/fp/g“ nicht mehr aufgelistet wird. Beachten Sie, dass die Verwaltung der Tabellen für die Gruppenkommunikation nur im Zustand „loading“ möglich ist.
Die URL für die Runtime-Kommunikation
Die URL ‚/.knx‘ wird für die Übermittlung von S-Mode-Nachrichten verwendet. Die S-Mode-Nachrichten enthalten die folgenden Informationen:
• Gruppenadresse („ga“).
• Individuelle Absenderadresse („sia“).
• Servicetyp (’st‘).
Das in Abbildung 5 gezeigte Beispiel eines S-Mode-Ablaufs besteht aus mindestens zwei Geräten, nämlich einem, das eine S-Modus-Nachricht erstellt, und einem anderen, das die S-Modus-Nachricht empfängt. Das sendende Gerät verfügt über einen Gruppenobjekteintrag mit der Gruppenadresse 5 und einer URL, die den Wert
Multicast S-Mode Kommunikation
Die Empfänger- und die Publisher-Tabelle enthalten ebenfalls Einträge. Diese Einträge bestimmen, welche Multicast-Adresse verwendet wird. Zum Beispiel wird ein Eintrag mit ga = 5 und grpid = 1 dazu führen, dass der Wert grpid=1 Teil der sendenden oder empfangenden Multicast-Adresse ist. Deshalb müssen die Einträge in der Empfänger- und der Publisher-Tabelle für dieselbe Gruppenadresse übereinstimmen, sonst könnte der Sender eine andere Multicast-Adresse verwenden als der Empfänger.
Unicast S-Mode Kommunikation – neu für KNX IoT
Die Unicast-Kommunikation unterscheidet sich darin, dass auf der Senderseite ein anderer Eintrag vorhanden ist. Der Absender hat eine individuelle Zieladresse („ia“). Die individuelle Adresse muss in eine tatsächliche IPv6-Adresse aufgelöst werden. Dies kann mittels gängiger IT-Protokolle wie CoAP Discovery oder Multicast DNS (mDNS) geschehen. Dann kann die aktuelle IPv6-Adresse für die Runtime-Kommunikation verwendet werden.
Semantische Informationen: Funktionsblöcke und Datenpunkte (Neu für KNX IoT)
KNX TP und ETS arbeiten mit Datenlängen. Daher werden die semantischen Informationen, die in den S-Mode-Nachrichten enthalten sind, nicht übertragen. Mit KNX IoT wurde dies jedoch auf der Geräteebene hinzugefügt, z. B. haben Datenpunkte, die zum Abrufen oder Setzen des Wertes verwendet werden, eine (Datenpunkt-)URL. Die (Datenpunkt-)URL kann verwendet werden, um den „dpt“-Wert zu erhalten, indem ein CoAP GET mit dem Abfrageparameter ‚?m=*‘ ausgegeben wird. Daneben listet die Ressource /f alle Funktionsblöcke auf, z.B. CoAP GET auf /f liefert eine Liste aller implementierten Funktionsblöcke im Link-Format. Die URL jeder Funktionsblockeintragung enthält die implementierten Datenpunkte des Funktionsblocks.
Wie in Abbildung 6 zu sehen ist, gibt diese Information die semantische Information in der gleichen Form wie bei KNX TP.
Fazit
Der Vorteil von KNX IoT ist, dass es perfekt mit der bestehenden KNX Infrastruktur interoperabel ist, und gleichzeitig IP-basiert ist. So können mehrere Installationen gleichzeitig über dasselbe (IT-)Netzwerk unter Verwendung einer kabelgebundenen (Ethernet/PoE) und drahtlosen (Thread/WiFi/Zellular) Infrastruktur laufen. 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.
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.
