Wissensdatenbank

efeuApp

Abbildung 1: Die Begrüßung des Nutzenden in der efeuApp

Die efeuApp ist die zentrale Schnittstelle zwischen Menschen und Maschinen im efeuQuartier. Bei der Entwicklung der App stand ganz klar die Usability im Vordergrund: Das efeuQuartier soll ein Zukunfts-Viertel für jedermann sein. Daher soll auch die efeuApp von jedem leicht bedienbar sein und niemanden vor große Hürden stellen. Die App ist der Punkt, an dem Menschen und Maschinen aufeinandertreffen. Dank intuitiver Bedienbarkeit werden schon hier die Hemmschwellen deutlich gesenkt.

Abbildung 2: Der Startbildschirm
Abbildung 3: Die Ansicht aktueller Aufträge

Paketbestellung leicht gemacht

In der App können die Nutzer stets den aktuellen Status ihrer Bestellungen einsehen. Wird ein neues Paket angekündigt, kann der Nutzer zwischen zwei Optionen wählen: Soll es direkt übergeben werden (synchrone Zustellung), oder will man es lieber zu einem späteren Zeitpunkt von einer Übergabestation abholen (asynchrone Zustellung)?

Dabei zeigt die App dem User zu jedem Zeitpunkt, wo sich der Roboter mit der Bestellung gerade aufhält und wann man mit der Lieferung rechnen kann. Bei der asynchronen Zustellung kann der Nutzer außerdem den Übergabebock auswählen, von dem er das Paket abholen will. Dies geschieht ganz einfach und intuitiv auf einer Karte.

Die Entwicklung der App

Wünsche der Anwohnerinnen und Anwohner im efeuQuartier

Den Anwohnerinnen und Anwohner des efeuQuartiers wurden gezielt Fragen gestellt, die die Funktionsweise der efeuApp betreffen:

  • Ist eine Zustellung oder eine Abholung (von Paketen) gewünscht?
  • Soll der Service direkt am Lieferroboter (synchron) oder über einen Übergabebock (asynchron) erfolgen?
  • Wann soll zugestellt oder abgeholt werden?

Die Ergebnisse der Befragung waren je Auftrag sehr individuell. Sie ergaben dennoch allgemeingültig Standardeinstellungen, die individuell pro Auftrag an das Leben des einzelnen Anwohnenden angepasst werden können.

Abbildung 4: Die Wünsche der Anwohnenden

Anforderungen an die App

