atp edition Gamification in Kollaborationsnetzwerken (Vorschau)

zogen, um das visuelle Erscheinungsbild anzupassen
und die Interaktionsmodalität der gewählten Apps festzulegen.
Die nächste Funktion im Adaptionsschritt (Parametrize
Template) passt die in den App-Beschreibungen
hinterlegten Sparql Templates an die verwendete
Ontologie an, sodass die korrekten Begriffe, Typen und
Relationen in der Abfrage verwendet werden. Die Domain
Source Map enthält dabei die nötigen Informationen
zu den Sparql-Endpoints der Virtual Factory.
Das Resultat, ein Satz von Adapted Apps, wird an die
nächste Funktion weitergereicht (Create Navigation Design).
Unter Verwendung des in den App-Beschreibungen
definierten Interface und des Arbeitsflussmodells wird
ein Navigationsdesign erstellt, welches in die Managementkomponente
einfließt.
Die Ergebnisse der Orchestrierung, die adaptierten Apps
und die Managementkomponente (siehe Bild 2) werden auf
das mobile Gerät übertragen. Die Managementkomponente
ist zur Runtime für das Umschalten zwischen den orchestrierten
Apps (App Switcher), das Navigationsdesign
(Navigation Design), die Inter-App-Kommunikation (Message
Dash) und den Zugriff auf den gemeinsamen Informationsraum
(Linked Data Interface) zuständig. Ein
Linked Data Cache kann temporär auch das Arbeiten ohne
Netzwerkverbindung ermöglichen. Der App Switcher
nutzt das modellierte Navigationsdesign, um zwischen
den Apps umzuschalten, das Message Dash dient zum
Austausch zwischen Apps. Sie können dort Nachrichten
bestehend aus einem Zeitstempel, der App-ID und einem
einfachen Schlüssel-Wert-Paar hinterlegen. Typische
Nachrichten sind URIs, die zum nächsten Point of Interest
zeigen, generierte oder eingegebene Daten, die von der
nächsten App benötigt werden, oder andere in der App-
Beschreibung definierte Nachrichten. Alle Sparql Queries,
die eine App ausführen möchte, werden durch das Linked
Data Interface geleitet, welches sich beim passenden
Linked Data Endpoint authentifiziert, die gewünschten
Informationen abfragt oder aus dem lokalen Cache holt.
Das Orchestrierungskonzept lässt sich auf verschiedene
Arten implementieren. Dabei ist grundsätzlich zwischen
der Design-Time-Komponente und der Runtime-
Komponente zu unterscheiden. Erstere übernimmt den
eigentlichen Orchestrierungsprozess und wird außerhalb
des Mobilgerätes durchgeführt. Die Runtime-Komponente
dagegen managt unter anderem die Umschaltung
zwischen den Apps auf dem Gerät gemäß dem erstellten
Navigationsdesign und erlaubt die Inter-App-
Kommunikation (siehe Bild 2).
Die Design-Time-Komponente lässt sich beispielsweise
als Eclipse-Modul oder in Form von Build-Skripten
plattformunabhängig realisieren. Die Runtime-
Komponente muss dagegen plattformspezifisch für das
jeweilige Zielsystem implementiert werden. Primäre
Zielplattform für den vorgestellten Prototypen ist Android.
Dort bietet der Intent-Mechanismus eine gute
Grundlage für die Umsetzung des Orchestrierungskonzeptes
durch gesteuerten App-Wechsel. Für IOS
kann auf URL-Schemes zurückgegriffen werden und
unter Windows Phone auf die Launcher und Chooser,
wobei hier aufgrund des Sandbox-Konzeptes Einschränkungen
bestehen.
2. APP-ORCHESTRIERUNG IN DER INSTANDHALTUNG
Im folgenden Abschnitt wird ein Anwendungsbeispiel vorgestellt,
in dem das Konzept der App-Orchestrierung prototypisch
implementiert und anschließend evaluiert wurde.
2.1 Szenario
In dem gewählten Szenario aus der mobilen Instandhaltung
[11] ist ein externer Dienstleister für die Wartung
einer automatisierten chemischen Anlage zuständig. Ein
gemeinsamer Informationsraum auf Basis des Linked-
Data-Konzepts [5] enthält dabei die Planungsdaten, die
Wartungsinformationen und die aktuellen Betriebsparameter
der Anlage. Die von dem Dienstleister entsendeten
Wartungstechniker haben dadurch Zugriff auf Informationen,
die sie zur regelmäßigen Instandhaltung der Anlage
benötigen. Der Zugriff erfolgt mit mobilen Endgeräten,
sodass ein papierfreies Arbeiten ermöglicht wird.
2.2 Aufgaben- und Arbeitsflussmodelle
BILD 2: Runtime-Komponenten
der App-Orchestrierung
Eine Aufgabenanalyse mit Industriepartnern [12] hat
zu dem in Bild 3 dargestellten hierarchischen Aufgabenmodell
geführt. Das Ziel – Anlage warten – besteht
dabei aus zwei Aktivitäten und einem Teilziel, welches
sich wieder in fünf Aktivitäten aufteilt. Dabei werden
nur die tatsächlichen Arbeiten im Feld beachtet und
vorbereitende sowie nachfolgende Tätigkeiten vernachlässigt.
Die dazugehörigen Handlungspläne sind in Tabelle 1
dargestellt. Nach Plan 0 muss sich der Wartungstechniker
erst in der Anlage anmelden, bevor er die spezifizierten
Geräte warten und ein intelligentes Durchflussmessgerät
parametrieren darf. Plan 2 beschreibt den notwendigen
atp edition
3 / 2013
37