Digitale Inhalte in physischen Prozessen verankern

Abstract In this article, we present a concept for an AR development tool that enables non-developers from the industry to independently create AR instructions and enrich the physical environment with digital content. In a field study with 15 experts from the industry, we determined the utility, user acceptance, and the resulting workload. As a result, we provide design recommendations that serve as a blueprint for the development of similar tools.

1 Motivation

Im Jahr 2018 wurde die Technologie AR das letzte Mal im Gartner Hype Cycle in der Phase Tal der Tränen verortet, mit der Prognose, dass AR innerhalb von 5–10 Jahren das Plateau der Produktivität erreichen werde [1]. Eine große Studie der Unternehmensberatung Capgemini aus demselben Jahr, die über 700 Unternehmen zu ihrer internen AR/VR-Implementierung befragte, ergab, dass 86 % der Unternehmen davon ausgehen, dass AR in den nächsten fünf Jahren eine breite Anwendung in ihren Betrieben finden wird [2].

Diese positive Einschätzung ist eng verbunden mit den erheblichen Potenzialen, die AR für die Industrie darstellt. So konnte beispielsweise Boeing durch den Einsatz von AR in der Kabelmontage die Produktionszeit um 25 % reduzieren [2] und die Vorbereitungszeit sogar um 90 % [3]. Darüber hinaus leistet AR einen bedeutenden Beitrag zu der Förderung der Nachhaltigkeit und sozialen Verantwortung von Unternehmen, was sich positiv auf die ESG-Berichterstattung auswirkt. Durch die Implementierung von AR-basierten Fernwartungen lassen sich kostspielige Serviceeinsätze erheblich optimieren und in einigen Fällen sogar vollständig ersetzen. Dies wird ermöglicht, indem Kunden mithilfe von AR einfache Wartungs- und Reparaturarbeiten eigenständig durchführen können [4].

Trotz dieser hohen Erwartungen und des enormen Potenzials ist fünf Jahre später noch immer ein breiter Einsatz von AR in der Industrie ausgeblieben. Die Gründe dafür liegen sowohl in organisatorischen als auch in technischen Herausforderungen [5]. So erfordert die Entwicklung von AR-Anwendungen zum einen Programmierkenntnisse und zum anderen ein ausgeprägtes räumliches Vorstellungsvermögen [6]. Dies führt dazu, dass die Entwicklung entweder externen Agenturen überlassen werden muss oder speziell ausgebildete Mitarbeiter eingestellt werden müssen, was besonders für kleine und mittlere Unternehmen (KMUs) aufgrund der hohen Kosten oft nicht praktikabel ist. Darüber hinaus sind die technischen Herausforderungen auch ein wesentlicher Treiber der organisatorischen Herausforderungen, welche experimenteller Natur sind [7]. So ist es für die Unternehmen aufgrund der technischen Herausforderungen nicht möglich, mit der Technologie AR zu experimentieren, um mögliche Prozesse oder die allgemeine Tauglichkeit und den Mehrwert zu evaluieren.

Um die technische Komplexität bei der Erstellung von AR-Anwendungen zu reduzieren, konzentrieren sich die Wissenschaft und Praxis zunehmend auf die Entwicklung und Erforschung von AR-Entwicklungstools [8]. Dabei liegt der Fokus häufig auf Low-Code/No-Code-Methoden zur Erstellung der AR-Inhalte [9]. Solche Tools erlauben es Anwendern, die nur über Basis-IT-Kenntnisse und keine oder nur geringe Programmierkenntnisse verfügen, AR-Anwendungen zu entwickeln. Die Programmierung erfolgt nicht mehr auf der Basis von Textzeilen, sondern mit visuellen Hilfsmitteln in einer grafischen Benutzeroberfläche.

Dieser Beitrag stellt ein AR-Entwicklungstool für die Industrie vor, dass es Servicetechnikern ermöglicht, eigenständig AR-Anleitungen direkt vor Ort bei Reparaturen zu erstellen. Diese Anleitungen können anschließend mit Kollegen, für Trainingszwecke oder mit Kunden geteilt werden, um das Geschäftsmodell zu erweitern. Dadurch sind die Anwender in der Lage, ihre Reparaturen prozesskonform und effizient durchzuführen, was zu einer breiteren Adoption und einem breiteren Nutzen von AR in der Industrie führt.

