Communicatieprotocollen:
ziet u door de bomen het bos nog?

Onderscheid nodig tussen dataprotocol en communicatiewijze

De wildgroei van communicatieprotocollen in domotica- en andere technieken levert vaak kopbrekens op. Soms is er meer programmeerwerk nodig om alles met elkaar te laten spreken dan dat er tijd kruipt in de installatie. Hoe ga je hier als elektricien mee om?

Alles verbonden?

We leven in een snel veranderende wereld. De tijd dat enkel de pc verbonden werd met het internet, is allang achter de rug. Het Internet Of Things vordert met rasse schreden, waarbij zeer diverse apparaten en doordeweekse gebruiksvoorwerpen met internet ver­bonden worden. Tegen volgend jaar zouden maar liefst 30 miljard toestellen verbonden zijn met het internet.

Wie had vijftien jaar terug durven voorspellen dat we zelfs onze verlichting zouden regelen via internet? Is dat een evolutie die we toejuichen? Ja, uit het standpunt van de consument. Het brengt ongekende mogelijkheden met zich mee. Voor de installateur is het niet altijd een hoeraverhaal.

Nieuwe spelers

Ook aan de fabrikantenzijde worden de evoluties met argusogen gevolgd. Nieuwe producten van technologiegiganten zoals Apple, Amazon en Google genereren wekelijks aandacht voor domoticasystemen, denk aan de opkomst van Alexa van Amazon en Google Home.

Vooral bij de jongere generaties – de klanten voor de nabije toekomst – zijn deze toepassingen ontzettend populair aan het worden. Die techgiganten zien dan ook brood in deze markt. De lancering van slimme thermostaten als Google Nest is alvast een mooi voorbeeld van dit streven.

Als installateur is het zaak om op de hoogte te zijn van deze markante evoluties.

Een reëel voorbeeld

Gegeven

• Een woning met een zonnepaneleninstallatie waarvan de bewoner de opbrengst wil kunnen volgen op zijn pc.
• Aanbellen aan diezelfde woning moet via een toegangscontrolesysteem, waarvan het beeld naar mobiele toestellen gecommuniceerd moet worden.
• Het domoticasysteem werkt op basis van KNX, maar de bewoner wil ook een Alexa assistent en zijn Google account via een Raspberry PI verbinden met zijn router en LAN-netwerk.
• Zijn pas aangekochte tv is een smart-tv. De geluidsinstallatie werkt via een Crestron processor, maar ook de smart-tv en de HMI (touchscreen) om de woning aan te sturen worden op dat toestel aangesloten.
• Verder is er nog een aparte licht- en rolluiksturing.
• Tot slot moet er ook nog een alarmcentrale aangesloten worden.

Gevraagd

De uitdaging? Zorg dat de bewoner alles kan laten communiceren met één touchscreen. Komt het u bekend voor?Menige elektricien zal zich eens in de haren krabben, want we zijn van nature uit doeners, geen programmeurs. Om de communicatie tussen al deze onderdelen te stroomlijnen, volstaat het wat hardware betreft vaak om een eenvoudige gateway te plaatsen, maar daar stopt het helaas niet. Het daaropvolgende programmeerwerk vormt de échte uitdaging. En zelfs wie kaas gegeten heeft van programmeren, heeft de nodige software nodig om die taak naar behoren te kunnen uitvoeren. Omdat er zoveel diverse protocollen zijn, is ook dat niet evident. Vaak is men genoodzaakt om meerdere softwareprogramma’s te kennen om al de toestellen met elkaar te kunnen koppelen. Een absurde situatie, waarin de installatiebranche helaas niet het alleenrecht heeft. Ondertussen werkt de toevloed van apps voor de smartphone de eindklant meer op de zenuwen dan wat anders: hij wil één allesomvattend systeem, geen 10 verschillende apps om zijn pv-opbrengst, licht, rolluiken en verwarming aan te sturen. Standaardisatie is hier de oplossing, maar dat ligt niet zo eenvoudig.