KategorieNr.TitelBeschreibung der Anforderung
Abholung01ASAPDer Nutzer kann wählen, dass eine Paketbox zur Abholung so schnell wie möglich geliefert wird. Dann werden etwaige voreingestellte Zeitfenster bei der asynchronen oder synchronen Abholung nicht berücksichtigt, sondern eine ASAP-Lieferung ausgelöst. Der Nutzer hat weiterhin die Möglichkeit, asynchron oder synchron auszuwählen.
02Standardbehälter bzw. Wertstoffbehälter ja / neinEs wird angegeben, ob es sich bei der Abholung um einen Werkstoffbehälter handeln soll. Dazu kann der Nutzer ja / nein, d.h. eine boolische Angabe, machen. Es wird per Checkbox unterschieden, wenn eine neue Abholung in Auftrag gegeben wird.
03Box S / LBeim Anlegen eines neuen Auftrags, d.h. Abholung, gibt ein Feld Auskunft darüber, ob eine große L oder kleine S Box zur Abholung geschickt werden soll.
Auftragsdetails01Aktuelle Roboter- PositionDie Position des Roboters soll unter Details beim Auftrag sichtbar sein. Die Historie gehört nicht dazu.
02Aktuelle Nutzer- PositionDie aktuelle Position des Nutzers wird auf der Karte angezeigt.
03Anzahl ZustellversucheUnter den Auftragsdetails wird die Anzahl der Zustellversuche angezeigt. Dazu steht dort „Anzahl Zustellversuche“ und die jeweilige Anzahl der aktuellen Zustellversuche. Wurde noch kein Zustellversuch unternommen, steht dort „Anzahl Zustellversuche: 1“. Wenn dieser fehlgeschlagen ist und der zweite unternommen wird, steht dort „Anzahl Zustellversuche: 2“.
04StatusEin Fortschrittsbalken gibt Aufschluss über den Status des Auftrags.
Auftrag Ändern01Änderung eines AuftragsDie Details eines Auftrags, d.h. Zeitfenster, Art der Lieferung (asynchron, synchron und bei Lieferung auch Selbstabholung), können solange durch den Kunden geändert werden, wie der Auftrag noch nicht verplant wurde. (Bis zu welchen Auftragsstatus und Zeiträumen Änderungen erlaubt sind, sind als Parameter je Umfeld, also einsatzspezifisch für das efeuLog-System in den Planungskomponenten ggf. je Kunde einzustellen.) 
Auftragsübersicht01Auftrag anzeigenAufträge bestehen technisch aus Teilaufträgen (mehreren Aufträgen), die in der App als ein Auftrag angezeigt werden sollen. Der Auftrag enthält dabei die Information, wie viele Pakete die Box (der Auftrag) enthält.
Dauerabholung01Standardbehälter bzw.
Wertstoffbehälter ja / nein
Es wird für eine Dauerabholung angegeben, ob es sich bei der Abholung um einen Werkstoffbehälter handeln soll. Dazu kann der Nutzer ja / nein, d.h. eine boolische Angabe, machen. Es wird per Checkbox unterschieden, wenn eine neue Dauerabholung beauftragt wird.
02Frequenz angebenEs wird angegeben, von wann bis wann die Dauerabholung erfolgt. Dazu wird der Startzeitpunkt und der Endzeitpunkt (beides inklusive) gewählt sowie ein Wunschzeitfenster innerhalb der Woche, d.h. Wochentag und Zeitfenster an diesem Tag, bspw. montags, 15:30 Uhr – 17:30 Uhr.
03OrdnerType wählenSoll eine Paketbox für Versand regelmäßig empfangen werden, soll der Nutzer auswählen können, ob er die Paketbox (1) synchron oder (2) asynchron zugestellt wird.
04Übergabebock bei asynchroner AbholungDer Nutzer soll bei asynchroner Dauerabholung einen Übergabebock aus der Karte wählen können. Die Angabe ist verpflichtend. Standardmäßig wird der Default des Nutzers voreingetragen, er kann jedoch davon abweichen und einen anderen auswählen.
05SyncMeetingPoint bei synchroner AbholungDer Nutzer soll bei synchroner Dauerabholung einen SyncMeetingPoint aus der Karte wählen können. Die Angabe ist verpflichtend. Standardmäßig wird der Default des Nutzers voreingetragen, er kann jedoch davon abweichen und einen anderen auswählen.
Nutzereinstellungen01Sammelauftrag zulassen Es gibt die Möglichkeit per Checkbox, Kommissionierung von Paketen bei der Zustellung zuzulassen. dies wird in den Nutzereinstellungen hinterlegt. Dort steht „Sammelauftrag zulassen“ und jeweils eine Checkbox, die entweder angeklickt werden kann (JA) oder nicht (NEIN).
02DEFAULT ÜbergabedocksDefault: Beliebig viele Übergabedocks sind als Default konfigurierbar (unabhängig von OrderType (Abholung, Zustellung), gilt jedoch nur für asynchron). Dies wird konfiguriert, damit im Falle einer automatischen Verplanung der Übergabedock gewählt wird, der am besten passt. Es kann unter allen Angaben genau *einer* gewählt werden, der als Default voreingetragen werden soll. Diese Angabe ist nicht erforderlich, aber möglich. Dies kann per Checkbox an- und abgewählt werden.
03DEFAULT synchronen MeetingPointDefault: Es kann (muss jedoch nicht) genau ein synchroner MeetingPoint angegeben werden.
04DEFAULT SyncAvailabilityTimeSlotsDefault: Es können zwei Zeitfenster pro Tag (Mo – So) angegeben werden, was jedoch keine Pflicht ist (SyncAvailabilityTimeslots). Diese werden unabhängig von OrderType gewählt.
05NichtverfügbarkeitEs können Zeiten angegeben werden, zu denen keine Paketboxen geschickt (Abholung) oder geliefert (Zustellung) werden sollen. Dies wird per Zeit-Range angegeben, d.h. von (Tag + Uhrzeit) bis (Tag + Uhrzeit), wobei beides inklusive der Grenzen ist (intern NoAvailabilities).
Registrierung01Dummy-Prozess veranschaulichen (z.B. für Betreiber)Der nutzerseitige Registrierungsprozess für das efeuLog-System wird zum Zeitpunkt der Dokumentation noch zwischen den Partnern detailliert und abgestimmt. Nutzer sollen registriert werden können – z.B. vom Betreiber. Dies soll per Dummy-Prozess veranschaulicht werden, ohne dass es am Ende zu einer Eintragung in die Nutzer-Datenbank kommt. Beispielhaft abzufragende Daten sind E-Mail-Adresse, Vor- und Nachname, Geburtsdatum.
02Registrierung abschließenDie Registrierung neuer Nutzer bzw. die Zusammenstellung der für eine Registrierung not-wendigen Daten soll per App möglich sein.
Support01Link zur WissensdatenbankFAQ und How-to Seite sollen schon vor der Anmeldung erreichbar sein. URL Stand zum Zeitpunkt der Dokumentation „Bedienungsanleitung/ how-to“ Nutzer-App: https://wissen.efeucampus-bruchsal.de/urbane-güterlogistik/efeuapp. Schön wäre, wenn in der App auf die Wissensdatenbank verlinkt würde, z.B. über ein eigenes Icon. URL Stand zum Zeitpunkt der Dokumentation: https://wissen.efeucampus-bruchsal.de
02Telefon und Adresse (des Depots)Adresse und Telefonnummer des Quartiersdepots sollen für Support-Anfragen zur Verfügung stehen (Reiter Support), „Für Rückfragen jeder Art stehen Ihnen die Mitarbeiter gern zur Verfügung. Halten Sie bitte die Auftragsnummer bereit, wenn Sie konkrete Anliegen zu Aufträgen haben.“
03Öffnungszeiten des DepotAnzeige der Öffnungszeiten des Depots.
Zustellung01ASAPDer Nutzer bzw. die Nutzerin kann wählen, dass die Paketbox so schnell wie möglich zugestellt wird. Dann werden etwaige Zeitfenster bei der asynchronen oder synchronen Abholung nicht berücksichtigt, sondern eine ASAP-Lieferung ausgelöst. Der Nutzer bzw. die Nutzerin hat weiterhin die Möglichkeit, asynchron oder synchron auszuwählen.
02Zustellungsart (OrderMode) wählenKommt eine neue Lieferung am Depot an, soll der Nutzer bzw. die Nutzerin auswählen können, ob er/ sie die Paketbox (1) synchron oder (2) asynchron zugestellt haben oder (3) selbst abholen möchte. Dies kann nur ausgewählt werden, bevor die Tour „verplant“ wurde (Tour Status != Fixed). Wurde die Tour mit diesem Paket bereits verplant, ohne dass der Nutzer bzw. die Nutzerin eine explizite Angabe gemacht hat, so wird auf den Default-Wert des/der Nutzenden zurückgegriffen.
(zu Änderungsmöglichkeiten siehe Kategorie „Auftrag Ändern“)
03Stoppen und entsperrenWährend der Zustellung können fahrende Roboter per App unter Details gestoppt und entriegelt werden (wenn das Fahrzeug eine entsprechende Schnittstelle zur Verfügung stellen kann).
04Übergabebock bei asynchroner ZustellungDer Nutzer bzw. die Nutzerin soll bei asynchroner Zustellung einen Übergabebock aus einer Karte wählen können. Die Angabe ist zwingend erforderlich (Pflichtfeld). Der Default „Lieblingsübergabenbock“ wird automatisch eingetragen, sofern er angegeben wurde (dann ist die Pflichtangabe bereits erfüllt). Sofern ein Default voreingetragen wurde, kann der Nutzer bzw. die Nutzerin jedoch davon abweichen und einen andern auswählen.
05SyncMeetingPoint bei synchroner ZustellungDer Nutzer bzw. die Nutzerin soll bei synchroner Zustellung einen SyncMeetingPoint aus der Karte wählen können. Die Angabe ist verpflichtend. Standardmäßig wird der Default des Nutzenden voreingetragen, er bzw. sie kann jedoch davon abweichen und einen anderen auswählen