Während das AR-Entwicklungstool nur für die Erstellung von AR-Anleitungen evaluiert wurde, ist es durch das einfache Ersetzen der Inhalte des 3D-Inhalte-Editors, vorgestellt in Kapitel 3.2, möglich, das AR-Entwicklungstool auch für weitere Anwendungsfälle in der Industrie zu verwenden. Das vom Autorenteam vorgeschlagene AR-Entwicklungstool eignet sich für alle Prozesse, bei denen Informationen jeglicher Art in der physischen Umgebung der Nutzer dargestellt werden sollen. Die Tabelle 1 gibt einen Überblick über die Anwendungsfälle, für welche das AR-Entwicklungstool verwendet werden kann. Die hier dargestellten Anwendungsfälle sind im Allgemeinen tauglich, um in AR abgebildet zu werden [10].

2 Augmented-Reality-Entwicklungstools

AR ist eine Technologie, bei der die menschliche Wahrnehmung der physischen Welt durch Überlagerung mit nützlichen digitalen Informationen oder Inhalten, die in Echtzeit angezeigt werden, augmentiert beziehungsweise ergänzt wird [11]. Im Gegensatz dazu schafft Virtual Reality (VR) eine immersive digitale Umgebung, bei welcher die menschliche Wahrnehmung der physischen Welt komplett ausgeblendet und die Nutzer in eine virtuelle Welt versetzt werden. Eine klare Trennung und Unterscheidung zwischen VR und AR ist essenziell, da beide Technologien sich grundlegend unterscheiden und zu verschiedenen Anwendungsmöglichkeiten führen. Das Tool in diesem Beitrag ist dem AR-Kontinuum aus dem XReality-Framework zu zuordnen, da Mitarbeiter und Kunden bei Prozessen in der physischen Welt unterstützt werden sollen. [12].

AR-Entwicklungstools bieten eine Umgebung für das Design, die Erstellung und die Verwaltung von AR-Anwendungen, in welchen die Anwender 3D-Inhalte in der physischen Umgebung platzieren und manipulieren können. Diese Tools lassen sich im Wesentlichen in zwei Kategorien einteilen. Die erste Kategorie umfasst Tools mit hoher Komplexität, die umfassende Programmierkenntnisse voraussetzen. Diese Tools bieten nahezu unbegrenzte Funktionen, ermöglichen die Erstellung von Anwendungen für diverse Kontexte und erfüllen eine Vielzahl an Anforderungen [6]. Die Entwicklung der AR-Anwendungen mithilfe dieser Tools erfolgt hauptsächlich auf dem Desktop. In der Praxis werden diese Tools wie Unity oder Unreal von Softwareentwicklern genutzt, um hoch individualisierte und leistungsfähige Anwendungen zu entwickeln.

Die zweite Kategorie enthält Tools mit geringerer Komplexität, die wenig bis keine Programmierkenntnisse erfordern. Die Tools aus dieser Kategorie sind häufig in ihrem Funktionsumfang stark eingeschränkt und oft auf spezifische Anwendungsfälle, wie das Erstellen und Animieren von Avataren, begrenzt [13]. Die Entwicklung von AR-Anwendungen mit diesen Tools findet zumeist auf Handheld-Geräten wie Smartphones oder Tablets sowie auf Head-Mounted-Displays, zum Beispiel der Microsoft HoloLens, statt. Ein Beispiel für ein solches Tool in der Praxis ist Microsoft Dynamics 365 Guides, das die Erstellung von AR-Anleitungen auf der Microsoft HoloLens 2 gestattet. Auffallend bei den Tools aus dem zweiten Cluster ist nicht nur die Einschränkung auf einen Anwendungsfall, sondern auch auf eine spezifische Hardware zum Erstellen und Anzeigen der AR-Anwendungen.

3 Technisches Konzept

3.1 Entscheidungspunkte des AR-Entwicklungstools

In diesem Abschnitt werden die Entscheidungen und die damit verbundenen Rationalen erläutert, die als Grundvoraussetzung für das AR-Entwicklungstool dienen. Die erste Entscheidung betraf die Auswahl der Hardware, abhängig vom Anwendungsfall und den Rahmenbedingungen. Hierbei standen im Wesentlichen drei Hardwarekategorien zur Verfügung: Head-Mounted-Displays wie die HoloLens, Handheld-Geräte wie Smartphones oder Tablets und projektorbasierte Schnittstellen. Die Auswahl wurde letztendlich durch den Zweck des Anwendungsfalls und die Funktionalitäten der AR-Hardware bestimmt [14]. Da der Fokus auf der Erstellung und nicht auf der eigentlichen Nutzung von AR-Anleitungen liegt, bei denen die Anwender beide Hände frei haben müssen, fiel die Wahl auf Handheld-Geräte, die zum einen weit verbreitet sind und zum anderen für die Anwender eine bekannte Benutzerschnittstelle darstellen.

