Smart Devices zur Bedienung, Programmierung, Diagnose und Konfiguration von Steuerungen und Automatisierungsanlagen sind in aller Munde. Durch die Vielseitigkeit der mobilen Endgeräte entstehen gegenüber traditionellen Bedienungsmechanismen tatsächlich Mehrwertdienste. Die Gerätehersteller stehen vor einer Herausforderung: Neben der herkömmlichen Geräte-Software müssen in Zukunft auch Apps bereitgestellt werden, die sowohl lokal als auch über das Internet mit ihren Geräten kommunizieren müssen. Außerdem läuft der Vertrieb der neu erstellten Apps für die Hersteller über völlig neue Vertriebswege – die App Stores. Und obwohl die beiden Produktgruppen unterschiedliche Vertriebswege nehmen, müssen sie beim Kunden – wo sie wieder zusammentreffen – reibungslos zusammenarbeiten. Um diese Probleme zu entschärfen, haben sich bisher zwei Lösungsansätze etabliert, welche jedoch beide mit mehr oder weniger großen Nachteilen behaftet sind.

Fat Clients und Thin Clients

Beim Fat-Client-Prinzip stellt der Gerätehersteller Netzwerkschnittstellen zu den Smart Devices auf seinen Geräten bereit. Die Apps auf den Smart Devices werden speziell und ausschließlich für die entsprechende Geräte erstellt und laufen direkt auf den Smart Devices ab. Daher auch der Begriff "native Apps". Da es für Smart Devices unterschiedliche, zueinander inkompatible Betriebssysteme gibt (Apple iOS, Google Android, Microsoft Windows Phone, Desktop Windows) und die Geräte unterschiedlichste Bildschirmgrößen haben können, muss der Gerätehersteller die nativen Apps für alle diese Systeme jeweils für unterschiedliche Bildschirmgrößen erstellen und über die vorgegebenen Vertriebskanäle in Umlauf bringen. Weitere Nachteile sind die kurzen Innovationszyklen bei Smart-Device-Betriebssystemversionen und dass die Geräte-Software beziehungsweise Firmware-Versionen immer mit den entsprechenden App-Software-Versionen kompatibel sein müssen.

Ein Vorteil der nativen Apps: Es gibt keinerlei Einschränkung bezüglich des Zugriffs auf die Smart-Device-Hardware-Funktionen wie Kamera, Buttons und alle Dienste des Smart Devices wie E-Mail, Internet-Gateway oder Empfang von Push-Nachrichten. Weitere Vorteile: Das einfacher erzielbare native Look-&Feel des Smart Devic und die höhere Reaktions- und Bearbeitungs-Performance, da alle Aktionen und die Regelschleife Bediener/App lokal auf dem Smart Device laufen. Im Zuge der stetig steigenden Prozessorrechenleistung und Netzwerkbandbreiten der Smart Devices relativiert sich dies jedoch zunehmend.

Während beim Fat Client die "Intelligenz" der App auf dem Smart Device implementiert ist, läuft beim Thin-Client-Prinzip eine Standard-Server-Software wie zum Beispiel ein Embedded-Webserver auf den Geräten. Diese Server-Software muss der Gerätehersteller beschaffen und in seine Geräte integrieren. Zusätzlich muss er intern eine Verbindung seiner bestehenden Geräte-Software zum Server schaffen. Neben reinen Daten ist es bei Webservern auch möglich, komplette Programme zum Beispiel als Java Applets beziehungsweise als JavaScript vom Thin Client auf das Smart Device herunterzuladen, welche dann auf dem Smart Device in der Standard-Browser-App ausgeführt werden. Dadurch ergibt sich der große Vorteil, dass der Gerätehersteller keine native App für das Smart Device erstellen und ausliefern muss. Das Gerät bringt seine Bedieneroberfläche und Bedienlogik komplett selbst mit. Der Webbrowser des Smart Device zeigt die Inhalte lediglich an und nimmt Bedienhandlungen entgegen.

Das Thin-Client-Prinzip ist jedoch ebenfalls mit einigen Nachteilen verbunden: Der Zugriff auf die meisten Hardware-Funktionen des Smart Devices oder die Verwendung von Smart-Device-Diensten ist aus Standard-Webbrowsern heraus nicht möglich. Hinzu kommen Unterschiede in den Browsern und Betriebssystemen der Smart Devices. Zusätzlich ist ein vollständig funktionsfähiger Webserver im Gerät notwendig, was Ressourcen-, Pflege- und schutzrechtliche Probleme aufwerfen könnte.

