Leseprobe
Inhaltsverzeichnis
Abbildungsverzeichnis
Tabellenverzeichnis
Abkürzungsverzeichnis
I. Einleitung und Ziel der Arbeit
1. Einleitung
2. Ziel der Arbeit
II. Entwurf einer mobilen Client – Webserver – Infrastruktur als Demonstrator
1. Die heutigen technischen Möglichkeiten
1.1. Datenübertragungstechniken
1.1.1. GSM, GPRS und HSCSD
1.1.2. UMTS und HSDPA
1.2. Standortlokalisierungsverfahren
1.2.1. Netzwerkbasierte Verfahren
1.2.2. Verfahren, basierend auf dem mobilen Endgerät
2. Anforderungen an den mobilen Client
2.1. Verwendbare Hard- und Software
2.2. Benötigte Informationen für die Anzeige einer Ordnungswidrigkeit
2.3. Ablauf der digitalen Erfassung der benötigten Informationen
2.3.1. Art der Ordnungswidrigkeit wählen
2.3.2. Erfassung der spezifischen Informationen zur gewählten Ordnungswidrigkeit
2.3.3. Übermittlung der erfassten Anzeige an den Adressaten
2.3.4. Erfassung der persönlichen Daten des Anzeigenerstatters
3. Anforderungen an die Webserver-Software
3.1. Verwendung eines User-Management
3.1.1. Durchführung der Registrierungsprüfung
3.1.2. Registrierung eines neuen Benutzers
3.1.3. Durchführung der Authentifizierung
3.2. Ablage der übermittelten Daten zur Weiterbearbeitung
3.2.1. Ablage der übermittelten Anzeige
3.2.2. Ablage der übermittelten Bilddateien
3.2.3. Darstellung der eingegangenen Anzeigen inklusive der Beweisfotos
III. Implementierung des entworfenen Demonstrators
1. Die verwendete Testumgebung
1.1. Der mobile Client
1.2. Der Webserver
2. Das graphische User – Interface des mobilen Clients
2.1. Auswahl der anzuzeigenden Ordnungswidrigkeit
2.2. Erfassung der persönlichen Daten des Anzeigenerstatters
2.3. Erfassung der detaillierten Informationen zur Ordnungswidrigkeit
2.4. Übermittlung der Anzeige an den Adressaten
2.5. Archivierung der übermittelten Anzeigen
3. Vorbemerkungen zur Dokumentation
3.1. Die XmlTextWriter-Klasse
3.2. Das Document Object Model (DOM)
4. Beschreibung der Funktionalitäten der Client-Software
4.1. Abfragen und Überprüfungen beim Start der Anwendung
4.2. Erfassung und Verwaltung der persönlichen Daten des Anzeigenerstatters
4.2.1. Abfragen und Überprüfung bei der Verwaltung der persönlichen Benutzerdaten
4.2.2. Laden der persönlichen Benutzerdaten
4.2.3. Speichern der persönlichen Benutzerdaten
4.3. Start der Kameraanwendung
4.4. Ermittlung der spezifischen Informationen zur digitalen Erstellung der Anzeige
4.4.1. Bildauswahl abfragen
4.4.1.1. Anzeige der in einem Verzeichnis vorhandenen Bilddateien
4.4.1.2. Möglichkeit zur Änderung des Bildverzeichnisses
4.4.1.3. Möglichkeit zur Vorschau der ausgewählten Bilder
4.4.1.4. Anzahl ausgewählter Bilddateien überprüfen
4.4.2. Detailangaben abfragen
4.4.2.1. Ermittlung des Tatortes mithilfe der GPS-Lokalisierung
4.4.2.1.1. Abfragen und Überprüfungen beim Start der Standortlokalisierung
4.4.2.1.2. Laden und Speichern der Einstellungen für das GPS-Gerätes
4.4.2.1.3. Automatische Ermittlung der Einstellungen des GPS-Gerätes
4.4.2.1.4. Starten und Beenden der Kommunikation mit dem GPS-Gerät
4.4.2.1.5. Generierung der Klartextadresse aus den ermittelten Koordinaten
4.4.2.2. Abfragen und Überprüfungen bei der Erfassung der Detailinformationen
4.4.2.3. Überprüfung der eingegebenen Detailinformationen
4.4.2.4. Ermittlung der Anzahl der bereits für ein Kennzeichen übermittelten Anzeigen
4.4.2.5. Erstellen der Textvorlagen für den Freitext
4.4.3. Erzeugung und Speicherung der Anzeige
4.5. Überprüfung der Anzeige und Übermittlung an den Adressaten
4.5.1. Vorschau der zu sendenden Anzeige
4.5.2. Übermittlung der Anzeige an den Adressaten
4.5.2.1. Abfragen und Überprüfungen vor der Übermittlung der Anzeige an den Webserver
4.5.2.2. Überprüfung der Registrierung
4.5.2.3. Neuregistrierung eines Benutzers auf dem Webserver
4.5.2.4. Durchführung der Authentifizierung
4.5.2.5. Übermittlung der Anzeige an den Webserver
4.5.2.6. Übermittlung der Bilddateien an den Webserver
4.6. Archivierung der übermittelten Anzeige und notwendige Abschlussschritte
4.6.1. Die Anzeigenhistorie als Archiv
4.6.1.1. Die Erstellung der Anzeigenhistorie als XML-Datei
4.6.1.2. Der Aufruf der Anzeigenhistorie
4.6.2. Erstellung einer XML-Datei zur Ermittlung der Anzahl von Ordnungswidrigkeiten
4.6.3. Abschließende Abläufe nach erfolgreicher Übermittlung der Anzeige
5. Beschreibung der Funktionalitäten der Webserver-Software
5.1. Das User-Management
5.1.1. Überprüfung der Registrierung
5.1.2. Neuregistrierung eines Benutzers
5.1.3. Durchführung der Authentifizierung
5.2. Ablage der vollständigen Anzeige
5.2.1. Speichern der übermittelten Anzeige
5.2.2. Speichern der gesendeten Bilddateien
5.3. Notwendige Abläufe auf dem Webserver
5.3.1. Methode zur Durchführung der Netzlokalisierung
5.3.2. Methode zur Ermittlung der Mobilfunknummer anhand der gesendeten Kundenummer
5.3.3. Methode zur Ermittlung der Klartextadresse
5.3.4. Methode zur Erstellung einer XML-Datei mit den Pfadangaben der Anzeigen
5.4. Darstellung der eingegangenen Anzeigen inklusive der Beweisfotos
IV. Mögliche Kritikpunkte an der technischen Lösung
V. Erweiterungsmöglichkeiten
VI. Fazit
Literaturverzeichnis
Anhang
Abbildungsverzeichnis
Abbildung 1: Anwendungsfalldiagramm des zu entwickelnden Demonstrators
Abbildung 2: Screenshot der Auswahl der anzuzeigenden Ordnungswidrigkeit
Abbildung 3: Screenshot der Erfassung der persönlichen Benutzerdaten
Abbildung 4: Screenshot der Auswahl eines Beweisfotos
Abbildung 5: Screenshot des Verzeichniswechsels für die Bildauswahl
Abbildung 6: Screenshot der Standortermittlung per GPS
Abbildung 7: Screenshot der Eingabe der detaillierten Angaben zur Ordnungswidrigkeit
Abbildung 8: Screenshot der Vorschau der Anzeige vor der Übermittlung an den Webserver
Abbildung 9: Screenshot der Übermittlung der Anzeige an den Webserver
Abbildung 10: Screenshot der Darstellung der Historie
Abbildung 11: Ausschnitt Sequenzdiagramm Client: Abläufe inklusive der Bilddateiauswahl
Abbildung 12: Die persönlichen Benutzerdaten als XML-Datei
Abbildung 13: Ausschnitt Sequenzdiagramm Client: Ermittlung aller Detailangaben
Abbildung 14: Die auf dem Client erstellte Anzeige als XML-Datei
Abbildung 15: Ausschnitt Sequenzdiagramm Client: Übermittlung der Anzeige an den Adressaten
Abbildung 16: Die Historie als XML-Datei
Abbildung 17: Die Häufigkeitsermittlung als XML-Datei
Abbildung 18: Ausschnitt Sequenzdiagramm Webserver: User-Management
Abbildung 19: Ausschnitt Sequenzdiagramm Webserver: Ablage der übermittelten Anzeige
Abbildung 20: Die auf dem Webserver gespeicherte Anzeige als XML-Datei
Tabellenverzeichnis
Tabelle 1: Übersicht der verwendeten Hard- und Software für den mobilen Demonstrator 20
Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
Hinweis
Es wird darauf hingewiesen, dass die in dieser Arbeit verwendeten Soft- und Hardwarebezeichnungen sowie Markenamen der jeweiligen Firmen dem allgemeinen Markenschutz unterliegen. Die jeweilige Marken- und Warenzeichen sind Eigentum der betreffenden Firmen.
I. Einleitung und Ziel der Arbeit
1. Einleitung
Die Teilnahme am Straßenverkehr erfordert die Einhaltung zweier Grundregeln:
Zum einen gegenseitige Rücksichtnahme und zum anderen ein Verhalten, das keinen anderen schädigt, gefährdet, behindert oder belästigt.[1]
Die Realität sieht in den deutschen Großstädten hingegen anders aus. Beispielsweise kam es in Frankfurt am Main im Jahr 2003 zu insgesamt 3219 verunglückten[2] Personen, wovon circa ein Drittel[3] Fußgänger und Radfahrer waren. 17 Fußgänger kamen dabei sogar ums Leben.[4]
Ein Grund für diese Entwicklung könnte die zunehmende Anzahl der Personenkraftwagen in den Innenstädten[5] sein, was wiederum zu einem stetig ansteigenden Parkdruck führt. Resultierend aus diesem wachsenden Parkdruck kommt es immer häufiger zu Behinderungen der „schwächeren“ Verkehrsteilnehmer im Straßenverkehr – den Fußgängern und Fahrradfahrern.
Sie sind teilweise bei völliger Blockierung ihres jeweiligen Verkehrsweges (Gehweg oder Radweg) gezwungen, diesen gänzlich zu verlassen und auf den einzig übrig bleibenden Verkehrsweg, die Strasse auszuweichen. Dadurch erhöht sich das Risiko von schweren Unfällen, einhergehend mit erheblichen Verletzungen bis hin zu Todesfällen.
Darüber hinaus kommt es durch solche Ordnungswidrigkeiten im ruhenden Verkehr immer wieder zu Behinderungen beim Einsatz von Rettungskräften, was wiederum direkte Auswirkungen auf Menschenleben haben kann. Dieser Ansicht war offensichtlich auch der Gesetzgeber, der den Tatbestand solcher Ordnungswidrigkeiten aus dem Rahmen der Geringfügigkeit herausnahm. Wer nun an engen Stellen oder Kurven parkt und dadurch ein Rettungsfahrzeug behindert erhält nicht mehr maximal 35,00 Euro Verwarngeld, sondern sofort 40,00 Euro Bußgeld und einen Punkt im Zentralregister.[6]
Zusätzlich könnte eine nur beschränkt mögliche Anwendung beziehungsweise Durchführung von gesetzlichen Regelungen zur Überwachung des Straßenverkehrs verantwortlich für die gerade geschilderte Situation sein.
Es existieren zwar ausreichend anwendbare gesetzliche Regelungen[7] zur Durchführung der Verkehrssteuerung und -überwachung, um dieser Entwicklung entgegenzuwirken. Eine flächendeckende Anwendung, wodurch eine konsequente Ahndung und dadurch wiederum ein Sinken des Unfallrisikos erreicht werden könnte, scheitert allerdings meist schon an den geringen personellen Kapazitäten der zuständigen Ordnungsbehörden.[8]
Aufgrund dieser nur beschränkt möglichen Anwendung der gesetzlichen Regelungen durch die Ordnungsbehörden entwickelte sich im Laufe der Jahre eine scheinbar immer größere Ausnutzung dieser Rechtssituation durch die Verkehrsteilnehmer, die eine Ordnungswidrigkeit im ruhenden Verkehr begehen, da nicht alle von ihnen aufgrund der gerade beschriebenen personellen Situation zur Verantwortung gezogen werden konnten.
Zudem erweckt diese momentan vorherrschende Situation den Eindruck, dass ganz bewusst Ordnungswidrigkeiten im ruhenden Verkehr begangen werden, in der Gewissheit nicht dafür belangt zu werden.
Ziel ist es, eine effizientere Verkehrsüberwachung der Ordnungsbehörden zu ermöglichen und dem entgegenzuwirken. Dabei ist unter dem Begriff Effizienz ein möglichst geringer Aufwand zur Erreichung eines in definierter Qualität vorgegebenen Nutzens zu verstehen.[9]
Als ein in definierter Qualität vorgegebener Nutzen wird im vorliegenden Fall die Verfolgung von Verkehrsverstößen im ruhenden Verkehr durch die Anzeige einer Ordnungswidrigkeit betrachtet. Hierdurch entsteht für die Verkehrsteilnehmer, die negativ von der vorherrschenden Situation betroffen sind ein wesentlicher Nutzen. Des Weiteren kann die manuelle Erfassung der notwendigen Informationen für die Anzeige als Aufwand (vor allem die benötige Zeit für die Erfassung) betrachtet werden.
Eine technische Lösung die das Anzeigen einer Ordnungswidrigkeit im ruhenden Verkehr an Ort und Stelle – durch Verwendung von Location Based Services und Mobilfunk – bei der zuständigen Ordnungsbehörde ermöglicht, könnte somit als effizientere Möglichkeit zur Erreichung des definierten Ziels gewertet werden, als die momentan vorherrschende Situation.[10]
Der betroffene Verkehrsteilnehmer, zum Beispiel ein Fahrradfahrer der durch einen falsch parkenden PKW an der Weiterfahrt gehindert wird, könnte an Ort und Stelle ein Beweisfoto der Ordnungswidrigkeit mit seinem mobilen Endgerät schießen. Anschließend hätte er die Möglichkeit diese Ordnungswidrigkeit durch Übermittlung des Beweisfotos – ergänzt um alle benötigten Informationen – direkt an die Ordnungsbehörde zu melden.
2. Ziel der Arbeit
Das Ziel der Diplomarbeit ist die Entwicklung und Spezifikation einer technischen Lösung als M-Government-Anwendung auf Grundlage des Mobilfunks mit Location Based Services, um den Ordnungsbehörden eine technische Infrastruktur zur Verfügung zu stellen, die es ihnen ermöglicht, der oben beschriebenen vorherrschenden Situation entgegenzuwirken.
Diese Infrastruktur könnte die Möglichkeit eines effizienteren Ablaufs der Erfassung und Ahndung von Verkehrsordnungswidrigkeiten ermöglichen. Beginnend mit der Aufnahme einer Verkehrsordnungswidrigkeit mittels mobilen Endgeräten, Übermittlung der erfassten Anzeige per Mobilfunk und letztlich Speicherung der Daten in einer Datenbank. Der gesamte Ablauf kann hierbei vollständig digital realisiert werden.
Zudem eröffnet diese Infrastruktur die Möglichkeit, Verkehrsordnungswidrigkeiten direkt durch den betroffenen Verkehrsteilnehmer selbst an die Ordnungsbehörde zu melden. Es müsste jederzeit damit gerechnet werden, dass die begangene Ordnungswidrigkeit direkt angezeigt wird. Hierdurch könnte die Effizienz der Verkehrskontrolle durch die Ordnungsbehörden ebenfalls erhöht werden.
Die durch das Vorhandensein einer solchen M-Government-Anwendung resultierende latente „Gefahr“, immer und überall für eine Verkehrsordnungswidrigkeit zur Verantwortung gezogen zu werden, würde somit das Risiko für eine begangene Ordnungswidrigkeit belangt zu werden, deutlich steigern.
Der Schwerpunkt der Diplomarbeit liegt in der Erfassung der Anforderungen und Spezifikation, sowie der Entwicklung einer Testumgebung für eine solche technische Lösung als Demonstrator.
In diesem Rahmen wird zum einem eine Client-Software für ein mobiles Endgerät in einer geeigneten Programmiersprache entwickelt.
Der Benutzer („Fußstreife“ bzw. betroffener Verkehrsteilnehmer) startet diese Anwendung auf seinem mobilen Endgerät und erfasst die benötigten Informationen, um die Ordnungswidrigkeit sofort anzuzeigen. Zusammen mit einem zum Beweiszweck dienenden Foto, den Zeitangaben (Datum und Uhrzeit), sowie den ermittelten Standortdaten wird die erfasste Anzeige per Webservice an die Ordnungsbehörde gesendet.
Zum anderen wird eine Webserver-Software erstellt, deren Aufgabe der Empfang und die Ablage der übermittelten Anzeigen darstellen.
Hierfür wird zunächst ein User-Management benötigt, um zu gewährleisten, dass lediglich registrierte Benutzer den Dienst verwenden können. Anschließend müssen die gesendeten Daten einer Anzeige auf ihre Widerspruchsfreiheit bezüglich der Standortinformation überprüft werden. Dies kann durch eine obligatorische Netzlokalisierung realisiert werden, welche als unabhängige Dritte Partei den Standort verifiziert. Die eingegangenen Anzeigen werden abschließend zusammen mit dem übermittelten Beweisfoto zur weiteren Bearbeitung systematisch abgelegt.
Der Ablauf der Software wird mittels UML[11] erfasst und beschrieben. Insbesondere werden die Abläufe anhand von Sequenzdiagrammen dargestellt und erläutert.
II. Entwurf einer mobilen Client – Webserver – Infrastruktur als Demonstrator
Für die Entwicklung der oben erläuterten technischen Lösung eignet sich eine mobile Client-Webserver-Infrasruktur.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: Anwendungsfalldiagramm des zu entwickelnden Demonstrators
Dies ergibt sich aus der Tatsache, dass den betroffenen Verkehrsteilnehmern – vor allem Fußgängern und Fahrradfahrern – am Tatort der Ordnungswidrigkeit keine anderen technischen Geräte außer einem mobilem Endgerät für die Erfassung der Anzeige zur Verfügung stehen. Zudem verfügen diese über die Möglichkeit, die Anzeige der Ordnungswidrigkeit sofort an die zuständige Ordnungsbehörde zu übermitteln.
Als Kommunikationspartner, auf der Seite der zuständigen Verwaltungsbehörde, ist die Verwendung eines Webservers geeignet. Allgemein versteht man unter einem Webserver einen Prozess, der Daten über das HTTP-Protokoll zur Verfügung stellt. Dabei stellt ein mobiles Endgerät, das als Client fungiert, eine Anfrage (HTTP-Request) an den Webserver, der diese wiederum verarbeitet und die resultierenden Daten zurückgibt (Response).[12]
Auf diese Art und Weise kann eine Kommunikation mit dem mobilen Endgerät ermöglicht werden. Zudem kann hierdurch erreicht werden, dass die Anzeige zu jeder Zeit übermittelt werden kann und dass die abgelegte Anzeige nicht erst manuell eingegeben werden muss, sondern bereits in digitaler Form existiert. Dies könnte darüber hinaus die Weiterbearbeitung der eingegangenen Anzeige deutlich vereinfachen beziehungsweise erleichtern.
Für die Identifizierung der benötigten technischen Anforderungen an die Client-Webserver-Infrastruktur, insbesondere an den mobilen Client, müssen vorher die heutzutage gegebenen technischen Möglichkeiten in Bezug auf mobile Datenübertragung und Standortlokalisierung untersucht werden.
1. Die heutigen technischen Möglichkeiten
1.1. Datenübertragungstechniken
Für die sofortige Übermittlung der erfassten Anzeige muss das mobile Endgerät über einen Datenübertragungsstandard verfügen.
Die heutigen Möglichkeiten, Daten mobil zu übertragen umfassen zum einen die Übertragung per GSM, die Verwendung von GPRS beziehungsweise HSCSD oder die Nutzung von UMTS beziehungsweise HSDPA.
Nachfolgend wird kurz auf die jeweiligen Funktionsweisen eingegangen und nach Abwägung der Vor- und Nachteile eine der Datenübertragungsmöglichkeiten für den mobilen Client ausgewählt.
1.1.1. GSM, GPRS und HSCSD
Die Übertragung von Daten über das GSM-Mobilfunknetz ist auf 9,6 kBit/s beziehungsweise auf maximal 14 kBit/s begrenzt, da dieses Netz vorrangig für die Sprachübermittlung und nicht für die Datenübertragung konzipiert wurde und daher lediglich einen der verfügbaren acht Kanäle nutzt.[13]
Aufgrund der Tatsache, dass die Datenübertragung immer mehr in den Vordergrund gerückt ist, wurden mittlerweile zwei Erweiterungen innerhalb des GSM-Mobilfunknetzes eingeführt, die die Bündelung von mehreren Kanälen ermöglichen.
Die erste Erweiterung ist der GPRS-Datenübertragungsstandard. Diese Technologie nutzt zum einen die Kanalbündelung, um höhere Datenübertragungsraten zu erreichen und zum anderen wird die IP-Technologie verwendet.
Bei einer maximalen Bündelung der acht GSM-Funkkanäle[14] ließe sich damit die Datenübertragungsrate theoretisch auf 171,2 kBit/s erhöhen.[15] In der Praxis ist die Übertragungsrate hingegen auf 53,6 kBit/s beschränkt. Je nachdem, welche GPRS-Klasse das mobile Endgerät unterstützt, unterscheidet sich aufgrund der genutzten Kanäle, die Höhe der maximal möglichen Übertragungsraten. Wird beispielsweise die Klasse 10 unterstützt, bedeutet das, dass für das Versenden von Daten maximal zwei Kanäle (maximal circa 26 kBit/s)[16] und für deren Empfang maximal vier Kanäle (maximal circa 53,6 kBit/s) verwendet werden können.[17]
HSCSD verwendet, ebenso wie GPRS die Kanalbündelung zur Erhöhung der Übertragungsrate.[18] Auch in diesem Fall ist theoretisch die Bündelung von acht Känalen möglich. In der Praxis ist lediglich die Bündelung von vier Kanälen in der Kombination zwei zu zwei oder eins zu drei für das Senden und Empfangen von Daten realisiert.
Der Vorteil gegenüber GPRS ist jedoch die garantierte Bandbreite der Übertragungsgeschwindigkeit. Solange eine Verbindung mit dem Netzt besteht, werden die notwendigen Kanäle reserviert.[19] Allerdings wird die Datenübertragung nach der verwendeten Zeit abgerechnet, das heißt man bekommt auch die Zeit abgerechnet, in der kein Datenverkehr stattfindet (beispielsweise beim Warten auf die Antwort eines Webservers).[20]
1.1.2. UMTS und HSDPA
Der Mobilfunkstandard UMTS stellt ein neues Übertragungsverfahren dar, welches erstmals Sprach- und Datenübertragung miteinander vereint.
Eines der Ziele bei der Einführung von UMTS war die Ermöglichung der Übertragung großer Datenmengen. Durch UMTS ist eine Übertragungsrate von maximal 2 Mbit/s theoretisch möglich. In der Praxis werden hingegen „lediglich“ 384 kBit/s zur Verfügung gestellt, was allerdings immer noch der 40fachen GSM-Geschwindigkeit entspricht.[21]
Der wesentliche Unterschied zu GSM ist die verwendete Technik für die Übertragung der Daten. Während bei GSM das Zeitmultiplex (TDMA)[22] verwendet wird, bildet bei UMTS das Codemultiplex (CDMA)[23] die Grundlage für die Übertragung.[24] Die Verwendung von UMTS ermöglicht es beispielsweise ein Farbbild von 72 KB Größe in etwa 1,6 Sekunden zu versenden.[25]
Darüber hinaus ist mit HSDPA bereits die nächste Entwicklungsstufe erreicht worden. Diese Mobilfunktechnik basiert auf den UMTS-Netzen und ermöglicht maximale Übertragungsraten von 14,4 Mbit/s.[26] Allerdings beschleunigt HSDPA lediglich den Datenempfang auf UMTS-fähigen Endgeräten, so dass die Geschwindigkeit des Datenversands gleich bleibt.[27]
Vergleicht man nun die vorstehenden Datenübertragungsverfahren miteinander und beachtet hierbei, dass beim Client mehr die Übermittlung der Daten, als der Empfang im Vordergrund steht, so ist es bei Verwendung des GSM-Mobilfunknetzes unerheblich, welche der beiden möglichen Datenübertragungsstandards verwendet werden. In beiden Fällen ist eine maximale Datenübertragungsrate von circa 26 kBit/s erreichbar und beide Verfahren haben sowohl Vor- als auch Nachteile.
Anstelle des GSM-Mobilfunknetzes kann auch das UMTS-Mobilfunknetz als Datenübertragungsstandard verwendet werden. Momentan liegt jedoch der gravierende Nachteil dieser Verwendung in der geringen Verfügbarkeit von Endgeräten zur Nutzung dieser Technik, so dass die Verwendung von UMTS momentan ausscheidet. Aufgrund der Tatsache, dass HSDPA lediglich den Datenempfang im UMTS-Mobilfunknetz beschleunigt und die Geschwindigkeit des Datenversands gleich bleibt, hat die Entwicklung dieses Standards keinerlei Relevanz für die Auswahl eines Datenübertragungsstandards.
Neben einem Datenübertragungsstandard muss der Client auch über eine Technik verfügen, die es ermöglicht dessen Standort zu lokalisieren und somit einen Location Based Service zu realisieren.
1.2. Standortlokalisierungsverfahren
Man unterscheidet die vorhandenen Lokalisierungsverfahren grundsätzlich nach zwei Gesichtspunkten. Zum einen existieren Verfahren, deren Technik auf dem Mobilfunknetz basieren, zum anderen basiert die verwendete Technik auf dem mobilen Endgerät selbst. Hierzu zählen überwiegend die satellitengestützten Lokalisierungsverfahren, wie Global Positioning System (GPS) und Assisted-GPS (A-GPS).[28]
Nachfolgend wird eine Auswahl der technisch möglichen Verfahren kurz erläutert, wobei lediglich die wichtigsten Abläufe zur Unterscheidung der einzelnen Verfahren dargestellt werden.
1.2.1. Netzwerkbasierte Verfahren
Zu dieser Gruppe von Lokalisierungsverfahren zählen unter anderem das Cell of Origin (COO), das Enhanced Observed Time Difference (E-OTD), sowie das Time Difference of Arrival (TDOA) und Time of Arrival (TOA).
Beim COO handelt es sich um eine Netzlokalisierung. Dabei wird durch den Mobilfunkbetreiber diejenige Funkzelle identifiziert, in welcher sich das mobile Endgerät gerade an einer Basisstation (BTS) angemeldet hat.[29] Die Genauigkeit dieses Verfahrens beträgt je nachdem, wo sich das zu lokalisierende Objekt gerade befindet, zwischen 150 Metern und ca. 35 Kilometern[30].
Der bedeutende Vorteil dieses Verfahrens liegt einerseits darin, dass keinerlei technische Erweiterungen an den mobilen Endgeräte beziehungsweise des Mobilfunknetzes notwendig werden und andererseits in der schnellen Lokalisierung des mobilen Endgerätes.[31]
Ein weiteres netzwerkbasiertes Verfahren ist das E-OTD. Die Datenermittlung für die Standortbestimmung erfolgt dabei allerdings hauptsächlich durch das mobile Endgerät. Es misst die Laufzeit des Funksignals von drei verschiedenen benachbarten BTS und berechnet hieraus die Laufzeitunterschiede der Signale. Dieses Ergebnis wird abschließend an eine zentrale Auswerteeinheit übermittelt, die daraufhin den Standort des mobilen Endgerätes ermittelt.[32]
Das E-OTD führt zwar zu einer höheren Genauigkeit (zwischen 50 und 125 Meter), als das COO, allerdings hat es eine längere Antwortzeit und eine modifizierte Software für das mobile Endgerät wird benötigt. Ein weiterer Nachteil dieses Verfahrens ist die Problematik des Signalempfangs von drei BTS in ländlichen Gebieten, da diese unter Umständen kilometerweit von einander entfernt stehen können.[33]
Das Time Difference of Arrival ist das am längsten verwendete Lokalisierungsverfahren und wird heutzutage zusammen mit den GPS angewendet.[34]
Auch bei diesem Verfahren existiert eine zentrale Auswerteeinheit. Allerdings bekommt sie nicht die ermittelten Laufzeitunterschiede von dem mobilen Endgerät übermittelt, sondern erhält von den drei betreffenden BTS jeweils die Laufzeit zugesendet, die das Funksignal vom mobilen Endgerät an die jeweilige BTS benötigt hat.
Aufgrund der bekannten Geschwindigkeit des Funksignals, wird aus den gemessenen Laufzeiten von zwei BTS eine Hyperbel um diejenige BTS konstruiert, die das Signal zuerst empfangen hat. Unter Berücksichtigung des Laufzeitunterschiedes von allen drei BTS wird abschließend der Standort des mobilen Endgerätes berechnet.[35]
Der Vorteil dieses Verfahren liegt darin, dass die Genauigkeit der Standortberechnung nicht von der Entfernung des mobilen Endgerätes zur BTS beeinflusst wird. Zudem liefert es etwas genauere Messergebnisse, als beim COO erzielt werden. Nachteilig wirkt sich die Tatsache aus, dass mindestens drei BTS für die Ortung benötigt werden und dass die Antwortzeit deutlich über denen des E-OTD und des COO liegt.[36]
Das letzte Verfahren in dieser Aufzählung ist das Time of Arrival. Bei diesem Verfahren werden, im Gegensatz zum TDOA, nicht die Laufzeitunterschiede, sondern die Laufzeiten des Funksignals ermittelt. Zu diesem Zweck sendet das mobile Endgerät ein Signal aus, das von drei BTS empfangen wird. Die Position wird anschließend aufgrund der Differenz dieser Laufzeiten ermittelt.
Ein schwerwiegender Nachteil dieses Verfahrens sind die durch notwendige Netzwerkerweiterungen entstehenden Kosten. Diese werden auf das etwa 10fache der Kosten von E-OTD geschätzt.[37]
1.2.2. Verfahren, basierend auf dem mobilen Endgerät
Neben den gerade erläuterten netzwerkbasierten Lokalisierungsverfahren existiert als Verfahren, welches auf dem mobilen Endgerät basiert, das GPS-Lokalisierungsverfahren. Hierbei wird die Position mittels Satelliten bestimmt.[38]
Das Prinzip der Lokalisierung mittels Satelliten lässt sich folgendermaßen darstellen. Um den geometrischen Ort eines Punktes in einem Raum zu ermitteln, benötigt man grundsätzlich drei Entfernungen zu drei Bezugspunkten (hier: die Satelliten).[39] Das Prinzip der GPS-Lokalisierung beruht auf der Messung eines Signals zwischen dem Bezugspunkt (Satelliten) und dem zu lokalisierenden Objekt (GPS-Gerät). Das Messsignal wird durch die Satelliten ausgestrahlt und durch das GPS-Gerät empfangen. Die Genauigkeit der Lokalisierung bestimmt sich dabei durch die Genauigkeit der Entfernungsmessung, welche wiederum von der Genauigkeit der verfügbaren Zeitbasis abhängig ist. Entscheidend ist, dass die Uhren sowohl beim Satelliten, als auch beim zu lokalisierenden Objekt mit hoher Genauigkeit synchron laufen. Um den, aufgrund technischer Bedingungen bei dem zu lokalisierenden Objekt, auftretenden Zeitunterschied zu eliminieren, wird ein vierter Satellit benötigt. Dieser dient ausschließlich dazu, die vorhandenen Zeitunterschiede zu erfassen und den dadurch entstehenden Messfehler zu korrigieren.[40]
Aus der Laufzeit und der Geschwindigkeit (Lichtgeschwindigkeit) des Signals wird abschließend die gesuchte Entfernung berechnet.
Der Vorteil dieses System liegt in der hohen Genauigkeit des Ergebnisses und der weltweiten Verfügbarkeit der Satelliten. Durch die Anordnung der insgesamt 24 Satelliten ist an jedem Punkt der Erde der Empfang der Signale von mindestens vier Satelliten gewährleistet.[41]
Von großem Nachteil ist allerdings die zwingend optische Verfügbarkeit der für die Lokalisierung benötigten Satelliten. Eine Verwendung des Verfahrens ist demnach in Gebäuden oder Straßenschluchten ausgeschlossen. Hinzukommt, dass dieses Verfahren auf eine gewisse Signalstärke der Satelliten angewiesen ist.[42]
Zudem untermauert die Ankündigung der Siemens AG im Herbst 2005 ein marktreifes Assisted-GPS System zur Verfügung zu stellen, welches in allen Mobilfunknetzen ohne Eingriff in das bestehende Netz funktioniert, die Annahme, dass GPS sich in den kommenden Jahren zum genauesten und am häufigsten verwendete Lokalisierungsverfahren entwickelt.[43]
Aus diesen Gründen ist die Implementierung des GPS-Verfahrens zur Lokalisierung des aktuellen Standorts des Client allen anderen möglichen Verfahren vorzuziehen. Aufgrund der tatsächlichen Verfügbarkeit bietet sich im Rahmen des zu entwickelnden Demonstrators lediglich das netzwerkbasierte Verfahren COO zur Verifizierung der GPS-Koordinaten an.
2. Anforderungen an den mobilen Client
2.1. Verwendbare Hard- und Software
Zunächst ist festzustellen, welche Anforderungen an die verwendbare Hard- und Software für den Client zu stellen sind.
Für den zu entwickelnden Demonstrator wäre die Verwendung eines mobilen Endgerätes ideal, welches sowohl mit einer integrierten Digitalkamera ausgestattet ist, um die notwendigen Beweisfotos machen zu können, als auch ein integriertes GPS-Gerät zur Ermöglichung der Standortlokalisierung besitzt und die TCP/IP-Datenübertragung zur Übermittlung der Anzeige ermöglicht.
Das Vorhandensein einer digitalen Kamera hat den Vorteil, dass ein Foto die Sachlage vor Ort klar und deutlich beweisen kann und nur wenig Raum für Vermutungen, Spekulationen oder Unterstellungen lässt.
Problematisch ist jedoch, dass bis dato auf dem Markt für mobile Endgeräte noch kein frei verkäufliches Gerät, welches alle drei Hardwarebedingungen gleichzeitig erfüllt, existiert.[44] Es gibt lediglich diverse mobile Endgeräte, die eine integrierte Digitalkamera besitzen und die TCP/IP-Datenübertragung unterstützen.[45]
Aus diesem Grund reicht ein PDA[46] bzw. Smartphone[47] nicht aus, sondern es muss zusätzlich auf ein externes GPS-Gerät zurückgegriffen werden. Beide Geräte zusammen finden dann als mobiler Client Verwendung.
Die Client-Software muss in einer Programmiersprache entwickelt werden, die auf einem Betriebssystem für mobile Endgeräte ausgeführt werden kann und gleichzeitig für eine möglichst große Auswahl an mobilen Endgeräten Anwendung findet.
Als zugrunde liegendes Betriebssystem kommen das Symbian OS, das PalmOS, sowie Windows CE in Betracht. Bei dieser Auswahl handelt es sich um die am Markt für mobile Endgeräte etablierten Betriebssysteme.[48]
Ein Betriebssystem wird grundsätzlich bereits bei der Auswahl der Hardware festgelegt, da jeder Hersteller eines mobilen Endgerätes das verwendete Betriebssystem an seine Bedürfnisse anpasst. Somit wird bereits durch die Hardwareauswahl auch die verwendbare Programmiersprache definiert.
Microsoft stellt beispielsweise für die Programmierung von mobilen Anwendungen, insbesondere für Betriebssysteme, basierend auf Windows CE, das .NET Compact Framework zur Verfügung.[49] Es ist speziell für die Ausführung von Anwendungen auf mobilen Endgeräten mit beschränkten Ressourcen entwickelt worden.
Als Programmiersprachen für die Softwareentwicklung innerhalb des .NET Compact Frameworks kommen sowohl C# .NET, als auch Visual Basic .NET in Betracht.
Für die zu erstellende Webserver-Software kann dieselbe Programmiersprache benutzt werden, da sie auf Grundlage des .NET Frameworks entwickelt werden kann, von dem das .NET Compact Framework eine Teilmenge ist.
2.2. Benötigte Informationen für die Anzeige einer Ordnungswidrigkeit
Nachdem die notwendigen Hard- und Softwareanforderungen festgelegt sind, folgt die Ermittlung der für die Anzeige einer Ordnungswidrigkeit benötigten Informationen.
Diese können über das im Internet verfügbare Anzeigenformular der Stadt Frankfurt am Main ermittelt werden.[50]
Das Formular wurde für die Anzeige einer Ordnungswidrigkeit durch eine Privatperson veröffentlicht und muss demnach alle für die Ordnungsbehörden relevanten Informationen enthalten, um eine Anzeige erstatten zu können.[51]
Aufgrund dieses herangezogenen Formulars wird die Gesamtheit der darauf benötigten Informationen in insgesamt vier Informationsblöcke unterteilt.
Den ersten Block an benötigten Informationen stellen die persönlichen Daten der Anzeigenerstatterin beziehungsweise des Anzeigenerstatters dar. Hierzu zählen der Name und der Vorname, die Straße und Hausnummer, die Postleitzahl und der Ort (darüber hinaus kann auch die Telefonnummer, die Faxnummer und / oder die Emailadresse angegeben werden).
Unter diesen Block fällt auch die Kenntnisnahme der rechtlichen Konsequenzen, die sich aus der Erstattung einer Anzeige ergeben.
Der Anzeigende muss deshalb einerseits versichern, dass die gemachten Angaben vollständig und richtig sind. Andererseits muss er sich darüber bewusst sein, dass er als Zeuge der angezeigten Ordnungswidrigkeit zur wahrheitsgemäßen Aussage verpflichtet ist[52] und auf Nachfrage zur Sache, gegebenenfalls auch vor Gericht, aussagen muss.[53]
Den zweiten Informationsblock bildet die Art der Ordnungswidrigkeit. Gemäß dem Anzeigenformular können vier Arten von Ordnungswidrigkeiten bei der Ordnungsbehörde angezeigt werden: „Kleinabfälle nicht in den Abfallbehälter eingebracht“, „Abstellen von Speermüll ohne Abholungstermin der FES“, „Abstellen von Speermüll nicht zum Abholungstermin der FES“ und „Sonstiges“.
Unter den letztgenannten Punkt fällt die Anzeige einer Verkehrsordnungswidrigkeit im ruhenden Verkehr, da dies eine Ordnungswidrigkeit[54] darstellt und somit der Ordnungsbehörde angezeigt werden kann.
Zum dritten Block gehören die spezifischen Informationen zur Ordnungswidrigkeit. Hierunter fallen die Tatzeit, der Tatort, Angaben zum Verursacher, sowie eventuell vorhandene Zeugen. Des Weiteren gehört die Sachverhaltsschilderung zu diesem Informationen. Diese dient dazu, zusätzliche bzw. konkretisierende Informationen zu der Ordnungswidrigkeit zu erfassen.
Block vier beinhaltet die letzte Information: den Adressaten der Anzeige. Im vorliegenden Fall ist das die zuständige Ordnungsbehörde, bei welcher die Anzeige eingereicht werden muss.
Nach Identifizierung der für eine Anzeige erforderlichen Informationen, wird darauf aufbauend ein zeitlicher Ablauf zur Erfassung dieser Informationen entwickelt.
2.3. Ablauf der digitalen Erfassung der benötigten Informationen
Dieser Vorbereitungsschritt legt gleichzeitig den Ablauf der zu entwerfenden Client-Software fest und muss daher sorgfältig durchgeführt werden, um eine hohe Benutzerfreundlichkeit zu erreichen.
2.3.1. Art der Ordnungswidrigkeit wählen
Generell sollte als erstes die Art der anzuzeigenden Ordnungswidrigkeit per Auswahl abgefragt werden, damit der Umfang der im weiteren Verlauf benötigten Informationen dementsprechend festgelegt werden kann.
Die verschiedenen Arten von Ordnungswidrigkeiten finden zwar in einer Auflistung Berücksichtigung, auf eine Auswahlmöglichkeit soll jedoch verzichtet werden, da dies im vorliegenden Fall für die Erreichung des Ziels irrelevant ist.
Im Rahmen des zu entwickelnden Demonstrators wird daher lediglich die Anzeige einer Verkehrsordnungswidrigkeit im ruhenden Verkehr möglich sein.
2.3.2. Erfassung der spezifischen Informationen zur gewählten Ordnungswidrigkeit
Nach Auswahl der Ordnungswidrigkeit sollte dem Benutzer die Möglichkeit gegeben werden, die Erfassung der Beweisfotos mithilfe der Kamera durchzuführen. Diese Möglichkeit sollte direkt beim Start der Anwendung vorliegen, so dass gegebenenfalls das benötigte Beweisfoto sofort gemacht werden kann.
Daran anschließend sollten die gemachten Beweisfotos vom Benutzer ausgewählt werden können. Der Vorteil in dieser Vorgehensweise liegt darin, dass der Benutzer gleich entscheiden könnte, ob das soeben gemachte Beweisfoto Verwendung finden soll. Für den Fall, dass der Benutzer mit den aktuellen Beweisfotos nicht zufrieden ist, könnten sofort neue Beweisfotos gemacht werden.
Der nächste Schritt muss die Erfassung der spezifischen Informationen bezüglich der Ordnungswidrigkeit darstellen. Da diese Daten vollständig vorhanden sein müssen, lässt sich die Reihenfolge in keiner Weise benutzerfreundlicher gestalten bzw. optimieren.
Die Verwendung der GPS-Lokalisierung für die Ermittlung des Tatortes würde jedoch zu einer deutlichen Steigerung der Benutzerfreundlichkeit führen, da der Benutzer auf der einen Seite nicht immer den Namen der Straße kennt, auf der er sich gerade befindet. Auf der anderen Seite würde das Verfahren dem Benutzer die manuelle Eingabe der Adressdaten ersparen.
Durch die dargestellte Reihenfolge der Erfassung könnte somit sichergestellt werden, dass eine vorherige nutzlose Eingabe spezifischer Informationen bei Unbrauchbarkeit des Beweisfotos entfällt.
2.3.3. Übermittlung der erfassten Anzeige an den Adressaten
Nach Erfassung aller Informationen kann sich nur die Übermittlung der Anzeige an den Webserver anschließen. Vorher sollte dem Benutzer allerdings die Gelegenheit gegeben werden, die erfassten Informationen zu überprüfen und gegebenenfalls die Übermittlung an dieser Stelle abzubrechen.
2.3.4. Erfassung der persönlichen Daten des Anzeigenerstatters
Vor Übermittlung der Anzeige müsste zunächst das Vorhandensein der persönlichen Daten des Anzeigenerstatters sichergestellt werden. Sinnvoll wäre es, wenn der Benutzer bei Nichtvorhandensein einen Hinweis darüber erhält, dass ein Anzeigenversand, solange die persönlichen Daten nicht hinterlegt wurden, nicht stattfinden kann.
Eine einzige Prüfung direkt vor der Übermittlung der Anzeige würde jedoch nicht ausreichen. Wurden die Daten vom Benutzer noch nicht hinterlegt, würde das zu einem insgesamt höheren Zeitaufwand für den Prozess als Ganzes führen und die Benutzerfreundlichkeit würde darunter leiden. Darüber hinaus könnte es auch vorkommen, dass die persönlichen Daten nach Hinterlegung versehentlich gelöscht wurden.
Aus diesen Gründen sollte grundsätzlich bereits beim Start der Anwendung eine Überprüfung des Vorhandenseins der persönlichen Daten stattfinden.
Die Anforderungen an die Client-Software sind damit vollständig aufgeführt, so dass nun noch die Anforderungen an die Webserver-Software ausstehen.
3. Anforderungen an die Webserver-Software
Zunächst müsste auf dem Webserver ein User-Management bereitgestellt werden, da die anonyme Anzeige einer Ordnungswidrigkeit nicht möglich sein darf.
In dessen Rahmen sollte die Überprüfung der Registrierung eines Benutzers erfolgen. Für den Fall, dass ein Benutzer noch nicht registriert ist, müsste durch das User-Management eine Neuregistrierung ermöglicht werden. Nach erfolgreicher Registrierungsprüfung beziehungsweise nach erfolgter Neuregistrierung sollte eine Authentifizierung stattfinden.[55]
Nach Überprüfung und Bestätigung der Benutzerberechtigung durch das User-Management würde nun der Empfang der Anzeige, sowie deren Ablage zur weiteren Bearbeitung gestartet werden.
Dieser Ablauf verhindert eine unnötige Übermittlung der Anzeige, wodurch vor allem Kosten gespart werden würden.
3.1. Verwendung eines User-Management
3.1.1. Durchführung der Registrierungsprüfung
Sobald der Client die Übermittlung der Anzeige an den Webserver initiiert, sollte die Registrierungsprüfung gestartet werden.
Die hierfür notwendige Benutzerdatenbank sollte generell gewährleisten, dass jeder Benutzer mit seinen persönlichen Daten darin gespeichert werden kann. Zudem sollten sie bei Bedarf einfach und schnell wieder aus der Benutzerdatenbank ausgelesen werden können. Hierzu reicht im Rahmen des zu entwickelnden Demonstrators die Verwendung einer XML-Datei aus.
3.1.2. Registrierung eines neuen Benutzers
Sofern der Client die Neuregistrierung eines Benutzers veranlasst, sollten alle in diesem Rahmen übermittelten Daten in der Benutzerdatenbank automatisch hinzugefügt und zusätzlich eine Kundennummer generiert werden. Diese könnte sich aus Buchstaben und aus Zahlen zusammensetzen.
3.1.3. Durchführung der Authentifizierung
Sinnvoll wäre an dieser Stelle die Anwendung des Challenge-Response-Verfahrens.
Zum einen spricht die Tatsache dafür, dass keinerlei statische Passwörter auf dem Client oder dem Webserver hinterlegt werden müssten und zum anderen wird dieses Verfahren seit Jahren im Mobilfunk zur Authentifizierung genutzt.[56]
Der Verfahrensablauf würde durch die Genierung einer Zufallszahl, durch die von beiden Kommunikationspartnern vorgenommene Berechnung eines Ergebnisses mit der Zufallszahl und durch einen abschließenden Vergleich der Ergebnisse, erfolgen. Stimmen die Ergebnisse überein, ist die Authentifizierung positiv abgeschlossen.
3.2. Ablage der übermittelten Daten zur Weiterbearbeitung
Für die Weiterverarbeitung der übermittelten Daten müssten die empfangenen Daten strukturiert abgelegt werden. Eine Unterscheidung zwischen der Anzeige und den dazugehörigen Bilddateien wäre sinnvoll, da beide aus programmiertechnischen Gründen getrennt übermittelt werden.
3.2.1. Ablage der übermittelten Anzeige
Für die Ablage sollten zunächst die aktuelle Uhrzeit und das aktuelle Datum erfasst werden. Dies könnte später für die Verfolgung der begangenen Ordnungswidrigkeit von Bedeutung sein. Bei geringfügigen Ordnungswidrigkeiten im ruhenden Verkehr, bei denen im Regelfall Verwarnungsgelder bis maximal 35,00 Euro verhängt werden, tritt beispielsweise die Verjährung nach Ablauf von sechs Monaten ein.[57]
Im nächsten Schritt sollte eine Netzlokalisierung durchgeführt werden, um die übermittelten GPS-Standortdaten zu verifizieren.
Für eine übersichtliche und leicht zu handhabende Ablage müsste zuletzt eine geeignete Ordnerstruktur, eingeteilt in Eingangstage und Benutzer, angelegt werden.
Daran anschließend könnten die übermittelten Informationen der Anzeige als XML-Datei erstellt und darin abgelegt werden.
3.2.2. Ablage der übermittelten Bilddateien
Bei der Ablage der übermittelten Bilddateien müsste darauf geachtet werden, dass diese in demselben Ordner, wie die dazugehörigen, bereits abgelegten Anzeigen, gespeichert werden. Um dies zu erreichen, müsste an dieser Stelle dieselbe Pfadangabe als Speicherort verwendet werden.
Nur so kann auch sichergestellt werden, dass die Anzeige samt übermittelten Beweisfotos in dem relevanten Ordner für Eingangstag und Benutzer abgespeichert werden.
3.2.3. Darstellung der eingegangenen Anzeigen inklusive der Beweisfotos
Für die Realisierung dieser Aufgabe könnte als Web-Interface eine dynamische Webseite erstellt werden. Auf dieser könnte zum einem eine kleine Statistik über die Anzahl der Benutzer oder der eingegangen Anzeigen erstellt werden.
Darüber hinaus sollte zumindest eine Auswahlmöglichkeit für die eingegangen Anzeigen bestehen, damit die enthaltenen Informationen betrachtet und ausgewertet werden können.
III. Implementierung des entworfenen Demonstrators
1. Die verwendete Testumgebung
Unter II.2.1. wurde bereits dargestellt, welche Hard- und Softwareanforderungen an die mobile Infrastruktur gestellt werden.
Die nachfolgende Darstellung zeigt nun, welche Hard- und Software speziell für die Realisierung der mobilen Client – Webserver – Infrastruktur verwendet wird.
1.1. Der mobile Client
Für den mobilen Client wird einerseits der T-Mobile MDA II als PDA verwendet. Er unterstützt sowohl eine TCP/IP-Datenübertragungstechnik in Form von GPRS und bietet andererseits die Möglichkeit, ein externes Gerät (z. B. ein GPS-Gerät) über die vorhandene Bluetooth-Schnittstelle zu verbinden und zu verwenden.
Des Weiteren verfügt der MDA II über ein integriertes CMOS-Kameramodul, durch das die Aufnahme von Fotos in VGA-Auflösung im Format 480x640 ermöglicht wird.[58]
Als benötigtes GPS-Gerät wird das Bluetooth-GPS-Gerät der Firma Socket Communication verwendet.
Beide Geräte, sowohl der MDA II als auch das GPS-Gerät können leicht über Bluetooth verbunden und zusammen verwendet werden. Daher eignen sie sich zusammen als mobiler Client für die Implementierung des Demonstrators innerhalb der Testumgebung.
Zu erwähnen ist, dass grundsätzlich jedes verfügbare mobile Endgerät, welches die erforderlichen Hardwareanforderungen erfüllt, als PDA verwendet werden kann.[59] Ebenso kann jedes GPS-Gerät verwendet werden, dass sich mit einem PDA verbinden lässt, sofern es nicht bereits im verwendeten PDA integriert sein sollte.
Die Wahl des T-Mobile MDA II legt gleichzeitig das zu verwendende Betriebssystem fest. Hierbei handelt es sich um Windows Mobile 2003 for PocketPC Phone Edition.[60]
Mit der Veröffentlichung dieses mobilen Betriebssystems ist das .NET Compact Framework standardmäßig auf diesen mobilen Endgeräten vorhanden. Eine Nachinstallation ist bei früheren Versionen des Windows PocketPC-Betriebssystems[61] allerdings mithilfe der entwickelten Software möglich.
Die Softwareentwicklung auf Grundlage des .NET Compact Framework beschränkt die Ausführung der Anwendung nicht nur auf PocketPCs[62]. Es ist darüber hinaus möglich, unter Anpassung des User-Interfaces die Anwendung auch auf geeigneten Smartphones[63] auszuführen. Für die Einbindung des GPS-Gerätes und der durch das GPS-Gerät empfangenen Daten muss eine entsprechende Klasse für die Programmierung zur Verfügung stehen. Hierfür existiert die GPS-Klasse der Firma StormSource LLC.
Als Programmiersprache wird C# .NET verwendet, wobei allerdings ohne Vor- oder Nachteile auch Visual Basic .NET verwendet werden kann. Anhand der unter II.2.1. dargestellten Hard.- und Softwareanforderungen und den vorstehenden Erläuterungen wird der mobile Client innerhalb der in Tabelle 1 zusammengefassten Hardware- und Softwarespezifikationen entwickelt.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 1: Übersicht der verwendeten Hard- und Software für den mobilen Demonstrator
1.2. Der Webserver
Für die Integration und Verwendung des Webservers ist zunächst ein geeignetes Betriebssystem zu wählen.
Da für die Entwicklung des Demonstrators auf dem mobilen Endgerät bereits ein Betriebssystem von Microsoft Verwendung findet, wird auch für den Betrieb des Webservers ein Betriebssystem aus diesem Haus herangezogen – Windows Server 2003 Web Edition.[64]
Wie unter II.2.1. bereits angedeutet, kann auch die notwendige Software für den Webserver auf Grundlage des .NET Frameworks entwickelt werden. Ein Vorteil dabei ist, dass die gleiche Programmiersprache zur Verfügung steht, mit der bereits der Demonstrator auf dem mobilen Client entwickelt wurde.
Neben dem bloßen Eingang der Daten und deren Ablage auf dem Webserver sollen diese auch geeignet dargestellt werden.
Für diesen Zweck kann ebenfalls das .NET Framework die Grundlage bilden. Es ermöglicht die Erstellung einer dynamische Website unter Verwendung der Programmiersprache C# .NET.
Vor allem das in diesem Rahmen zur Anwendung kommende Code-Behind-Model bei der Entwicklung von ASP .NET-Webseiten kann als hauptsächlicher Grund für die Anwendung betrachtet werden.[65]
Zusammenfassend kann festgehalten werden, dass sowohl für die Entwicklung der Webserver-Software, als auch für die Entwicklung der dynamischen Webseite, zur Darstellung der eingegangenen Daten, C# .NET verwendet wird.
Zu beachten ist darüber hinaus, dass der Webserverprozess durch das Windows-Benutzerkonto ASPNET ausgeführt wird. Aus diesem Grund sind diesem Benutzer uneingeschränkte Rechte für die benötigten Verzeichnisse zu gewähren. Der mobile Client tritt bei der Kommunikation als Internet-Gast über das Benutzerkonto IUSR<Domäne> auf.
Des Weiteren ist sicherzustellen, dass zur Erfassung der korrekten Eingangszeit der Anzeige auf dem Webserver die richtige Uhrzeit eingestellt ist. Für eine Synchronisation wird aus diesem Grund ein externer Zeitserver zur Aktualisierung der Uhrzeit verwendet.[66]
Der Vollständigkeit halber wird abschließend erwähnt, dass als benötigte Hardware jeder Desktop-PC verwendet werden kann, der die Voraussetzung zum Betrieb eines Microsoft Windows Server Betriebssystems erfüllt, sowie die Möglichkeit einer Verbindung zum Internet bietet.
2. Das graphische User – Interface des mobilen Clients
2.1. Auswahl der anzuzeigenden Ordnungswidrigkeit
Die Auswahl der anzuzeigenden Ordnungswidrigkeit findet bereits auf dem Startbildschirm statt. Dadurch wird gewährleistet, dass vor der Erfassung einer Anzeige der benötigte Informationsumfang festgelegt wird.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2: Screenshot der Auswahl der anzuzeigenden Ordnungswidrigkeit
Zudem existiert auf dem Startbildschirm ein Button „Bild holen“, um die Kameraanwendung zu starten und der Button „Anzeige senden“, um mit der Erfassung der Anzeige zu beginnen. Über das vorhandene Menü „Datei“ kann der Benutzer, sowohl das Fenster für die Benutzerdaten aufrufen, als auch alle von ihm erfolgreich übermittelten Anzeigen im Fenster„History“ darstellen lassen.
[...]
[1] vgl. §1 StVO
[2] Hierunter fallen sowohl im Straßenverkehr verletzte, als auch getötete Personen.
[3] Bei den restlichen Personen handelt es sich um Fahrer/innen bzw. Mitfahrer/innen in Kraftfahrzeugen.
[4] vgl. Statistisches Jahrbuch (2004), S. 147
[5] Allein in Frankfurt hat sich der PKW-Bestand in den Jahren 1990 bis 2003 um ca. 10% erhöht. Vgl. Fahrzeugbestand FFM (2005), S. 144
[6] vgl. BMVBW (2005)
[7] Hierzu zählen in Hessen u. a. StVG, StVO, StVZO, HSOG, OwiG, ZuweisungsVO, stop, AltautoVO, Erlaß des HMdI, Gesetze: StVO, BimschG, BOStrab, Vz-Kat, StVO-VWV, Erlasse der obersten Straßenverkehrsbehörde, Richtlinien: RAS, RAS-K, RMS-1, RWB, ERA, ESG, HAV, RSA, RILSA, EAE, EAHV, ZTV-SA, EVE, R-FGÜ, RAF Luftverkehrsgesetz, Hessisches Straßengesetz, Erlasse und ECE-Regelungen u.a.
[8] vgl. Produkthaushalt Frankfurt (2004), Tabelle „Personal“, S. 3 , Insbesondere bei den Kostenstellen 32/00050, 32/00052 und 32/00053
[9] vgl. Wikipedia Effizienz (2005)
[10] Momentan ist es lediglich möglich, eine Ordnungswidrigkeit per Email, Fax oder Brief anzuzeigen.
[11] Es wird die Notation in der Version 1.4 verwendet.
[12] Wikipedia Webserver (2005)
[13] vgl. Teltarif (2005a)
[14] vgl. Teltarif (2005b)
[15] vgl. Teltarif (2005a) ; Teltarif (2005b)
[16] vgl. Karl, H. (2004), S. 227
[17] vgl. Tarif4you (2005)
[18] vgl. Karl, H. (2004), S. 227
[19] vgl. Teltarif (2005c)
[20] vgl. Onlinekosten (2005b)
[21] vgl. Onlinekosten (2005a)
[22] Für eine genaue Darstellung des Verfahren TDMA, vgl. Schiller,(2000b)
[23] Für eine genaue Darstellung des Verfahren CDMA, vgl. Schiller,(2000c)
[24] vgl. Schiller (2000a), S. 72 ; vgl. N.N. (2005b)
[25] N. N. (2005b)
[26] vgl. Krenik, B. (2005), S. 1
[27] vgl. N. N. (2005a)
[28] vgl. Röttger-Gerigk (2002), S. 419
[29] vgl. Roth, J. (2004), S. 199
[30] vgl. Ranke, J. (2003), S. 19; vgl. Röttger-Gerigk (2002), S. 419
[31] vgl. Röttger-Gerigk (2002), S. 420
[32] vgl. Röttger-Gerigk (2002), S. 422
[33] vgl. Röttger-Gerigk (2002), S. 423
[34] vgl. Röttger-Gerigk (2002), S. 421
[35] vgl. Roth, J. (2004), S. 179
[36] vgl. Röttger-Gerigk (2002), S. 422
[37] vgl. Röttger-Gerigk (2002), S. 422
[38] für ein detaillierte Darstellung der Berechnung der Distanz vgl. TU-Ilmenau (2005), S. 5 - 8 ; vgl. Roth, J. (2004), S. 182 - 184
[39] vgl. Roth, J. (2004), S. 181
[40] vgl. TU-Ilmenau (2005), S. 1 – 4
[41] vgl. TU-Ilmenau (2005), S. 5
[42] vgl. Siemens AG (2005)
[43] vgl. Siemens AG (2005)
[44] Lediglich zu Demonstrationszwecken wurde unter anderem das Siemens SX1 mit einem GPS-Modul ausgestattet. Vgl. Siemens AG (2005)
[45] vgl. Geräteübersicht PocketPC (2005)
[46] vgl. Wikipedia PDA (2005)
[47] Hierbei handelt es sich, im Gegensatz zu PocketPCs um Mobiltelefone, die auch über Funktionalitäten von PDAs verfügen. Der größte Unterschied dabei ist, dass Smartphones nicht über einen Touchscreen verfügen. ; vgl. Wikipedia OS (2005)
[48] vgl. Wikipedia OS (2005)
[49] Beim Compact Framework handelt es sich um eine Teilmenge des .NET Frameworks. Für einen vollständigen Vergleich mit diesem und eine Übersicht der Funktionalitäten des .NET Compact Framework, vgl. Compact Framework (2005)
[50] vgl. Anzeige OW (2005)
[51] vgl. http://www.frankfurt.de/sis/sis/detail.php?id=4818&_reload=1 (07.04.2005)
[52] § 57 StPO i.V.m. § 46 OWiG
[53] § 161a StPO i.V.m. § 46 OWiG
[54] gem. § 24 StVG Abs.1 i. V. m. § 49 StVO
[55] vgl. Wikipedia Authentifizierung (2005)
[56] vgl. Schiller, J. (2000d), S. 172
[57] vgl. Grunert, G. (2005) ; vgl. § 31 Abs.4 OWiG bezüglich der Verjährung
[58] vgl. Bedienung MDAII (2003), S. 190
[59] Die Wahl des MDA II ist lediglich aufgrund der Verfügbarkeit erfolgt.
[60] vgl. Bedienung MDAII (2003), S. 190
[61] Eine kurze Übersicht der bisher erschienen Vorgängerversionen kann unter http://www.pocketpc-users.de/ceinfo.htm (03.04.2005) nachgelesen werden.
[62] PocketPC bezeichnet sowohl ein Betriebssystem, als auch eine Geräteklasse von PDAs. Im vorliegendem Fall ist die Geräteklasse zu verstehen. Für eine ausführliche Unterscheidung und weiterführenden Verweisen, vgl. Wikipedia PocketPC (2005)
[63] Für eine Geräteübersicht vgl. http://www.pocketpc-users.de/devicess.htm (03.04.2005)
[64] Eines diverser Produkte aus der Windows-Server-Famile.
Vgl. http://www.microsoft.com/windowsserver2003/default.mspx (29.03.2005)
[65] Näheres hierzu vgl. Microsoft ASP .NET (2005)
[66] vgl. Zeitsynchronisation (2005) ; vgl. http://support.microsoft.com/?kbid=262680 (03.04.2005)