Diplombericht Kartenloser Datenaustausch der LSVA

Eidgenössisches Finanzdepartement EFD
Eidgenössische Zollverwaltung EZV
Oberzolldirektion
Sektion LSVA 1
Diplombericht
Kartenloser Datenaustausch der
LSVA-Deklarationsdaten (BLUDEC)
Version:
1.0 vom 31.05.2007
Diplomarbeit B37.07 / Klasse B37 / Software Schule-Schweiz
Betreuer:
Christian Hennecke
Oberzolldirektion, Sektion LSVA 1
Gutenbergstrass 50, 3003 Bern
Tel. 031 323 07 81
Experte:
Andres Scheidegger
GLUE Software Engineering AG
Zieglerstrasse 34, 3007 Bern
Tel. 031 385 30 32
Diplomand:
Paolo Dünner
Oberzolldirektion, Sektion LSVA 1
Gutenbergstrass 50, 3003 Bern
Tel. 031 323 17 55
Abstract:
Es wird eine Applikation für Standard-Mobilgeräte (Handy, PDA) für den Datenaustausch zwischen einem Erfassungsgerät mit Bluetooth-Schnittstelle und
einer PC-Applikation mit Internetschnittstelle entwickelt.
Das Programm wird als MIDlet realisiert, so dass es in einer Java MIDP2.0
Laufzeitumgebung ausgeführt werden kann.
Keywords:
J2ME, Bluetooth, FTP, HTTP, SOAP
DA_Bericht_BLUDEC.doc
S LSVA 1
1 Management Summary
Mit dieser Arbeit konnte der Nachweis erbracht werden, dass sich das Konzept der kartenlosen Deklaration in die Praxis umsetzten lässt und die im Pflichtenheft festgelegen Technologien für diese Anwendung geeignet sind.
Das iterative Entwicklungsvorgehen wurde für diese Aufgabenstellung (Prototypenentwicklung mit vielen Unbekannten) als sehr zweckmässig empfunden. Es minimiert das Risiko,
eine Fehlentwicklung (zu) spät zu erkennen. Nach Abschluss der Prototypenphase muss
aber unbedingt vermieden werden, die Weiterentwicklung bis zum Produkt auf Basis des
Prototypen durchzuführen. Für eine Produktentwicklung wird der iterative Design als ungenügend eingestuft.
Es wurde die Erfahrung gemacht, dass die Java Micro Edition Technologie noch nicht in allen Punkten genügend vollständig spezifiziert ist. Dies hat als Konsequenz, dass die Entwicklung mit dieser Technologie sehr viel Erfahrung erfordert und sehr defensiv entwickelt
werden muss. Für die Entwicklung eins kommerziellen Produkts ist zu berücksichtigen, dass
die Unterstützung verschiedener Geräte einen nicht zu unterschätzenden Testaufwand zur
Folge hat.
Es hat sich herausgestellt, dass die im Pflichtenheft definierten Ziele zu hoch gesteckt waren. So konnten nicht alle definierten Funktionen vollständig implementiert werden. Auf die
Realisierung der „soll“ Anforderungen musste vollständig verzichten werden und die Softwarearchitektur konnte nicht überarbeitet werden.
2/44
DA_Bericht_BLUDEC.doc
S LSVA 1
2 Inhaltsverzeichnis
1
Management Summary ..............................................................................................2
2
Inhaltsverzeichnis .......................................................................................................3
3
3.1
3.2
3.3
Übersicht.....................................................................................................................5
Sinn und Zweck......................................................................................................5
Abgrenzung............................................................................................................5
Leserkreis...............................................................................................................5
4
Werdegang des Dokuments .......................................................................................5
5
5.1
5.2
Einleitung und Übersicht.............................................................................................6
Beschreibung des Produkts ...................................................................................6
Herausforderung ....................................................................................................8
6
6.1
6.1.1
6.1.2
6.2
6.2.1
6.2.2
6.2.3
6.2.4
Technologien ..............................................................................................................9
Bluetooth ................................................................................................................9
Die Bluetooth-Funk Technologie .......................................................................9
Bluetooth Protkoll-Stack-Architektur................................................................12
Java 2 Micro Edition.............................................................................................14
Produktepalette der durch J2ME unterstützten Endgeräte..............................16
J2ME Konfigurationen und Profile ...................................................................17
Anwendung BLUDEC ......................................................................................19
Alternativen zu Java 2 ME...............................................................................19
7
7.1
7.1.1
7.1.2
7.1.3
7.2
7.2.1
7.2.2
7.3
7.3.1
7.3.2
7.4
7.4.1
7.4.2
7.4.3
7.4.4
Analyse .....................................................................................................................21
OBU Simulator .....................................................................................................21
OBU Simulator als MIDlet................................................................................21
OBU Simulator als Java Standard Edition Applikation ....................................22
Zusammenfassung Erkenntnisse OBU Simulator ...........................................22
FZHSW Simulation...............................................................................................23
Beschreibung der FZHSW Simulation.............................................................23
Erkenntnisse FZHSW Simulation ....................................................................23
BLUDEC Demonstrator........................................................................................23
Beschreibung Vorgehen ..................................................................................23
Erkenntnisse Entwicklung BLUDEC ................................................................24
Klassendiagramme aus den Iterationen A und B.................................................25
BLUDEC OBEX Client.....................................................................................25
OBEX Server ...................................................................................................26
WebService Client ...........................................................................................27
Skizze des Kommunikationsschnittstelle zur OBU ..........................................28
8
8.1
8.2
8.3
8.3.1
8.3.2
8.3.3
8.3.4
Design und Implementierung....................................................................................29
Grundsätze und Annahmen .................................................................................29
Vorgehen..............................................................................................................29
Softwarearchitektur ..............................................................................................30
Klassenmodell .................................................................................................30
Beschreibung der Klassen...............................................................................31
Package Diagram ............................................................................................33
Sequenzdiagramm eines Imageaustausch mit der OBU.................................34
9
Test...........................................................................................................................34
10
Erreichte Ziele...........................................................................................................35
11
Ausblick ....................................................................................................................35
12
Schlusswort ..............................................................................................................36
A
Anhang .....................................................................................................................37
3/44
DA_Bericht_BLUDEC.doc
S LSVA 1
A.1
A.2
A.3
A.3.1
A.3.2
A.3.3
A.3.4
A.4
A.4.1
A.4.2
A.5
A.6
Literaturverzeichnis ..............................................................................................37
Abbildungsverzeichnis .........................................................................................38
Einrichten der Entwicklungsumgebung ................................................................39
Eclipse .............................................................................................................39
Java ME Wireless Toolkit: ...............................................................................39
JavaME Plugin.................................................................................................39
Tools................................................................................................................39
Einrichten des Entwicklungssystems ...................................................................40
FZHSW Simulation ..........................................................................................40
WebServer für OTA Provisioning ....................................................................40
Programmieren mit Java Micro Editon .................................................................40
Kurzanleitung BLUDEC Demonstrator.................................................................43
4/44
DA_Bericht_BLUDEC.doc
S LSVA 1
3 Übersicht
3.1 Sinn und Zweck
Dieser Bericht dokumentiert die Entwicklung einer mobilen Applikation für die „kartenlose
Deklaration“ der LSVA Erfassungsdaten. Die mobile Applikation für die „kartenlose Deklaration“ der LSVA Erfassungsdaten ist im Rahmen einer Diplomarbeit der Software Schule
Schweiz entstanden.
Das Thema der Diplomarbeit ist motiviert durch den Wunsch, Software für die Optimierung
betrieblicher Abläufe zu entwickeln. Ermöglicht wird die Optimierung durch ein geändertes
technologisches Umfeld auf der Basis der Bluetooth Kommunikations- Technologie und der
Verfügbarkeit von Internet Services auf Mobiltelefonen.
Dieser Bericht dokumentiert die verwendeten technologischen Grundlagen, das methodische
und praktische Vorgehen und die gewonnen Erkenntnisse und Erfahrungen beim Design und
der Realisierung der mobilen Applikation für die „kartenlose Deklaration“ der LSVA Erfassungsdaten.
3.2
Abgrenzung
Der erste Teil der Arbeit bestand im Verfassen des Pflichtenheftes der Diplomarbeit und des
zu entwickelnden Produktes. Ein grosser Teil der Analysearbeit wurde bereits in diesem Zusammenhang durchgeführt. Dieser Teil der Analyse ist im Pflichtenheft dokumentiert. Der
Inhalt des Pflichtenheftes wird in diesem Bericht nicht wiederholt.
3.3
Leserkreis
Dieses Dokument richtet sich an den Experten der Diplomarbeit, an den Auftrageber der Arbeit, den Betreuer der Arbeit sowie alle weiteren interessierten Personen. Vom Leser wird
die Kenntnis des Pflichtenheftes und ein technisches Verständnis erwartet. Auf ein Begriffund Abkürzungsverzeichnis wird deshalb bewusst verzichtet. Wo nötig werden Begriffe und
Abkürzung direkt im Text oder in einer Fussnote erklärt.
4 Werdegang des Dokuments
Ver.
1.0
Datum
Änderung
Autor
31.05.07
Erstellung Dokument
Paolo
Dünner
Freigabe
5/44
DA_Bericht_BLUDEC.doc
S LSVA 1
5 Einleitung und Übersicht
5.1 Beschreibung des Produkts
Mit Hilfe des BLUDEC1 und einem Mobilgerät mit Internetzugang und Bluetoothschnittstelle
kann der Fahrzeugführer die LSVA Erfassungsdaten aus dem Erfassungsgerät (OBU) im
Fahrzeug auslesen und elektronisch zur Fahrzeughaltersoftware am Standort des Fahrzeughalters übermitteln. Die übermittelten Erfassungsdaten werden in der Fahrzeughaltersoftware gespeichert.
Der BLUDEC Demonstrator dient der Systembetreiberin zu Test- und Demonstrationszwecken für diese neue Art der Übermittelung.
Mit Hilfe der Fahrzeughaltersoftware, einer PC Applikation, kann der Fahrzeughalter die gespeicherten Erfassungsdaten einsehen, weiterverarbeiten (z.B. für buchhalterische Zwecke)
oder per Internet an das Hintergrundsystem der LSVA senden, wo die Berechnung der Abgabe erfolgt.
Der Datenaustausch zwischen der OBU und dem Hintergrundsystem erfolgt in Form von
Aufträgen und Meldungen die in so genannte LSVA-Datenimages (Images) verpackten sind.
Die Systemübersicht auf der nächsten Seite stellt die Zusammenhänge bildlich dar.
IST – System
Für die Übertragung der Erfassungsdaten zwischen dem Erfassungsgerät (OBU) und der
Fahrzeughaltersoftware (FZHSW) wird eine 16kB Speicher-Chipkarte (Chipkarte) verwendet.
Die Chipkarte dient als Transportmedium für die LSVA Aufträge und Meldungen.
SOLL – System
Für die Übertragung der Erfassungsdaten zwischen dem Erfassungsgerät und der Fahrzeughaltersoftware (FZHSW) wird eine Netzwerkverbindung verwendet. Zu diesem Zweck ist
die OBU mit einer Bluetooth Schnittstelle und die FZHSW mit einem Imageserver als Datenschnittstelle ausgestattet. Die Aufträge an die OBU und die Meldungen von der OBU werden
über eine Netzwerkverbindung, die zwischen OBU und der FZHSW aufgebaut wird, ausgetauscht. Als Gateway dient ein Mobilgerät, das mit einer Bluetooth und einer Internet Schnittstelle z.B. auf Basis von GPRS oder WLAN und der Applikationssoftware, dem BLUDEC,
ausgerüstet ist.
1
„BLUDEC Demonstrator“ (BLUDEC = Bluetooth Declaration System)
6/44
DA_Bericht_BLUDEC.doc
S LSVA 1
SOLL - System
Internet
Internet
Mobilgerät
Bluetooth
CH-OBU-2
Fahrzeughalter-
Erfassungsgerät
software
Hintergrundsystem
Chipkarte
IST - System
Abbildung 1: Systemübersicht
7/44
DA_Bericht_BLUDEC.doc
S LSVA 1
5.2
Herausforderung
Das Kommunikationsumfeld des BLUDEC mit zwei grundsätzlich verschiedenen Kommunikationsschnittstellen mit jeweils grundlegend verschiedenen Protokollstacks mit ihren vielfältigen Variablen und Unsicherheiten stellt die grundlegende Herausforderung des Themas
dar.
Die Bluetooth Technologie und die Software Entwicklung für Mobilgeräte sind neu für den
Verfasser. Ein wesentlicher Teil der Aufgabe umfasst den Aufbau des benötigten technologischen Wissens, das Sammeln von methodischen Erfahrungen und deren Anwendung in die
Entwicklung des BLUDEC.
Das Umsystem der Entwicklung (das Erfassungsgerät und die FZHSW) befinden sich
momentan noch in der Realisierungsphase und steht noch nicht für Systemtests zur
Verfügung. Die Kommunikationsschnittstellen und die Software, die die Schnittstellen
bedient, können also nur simuliert werden. Im Rahmen der Diplomarbeit wurden die
benötigten Simulationen erstellt und in die entsprechenden Simulationsumgebungen
integriert.
Die für den BLUDEC Demonstrator benötigten Schnittstellendefinitionen sind noch nicht finalisiert. Die vorgelegte Version des BLUDEC wurde auf der Basis von „plausiblen“ Schnittstellenspezifikationen entwickelt. Aufgrund dieses Vorgehens konnte die zugrunde liegende
Technologie kennen gelernt und die eigentliche Applikation entwickelt werden.
Es ist möglich und wahrscheinlich, dass der BLUDEC Demonstrator an die finalisierten Spezifikationen der Schnittstellen angepasst werden muss.
8/44
DA_Bericht_BLUDEC.doc
S LSVA 1
6 Technologien
Dieses Kapitel stellt eine Einführung in die begrifflichen und in die technologischen Grundlagen des BLUDEC dar. Dabei werden die entsprechenden Themen in Umfang und Detail nur
so weit behandelt, wie es zum Verständnis dieser Arbeit nötig ist. Für eine tiefergreifende
Auseinandersetzung mit den Themen wird an dieser Stelle an die entsprechende Fachliteratur [A.1] verwiesen.
6.1
Bluetooth
6.1.1
Die Bluetooth-Funk Technologie
Bluetooth ist ein Industriestandard für die drahtlose Vernetzung von Geräten über kurze Distanz und bietet eine drahtlose Schnittstelle, über die sowohl mobile Kleingeräte wie Mobiltelefone und PDA2 als auch Computer und Peripheriegeräte miteinander kommunizieren können. Hauptzweck von Bluetooth ist das Ersetzen von Kabelverbindungen zwischen Geräten.
Die Technik dient vorrangig zur Realisierung von Ad-hoc-Pikonetzen, die eine sehr geringe
räumliche Ausdehnung von wenigen Metern haben.
Bluetooth sendet - wie viele andere Standards auch - im unregulierten lizenzfreien ISMBand3 im Frequenzbereich um 2,4 GHz, welcher mit gewissen nationalen Einschränkungen
weltweit zur Verfügung steht.
Grundlage für die Funktionsweise von Bluetooth ist das so genannte ”Frequency Hopping
Spread Spectrum” (Frequenzsprungverfahren). Dabei werden 79 Kanäle innerhalb des Frequenzbandes zur Kommunikation verwendet. Ein Zufallsgenerator bestimmt die Folge der
Frequenzen, auf die gewechselt wird. Damit unterschiedliche Geräte miteinander kommunizieren können, müssen sie die Reihenfolge und die Zeitspanne für die Nutzung einer Frequenz kennen. Die beteiligten Geräte müssen also den gleichen Startparameter erhalten,
damit sie synchron bleiben können. Durch diesen Wechsel wird die Verbindung robust gegenüber Störungen auf einzelnen Frequenzen und ein Abhören der Daten wird erschwert.
Die theoretischen Reichweiten und Sendeleistungen für Bluetooth-Geräte sind:
Klasse I:
100 mW,
100 m
Klasse II:
2.5 mW,
20 m
Klasse III:
1 mW,
10 m
Die Angaben der theoretischen Reichweiten sind mit Vorsicht zu geniessen, da sie den Einfluss der Antenne nicht berücksichtigen.
Mit einem modifizierten Bluetooth-USB-Adapter mit Richtfunkantenne soll es sogar möglich
sein, ein Bluetooth-Handy bei Sichtkontakt noch aus etwa 1,6 km Entfernung anzusprechen
(http://www.golem.de/0408/32854.html)
Bluetooth unterstützt seit der Version 1.0 zwei Sprach- und Datenübertragungsdienste:
2
Personal Digital Assistant
das ISM-Band (Industrial, Scientific, and Medical Band) ist ein Frequenzbereich für HochfrequenzSendegeräte in Industrie, Wissenschaft und Medizin, der nicht der staatlichen Regulierung unterliegt und
lizenzfrei genutzt werden darf
3
9/44
DA_Bericht_BLUDEC.doc
S LSVA 1
•
Eine asynchrone Datenübermittlung, ein verbindungsloser Dienst, welcher paketvermittelte Übertragung anbietet. Ist die Vollständigkeit der Übertragung von Wichtigkeit,
so wird diese Methode verwendet. Zusätzlich kann unterschieden werden in asymmetrische Verbindungen, mit Geschwindigkeiten von bis zu 723,2 kbit/s in eine, beziehungsweise 57,6 kbit/s in die andere Richtung und symmetrische Verbindungen,
mit Geschwindigkeiten von bis zu 433,9 kbit/s in beide Richtungen.
•
Eine synchrone Datenübermittlung, ein verbindungsorientierter Dienst, welcher symmetrische, leitungsvermittelte Dienstkanäle bietet. Für zeitkritische Anwendung, wie
zum Beispiel der Sprachübertragung, wird diese Art der Kommunikation verwendet.
Hier ist die Reihenfolge der Daten wichtiger als die Vollständigkeit - lieber ein abgehacktes Gespräch als ein Gespräch mit vertauschten Stimmenlauten. Die Nutzung
von maximal drei paralllen Kanälen mit einer Datenübertragungsgeschwindigkeit bis
zu 64 kbit/s ist möglich.
Im aktuellen Bluetooth-Standard Version 2 - auch mit EDR (Enhanced Data Rate) betitelt sind bis zu drei mal höhere Datenübertragungsgeschwindigkeiten – also bis zu 2.3 Mbit/s möglich. Die verschiedenen Versionen sind zueinander kompatibel.
Bluetooth stellt unter anderem auch Schutzmechanismen für die Datenübertragung zur Verfügung, die aus Verschlüsselungs- und Authentifizierungsverfahren bestehen.
Bluetooth-Geräte, die sich in gegenseitiger Reichweite befinden, können eine Kommunikationsverbindung aufbauen, ohne dass weitere Geräte oder eine zentrale Administration notwendig sind. Ein solches auch als Piconet bezeichnetes Netzwerk kann aus zwei bis maximal acht aktiv kommunizierenden Teilnehmern bestehen, wobei sich die Geräte die Bandbreite teilen. Ein ausgezeichnetes Gerät (meist das Gerät, welches die Verbindungsaufnahme initiiert), der sog. Master, regelt den Zugriff auf die Funkschnittstelle. Die weiteren Geräte
(Slaves) sind nicht direkt, sondern über den Master miteinander verbunden. Im Fall einer
Überlappung solcher Piconets ist es einem Gerät möglich, Teilnehmer mehrerer Netze zu
sein und man spricht von einem Scatternet. Abbildung 2 zeigt solche Szenarien. Bis zu zehn
Piconets können sich ohne gegenseitige Störungen überlagern (Schiller 2000).
Abbildung 2: Beispiele für Piconets und Scatternets
10/44
DA_Bericht_BLUDEC.doc
S LSVA 1
Der Aufbau einer Bluetoothverbindung gliedert sich in drei Stufen:
1. Inquiry:
Dabei wird der bereitstehende Funkraum nach kommunikationsbereiten Geräten abgesucht.
Wird eines gefunden, so werden Informationen über die Zeittakte und die Zugehörigkeit zur
Geräteklasse ausgetauscht. Soll nun eine Verbindung aufgebaut werden, so wird vom Sender der Inquiry die Paging Prozedur angestossen.
2. Paging:
Darunter versteht man den eigentlichen Verbindungsaufbau. Es werden die Frequenzfolge,
der Zeittakt, sowie die Master- und Slaverolle festgelegt. Der Slave erhält eine Active Member Address, mittels dieser er Datenpakete an den Master senden kann.
3. Pairing:
Beim Pairing wird eine Zutrittsberechtigung zum Piconet in Form eines 128 bit langen
Schlüssels erstellt. Dieser wird ebenfalls, durch einen bei der Initialisierung einmalig erzeugten Schlüssel, verschlüsselt übersandt und auf beiden Geräten gespeichert. Für eine sichere
Datenübertragung wird auf Basis des Zutrittsberechtigungsschlüssels eine Verschlüsselung
initialisiert. Die Adressierung zwischen den Bluetoothgeräten erfolgt, ähnlich den Ethernet
Netzwerkkarten, über eine weltweit eindeutige 48 bit lange Gerätekennung.
Anwendung BLUDEC:
Diese drei Stuften des Verbindungsaufbaus verbergen sich hinter der BLUDEC Funktion
Bluetooth Verbindungsaufbau.
11/44
DA_Bericht_BLUDEC.doc
S LSVA 1
6.1.2
Bluetooth Protkoll-Stack-Architektur
6.1.2.1 Einführung
Dieser Abschnitte bietet einen kurzen Überblick über den Bluetooth-Protokoll-Stack. Der
Bluetooth-Protokoll-Stack kann allgemein in zwei Komponenten eingeteilt werden: den Bluetooth Host und den Bluetooth Controller (oder auch Bluetooth Funkmodul). Das Host Controller Interface (HCI) stellt eine standardisierte Schnittstelle zwischen Host und Controller bereit. Diese Klassifikation wird in der Abbildung 3 illustriert. Der Bluetooth Host wird auch als
Upper-Layer-Stack bezeichnet und ist üblicherweise als Software implementiert und in die
System-Software oder das Betriebssystem integriert. Bluetooth Profile setzen auf diese Protokolle auf. Beim Bluetooth Controller handelt es sich normalerweise um ein Hardwaremodul,
das einen festen Bestandteil des Systems bildet oder über USB, PCMCIA, UART, etc. mit
dem System verbunden wird. In einigen Geräten sind sowohl Controller als auch Host fest
integriert und das HCI wird nicht für eine Verbindung dieser benutzt. Ein Beispiel hierfür sind
die mittlerweile weit verbreiteten Headsets, die als Freisprecheinrichtung mittels Bluetooth an
ein Mobiltelefon gekoppelt werden. Einige der in Abbildung 3 dargestellten Bestandteile des
Bluetooth-Stacks werden im Folgenden näher erläutert.
Abbildung 3: Bluetooth Host und Controller Klassifikation
6.1.2.2 Bluetooth-Protokolle
In der Bluetooth Spezifikation sind mehrere Protokolle definiert, Abbildung 4 zeigt die gebräuchlichsten als Blockdiagramm des Bluetooth Protokoll-Stacks. Die schattierten Blöcke
repräsentieren die Protokolle, die von den Java APIs für Bluetooth Wireless Technology
(JABWT) adressiert werden. Der Protokoll-Stack baut sich aus Bluetooth-spezfischen Protokollen, wie z.B. dem Service Discovery Protokoll (SDP) und anderen, adaptierten Protokollen, wie z.B. dem Object Exchange Protokoll (OBEX) auf. Die einzelnen Schichten und Protokolle sollen im Folgenden kurz beschrieben werden.
12/44
DA_Bericht_BLUDEC.doc
S LSVA 1
Abbildung 4: Bluetooth-Protokoll-Stack
Bluetooth radio ist die unterste in der Bluetooth-Spezifikation definierte Schicht und bestimmt
die Anforderungen des Bluetooth Sende- und Empfangsgerätes für den Betrieb auf dem 2,4GHz ISM Band bezüglich Modulationen und Sendeleistungen. Diese Schicht entspricht im
Wesentlichen der Bitübertragungsschicht des OSI-Modells4.
Die Schicht Baseband and Link Control ermöglicht die physikalische Funkverbindung zwischen Bluetooth-Einheiten. Sie ist zuständig für die Abwicklung der Funkkanäle und die zeitliche Koordinierung, setzt die Pakete für die Übertragung zusammen und synchronisiert sie.
Dabei werden zwei Arten von physikalischen Verbindungen unterstützt: Ein synchroner, verbindungsorientierter Anschluss (SCO, synchronous connection oriented) und ein asynchroner, verbindungsloser Anschluss (ACL, asynchronous connectionless).
Audio stellt keine Schicht des Protokoll-Stacks im eigentlichen Sinn dar, sondern wird bei der
Bluetooth-Kommunikation eigenständig behandelt. Reine Audiodaten werden typischerweise
über eine SCO-Verbindung direkt zu und von der Baseband-Schicht geleitet.
Das Link Manager Protocol (LMP) ist verantwortlich für den Verbindungsaufbau und die Konfiguration einer solchen Verbindung zwischen Bluetooth-Geräten und handhabt Sicherheitsaspekte wie Authentisierung und Verschlüsselung.
Das Logical Link Control and Adaptation Protocol (L2CAP) schirmt in der Stack-Architektur
weiter oben liegende Protokolle von den Details der unteren Protokolle ab und ermöglicht
das Multiplexen zwischen verschiedenen logischen Verbindungen, die durch höher angesiedelte Schichten initiiert wurden.
SDP stellt Applikationen ein Hilfsmittel bereit, um Bluetooth Services und deren Charakteristiken zu erkunden. Im Gegensatz zu einer üblichen LAN5-Verbindung, bei der zuerst eine
4
Das OSI-Modell (engl. Open Systems Interconnection Reference Model) beschreibt modellhaft eine Art der
Datenübertragung für die Kommunikation offener, informationsverarbeitender System.
5
Local Area Network
13/44
DA_Bericht_BLUDEC.doc
S LSVA 1
Verbindung mit dem Netzwerk und dann das Auffinden von Geräten stattfindet, werden in
einer Bluetooth-Umgebung zuerst die Geräte und erst dann die Dienste gefunden. Zusätzlich
gestaltet sich das Angebot an Diensten dynamisch, wenn sich die Geräte in Bewegung befinden und sich die Umgebung dadurch verändert. SDP setzt auf L2CAP auf.
Serielle Ports sind eine der am weitesten verbreiteten Schnittstellen bei Computern und
Kommunikationsgeräten. Mit dem RFCOMM Protokoll können solche seriellen Verbindungen
über L2CAP emuliert werden. Mit RFCOMM sind mehrere gleichzeitige Verbindungen zu
einem Gerät und zu unterschiedlichen Geräten möglich.
Damit Bluetooth-Geräte in einem Netzwerk interagieren und Informationen austauschen
können, muss ein allgemeines Paketformat definiert werden, um die unterschiedlichen Netzwerkprotokolle zu kapseln. Das Bluetooth Network Encapsulation Protocol (BNEP) kapselt
Pakete diverser Netzwerkprotokolle und transportiert diese direkt über L2CAP. BNEP ist ein
optionales Protokoll, das nach der Bluetooth-Spezifikation Version 1.1 entwickelt wurde und
auf dieser Version basiert.
Die Telephony Control Protocol Spezification (TCS binary) definiert die Kontrollsignale für
den Aufbau, Abbau und Verlauf einer Verbindung bei Sprach- und Datenübertragungen zwischen Bluetooth-Geräten und verwendet als Basis L2CAP.
Adaptierte Protokolle, wie OBEX und das Internet Protocol (IP), basieren auf einem der bereits erwähnten Protokolle. So verwendet OBEX den RFCOMM oder TCP/UDP Service und
IP verwendet den BNEP Service.
Die Anzahl der Bluetooth-Protokolle unterliegt zurzeit einem ständigen Wachstum. Viele
neue Protokolle werden durch die Bluetooth SIG6 spezifiziert, wobei die meisten von ihnen
das L2CAP Protokoll als Basis verwenden.
6.1.2.3 Anwendung BLUDEC
Es wurde festgelegt, dass das neue LSVA Erfassungsgerät das über eine Bluetooth Schnittstelle verfügt mit dem OBEX Service und dem OBEX Protokoll Images sendet und empfängt.
Aus funktionaler Sicht könnte die OBU genau so gut den RFCOMM Service und das
RFCOMM Protokoll zum Senden und Empfangen von Images verwenden. Ein Wartungsfreundlicher objektorientierter Software Design kann dieser Situation gerecht werden, in dem
von konkreten Übertragungsservice zunächst abstrahiert und auf der Basis des abstrakten
Übertragungsservice der konkrete Image Übertragungsservice realisiert wird.
Mit diesem Ansatz kann die Entwicklung der Simulationsapplikation der Applikation und der
BLUDEC Applikation unabhängig vom endgültig verwendeten Übertragungskanal z.B. auf
der Basis von Sockets erfolgen. Für die Anpassung an den verwendeten Bluetooth Service
muss lediglich die entsprechende Realisierung der Image Übertragungssoftware ausgetauscht werden. Die Applikationsentwicklung von BLUDEC und der Simulation des Erfassungsgerätes kann so von der Entwicklung der Realisierung des Image Übertragungssoftware entkoppelt werden.
6.2
Java 2 Micro Edition
Java 2 Micro Edition (J2ME oder Java 2 ME) ist eine Entwicklungs- und Laufzeitumgebung,
die für die Ausführung von Java Applikation auf Endgeräten mit wenig Speicherplatz und
geringer Rechenleistung konzipiert wurde. Java Applikationen, die für Personal Computer
6
Bluetooth Special Interest Group
14/44
DA_Bericht_BLUDEC.doc
S LSVA 1
(PC) entwickelt wurden, können aufgrund ihrer Anforderungen an die Hardware (Speicherplatz, Rechenleistung, Tastatur, Bildschirm) nicht auch auf einem Mobiltelefon ausgeführt
werden.
Java ist eine objektorientierte Programmiersprache, die es dem Programmierer erlaubt, ein
Programm zu erstellen und zu kompilieren, um es später auf einer Vielzahl von verschiedenen Plattformen zu verwenden. Die erstellte Software ist daher unabhängig von Hardware
und Betriebssystem.
Die J2ME Plattform ermöglicht es, die Leistung und Vorteile der Java-Technologie im Rahmen von Mobiltelefonen zu nutzen. Ein weiteres Ziel der J2ME Plattform ist es, Geräten den
dynamischen Download von Applikationen z.B. über das Internet zu ermöglichen.
Die von der J2ME adressierten Gerätetypen weisen ein breites Spektrum bezüglich verfügbarem Speicher, Rechen- und damit auch Ausführungsgeschwindigkeit und den Möglichkeiten der Ein- und Ausgabe auf. Um einer solchen Vielfalt in möglichst vielen Fällen gezielt
gerecht zu werden, definiert die J2ME Architektur sog. Konfigurationen, Profile und optionale
Pakete, die eine modulare Anpassung der Architektur ermöglichen. Der grundsätzliche Aufbau der J2ME Architektur ist in Abbildung 6 illustriert, die einzelnen Schichten werden in den
folgenden Abschnitten betrachtet.
Abbildung 6:
5: Komponenten der J2ME Architektur
Jeder Java Programmierer kann, unter Beachtung einiger Details, J2ME Software erstellen.
Auch muss erwähnt werden, dass ein J2ME-Programm auf jedem mobilen Endgerät, das
diesen Standard unterstützt, funktioniert (theoretisch, in der Praxis können trotzdem verschiedenste Kompatibilitätsprobleme auftreten).
Die Vorteile der Programmiersprache Java:
Sicher:
Java war von Anfang an für die Verwendung in Netzwerkarchitekturen konzipiert und daher
wurde besonders auf die Sicherheit Wert gelegt. Gerade in Netzwerken lauert eine ständige
Gefahr von Attacken anderer Systeme.
Zuverlässig:
Programmierer müssen sich in Java nicht um Speicherplatzbelegungen und -bereinigungen
kümmern. Dies wird ihnen durch die Java Runtime Umgebung verlässlich abgenommen.
15/44
DA_Bericht_BLUDEC.doc
S LSVA 1
Anders als zum Beispiel in C++ kann der Softwareentwickler nicht auf die Freigabe von Speicherbereichen vergessen.
Objektorientiert:
Als eine objektorientierte Sprache ermöglicht Java die leichte Wiederverwendbarkeit von
Programmteilen zu einem späteren Zeitpunkt. Diese Form der Programmierung erleichtert
die Abbildung der realen in die virtuelle Welt einer Software. Software kann dadurch auch für
Aussenstehende leichter verständlich gemacht werden; zum Beispiel, dass ein Konto aus
den Attributen Kontonummer und Kontobenutzername besteht. Die Zuverlässigkeit zusammen mit der Objektorientierung ermöglicht eine schnellere und einfachere Softwareentwicklung. Vor allem für Entwickler, die bereits Erfahrung mit anderen objektorientierten Programmiersprachen haben, ist ein Umstieg sehr schnell realisierbar.
Frei erhältlich:
Für die Verbreitung von Java war es wichtig, dass die grundlegende Spezifikation frei erhältlich ist, und somit eine Implementierung auf allen Plattformen ermöglicht wird.
Plattformunabhängig:
Java Applikationen sind auf allen Plattformen, die die durch die Applikation geforderte Laufzeitumgebung, Konfigurationen und Profile unterstützen, identisch ausführbar.
6.2.1
Produktepalette der durch J2ME unterstützten Endgeräte
1. Drahtlose Endgeräte:
Drahtlose Endgeräte kommunizieren durch eine Funkverbindung mit ihrer Umgebung.
2. Mobile Endgeräte:
Mobile Endgeräte können, müssen aber nicht drahtlose Endgeräte sein. Ein Personal Digital Assistant (PDA) ist zwar ein mobiles Endgerät, kommuniziert allerdings nicht unbedingt mit anderen Geräten über eine drahtlose Funkverbindung. Ausnahmen sind natürlich möglich. Mobile Endgeräte bieten die Möglichkeit sie überall hin mitzunehmen und zu
verwenden. Drahtlose Geräte sind jedoch oft an ihre Umgebung gebunden; zum Beispiel
eine Funkmaus ist an die Reichweite des Funkempfängers und damit an die Umgebung
des Computers gebunden - die Mitnahme einer Maus und Verwendung ausserhalb der
Reichweite des Empfängers macht diese nutzlos.
Beispiel für eine mobiles und drahtloses Endgeräte ist ein Mobiltelefon mit integriertem MP3
Player. Es kann sowohl über die Funkverbindung zum Telefonieren, als auch zum Abspielen
von Musik ausserhalb des Mobilfunknetzes verwendet werden.
Java 2 Micro Edition beschränkt sich jedoch nicht nur auf drahtlose und mobile Endgeräte
sondern unterstützt auch die Programmierung einer Vielzahl anderer Geräte. Nachfolgende,
nicht abschliessende Aufzählung soll dies verdeutlichen:
•
Fernsehgeräte
•
Navigationssystem
•
Auto – Entertainmentsysteme
•
Smart Cards
•
Pager
•
Personal Digital Assistants
•
Mobiltelefone
•
Bildtelefone
16/44
DA_Bericht_BLUDEC.doc
S LSVA 1
6.2.2
J2ME Konfigurationen und Profile
Innerhalb der Java 2 Micro Edition Spezifikation gibt es zwei architektonische Konzepte auf
Basis von:
1.
Konfigurationen:
Konfigurationen sollen die Portierbarkeit zwischen verschiedenen Geräten erleichtern.
Es werden zum Beispiel die unterstützten Hauptklassen, wie String, Stream, Thread,
etc. definiert.
2.
Profile:
Profile konzentrieren sich auf gerätespezifische Merkmale, wie zum Beispiel die Unterstützung von Infrarotschnittstellen oder Spiele-APIs.
Der Hauptunterschied zwischen Konfigurationen und Profilen ist, dass Profile im Gegensatz
zu Konfigurationen voneinander unabhängig sein können. Jede Konfiguration muss im Definitionsbereich ihrer Mutterkonfiguration stehen. Bisher sind die folgenden zwei Konfigurationen definiert:
•
CLDC (Connected Limited Device Configuration):
CLDC definiert die Anforderungen für Endgeräte mit geringen Speicher- und Rechenleistungen. Der Speicherbereich ist auf 160 kB bis 512 kB begrenzt.
•
CDC (Connected Device Configuration):
CDC richtet sich an Geräte mit einer höheren Speicher- und Rechenleistung.
Profile wiederum basieren auf den definierten Konfigurationen und spezifizieren welche APIs
für die Unterstützung der jeweilig benötigten Funktionalitäten implementiert werden müssen zum Beispiel muss ein Profil für die Programmierung von Spielen eine Möglichkeit zur Darstellung von Grafiken haben. Beispielprofile sind:
Mobile Information Device Profile (MIDP):
Eine ”Virtuell Java Machine” die dieses Profil implementiert bietet viele Funktionalitäten, die
für die Entwicklung von Mobiltelefonapplikationen wichtig sind. Beispiel hierfür ist die Möglichkeit, eine HTTP Verbindung zu öffnen oder die Darstellung von Eingabefeldern. Dieses
Profil basiert auf der CLDC Konfiguration.
PDA Profil (PDAP):
Das PDA Profil ist abgestimmt auf die besonderen Bedürfnisse von Personal Digital Assistants, wie zum Beispiel die Nutzung des relativ grossen Displays; basiert auf der CLDC
Konfiguration.
RMI Profile
Das PMI Profil ist ein auf der CDC Konfiguration basierendes Profil, das die Implementierung
von ”Remote Method Invocation” definiert.
In Mobiltelefonen ist prinzipiell das Mobile Information Device Profile implementiert. Die derzeit meist verwendete Spezifikation ist die Version 1.x des MIDP. Alle neueren Geräte unterstützen aber bereits die Version 2.0.
17/44
DA_Bericht_BLUDEC.doc
S LSVA 1
Das MID Profil in der Version 2.0 [JSR118]. verfügt über folgende Standard API Packages:
•
java.lang:
Beinhaltet ca. 50% der Klassen im Vergleich zur Java der Standard Edition.
•
Java.lang.ref
Bietet Klassen für schwache Referenzen
•
java.io:
Deutlich, im Vergleich zur Java Standard Edition, abgespeckte Version des io packages.
Es fehlen zum Beispiel die Filehandling Klassen.
•
java.util:
Ebenfalls wurde auf die Implementierung von substanziellen Klassen, wie zum Beispiel
List verzichtet.
•
javax.microedition.io:
Zusatzklassen für den Zugriff auf Netzwerkfunktionalitäten.
•
javax.microedition.lcdui:
Zusatzklassen für die Benutzerschnittstellen.
•
javax.microediton.lcdui.game:
Zusatzklasse für die Entwicklung von Spielen
•
javax.microediton.media:
Zusatzklasse für Multimedia
•
javax.microediton.media.control:
Zusatzklasse für Playback und Lautstärke
•
javax.microedition.midlet:
Dieses Package beinhaltet die Klasse MIDlet, welche für die Ausführung und Zustandsbeschreibung eines Java 2 ME Programms und die Interaktion mit der Umgebung zuständig ist.
•
javax.microedition.pki:
Klassen für die Authentifizierung von Informationen.
•
javax.microedition.rms:
Im rms Package befindet sich die Bibliothek zur Speicherung von Daten. Jedes Java 2
ME Programm hat seinen eigenen Speicher und es kann auch nur auf diesen zugreifen.
Die Bluetooth API [JSR82] beinhaltet folgende Packages:
•
javax.bluetooth:
Beinhaltet Klassen und Interfaces für die Bluetooth Unterstützung.
•
javax.obex:
Optionales Packages von JSR82 zur Unterstützung des OBEX (Object Exchange Protocol) Protokolls
Die Filesystem API [JSR75] beinhaltet das folgende Package:
•
javax.microedition.io.file:
Beinhaltet Klassen und Interfaces für Unterstützung des Filesystemzugriffs.
Die WebService API [JSR172] beinhaltet die folgenden Packages:
18/44
DA_Bericht_BLUDEC.doc
S LSVA 1
•
java.rmi:
Package zur Unterstützung von RMI
•
javax.microedition.xml.rpc:
Package zur Unterstützung von JAX-RPC (einem Typ von WSDL)
•
javax.xml.namespace:
Package zur Unterstützung XML Namensauflösung.
•
javax.xml.parsers:
Beinhaltet Klassen zur Verarbeitung von XML Dokumenten.
•
javax.xml.rpc:
Package zur Unterstützung JAX-RPC
•
org.xml.sax:
Package stellt die Java ME SAX API als Subset von JSR 172 zur Verfügung.
•
org.xml.sax.helpers:
Packages mit Hilfsklassen
6.2.3
Anwendung BLUDEC
Der BLUDEC Demonstrator wurde auf Basis des MID Profil 2.0 entwickelt, wobei weitere
optionale Pakete (Profile, Schnittstellen) für die Unterstützung von WebService [JSR172],
des Filesystem Zugriffs [JSR75] und von Bluetooth [JSR82] verwendet wurden.
In diesem Zusammenhang ist der Umstand zu beachten, dass optionale Pakete wie z.B. der
JSR82 für die Bluetooth Unterstützung wiederum optionale Bestandteile haben. Die Unterstützung von OBEX ist ein solcher optionaler Bestandteil. Viele Gerätehersteller unterstützen
OBEX trotz der Implementierung von JSR82 bis heute noch nicht.
Die Verwendung der Bluetooth RFCOMM Protokolls statt des OBEX Protokolls für die Übertragung von Images ist in diesem Zusammenhang eine Alternative. Vgl. hierzu auch 6.1.2.3.
Durch den Entscheid, Java Software Technologie für die Realisierung von BLUDEC zu verwenden wird erreicht, dass BLUDEC auf allen Geräten ausführbar ist, die die J2ME Laufzeitumgebung und die entsprechenden Konfigurationen unterstützen.
Weiterhin kann aufgrund von diesem Entscheid BLUDEC von einer zentralen Stelle aus über
das Internet verteilt und auf der Zielplattform Mobiltelefon installiert werden.
6.2.4
Alternativen zu Java 2 ME
Wie schon in Kapitel 6.2 erwähnt, bietet Java den Vorteil, dass der einmal erstellte Programmcode auf einer Vielzahl anderer Systemumgebungen ausgeführt werden kann. Für die
Programmierung von Endgeräten mit den erwähnten speziellen Anforderungen gibt es natürlich auch die Möglichkeit, andere Programmiersprachen einzusetzen. Der erstellte Programmcode muss jedoch für eine Ausführung auf jedem System neu kompiliert werden. Dies
verhindert eine rasche Verbreitung von Software auf einer Vielzahl unterschiedlicher Geräte.
Ebenfalls bieten andere Programmiersprachen nicht immer die Vorteile von Java, wie Sicherheit, Zuverlässigkeit und Objektorientierung.
Ein sehr gut verständliches Bespiel für die genannten Vorteile sind für Mobiltelefone programmierte J2ME - Spiele: durch eine grosse Gemeinschaft an Softwareentwicklern besteht
bereits eine Vielzahl an wieder verwendbaren, objektorientierten Code, für die leichte und
schnelle Umsetzung von Ideen. Auch die Anzahl der Mobiltelefone, die eine J2ME - Runtime
19/44
DA_Bericht_BLUDEC.doc
S LSVA 1
mitliefern steigt stetig. Möchte nun ein engagierter Entwickler sein Spiel entgeltlich oder frei
verbreiten, so ist dies durch das Anbieten im Internet sehr leichtmöglich. Der Konsument
dieses Spieles kann wiederum auf die sichere und beschränkte Ausführumgebung der Runtime vertrauen und sicher sein, dass keine gefährlichen Informationen über sein Mobiltelefon
verbreitet werden.
Es verschwinden somit die Grenzen zwischen den einzelnen Herstellerfirmen wie Nokia,
Siemens, Sony Ericsson, etc. Würde der Entwickler stattdessen auf eine Implementierung in
C++ setzen, so hätte er darauf zu achten, dass der Code auch auf einer möglichst grossen
Anzahl von Endgeräten funktioniert. Weiters könnte er nur bedingt auf wieder verwendbaren
Programmcode zurückgreifen und müsste den Programmcode zusätzlich für jedes einzelne
Gerät neu kompilieren. Das heisst nicht nur für jede Firma, sondern auch für jeden einzelnen
Typ einer Firma, soweit die einzelnen Geräte nicht auf dem gleichen Betriebssystem basieren. Auch Java 2 Micro Edition kann nicht als die berühmte ”eierlegende Wollmilchsau” bezeichnet werden, da es gerade im Bereich der Performance oft an ihre Grenzen stösst und
es daher manchmal notwendig ist, Software in einer ”schnelleren” Programmiersprache zu
implementieren.
Innerhalb der Java-Programmiersprache gibt es auch für die erwähnten Endgeräte Alternativen zu J2ME. Es handelt sich dabei meist um spezielle umfangreichere Implementierungen,
als die der J2ME Spezifikation: [White and Hemphill, 2002]
•
Chai VM von Hewlett-Packard
•
VisualAge Micro Edition von IBM
•
Waba von Wabasoft
Ausserhalb der Javawelt gibt es noch folgende Alternativen:
•
WAP/WML:
beschränkt sich auf die Darstellung von Inhalten auf Display, ähnlich der Kombination
von HTTP und HTML. Für die Anzeige von dynamischen Inhalten wird WMLScript
verwendet, welches an die Programmiersprache Javascirpt angelehnt ist. Eine Speicherung von Daten ist jedoch nicht möglich.
•
C/C++
bietet vor allem Performanzvorteile gegenüber Java. Nachteil ist die kompliziertere
Programmierung, sowie Lauffähigkeit auf anderen Systemen.
•
.net Programmiersprachen
beschränkt sich auf die Betriebssysteme von Microsoft, zum Beispiel: Windows CE,
PocketPC oder PhoneEdition
20/44
DA_Bericht_BLUDEC.doc
S LSVA 1
7 Analyse
Im folgenden Kapitel sind das Vorgehen und die Erkenntnisse aus dem 2. Teil der Analysephase dokumentiert. Der erste Teil der Analysephase hat im Zusammenhang mit der Erstellung des Pflichtenheftes stattgefunden. Die entsprechenden Analyseresultate sind im BLUDEC Pflichtenheft dokumentiert.
Das grundsätzliche Vorgehen kann in einem Satz zusammengefasst werden: Es wurden
anhand von Literatur und Beispielprogrammen die Thematik analysiert und die Erkenntnisse
sind anhand von kleinen Prototypen überprüft worden.
7.1 OBU Simulator
Da zum Zeitpunkt der Diplomarbeit noch keine CH-OBU-2 für Tests zur Verfügung stand,
musste eine Simulation für die OBU entwickelt werden, welche folgende Anforderungen erfüllt:
Bereitstellen eines OBEX FTP Servers zum Senden und Empfangen eines Images.
Bereitstellen eines Loggingmechanismus zur Analyse des Verbindungsaufbaus und -abbaus,
sowie des Imageaustausches.
7.1.1
OBU Simulator als MIDlet
Als erster Ansatz wurde ein OBU Simulator als MIDlet realisiert. Für eine Realisierung als
MIDlet haben folgende Argumente gesprochen:
Maximaler Erfahrungsgewinn in der J2ME Technologie.
Kleinster Aufwand, da dieselben APIs wie für die BLUDEC Entwicklung verwendet werden
können.
JSR 82 wird durch die Java Standard Edition nicht unterstützt. Der Aufwand für die Suche
einer Implementierung der JSR 82 für die Java Standard Edition sollte vermieden werden.
Im Iterationsschritt A konnte mit Hilfe des OBU MIDlet Simulators eine Bluetoothverbindung
zum BLUDEC Demonstrator aufgebaut und Images erfolgreich zwischen dem OBU MIDlet
Simulator und BLUDEC ausgetauscht werden.
Es stellten sich jedoch schon sehr bald wichtige Erkenntnisse heraus:
Die Bluetoothverbindung konnte nur zwischen zwei emulierten Geräten hergestellt werden.
Es wurde keine (mit vertretbarem Aufwand) Möglichkeit gefunden, mittels eines emulierten
Geräts auf den Bluetooth-Stack des Betriebsystems zuzugreifen. Um das Verhalten einer
„physischen“ Bluetoothverbindung analysierten zu können mussten also zwei „reale“ Mobilgeräte verwendet werden.
Das zweite Mobilgerät - der PDA HP IPAQ – musst vorgängig für die Ausführung von MIDlets vorbereitet werden. Dazu wurden die Laufzeitumgebung J9 und die Implementation der
JSR 75 von IBM und sowie die JSR 82 Implementation von Avetana eruiert und installiert.
Doch auch nach intensiven Internetrecherchen musste der Versuch abgebrochen werden
den PDA zur Ausführung eines MIDlet zu bewegen.
21/44
DA_Bericht_BLUDEC.doc
S LSVA 1
Deswegen wurde als Workaround, wie im nächsten Kapitel beschrieben, die OBU Simulation
als Java PC Applikation mit einem Bluetooth Protokollstack als Betriebssystemerweiterung
realisiert.
7.1.2
OBU Simulator als Java Standard Edition Applikation
Da bereits für den PDA eine JSR 82 Implementierung gesucht werden musste und die gefundene Implementierung von Avetana auch mit der Java Standard Edition kompatibel ist,
war es nahe liegend, den OBU Simulator auch als Java Standard Edition Applikation zu realisieren.
Mit Hilfe des Java SE OBU Simulators war es im Iterationsschritt C möglich, einerseits das
Verhalten einer „physischen“ Bluetoothverbindung zu analysierten, sowie das Verhalten von
BLUDEC auf einem realen Mobilgerät - einem Sony Ericsson K800i – zu untersuchen.
7.1.3
Zusammenfassung Erkenntnisse OBU Simulator
Die wesentlichen Erkenntnisse auf Stufe OBU Simulationsentwicklung lassen sich wie folgt
zusammenfassen:
Um ein effizientes Entwickeln zu ermöglichen, wird sowohl die OBU MIDlet Simulation als
auch der Java SE OBU Simulator benötigt. Beide Java Applikationen müssen „gepflegt“ werden.
Die Tatsache, dass aus den emulierten Gräten nicht auf den Bluetooth-Stack des Betriebssystems zugegriffen werden kann, bringt auch mit dem Java PC (SE) OBU Simulator eine
wichtige Einschränkung mit sich: Für die Kommunikation mit BLUDEC muss der Java PC
OBU Simulator auf einem realem Gerät ausgeführt werden. Dadurch werden die Möglichkeiten fürs Debugging erheblich eingeschränkt und die benötigte Zeit fürs Deploying des BLUDEC auf ein Handy wird massiv erhöht.
Weiterhin konnten folgende Erkenntnisse gewonnen werden:
a) Die Bluetoothverbindung verhält sich grundsätzlich sehr stabil.
b) Auch die Übertragung und Verarbeitung von grossen Images (128kByte) läuft sehr zügig
(ca. 1s) ab.
c) Die Geräte- und Dienstsuche beansprucht mit ca. 15s relativ viel Zeit. Unter anderem
deswegen wurde der Aufbau einer Bluetooth Verbindung als eigene Funktion des BLUDEC realisiert.
d) Das Verhalten eines MIDlet kann zwischen emulierten und realen Geräten sehr unterschiedlich sein. Dies kann am besten an Hand von unterschiedlichem Verhalten von
Elementen der Benutzeroberfläche, z.B. einem Alarm Fenster beobachtet werden. Es ist
nicht immer nachvollziehbar wieso etwas gar nicht, oder anders als erwartet läuft.
Um die Auswirkungen von Erkenntnis d) zu minimieren, wurde die Applikationssoftware so
implementiert, dass die verwendeten Speicherressourcen soweit wie möglich durch die Applikation vorgenommen werden. Dieser Ansatz widerspricht der Philosophie der objektorientierten Programmierung für PC Applikationen, kommt aber immer dort zu Einsatz, wo die
Ressourcen knapp sind, wie z.B. für embedded Systeme. Man erreicht mit diesem Ansatz
22/44
DA_Bericht_BLUDEC.doc
S LSVA 1
einerseits die bestmögliche Unabhängigkeit von der Ressourcenverwaltung der JVM, die je
nach Implementierung ein sehr unterschiedliches Verhalten haben kann. Andererseits wird
das Exceptionhandling der Applikation stark vereinfacht, wenn bereits beim Programmstart
alle benötigten Ressourcen alloziert werden können. Ressourcenengpässe während der
Laufzeit können so weitgehendst ausgeschlossen werden.
Aus Erkenntnis d) folgt auch, dass eine Applikation immer auch auf der realen Ziel-Hardware
getestet werden muss.
7.2
FZHSW Simulation
7.2.1
Beschreibung der FZHSW Simulation
Es wurde entschieden, die FZHSW Internet-Kommunikationsschnittstelle mit der bestehenden FZHSW der CH-OBU-1 zu testen und analysieren. Dies bedingt, dass mit BLUDEC CHOBU-1 Images zwischen OBU Simulation und FZHSW Simulation ausgetauscht werden.
Der WebService der FZHSW wurde im Iterationsschritt 0 auf einem IIS Webserver im Intranet installiert und konfiguriert.
Im Iterationsschritt B konnten mit dieser Installation die ersten Images zwischen BLUDEC
(auf emuliertem Gerät) und der FZHSW erfolgreich ausgetauscht werden. In einem zweiten
Schritt konnte BLUDEC erfolgreich um die Funktionalität der Auswertung der Service Response mittels eines SAX Parsers erweitert werden.
Um das Verhalten des WebServices auf einem realen Gerät mit GPRS Internetanbindung zu
testen wurde im Iterationsschritt C der WebService auf einem mittels Domainname aus dem
Internet her erreichbaren IIS WebServer installiert und konfiguriert. Interessanter Weise
konnte jedoch der WebService nur vom emulierten Gerät aus erreicht werden, auf dem realen Gerät ist der http Fehlercode 504 – Gateway Timeout – aufgetreten. Ein Umkonfigurieren
des Server-Ports auf die Portnummer 82 konnte das Problem beheben.
7.2.2
Erkenntnisse FZHSW Simulation
Dieser aufgetretene Fehler und seine Behebung zeigen, dass die GPRS Internetprovider
u.U. restriktiver im Routing der Ports sind als ADSL Internetprovider.
7.3
BLUDEC Demonstrator
7.3.1
Beschreibung Vorgehen
Gemäss dem im Pflichtenheft definierten Entwicklungsvorgehen wurden in der Analysephase
die Iterationsschritte A und B durchgeführt und somit für jede Kommunikationsschnittstelle
ein eigener Prototyp entwickelt. Die Tests mit den Kommunikationspartnern sind ohne grössere Probleme verlaufen. Die aufgetauchten Probleme konnten relativ rasch eingegrenzt und
behoben werden. Die Hauptschwierigkeiten bei der Entwicklung sind auf die eingeschränkten Debug-Möglichkeiten und das unterschiedliche Verhalten zwischen realen und emulierten Geräten zurückzuführen. Die Anwendung und die Arbeit mit den Kommunikationsschnittsstellen waren dagegen relativ problemlos.
23/44
DA_Bericht_BLUDEC.doc
S LSVA 1
7.3.2
Erkenntnisse Entwicklung BLUDEC
Aus dem Iterationsschritt C konnte die Erkenntnis gewonnen werden, dass
•
•
die Anwendung der Filesystem API JSR 75 ihre Tücken hat:
o
Die Verfügbarkeit der JSR 75 ist nur in „besseren“ Handys gegeben.
o
Die Struktur des Filesystems auf den verschiedenen Handys ist nicht einheitlich
und dieser Umstand muss bei der Entwicklung berücksichtigt werden.
o
Je nach Hersteller darf nur auf bestimmte Verzeichnisse zugegriffen werden.
o
Das Sicherheitskonzept von J2ME erlaubt keine Filesystemzugiffe von unsignierten MIDlets ohne Benutzerbestätigung. Das Signieren eines MIDLets ist mit Kosten von ca. 500$ pro Jahr relativ kostspielig. Weiterhin haben nicht alle Handys
dieselben Zertifikate installiert. Es lassen sich keine eigenen Zertifikate installieren.
Auf Grund der oben genannten Probleme bei der Anwendung des Filesystems des Handys liegt es nahe, auf das Filesystem als persistenten Speicher nach Möglichkeit zu verzichten.
Solange nur das MIDlet selbst die Daten verwalten muss, bietet sich die Verwendung des
durch die J2ME Technologie zur Verfügung gestellten Record-Management-System
(RMS) zur persistenten Speicherung und Verwaltung von Daten an.
Aus diesen gewonnen Erkenntnissen leitet sich folgende Anforderung ab:
•
BLUDEC muss im Deklarationsmodus ohne Filesystemzugriff auskommen.
24/44
DA_Bericht_BLUDEC.doc
S LSVA 1
7.4 Klassendiagramme aus den Iterationen A und B
7.4.1
BLUDEC OBEX Client
Abbildung 7: Klassendiagramm BLUDEC OBEX Client
25/44
DA_Bericht_BLUDEC.doc
S LSVA 1
7.4.2
OBEX Server
Abbildung 8: Klassendiagramm OBEX Server
26/44
DA_Bericht_BLUDEC.doc
S LSVA 1
7.4.3
WebService Client
Abbildung 9: Klassendiagramm BLUEC WebService
27/44
DA_Bericht_BLUDEC.doc
S LSVA 1
7.4.4
Skizze des Kommunikationsschnittstelle zur OBU
Diese Skizze ist eine Folge der Auseinandersetzung mit den Unzulänglichkeiten mit der
Bluetoothschnittstelle. Zusammen mit meinem Betreuer wurde die Schnittstelle genauer betrachtet und es wurden Alternativen zum OBEX Profil, sowie Möglichkeiten zur Abstraktion
der Schnittstelle skizziert. Siehe auch Kapitel 6.1.2.3.
Abbildung 10: Skizze Protokollstack
28/44
DA_Bericht_BLUDEC.doc
S LSVA 1
8 Design und Implementierung
8.1 Grundsätze und Annahmen
In diesem Kapitel werden die Designgrundsätze und –annahmen, sowie Desingresultate
aufgezeigt.
Der BLUDEC Demonstrator stellt ein Proof of Concept bzw. ein Rapid Prototype dar, d.h. es
soll das Konzept von BLUDEC mit Hilfe des BLUDEC Demonstrators überprüft werden können.
Der Rahmen für die Bedienprozesse ist durch das Gesetz und die Verordnungen vorgegeben. Die konkreten Bedienprozesse werden in Abstimmung mit dem technisch Möglichkeiten
durch den Betrieb LSVA definiert. Es ist nicht die Aufgabe der Auftraggeberin der Diplomarbeit (Abteilung LSVA) kommerzielle Software z.B. für die „kartenlose“ Deklaration zu entwickeln und zu vertreiben. BLUDEC ist im Sinn eines kundenfreundlichen Service als Basis für
die Förderung entsprechender Entwicklungen kommerzieller Applikationen zu verstehen.
Gegenüber einem kommerziellen Lösung können und müssen folgende Vereinfachungen
getroffen werden:
a) Der BLUDEC Demonstrator wird für eine Zielhardware (Sony Ericsson K800i) optimiert
und nur auf dieser getestet. So wird zum Beispiel nur die Filesystemstruktur des Zielsystems berücksichtigt.
b) Während der Laufzeit vom Demonstrator werden keine weiteren Applikationen auf dem
Gerät ausgeführt (auch der Demonstrator selbst wird nur einmal gestartet!). Die Ressourcen stehen dem Demonstrator für die Dauer der Programmausführung grundsätzlich
exklusiv zur Verfügung. Das MIDlet muss nicht Reentrance fähig sein.
c) Die Überprüfung der Datenintegrität durch die verwendeten Übertragungsprotokolle und
den WebService der FZHSW ist ausreichend und muss nicht durch die Anwendung sichergestellt werden. (Im Fehlerfall können alle Daten jederzeit wieder beschafft werden!)
d) Der GPRS- resp. UMTS-Empfang ist für die Dauer der Übertragung gewährleistet.
e) Die Bluetoothverbindung zur OBU ist für die Dauer der Übertragung gewährleistet.
f)
Der Wiederaufbau einer Bluetoothverbindung ist keine Funktion des Demonstrators.
8.2
Vorgehen
Der Prototyp wurde iterativ entwickelt. So war es möglich, die neue Technologie Stück für
Stück kennen zu lernen und die damit verbundenen Probleme zu lösen. Mit den Entwicklungserfahrungen und an Hand der Software der verschiedenen Iterationen ist die Spezifikation der Qualitätskriterien z.B. im Bereich Software Design für eine kommerzielle Realisierung der BLUDEC Funktionalität möglich.
Aufgrund nur geringfügig vorhandener technologischer Vorkenntnisse, wegen des gewählten
neuen iterativen Entwicklungsvorgehens und wegen fehlender Entwicklungserfahrung im
gewählten Themengebiet ist der Software Design nicht vor, sondern während der Realisierung entstanden. Der hier sehr knapp wiedergegebene Design hat den Anspruch, den Prototypen so zu erläutern, dass ein Abgleich mit dem Pflichtenheft möglich ist.
29/44
DA_Bericht_BLUDEC.doc
S LSVA 1
8.3 Softwarearchitektur
8.3.1
Klassenmodell
Aus den Anforderungen aus dem Pflichtenheft wurde das unten abgebildete Klassenmodell
entworfen. Dem Klassenmodell liegt die Idee des MVC Pattern zugrunde.
Auf Grund der in Kapitel 6.1.2.3 beschriebenen Überlegungen, sollten die Schnittstellen
Klassen von abstrakten Klassen abgeleitet werden.
Abbildung 11: Klassenmodell
Userinterface
Ist verantwortlich für die Benutzerein- und ausgaben.
Stellt das VIEW dar.
Demonstrator
Ist verantwortlich für die zentrale Programmlogik.
Stellt das CONTROL dar.
DatenModell
Ist verantwortlich für die Fahrzeug- und Konfigurationsdaten.
Stellt das MODEL dar.
OBEXHandler
Ist verantwortlich für die Schnittstelle zur OBU.
SOAPHandler
Ist verantwortlich für die Schnittstelle zur FZHSW.
Logger
Ist verantwortlich für die Protokollierung des Imageaustausch
30/44
DA_Bericht_BLUDEC.doc
S LSVA 1
Das Modell konnte – mit zusätzlichen Helper Klasen - wie abgebildet umgesetzt werden. Auf
die Abstrakten Schnittstellenklassen musste jedoch aus zeitlichen Gründen verzichtet werden. Eine nachträgliche Implementation dieser abstrakten Klassen stellt kein Problem dar
und ist mit geringem Aufwand machbar.
Durch den gewählten Ansatz Rückmeldungen über Methodenaufrufe der Demonstrator Klasse zu realisieren, ist aus meiner Sicht eine zu starke Kopplung der Klassen entstanden. In
diesem Bereich sehe ich noch Verbesserungspotential.
8.3.2
Beschreibung der Klassen
Mit Hilfe so genannter CRC Cards7 wurden die Aufgaben und das Zusammenspiel der umgesetzten Klassen dokumentiert.
Eine CRC Card beschreibt folgende Aspekte einer Klasse:
•
Eindeutiger Klassenname
•
Liste aller Tätigkeiten/Aktionen für die diese Klasse verantwortlich ist
•
Liste aller der Klassen mit denen eine Zusammenarbeit stattfindet bzw. die diese Klasse
benötigt um die Aufgaben für die sie verantwortlich ist, erfüllen zu können
Die Karten sind nach folgendem Muster aufgebaut:
Klassenname
•
•
•
verantwortliche Tätigkeiten
Als Schnittstelle dienen
Namen der Klasse mit denen diese zusammenarbeitet
BludecDemonstrator
• BludecUI
• BludecOBEXHandler
• WebServiceGetThread
• WebServicePutThread
• DateisystemThread
• StoreManager
• Logger
BludecUI
•
•
Benutzerbefehle entgegen nehmen
Benutzermeldungen ausgeben
•
•
BludecDemonstartor
LoggerUI
BludecOBEXHandler
•
•
Auftragsimage an OBU senden
Meldungsimage von OBU empfangen
•
•
BludecDemonstartor
ClientAuthentifizierung
ErgebnisAuswertung
•
Wertet die SAOP Meldungen aus
•
•
•
•
BludecDemonstrator
SOAPHandler
WebServiceGetThread
WebServicePutThread
7
steht für: Class – Klasse, Responsibility – Verantwortung, Collaboration - Zusammenarbeit
31/44
DA_Bericht_BLUDEC.doc
S LSVA 1
SOAPHandler
•
•
Parst die SOAP Meldungen
BludecDemonstrator
WebServiceGetThread
•
Auftragsimage von FZHSW beziehen
•
Meldungsimage an FZHSW senden
•
BludecDemonstrator
WebServicePutThread
•
BludecDemonstrator
Configuration
•
•
Konfigurationsdatensatz definieren
Konfigurationsdatensatz konvertieren
•
•
Fahrzeugdatensatz definieren
Fahrzeugdatensatz konvertieren
•
StoreManager
•
StoreManager
Vehicle
DateisystemThread
•
•
•
•
•
Meldungsimage speichern
Meldungsimage lesen
Auftragsimage speichern
Auftragsimage lesen
BludecDemonstrator
StoreManager
•
•
•
•
•
•
•
•
•
Datenbank verwalten
Bludec Konfiguration speichern
Bludec Konfiguration lesen
Fahrzeug Konfiguration speichern
Fahrzeug Konfiguration lesen
Meldungsimage speichern
Meldungsimage lesen
Auftragsimage speichern
Auftragsimage lesen
•
•
•
BludecDemonstrator
Configuration
Vehicle
•
BludecDemonstrator
•
•
Logger
BludecUI
Logger
•
•
Erfolgreicher Imageaustausch protokollieren
Fehlerhaften Imageaustausch protokollieren
LoggerUI
•
Protokoll anzeigen
32/44
DA_Bericht_BLUDEC.doc
S LSVA 1
8.3.3
Package Diagram
Die folgende Abbildung zeigt die Gruppierung der Klassen in Packages. Das grau schraffierte Package ist eine Fremdkomponente, welche einen Logging-Mechanismus zur Verfügung
stellt.
Bemerkung: Aus Gründen der Übersichtlichkeit stellt dieses Diagramm eine Vereinfachung
dar.
Abbildung 12: Package Diagramm
33/44
DA_Bericht_BLUDEC.doc
S LSVA 1
8.3.4
Sequenzdiagramm eines Imageaustausch mit der OBU
Abbildung 13: Sequenzdiagramm
9 Test
Dank dem gewählten Entwicklungsvorgehen wurde bereits sehr früh mit Modultests begonnen. Jede Iteration und auch alle Zwischenschritte wurden getestet. Nach Änderungen wurden Regressionstests durchgeführt. Weniger intensiv wurde die Kommunikation zur OBU
getestet, weil hier noch keine gültigen Schnittstellenspezifikationen und auch keine OBU
verfügbar sind. Der Endtest wurde als End to End Test gegenüber dem Pflichtenheft durchgeführt.
34/44
DA_Bericht_BLUDEC.doc
S LSVA 1
10 Erreichte Ziele
Das Ziel vom BLUDEC Demonstrator, das Konzept der kartenlosen Dekaration zur überprüfen und zu demonstrieren, konnte trotz der während der Entwicklung aufgetauchten Probleme erreicht werden. Das zentrale und kritische Thema von BLUDEC sind die Kommunikationsschnittstellen, welches während der Entwicklung entsprechend priorisiert wurde.
Mit dieser Arbeit konnte der Nachweis erbracht werden, dass sich das Konzept der kartenlosen Deklaration in die Praxis umsetzten lässt und die im Pflichtenheft festgelegen Technologien für diese Anwendung geeignet sind.
Es musste aber auch festgestellt werden, dass die im Pflichtenheft definierten Ziele zu hoch
gesteckt waren. So konnten nicht alle definierten Funktionen vollständig implementiert werden. Auf die Realisierung der „soll“ Anforderungen musste vollständig verzichten werden und
die Softwarearchitektur konnte nicht überarbeitet werden.
Rückblickend gibt es mehrere Gründe dass die Ziele nicht vollumfänglich realisiert werden
konnten:
•
Es wurde das erste Mal selbstständig eine Applikation entwickelt. Aufgrund der fehlenden Erfahrung ist eine Beurteilung über den Umfang des Machbaren im vorgegebenen Rahmen schwierig.
•
Es hat spezifisches Know-how im Beriech Java MIDlet Entwicklung und Entwicklung
von Kommunikationsapplikationen gefehlt. Deswegen sind strategischen Entscheidungen und Design Entscheidungen nicht oder unter ungünstigen Bedingungen gefällt worden.
•
Es ist eine wertvolle Erfahrung, dass standardisierte Schnittstellen und Programmierumgebungen nicht vollständig standardisiert sind und teilweise viel Raum für Interpretationen und damit Überraschungen bieten.
11 Ausblick
Für die Weiterentwicklung des Produktes können folgende Empfehlungen gemacht werden:
a) Der Design sollte überarbeitet werden. Das Verbesserungspotential wird in der Entkopplung der Klassen gesehen. Insbesondere sollte das Konzept der Rückmeldungen verbessert werden.
b) Die „relevanten“ Ressourcen müssen möglichst während dem Start des Demonstrators
alloziert werden. Unter einer „relevanten“ Ressource wird eine Ressource verstanden,
die entweder sehr speicherintensiv ist weil sie „gross“ ist oder weil sie sehr oft alloziert
wird. Diese Empfehlung hat zu Ziel, einerseits den „Eigenheiten“ der verschiedenen
Laufzeitumgebungen entgegenzuwirken und andererseits das Exceptionhandling zu vereinfachen.
c) Um die Portabilität zu gewährleisten sollten persistente Daten nicht (direkt) im Filesystem
gespeichert werden. Eine Ausnahme bildet der Testmodus. Im Testmodus müssen die
Images auch über das Filesystem ausgetauscht werden können.
d) Optimierungen sind erst im Bedarfsfall erforderlich.
35/44
DA_Bericht_BLUDEC.doc
S LSVA 1
e) Die Kommunikationsschnittstellen müssen für eine gute Test- und Wartbarkeit gekapselt
werden. Siehe dazu auch Kapitel 6.1.2.3 und 7.4.4.
f)
Aufgrund der verschiedenen Geräteverhalten und der beschränkten DebuggingMöglichkeiten sollte der Test- und Entwicklungsaufwand nicht unterschätzt werden.
12 Schlusswort
Die im Rahmen dieser Arbeit gewonnen Erfahrungen und Erkenntnissen sind für mich und
die LSVA von grosser Bedeutung. Durch das gewonnene Wissen kann ich aktiv dazu beitragen, dass die LSVA praxisgerechte und kundenorientierte Lösungen anbieten und betreuen
kann.
Die Motivation den Herausforderungen zu begegnen, hat während der gesamten Arbeit nie
nachgelassen. Die aufgetauchten Probleme haben mir immer wieder von neuem den Ansporn gegeben um nach Lösungen zu suchen. Die grösste Schwierigkeit hat in der Planung
gelegen. Einerseits fehlten mir die Erfahrung und das Hintergrundwissen in den verwendeten
Technologien und andererseits war meine Berufsalltag von einer grossen Arbeitsauslastung
geprägt.
Als sehr konstruktiv habe ich die Zusammenarbeit mit dem Experten und dem Betreuer empfunden. Für die geleistete Unterstützung die gute Zusammenarbeit möchte ich mir herzlich
bei den Herren Scheidegger und Hennecke bedanken!
Meiner Partnerin Jacqueline gebührt ein grosser Dank für ihre Geduld und ihr aufgebrachte
Verständnis. Merci!
36/44
DA_Bericht_BLUDEC.doc
S LSVA 1
A Anhang
A.1 Literaturverzeichnis
Breymann u.
Mosemann
2006
Breymann, Ulrich; Mosemann Heiko: JAVA ME
Hanser, 2006
Burbiel 2006
Burbiel, Herbert: Java goes Handy
Franzis, 2006
IBM 2007
IBM (Hrsg.):IBM DeveloperWorks, Techical
Libaray
www.ibm.com/developerworks/vie
ws/java/library.jsp, 2007
JCP
Java Community Process
www.jpc.org
JSR75
JCP (Hrsg.): PDA Optional Packages for the
J2ME Platform
http://www.jcp.org/en/jsr/detail?id=
75, 2004
JSR82
JCP (Hrsg.):Java APIs for Bluetooth Wireless
Technology 1.1
http://www.jcp.org/en/jsr/detail?id=
82, 2006
JSR118
JCP (Hrsg.):Mobile Information Device Profile
2.0
http://www.jcp.org/en/jsr/detail?id=
118, 2006
JSR139
JCP (Hrsg.):Connected Limited Device Configuration 1.1
http://www.jcp.org/en/jsr/detail?id=
139, 2003
JSR172
JCP (Hrsg.):J2ME Web Service 1.0
http://www.jcp.org/en/jsr/detail?id=
172, 2004
Nokia 2007
Nokia (Hrsg.): Forum Nokia
http://forum.nokia.com, 2007
Pfeiffer 2007
Pfeiffer, Michael: Java Micro Edition, 1.Auflage
Galileo, 2007
Roth 2005
Roth, Jörg: Mobile Computing, 2. Auflage
dpunkt, 2005
Sauter 2006
Sauter, Martin: Grundkurs Mobile Kommunikationssysteme, 2. Auflage
Vieweg, 2006
Schiller 2000
Schiller, Jochen: Mobilkommunikation . Techniken für das allgegenwärtige Internet
Addison-Wesley, 2000
Schmatz 2007
Schmatz, Klaus-Dieter: JAVA Micro Edition, 2.
Auflage
dpunkt, 2007
SIG
Bluetooth Special Interest Group (SIG)
www.bluetooth.org
SonyEricsson
2007
SonyEricsson (Hrsg.): Sony Ericsson Developer World
http://developer.sonyericsson.com,
2007
Sun 2007
SUN (Hrsg.): Sun Developer Network (SDN)
http://developers.sun.com 2007
Ullenboom
2006
Ullenboom, Christian: Java ist auch eine Insel,
5. Auflage
Galileo, 2006
White a.
Hemphill 2002
White, James; Hemphill, David: Java 2 Micro
Edition
Manning Publications, 2002
Wikipedia
2007
WIKIPEDIA (Hrsg.): Die freie Enzyklopädie
www.wikipedia.ch, 2007
37/44
DA_Bericht_BLUDEC.doc
S LSVA 1
A.2 Abbildungsverzeichnis
Abbildung 1: Systemübersicht................................................................................................................. 7
Abbildung 2: Beispiele für Piconets und Scatternets ............................................................................ 10
Abbildung 3: Bluetooth Host und Controller Klassifikation.................................................................... 12
Abbildung 4: Bluetooth-Protokoll-Stack................................................................................................. 13
Abbildung 6: Komponenten der J2ME Architektur ................................................................................ 15
Abbildung 7: Klassendiagramm BLUDEC OBEX Client ....................................................................... 25
Abbildung 8: Klassendiagramm OBEX Server...................................................................................... 26
Abbildung 9: Klassendiagramm BLUEC WebService ........................................................................... 27
Abbildung 10: Skizze Protokollstack ..................................................................................................... 28
Abbildung 11: Klassenmodell ................................................................................................................ 30
Abbildung 12: Package Diagramm........................................................................................................ 33
Abbildung 13: Sequenzdiagramm ......................................................................................................... 34
Abbildung 14: Programm "Hello World" ................................................................................................ 40
Abbildung 15: Listing "Hello World"....................................................................................................... 41
Abbildung 16: Screenshot des HelloWorld Programms ........................................................................ 42
38/44
DA_Bericht_BLUDEC.doc
S LSVA 1
A.3 Einrichten der Entwicklungsumgebung
A.3.1 Eclipse
Als Basis für die Entwicklungsumgebung wurde das Eclipse Packet „WebTools Platform; Allin-one“ gewählt. Dieses Packet beinhaltet nebst der integrierten Entwicklungsumgebung Eclipse die grundlegenden (Erweiterungen) Plugins für die Entwicklung von Webanwendungen.
Durch die Installation dieses all-in-one Pakets können Versionskonflikte vermieden werden.
A.3.1.1
Installation
Das Paket kann als zip Datei (wtp-all-in-one-sdk-R-1.5.3-win32.zip) von folgender URL geladen werden: http://download.eclipse.org/webtools/downloads. Die Installation beschränkt
sich auf das Entpacken der Datei und das Erstellen der Verknüpfungen für den Programmstart.
A.3.1.2
Konfiguration
Unter Windows/Perferences/Java/Build Path wurde die Einstellung „Folder“ gewählt. Dadurch werden die Projekte so organisiert, dass für die Sourcen und die binären Files unterschiedliche Ordner verwendet werden.
Der Pfad zum installierten Java Laufzeitumgebung wird normalerweise selbständig gefunden, anderenfalls kann er unter Windows/Perferences/Java/ Installed jre definiert werden.
A.3.2 Java ME Wireless Toolkit:
Es wurde das Java Wireless Toolkit von Sun installiert. Das Toolkit und eine Installationsbeschreibung sind unter folgender URL frei erhältlich:
http://java.sun.com/products/sjwtoolkit/download-2_5.html. Es wurde die Version Sun Java
Wireless Toolkit 2.5 for CLDC installiert.
A.3.3 JavaME Plugin
Für die komfortable Entwicklung von MIDlets wurde das JavaMe Plugin von Craig Setera mit
Hilfe des Eclipse Update Managers installiert. Die Installation und Konfiguration wurde gemäss der Beschreibung unter http://eclipseme.org/docs/installation.html durch geführt.
A.3.4 Tools
Zur Aufzeichnen und Analysieren des Netzwerkverkehrs zwischen dem WebService und
Client dem wurde ein Tool benötigt das Loopback Interfaces unterstützt. Die Wahl ist auf
eine Testversion des Programms CommView der Firma TamoSoft gefallen.
39/44
DA_Bericht_BLUDEC.doc
S LSVA 1
A.4 Einrichten des Entwicklungssystems
A.4.1 FZHSW Simulation
Als FZHSW Simulation wurde der WebService der heutigen Fahrzeughaltersoftware TriponDirect auf dem Entwicklungs-PC installiert. Der WebService verwendet die Microsoft Internet
Information Services (IIS) und stellt die beiden Funktionen „getEmtyImage“ und „putDeklImage“ zum Bezug eines Auftragsimages und zum Ablegen eines Meldungsimages zur Verfügung. Die Installation und Konfiguration wurde gemäss der Benutzeranleitung vorgenommen [Anhang A.3]
A.4.2 WebServer für OTA Provisioning
Für das OTA Provisioning wurde ein Verzeichnis auf einem Apache WebServer eingerichtet.
Für den Upload wurde auf ein neuer Benutzer auf dem FTP Server eingerichtet. Programmierung unter Java 2Micro Edition
A.5 Programmieren mit Java Micro Editon
Jedes Programm das unter J2ME lauffähig sein soll, muss als eine erweiterte Klasse von
javax.microedition.midlet.MIDlet implementiert werden. Dieses Konzept entspricht in etwa
dem, eines Java Applets oder eines Java Servlets. Die Applikation selbst ist daher eine Subklasse der abstrakten Klasse MIDlet. Um ein funktionsfähiges Programm zu schreiben, müssen Methoden zum Starten, Stoppen und Pausieren der Applikation implementiert werden.
Ein Beispielprogramm, dass den Text ”Hello World!” am Display eines Mobiltelefons ausgibt:
import javax.microedition.midlet.MIDlet;
import javax.microedition.lcdui.*;
public class HelloWorld extends MIDlet {
private TextBox textbox;
public HelloWorld() {
textbox = new TextBox("", "Hello World!", 20, 0);
}
public void startApp() {
Display.getDisplay(this).setCurrent(textbox);
}
public void pauseApp() {
}
public void destroyApp(boolean unconditional) {
}
}
Abbildung 14: Programm "Hello World"
_
_
_
Funktionen der einzelnen Methoden des Hello World Programms:
40/44
DA_Bericht_BLUDEC.doc
S LSVA 1
HelloWorld:
In diesem Beispiel erstellt der Konstruktor ”HelloWorld()” ein Objekt der Klasse TextBox. Dieses enthält den Text ”Hello World!”.
startApp:
Der Start einer J2ME Applikation wird durch die Methode startApp initialisiert. In unserem Beispiel wird
dem Objekt Display das durch den Konstruktor erstellte Objekt der Klasse TextBox zugewiesen. Auf
dem Display des Mobiltelefons wird nun ”Hello World!” ausgegeben.
pauseApp:
Eine Applikation kann dem Benutzer die Möglichkeit bieten, diese zu pausieren. Hierzu müsste ausprogrammiert werden, was in der Pause geschehen soll. Die Applikation kann ihren Zustand zwischenspeichern und die Tastatur und den Bildschirm freigeben. Am Ende der Pause wird wieder „Hello world“ auf den Bildschirm geschrieben und die Programmausführung unterbruchsfrei weitergeführt.
destroyApp:
Beim Beenden des Programms wird diese Methode aufgerufen. Es kann ein boolean Wert übergeben
werden, der Einfluss auf das Programmende hat. Ist der Wert ”True” so hat die Applikation keine Möglichkeit das Ende zu verzögern. Wird ein ”False” übergeben so kann das Beenden der Applikation
verhindert werden und zum Beispiel eine neue Meldung am Display ausgegeben werden. Sinn der
Methode ist es die Applikation ”sauber” beenden zu können und die bestehenden Systemresourcen
freizugeben (zum Beispiel alle bestehenden Netzwerkverbindungen zu trennen).
Damit das erstellte Programm auf einem Mobiltelefon ausgeführt werden kann muss es zuerst kompiliert und anschliessend ”preferified” werden. Der Kompiliervorgang übersetzt das
Programm in einen Zwischencode der bei der Ausführung durch die Java Virtual Machine
interpretiert wird. Aus Sicherheitsgründen, damit eine Java Klasse nur auf die erlaubten
Speicherbereiche zugreift, muss das Programm noch den ”Preverifying” Prozess durchlaufen. Ist dieser erfolgreich so ist die Applikation grundsätzlich lauffähig.
Das in einem Texteditor, mit dem Namen HelloWorld.java, gespeicherte Programm wird mit
folgendem Befehl kompiliert:
>javac -classpath c:\java\wtk\lib\midpapi21.jar HelloWorld.java
Wobei der Klassenpfad auf die auf die J2ME Library zeigt. Das Ergebnis ist die Datei HelloWorld.class.
Das Preverifiying wird mit dem Befehl
>preferivy -classpath c:\java\wtk\lib\midpapi21.jar -d preverified HelloWorld
ausgeführt. Die Option ”-d” teilt dem preferivy Programm mit, dass das Ergebnis des Prozesses in den Dateiordner ”preverified” geschrieben werden soll.
Die erstellte, kompilierte und überprüfte Applikation muss nun auf das mobile Endgerät
”deployed” werden. Dazu wird noch zusätzlich eine Beschreibungsdatei benötigt. Eine solche
Datei beinhaltet diverse Informationen rund um die Applikation und wird unter der Dateiendung ”*.jad” gespeichert.
Beispielinhalt der Datei HelloWorld.jad:
MIDlet-1: HelloWorld, , HelloWorld
MIDlet-Jar-Size: 906
MIDlet-Jar-URL: http://localhost/HelloWorld.jar
MIDlet-Name: HelloWorld
MIDlet-Vendor: Paolo Dünner
MIDlet-Version: 1.0.0
Abbildung 15: Listing "Hello World"
Gemeinsam mit dieser Beschreibungsdatei wird die kompilierte Klasse in eine jar Datei zusammengefasst und auf dem mobilen Endgerät gespeichert. Der Speichervorgang kann
41/44
DA_Bericht_BLUDEC.doc
S LSVA 1
entweder direkt über eine PC-Verbindung oder durch ein Laden aus dem Internet erfolgen.
Anschliessend kann das Programm ausgeführt werden.
Der Befehl zum erzeugen einer jar Datei lautet:
>jar -cf HelloWorld.jar HelloWorld.class HelloWorld.jad
Abbildung 16: Screenshot des HelloWorld Programms
42/44
DA_Bericht_BLUDEC.doc
S LSVA 1
A.6 Kurzanleitung BLUDEC Demonstrator
Navigation:
Es wird über Listen und das Softmenu navigiert. Der Befehl zurück ist im Softmenu verfügbar.
Hauptmenu:
a) Deklarieren: Es wird ein Auftrag an die OBU geschickt und die Meldung abgeholt.
Vorgängig muss eine BT Verbindung aufgebaut sein.
b) Übermitteln: Es werden alle Meldungen an die FZHSW geschickt und alle Aufträge empfangen.
c) Protokoll anzeigen :Einsicht in das Protokoll und Konfiguration der Protokollierung.
d) Einstellungen: Wechselt in das Menu Einstellungen. Siehe Menu Einstellungen.
Softmenu:
a) BT trennen: Trennen der BT Verbindung
b) Auftrag senden: Ein Auftrag zur OBU senden
43/44
DA_Bericht_BLUDEC.doc
S LSVA 1
c) Meldung empfangen: Ein Meldung wird auf der OBU abgeholt.
d) Meldung senden: Alle Meldungen werden an die FZHSW gesendet.
e) Aufträge beziehen: Es werden die Aufträge für alle konfigurierten Fahrzeuge von der
FZHSW abgeholt.
f) Help: Kurzhilfe
Menu Einstellungen:
a) Betriebsmodus: Es wird der Modus Test oder Deklaration eingestellt.
Im Modus Deklaration steht nur ein reduzierter Funktionsumfang zur Verfügung.
Betriebsart: Es wird die Betriebsart Online oder Offline eingestellt.
In der Betriebsart Online werden die Images in einem Zug von der FZHSW bezogen,
an die OBU geschickt und wieder zurück an die FZHSW geschickt.
b) Fahrzeuge: Es werden die Fahrzeuge und OBU BT Einstellungen konfiguriert.
Es werden die FZHSW Einstellungen eingestellt.
44/44
DA_Bericht_BLUDEC.doc