Ferngesteuerte generische App

Die rApp-Architektur: Die generische App fungiert als SOA-Dienste-Server.

© Acontis

Die Verwendung der Remote-App-Plattform (rApp) erlaubt es den Geräte­herstellern, die oben beschriebenen Nachteile zu vermeiden und sich wie bisher vollständig auf die Entwicklung ihrer Geräte-Software zu konzentrieren. Mit den Herausforderungen von App-Entwicklungen auf den Smart Devices und des App-Vertriebs über App-Stores brauchen sich die Gerätehersteller nicht zu beschäftigen.

Die Grundidee: Eine immer gleichbleibende, generische App auf den Smart Devices wird über SOA-Dienste (Service Oriented Architecture) durch die Geräte ferngesteuert. Alle Aktionen gehen dabei immer vom Gerät aus, die generische App tut nur das, was das Gerät ihr aufträgt. Insofern fungiert die generische App als SOA-Dienste-Server und das Gerät ist der SOA-Dienste-Client. Die generische App wird als ein Bestandteil von rApp vom Hersteller acontis in den unterschiedlichen App Stores kostenlos zum Download bereitgestellt. Apple, Android, Windows Phone, Windows Modern Apps, Windows IoT, Desktop Windows, Linux und später Apple OSX werden dabei unterstützt. Desktop-Windows, Linux und MacOS adressieren neben Smart Devices auch herkömm-liche PCs, Laptops und Server, welche somit auch als Terminal zum Benutzer dienen können. Aus diesem Grunde wird im Weiteren der allgemeinere Begriff "Terminal" anstatt "Smart Device" verwendet. Bei Bedarf sind die generischen Apps auch in Source Code erhältlich, sodass der Gerätehersteller gerade bei PCs, Laptops und Servern diese durch ­eigene Programme auf den Terminals ­erweitern kann, welche zum Beispiel zusätzlich zu Benutzerinteraktionen Daten­erfassungen und Auswertungen durchführen.

Für die Geräteseite stellt rApp eine Bibliothek mit definiertem API für gängige (Echtzeit-)Betriebssysteme, Prozessoren und zunächst für die Programmiersprachen C# und C++ zur Verfügung. Über diese Bibliothek, welche der Gerätehersteller in seine Geräte-Software einbindet, kann er alle Funktionen des Terminals wie Bildschirm-Ein- und Ausgabe, Hardware-Funktionen und Dienste quasi fernsteuern. Dabei stehen dem Geräteprogrammierer bei der Remote-Nutzung nahezu alle gängigen Dienste von Smart Devices zur Verfügung.  

Für die Bildschirmausgabe existieren wahlweise zwei Möglichkeiten: Zum einen wie beim Thin-Client-Prinzip die Bildschirm-Aus- und -Eingaben mittels HTML und JavaScript zu beschreiben. Die dabei erzeugten Dateien werden jedoch nicht durch einen Webserver wie üblich bereitgestellt, sondern durch die rApp-Bibliothek auf Veranlassung des Gerätes zum Terminal geschickt (Push-Verfahren), welches den sich daraus ergebenden Bildschirm anzeigt und die in JavaScript programmierte Logik ausführt. Dies hat den Vorteil, dass kein Webserver im Gerät notwendig ist und es auch keine patentrechtlichen Probleme gibt.

Eine zweite Möglichkeit für die Bildschirmausgabe besteht darin, den lokal auf dem Gerät erzeugten Bildschirminhalt mittels H.264 komprimierten Video-Stream an das Terminal zu senden, welches diesen Video-Stream dekomprimiert und auf dem Bildschirm darstellt. Dies ist auch der Weg, den Apple bei CarPlay beschritten hat, um die Bildschirminhalte eines iPhone auf der Konsole des Autos darzustellen. Der Vorteil von H.264 Streaming ist, dass die Bildschirmerzeugung auf dem Gerät mit herkömmlichen Methoden des Geräteherstellers erfolgen kann und nicht auf Web-Techniken umgestiegen werden muss. Das H.264 Streaming zur Bildschirmausgabe setzt allerdings Hardware-Unterstützung im Gerät voraus, wie sie alle modernen Intel- und ARM-Prozessoren mit eingebauter Grafik Processing Unit (GPU) aufweisen.