Die zweite Entscheidung betraf die Auswahl der Tracking- und Anchoring-Methode. Das Anchoring bestimmt, wie und wo die digitalen Objekte in der physischen Umgebung verankert werden. Das Tracking hingegen sorgt dafür, dass die digitalen Objekte in der verankerten Position bestehen bleiben, auch wenn sich die Nutzer in der physischen Umgebung bewegen [15]. Das Autorenteam hat sich für eine Bilderkennung als Anchoring-Methode entschieden, die es dem Benutzer ermöglicht, ein Bild als Ankerpunkt zu verwenden. Diese Methode erleichtert es, die digitalen Objekte in der physischen Welt präzise zu positionieren. Im Gegensatz zu einer millimetergenauen Objekterkennung bietet die Bilderkennung eine einfachere Handhabung und erlaubt es den Anwendern, die digitalen Inhalte selbstständig zu platzieren. Für das Tracking wurde die ARFoundation-Technologie gewählt, die auf Apples ARKit und Androids ARCore aufbaut. ARFoundation ist ein Framework von Unity, das die Entwicklung von Augmented-Reality-Anwendungen ermöglicht [16]. ARKit ist Apples Framework für die Integration von Hardware-Sensorikfunktionen zur Erstellung von Augmented Reality Anwendungen auf iOS-Geräten [17], während ARCore das entsprechende Framework für Android-Geräte darstellt [18]. Beide Frameworks bieten präzises Tracking und Mapping der physischen Umgebung, wodurch AR-Anwendungen auf ihren jeweiligen Plattformen ermöglicht werden. Bei ARFoundation wird eine SLAM-Methode (Simultaneous Localization and Mapping) verwendet, ein Algorithmus, der gleichzeitig die Position des Geräts in einer unbekannten Umgebung bestimmt und eine Karte dieser Umgebung erstellt [19]. Diese Methode nutzt 3D-Referenzpunkte zur Bestimmung der Position des Geräts in der physischen Umgebung.

Die letzte Entscheidung, die getroffen wurde, ist die Auswahl der Methode der Benutzereingabe, bei welcher bestimmt wird, wie die Anwender mit den digitalen Inhalten interagieren können. Die Wahl der Benutzereingabe-Methode ist maßgeblich von der verwendeten Hardware abhängig. Durch die Entscheidung für Handheld-Geräte, standen grundlegend drei verschiedene Interaktionsmethoden zur Auswahl: berührungsbasierte Interaktionen, gerätebasierte Interaktionen und gestenbasierte Interaktionen [20]. In unserem Fall haben wir uns für die gerätebasierte Interaktion entschieden, da diese von den Anwendern als die natürlichste Interaktion und als die schnellste und einfachste Art der Interaktion wahrgenommen wird [20].

3.2 Software-Architektur

Das AR-Entwicklungstool ist ein eigenständiges Tool, welches auf einem Tablet funktioniert, ohne dass zusätzliche Software oder Plug-Ins installiert oder zusätzliche Hardware eingesetzt werden müssen. Das Entwicklungstool läuft auf Apple iPads mit iOS 11 oder höher. Das folgende Kapitel gibt einen Überblick über die grundlegende Architektur des AR-Entwicklungstools, Bild 1, das aus drei Softwarekomponenten besteht: 2D-Prozess-Editor, 3D-Inhalte-Editor und einem Ansichtsmodus.

Die erste Softwarekomponente des AR-Entwicklungstools ist der 2D-Prozess-Editor, in welchem die eigentliche Struktur und die Reihenfolge der AR-Anleitung festgelegt wird. Innerhalb dieses 2D-Prozess-Editors können Anwender zwischen drei verschiedenen Prozesstypen (Nodes) wählen: Info-Node, Instruction-Node und der Exploration-Node. Die Info-Node ermöglicht das Hinzufügen von 2D-Elementen wie Texten, die für allgemeine Hinweise vor der eigentlichen Montage oder dem eigentlichen Prozess verwendet werden können. Die Instruction-Node stellt einen Anleitungsschritt dar, bei welchem sowohl 2D-Inhalte in Form von Texten, Bildern und Videos als auch 3D-Inhalte hinzugefügt werden können. Dadurch kann auf spezifische Positionen in der physischen Umgebung verwiesen werden und zusätzlich die auszuführende Tätigkeit (der Arbeitsschritt) dargestellt werden. Bei der Exploration-Node können ausschließlich 3D-Inhalte in der physischen Umgebung hinzugefügt werden. Dies könnte zum Beispiel dafür verwendet werden, um schraubenspezifische Newtonmeter-Angaben hinzuzufügen. Das Bild 2 gibt einen Überblick über die grafische Benutzeroberfläche des 2D-Prozess-Editors, in welchem eine einfache AR-Anleitung abgebildet ist.

