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 Ubiquitous Computing

Agenda

• Überblick

• Mobile Geräte

• Backoffice

• Sensoren

11.04.23 Seite 2

Überblick Mobile Geräte Backoffice Sensoren

Ü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 werden automatisch erzeugt+ 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

11.04.23 Seite 13


UsabilityUmsetzung der GUI 2/2

11.04.23 Seite 14


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

11.04.23 Seite 15


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

11.04.23 Seite 16


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

11.04.23 Seite 17


Backoffice

11.04.23 Seite 18


Backoffice

• Warum Entwicklung mit C#.Net?

– Rapid Prototyping

– Natives Look & Feel

– SQL-Server integriert in Entwicklungsumgebung

– Zugriff auf Daten vereinfacht• Keine extra Persistenzschicht/-bibliothek notwendig• Keine Domänenobjekte notwendig

11.04.23 Seite 19


BackofficeDesktop-Applikation

• Auftragsverwaltung und Paketeinlagerung – Vollständigkeitshalber implementiert

• Sensorenkonfiguration– Auf mobilen Testgerät nicht möglich

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

• Auswirkung auf Prozess:– Gegebenenfalls eigene Stelle für Konflikt-Management notwendig– Test zum Bestimmen notwendig, ob Konflikte häufig vorkommen

11.04.23 Seite 20


Backoffice Konflikt-Management

• .

11.04.23 Seite 21


Konflikt-Management 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 22


BackofficeVerbesserungen

• Konfliktkennzeichnung im 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 (Auftragsposition)– Besseres Erkennen, ob Konflikte vorhanden

11.04.23 Seite 23

Konflikt Konflikt gelöst


Sensoren

11.04.23 Seite 24


SensorenAnforderungen

11.04.23 Seite 25

• Drahtlose Übertragung in schwierigem Umfeld

• Möglichst lange Laufzeit– Verschiedene Modi für Energieverbrauch

• Geringe Größe und Gewicht


SensorenAVR Raven

11.04.23 Seite 26

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

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


SensorenAVR Raven

11.04.23 Seite 27


SensorenKonfiguration

11.04.23 Seite 28


SensorenKonfiguration: Message Format

11.04.23 Seite 29

Testformat:

Endgültiges Format:


SensorenDaten

11.04.23 Seite 30


SensorenLive Daten: Message Format

11.04.23 Seite 31

Testformat:



SensorenLog Daten: Message Format

11.04.23 Seite 32

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

Seite 3311.04.23


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)

Seite 3411.04.23


SensorenFazit

± …

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

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

11.04.23 Seite 35


Diskussion

Vielen Dank für eure Aufmerksamkeit!

11.04.23 Seite 36


10-Feb-03 Seite 1 Anton Biller, Matthias Gsteu, Sylvia Nischkowski, Florian Schmid ZigWarehouse...

Documents

Transcript of 10-Feb-03 Seite 1 Anton Biller, Matthias Gsteu, Sylvia Nischkowski, Florian Schmid ZigWarehouse...