Een protocol doorgelicht van A tot Z

Opdracht slechts miniem deel van totale bericht

We halen het spreekwoordelijke fileermes boven en analyseren een protocol tot op het bot. Het slachtoffer van dienst is KNX, maar de analyse geldt in grote lijnen ook voor andere protocollen.

Open en decentraal systeem

KNX hoeven we eigenlijk niet meer voor te stellen. Wel herhalen we nog even twee voorname karakteristieken van KNX, omdat deze belangrijk zijn voor de opbouw van de communicatie. Een eerste is dat het een open systeem betreft: het is niet gebonden aan één fabrikant, elk bedrijf kan naar hartenlust KNX-componenten ontwerpen en laten certificeren. De tweede karaktertrek is de decentrale opbouw. Elke component bezit zelf de intelligentie die nodig is om te functioneren binnen een KNX systeem. Het kan dus zelf de berichten ontvangen en verwerken.

Communicatiewijzes

De communicatiedrager voor KNX kan divers zijn:

• KNX TP (Twisted Pair – de traditionele buskabel).
  Dit was het eerste communicatiemedium waarover KNX berichten verstuurd werden. De datatransfersnelheid ligt op 9.600 bit/s.
• KNX PL (Power Line – via het 230V-netwerk)
  Snelheid is hier 1.200 bit/s.
• KNX RF (Radio Frequency – radiogolf­gestuurd). Via de frequentie 868.3 MHz.
• KNXNet/IP (via ethernet, bluetooth, wifi)
  Vandaag wordt richting KNX IoT gemanoeuvreerd, om zo een meer uniforme werkwijze met de IT-wereld te verkrijgen. De eenvoudige en gestructureerde opbouw van adressen en acties in KNXNet/IP stoot wat tegen de borst van softwareprogrammeurs, want de integratie tussen KNX en internet­gebaseerde applicaties verloopt zo net moeilijker. De boodschap vanuit KNX wordt door KNXnet/IP alleen maar verpakt in een IP-telegram. Er wordt eigenlijk geen meerwaarde toegevoegd aan de data. Maar vandaag volstaat die benadering – in het kader van cyberveiligheid – niet langer. Dat heeft er alles mee te maken dat de connectie tussen KNX en het externe internet vandaag steeds meer rechtstreeks verloopt, terwijl dat vroeger voornamelijk via het LAN-netwerk gebeurde.
  Daarnaast is er ook de belangrijke evolutie naar besturing met tablet & smartphone. De IT-specialisten die de software voor deze toestellen ontwikkelen, prefereren HTTP, Websockets en JavaScript. De KNX-gelieerde IP/UDP (User Datagram Protocol) wordt in de KNX IoT vervangen door een volledig IP-gebaseerde manier van communiceren. Op zich heeft de communicatiewijze geen invloed op de inhoud (‘Payload’ genoemd) van een KNX-telegram, maar wel op de opbouw van de overhead (de extra informatie die meegestuurd wordt). Een telegram ziet er dus wel anders uit, maar de inhoud is hetzelfde.

opbouw van een bericht

De kern van een KNX-telegram vormt de info die de opdracht bevat voor een toestel. Deze data worden gevormd door het 'Payload'-veld. Maar enkel de Payload rondsturen vol­staat niet. Ook info zoals wie de ontvanger en zender is, welk type bericht het betreft, hoe lang de info is, bepaalde prioriteiten … moet vervat worden in een telegram. 

STANDAARDINFORMATIE
De KNX Association definieert de fabrikantsonafhankelijke eigenschappen waaraan de opdracht in een telegram moet voldoen. Op die manier zijn er geen compatibiliteits­problemen mogelijk tussen de verschillende aanbieders. Deze standaard wordt de EIB Interworking Standard genoemd, kortweg de EIS. Dit zijn de opgelijste telegrammen en hun inhoud (zie tabel). 

Rond de Payload kunnen tot zeven extra velden met informatie toegevoegd worden. Dit zijn ze (in volgorde van opbouw):