Die zweite Softwarekomponente des AR-Entwicklungstools ist der 3D-Inhalte-Editor, in welchem die Inhalte für die zuvor definierten Prozessschritte erstellt werden. Die Grundlage für die von uns genutzten Inhalte bildet die Forschung von Gatullo et al. [21] in welcher sechs Informationstypen vorgeschlagen werden, die ausreichend sind, um jede technische Dokumentation in einer AR-Anleitung abzubilden. Die Tabelle 2 gibt einen Überblick über die sechs Informationstypen und darüber, wie diese als Softwarefeatures in das AR-Entwicklungstool integriert wurde.

Die dritte Softwarekomponente ist der Ansichtsmodus, in welchem die erstellten AR-Anleitungen angezeigt und genutzt werden können. In diesem können die erstellten AR-Anleitungen lediglich angeschaut und nicht bearbeitet werden. Die erstellten 2D- und 3D-Elemente werden dem Anwender genau dort angezeigt, wo diese vorher platziert wurden. Zusätzlich können die erstellten Inhalte auf dem Smartphone angezeigt werden.

4 Feldstudie in der Industrie

Um die Nützlichkeit des AR-Entwicklungstools zu testen, wurde eine Fallstudie in zwei produzierenden Unternehmen aus den Bereichen der Energietechnik und Prozesstechnik durchgeführt. Es wurden 15 Experten*innen, die über Fachwissen in AR und im Umgang mit technischen Dokumentationen verfügen, mittels halbstrukturierter Interviews nach der Nutzung unseres Tools befragt. Der Ablauf der Fallstudie ist in drei Komponenten aufgeteilt. In der ersten Komponente, um Erfahrungen zu sammeln, wie AR-Entwicklungstools in der Praxis genutzt werden, haben die Experten*innen das AR-Entwicklungstool in ihrer realen Arbeitsumgebung genutzt, um eine AR-Anleitung zu erstellen. In der ersten Organisation wurde ein Standardwartungsfall gewählt, das Tauschen eines Schrader-Ventils, welches in regelmäßigen Intervallen an den technischen Anlagen durchgeführt werden muss. Bei der zweiten Organisation wurde ein komplexerer Anwendungsfall gewählt, das Tauschen der zentralen Steuereinheit, welches nur bei Defekten notwendig ist.

Nachdem die Experten*innen die AR-Anleitungen erstellt hatten, führten die Autoren eine Wartung oder Reparatur mit einer AR-Anleitung, die mit dem AR-Entwicklungstool vorab von ihnen erstellt wurde, durch. Die Anwendungsfälle sind dabei die gleichen geblieben.

Anschließend wurden mit einem halbstrukturierten Interview als erstes ihre ersten Eindrücke bezüglich des Tools abgefragt. Des Weiteren wurden sie gebeten, die Funktionalitäten und die Informationselemente zu beschreiben, welche für die Erstellung und Nutzung für sie von Relevanz waren. Zum Schluss wurden die Experten*innen bezüglich der Praxistauglichkeit und der Vor- und Nachteile gegenüber den herkömmlichen Systemen befragt.

Nach dem halbstrukturierten Interview wurden die Experten*innen gebeten, eine kurze Umfrage bezüglich der wahrgenommenen Nützlichkeit, der wahrgenommenen einfachen Bedienbarkeit, der allgemeinen Bereitschaft zur Nutzung der Technologie, der Arbeitsbelastung und demografischer Daten auszufüllen. Wann immer es möglich war, wurden validierte Skalen aus früheren Studien verwendet und angepasst, um die Konstrukte auf einer Skala von 1 (negativ) bis 7 (positiv) zu messen. Die Skala der wahrgenommenen Nützlichkeit, einfachen Bedienbarkeit und der allgemeinen Bereitschaft zur Nutzung gegenüber einer neuen Technologie basiert auf der Skala von Wixom und Todd [22]. Die Skala der Arbeitsbelastung basiert auf der Skala NASA Task Load Index [23], welche mit einer Skala von 10 (niedrig) bis 100 (hoch) gemessen wurde. Das Bild 3 gibt einen Überblick über den Ablauf der Fallstudie, um ein besseres Verständnis für die Rahmenbedingungen zu erhalten.

5 Ergebnisse der Feldstudie

Im Folgenden werden die qualitativen und quantitativen Ergebnisse der Feldstudie dargestellt. Basierend auf den Ergebnissen werden zusätzlich Handlungsempfehlungen für die Gestaltung zukünftiger AR-Entwicklungstools in der Industrie gegeben.