Open en gesloten protocollen

Als we even snel een aantal protocollen uit onze branche oplijsten, zien we dat het aantal al snel oploopt: EnOcean, Crestron, Autobus (Teletask), Duotecno, Niko Home, Apple HomeKit, Modbus (energiemetingen), Mbus, Qbus, Bticino, IFTTT, Loxone, Somfy, Casambi, ZigBee, BLE-sensoren, 433 Mhz, 868 Mhz, Bluetooth, Bluetooth Smart (low energy), Google Cast, Infrarood, IP, Somfy RTS, WiFi, X10, Z-Wave …

Vaak worden deze ‘protocollen’ door elkaar gehaald omdat de term ‘protocol’ meerdere ladingen dekt. Het is wat een containerbegrip geworden waarbij alles op één hoopje gegooid wordt, en dat is eigenlijk niet correct. Zo kan een KNX-datapakket bijvoorbeeld verstuurd worden via een bussysteem, maar evengoed via ethernet, RF (draadloos) of Powerline.

Er is dus een belangrijk onderscheid tussen de wijze waarop de data samengesteld worden in een protocol en de wijze waarop die data gecommuniceerd worden met de andere entiteiten.

Maar ook in de communicatievormen zijn er nog diverse onderverdelingen. Zo kun je wifi hebben, maar geen internet. Je hebt draadloos, maar ook daarin zijn tientallen onderverdelingen (ZigBee, EnOcean, Bluetooth …).

U merkt ook dat er enkele specifiek aan fabrikanten gebonden systemen tussen zitten, maar ook systemen die door meerdere bedrijven aangeboden worden. Dat is meteen ook een belangrijk onderscheid: gesloten en open systemen.

Systemen als Autobus van Teletask en Niko Home zijn gesloten merkafhankelijke protocollen, maar dat betekent niet dat de gebruiker er enkel de fabrikantspecifieke componenten op kan aansluiten. Wie een DALI-lichtsturing op zijn gesloten systeem wil aansluiten, zal dat kunnen als de fabrikant in kwestie zelf een gateway aanbiedt om de communicatie te kunnen realiseren.

Wel zul je bij deze gesloten protocollen geen gateways vinden naar andere gesloten protocollen. Een gateway van Teletask naar Niko zul je niet gauw vinden en vice versa.

Bij open protocollen staat het fabrikanten vrij om hun componenten compatibel te maken met deze standaard. Daarbij moeten ze zorgen dat de communicatie volledig volgens de opgestelde regels van de bewuste organisatie verloopt.

Als we KNX als voorbeeld nemen, betekent dit dat de KNX-organisatie zelf geen toestellen ontwikkelt, maar enkel de open standaard. Het staat de fabrikanten vrij om hun apparaten te voorzien van de mogelijkheid om volgens de KNX-standaard te werken en ze als dusdanig te laten certificeren, iets wat ondertussen breed gedragen wordt door fabrikanten.

Centraal of decentraal systeem?

Een ander belangrijk onderscheid dat we kunnen maken bij protocollen, is het verschil tussen centrale en decentrale systemen. Bij een centraal systeem is er één component die de installatie aanstuurt en dus alle logica bevat. Bij decentrale systemen beschikt elk toestel zelf over de nodige intelligentie om zijn eigen taak uit te voeren.

OSI-model

Een belangrijk hulpmiddel om protocollen in kaart te brengen en te vergelijken is het OSI-model. Voluit staat dat voor Open Systems Interconnection Model en het is ontworpen door de  International Organization for Standardization (ISO). Zij voelden ook aan dat er nood was aan een vergelijkingskader tussen verschillende technische datacommunicatiesystemen. Het kan ook worden toegepast op domoticaprotocollen.

De opbouw is in zeven lagen, waarbij per protocol telkens een beschrijving van de werkwijze gegeven kan worden, zoals rond de communicatieregeling, de adressering van het doelsysteem of het omzetten van datapakketten in fysieke signalen.

