10-feb-03 seite 1 anton biller, matthias gsteu, sylvia nischkowski, florian schmid zigwarehouse...

10-Feb-03 Seite 1

Anton Biller, Matthias Gsteu, Sylvia Nischkowski, Florian Schmid

ZigWarehouseEndpräsentation Projekt Ubicomp

Agenda

• Überblick

• Mobile Geräte

• Backoffice

• Sensoren

• Probleme

11.04.23 Seite 2

Überblick Mobile Geräte Backoffice Sensoren Probleme

Überblick

11.04.23 Seite 3


ÜberblickUrsprüngliche Zielsetzung

• Schnitt durch alle Systemteile

• Backoffice– Persistenz

– Synchronisierung mit mobilen Geräten

• Mobile Geräte– Usability

– Synchronisierung mit Backoffice

– Empfangen von Sensordaten

• Paketsensoren– Sensordaten weitergeben

– Protokollierung

– Konfiguration

11.04.23 Seite 4


Mobile Geräte

11.04.23 Seite 5


Mobile GeräteAuswahlkriterien

• Windows Mobile 5• Barcodescanner• WLAN• Bluetooth• RFID (optional)

• 3,8“ Touchscreen• Robuste Bauweise• Gewicht: 709 g• ca. 16h Akkubetrieb• Tastatur (optional)

Motorola MC9090g

11.04.23 Seite 6


Mobile GeräteCharakteristik der Applikation

11.04.23 Seite 7

• Keine permanente Verbindung zum Netzwerk– daher nicht möglich, direkt auf DB zu arbeiten

• Lösung:– lokaler Datenbank-Cache– permanent auf dem Gerät verfügbar– bei Bedarf mit DB synchronisieren (nicht trivial)– bekanntes Problem– Welche bestehenden Technologien / Frameworks gibt es hierzu bereits?


Frameworks für SynchronisierungGegenüberstellung

11.04.23 Seite 8

• Was spricht sonst noch für MS Sync Services?– lt. Fachzeitschrift „dotnet pro“ fixer Bestandteil von CF 3.5– Wird aber eigentlich erst mit SQL Server CE 3.5 installiert– verschiedene Synchronisierungsstrategien möglich (Snapshot, Incremental

download, Upload only, Bidirectional)


Microsoft Sync ServicesBelange

• Soll das clientseitige Schema angelegt werden oder ein bestehendes verwendet werden?

• Welche Tabellen und Spalten sollen synchronisiert werden? (Tradeoff: Implementierungsaufwand Performance)

• Welche Synchronisierungsstrategie soll verwendet werden?

• Welche Konflikte können auftreten? Wie werden diese behandelt?

• Sollen nur bestimmte Daten synchronisiert werden? (Filter Einfluss auf Performance und Konflikte)

• Two-Tier oder N-Tier Modell?

11.04.23 Seite 9


Microsoft Sync ServicesArchitektur

11.04.23 Seite 10


Microsoft Sync ServicesFazit

± Wizards generieren bereits vieles

+ Notwendige Erweiterungen für DB (zusätzl. Spalten, Tombstone-Tables)+ Beteiligte Klassen werden erzeugt (nur noch parametrisieren)+ Providers für SQL Server + SQL Server CE+ N-Tier Modell: Robust gegen plötzliche Verbindungsabbrüche

- Generierung des clientseitigen Datasets schwach!- Zu viel generierter Code erschwert Fehlersuche- N-Tier Modell: Client kann Konflikte nicht erkennen (2. “Kanal” nötig)- Installationsreihenfolge beachten!!!

11.04.23 Seite 11


UsabilityPaper Prototype

11.04.23 Seite 12


UsabilityUmsetzung der GUI 1/2


UsabilityUmsetzung der GUI 2/2


UsabilityEntscheidungen 1/2

• 1. Ansatz:– Synchronisierung durch Benutzer angestoßen

– VT: Benutzer kann entscheiden, wann synchronisiert wird

– VT: Bei Bedarf Update vom Server holen

– NT: Verantwortung für Datenaktualität bei Benutzer

– NT: Benutzer wird damit konfrontiert, dass lokale Daten eine Kopie sind

Für Benutzer sollte es sich so anfühlen, als arbeitete er auf den Echtdaten!

• 2. Ansatz:– Synchronisierung transparent im Hintergrund

– Bei Änderung durch Benutzer: Scheduling eines SyncTasks

– SyncTask wird durchgeführt, wenn Verbindung zum Netzwerk besteht


UsabilityEntscheidungen 2/2

• Applikation startet bei Power-On

• Applikation kann nicht einfach beendet werden (kein Button)

• Forms einheitlich aufgebaut

• Beim Starten: Initialer Sync

• Benutzer kann keine Optionen festlegen Inbetriebnahme