5.1 Technologieakzeptanz und Arbeitsbelastung

Die Akzeptanz einer neuen Technologie durch die Anwender ist ein entscheidendes Element, das über deren Nutzung und Erfolg entscheidet. Akzeptanzmodelle sind theoretische Rahmen, die darlegen, aus welchen Bestandteilen sich diese Konstrukte zusammensetzen und durch welche Faktoren die Akzeptanz bestimmt wird. Ein bekanntes Beispiel ist das Technologieakzeptanz­modell von Davis [24] welches besagt, dass sich die Akzeptanz im Wesentlichen aus zwei Faktoren zusammensetzt: dem wahrgenommenen Nutzen (perceived usefulness) und der wahrgenommenen Bedienungsfreundlichkeit der Technologie (perceived ease of use). Einfach ausgedrückt, je größer der Nutzen und je einfacher die Bedienung, desto eher sind Anwender bereit, eine neue Technologie zu nutzen [24].

Das Bild 4 gibt einen Überblick über die Ergebnisse des wahrgenommenen Nutzens und der Bedienungsfreundlichkeit des AR-Entwicklungstools Die Umfrage ergab, dass die Anwender das AR-Entwicklungstool als sehr einfach zu bedienen empfanden (mit einem Mittelwert von 5,83 und einer Standardabweichung von 0,80) und ihm einen ähnlich hohen Nutzen zuschrieben (Mittelwert: 5,75; Standardabweichung: 1,26). Diese positiven Ergebnisse spiegelten sich auch in der hohen Bereitschaft wider, die Technologie im Arbeitsalltag einzusetzen (Mittelwert: 6,30; Standardabweichung: 0,75).

Ein weiterer wichtiger Aspekt bei der Implementierung neuer Technologien ist die daraus resultierende Arbeitsbelastung. Eine Bewertung der Arbeitsbelastung hilft festzustellen, ob eine Technologie zu komplex ist und ob Anpassungen nötig sind, um sie benutzerfreundlicher zu gestalten. Dies trägt dazu bei, die Akzeptanz und Effizienz der Technologienutzung zu verbessern, da Technologien, die eine hohe kognitive Belastung verursachen, weniger effektiv genutzt werden können, Fehler begünstigen oder von den Anwendern möglicherweise abgelehnt werden.

Wie bereits in Kapitel 4 „Feldstudie in der Industrie“ erwähnt, haben wir zu der Bestimmung der Arbeitsbelastung den NASA Task Load Index verwendet, da dieser eine umfassende Bewertung der wahrgenommenen Arbeitsbelastung bietet, indem verschiedene Dimensionen wie mentale Belastungen, körperliche Belastungen, zeitliche Belastungen, Leistung, Anstrengung und Frustrationsniveau berücksichtigt werden [23]. Das Bild 4 gibt einen Überblick über die Ergebnisse der wahrgenommenen Arbeitsbelastung unter Verwendung des AR-Entwicklungstools. Dabei entsprechen Werte von 0–9 einer niedrigen, von 10–29 einer mittleren, von 30–49 einer etwas erhöhten, von 50–79 einer hohen und von 80–100 einer sehr hohen Arbeitsbelastung. Die Ergebnisse der Studie zeigten eine insgesamt etwas erhöhte Arbeitsbelastung (Mittelwert: 40,69; Standardabweichung: 12,90) bei der Verwendung des AR-Entwicklungstools. Besonders hervorzuheben ist das wahrgenommene mittlere Frustrationsniveau (Mittelwert: 25,33; Standardabweichung: 15,86). Der einzig erhöhte Wert ist die empfundene zeitliche Belastung durch das AR-Entwicklungstool (Mittelwert: 53,3; Standardabweichung: 22,41).

5.2 Ergebnisse der Interviews

Bei der Analyse der Interviews lag der Fokus auf der Praxistauglichkeit des AR-Entwicklungstools für das Erstellen und Nutzen von AR-Anleitungen und darauf, welche Funktionen als besonders hilfreich angesehen wurden. Die Experten*innen berichteten übereinstimmend, dass sie keine Schwierigkeiten beim Erstellen der AR-Anleitungen hatten. Im Gegenteil: Sie fanden es beeindruckend, dass sie nach einer kurzen Einführung in das Tool selbstständig AR-Anleitungen erstellen konnten. Allerdings nur verbunden mit einer kurzen Einführung in Form eines Trainings oder eines Onboardings innerhalb des AR-Entwicklungstools, welche ihnen die grundlegende Funktion des Tools erklärt.

