Sensornetzwerk: Virtuelles Sensornetzwerk mit Riot OS (Teil 1)

In meinen vorherigen Beiträgen zum Thema Sensornetzwerk bin ich auf die Theorie eines Sensornetzwerkes eingegangen und die damit verbundenen Technologien. In diesem Beitrag wird es nun etwas praktischer. Wir fangen an unser eigenes Sensornetzwerk aufzubauen, zunächst jedoch nur virtuell mit dem Simulationsboard „native“ von Riot OS.

Das Simulationsboard „native“

Der Einsatz des Simulationsbords „native“ hat den entscheidenden Vorteil, dass wir frei von unerwünschten Fehlern sind, welche eventuell durch defekte oder falsch konfigurierte Hardware auftreten können. Man kann sich zu 100% auf den eigentlichen Aufbau eines Sensornetzwerkes und der eingesetzten Software konzentrieren. Eine spätere Übertragung auf echte Hardware ist dann auch um einiges einfacher, da man Fehler der Sensornetzwerk-Software ausschließen kann.

Das Simulationsboard „native“ ist minimal gehalten und kann im Grunde auch nicht sehr viel. Für die diversen Beispielprogramme kann es jedoch meistens eingesetzt werden. Einzige Ausnahme ist, sobald externe Hardware benötigt wird.

Wie alle Board-Treiber befindet sich das native-Treiber im Ordner „boards“ im Riot-Hauptverzeichnis. Im Treiber selbst lässt sich wenig einstellen bzw. konfigurieren. Verwendet wird das Board durch eine Zeile im Makefile des eigenen Programms. Im später eingesetzten Beispielprogramm „gnrc_networking“ ist es die Zeile 5:

Makefile -  Board-Auswahl

Abbildung 1:  Makefile –  Board-Auswahl / Bildquelle: Daniel Waschto, generic.de AG

Wird beim Kompilieren kein Board mit angegeben, so wird das native-Board verwendet.

Das Beispielprogramm „gnrc_networking“

Das Beispielprogramm „gnrc_networking“ findet ihr im Examples-Ordner und bietet ein einfaches Programm mit Netzwerkunterstützung. Für die ersten Gehversuche mit einem Sensornetzwerk optimal.

Dieses Programm wird später auf die einzelnen Sensorknoten geladen bzw. auf das native-Board. Damit ihr auch versteht, was das Programm alles macht und wofür die einzelnen Module im Makefile sind, werde ich diese nun kurz erklären.

Makefile - Einbinden der Module

Abbildung 2: Makefile – Einbinden der Module / Bildquelle: Daniel Waschto, generic.de AG

Zeile 21 und 22 laden die benötigten Module für die Netzwerkkommunikation. Zeile 21 lädt dafür die default Netzwerk-Geräte des Boards und Zeile 22 initialisiert diese.

Zeile 24 und 25 sind für die IPv6-Kommunikation zuständig. Zeile 24 gibt an, wie der Sensorknoten arbeiten soll. In diesem Fall hat der Knoten auch eine Router-Funktion und kann somit Pakete weiterleiten, welche nicht an ihn selbst gerichtet sind. Genau das was wir in einem Sensornetzwerk haben möchte. Zeile 25 fügt die UDP-Unterstützung hinzu.

Zeile 27 und 28 sind für das Routing mit RPL. Sie fügen zum einen RPL hinzu und zum anderen wird RPL initialisiert.

Zeile 30 sorgt dafür, dass empfangene Pakete auf der Ausgabe erscheinen. Für die Fehlersuche optimal.

Zeile 32 fügt die „ICMPv6 echo request/reply“-Funktion hinzu. Diese Funktion sorgt dafür, dass sich die Knoten untereinander anpingen können und somit überprüfen, ob der andere Knoten erreichbar ist.

Die Zeilen 34 bis 39 sind unter anderem für die Shell notwendig und aktivieren die Statistik für die Netzwerkübertragung.

Weiterhin interessant sind die unteren Zeilen des Makefiles:

Makefile - Channel-Selection

Abbildung 3: Makefile – Channel-Selection / Bildquelle: Daniel Waschto, generic.de AG