• Explizite Entscheidungen gegen WinMobile UI Guidelines (für Bedienung durch Stylus ausgelegt)

• Einheitliche Funktion von Softkey(s): keine verschachtelten Menüs


UsabilityVerbesserungen

• Unterschiedliche Farbschemen pro „Pfad“

• Zwischen „Pfaden“ hin- und herspringen (kein wiederholtes Betätigen von Zurück-Button)

• Filter asynchron anwenden (Volltextfilter bremst sehr stark): Responsiveness


Backoffice

11.04.23 Seite 18


BackofficeDesktop-Applikation

• Auftragsverwaltung – vollständigkeitshalber implementiert

• Paketeinlagerung und Sensorenkonfiguration– Vollständigkeitshalber implementiert

• Konflikt-Management– Auflösung von Konflikten zwischen Aufträgen– Auflösung von Konflikten zwischen Auftragspositionen

• Auswirkung auf Prozess:– Eigene Person für Konflikt-Management notwendig

– Theoretisch zwei Fälle:• nie Konflikt• dauernd Konflikte

11.04.23 Seite 19


Backoffice Konflikt-Management

• .

11.04.23 Seite 20


Backoffice Entscheidungen

• Konflikt-Management im Backoffice:– Zu komplex für Mobiles Gerät– Lagerarbeiter verfügt nicht über die nötige Kompetenz– Lagerarbeiter soll nicht mit für ihn unnötigen Tätigkeiten belastet

werden

• Usability:– Farbiges Hinterlegen von

• Aufträge und Auftragspositionen– in Konflikt stehend– nicht in Konflikt stehend

• gelöster Konfliktpositionen

– Exklusive Selektion von Werten

– Fertigstellen erst nach Bearbeitung aller Konfliktpositionen möglich

11.04.23 Seite 21


BackofficeVerbesserungen

• Konfliktkennzeichnung in Konflikt-Management mit Icons erweitern

– Wichtig wegen Rot-Grün-Blindheit– Beispiel-Icons:

• Entwicklungshilfe: Schwarz-Weiß-Modus für Oberfläche

• Keine Selektion einer Zeile am Anfang– Besseres Erkennen, ob Konflikte vorhanden

11.04.23 Seite 22

Konflikt Konflikt gelöst


Sensoren

11.04.23 Seite 23

Überblick Mobile Geräte Desktop-Applikation Sensoren Probleme Verbesserungen

SensorenAnforderungen

11.04.23 Seite 24


• Drahtlose Übertragung in schwierigem Umfeld

• Möglichst lange Laufzeit

SensorenAVR Raven

11.04.23 Seite 25


• Stromverbrauch: PicoPower Familiy• 16mbit Serial Dataflash• Demoapplikation vs. BitCloud

• Ideales Gerät:– Ohne Display– Temperaturfühler herausgeführt

SensorenAVR Raven

11.04.23 Seite 26


SensorenKonfiguration

11.04.23 Seite 27


SensorenKonfiguration: Message Format

11.04.23 Seite 28


Testformat:

Endgültiges Format:

SensorenDaten

11.04.23 Seite 29


SensorenLive Daten: Message Format

11.04.23 Seite 30


Testformat:


SensorenLog Daten: Message Format

11.04.23 Seite 31


Testformat:


SensorenLebensdauer

• Simulations-Scripte von Atmel für Stromverbrauch– Bottom-Up (Physikalische und MAC-Schicht)

– Top-Down (Gesamtes Board)

• Top-Down Script ausgelegt für:– AT86RF230 (Funk)

– ATmega1281 (Logik)

• Anpassung für:– AT86RF230 (Funk)

– ATmega3290P (Logik)

– ATmega1284P (Logik)

– Ohne LCD, Speaker und Mikrofon

Lebensdauer: ~5 Monate

SensorenStromverbrauchsberechnung

• Eckdaten für einfache Simulation

– Geschätzte Kapazität: 200 mAh (2 x Knopfzellen)

– Sleep-Mode Zyklus: ~5s

– Applikationslaufzeit (Übernommen): 58 ms

– Sendezeit (Übernommen): 1 ms

– PHY-Payload: 40 Bytes

Stromverbrauch per Zyklus: 243.864 uA/s Lebensdauer: 0.4735 Jahre (5 Monate)

SensorenFazit

± …

+ ...+ ….+ ….+ ….

- ….- ….- ….- ….

11.04.23 Seite 34


Probleme xxx

± …

+ …+ ….+ ….+ ….

- ….- ….- ….- ….

11.04.23 Seite 35


Probleme xxx

11.04.23 Seite 36

• …


Diskussion

Vielen Dank für eure Aufmerksamkeit!

11.04.23 Seite 37

10-feb-03 seite 1 anton biller, matthias gsteu, sylvia nischkowski, florian schmid zigwarehouse...

Documents