In Teil 4 dieser Serie über KNX IoT erklären 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, 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.
Der Ablauf auf hoher Ebene
Um die Rückwärtskompatibilität zu KNX Classic Systemen (z.B. KNX Twisted Pair (KNX TP)) zu gewährleisten, 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 Konfigurationsfluss 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 zwischen der Verwendung von KNX TP und KNX IoT Geräten gibt. Der Ablauf bei der Nutzung der neuen KNX IoT Geräte ist in Abbildung 1 dargestellt.
Für die Konfiguration 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 Konfiguration der Gruppenadresse.
- Verwendung eines Passworts, ähnlich dem Factory Default Setup Key (FDSK), um die Sicherheit einzurichten.
Neben diesem wird ein neues Feature implementiert, nämlich eine Installationsidentifikation (iid). Damit können mehrere Installationen über dasselbe IT-Netz laufen. Wenn das Gerät in Betrieb ist (d. h. der Zustand "geladen"), tauscht es unter Verwendung der konfigurierten Informationen s-mode-Nachrichten aus. Dies ist in Abbildung 2 dargestellt.
Beachten Sie, dass die Laufzeitkommunikation zwischen N Sendegeräten und M Empfangsgeräten aufgebaut werden kann, wie bei KNX TP.
Gerätearchitektur
Webadressen, z.B. URLs, werden auf dem Gerät implementiert. Jede URL, die das Gerät bereitstellt, 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 tut. Abbildung 3 zeigt die häufigsten URLs in einem Gerät.
Die URLs haben unterschiedliche Zwecke im System. Es werden jedoch die gleichen Informationen wie bei einem KNX TP Gerät über URLs gespeichert.
Abbildung 3 zeigt die URLs auf Geräteebene, und diese übermitteln die Daten wie:
- Seriennummer des Geräts.
- Programmiermodus, (ein oder aus).
- Kennung der Installation.
- Status des Ladegerätes ('unloaded', 'loading', 'loaded') und Aktion zur Änderung des Status ('unload', 'starLoading', 'loadcompleted').
- Fingerabdruck des geladenen Zustands, um zu verfolgen, ob sich etwas geändert hat.
Die URL für die Konfiguration
Tabellen werden verwendet, um die Laufzeitkommunikation zu konfigurieren, z.B. um das Mapping zwischen Gruppenadresse, Kommunikationsflags, Datenpunkt (URL), Sicherheitsschlüsseln und der IPv6-Multicast-Adresse für die Gruppenkommunikation zu übermitteln.
Die folgenden Tabellen werden verwendet:
- Gruppenobjekttabelle - diese enthält die Zuordnung der Datenpunkt-URL zur Gruppenadresse, einschließlich der Kommunikationsflags.
- Recipient Table - diese enthält die Zuordnung von Gruppenadresse zu Gruppenkennung; die Gruppenkennung wird als Teil der Multicast-Adresse der S-Mode-Kommunikation oder zur Auflistung der individuellen Adresse als Ziel verwendet.
(Kommunikation nach außen)
- Publisher Table - diese enthält die Zuordnung von Gruppenadresse zu Gruppen-ID. Die Gruppenkennung wird als Teil der Multicast-Adresse der S-Mode-Kommunikation verwendet.
(Kommunikation nach innen)
- Sicherheitstabelle - 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 Unicast-Zugangsbereiche, die durch die Liste der Schnittstellen identifiziert werden.
Verwaltung von 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 mit CoAP POST '/fp/g' für die Group Object Table. Die Werte müssen einen korrekten Eintrag definieren. Die verwendete 'id' wird Teil der URL des neuen Eintrags sein. Wird beispielsweise id = 'item_1' verwendet, entsteht ein neuer Eintrag mit einer Unter-URL, z. B. '/fp/g/item_1'. Somit hat der MAC die Kontrolle über die Definition der Eintrags-URLs.
Die erstellte URL wird mit einem CoAP GET auf '/fp/g' als Eintrag im Linkformat in der Antwort aufgeführt. Der Eintrag kann durch einen CoAP GET auf '/fp/g/item_1' eingesehen werden. Die Antwort enthält die Werte gemäß der Spezifikation. Ein Eintrag kann entfernt werden, indem ein CoAP Delete auf "/fp/g/item_1" abgesetzt 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 aufgeführt wird. Beachten Sie, dass die Verwaltung der Tabellen für die Gruppenkommunikation nur im Zustand 'loading' möglich ist.
Die URL für die Kommunikation während der Laufzeit
Die '/.knx' URL wird für die Kommunikation von s-mode Nachrichten verwendet. Die s-mode-Meldungen enthalten folgende Informationen:
- Gruppenadresse ('ga').
- Absender-Einzeladresse ('sia').
- Dienstart ('st').
Der in Abbildung 5 gezeigte beispielhafte s-mode Fluss besteht aus mindestens 2 Geräten, nämlich einem, das eine s-mode Nachricht erstellt, und einem anderen, das die s-mode Nachricht empfängt. Das sendende Gerät hat einen Gruppenobjekteintrag mit der Gruppenadresse 5 und einer URL, die den Wert <value> darstellt/enthält und das Übertragungsflag ('t') hat. Wenn etwas das Setzen der s-mode-Nachricht auslöst, wird die s-mode-Nachricht erstellt und verschlüsselt über die Leitung gesendet. Das empfangende Gerät hat ebenfalls einen Gruppenobjekteintrag mit der Gruppenadresse = 5 und dem Kommunikationsflag write ('w'), was bedeutet, dass die entsprechende URL mit dem empfangenen <value> aktualisiert wird.
Multicast s-mode Kommunikation
Die Empfänger- und Verlegertabelle haben ebenfalls Einträge. Diese Einträge bestimmen, welche Multicast-Adresse verwendet wird. Zum Beispiel führt ein Eintrag mit ga = 5 und grpid = 1 dazu, dass der Wert grpid=1 Teil der sendenden oder empfangenden Multicast-Adresse ist. Daher müssen die Einträge in der Empfänger- und Verlegertabelle 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 durch einen anderen Eintrag auf der Senderseite. Der Absender hat eine individuelle Zieladresse ('ia'). Die individuelle Adresse muss in eine tatsächliche IPv6-Adresse aufgelöst werden. Dies kann über gängige IT-Protokolle wie CoAP Discovery oder Multicast DNS (mDNS) erfolgen. Dann kann die tatsächliche IPv6-Adresse für die Laufzeitkommunikation verwendet werden.
Semantische Informationen: Funktionsblöcke und Datenpunkte (Neu für KNX IoT)
KNX TP und ETS arbeiten mit Datenlängen. Daher wird die semantische Information, was in den s-mode Nachrichten enthalten ist, 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, d.h. CoAP GET auf /f liefert eine Liste aller implementierten Funktionsblöcke im Link-Format. Die URL eines jeden Funktionsblockeintrags gibt die implementierten Datenpunkte des Funktionsblocks an.
Wie in Abbildung 6 oben zu sehen ist, gibt diese Information die semantische Information in der gleichen Form wie bei KNX TP.
Zusammenfassung
Der Vorteil von KNX IoT ist, dass es perfekt mit der bestehenden KNX-Infrastruktur interoperabel ist, während es gleichzeitig IP-basiert ist. So können mehrere Installationen gleichzeitig über dasselbe (IT-)Netzwerk laufen, wobei eine drahtgebundene (Ethernet/PoE) und eine drahtlose (Thread/WiFi/Zellular) Infrastruktur verwendet wird. Es wurde mit garantierter Interoperabilität mit bestehender KNX Technologie entwickelt und verwendet die neuesten internetbasierten Technologien in seiner Spezifikation, wodurch KNX IoT von vornherein 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.
