Category

Mit einem WebSocket lassen sich asynchron Daten austauschen, ohne dass eine explizite Anfrage des Clients nötig ist. Wieso kann dies für Embedded Systeme interessant sein?

Embedded Systeme müssen häufig auch nach der Herstellung konfigurierbar sein. Um die Konfiguration zu ändern oder aktuelle Zustandsinformationen auszulesen wird oft ein proprietäres Protokoll entwickelt. Entsprechende Tools mit GUI erleichtern Kunden die Inbetriebnahme des Systems. Um die Flexibilität zu erhöhen werden diese Tools für verschiedene Plattformen zur Verfügung gestellt. Dadurch werden die Entwicklung und das Testing jedoch aufwändiger. Die Tools müssen unterhalten werden, denn wird in späteren Versionen die Hard- oder Software verändert, müssen die Tools mit neuen und älteren Geräten funktionieren.

Web-App auf Embedded-Geräten hosten

Die Konfiguration der Embedded-Geräte kann alternativ per Web-Applikation angeboten werden. Nicht zuletzt durch Trends wie Internet Of Things (IoT) oder Industrie 4.0 werden immer mehr Geräte mit Netzwerkschnittstellen ausgestattet. In diesen Fällen ist keine zusätzliche Hardware nötig. Zusätzlich kann ein Webservice auf das Gerät zugeschnitten werden. Das bedeutet, dass die Web-App exakt auf die Version des Geräts abgestimmt werden kann. Wenn sämtliche Daten für Frontend etc. auf dem Gerät gespeichert werden, muss das Gerät auch nicht mit dem Internet verbunden sein. Es reicht eine direkte Verbindung zwischen Server und Client. Der Client kann dabei ein PC, Smartphone, Tablet oder sonst ein Gerät mit Browser sein. Die Plattformabhängigkeit ist also deutlich reduziert und es ist keine Installation von zusätzlicher Software auf dem Client nötig.

Im Gegensatz zu klassischen Webservices ist es aber in diesem Falle meist so, dass der Client mehr Rechenleistung besitzt als der Server. Das Ziel ist also, möglichst wenig Last auf dem Server zu verursachen und den Grossteil der Logik auf den Client auszulagern. Entsprechend ist es sinnvoll, die Website nicht dynamisch auf dem Server zu erzeugen sondern nur statische Dateien zur Verfügung zu stellen. Der Client soll gezielt die dynamischen Inhalte abrufen und einen wesentlichen Teil der Businesslogik bearbeiten.

Die Informationen werden typischerweise in kleinen HTTP-Paketen asynchron vom Server abgerufen. Technologien wie PHP oder NodeJS erlauben dies, sind aber aufgrund der hohen Systemanforderungen nicht immer für Embedded-Geräte geeignet. Ausserdem ergeben sich dadurch weitere Probleme:

1. Je nach Systemlast und Technologie ist mit beachtlicher Latenz zu rechnen, auch für die Abfrage von einfachen Messwerten.
2. Durch die Verwendung von HTTP-Requests muss für jeden Datenaustausch ein Header usw. mitgeschickt werden.
3. Push-Nachrichten vom Server sind umständlich zu realisieren. Wenn der Client die Inhalte regelmässig abruft (polling), wird oft unnötiger Traffic verursacht. Somit erhöht sich auch die Belastung des Servers.

Web-App mit WebSocket

Eine Lösung für diese Probleme können WebSockets sein. Es handelt sich dabei um eine asynchrone bidirektionale Verbindung. Diese kann beispielsweise die Ein- und Ausgabe eines Programms im Netzwerk zur Verfügung stellen, wie auf der Linux-Konsole. Eine Verbindung kann für mehrere Anfragen bestehen bleiben. Dies reduziert den Overhead pro Anfrage stark.

Es ist also entscheidend, dass über ein Programm auf alle dynamischen Daten für die Web-App schnell und ressourcenschonend zugegriffen werden kann. Entsprechend sollte man dies früh in der Architektur der Software berücksichtigen.

Einschränkungen

Eine Web-App kann in vielen Fällen GUI-Tools ersetzen. Dennoch kann je nach Anwendung zusätzlich ein proprietäres Protokoll für die Kommunikation von Nöten sein. Denn diese Art der Steuerung lässt sich einfacher in bestehende Systeme einbinden und automatisieren.

Die Web-App ist Bestandteil der Firmware. Deshalb kann das Frontend ausschliesslich per Software Update aktualisiert werden.

Ein sehr wichtiger Aspekt ist die Sicherheit. Dieses Thema wird jedoch nicht in diesem Blogeintrags vertieft. WebSockets bieten keine integrierten Methoden für die Authentifizierung. Eine Verschlüsselung per SSL ist möglich. Doch dies verhindert nicht das Ausführen von Befehlen durch unautorisierte Benutzer. Es lassen sich aber bekannte Verfahren von HTML5 auf WebSockets anwenden. Ein Security- und Safety-Konzept ist unabdingbar, bevor die Web-App produktiv eingesetzt wird.

Verwandte Konzepte

