Warum überhaupt SignalK?
In einem Wohnmobil oder Caravan – oder erst recht auf einer großen Yacht – gibt es viele Größen, die Überwacht werden wollen: Vom Füllstand von Frischwasser- und Abwassertank über Ladestand der Batterie und Leistung der Photovoltaik, Einstellung der Heizung/Klimaanlage und für die Navigations relevante Informationen wie Position, Wetter oder Wassertiefe bis hin zu mehreren Antriebsmotoren oder Generatoren auf größeren Yachten. Dazu kommt das Schalten von elektrischen Verbrauchern wie einfaches Licht, aber auch Pumpen, Ladegeräte oder Unterhaltungs- und Navigationsgeräte. Bei klassischen Systemen werden dafür einzelne Sensoren und Schalter mit Anzeigen und Verbrauchern verkabelt – was zu einer starren Verkabelung, Verknüpfung und Funktionalität führt.
Deswegen existieren inzwischen auf dem CAN-Bus basierende Alternativen wie z.B. NMEA2000, Mastervolts Masterbus, Raymarines SeaTalk NG, oder im Caravan-Bereich der CI-Bus. Diese haben den Vorteil, dass Sensorsignale sich an eine Vielzahl Abnehmer verteilen lassen und sich z.B. auch „smarte Schalter“ realisieren lassen. Bei diesen gibt es keine direkte Verbindung zwischen Schalter und Verbraucher. Statt dessen wird der Schalter in Software eingelesen, über diese der/die zu schaltenden Verbraucher definiert und über einen „smart Switch“ dann der eigentliche Schaltvorgang realisiert. Nachteil ist, dass die Bus-Definitionen nicht öffentlich bzw. sogar proprietär sind. Zudem ist der CAN-Bus zwar ressourcenschonend zu Verarbeiten und günstig, allerdings ist das codieren/decodieren der Daten in „Bitfelder“ fehlerträchtig und aufwändig.
Auf der Suche nach möglichen Lösungen sind wir auf SignalK gestossen, welches zum einen ein offener Standard ist und zum anderen auf modernen und über das Web weit verbreiteten Techniken wie TCP/IP, JSON, http und weiteren basiert. Neben dem Vorteil der Offenheit sind die verwendeten Techniken im Bereich der IT/Elektronik weit verbreitet, es existieren viele SW-Pakete, die sich fast „Plug and Play“ verwenden lassen und die verwendeten Formate sind im Debugging-Fall relativ leicht für Menschen lesbar. Nachteil ist, dass sie wenig ressourcenschonend sind, was einer Verwendung auf Microcontrollern entgegen stehen könnte. Das zu überprüfen und mögliche Lösungsansätze zu entwickeln, ist das Ziel dieses Projekts.
Entwicklungs-System
Die ersten Versuche werden wir mit Laboraufbauten basierend auf existierenden Komponenten wie z.B. dem Raspberry Pi, Arduino-Boards, ESP8266/ESP32 sowie dazu gehörenden Shields aus der Maker-Szene aufbauen um die Software zu entwickeln und zu testen. Der Laboraufbau soll dabei einen auf einer Yacht oder in einem großen Caravan möglichen Aufbau wiederspiegeln. Einen Überblick über das Entwicklungssystem zeigt die Abbildung. Die Bestandteile gehen wir jetzt kurz durch.
Eine SignalK-Installation kann einen zentralen Server enthalten, der neben der Konsolidierung des Datenmodells noch weitere Aufgaben übernehmen kann. Das SignalK-Projekt stelle einen auf node.js basierende Implementierung eines Servers zur Verfügung, die wir hier auf dem Raspberry Pi verwenden. Neben SignalK-bezogenen Aufgaben kann der Server noch weitere übernehmen, z.B. einen NTP-Server (Zeitserver) oder WLAN-Access-Point zur Verfügung stellen. Für diese Funktionalität wird ein vergleichsweise (mit Microcontrollern) leistungsfähiger Rechner mit einem Server-artigen Betriebssystem verwendet, weswegen wir hierfür einen Raspberry PI mit Raspberry PI OS (einer auf debian basierenden Linux-Distribution) verwenden werden. Im ersten Schritt richten wird den Raspberry PI ein.
Um mehrere Geräte per Ethernet zu verbinden, brauchen wir einen Switch. Diese Rolle übernimmt hier ein Router, im konkreten Fall eine Fritz Box. Neben dem Switch übernimmt die Fritzbox noch weitere Aufgaben: Sie dient als DHCP-Server (automatischer Zuteilung von IP-Addressen), als DNS-Server (Namensauflösung), als NTP-Server (Zeitserver), stellt die Verbindung zum Internet und ein WLAN zur Verfügung. Im weiteren Verlauf können wir alle Services der Fritzbox auf den Raspberry PI umziehen und sie dann durch ein einfaches Switch ersetzen (ohne Internetzugriff), was eher einer typischen Installation entspricht.
Da die Datenrate oder das grundsätzliche Zustandekommen einer WLAN-Verbindung leicht gestört wird (z.B. durch niedrige Signalqualität oder ein stark belegtes Frequenzband) werden wir bei Eingängen, die eine hohe Verfügbarkeit benötigen (wie Navigations- oder Motordaten) eine Ethernet-Verbindung bevorzugen. Im Testaufbau verwenden wir hier einen Arduino Uno/Mega mit einem Ethernet-Shield. Ein Arduino Uno/Mega stellt zudem eine große Anzahl an analogen Ein- und Ausgängen sowie SPI- und I2C-Schnittstellen, mit denen sich eine Vielzahl von Sensoren und Aktoren ansteuern lässt. Nachteil eines Arduino ist die geringe Rechenleistung und nur wenig FLASH/SRAM – ob wir ihn trotzdem verwenden können, soll ein erster Prototyp herausfinden.
Ein ESP8266 oder ESP32 ist mit WLAN und deutlich mehr Rechenleistung, FLASH und SRAM ausgestattet. Dies ermöglicht die Ansteuerung auch graphischer Displays und ist beim Empfang und der Auswertung von SignalK-Daten auch ein Vorteil. Dafür verfügt er nur über wenige analoge Ein- und Ausgänge. Wir werden ihn hier also zunächst für den Empfang von SingalK-Botschaften und die Ansteuerung eines Displays verwenden. Obwohl er üblicherweise mit WLAN verwendet wird, verfügt zumindest der ESP32 auch über einen Ethernet MAC, der auf wenigen Boards auch für das Bereitstellen eines Ethernet-Ports. verwendet wird.
Zuletzt brauchen wir noch einen Rechner für Entwicklung und Tests. Hier wird ein PC mit Ubuntu 10.0 verwendet, ein Windows-PC oder Mac sollte es aber genau so tun. Er ist per Ethernet oder WLAN mit der Fritzbox verbunden. Das WLAN lässt sich aber auch testweise mit dem vom Raspberry PI bereit gestellten WLAN-AP verbinden.