Hier wird abhängig vom eingesetzten Funkchip der Kanal der Funkübertragung gewählt. Wird zum Beispiel mit 2,4 GHz gesendet, so wird der Kanal 26 benutzt. Einige werden sich jetzt wundern, da die WLAN-Frequenz 2,4 GHz doch nur 13 Kanäle besitzt. Genau, der Kanal 26 orientiert sich jedoch an der ZigBee-Aufteilung, welche die Kanäle 11-26 benutzt. Eine gute Erklärung der Koexistenz zwischen WLAN und Zigbee findet ihr auf der Seite von Metageek (https://www.metageek.com/training/resources/zigbee-wifi-coexistence.html).

Nach dem Makefile schauen wir uns nun die main.c an. Hier steht das eigentliche Programm mit der Main-Funktion.

Main-Funktion

Abbildung 4: Main-Funktion / Bildquelle: Daniel Waschto, generic.de AG

Die Main-Funktion ist jedoch einfach und entsprechend relativ langweilig. Der Grund ist, dass alle notwendigen Einstellungen und Konfigurationen bereits durch das Laden der Module erfolgt sind.

Das Beispielprogramm „gnrc_border_router“

Das zweite Beispielprogramm, welches für den Betrieb einen Sensorknoten benötigt wird, ist das Programm „gnrc_border_router“. Wie der Name schon sagt, stellt dieses Programm den Border Router zur Verfügung. Das hier verwendete Makefile sieht etwas anders aus.

Makefile - Netzwerkfunktion

Abbildung 5: Makefile – Netzwerkfunktion / Bildquelle: Daniel Waschto, generic.de AG

Zeile 27 bis 33 ist die Konfiguration der UART-Schnittstelle und ETHOS (Ethernet over Serial). Der führt dazu, dass die Serielle-Schnittstelle als Netzwerk-Gerät konfiguriert wird und somit eine Kommunikation mit dem Host-PC erlaubt. Ethos wird jedoch erst beim Einsatz echter Hardware verwendet.
Hier beim native-Board wird mit einer tap-Schnittstelle gearbeitet. Dazu später mehr.

Makefile - Einbinden der Module

Abbildung 6: Makefile – Einbinden der Module / Bildquelle: Daniel Waschto, generic.de AG

Auf den ersten Blick relativ ähnlich wie bei dem ersten Beispielprogramm. Hinzugekommen ist unter anderem das Modul in Zeile 64. Dies aktiviert die 6LoWPAN-Verwendung und den Border-Router selbst.

Des Weiteren wird in Zeile 66 die FIB-Tabelle (forwarding information base) aktiviert. Dies erlaubt die Ausgabe einer Tabelle mit den aktuellen Routing-Wegen über die Shell.

In Zeile 75 wird nun noch UHCPC aktiviert, der Klient für die IP-Vergabe.

Ausführen des Beispielprogramms „gnrc_networking“ mit dem native-Board

Bevor ich nun damit beginne ein virtuelles Sensornetzwerk aufzubauen, werden ich euch zunächst zeigen, wie ihr ein Programm für das native-Board kompiliert und ausführt und zwar mit zusätzlicher Netzwerkfunktionalität. Dazu nehme ich das Beispielprogramm „gnrc_networking“.

Das einfache Kompilieren und Ausführen habe ich euch bereits in einem meiner vorangegangenen Beiträge gezeigt (https://blog.generic.de/2018/10/23/sensornetzwerk-riot-os-betriebssystem-iot-teil2/).

Um dem virtuellen Sensorknoten noch Netzwerkfunktionalität mitzugeben, sind ein paar weitere Dinge zu erledigen. Wie oben schon erwähnt arbeitet das native-Board mit sogenannten tap-Schnittstellen. Eine tap-Schnittstelle arbeitet dann als virtuelles Netzwerkgerät und verbindet das native-Board mit dem Host-PC und ermöglich somit eine Kommunikation zwischen den beiden.

Mit folgenden Befehlen lässt sich die tap0-Schnittstelle erstellen und aktivieren:

Anschließend kann das gnrc-networking-Beispiel kompiliert und ausgeführt werden. Fragt man nun im „ifconfig“ die IP-Adresse des Knoten ab, so kann man sehen, dass ihm eine IPv6-Adresse zugewiesen wurde.

Anzeigen der IP-Adressen

Abbildung 7: Anzeigen der IP-Adressen / Bildquelle: Daniel Waschto, generic.de AG

Mit dieser lokal-Adresse lässt sich der virtuelle Sensorknoten nun vom Host-PC anpingen: ping6 fe80:0803:84ff:fe80:a32d%tap0

Ping zum virtuellen Node

Abbildung 8: Ping zum virtuellen Node / Bildquelle: Daniel Waschto, generic.de AG

Fazit

Im ersten Teil habe ich euch gezeigt, wie ihr einen virtuellen Sensorknoten mit Hilfe des Simulationsboards „native“ einrichtet und ihn mit Netzwerkfunktionen ausstattet. Im zweiten Teil werden wir dann mehrere virtuelle Sensorknoten zu einem virtuellen Sensornetzwerk zusammenschließen.