Vielfältige Kommunikation

rApp-Kommunikation: Es stehen drei unterschiedliche Kommunikationsartenzur Verfügung.

© Acontis

Damit das Gerät die Dienste des Terminals nutzen kann, muss es mit diesem in einer Kommunikationsbeziehung stehen. Hierfür gibt es drei Möglichkeiten, welche der Pprogrammierer wahlfrei nutzen kann. Alle Kommunikationsarten sind mittels aktuellen Security-Verfahren verschlüsselt und für den Benutzer völlig transparent. Das heißt, es stellt für ihn keinen Unterschied dar, ob er lokal (On Premise), über einen Inhouse-Server (Private Cloud), über das Internet (Public Cloud) oder einer Kombination von beiden (Hybrid Cloud) mit dem Gerät verbunden ist. Die erste Kommunikationsart ist "On Premise". Dies ist dann der Fall, wenn Gerät und Terminal im selben lokalen Netzwerk angemeldet oder über VPN verbunden sind. In diesem Falle ist kein weiterer Server notwendig: Gerät und Terminal kommunizieren Peer to Peer.

Die zweite Kommunikationsart "Lokales Relay" wird angewendet, wenn zwar das Terminal Zugang zum Internet hat, das Gerät aber nur über einen zentralen Server als Gateway mit dem Internet kommunizieren kann (Hybrid Cloud) oder wenn sich Gerät und Terminal in zwei unterschiedlichen Netzen befinden, an welche der lokale Server angeschlossen ist, zum Beispiel wenn Produktions- und Office-Netzwerk getrennt sind (Private Cloud, gestrichelt dargestellt). Auf dem lokalen Server muss dann die rApp-Relay-Software ablaufen, welche der dritte Bestandteil von rApp ist. rApp-Relay speichert lokal keine Daten, sondern reicht den Datenstrom vom Gerät zum Terminal in beide Richtungen einfach nur durch.

Die dritte Kommunikationsart kommt zum Einsatz, wenn sowohl Gerät als auch Terminal einen Internet-Zugang haben. "Internet-Zugang" bedeutet jedoch nicht, dass das Gerät oder das Terminal eine offizielle IP-Adresse haben und vollständig funktionsfähig am Internet angeschlossen sein müssen. Es reicht aus, wenn sowohl das Gerät als auch das Terminal lediglich Outbound-Zugriffe über Port 80 oder Port 443 machen können (HTTP Standard Web-Port beziehungsweise mit TLS (HTTPS) verschlüsselt). Dies ist beispielsweise bei Geräten hinter Firewalls oder in Privathaushalten mit DSL-Routern und NAT der Fall. Sowohl Gerät als auch Terminal nehmen lediglich über Port 80/443 Outbound-Kontakt mit dem rApp-Relay in der Public Cloud auf, welches dann den Datenkanal zwischen den beiden durchschaltet. Durch diesen, auf Outbound-only-Ports bestehendem Mechanismus wird ein hohes Maß an Sicherheit erreicht, da anders als bei Fat- und Thin-Client-Lösungen auf dem Gerät keine Inbound-Ports offen sind. Auch spielt es keine Rolle, hinter welchen Firewalls, DMZs und NAT-Netzen sich das Gerät befindet. In dem Moment, da es Port-80/443-Web-Browser-Zugriffe machen kann, können Gerät und Terminal über das rApp-Relay miteinander kommunizieren. Der Gerätehersteller kann die rApp-Relay-Software in einer eigenen Cloud betreiben oder den von Acontis hierzu angebotenen Service nutzen.

Identifikation

Damit ein Terminal mit einem Gerät Kontakt aufnehmen kann, muss es sich gegenüber diesem ausweisen. Eine rApp-Kommunikation zwischen Gerät und Terminal kann nur zustande kommen, wenn das Terminal Gerätename und Passwort des Gerätes kennt. Der Gerätename wird vom Hersteller vergeben und kann nicht verändert werden, da in ihm neben eindeutigen Geräteinformationen wie Seriennummer oder MAC-Adresse verschlüsselte Hinweise zur Kommunikationsaufnahme wie die Cloud-Adresse verborgen sind. Der Benutzer kann jedoch einen Friendly Name für das Gerät vergeben. Das Passwort wird als Default vom Hersteller vergeben und kann später vom Benutzer geändert werden.