Um die Anforderungen an die Nutzer-App für den Nutzer bzw. die Nutzerin sinnvoll umzusetzen, wurde ein Usability Konzept erarbeitet.

Usability Konzept als Umsetzungsbasis für die App

Die Umsetzung der Anforderungen in eine Nutzer-App baut auf einem Usability Konzept auf. Richtungsweisend waren dabei zudem Meta-Anforderungen an die Interaktion der Endkunden mit Letzte-Meile Logistiksystemen, welche aus verschiedenen Literaturquellen zusammengetragen wurden.

Insbesondere wurde bei der weiteren Entwicklung nach dem PACT Framework (dargestellt durch Abbildung 1) vorgegangen. Dies ist eine Methode, um potenzielle Situationen (Kontext C) zu beschreiben, in welchen Personen (P) Aktivitäten (A) durchfuhren und eine bestimmte Technologie (T) verwenden (vgl. Benyon, 2010, S. 25). 

Mithilfe von diesen definierten Szenarios, sollen HCI-Designerinnen und Designer das Wissen über die Nutzenden ihres Produktes oder Systems gewinnen, welches notwendig ist, um für den Benutzer bzw. die Benutzerin Mehrwert bringende und effektive Designs zu erstellen. Dazu müssen die Designerinnen und Designer verstehen, welche Aktivitäten die Benutzerinnen und Benutzer durchfuhren möchten und in welchem Kontext diese Aktivität stattfindet. Um erfolgreich ein Interaktives System zu gestalten, ist Wissen der Designerinnen und Designer auch über Eigenschaften dieser notwendig, sowie über den Umgang mit der Gestaltung von Interaktiven Systemen. (vgl. Benyon, 2010, S. 25)