Die Experten*innen betonten, dass das Tool besonders geeignet für das Erstellen von Anleitungen für standardmäßige oder geplante Wartungen sei. Was Reparaturen bei Kunden vor Ort betrifft, waren sie eher zurückhaltend, da sie zum Beispiel durch Wartungsverträge oder Ähnliches dazu verpflichtet sind, Reparaturen in einer vorgegebenen Zeit zu erledigen. Das gleichzeitige Erstellen einer AR-Anleitung könnte sie dabei behindern. Diese Zurückhaltung deckt sich mit den Beobachtungen zu erhöhten zeitlichen Belastungen aus der Umfrage, die in Kapitel 4.1 Technologieakzeptanz und Arbeitsbelastung beschrieben wurden.

Das Erstellen der AR-Anleitung auf dem Tablet wurde von der Mehrheit der Experten*innen als sehr angenehm empfunden, da sie durch das größere Display die AR-Inhalte deutlich präziser in der physischen Umgebung verankern konnten. Die Experten*innen merkten zudem an, dass Änderungen in bestehenden Handbüchern aufwendiger seien als das Erstellen oder Überarbeiten einer AR-Anleitung mit dem AR-Entwicklungstool. Eine Funktion zum Duplizieren oder Kopieren von Wartungsschritten wurde als potenzielle Verbesserung vorgeschlagen, um den Erstellungsprozess effizienter zu gestalten, da häufig die Anleitungen über ähnliche Wartungsschritte verfügen.

Bezüglich der Nutzung der AR-Anleitungen stellten die Experten*innen fast einheitlich fest, dass die Anzeige der AR-Anleitungen auf verschiedenen Geräten wie Smartphones essenziell sei. Tablets wurden als unpraktisch für Reparatur- oder Wartungsarbeiten angesehen, da diese für jeden Wartungsschritt, der durchgeführt werden soll, abgelegt werden müssen. Auch AR-Brillen, obwohl sie ein freihändiges Arbeiten ermöglichen, wurden ebenfalls von den Experten*innen als unpraktisch angesehen, da die Servicetechniker*innen daran denken müssen, die AR-Brille mit zu dem Serviceeinsatz zu nehmen und sicherzustellen, dass die Brille vorher auch geladen ist. Fast alle Experten*innen waren sich einig, dass für die Wartung/Reparatur einer technischen Anlage mithilfe einer AR-Anwendung auf dem Smartphone die beste Lösung darstellt, da zum einen jede*r Servicetechniker*in ein Smartphone bei dem Serviceeinsatz dabei hat und dieses zum anderen mit nur einer Hand bedient werden kann.

Neben Fotos und Videos galten die Tether, welche zur Positionsbestimmung von Bauteilen im physischen Raum verwendet werden, als besonders hilfreich. Zudem haben die Experten*innen angegeben, dass sie eine AR-Anleitung einem Video vorziehen würden, da sie durch die Schritt-für-Schritt-Anleitung die Wartung/Reparatur in ihrem eigenen Tempo durchführen können, was bei einem Video nicht der Fall ist. Nahezu alle Experten*innen haben angegeben, dass die sechs Informationstypen nicht ausreichen, um vollständige AR-Anleitungen für ihre technischen Anlagen zu erstellen, und spezifischere, auf das Unternehmen und die technischen Anlagen zugeschnittene Inhalte erforderlich sind. Schließlich sahen die Experten*innen in der Einarbeitung neuen Personals den größten Nutzen der AR-Anleitungen, da diese nur einmal erstellt werden müssen und dann dem neuen Personal helfen, den Montage- oder Reparaturprozess der technischen Anlagen Schritt für Schritt zu erlernen.

5.3 Designempfehlungen für AR-Entwicklungstools

Die erste Designempfehlung für zukünftige AR-Entwicklungstools in der Industrie ist, den Erstellungs- und Nutzungsprozess innerhalb des Tools zu trennen. Dies ermöglicht es den Anwendern, die erstellten AR-Anleitungen auf verschiedenen Geräten wie Smartphones oder Head-Mounted-Displays abzuspielen, um die unterschiedlichen Präferenzen der Anwender zu berücksichtigen.

Die zweite Designempfehlung betrifft die Durchführung des gesamten AR-Entwicklungsprozesses auf einer einzigen Hardware, wodurch Anwender direkt an der technischen Anlage die AR-Anleitung erstellen können.

