In de derde van deze reeks artikelen over KNX IoT leggen Bruno Johnson en Wouter van der Beek de grondbeginselen van KNX IoT apparaten uit.
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 grondbeginselen
Om achterwaartse compatibiliteit met andere KNX media (KNX Classic installaties) te verzekeren, beschrijft de KNX IoT specificatie in de KNX systeem specificaties groep (3_10_5 KNX IoT Point API):
• Een nieuwe transportlaag op basis van IPv6, bijvoorbeeld Wi-Fi, Ethernet en Thread-gebaseerde netwerken.
• Een nieuw communicatie-/berichtenprotocol dat de volgende communicatiemodi mogelijk maakt:
- Point-to-Multipoint, Connectionless (Multicast).
- Point-to-Point, Connectionless.
- Point-to-Point, Connection-Oriented.
Voorts moet het nieuwe transport dezelfde datapunten gebruiken als de bestaande KNX-transportlagen zoals gedefinieerd in de specificaties van de toepassingsbeschrijvingen (volume 7).
Het ontwerpen van het nieuwe transportmedium met deze beperkingen zal de huidige toepassing van KNX niet veranderen. Het heeft nog steeds dezelfde aanpak in ETS bij het configureren van de apparaten, en de apparaten communiceren nog steeds met elkaar door middel van S-mode berichten.
De technologie-stack
Apparaten moeten kunnen communiceren via IPv6, ongeacht de gebruikte fysieke laag, wat betekent dat Ethernet (inclusief PoE), Wi-Fi en Thread worden ondersteund. Thread is inderdaad inherent op IPv6 gebaseerd.
Discovery
Om via IP te communiceren, moet men het IP-adres en de poort van het KNX-apparaat kennen. Om deze gegevens op te vragen worden twee verschillende ontdekkingsmechanismen gebruikt.
1) mDNS discovery is een protocol dat gebruik maakt van multicast DNS (mDNS) om apparaten en diensten op het lokale netwerk te vinden zonder hun IP-adres te kennen. Het is ook bekend als nul-configuratie, Bonjour, of Avahi. Het wordt veel toegepast voor smart home-apparaten, draadloze Arduino apparaten, printers, luidsprekers, netwerkopslagapparaten, enz. Het werkt door pakketten te sturen naar elk knooppunt op het netwerk om hostnamen om te zetten en diensten op te vragen. Het kan worden gebruikt met DNS Service Discovery (DNS-SD) om diensten te zoeken en om te zetten op basis van de hostnaam of de dienst. Het werkt alleen voor het .local top-level domein (TLD).
mDNS discovery maakt ontdekking mogelijk op basis van:
– Serienummer.
– Individueel adres.
– Programmeermodus.
2) De CoAP (Constrained Application Protocol) discovery is een speciaal CoAP-verzoek, om de resources van een bekende host te ontdekken. Om de host te ontdekken kan een multicast-aanvraag worden gebruikt, maar deze moet door de server worden ondersteund.
CoAP discovery maakt ontdekking mogelijk op basis van:
– Serienummer.
– Individueel adres.
– Programmeermodus.
– Ontdekking van een apparaat dat een specifiek gegevenspunt bevat.
– Ontdekking van een apparaat dat een specifiek functieblok bevat.
Telegram transporten
Het volgende niveau is communiceren over IPv6 met behulp van CoAP. Dit is de laag die de KNX telegrammen van de verzender naar de bestemming transporteert. Dit gebeurt met behulp van URL’s. De eenvoudigste manier om CoAP te bekijken is dat het gelijkwaardig is aan HTTP waarbij het versturen van berichten met behulp van het request en response paradigma, tussen een Client (initiator) en een Server (responder) wordt geïmplementeerd. Het belangrijkste verschil tussen HTTP en CoAP is dat de CoAP-headers in binair formaat zijn en dat CoAP over UDP werkt.
De commando’s voor de berichten zijn dezelfde:
- GET – voor het ophalen van gegevens.
- POST – voor het gedeeltelijk bijwerken van gegevens.
- PUT – voor volledige bijwerking van gegevens.
- DELETE – om een resource te verwijderen.
Daarnaast is OBSERVE een nieuwe functie die lijkt op de HTTP long poll. Met Observe kunnen meerdere antwoorden worden verkregen. Bijvoorbeeld; wanneer de gegevens veranderen, wordt een nieuw antwoord gestuurd naar het Observe-verzoek. Om dezelfde betrouwbaarheid te hebben als HTTP over TCP, heeft het CoAP-protocol bevestigde overdrachten geïmplementeerd. Het opnieuw verzenden van de pakketten, wanneer deze niet worden bevestigd, maakt dus deel uit van CoAP en daarom zijn verzoeken met CoAP-bevestiging even betrouwbaar als HTTP over TCP. De payload van een bericht wordt bepaald door het inhoudstype, dat wil zeggen dat verschillende formaten kunnen worden ondersteund, zoals bij HTTP.
Payload typen
De KNX IoT specificatie gebruikt twee inhoudsformaten, elk voor een andere functie. De eerste is voor de opsomming van de URL’s (gegevenspunten/functieblokken) waarmee kan worden geinteracteerd, en de tweede voor de interactie met de URL’s.
Het Application-Link formaat
Dit inhoudsformaat maakt de beschrijving mogelijk van gehoste bronnen, hun attributen en andere relaties tussen links. Op basis van het in RFC 5988, gedefinieerde HTTP Link Header-veld wordt het Constrained RESTful Environments (CoRE) Link Format als payload meegevoerd en krijgt het een Internet mediatype toegewezen. Een bekende URL wordt gedefinieerd als een standaard ingangspunt voor het opvragen van de links die door een server worden gehost.
Typisch antwoord
Een voorbeeld van een typisch antwoord is als volgt:
Elke regel bevat:
– De gehoste URL (tussen ).
– Het type resource (rt), dat aangeeft wat het is.
– Het inhoudstype, bijv. 60 voor CBOR en 40 voor Application-Link Format.
Hierdoor kan de cliënt met het apparaat communiceren op basis van een URL.
Interactie met een apparaat
De URL kan worden gezien als een gegevenspunt waarmee kan worden gewerkt via sleutelwaardeparen. De sleutelwaardeparen worden beschreven met de Concise Binary Object Representation (CBOR). CBOR is een binair gegevensserialisatieformaat dat losjes gebaseerd is op JSON. Net als JSON maakt het de overdracht mogelijk van gegevensobjecten die naam-waardeparen bevatten, maar op een beknoptere manier. Dit verhoogt de verwerkings- en overdrachtssnelheid ten koste van de menselijke leesbaarheid. Het opent echter de documentatie: definieer de payloads in JSON om de menselijke leesbaarheid van de specificatie te vergroten en het binaire formaat op de kabel te hebben.
De gegevens voor een S-bericht kunnen als volgt in JSON worden gedefinieerd:
{ “s”: { “st”: “the st value” , “ga”: “the ga value”, “value”: “the value” } }
De JSON-sleutels kunnen worden vervangen door gehele getallen om het bericht nog kleiner te maken, en wel als volgt:
{ 5: { 6: “the st value” , 7: “the ga value”, 1: “the value” } }
Beveiliging
Het OSCORE RFC 8613 (Object Security for Constrained RESTful Environments) standaardprotocol dat end-to-end beveiliging biedt voor CoAP-berichten op de toepassingslaag, versleutelt de verzoek-/antwoordberichten op de toepassingslaag tussen eindpunten. Niet alleen de payload met de waarde die aan een bron is gekoppeld, wordt versleuteld, maar ook de verzoekmethode, de identificatiecode van de bron en het inhoudsformaat van de payload. Dit betekent dat de voor de toepassing relevante gegevens en de semantiek van het verzoek/antwoord kunnen worden beschermd op een wijze die is losgekoppeld van het vervoer van de berichten, terwijl de overhead laag is.
Naast CoAP gebruikt OSCORE ook de Concise Binary Object Representation (CBOR) voor compacte codering en de CBOR Object Signature and Encryption (COSE) voor encryptie en sleutelafleidingsstructuren – beide ontworpen voor beperkte apparaatbewerkingen – en verder gecomprimeerd met OSCORE door overbodige informatie weg te laten. OSCORE heeft ingebouwde identifiers die end-to-end operaties over verschillende paden mogelijk maken, met of zonder IP.
De berichtoverhead is minimaal omdat OSCORE alleen de relevante informatie van de toepassingslaag beschermt, en de hoeveelheid gegevens die aan de omvang van het oorspronkelijke CoAP-bericht wordt toegevoegd, kan met ingebouwde identificatiemiddelen slechts 11-13 bytes bedragen. OSCORE heeft bijgedragen tot de definitie van het overheadniveau voor lichtgewicht communicatiebeveiliging en presteert beter dan state-of-the-art transportlaagbeveiliging.
Om alles samen te vatten
Hiermee zijn alle communicatiemechanismen uitgelegd. KNX IoT apparaten hebben een reeks URL’s om op te sommen welke functionele blokken en datapunten geïmplementeerd zijn en hebben URL’s om het apparaat te configureren.
Zo zijn er resources (datapunten) voor het configureren van het apparaat. Bestaande concepten als Load State Machine (LSM), programmeermodus (PM), individueel adres (IA) en Groepsobjecttabel worden gemodelleerd met de hierboven beschreven mechanismen.
Als resultaat worden de volgende IETF (Internet Engineering task Force) specificaties aangehaald in de KNX IoT Point API specificatie:
Samenvatting
Het voordeel van KNX IoT is dat de nieuwe technologie op IP is gebaseerd en dus via IT-netwerken kan worden gebruikt. 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 veilig is door het ontwerp.
De specificatie werd speciaal voor ingebouwde apparaten ontworpen en de opensource stack die KNX IoT implementeert, blijkt met slechts 512 kB opslaggeheugen en 96 kB geheugen vrij klein te zijn.
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.
