Mijn pad naar het IoT (2): Protocolstacks
In de vorige aflevering noemde ik al de veelheid aan toepasbare communicatieprotocollen; kijk eerst eens naar het grafische overzicht van verschillende protocollagen. IoT-knooppunten communiceren met elkaar via IP; daar hoort ook een IP-adres bij. (Subknooppunten met sensoren/actuatoren kunnen via ZigBee, Bluetooth e.d. communiceren met zo’n knooppunt, maar dat laten we voor dit moment buiten beschouwing.) Gelukkig zijn er ruim voldoende IP-adressen beschikbaar: Bij de moderne IP-variant IPv6 is het adresveld 128 bits lang, dat geeft een aantal van ca. 340.000.000.000.000.000.000.000.000.000.000.000.000 adressen.

Onder de netwerklaag met IP vinden we de fysieke laag met de gebruikelijke communicatiekanalen voor IP-pakketten; dat zijn bijvoorbeeld WLAN (Wifi), Ethernet en de GSM-netwerken. Daarnaast is er ook de 6LoWPAN-specificatie, die een interface vormt voor de low power-standaard voor draadloze communicatie IEEE 802.15.4, waar bijvoorbeeld ook ZigBee mee werkt. Een voordeel ten opzichte van de traditionele Internet-communicatiekanalen is het bijzonder geringe energieverbruik; juist voor batterijgevoede of energy-harvesting-sensorknooppunten is dat heel belangrijk.

Voor ons als ontwikkelaars zijn de protocollen boven IP, in de applicatielaag, interessanter. Het mooie van protocolstacks is dat we ons geen zorgen hoeven te maken over de onderliggende lagen. Het enige dat telt is dat we IP-pakketten kunnen overdragen. Als we moeten werken met een kleine microcontroller kunnen we bijvoorbeeld gebruik maken van een netwerkmodule met voorgeïnstalleerde standaard firmware; voor grotere controllers/processors, zoals bijvoorbeeld de Raspberry Pi, zijn  besturingssystemen beschikbaar, waarin dat soort functies zijn ingebouwd. Dat zijn heel volwassen systemen, want ze zijn al in het verleden ontwikkeld voor het klassieke Internet.

Twee protocollen, die werken op basis van IP, zijn ook al lang gevestigd: TCP en UDP. Via TCP /IP halen we websites en de meeste andere data in huis, omdat webservers en clients (browsers) ermee werken. Bij TCP -communicatie gaat het altijd om een verbinding tussen twee deelnemers, die eindpunten of sockets worden genoemd. Bij elk socket horen een IP-adres en een poortnummer. Een uitgekiend systeem van bevestigingen garandeert, dat de verzonden IP-pakketten ook aankomen. UDP daarentegen is een onbeveiligd protocol, dat bijvoorbeeld heel geschikt is voor de overdracht van audio-informatie.

Over het algemeen hoeven ontwikkelaars zich niet druk te maken over de details van TCP en UDP. Voor alle gangbare programmeertalen zijn er (gratis) bibliotheken beschikbaar voor het programmeren van sockets. Die maken het mogelijk om zonder grote moeilijkheden al te beginnen aan een werkende toepassing voor datalogging of besturing via Internet. Een zelfbedacht toepassingsprotocol voor ons project kan heel eenvoudig zijn. Als er maar twee deelnemers zijn, dan hoeven we in het eenvoudigste geval alleen maar „ON“ en „OFF“, of een getal, via een TCP /IP-bericht te verzenden via het netwerk. Twee voorbeelden van zulke projecten zijn te vinden in het komende nummer van Elektor: In “WLAN voor microcontrollers” besturen we een kaart met LED’s met een smartphone en in “Windows op de Raspberry Pi (2)” geeft een 7-segment-display cijfers weer, die via het netwerk worden gestuurd.

Bij domotica en dergelijke toepassingen zijn er meestal veel meer deelnemers; er kan bijvoorbeeld een groot aantal sensoren zijn die data leveren voor weergave op verschillende computersystemen. Maar wie moet daarbij welke data ontvangen? We moeten ook nadenken over de vraag, hoe we de individuele sensoren en andere knooppunten moeten adresseren, zonder te hoeven werken met een lijst van lange IP-adressen. Ten behoeve van energiebesparing en robuustheid van het systeem, zou het nog wenselijk zijn om data ook op te kunnen vragen als de sensoren niet online zijn. Gelukkig bestaan er protocollen die bovenop TCP en UDP werken, die daar oplossingen voor bieden.
Meer daarover in het volgende deel!