In deel 4 van deze serie over KNX IoT leggen Bruno Johnson en Wouter van der Beek de architectuur van KNX IoT-apparaten uit en tonen ze hoe KNX IoT compatibel is met KNX Classic systemen.
Digitale transformatie is de laatste jaren één van de belangrijkste strategiethema’s op de agenda’s van bestuursvergaderingen. De mogelijkheid om digitale diensten te ontwikkelen vanuit op de cloud gebaseerde toepassingen vereist op IPv6 gebaseerde netwerkverbindingen met randapparatuur die de klanteninterface wordt. Bedrijven in alle soorten en maten van commerciële gebouwautomatisering hebben gevraagd naar draadloze IoT-oplossingen om dit te realiseren, en KNX Association heeft hierop gereageerd door KNX IoT Point API (KNX IoT) uit te brengen.
De flow op hoog niveau
Om achterwaartse compatibiliteit met KNX Classic systemen (bv. KNX Twisted Pair (KNX TP)) te verzekeren, zijn in de KNX IoT specificatie twee fundamentele mechanismen geïmplementeerd die semantisch gelijkwaardig zijn aan KNX TP: deze mechanismen zijn de configuratie van apparaten en het werkingsgedrag. Voorts volgt de configuratiestroom in een Management Client (MAC, bijvoorbeeld ETS) dezelfde stappen die reeds door installateurs worden gebruikt. Het resultaat is dat er voor installateurs geen verschil is tussen het gebruik van KNX TP en KNX IoT-apparaten. De flow in het gebruik van de nieuwe KNX IoT apparaten is weergegeven in figuur 1.
Het configureren van KNX IoT-apparaten gebruikt dezelfde informatie als voor KNX TP beveiligde apparaten, namelijk:
• Koppeling van het serienummer aan een individueel adres.
• Downloaden van de groepsadresconfiguratie.
– Gebruik van een wachtwoord, vergelijkbaar met de Factory Default Setup Key (FDSK) om de beveiliging in te stellen.
Daarnaast wordt een nieuw kenmerk geïmplementeerd, namelijk een installatie-identificatie (iid). Hierdoor kunnen meerdere installaties via hetzelfde IT-netwerk lopen. Wanneer het apparaat operationeel is (d.w.z. de status is “geladen”), wisselt het s-modus berichten uit met gebruikmaking van de geconfigureerde informatie. Dit is weergegeven in figuur 2.
Merk op dat operationele communicatie mogelijk is tussen N verzendende en M ontvangende apparaten, zoals bij KNX TP.
Architectuur van het apparaat
Webadressen, bijvoorbeeld URL’s, worden op het apparaat geïmplementeerd. Elke URL die het apparaat blootstelt, geeft informatie die vergelijkbaar is met die van een HTTP-server, en elke URL heeft een ander doel. De URL’s worden gedefinieerd in de specificatie en de specificatie bepaalt wat de URL doet in het systeem. Figuur 3 toont de meest voorkomende URL’s in een apparaat.
De URL’s hebben verschillende doelen in het systeem. Dezelfde informatie als bij een KNX TP-apparaat wordt echter via URL’s opgeslagen.
Figuur 3 toont de URL’s op apparaatniveau, en deze bevatten gegevens zoals:
• Serienummer van het apparaat.
• Programmeermodus, (aan of uit).
• Installatie identificatie.
• Status van de laadmachine (“ongeladen”, “bezig met laden”, “geladen”), en actie om de status te veranderen (“ontlaad”, “start met laden”, “laden voltooid”).
• Vingerafdruk van de geladen toestand, om na te gaan of er iets veranderd is.
De URL voor de configuratie
Tabellen worden gebruikt om de operationele communicatie te configureren, bv. het doorgeven van de mapping tussen groepsadres, communicatiemarkeringen, datapunt (URL), beveiligingssleutels en het IPv6-multicastadres voor de groepscommunicatie.
De volgende tabellen worden gebruikt:
• Groepsobjecttabel – deze bevat de toewijzing van de datapunt-URL aan het groepsadres, inclusief de communicatiemarkeringen.
• Ontvangerstabel – deze bevat de koppeling tussen groepsadres en groeps-ID; de groeps-ID wordt gebruikt als onderdeel van het multicast-adres van de s-modus communicatie of om het individuele adres als bestemming te vermelden.
(Uitgaande communicatie)
• Uitgeverstabel – deze bevat de toewijzing van het groepsadres aan het groeps-ID. De groeps-ID wordt gebruikt als onderdeel van het multicast-adres van de s-modus communicatie.
(Inkomende communicatie)
• Veiligheidstabel – deze bevat de OSCORE veiligheidssleutels met OSCORE informatie (‘osc’) en de mapping naar KNX voor groepscommunicatie, bijv. lijst van groepsadressen of de unicast toegangsscopes geïdentificeerd door de lijst van interfaces.
Tabellen beheren
Nieuwe gegevens worden ingevoerd met een internetapplicatieprotocol voor beperkte apparaten dat bekend staat als Constrained Application Protocol (CoAP). Een voorbeeld is een CoAP POST op de tabel-URL met CoAP POST ‘/fp/g’ voor de Groepsobjecttabel. De waarden moeten een correcte invoer definiëren. De gebruikte “ID” zal deel uitmaken van de URL van de nieuwe invoer. Bijvoorbeeld, met ID = ‘item_1’ wordt een nieuw item aangemaakt met een sub URL, bijvoorbeeld ‘/fp/g/item_1′. De MAC heeft dus de controle over het definiëren van de URL’s voor invoer.
De aangemaakte URL wordt vermeld met een CoAP GET op ‘/fp/g’ als een link formaat invoer in het antwoord. Het item kan worden geïnspecteerd door een CoAP GET uit te voeren op “/fp/g/item_1”. Het antwoord geeft de waarden volgens de specificatie. Een item kan worden verwijderd door een CoAP Delete uit te voeren op ‘/fp/g/item_1’. Dit heeft tot gevolg dat de vermelding van het apparaat wordt verwijderd, zodat deze bij een volgende CoAP GET op “/fp/g” niet meer in de lijst voorkomt. Merk op dat het beheer van de tabellen voor groepscommunicatie alleen mogelijk is in de status “laden”.
De URL voor operationele communicatie
De ‘/.knx’ URL wordt gebruikt voor de communicatie van s-modus berichten. De s-modus berichten bevatten de volgende informatie:
• Groepsadres (‘ga’).
• Individueel afzenderadres (“sia”).
• Service type (‘st’).
Het voorbeeld van de s-modusstroom in afbeelding 5 bestaat uit minimaal 2 apparaten, namelijk één dat een s-modusbericht aanmaakt, en een ander dat het s-modusbericht ontvangt. Het verzendende apparaat heeft een Group Object Entry met groepsadres 5 en een URL die de waarde
Multicast s-modus communicatie
De tabel met ontvangers en uitgevers bevat ook invoeren. Deze regels bepalen welk multicast-adres wordt gebruikt. Bijvoorbeeld, een entry met ga = 5 en grpid = 1 zal ertoe leiden dat de waarde grpid=1 deel uitmaakt van het verzendende of ontvangende multicast-adres. Daarom moeten de invoeren in de ontvanger- en de uitgeverstabel voor hetzelfde groepsadres overeenstemmen, anders zou de verzender een ander multicast-adres kunnen gebruiken dan de ontvanger.
Unicast s-modus communicatie – nieuw voor KNX IoT
De unicast-communicatie verschilt door een andere invoer aan de verzendende kant. De verzender heeft een individueel adres van bestemming (“ia”). Het individuele adres moet worden omgezet in een echt IPv6-adres. Dit kan via gangbare IT-protocollen zoals CoAP discovery of multicast DNS (mDNS). Dan kan het eigenlijke IPv6-adres worden gebruikt voor operationele communicatie.
Semantische informatie: functionele blokken en datapunten (nieuw voor KNX IoT)
KNX TP en ETS werken met datalengtes. De semantische informatie van wat in de s-modusberichten staat, wordt dus niet overgedragen. Met KNX IoT is dit echter toegevoegd op apparaatniveau, bv. datapunten die gebruikt worden om de waarde op te halen of in te stellen hebben een (datapunt) URL. De (datapunt)URL kan worden gebruikt om de “dpt”-waarde te verkrijgen door een CoAP GET uit te voeren met de queryparameter ‘?m=*’. Daarnaast geeft de bron /f een lijst van alle functionele blokken, bijv. CoAP GET /f geeft een lijst van alle geïmplementeerde functionele blokken in linkformaat. De URL van elk functioneel blok geeft de geïmplementeerde datapunten over het functioneel blok.
Zoals in figuur 6 te zien is, geeft deze informatie de semantische informatie in dezelfde vorm als bij KNX TP.
Samenvatting
Het voordeel van KNX IoT is dat het perfect interoperabel is met bestaande KNX infrastructuur, terwijl het IP-gebaseerd is. Daarom kunnen meerdere installaties gelijktijdig via hetzelfde (IT-)netwerk werken met behulp van bekabelde (Ethernet/PoE) en draadloze (Thread/WiFi/cellulair) infrastructuur. Het is ontwikkeld met gegarandeerde interoperabiliteit met bestaande KNX-technologie, en het gebruikt de nieuwste onderliggende internet-gebaseerde technologieën in zijn specificatie, waardoor KNX IoT beveiligd is door het ontwerp.
Bruno Johnson en Wouter van der Beek zijn respectievelijk CEO en COO van Cascoda Limited. Cascoda is een communicatiebedrijf dat veilige IoT-halfgeleiderradio’s en -modules produceert en de ontwikkeling van veilige IoT-communicatiestandaarden voor slimme gebouwen en slimme steden leidt. Hun producten lossen problemen met bereik, betrouwbaarheid, veiligheid, vermogen en schaalbaarheid voor industrieel en commercieel IoT op door middel van gepatenteerde innovaties en de meest recente veilige standaarden, allemaal geïntegreerd in goedkope IoT-modules met een ultralaag vermogen.