Die Entwicklung erfolgt daraufhin in vier Phasen: 

Phase 1.1: Aufstellen von Szenarien

Abgeleitet von den identifizierten Anforderungen, werden sogenannte Szenarien aufgestellt, welche es der Designerin oder dem Designer ermöglichen, Wissen über die verschiedenen Benutzer und den Kontext ihres Produktes zu erhalten und speziell auf dieses ein zugeschnittenes Produkt zu erarbeiten. Szenarien verringern ebenfalls die Anzahl der benötigten Iterationsschritte, bis das Produkt für den Endkunden bzw. die Endkundin nutzbar ist und einen signifikanten Mehrwert liefert. Spezifisch für die Einbindung von Nutzenden in das efeuLog-System bedeutet dies, Szenarien zu entwerfen, welche das typische Benutzerverhalten der Endkunden (EK) beschreiben.

Phase 1.2: Aufstellen von Use Cases

Durch die Definition der Szenarien werden Situationen beschrieben, in welchen der Endkunde bzw. die Endkundin potenziell die einzuführende Technologie und deren Funktionen nutzen wird. Um diese Szenarien auf einer höheren Abstraktionsebene betrachten zu können, werden diese im nächsten Schritt zu Use-Case Szenarien aufgestellt. Sie bündeln somit potenzielle Szenarien, welche bei Verwendung des Systems durch den Endkunden bzw. die Endkundin eintreten können, um ein bestimmtes fachliches Ziel zu erreichen. Dabei wird die inhaltliche Ausführung von konkreten technischen Lösungen abstrahiert

Phase 2: Informationsarchitektur

Im Zentrum der Phase der Informationsarchitektur steht das Ziel, die benötigten Informationen der verschiedenen Stakeholder (SH) zu identifizieren und eine Datenarchitektur zu entwerfen. Die Basis dafür bilden die Ergebnisse aus den vorherigen Abschnitten. Es wird definiert, welcher Input von welchem EK notwendig ist, um die Prozesse des efeuCampus bedienen zu können. Damit die benötigten Informationen in der Reihenfolge vom System angefordert werden, in welcher die Benutzenden die Informationen benötigen, werden Prozesse definiert. Die Ergebnisse dieser Phase dienen als Grundlage für weitere Designaktivitäten, da benötigter Input festgelegt wird und die Reihenfolge der Interaktion, in welcher diese dem EK präsentiert werden. (Lewis.1994).

Phase 3: Wahrnehmungsphase

Nach Vorgehensweise von Lewis (1994) werden im Folgenden bestehende digitale Services, welche einen verwandten Sachverhalt zum efeuLog abbilden, auf Designelemente untersucht, Gemeinsamkeiten und eventuelle Standards identifiziert und innerhalb eines Style Guides zusammengefasst. Durch diesen Prozessschritt soll sichergestellt werden, dass die prototypische Nutzer-App dem EK eine Experience bietet (User Experience) und intuitiv zu bedienen ist.

Phase 4: Entwurfsphase

