Hier geht es darum wie die externe Steuerungseinheit mit dem Bordcomputer spricht. In den Anforderungen steht, dass ein Start- und ein Stoppsignal übermittelt werden muss. Jedoch kann es auch Sinn machen, dass der Bordcomputer komplexe Rechenaufgaben an die Steuerungseinheit übergibt. Ich kann mir das vorstellen, wenn es um Bildverarbeitung oder wenn es um die Berechnung geht, wie die Maschine ausgerichtet werden muss.

Schlussendlich geht es nur darum Daten auszutauschen. Dafür gibt es bewährte Technologien wie Bluetooth und WLAN. Es macht keinen Sinn eigene Protokolle zu entwickeln. Der Aufwand wäre zu gross und wir erzielen dadurch auch keinen Benefit.

Dies setzt jedoch voraus, dass die Komponenten diese Protokolle beherrschen. Die externe Steuereinheit darf "alles" sein. Moderne Smartphones unterstützen sowohl WLAN wie auch Bluetooth. Nicht jedes Notebook unterstützt Bluetooth. Und mit der Option, dass die Steuerungseinheit eventuell Rechenpower braucht, wird es eventuell mehr Sinn machen mit Notebooks zu arbeiten.

Der Bordcomputer ist noch ein Fragezeichen. Momentan tendiert man zu einem Raspberry PI, welches sowohl WLAN wie auch Bluetooth unterstützen kann.

Aus Java und Python kann man relativ einfach Bluetooth aufrufen. Jedoch wird es relativ schwierig, wenn man über Bluetooth Webservices aufrufen will (nicht unbedingt förderlich für eine Service Orienterte Architektur). Möglich ist es, aber aufwändig. Wenn ich den Vergleich zum TCP/IP Stack mache, dann nimmt mir TCP/IP vieles schon ab. Ich muss mich um einiges nicht kümmern.

TCP/IP Stack steht uns hier zur Verfügung. Die geballte Power der Netzwerkkommunikation. Service-Orienterte Architektur ist einfach zu gestalten.

Das wäre die gängige Variante. Ein Netz zur Verfügung stellen (wir besitzen einen Access Point). Die HSLU verfügt sonst auch über ein Netz, aber sicher ist sicher.

Anscheinend gibt es noch eine andere Methode um zwei Partner über WLAN kommunizieren zu lassen. Gemäss Ervin (Ad-hoc-Netz Vor- und Nachteile) ist das aber kompliziert einzurichten. Dieser Ansatz wird nicht weiterverfolgt. Wir müssen uns das Leben nicht zunehmend schwerer gestalten, wenn wir ein eigenes Netz in Betrieb nehmen können.

Es ist für den Einsatz wartungsfreier Funkschalter und Funksensoren mit beschränkter Energieversorgung (z. B. durch Batterie) in schwer zugänglichen Bereichen vorgesehen, wo der Austausch von Batterien nur mit großem Aufwand möglich ist. Die genormten Funktionen schließen auch eine grobe Pegelmessung (RSSI) ein, welche den Netzaufbau unterstützt. (http://de.wikipedia.org/wiki/ZigBee)

Zigbee ist optimiert für Low Power Sensoren. Das heisst auch, dass die Datenkommunikation minimal ist. Sie ist nicht dafür ausgelegt um grosse Datenmengen zu übertragen. Wir werden diese mit grosser Wahrscheinlichkeit auch nicht haben. Jedoch kann es sein, dass wir ein Bild von einem Punkt an einen anderen senden. Dafür braucht man auch spezielle Hardware. Und wir besitzen nicht über ein Notebook oder ein Mobile Phone welches das out of the box unterstützt. Bluetooth und WLAN haben wir bereits. Daher macht das keinen Sinn.

Zigbee scheidet definitv aus. Ich würde die Kommunikation über WLAN bevorzugen, da können wir einfach Architekturen entwickeln. Schlussendlich hängt es von den einzelnen Komponenten ab, was diese Unterstützen. Der Raspberry PI unterstützt zurzeit WLAN. Ein Bluetooth Modul müsste zusätzlich noch gekauft werden. Eventuell verwenden wir ja auch gar nicht Raspberry PI. Auf der Seite der Notebooks unterstützt jedes WLAN. Auch die Mobiles unterstützen alle WLAN. Bluetooth auf dem Notebook ist nicht überall vorhanden. Auf dem Handy in der Regel schon. Daher - WLAN beverzugen, aber Bluetooth im Auge behalten.