Apps für Geräte
 
Mit den Smart Devices ziehen auch die Apps in die Industriewelt ein. Dies kann enorme Investitionen in neuartige Entwicklungswerkzeuge und Vertriebswege von Cloud- und App-Entwicklungen mit sich bringen. Mit rApp ist es Geräteherstellern oder -Anwendern möglich, Apps nicht auf den Smart Devices, sondern auf ihren Geräten beziehungsweise Maschinen – sozusagen "remote" – zu erstellen und in Verkehr zu bringen.

Smart Devices zur Bedienung, Programmierung, Diagnose und Konfiguration von Steuerungen, Automatisierungsanlagen aber auch alltäglichen Haushaltsgeräten 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 - Vor- und Nachteile

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. Diese Vertriebskanäle, so genannte App Stores, werden oft sehr rigoros gehandhabt, wobei sich der Gerätehersteller den Vorgaben der App Store Betreiber unterwerfen muss. Auch kann der App Store Betreiber den Vertrieb der App ganz ablehnen. 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. Zusätzlich stellt sich noch das Problem, dass die Geräte- Soft bzw. Firmware-Versionen immer mit den entsprechenden App-Software-Versionen kompatibel sein müssen. Dies ist schwer zu gewährleisten, wenn der Gerätehersteller viele unterschiedlichen Geräte und Gerätetypen im Feld hat, da die Geräte auf anderen Vertriebskanälen bereitgestellt werden als die Apps und die Geräte viele Jahre in Betrieb sein können.

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.

Fat- und Thin Clients - Security

In beiden Fällen, welche natürlich auch gemischt werden können, geht die aktive Rolle jeweils von den Clients auf den Smart Devices aus. Die Geräte sind immer in der passiven (Server-) Rolle und warten, bis sich ein Smart Device mit ihnen verbindet. Durch diese passive Rolle werden die Geräte leichter angreifbar, wodurch ein Sicherheitsproblem bzgl. der IT-Security entsteht. Wurde der initiale Sicherheitsschutz einmal überwunden, kann der Angreifer das Gerät komplett kontrollieren und missbrauchen. Durch den Einsatz von Standard-Server-Software beim Thin Client Prinzip, welche meist aus Open Source Projekten stammen, sind deren Mechanismen weitestgehend bekannt und daher für Angreifer leicht zu verstehen.



 
(C) 2014 - Alle Rechte vorbehalten