Zur Lösung dieser Problemstellung haben sich zwei Projektpartner zusammengetan:
Upstream Mobility, ein Tochterunternehmen der Wiener Linien und Wiener Stadtwerke. Ihre Mission: „Wir stellen den Menschen in den Mittelpunkt und schaffen Mobilität mit Mehrwert. Stets einen Schritt voraus, bauen wir mit zukunftsweisenden Projekten unsere Innovationsführerschaft in Sachen digitaler Mobilität aus.“
Und Nagarro, ein weltweit führendes Unternehmen für digitale Produktentwicklung. Das Full-Service-Portfolio umfasst Digital Product Engineering, E-Commerce und Customer Experience Services, Managed Services, ERP-Beratung und Technologie-Dienstleistungen.
Die gemeinsame Vision: Indoor-Navigation über Smart Glasses zur Unterstützung von Blinden und Sehbehinderten sowie sehenden Menschen im ÖV.
Konkret wurde das Wissen beider Unternehmen gebündelt um herausfinden, wie man blinden- und sehbehinderten Menschen, durch die Nutzung von modernster Technologie in der Indoor-Navigation ein Stückchen Freiheit zurückgeben kann – Codewort „Mobi“. Ich bekam die einmalige Chance, als Innovation Quality Manager bei Nagarro Teil dieser Mission zu sein, und möchte praxisnahe Insights aus diesem spannenden Projekt mit Ihnen teilen.
Der Projektstart
Zwei ambitionierte Teams standen in den Startlöchern. Nach einigen Brainstormings zur Aufgabenstellung haben wir mit den Upstream Technology Scouts erste Ideen, Wünsche und Vorstellungen geboren und in eine griffigere und anschaulichere Form gebracht, bevor wir uns mit konkreten Technologien beschäftigten.
Schritt 1: Recherche
Die Außenwelt ist kartiert. Die Genauigkeit/ Abweichung liegt je nach Tool-/App-Lösung (via GPS) bei rund 10 bis 20 Metern. Bei Navigation in Innenräumen oder sogar im „Untergrund“ (z. B. U-Bahn-Stationen) liegt die Genauigkeit sogar darunter. Theoretisch haben sich bereits Indoor-Positioning-Systeme (IPS) etabliert, die Abweichungen von weniger als 2 cm Genauigkeit versprechen.
Wir wollten diese Theorien in der Praxis prüfen! Das war der Ausgangspunkt unseres Projekts. Unsere initiale Komponenten-Recherche beinhaltete:
- Selektion eines PDR-Algorithmus (Pedestrian Dead Reckoning).
- Die Identifikation von passenden Wegfindungs-, sowie Positionsfindungs-Algorithmen: BLE-Beacon-Positionierung, Magnetfeldmethodik sowie Sensor-basierte Positionierung.
Die für uns erfolgversprechendste Lösung: Eine Kombination aus Smart Glass, Smartphone & BLE Beacons – eine integrierte Datenbrillen-Lösung mit Sprachausgabe, Suche und Navigation zum Point-of-Interest mithilfe von Echtzeit-Standorterkennung über Bluetooth Beacons und dynamische Objekterkennung.
Schritt 2: Eine erste Standortbestimmung
Die erste Recherche bot schon einen guten Einblick, was wir am Ende in Händen halten sollten. Aber wie man weiß, liegt der Teufel im Detail. Da die Entwicklung einer solchen Lösung für uns alle „Neuland“ war, setzten wir auf ein agiles Vorgehen bei der Produktentwicklung.
Neben einer technischen Evaluierung galt es aber vor allem, gewünschte Funktionalitäten für unsere Zielgruppe zu konkretisieren. Welche Bedürfnisse, Wünsche und vor allem reale Hilfen könnten hier wirklich Erleichterung bringen? Unser Ansatz: Wir definierten Personas inklusive User-Journeys.
Schritt 3: Verfeinerung der gewünschten Funktionalität
In weiteren Workshops wurden, aus Sicht der beiden Personas „Gustav“ und „Ina“ (siehe Tabelle 1), die skizzierten Features auf konkrete Machbarkeit und Nutzen geprüft, konkretisiert und in Epics und weiter in User-Storys (US) heruntergebrochen:
- Neben den Navigationselementen wurden KI-unterstützte Bilderkennungs-Features eingebracht, z. B. zur Erkennung temporärer Warnhinweise, wie „Vorsicht Rutschgefahr-“ oder „Außer Betrieb“-Schilder.
- Wir ergänzten Epics & US mit Akzeptanzkriterien (AK). Das Kern-Planungsteam fungierte als erweiterter Product Owner, welche Akzeptanz & Priorität abstimmten.
- Zu den AK definierten wir entsprechende Testfälle, denn was wäre die beste App ohne vernünftige Qualität?
- Weiters setzten wir „Prüfen auf Automatisierbarkeit der Testfälle“ auf unsere Todo-Liste.
Tabelle 1: Zwei Personas
Schritt 4: Architektur
Aus technischer Sicht sind die aktuelle Verfügbarkeit, verlässliche Partner sowie Technologien wesentliche Erfolgsfaktoren. Daraus leitet sich die in Abbildung 1 skizzierte Systemarchitektur für uns ab.
Abb. 1: Systemarchitektur Mobi
Aufgrund der Einschränkungen (Corona-Lockdown & Co.) mussten während der Testphase drei Testlocations aufgesetzt werden – zwei physische Testlocations in den Büros von Nagarro und Upstream in Wien sowie eine virtuelle Testlocation für unsere Nagarro-Projektkollegen in Indien –, bevor wir schlussendlich den Einsatz in einer realen U-Bahn-Station prüfen konnten. Dadurch gewannen wir wichtige Erkenntnisse.
Aus früheren Projekten wissen wir, wie wichtig eine klare Menü-Struktur, welche den Nutzer sowohl akustisch (Sprachbefehle) als auch visuell (Ansicht in Smart Glass) durch die Anwendung leitet, für die Nutzer-Akzeptanz ist. Darum legten wir ein Hauptaugenmerk darauf. Unsere Menüstruktur zeigt Abbildung 2.
Abb. 2: Menüstruktur Mobi (Testsystem)
Die Implementierung
Neben dem Aufbau der Architektur startete unser Entwicklungsteam mit Hochdruck die Implementierung der Basis-Funktionalität und die Integration der System-Komponenten:
- Digitalisierung der Testlocation: Digitalisierung der Location-Grundrisse, Definition der möglichen Verbindungspfade sowie aller verwendeten Kategorien & Typen (Ausgänge, Sitzbänke, Aufzüge, Rolltreppen usw., siehe Abbildung 3).
- Beacon Coverage: Mittels der App eines weiteren Partners wurde die Abdeckung der montierten Beacons aufgezeichnet – eine der wesentlichsten Voraussetzungen für eine funktionstüchtige Navigation (siehe Abbildung 4).
- Smart Glass Set-up: Das Aufsetzen/Aktualisieren der Google Glass bedurfte mehr Geduld und Kreativität, als ursprünglich angenommen, letztlich waren wir aber erfolgreich (siehe Abbildung 5).
Abb. 3: Digitalisierte Testlocation 1
Abb. 4: Beacon Coverage
Abb. 5: „Gustav“ in Action
Der Testbetrieb
„OK Mobi“, unser „Wake Up“- Kommando für die Lösung, wurde im Testbetrieb unser Alltag. In zahlreichen Testläufen wurden Routen, Screen-Anzeigen und Sprachausgaben verifiziert, korrigiert und optimiert, bis uns „OK Mobi“ im Traum erschien und wir uns mit „OK Mobi“ begrüßten.
Durch die effiziente Zusammenarbeit mit unserem außerordentlich motivierten Entwicklungsteam konnten initiale Fehler stets rasch behoben werden. Neben ersten Erfolgen gab es jedoch auch einige Herausforderungen, die uns einiges an Kopfzerbrechen bereiteten. Ein Dauerbrenner war die akkurate Lokalisierung der aktuellen Position der Testperson („Blue Dot“) auf dem Weg von A nach B. Wir investierten viele Teststunden, um das Zusammenspiel von berechneter Navigation und Identifikation der aktuellen Position zu verfeinern.
Die aus den Akzeptanzkriterien abgeleiteten Testfälle, welche sich auf die Menü-Abfolge bezogen, konnten rasch erfolgreich abgewickelt werden. Dabei bewährte sich unser agiler Ansatz, durch welchen wir im PD-CA-Zyklus aus Plan – Do – Check – Act die Screen-Inhalte und -Abläufe laufend verbessern und optimieren konnten.
Routen-Kommandos, welche uns zum gewünschten Ziel führen sollten, hielten häufig Überraschungen für uns bereit. Manchmal führte uns Mobi sehr präzise zum gewünschten Ziel, beim „Regressionstestlauf“ blieben wir allerdings „auf der Strecke“ liegen. Nach vielen, vielen (Test-) Stunden kamen wir zur Erkenntnis, dass die auf der Website des Positionsbestimmungs-Tool-Herstellers kolportierten 1 bis 3 Meter Abweichung bei der Positionserkennung wohl eher ein theoretischer Marketingspruch war als erprobte Praxis.
Neu war für uns auch, dass die Größe der Location einen wesentlichen Einfluss auf die Präzision der gelieferten (Beacon-)Signale hatte, welche die Basis für die Positionsberechnung bildeten. Konkret: Bei kleinen Locations (ca. 100 m2) ist hier mit Abweichungen von 5 m und mehr zu kalkulieren. Bis zuletzt feilten wir an den Nachjustierungen und setzten auf Aussagen des Herstellers, wonach die Lösung in größeren Räumlichkeiten deutlich bessere Ergebnisse liefern sollte.
Mit dieser Hoffnung im Gepäck starteten wir den Vorbereitungstest für den UAT im Upstream Office (ca. 1.000 m2).
Bereits erste Testläufe zeigten deutlich verbesserte Navigationsergebnisse, was unsere Hoffnungen - zum Glück – bestätigte. Mit ein Erfolgsfaktor war die konstruktive und flexible Art des Upstream-Projektleiters und seines Teams, durch deren Engagement und Erfahrung auch noch kleinere technische Hürden erfolgreich genommen wurden. So stand der Abnahme am Ende dieser R&D Projekt-Phase (UAT) nichts im Wege.
Unseren Plan, hier auch gleich mit automatisierten Tests eine Basis für die nachhaltige Qualitätssicherung zu schaffen, mussten wir aufgrund der Volatilität der Ergebnisse, mehr und mehr reduzieren. Aktuell beließen wir es bei der konzeptionellen Planung und konzentrierten uns auf die Erfüllung der zugesagten Grundfunktionalität.
Was wir gelernt haben
Dieses Projekt zeigt, dass heute vieles bereits machbar ist, allerdings noch einige Schritte zu einer veritablen Produktreife erforderlich sind. Ein Auszug aus meinem Tester-Stammbuch:
Hohe Flexibilität und Kreativität ist Grundvoraussetzung bei Emerging Technology (R&D)-Projekten, da die eingebundene Hardware sehr volatile Ergebnisse verursacht/ liefert.
Grobe statt detaillierte Testfall-Beschreibungen sind unabdingbar, wenn Testfälle mit vernünftigem Aufwand aktuell gehalten werden sollen.
Agile in Reinkultur: „Inspect & Adapt“ gilt hier in allen Bereichen – bei der Definition der Epics, US, AK, bis hin zu den Testfällen.
Testautomatisierung setzt stabile, ident ablaufende Abläufe voraus, um hier zielführend auf- und umgesetzt werden zu können:
- In Basisfunktionen, wo stabil laufende Abläufe sichergestellt sind, wie beim Starten und Auswählen der Basissettings (Blind/ Sehend Modus, Aufzug/Rolltreppe/Stiegen-Präferenz), grundsätzlich denk- und machbar, zumal das auch via Simulatoren realistisch erfolgen kann.
- Auch in Routen-Funktionen sind Tests automatisierbar, allerdings ausschließlich, solange die Ergebnisse stabil via Simulatoren geliefert werden.
- Zur Automatisierung realer Teststellungen, also wenn „echte Devices“ im Live-Einsatz verwendet werden, sind wir aktuell aufgrund der volatilen Ergebnisse noch weit davon entfernt.
Support: Dank der aktiven Mitarbeit des Upstream-Teams sowie der unbürokratischen Unterstützung seitens Wiener Linien (U-Bahnbetreiber) konnten wir so manche Hürde rasch überwinden.
Live-Einsatz in Vorbereitung
War da nicht die Rede von einer U-Bahn-Station? Richtig! Der letzte Schritt unseres Projekts, das Installieren unserer Lösung in einer ersten U-Bahn-Station in Wien, ist aktuell in Vorbereitung und wir können es kaum erwarten, „Mobi“ in der realen Welt zu erleben, wenn es zahlreichen Blinden und sehbehinderten Menschen ein Stück Freiheit wiedergibt, und auch für sehende Menschen einen Mehrwert bringt (Stichwort „hands-free“).
Bis dahin werden wir noch viele weitere wichtige Erfahrungen gewinnen, die für weitere Innovationsprojekte dieser Art sehr wertvoll sein werden. The future is bright!