Nach Maedche (2012) sind die Phasen Entwurf und Validierung in einer UCD-Vorgehensweise eng miteinander verbunden. Nach einer Design- Phase werden diese Phasen gemeinsam validiert und darauffolgend Verbesserungen eingearbeitet, so lange bis definierte Zielwerte erreicht sind. (Maedche 2012).

Ziel der Entwurfsphase ist, erste Prototypen in Papierform zu erstellen, iterativ zu verbessern und folgend das erarbeitete UI in Form eines digitalen, klickbaren Prototyps zu erstellen und zu validieren. Diese Tests erfolgen unter Einsatz der Think Aloud- Methode mit prototypischen Benutzerinnen und Benutzern des Systems, sowie nachfolgenden strukturierten Interviews, unter Einsatz eines Fragebogens zur Abfrage der erlebten Usability und User Experience des Produktes. Dies geschieht unter Einsatz einer SUS und UEQ. Das konzipierte UI wird durch Einsatz dieser Metriken quantitativ bewertet und in Relation zu standardisierten Kennzahlen gesetzt. (Lewis.1994)

Umsetzung der Nutzer-App im efeu-Corporate Design

Parallel zur Fortentwicklung der Verhaltenslogik vordefinierter Features und auf Basis der Mock-Ups wird die efeuApp im Corporate Design des Projekts umgesetzt und integriert.

Die Adaption soll sicherstellen, dass auch die efeuApp in einem einheitlichen Corporate Design entworfen, entwickelt und bereitgestellt wird und sich so gestalterisch nahtlos in die IT-Systemlandschaft von efeuCampus integriert.

Dies kann insbesondere den Bewohnerinnen und Bewohnern des Quartiers eine saubere und ganzheitliche Integration der efeuApp in das efeuCampus-System vermitteln. Dabei erfolgt nicht nur die rein gestalterische Adaption des efeuCampus-Corporate Designs, sondern auch die technische Umsetzung des Designs in ReactJs-Komponenten und die Integration dieser in die efeuApp.

Abbildung 5: Ansicht in der App bei asynchroner Zustellung
Abbildung 6: Ansicht in der App bei synchroner Zustellung

Datenschutzrechtliche Anforderungen
& angrenzende Rechtsgebiete des autonomen Fahrens

Zu einer mobilen App und unseren autonomen Transportfahrzeugen gehört natürlich auch der Schutz der Daten der Nutzenden. Außerdem gibt es angrenzende Rechtsfelder wie das Straßen- und Zulassungsrecht- unser Fahrzeug ist schließlich ein Verkehrsteilnehmer- und das Haftungsrecht. Hierzu entwickelte das FZI Forschungszentrum Informatik eine Modulartige Struktur mit den Datenschutzfelder, die für das Projekt efeuCampus relevant sind.

Die Modulstruktur

Modul: Datenschutz

  • Einführung in den regulativen Rahmen des Datenschutzes aus Betreiberperspektive:
    Datenschutzgrundsätze, Einführung in Ermächtigungsgrundlagen; Verantwortungsabgrenzung
  • Fragebogen zur Ermittlung konkreter Datenverarbeitungsszenarien des efeuCampus als Anwendungsfallanalyse urbaner, automatisierter Güterlogistik
  • Rechtliche Betrachtung des technischen Datenschutzes bei autonomen Liefersystemen:
    Privacy by Design und by Default
    (Auswertung der Fragebögen: u.a. Zweck, Dauer, Beteiligte)
    • Systemkomponenten
    • Partner
  • Datenschutzrechtliche Konkretisierungen:
    u.a. Rechtfertigungsgründe der Einwilligung sowie der Interessenabwägung bei neuartigen Lieferkonzepten am Beispiel der Videokameras

Modul: Straßenverkehrs- und Zulassungsrecht

  • Rechtsrahmen zum automatisierten Fahren
  • Zulassungsvoraussetzungen für einen autonomen Lieferroboter
  • Erfahrungsberichte vergleichbarer Projekte
  • Nutzung der Straße als Normal- oder Sondernutzung

Modul: Haftungsrecht

  • Haftungsrechtliche Fragen zu Besonderheiten des autonomen Fahrens im Zusammenhang mit urbaner Gütelogistik:
    Darstellung des aktuellen Rechtsrahmens
  • Haftungsrechtliche Fragen bezüglich des Lieferdienstes: Haftungsrechtliche Besonderheiten am Beispiel der Behälteröffnung