Der generischen App muss in einem Pairing-Vorgang der Name und das Passwort des Gerätes bekannt gegeben werden. Dazu startet der Benutzer die generische App und gibt entweder manuell Name und Passwort des Gerätes ein oder scannt einen QR-Code oder einen NFC-Chip des Gerätes ein. Dabei kann er auch den Friendly Name festlegen und das Passwort ändern. Gerätename und Friendly Name werden in einer Geräteliste in der generischen App gespeichert, das Passwort nur optional auf Wunsch des Benutzers. Nach Auswahl eines der in der Liste gespeicherten Gerätes und Eingabe des Passworts – wenn es nicht auf dem Terminal gespeichert wurde – baut das Terminal eine rApp-Verbindung zum Gerät auf. Daraufhin übernimmt das Gerät die Kontrolle über das Terminal  und kann beispielsweise mittels eines ersten rApp-API-Aufrufes erfragen, um was für ein Terminal es sich handelt und welche Dienste es anbietet. Das Terminal gibt daraufhin alle möglichen Informationen über sich heraus, wie beispielsweise Hersteller, IMEI oder Bildschirmauflösung. Das Gerät kann dann immer noch entscheiden, ob und wie es mit diesem Terminal weiter kommunizieren will. Zum Beispiel in Form einer Warnung, wenn die Bildschirmgröße nicht optimal ist.

Bei On-Premise-Verbindungen gibt es zusätzlich die Möglichkeit, sich mittels einer Suchfunktion der generischen App alle lokal vorhandenen Geräte auf dem Terminal anzeigen zu lassen. Falls die gefundenen Geräte schon einmal gepairt wurden (Name und Passwort sind in der Geräteliste eingetragen), kann die rApp-Kommunikation sofort aufgenommen werden. Sind noch ungepairte Geräte vorhanden (Passwort ist dem Terminal nicht bekannt), erscheint ein entsprechender Hinweis. Nachdem der Benutzer das Passwort eingegeben hat, kann die rApp-Kommunikation ebenfalls beginnen.

Auch IT-ungeübte Personen können die Geräte einfach handhaben. So sieht der Benutzer nie URL-Adressen, IP-Adressen oder ähnliche IT-spezifische Fachbegriffe. Nach Eingabe von Gerätename und Password suchen sich sowohl Gerät als auch die generische App auf dem Terminal die passenden Verbindungswege selbstständig aus. Durch die geschickte Kombination und Erweiterung von Fat- und Thin-Client-Techniken durch SOA-Prinzipien ist mit rApp eine Entwicklerplattform entstanden, welche es den Geräteherstellern beziehungsweise deren Kunden ermöglicht, auf einfache und für sie gewohnte Weise ihre Produkte an den neuen Trends teilhaben zu lassen. Für entsprechende Vorhaben steht Acontis nicht nur als Plattformanbieter, sondern auch mit Beratung und Dienstleistung zur Verfügung.

Autor:
Stefan Zintgraf ist Geschäftsführer von Acontis.

Eigenschaften von SOA-Diensten

• SOA-Dienste sind in einem Verzeichnis (Repository) gelistet und entdeckbar (Discovery). Das Repository kann sich auch im Dienste-Server befinden. Die Summe aller zur Verfügung stehenden Dienste kann abgefragt werden.
• SOA-Dienste sind objektorientiert und haben daher eine wohldefinierte, veröffentlichte Netzwerkschnittstelle (Contract). Für die Nutzung reicht es aus, die Schnittstelle zu kennen. Kenntnisse über die Details der Implementierung sind nicht erforderlich.
• SOA-Dienste sind orts- und plattformunabhängig. Anbieter und Nutzer des Dienstes können in unterschiedlichen Programmiersprachen auf verschiedenen Plattformen und    Betriebssystemen realisiert sein.
• SOA-Dienste sind autonom, wieder verwendbar und verstecken die Implementierungs-Komplexität