Im Projekt APPsist wird eine Architektur fu¨r Assistenz- und Wissensdienste zur Unterstu¨tzung der Bescha¨ftigten in der Industrie 4.0 entwickelt, bestehend aus Basisdiensten und intelligent-adaptiven Diensten, die angepasst an den Kontext und den Benutzer die Unterstu¨tzung realisieren. Das Projekt befindet sich nahe dem Ende der Laufzeit, und dieser Beitrag beschreibt das finale System und gibt eine kritische Betrachtung der zu Projektbeginn getroffenen technischen Entscheidungen.
drei eingebundene Unternehmen und eine Lernfabrik. Die unterstu¨tzten Arbeitsprozesse umfassen Inbetriebnahme von Anlagen, Fehlerbehebung sowie Wartung und Instandhaltung [Ul16]. Dieser Artikel aktualisiert den ersten Bericht zum Projektstand [Ul15] und dient zur Beschreibung neuer Funktionalita¨ten, gesammelter Erfahrungen sowie der kritischen Betrachtung getroffener Entscheidungen. 2
Das Potential von Diensten, Bildungsprozesse am Arbeitsplatz zu unterstu¨tzen, wird aktuell aus einer Vielzahl von Perspektiven erforscht. So wurden bisher prima¨r Web 2.0 Technologien fu¨r das Themenfeld Wissensvermittlung verwendet, z.B. Erstellung und Austausch von Inhalten in der Instandhaltung (BMBF Projekt DiLi) und Unterstu¨tzung von Mechanikern bei Wartung und Reparatur (BMBF Projekt MOLEM). Ebenfalls gibt es Untersuchungen zur Verknu¨pfung von automatischer Kontexterfassung und sozialen Netzwerken fu¨r das betriebliche Wissensmanagement (BMBF Projekt AmbiWise) und fu¨r den Transfer von Erfahrungswissen (BMBF Projekt PLUTO, [BR15]). Eine Reihe von EU Projekten widmen sich der Frage, wie Daten aus fabrikweiten Sensornetzwerke verwendet werden ko¨nnen um die Informationsflu¨sse so zu steuern, dass kognitive U¨berlastung der Mitarbeiter vermieden wird (EU FP7 Projekt Sense& React), oder wie diese auf modernen Endgera¨ten dargestellt werden ko¨nnen, um Arbeitszufriedenheit zu erho¨hen (EU H2020 Projekt SatisFactory). Der Anspruch, eine allgemein einsetzbare Architektur fu¨r Assistenz- und Wissensdienste zu entwickeln, ist nach wie vor ein Alleinstellungsmerkmal von APPsist. Zu nennen ist im Bereich intelligent-adaptiver Systeme noch DigiLernPro [Fr15], in dem Bescha¨ftigte unterstu¨tzt durch KI Arbeitsprozesse aufnehmen. 3 3.1
Zur Umsetzung von Assistenzprozessen in den Unternehmensbereichen mu¨ssen diese systematisch aufgenommen und aufbereitet werden. Folgendes Vorgehensmodell hat sich in APPsist bewa¨hrt: Zuerst werden in einem Experten-Workshop alle fu¨r die Durchfu¨hrung eines Prozesses notwendigen Schritte aufgenommen. Die aufgenommene Struktur entspricht in der Regel zuna¨chst der bisherigen Vorgehensweise, ist aber nicht zwangsla¨ufig optimal hinsichtlich Effizienz und Prozesslogik. Daher muss der Prozess in einem zweiten Schritt in der Expertenrunde optimiert werden, um somit einen Best-Practice-Ansatz zu generieren. Dabei muss vor allem die angestrebte Zielgruppe betrachtet werden, da sich die Prozessmodellierung in der Struktur und Granularita¨t dementsprechend signifikant unterscheiden kann. Mit der Optimierung wird fu¨r den Assistenzprozess eine definierte und reproduzierbare Arbeitsmethode festgelegt. Um diese fu¨r APPsist nutzbar zu machen, mu¨ssen im Folgenden Prozessschritte annotiert werden mit relevanten Daten aus der Maschinensteuerung und aus ME- und ERP-Systemen, die den Prozess entweder auslo¨sen, oder die fu¨r die Interaktion des Systems mit der Maschine oder Anlage relevant sind. Weiterhin mu¨ssen die Inhalte (Texte, Fotos, Modelle, Videos und Augmented Reality Inhalte) aufgenommen werden, die der Nutzer im Rahmen der Assistenz angezeigt bekommen soll. Bevor der Prozess im realen Umfeld eingesetzt werden kann, ist es weiterhin unabdingbar, diesen in einer Evaluationsrunde mit Experten und auch Shopfloormitarbeitern zu testen, um letzte Optimierungen an den gezeigten Inhalten vorzunehmen. 3.2
Die APPsist-Plattform vereint viele unterschiedliche Anforderungen in einem koha¨renten System. Daher wurden fu¨r die Entwicklung den Prinzipien einer Microservice-Architektur verfolgt und die Funktionen in einzelnen Diensten gekapselt, welche dann in der Plattform orchestriert werden. APPsist umfasst derzeit 18 Dienste aus den Bereichen Assistenz, Weiterbildung, Adaption, Benutzer- und Maschinenschnittstellen. Als Integrationstechnologie wird das Vert.x-Framework [Ve] in Version 2.1 verwendet. Profiliert hat sich das Framework bei der Realisierung der APPsist-Plattform insbesondere bei der Orchestrierung der Dienste u¨ber das integrierte Modulsystem und der den Diensten zur Verfu¨gung gestellten API fu¨r Server- und Clientimplementierungen. Als Laufzeitumgebung la¨uft Vert.x stabil und konnte problemlos in die IT-Landschaft der Pilotbereiche integriert werden. Das Framework bietet daru¨ber hinaus eine Sock.js-Bridge zur plattformu¨bergreifenden, bidirektionalen Kommunikation an, welche bei der Realisierung der Client-Applikation verwendet wurde. Hierbei musste jedoch zusa¨tzlicher Aufwand fu¨r die Stabilisierung der Anbindung investiert werden, da per se keine Mechanismen zur automatischen Wiederaufnahme einer Verbindung bereitgestellt werden.
Wa¨hrend die Dienste von den Entwicklungspartnern eigenverantwortlich entwickelt werden, gibt es dennoch eine Reihe von Fragen, welche dienstu¨bergreifend gekla¨rt werden mussten: a) Welche Funktionen erfu¨llt welcher Dienst? b) Wer ist fu¨r die Entwicklung des Dienstes zusta¨ndig? c) Welche Kommunikationswege gibt es zwischen den Diensten? Die Erfahrung hat gezeigt, dass diese Fragen nicht nur initial adressiert werden mu¨ssen, sondern auch entwicklungsbegleitend, insbesondere im Kontext eines Forschungsprojekts: Viele Funktionen konkretisieren sich erst im Rahmen der Entwicklung und es ergeben sich daru¨ber hinaus regelma¨ßig neue Anforderungen an die Plattform.
Typisch fu¨r eine Microservice-Architektur sind die besonderen Anforderungen an Analysierbarkeit des Systemverhaltens, da die Entwicklung der Dienste weitestgehend getrennt stattfindet. Die Laufzeit- und Fehleranalyse des Gesamtsystems ist fu¨r die Entwickler erschwert, da die Plattform i.d.R. nicht vollsta¨ndig lokal ausgefu¨hrt und Fehlverhalten erst durch die Kombination mehrerer Dienste ersichtlich wird. Daher erfolgt das Protokollieren von Systemereignissen strukturiert in einer (dienstu¨bergreifenden) Datenbank, der Ausfu¨hrungstatus der einzelnen Dienste wird erfasst und eine Weboberfla¨che bereitgestellt, die Entwicklern Zugang zu den Laufzeitinformationen der Plattform ermo¨glicht. Eine besondere Herausforderung stellt das Prinzip der Isolation auch in anderer Hinsicht dar: Jeder Dienst soll unabha¨ngig von den anderen Diensten laufen, so dass Fehler einzelAPPsist Statusbericht 177 ner Dienste nicht das ganze System in einen Fehlerzustand bringen. Technisch wird diese Trennung seitens des Frameworks dahingehend unterstu¨tzt, dass die einzelnen Dienste als Module in separaten Classloadern ausgefu¨hrt werden und separat initiert und verwaltet werden. Technische Sicherungsmechanismen schu¨tzen jedoch nicht vor logischen Abha¨ngigkeiten zwischen den Diensten. So ist z.B. der Assistenzdienst abha¨ngig von dem Dienst, welcher fu¨r das fu¨r die Adaption der anzuzeigenden Inhalte zusta¨ndig sind. Die Betrachtung mo¨glicher Sto¨rungen ist daher essentieller Bestandteil der Modellierung der Kommunikation: Es muss gekla¨rt werden wie darauf reagiert werden soll wenn ein Dienst a) nicht reagiert (Kompensation), b) u¨ber einen Fehler benachrichtigt (Fehlerbehandlung), oder c) unerwartete Daten zuru¨ckliefert (Validierung).
Eine Eigenschaft der APPsist-Architektur, welche in vielen Beispielen einer MicroserviceArchitektur so nicht zu finden ist, liegt in der Natur eines ereignisbasierten Systems: Es reagiert nicht nur auf Benutzereingaben und -anfragen, sondern auch auf Ereignisse des Benutzerkontexts, z.B. der bedienten Maschine. Dies sollte bei der Planung der Kommunikation besondere Beachtung finden, da die Gefahr besteht, dass ein Ereignis mehrere Aktionen anstoßen kann. Dies ist dann problematisch wenn mehrere Aktionen die gleichen Parameter des Systemzustands beeinflussen. Mo¨gliche Lo¨sungen sind die explizite, dienstu¨bergreifende Spezifikation der durchzufu¨hrenden Aktionen und deren Auswirkungen, sowie die Priorisierung mo¨glicher Zustandsa¨nderungen.
Als eindeutiges und festgelegtes Vokabular fu¨r die Kommunikation der Dienste und als Grundlage der intelligenten Entscheidungsprozesse der adaptiven Dienste dient in APPsist ein Modell der Doma¨ne ”Produktion“ (repra¨sentiert in OWL). Es wurde eine allgemeine Ontologie erstellt, die dann fu¨r die jeweiligen Anwendungspartner spezialisiert wurde. Die Adaptionsregeln, die die Informationen der Ontologie verwenden (gespeichert in einem Tripple-Store), um die Unterstu¨tzung der Bescha¨ftigten zu realisieren, basieren auf der allgemeine Ontologie und sind somit auf alle Anwendungspartner anwendbar. Es lassen sich im aktuellen APPsist-System folgende vier Unterstu¨tzungsarten die durch Regeln realisiert werden unterscheiden: Hauptta¨tigkeit-Assistenz: Wenn Mitarbeiter in ”Hauptta¨tigkeit“ und fordert Assistenz an, dann bestimme Maßnahmen, die relevant sind fu¨r aktuelle Station und Maschinenzustand. Nebenta¨tigkeit-Assistenz: Wenn Mitarbeiter in ”Nebenta¨tigkeit Lernzeit“ und fordert Assistenz an, dann bestimme Maßnahmen, die relevant sind fu¨r langfristige Entwicklungsperspektive. Hauptta¨tigkeit-Inhalte: Wenn Mitarbeiter in ”Hauptta¨tigkeit“ und Anforderung von Inhalten, dann bestimme Inhalte, die relevant sind fu¨r aktuelle Station und Maschinenzustand. Nebenta¨tigkeit-Inhalte: Wenn Mitarbeiter in ”Nebenta¨tigkeit Lernzeit“ und Anforderung von Inhalten, dann bestimme Inhalte, die relevant sind fu¨r langfristige Entwicklungsperspektive. Die Regeln legen fest, welche Maßnahmen und Inhalte in der konkreten Situation relevant sind. Diese ziehen beispielsweise die Arbeitsplatzgruppe des Bescha¨ftigten in Betracht, Aufgaben von Stellen und damit verbundene Maßnahmen und weiteres. Implementiert sind sie in einer Kombination aus Java-Code und SPAQRL Anfragen an den Tripple-Store. 3.4
Der Großteil der APPsist-Oberfla¨che wurde mit Webtechnologien umgesetzt. Dadurch funktioniert sie im Browser und damit auf sehr vielen Endgera¨ten. Eine Ausnahme dazu stellen die Augmented Reality (AR)-Funktionalita¨ten dar, fu¨r die spezielle Komponenten notwendig sind. Diese sind im APPsist-System Vuforia als AR-Plattform und Unity als Grafik- und App-Entwicklungs-Engine. Im Gegensatz zum urspru¨nglichen und in ersten Prototypen getesteten Konzept, das gesamte APPsist-Frontend in einer Unity-App laufen zu lassen, sind AR-Funktionalita¨ten und Inhalte, die im Browser dargestellt werden ko¨nnen, ab der aktuellen APPsist-Version konsequent getrennt. D.h. der Nutzer schaltet zwischen AR-App (Unity) und beispielsweise Assistenzinhalten (Browser) hin und her – allerdings nicht explizit sondern per Button in der GUI, sodass diese Trennung im Nutzungserlebnis nicht auffa¨llt. Die Trennung verbessert die Performanz und vereinfacht das Deployment fu¨r verschiedene Plattformen und Endgera¨te – je nachdem ob AR mit dem Endgera¨t mo¨glich ist, oder nicht. Bis jetzt wird AR v.a. eingesetzt, um dem Nutzer die Orientierung an komplexen Maschinen und Anlagen zu erleichtern, indem bestimmte Maschinenteile im Kamerabild hervorgehoben werden; weitere AR-Szenarien sind geplant. 3.5
Die Anbindung an die Produktionsanlagen wurde durch eine REST API realisiert: Der Server ist als Dienst in APPsist implementiert und beno¨tigt erst zur Laufzeit Informationen u¨ber die Daten der angeschlossenen Maschinen. Dadurch ist keine serverseitige Anpassung no¨tig, falls neue Maschinentypen unterstu¨tzt oder bestehende angepasst werden mu¨ssen. Um eine neue Maschine an das APPsist-System anzuschließen muss ein RESTKlient entwickelt werden, der die Daten der Maschinensteuerung ausliest und aufbereitet an den Server weitergibt. Zu Beginn sendet der Klient an den Server eine Schemanachricht die die verfu¨gbaren Daten sowie eine Kurzbeschreibung der Daten entha¨lt. Im Anschluss sendet der Klient periodisch Datennachrichten, welche die tatsa¨chlichen Maschinendaten entsprechend dem vorangegangenen Schema enthalten. Durch diese Trennung kann der Server bereits im Vorfeld die Visualisierung der Maschinendaten aufbauen. Innerhalb des Projektes wurde bereits eine Anbindung an SPS-Steuerungen, OPC-Server sowie Anlagen von Mitsubishi und Siemens realisiert. Die Kommunikation kann dabei u¨ber die Formate JSON, XML, EXI oder Plaintext erfolgen. Die oben beschriebene Schnittstelle wurde um eine Funktion erweitert, die es ermo¨glicht Verbindungsabbru¨che zu Maschinen fru¨hzeitig zu erkennen und dies in der Oberfla¨che entsprechend wiederzugeben. 4
Das APPsist-Projekt verfolgt den Ansatz eines benutzerzentrierten Entwurfsprozesses und so wurden potentielle Nutzer als wichtigste Evaluationsinstanz fu¨r die Gebrauchstauglichkeit der Benutzungsoberfla¨chen bereits mehrere Male im Laufe den Projekts befragt bzw. APPsist Statusbericht 179 die GUI mit ihrer Hilfe getestet. Ein gro¨ßer angelegter Usability-Test wird im Folgenden beschrieben. Weitere derartige Tests werden bis zum Ende des Projekts folgen. Am aktuellen Usability-Test nahmen von jedem der drei Anwendungspartner je sechs Testpersonen teil. Als Endgera¨te wurden verschiedene Tablets (Microsoft Surface 4 Pro, LG Nexus 5, Fujitsu V535 Industrial) verwendet sowie ein 22”-Touchscreen an einem Windows-7-Desktop-Rechner. Der Ablauf des Tests war jeweils wie folgt: 1. 2.
Briefing fu¨r die Testpersonen mit Datenschutzvereinbarung Vorabfragebogen: Ein demografischer Fragebogen mit Zusatzfragen zu Ta¨tigkeit, Deutschkenntnissen und Sehfa¨higkeit der Testperson.
Aufgabenstellung mit der APPsist-App (ThinkAloud-Analyse): Die Bearbeitung der Aufgaben, die nahezu den gesamten Funktionsumfang abdeckten, dauerte zwischen 20 und 45 Minuten. Dabei wurden die Testpersonen gebeten, laut zu denken und auch zu ihrer Meinung zu einigen Teilen des Systems bzw. der Benutzungsoberfla¨che gefragt. Dabei wurde zur Auswertung ein Bildschirm-Video inklusive Aufzeichnung des Gesprochenen gespeichert. Der Ablauf der Aufgabenstellung war standardisiert und die Fragen gro¨ßtenteils vorformuliert. So ko¨nnen die Antworten zu geschlossenen Fragen auch quantitativ ausgewertet werden.
Fragebo¨gen: System Usability Scale (SUS) [Br96], AttrakDiff [At]: Zwei schnell auszufu¨llende Fragebo¨gen zur Bewertung von Gebrauchstauglichkeit (Usability) und Nutzungserlebnis (User Experience).
Abschlussinterview: Standardisierte Fragen zu Gesamteindruck, Vorerfahrung und Bewertung anhand der Dialogkriterien aus ISO-EN-9241-110. Vom Gespra¨ch wurde zur Dokumentation und Auswertung jeweils eine Audioaufzeichnung gespeichert. Dieser Ablauf hatte einen summativen Test der Gebrauchstauglichkeit zum Ziel, der sowohl qualitative als auch quantitative Test- und Auswertungsteile beinhaltet. Bis jetzt ausgewertet sind SUS und AttrakDiff. Mit einem SUS-Score von 86,9 und einer AttrakDiffBewertung, die sowohl was die hedonische Qualita¨t (HQ: 1,16 Konfidenz: 0,45), als auch was die pragmatische Qualita¨t (PQ: 1,63 Konfidenz 0,27) angeht, im Bereich ”begehrt“ liegt (Die Skala reicht von ”u¨berflu¨ssig“ u¨ber ”neutral“ bis ”begehrt“), offenbarte das APPsist-System keinen akuten Handlungsbedarf. Auch eine erste Kurzauswertung der ThinkAloud-Analyse zeigte kein Gestaltungs-, Interaktions- oder Funktionskonzept, das von vielen Probanden einheitlich kritisch beurteilt worden wa¨re. 5
Dieser Artikel gab einen U¨berblick u¨ber den aktuellen Stand des Projekt APPsist. Im Projektverlauf hat sich herausgestellt, dass die gewa¨hlten Methoden und Technologien sich zum großen Teil bewa¨hrt haben. So ist die Microservice-Architektur gut geeignet, um die einzelnen Dienste zu entwickeln und sie zu integrieren, allerdings um den Preis ei[At] [Br96] [BR15] [Fr15] [Ul15] [Ul16] ner schwierigen Fehlerbehebung und nicht zufriedenstellend stabiler Client-Server Kommunikation. Die Ontologie erlaubte wie erhofft die pra¨zise Beschreibung der jeweiligen Situationen der Anwendungspartner bei gleichzeitig allgemein formulierten Adaptionsregeln, auch wenn eine komplett deklarative Formalisierung nicht mo¨ glich war, sondern eine Kombination von Java und SPARQL notwendig gewesen ist. In den bisherigen Evaluationen wurde die Usability sehr positiv bewertet. Kommende Evaluationen werden noch die Gu¨ te der Adaptionsregeln untersuchen mu¨ ssen.
Dieser Beitrag entstand im Rahmen des Projekts APPsist Intelligente Wissensdienste fu¨ r ” die Smart Production“, das vom Bundesministerium fu¨ r Wirtschaft und Energie unter dem Kennzeichen 01MA13004C gefo¨ rdert und vom DLR-Projekttra¨ger betreut wird.
AttrakDiff Publikationen. http://www.attrakdiff.de/sience.html. Last accessed: 2016-06-02.
Brooke, J.: SUS: A quick and dirty usability scale. In (Jordan, P. W.; Weerdmeester, B.; Thomas, A.; Mclelland, I. L., Hrsg.): Usability evaluation in industry. Taylor and Francis, London, 1996.
Blu¨mling, Sabrina; Reithinger, Norbert: Aufbereitung und Speicherung von Erfahrungswissen im PLuTO-Projekt. In: 8. AAL-Kongress. VDE Verlag, 2015.
Freith, Sebastian; Schu¨tze, Glenn; Ullrich, Carsten; Welling, Stefan; Kreimeier, Dieter; Kuhlenko¨tter, Bernd: Digitale Lernszenarien zur ganzheitlichen Unterstu¨tzung von Mitarbeitern im Arbeitsalltag. In: Proceedings of DeLFI Workshops 2015. Jgg. 1443 in CEUR Workshop Proceedings. CEUR-WS.org, S. 79–87, 2015. Ullrich, Carsten; Hauser-Ditz, Axel; Kreggenfeld, Niklas; Prinz, Christopher; Igel, Christoph: Assistenz und Wissensvermittlung am Beispiel von Montage- und Instandhaltungsta¨tigkeiten. In (Wischmann, Stefan, Hrsg.): Zukunft der Arbeit – eine praxisnahe Betrachtung. Springer Verlag, 2016. In press.