Let wel: het OSI-model is geen netwerkstandaard, het beschrijft enkel de stappen die in elk protocol gezet worden om de communicatie in het netwerk te laten func­tioneren.

Elke laag heeft haar takenpakket

Om de gegevensoverdracht via een netwerk vlot te laten verlopen, moeten talloze taken worden volbracht en deze dienen betrouwbaar, veilig en integer te zijn. Daarom is het nuttig gebleken om de communicatie op te delen in lagen. Daarbij krijgt elke laag een exact gedefinieerd takenpakket. Een standaard dekt daarom meestal slechts een deel van het lagenmodel af.

Het model is ook hiërarchisch opgebouwd. Binnen elke laag zijn de taken die moeten worden volbracht en de eisen waaraan moet worden voldaan, duidelijk gedefinieerd. Zo kunnen fabrikanten, onafhankelijk van elkaar, standaarden ontwikkelen voor elke laag.

Omdat elke laag ook duidelijk afgescheiden is van de volgende laag, hebben wijzigingen aan een standaard binnen de ene laag geen invloed op processen die in andere lagen lopen. Dit maakt het invoeren van nieuwe standaarden makkelijker.

Toepassingsgeorienteerde en transportgeorienteerde lagen

Verder kunnen de lagen opgedeeld worden in twee types: toepassingsgeoriënteerde en transportgeoriënteerde lagen.

De 3 toepassingsgeoriënteerde lagen hebben betrekking op de communicatiewijze tussen het protocol en de bovenliggende besturing, zoals webbrowsers, apps of e-mailclients.

De transportgeoriënteerde lagen beschrijven dan weer hoe het transport van de data­pakketjes exact verloopt binnen een model. De vier lagen hier zijn respectievelijk de fysieke laag, de datalinklaag, de netwerklaag en de transportlaag.

Voorbeeld

Een voorbeeld uit de IT kan hierbij meer duidelijkheid brengen: in de onderste laag worden de bits van een datapakket omgezet in een fysiek signaal dat bij het overdrachtsmedium past. In de computerwereld zou dit bijvoorbeeld Bluetooth kunnen zijn.

In de datalinklaag worden de data toegewezen aan een fysieke locatie (het MAC-adres), terwijl het pakket ook gecontroleerd wordt op mogelijke fouten.

In laag 3 – de netwerklaag – worden de eindapparaten logisch geadresseerd door hun een uniek adres toe te kennen. IP is hier een bekende internetstandaard.

De transportlaag, ten slotte, fungeert als schakel tussen de toepassingsgeoriënteerde en de transport­georiënteerde lagen. Op dit niveau van het OSI-model wordt de logische end-to-endverbinding, het overdrachtskanaal, tussen de communicerende systemen gerealiseerd. Het datapakket wordt dus met andere woorden aan een bepaalde toepassing toegewezen.

In de praktijk

Eerst wordt het signaal gedecodeerd in de fysieke laag. Vervolgens worden MAC-adressen in laag 2 en routingprotocollen in laag 3 opgehaald. Aan de hand van deze informatie kan de controller beslissen hoe en waarheen het pakket moet worden doorgestuurd. Het datapakket kan dus weer worden ingekapseld en op basis van de ingewonnen informatie naar het volgende station op weg naar het doelsysteem worden gestuurd.

Meestal zijn meerdere gateways betrokken bij een gegevensoverdracht. Op al deze gateways vindt het beschreven proces (uitpakken en inkapselen) plaats tot het datapakket in de vorm van een fysiek signaal aankomt bij het eigenlijke doel.

Ook hier wordt het data­pakket uitgepakt doordat de lagen van het OSI-model van laag 1 tot en met laag 7 worden doorlopen.

Vervolgens kan het pakket bijvoorbeeld weergegeven worden als informatie voor de gebruiker.

Het klinkt voor velen als Chinees, maar dat is het eigenlijk niet. Het OSI-model helpt om protocollen te vergelijken met elkaar en zo te achterhalen hoe ze het best gekoppeld kunnen worden.