• Het controleveld heeft een lengte van 8 bits en bevat op zijn beurt drie types informatie: info over telegramtype, herhalingsstatus en de prioriteit die het bericht krijgt.
• Het bronadres bestaat uit 16 bits en geeft weer welk individueel adres het bericht verzendt. Het doeladres heeft eveneens een lengte van 16 bits en bepaalt voor welk adres de payload bedoeld is. Een KNX- toestel verwerkt alleen de payload van een ontvangen telegram wanneer het ook door dat telegram wordt geadresseerd.
• Het adrestype bestaat uit 1 bit (0/1) en geeft weer om welk type communicatie het gaat.
• De hop count zorgt ervoor dat multicast-telegrammen niet eindeloos door een KNX- netwerk worden verstuurd, zelfs wanneer er topologische fouten worden gemaakt.
• De lengte meegeven lijkt onbelangrijk, maar het laat het apparaat toe om exact te detecteren waar de payload zich bevindt in het telegram.
• De payload bevat onder meer het datapakket met de concrete opdracht voor de geadresseerde (open/sluitschakelaar, geef de status van klep X …).
• De checksom is ten slotte altijd de afsluitende pariteitscontrole.

Afhankelijk van de communicatiewijze wordt er nog additionele informatie toegevoegd, bijvoorbeeld welke versie er gebruikt wordt bij KNXnet/IP, of de batterijtoestand bij KNX RF.

Tijdsverloop

Aanmaken adresstructuur

In de ETS-software kunnen de fysieke adres­structuur en de toewijzing van de groepsadressen – voor de koppeling van de componenten – uitgetekend worden. Elke busdeelnemer heeft zijn eigen adres, de structuur gebruikt dit om de telegrammen te versturen. Hierdoor kan een ingang een telegram verzenden naar meerdere uitgangen en kan een uitgang reageren op meerdere ingangen. Een fysiek adres is als volgt opgebouwd: adres= zone.lijn.product = bijvoorbeeld 15.15.255.

Toekennen functies

Na het toekennen van de fysieke adressen moeten de functies per product worden in­gesteld. Dit betekent dat voor elke uitgang en elke ingang een keuze gemaakt moet worden welke functie wordt uitgevoerd. Dit zijn zeer concrete acties: aan/uit, dimmen, op/neer.

Versturen

In een bussysteem kan een telegram pas verstuurd worden als er op dat moment geen enkel ander telegram onderweg is. Om problemen te vermijden, ‘luistert’ elk toestel op de bus naar de datatransferinformatie in de bus. Als twee toestellen op hetzelfde moment een telegram willen versturen, zal toestel A een pariteit ‘0’ versturen. Toestel B wil op dat moment een ‘1’ versturen, maar detecteert de 0 van toestel A. Op dat moment is B verplicht om zijn communicatie uit te stellen en zo voorrang te verlenen aan A. Zodra die communicatie achter de rug is, wordt er door B een nieuwe poging ondernomen. Dit is een zeer eenvoudig voorbeeld, maar in de praktijk kan de prioriteit in geval van conflicten tussen telegrammen vastgelegd worden in het controleveld. Als die prioriteit vastligt, maar twee telegrammen over het­zelfde niveau beschikken, dan is het de opbouw van het fysieke adres die bepaalt wie eerst mag (eerst 0, dan 1). Deze werkwijze gaat op voor KNX TP, de andere communicatiewijzes hebben een aangepaste werkwijze.

Bevestigen

Na ontvangst van het telegram bevestigen de deelnemers de correcte ontvangst door het zenden van een bevestiging. ‘Bevestiging’ betekent hier niet a priori een positief ant­woord. Dit zijn de mogelijke bevestigingen:

• Positieve bevestiging = LL_ACK: bericht is ontvangen, de verzender van de telegrammen herhaalt het telegram niet.
• Negatieve bevestiging = LL_NAK of LL_BUSY: bericht werd niet goed ontvangen of kon niet ontvangen worden. De verzender van het telegram herhaalt het telegram drie keer.
• Geen (reactie): de verzender van het telegram herhaalt het telegram drie keer. Na die pogingen stopt de verzender zijn actie.

Vervolgens kan de cyclus opnieuw beginnen met een nieuwe opdracht.

En de toekomst?

De opkomst van IoT en de consumenten die steeds vaker willen overschakelen op smart­phones en tablets voor de aansturing van hun installatie, nopen ook domoticaprotocollen tot een aanpassing. Zo prefereren IT-specialisten die de software voor deze toestellen ontwikkelen, onder meer HTTP, Websockets en JavaScript als taal. KNX speelde daar een aantal jaar terug al op in met KNX IP, maar die werkwijze voldeed niet langer omdat dit enkel een herverpakking was van het KNX-protocol in een IP-jasje. Daarom lanceerde men vorig jaar KNX IoT, waarbij het KNX-gelieerde IP/UDP (User Datagram Protocol) wordt vervangen door een volledig IP-gebaseerde manier van communiceren.