Man kann die statischen Teile des Frontends auch auf einem externen Gerät mit Display speichern. Dieses Gerät kann eine externe Bedieneinheit sein. Die dynamischen Inhalte werden nach wie vor über WebSockets gelesen. Dabei sind keine Kenntnisse über proprietäre GUI-Framework wie Qt nötig. Je nach Frontend ist aber eine entsprechende Grafikleistung auf der Bedieneinheit notwendig.

Die Webapplikation kann auch auf einem externen Server gehostet werden. In diesem Fall werden ausschliesslich die dynamischen Inhalte vom Embedded System bezogen. So kann die Webapplikation auch unabhängig von der Gerätefirmware aktualisiert werden. Die Last auf dem Embedded-Gerät ist somit reduziert, da es keine statischen Dateien zur Verfügung stellen muss. Allerdings muss bei diesem Ansatz der Client mit dem Internet verbunden sein.

Starthilfe für Linux Systeme

Es gibt eine Vielzahl von verfügbaren Implementationen von WebSockets. Ein interessanter Einstieg kann hier websocketd sein. Binaries für Linux / ARM machen die Installation einfach. Mit folgender Zeile auf dem Terminal wird die Ein- und Ausgabe des Programms count.sh auf Port 8080 per WebSocket zur Verfügung gestellt:

websocketd --port=8080 ./count.sh

Websocketd bietet auch eine praktische Konsole. Es muss keine eigene Web-App vorhanden sein, um die Ein- und Ausgabe per WebSocket zu testen. Websocketd integriert ebenfalls einen statischen Webserver, beispielsweise für JavaScript- oder HTML-Dateien. Unter Umständen ist also keine separate Server-Software nötig. Ebenso werden die wichtigsten Sicherheitsfunktionen (SSL, Origin Checking) unterstützt. All diese Funktionen sind in einem einzigen Binary enthalten, welches rund 6 MB gross ist.

Für die client-seitige Entwicklung der Web-App sind Frameworks wie Angular empfehlenswert. WebSockets können dort einfach eingebunden werden. Für das Design ist Bootstrap oder Material weit verbreitet. Zu beachten ist aber, dass eine Angular-App oft 1 MB gross wird. Alternativen wie ReactJS versprechen kleinere Web-Apps.

Beim erstellen von WebApp kann man schnell an die Grenzen von JavaScript stossen, da der Browser nur einen limitierten Zugriff auf das Smartphone bietet. PhoneGap bietet dazu die Schnittstelle um auf das Gerät zuzugreifen.

PhoneGap stellt folgende Funktionen zur Verfügung:

Dies mag für manche App ausreichen, sobald man allerdings eine native Funktion benötigt, wird ein direkter Zugriff benötigt. PhoneGap bietet eine Lösung über sogenannte „Plugins“ an.

Diese Plugins werden immer mit demselben JavaScript-Code über die PhoneGap Schnittstelle aufgerufen. Das sieht dann in JavaScript so aus:
cordova.exec(pluginSuccess, pluginFail, "TestPlugin", "testAction", ["test"]);

Ich kann hier anmerken das PhoneGap und Cordova das selbe ist.

Der exec Funktion werden zwei Callbackfunktionen, der Plugin Name, die gewünschte Action und ein Array von Parametern übergeben, welche anschliessend der Action im Plugin geliefert werden.

Für jede Zielplattform muss das Plugin dann in der jeweiligen Programmiersprache implementiert werden. In den Pluginklassen kann dann grundsätzlich alles gemacht werden, was auch in der Nativeentwicklung möglich wäre. Sobald die Ausfühung des Plugins fertig ist, kann man den Programmlauf zurück zu den Callbackfunktionen im JavaScript senden. Eine solche Plugin Action könnte in Android wie folgt aussehen:
private void testAction(String message, CallbackContext callbackContext) {
  if (message != null && message.length() > 0) {
    callbackContext.success(message);
  } else {
    callbackContext.error("Expected one non-empty string argument.");
  }
}


Windows Phone 7/8:

public void testAction(string message) {
 if (message != null && message.Length > 0) {
     DispatchCommandResult(new PluginResult(PluginResult.Status.OK, message));
 }
 else {
     DispatchCommandResult(new PluginResult(PluginResult.Status.ERROR, "Error!"));
 }
}

iOS
- (void)testAction:(CDVInvokedUrlCommand*)command
{
CDVPluginResult* pluginResult = nil;
NSString* myarg = [command.arguments objectAtIndex:0];
if (myarg != nil) {
pluginResult = [CDVPluginResult resultWithStatus:CDVCommandStatus_OK];
} else {
pluginResult = [CDVPluginResult resultWithStatus:CDVCommandStatus_ERROR messageAsString:@"Arg was null"];
}
[self.commandDelegate sendPluginResult:pluginResult callbackId:command.callbackId]; }

Die fett markierten Funktionen sind hierbei die Aufrufe der Callbackfunktionen. Das Resultat kann somit zurück zum JavaScript gegeben werden, wo dieses verarbeitet wird. Beispiel von JavaScript Callbackfunktionen:

function pluginSuccess(message) {
// Success callback
 alert("Message:"+message);
}

function pluginFail(message) {
// Error callback
 alert("Error:" + message);
}


Unten sind die Ausgaben auf verschiedenen Geräten sichtbar:

(Windows Phone, Android, iOS)