Die dritte Designempfehlung bezieht sich auf die Gestaltung des AR-Entwicklungsprozesses. Dieser sollte so konzipiert sein, dass er in vollem Umfang ausschließlich auf einer einzigen mobilen Hardware durchgeführt werden kann. Dadurch sind die Anwender in die Lage, direkt an der technischen Anlage eine AR-Anleitung zu erstellen, ohne vorherige Vorbereitungen, wie beispielsweise Arbeiten am Computer, tätigen zu müssen.

Die vierte Designempfehlung betrifft die Inhalte im AR-Entwicklungstool. Obwohl die Anwender in der Lage waren, AR-Anleitungen mit den sechs Informationstypen nach Gattullo et al. [21] zu erstellen, zeigte sich, dass die Experten spezifische Inhalte benötigen, die auf ihr Unternehmen und ihre technischen Anlagen zugeschnitten sind, um vollständige AR-Anleitungen zu erstellen. Hierbei ist wichtig, dass den Anwendern eine begrenzte, aber ausreichende Anzahl an Informationstypen zur Verfügung gestellt wird, um die Arbeitsbelastung nicht unnötig zu erhöhen.

Schließlich empfiehlt das Autorenteam, ein umfassendes Onboarding oder Tutorial in dem AR-Entwicklungstool zu implementieren, das den Anwendern, wie zum Beispiel den Servicetechnikern*innen, die Funktionen des Tools erläutert. Dies ist von besonderer Relevanz, da nicht davon ausgegangen werden kann, dass alle Anwender bereits Erfahrungen im Umgang mit AR-Technologien gesammelt haben. Ein solches Onboarding oder Tutorial hilft den Anwendern, sich bei der ersten Benutzung des AR-Entwicklungstools zurechtzufinden, und unterstützt sie bei der Einarbeitung in die neue Technologie.

6 Zusammenfassung und Ausblick

In diesem Beitrag wird ein Konzept vorgestellt, mit welchem Nicht-Entwickler aus der Industrie in der Lage sind, eigenständig AR-Anwendungen zu erstellen und die physische Umgebung mit digitalen Inhalten anzureichern. Das Konzept des AR-Entwicklungstools bietet Unternehmen einen niederschwelligen Zugang zu der Technologie AR und den damit verbundenen Potenzialen. In diesem Beitrag wird anhand der allgemeinen Softwarearchitektur und der konkreten AR-Inhalte ein abstraktes Verständnis dessen vermittelt, was das Autorenteam bei der Entwicklung des Tools gelernt hat. Es dient somit als Blaupause für die Entwicklung ähnlicher Tools. Darüber hinaus wird aufgezeigt, für welche Anwendungsbereiche die Blaupause des AR-Entwicklungstools gültig ist. Durch die Feldstudie konnte zum einen die Praxistauglichkeit des AR-Entwicklungstools nachgewiesen werden und zum anderen konnten erste Schritte zur Ermittlung der Akzeptanz und der entstehenden Arbeitsbelastung beim Einsatz eines AR-Entwicklungstools unternommen werden.

Weiterer Forschungsbedarf besteht in der Ermittlung der Qualitäten der AR-Anleitung, welche von den Anwendern erstellt wurde. Durch unsere Feldstudie konnten wir zum einen nachweisen, dass Nicht-Entwickler aus der Industrie in der Lage sind, eigenständig AR-Anleitungen zu erstellen, und zum anderen konnten die Anwender mithilfe der vorher erstellten AR-Anleitungen erfolgreich eine Wartung/Reparatur durchführen. Die dafür genutzten AR-Anleitungen wurden vorher von AR-Experten erstellt. Im nächsten Schritt wäre es interessant, die von den Anwendern erstellten AR-Anleitungen hinsichtlich der Praxistauglichkeit zu bewerten.

Dieses Forschungs- und Entwicklungsprojekt wird mit Mitteln des Bundesministeriums für Bildung und Forschung (BMBF) im Programm „Zukunft der Wertschöpfung – Forschung zu Produktion, Dienstleistung und Arbeit“ (Förderkennzeichen 02K18D180) gefördert und vom Projektträger Karlsruhe (PTKA) betreut. Die Verantwortung für den Inhalt dieser Veröffentlichung liegt beim Autor.

Weitere Informationen zum Forschungsprojekt WizARd sind verfügbar unter: https://wizard.tu-dortmund.de

Literatur

1. Gartner: Gartner Identifies Five Emerging Technology Trends That Will Blur the Lines Between Human and Machine. Internet: https://www.gartner.com/en/newsroom/press-releases/2018–08–20-gartner-identifies-five-emerging-technology-trends-that-will-blur-the-lines-between-human-and-machine. Zugriff am 27.03.2024
2. Cohen, L.; Duboé, P.; Buvat, J. et al.: Augmented and Virtual Reality in Operations. Internet: https://www.capgemini.com/wp-content/uploads/2018/09/AR-VR-in-Operations1.pdf. Zugriff am 27.03.2024
3. Serván, J.; Mas, F.; Menéndez, J. L. et al.: Using augmented reality in AIRBUS A400M shop floor assembly work instructions. The 4th Manufacturing Engineering Society International Conference, 2011, S. 633–640
4. Porter, M. E.; Heppelmann, J. E.: Why every organization needs an augmented reality strategy. Harvard Business Review (2017) November-December, S. 1–13
5. Konopka, B.; Hönemann, K.; Wiesche, M.: Investigation of key barriers regarding adoption and implementation of augmented reality in industrial organizations: a delphi study. 57th Hawaii International Conference on System Sciences., 2024
6. Nebeling, M.; Speicher, M.: The Trouble with Augmented Reality/Virtual Reality Authoring Tools. IEEE International Symposium on Mixed and Augmented Reality Adjunct, 2018, S. 333–337
7. Azuma, R. T.: The Most Important Challenge Facing Augmented Reality. Presence: Teleoperators and Virtual Environments 25 (2016) 3, S. 234–238
8. Hönemann, K.; Konopka, B.; Thatcher, J. B. et al.: Designing a user-metaverse interface for the industrial-metaverse. International Conference on Information Systems (ICIS), 2023
9. Bräker, J.; Hertel, J.; Semmann, M.: Empowering Users to Create Augmented Reality-Based Solutions – Deriving Design Princi-ples for No-Code AR Authoring Tools. 44th International Conference on Information Systems., 2023
10. Klinker, K.; Berkemeier, L.; Zobel, B. et al.: Structure for innovations: A use case taxonomy for smart glasses in service processes. Multikonferenz Wirtschaftsinformatik Lüneburg, 2018
11. Azuma, R. T.: A Survey of Augmented Reality. Presence: Teleoperators and Virtual Environments 6 (1997) 4, S. 355–385
12. Rauschnabel, P. A.; Felix, R.; Hinsch, C. et al.: What is XR? Towards a Framework for Augmented and Virtual Reality. Computers in Human Behavior 133 (2022)
13. Krings, K.; Weber, P.; Jasche, F. et al.: FADER: An Authoring Tool for Creating Augmented Reality-Based Avatars from an End-User Perspective. Mensch und Computer 2022, 2022, S. 52–65
14. Oun, A.; Hagerdorn, N.; Scheideger, C. et al.: Mobile Devices or Head-Mounted Displays: A Comparative Review and Analysis of Augmented Reality in Healthcare. IEEE Access 12 (2024), S. 21825–21839
15. Kato, H.; Billinghurst, M.: Marker tracking and HMD calibration for a video-based augmented reality conferencing system. 2nd IEEE and ACM International Workshop on Augmented Reality, 1999, S. 85–94
16. Unity Technologies: AR Foundation. Internet: https://unity.com/de/unity/features/arfoundation. Zugriff am 03.09.2024
17. Apple Developer: Framework: ARKit. Internet: https://developer.apple.com/documentation/arkit/. Zugriff am 03.09.2024
18. Google Developer: Übersicht über ARCore und unterstützte Entwicklungsumgebungen. Internet: https://developers.google.com/ar/develop?hl=de. Zugriff am 03.09.2024
19. Durrant-Whyte, H.; Bailey, T.: Simultaneous localization and mapping: part I. IEEE Robotics & Automation Magazine 13 (2006) 2, S. 99–110
20. Goh, E. S.; Sunar, M. S.; Ismail, A. W.: 3D Object Manipulation Techniques in Handheld Mobile Augmented Reality Interface: A Review. IEEE Access 7 (2019), S. 40581–40601
21. Gattullo, M.; Dammacco, L.; Ruospo, F. et al.: Design preferences on Industrial Augmented Reality: a survey with potential technical writers. IEEE International Symposium on Mixed and Augmented Reality Adjunct (ISMAR-Adjunct), 2020, S. 172–177
22. Wixom, B. H.; Todd, P. A.: A Theoretical Integration of User Satisfaction and Technology Acceptance. Information Systems Research 16 (2005) 1, S. 85–102
23. Hart, S. G.; Staveland, L. E.: Development of NASA-TLX (Task Load Index): Results of Empirical and Theoretical Research. In: Human Mental Workload. Elsevier 1988, S. 139–183
24. Davis, F. D.: Perceived Usefulness, Perceived Ease of Use, and User Acceptance of Information Technology. MIS Quarterly 13 (1989) 3, S. 319