PDF 2.296kB - Hochschule Ulm

hs.ulm.de

PDF 2.296kB - Hochschule Ulm

Hochschule Ulm

Fakultät Produktionstechnik und Produktionswirtschaft

Studiengang Wirtschaftsingenieurwesen - Logistik

Feinkonzept und Pilotierung eines

Matching-Algorithmus für

dynamische Begegnungsverkehre

Studienarbeit im Projekt Dynamic Truck Meeting

Harald Busch

29. August 2011

Betreuer: Prof. Dr.-Ing. Hartwig Baumgärtel

Bearbeitungszeitraum: 01. März 2011 bis 31. Oktober 2011


Zusammenfassung

Diese Dokumentation beschreibt Aufbau, Design und Handhabung der Demonstrationssoftware

für den Matching-Algorithmus für dynamische Begegnungsverkehre (oder

kurz DTM-Partnersuche), der im Rahmen des Forschungsprojektes Dynamic Truck

Meeting erarbeitet wurde. Das Softwarepaket besteht aus einer Datenbank, einem Graphical

User Interface zur Partnersuche (GUI-P) und einem weiteren Graphical User

Interface zur Administration der Datenbank (GUI-A). Die Arbeit geht im ersten Teil

sowohl auf das Datenbankdesign, als auch auf die Algorithmen der Graphical User Interfaces

(GUIs), sowie die Datenbankbefehle, die die GUIs mit der Datenbank verbinden,

ein. Im zweiten Teil wird die Vorbereitung der Benutzung und die Präsenation einiger

Szenarien mit der Software beschrieben. Im dritten und letzten Teil werden dann erkannte

Grundsatz- und Ausführungsfehler beschrieben, die während der Arbeit entstanden

sind. Die Dokumentation beschreibt die Version 1.0 der Software vom 22. Mai 2011,

welche dem projektbegleitenden Ausschuss vorgestellt wurde. Diese unterscheidet sich

nur marginal von Version 0.9, welche am 10. Mai 2011 im Rahmen des Trepunkt

Forschung auf der Transport Logistic in München vorgestellt wurde. Das Handbuch

beschreibt Version 1.1 der Software, da nach den Präsentationen einige (wenige) Fehler

beseitigt und vor allem die Benutzerfreundlichkeit erhöht wurde.


Erklärung über unabhängiges

Arbeiten

Hiermit erkläre ich, dass ich die vorliegende Studienarbeit selbständig angefertigt habe.

Es wurden nur die in der Arbeit ausdrücklich benannten Quellen und Hilfsmittel benutzt.

Wörtlich oder sinngemäÿ übernommenes Gedankengut habe ich als solches kenntlich

gemacht.

Ulm, den

Harald Busch

5


Inhaltsverzeichnis

Abbildungsverzeichnis 9

Tabellenverzeichnis 11

Abkürzungsverzeichnis 13

1. Einleitung 17

1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.2. Einordnung in den Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.3. Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2. Das Informationsproblem 21

2.1. Informationen über den eigenen Auftrag . . . . . . . . . . . . . . . . . . 21

2.1.1. Kontaktdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.1.2. Informationen über den Transport . . . . . . . . . . . . . . . . . . 21

2.1.3. Informationen über Ladung und Ladeeinheit . . . . . . . . . . . . 21

2.2. Informationen über das eigene Angebot . . . . . . . . . . . . . . . . . . . 21

2.3. Informationen für das System . . . . . . . . . . . . . . . . . . . . . . . . 22

I. Feinkonzept 25

3. Design und Architektur 27

3.1. Umfeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.1.1. Annahmen und Voraussetzungen . . . . . . . . . . . . . . . . . . 27

3.1.2. Abgrenzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2. Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2.1. Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . 28

3.2.2. Nicht funktionale Anforderungen . . . . . . . . . . . . . . . . . . 29

3.3. Anwendungsfälle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.3.1. Diagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.3.2. Szenarien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4. Systemdesign 33

4.1. Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2. Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.3. Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

7


Inhaltsverzeichnis

4.4. Datenbankmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.4.1. Hauptrelationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.4.2. Stammdatenrelationen . . . . . . . . . . . . . . . . . . . . . . . . 36

5. Umsetzung und Implementierung 37

5.1. Stammdatenauswahl und Dienstprogramme . . . . . . . . . . . . . . . . 37

5.1.1. Einfache Listen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.1.2. Geokoordinaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.2. Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.3. Datenbankzugang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.4. Die Partnersuche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.4.1. Datensatzeingabe . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.4.2. Test auf Validität der Daten . . . . . . . . . . . . . . . . . . . . . 46

5.4.3. Daten hinterlegen . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.4.4. Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.4.5. Detailansicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.4.6. Begegnungspunkt berechnen . . . . . . . . . . . . . . . . . . . . . 55

II. Handbuch 59

6. Voraussetzungen und Installation 61

6.1. Bestandteile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6.2. Systemanforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6.3. Inbetriebnahme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6.3.1. Datenbank einrichten . . . . . . . . . . . . . . . . . . . . . . . . . 62

6.3.2. Stammdaten hinterlegen . . . . . . . . . . . . . . . . . . . . . . . 62

7. Benutzung des Demonstrators 65

7.1. Menüführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

7.2. Anmeldung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

7.3. Fahrtenverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

7.4. Detailansicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

7.4.1. Partner akzeptieren . . . . . . . . . . . . . . . . . . . . . . . . . . 67

7.4.2. Partner ablehnen . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

7.4.3. Begegnungspunkt berechnen und anzeigen . . . . . . . . . . . . . 68

7.5. Entfernungsrechner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

7.6. Mögliche Paarungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

8


Inhaltsverzeichnis

III. Kritische Diskussion 69

8. Konzeptfehler 71

8.1. Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

8.1.1. Redundante Datenhaltung . . . . . . . . . . . . . . . . . . . . . . 71

8.1.2. Fehlende Relation für Fehlermeldungen . . . . . . . . . . . . . . . 71

8.2. GUI-A - Automatische Datensatzerstellung . . . . . . . . . . . . . . . . . 71

9. Ausführungsfehler 73

9.1. Stabilität durch starre Stammdatenlisten . . . . . . . . . . . . . . . . . 73

9.2. Ja-Nein-Vielleicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

9.3. Partnersuche ohne Hinterlegen des Datensatzes . . . . . . . . . . . . . . 74

9.4. GUI-P - Gestaltung fehlende Übersichtlichkeit . . . . . . . . . . . . . . . 74

10.Zusammenfassung und Ausblick 75

A. Datenträger Programmcode 77

B. Datenträger Matching-Software 79

Literaturverzeichnis 80

9


Abbildungsverzeichnis

1.1. Verfahren zur Partnersuche . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.1. Informationsaustausch für Begegnungsverkehre . . . . . . . . . . . . . . 23

3.1. Anwendungsfälle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.1. Datenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.1. Maske für Distanzberechnung zwischen Depots und Orten . . . . . . . . 40

5.2. Distanzberechnung zwischen Depots und Orten . . . . . . . . . . . . . . 41

5.3. Anmeldemaske . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.4. Algorithmus des msdl-Paketes . . . . . . . . . . . . . . . . . . . . . . . . 44

5.5. Maske zur Datensatzeingabe . . . . . . . . . . . . . . . . . . . . . . . . 45

5.6. Algorithmus der Datensatzhinterlegung . . . . . . . . . . . . . . . . . . 47

5.7. Algorithmus zur Vorbereitung eines SQL-Statements . . . . . . . . . . . 48

5.8. Grundlegende Vorgehensweise bei der Partnersuche . . . . . . . . . . . . 50

5.9. Überschneidung der Zeitfenster . . . . . . . . . . . . . . . . . . . . . . . 52

5.10. Finden von Transporten mit passendem Ziel . . . . . . . . . . . . . . . . 52

5.11. Szenario für die Begegnungspunktberechnung . . . . . . . . . . . . . . . 56

5.12. Algorithmus der Begegnungspunktberechnung . . . . . . . . . . . . . . . 58

6.1. GUI-A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6.2. GUI-A Anmeldedialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

7.1. Maskenführung des GUI-P . . . . . . . . . . . . . . . . . . . . . . . . . 66

7.2. Verbindung kappen oder testen . . . . . . . . . . . . . . . . . . . . . . . 67

11


Tabellenverzeichnis

5.1. Kombinationsmöglichkeiten der Fahrzeuge . . . . . . . . . . . . . . . . . 38

5.2. Beispiel für Ergebnismatrix . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.3. Auswertung der Ja-Nein-Vielleicht Angaben . . . . . . . . . . . . . . . 53

5.4. Auswertung der Gefahrgut-Angaben . . . . . . . . . . . . . . . . . . . . 54

7.1. Datensätze mit besonderen Ausprägungen . . . . . . . . . . . . . . . . . 68

13


Abkürzungsverzeichnis

DBS Datenbanksystem. 2831, 33, 42, 46, 49, 51, 54, 6268, 71, 73, 79

DTM Dynamic Truck Meeting. 17, 18, 28, 29, 37, 40, 75, 79

GK Geokoordinaten. 27, 33, 34, 37, 39, 40, 42, 55, 68

GNU GPL GNU General Public License. 42

GUI Graphical User Interface. 3, 28, 33, 37

GUI-A Graphical User Interface zur Administration der Datenbank. 3, 11, 29, 33, 42,

6165, 71

GUI-P Graphical User Interface zur Partnersuche. 3, 11, 30, 33, 36, 37, 42, 45, 61, 65,

66, 71, 74

MS MySql Server. 33, 62, 79

msdl mysqldirect library. 42, 43

PAP Programm Ablauf Plan (DIN 66001). 40, 42, 46

POI Points of Interest. 75

SQL Structured Query Language. 42, 43, 46, 49

TD TurboDelphi 8. 33, 42, 45, 77

WB MySQL Workbench. 33, 62, 79

15


1. Einleitung

1.1. Motivation

Das Projekt Dynamic Truck Meeting beschäftigt sich mit (Ganzladungs-) Begegnungsverkehren.

Im Rahmen des Projektes Dynamic Truck Meeting (DTM) soll ein anbieterunabhängiger

Prozess- und Informationsstandard für die Abwicklung von dynamischen

Begegnungsverkehren im Bereich des Komplettladungsverkehrs erarbeitet werden.

[DT11]

Dies steht in vollem Gegensatz zur aktuellen Praxis, da Begegnungsverkehre bisher

einen relativ hohen Planungsaufwand erfordern und daher nur bei regelmäÿigen Verkehren

Anwendung nden. Es geht darum, dass Speditionen eine IT-Plattform bekommen,

um Ladungen auf halbem Wege auszutauschen.[Kön10] Diese IT-Plattform muss dabei

schnelle Möglichkeiten bieten, einen passenden Begegnungspartner zu nden und

einen Begegnungsort ausndig zu machen. Im Gegensatz zu TimoCom und vergleichbaren

Frachtenbörsen sollen dem Disponenten ausschlieÿlich Partneraufträge vorgeschlagen

werden, die auch zu seinem Auftrag passen, sodass eine langwierige Suche durch viele

irrelevante, aber auf der Plattform vorhandene, Aufträge entfällt.

Im Rahmen dieses Projektes verfasste Martin Mack im Wintersemester 2010/2011 eine

Bachelor-Thesis, die sich mit der Suche nach einem Begegnungspartner beschäftigt. Er

hat die aktuelle Situation des Verkehrsgewerbes, sowie die theoretischen Grundlagen, die

für seinen Lösungsansatz notwendig sind, ausreichend beschrieben. Ebenso sind in dieser

Arbeit erste Ansätze einer Umsetzung des Suchalgorithmus zu nden. Die Quintessenz

seiner Arbeit bildet die Basis dieser Arbeit, da die Implementierung des Suchalgorithmus

auf den Prinzipien beruht, die er in [Mac11] beschreibt.

Die folgende Dokumentation behandelt eine repräsentative Implementierung des in

[Mac11] vorgestellten Ansatzes.

1.2. Einordnung des Demonstrators in den Prozess

einer Partnersuche

Abbildung 1.1 zeigt den Ablauf einer Suche nach einem Begegnungsverkehrpartner, wie

sie in [Mac11], Kapitel 4.6 vorgestellt wird. Die rot markierten Vorgänge sind diejenigen,

die der Demonstrator des Matching-Algorithmus ausfüllen wird.

17


1. Einleitung

1.3. Zielsetzung

Die Implementierung des Lösungsansatzes soll belegen, dass der Algorithmus zu sinnvollen

Ergebnissen, das heiÿt zu einer Liste mit möglichen Begegnungspartnern führt. Um

diesen Beleg zu erbringen, wurde ein neues System erstellt. Da die Erstellung eines solchen

Demonstrators nicht durch die ursprüngliche Aufgabenstellung des DTM-Projektes

abgedeckt ist und auch nicht zwangsläug für die Denition eines Nachrichtenstandards

notwendig ist, kann diese Aufgabe als separat vom übrigen Projekt angesehen werden. Es

kann also mit ktiven Datensätzen und teilweise stark vereinfachten Einzelalgorithmen

betrieben werden. Auch wenn dadurch keinerlei Anspruch auf Perfektion oder realitätsgetreue

Abbildung entsteht, kann trotzdem bewiesen werden, dass ein Matching mit

vorhandenen Mitteln durchaus sinnvoll gearbeitet werden kann. Schlussendlich sollen

Demonstrator und die Dokumentation über dessen Implementierung als Vorbild und

Ideengeber zur Verfügung stehen, sollte ein Dritter eine kommerzielle Implementierung

eines Matching-Algorithmus planen und durchführen.

18


1.3. Zielsetzung

Start

Auftragseingang

Auftragsdaten

Suche

Auftrag steht im

BV-Server für x-

Minuten

0

Anzahl

Vorschläge

n

Nein

1

Nein

Auftragsauswahl

Kontakt

gewollt?

Auftrag

gefunden

Ja

Ja

Kontakt

aufnehmen

Abbruch

Nein

Auftrag aus dem

Server löschen

Konsens

Ja

Auftrag aus dem

Server löschen

Auftrag selber

fahren

Begegnungsverkehr

durchführen

Auftrag selber

fahren

Ende

Abbildung 1.1.: Verfahren zur Partnersuche

19


2. Das Informationsproblem

Um einen Partner für einen Begegnungsverkehr zu nden, müssen viele Informationen

zusammenkommen. Denn beide Parteien wollen wissen, mit wem sie kooperieren, was

für eine Art von Ware sie für den Partner transportieren sollen und zu guter Letzt ist es

von groÿem Interesse, dass die eigene Ware adäquat transportiert wird. Daher sollen hier

erst einmal alle Daten zusammengetragen werden, die für den Prozess einer Partnersuche

relevant sind. Hier gilt es jedoch zu unterscheiden, zwischen wirklich relevanten Daten,

interessanten Daten und Daten, die der Partner auf keinen Fall kennen soll.

2.1. Informationen über den eigenen Auftrag

2.1.1. Kontaktdaten

Der Name und Kontaktmöglichkeiten des Auftraggebers (hier des Tauschpartners), um

diesen zu verschiedenen Gelegenheiten kontaktieren zu können.

2.1.2. Informationen über den Transport

Zu Beginn wird der Zielort der Ladung benötigt, um festzustellen, ob dieser Ort im

gewünschten Aktionskreis um das Depot des Partners liegt. Gleichzeitig muss ein Zeitfenster

für den Transport angegeben werden, um zu testen, ob die Transporte sich nicht

durch terminliche Unterschiede ausschlieÿen.

2.1.3. Informationen über Ladung und Ladeeinheit

Zuletzt benötigt der Partner technische und rechtliche Daten über die verwendete Ladeeinheit

und die Ladung. So ist es unumgänglich, dass bekannt ist, ob ein Sattelzug

oder ein Gliederzug auf die Reise geschickt wird, da nicht alle Fahrzeugkombinationen

ihre Ladeeinheiten ohne weiteres tauschen können. Auch Informationen über die Ladung

müssen zwingend übermittelt werden, denn es gilt Verbote und Gebote wie das

Mülltransportverbot oder die Gefahrgutrichtlinien einzuhalten.

2.2. Informationen über das eigene Angebot

Um im System prüfen zu können, ob ein fremder Auftrag mit dem eigenen Fahrzeug

bzw. Fahrer durchführbar ist, müssen einige Angaben über die technische und rechtliche

Ausstattung des Fahrzeugs gemacht werden. So sollte festgehalten werden, ob der

21


2. Das Informationsproblem

Fahrer über einen Gefahrgutschein verfügt oder ob eine Sattelzugmaschine fähig ist,

ihre Sattelkupplung in der Höhe zu verstellen, sodass sie evtl. auch Jumbo-Auieger

aufnehmen kann. Über genau diese Informationen lässt sich aber auch steuern, ob man

für bestimmte Aufträge vorgeschlagen werden will oder nicht. Möchte man z.B. einen

Gefahrguttransport abgeben, aber auf keinen Fall einen solchen erhalten, muss man nur

im Angebot vermerken, dass man kein Gefahrgut akzeptiert. Die Informationen für die

eigene Ladung bleiben dadurch unverändert.

2.3. Informationen für das System

Damit das System der Partnersuche alle Funktionen erfüllen kann, muss der Disponent

eventuell auch Angaben machen, die dem Partner nicht übermittelt werden sollen.

So muss z.B. zur Ermittlung des Begegnungspunktes die Restfahrzeit des eigenen Fahrers,

die dieser für diesen Transport zur Verfügung hat, angegeben werden. Eine weitere

solche Information ist, wie lange der Auftrag noch im System verweilen soll, bevor er

gelöscht wird, ohne dass ein Partner gefunden wird. Da solche Informationen als Firmengeheimnisse

eingestuft werden können, dürfen diese auf keinen Fall für eventuelle Partner

sichtbar sein. Das System muss also dafür Sorge tragen, dass diese Informationen nur

für den Auftraggeber selbst sichtbar sind.

Die Gesamtheit der Informationen, und deren Austausch sieht man in Abbildung 2.1

schematisch dargestellt.

22


2.3. Informationen für das System

Partnersuche

Partner 1 Partner 2

Grundinformationen

Partner (Name + Kontakt)?

Zeitfenster?

Transportziel?

Eigener Transport

Fahrzeug und Ladeeinheit?

Kühltransport?

Hebebühnenentladung?

Gefahrguttransport?

Gewicht der Ladung?

Lademeter/ Volumen der

Ladung?

Grundinformationen

Partner (Name + Kontakt)?

Zeitfenster?

Transportziel?

Eigener Transport

Fahrzeug und Ladeeinheit?

Kühltransport?

Hebebühnenentladung?

Gefahrguttransport?

Gewicht der Ladung?

Lademeter/ Volumen der

Ladung?

Angebot Rücktransport

Akzeptierte Ladeeinheiten?

Kühltransporte möglich?

Hebebühnentransporte

möglich?

Gefahrguttransporte

möglich?

Angebot Rücktransport

Akzeptierte Ladeeinheiten?

Kühltransporte möglich?

Hebebühnentransporte

möglich?

Gefahrguttransporte

möglich?

Informationen für das System

Radius um das eigene Depot,

in dem das Ziel liegen muss

Startort

Verfügbare Fahrzeit des

Fahrers

Verfallsdatum des Gesuchs

Informationen für das System

Radius um das eigene Depot,

in dem das Ziel liegen muss

Startort

Verfügbare Fahrzeit des

Fahrers

Verfallsdatum des Gesuchs

Abbildung 2.1.: Informationsaustausch für Begegnungsverkehre

23


Teil I.

Feinkonzept

25


3. Design und Architektur

3.1. Umfeld

3.1.1. Annahmen und Voraussetzungen

Die Software soll einzig und allein einen Beleg liefern, dass der Suchalgorithmus funktioniert.

Daher können einige Parameter vereinfachend angenommen werden. Diese sind

einerseits die verwendbaren Orte: Um den Aufwand für die Erschlieÿung von Geokoordinaten

(GK) 1 im Demonstrator zu minimieren, werden ausschlieÿlich Orte verwendet, die

in einer vorher bestimmten Liste zu nden sind. Diese Liste soll sich prinzipiell auf Orte

in Deutschland beschränken. Darüber hinaus werden jegliche Distanzen, die anhand der

GK berechnet werden über einen einfachen Satz des Pythagoras berechnet. Prinzipiell

spricht hiergegen die Tatsache, dass der Satz des Pythagoras eine euklidische Metrik voraussetzt,

diese jedoch nur für Systeme in einer Ebene verwendbar ist. Allerdings ndet

sich in [Bau11], Kapitel 2.3.4 + 2.3.5 der Hinweis, dass bei Distanzen unter 1000km die

Erdkrümmung nicht beachtet werden muss. Der nördlichste Ort des deutschen Festlandes

ist Holnishof in der Flensburger Förde 2 , während der südlichste Ort ein Hütte mit

Namen Schroten-Paÿ (südlich von Oberstdorf) ist. Gemäÿ [Gmb11] beträgt die Distanz

zwischen diesen beiden Orten 846,445km.

Die längste West-Ost-Strecke Deutschlands liegt gemäÿ [ver11] mit 636km zwischen

den Orten Selfkant Isenbruch und einer Fluÿschleife zwischen Neiÿeaue Deschka und

Neiÿeaue Zentendorf.

Abstrahiert man eine Deutschlandkarte nun zu einem Rechteck, so ergibt sich die

Länge l der Diagonalen aus einem Satz des Pythagoras:

l =



(846, 445km) 2 + (636km) 2 = 1120965, 138025km ≈ 1059km

Die Diagonale der abstrahierten Deutschlandkarte wäre also 1059km lang. Das sind

rund 6% mehr, als die in [Bau11], Kapitel 2.3.4 + 2.3.5 angegebenen 1000km. Jedoch ist

diese Abweichung unter den folgenden Berücksichtigungen akzeptabel: Einerseits können

Transporte, die sich entlang der gesamten Länge einer der Diagonalen durch Deutschland

abspielen, für den Demonstrator als seltene Ausnahmefälle eingestuft werden. Andererseits

errechnet sich diese Diagonalenlänge aus einer abstrahierten rechteckigen Deutschlandkarte;

Deutschland ist jedoch im Süden deutlich schmaler, als an der breitesten

1 Eine Erklärung von Geokoordinaten und der Berechnung von Distanzen auf eine Kugel anhand von

Geokoordinaten kann in [Bau11], Kapitel 2.3 nachgeschlagen werden.

2 Der nördlichste Punkt Deutschlands ist nördlich von List am Ellenbogen auf der Insel Sylt. (vgl.

[ver11])

27


3. Design und Architektur

Stelle. In der Realität ergibt sich für die Strecke von Wyhlen, dem Pendant zum schweizer

Grenzort Pratteln in der Nähe von Basel, nach Lohme auf Rügen gemäÿ [Gmb11]

eine Strecke von 885,653km.

Unter diesen Voraussetzungen ist eine Berechnung der Distanzen mit dem Satz des

Pythagoras möglich, ohne dass gröÿere Abweichungen durch die Erdkrümmung entstehen.

3.1.2. Abgrenzung

Die bei der Implementierung entstehenden GUIs sowie das dazugehörige Datenbanksystem

(DBS) müssen nicht mit den bisher erstellten oder später noch folgenden Elementen

des DTM-Projektes interagieren können. Sie müssen nicht mehrbenutzertauglich sein

und auch nicht dem Nachrichtenstandard, den das DTM-Projekt erstellt, genügen. Dadurch

wird die Wahl der zu benutzenden Tools vollständig frei. Das DBS und die GUIs

haben Prototypcharakter und müssen weder selbsterklärend noch fehlerfrei sein.

3.2. Anforderungen

In [Mac11], Kapitel 4.1 ndet sich eine Anforderungsliste an das System einer Partnersuche.

Ergänzend zu dieser kommen die folgenden Punkte hinzu:

3.2.1. Funktionale Anforderungen

Zwingend erforderliche Anforderungen

• Die Implementierung liefert eine Liste mit möglichen Partnern für einen Begegnungsverkehr.

• Aufträge von Partnern, die gerade einem zweiten Partner als Begegnungsverkehr

vorgeschlagen werden, sind gesperrt und dürfen einem dritten Partner nicht als

Begegnungspartner vorgeschlagen werden, auch wenn sein Auftrag als Begegnungspartner

in Frage käme.

• Aufträge dürfen sich nicht selbst als Partner vorgeschlagen werden.

• Es wird eine Auswahl von Anforderungen an Begegnungspartner bereitgestellt und

bei der Bestimmung der Partneraufträge beachtet.

• Die Eigenschaften eines möglichen Partnerauftrages können eingesehen werden.

Dabei sind allerdings nur die wichtigsten Informationen sichtbar. (Möglichkeit des

Datenschutzes!)

28


3.3. Anwendungsfälle

Optionale Anforderungen

• Berechnung der Distanzen unter Beachtung der Erdkrümmung.

• Freigabe der Datensätze nach Ablehnung durch einen Partner.

• Schaung einer Möglichkeit, um das DBS des Demonstrators mit Datensätzen

auszustatten, anhand derer eine Demonstration des Systems durchgeführt werden

kann.

Nice-to-have Anforderungen

• Stammdatenpege über GUI-A.

• Infobox, falls neuer Datensatz eines Partners zu einem alten eigenen Datensatz

passt.

• Schaung einer Möglichkeit um on-the-y Datensätze zu erzeugen und so eine

dynamische Demonstration ermöglichen.

• Berechnung eines möglichen Begegnungspunktes in Geokoordinaten anhand der

Geokoordinaten von betroenen Depots, Start- und Zielpunkten und Anzeige desselben

in Google-Maps.

3.2.2. Nicht funktionale Anforderungen

• Übersichtlichkeit des Vorganges.

• Stabilität bei Falscheingaben.

• Benutzerfreundlichkeit.

• Repräsentation der Hochschulen Ulm und Neu-Ulm sowie des DTM-Projektes und

seiner Geldgeber.

3.3. Anwendungsfälle

3.3.1. Diagramme

Die in Abbildung 3.1 und dargestellten Anwendungsfälle sind im System des Demonstrators

möglich.

3.3.2. Szenarien

Im folgenden ist eine Liste mit möglichen Szenarien, die im Demonstrator abgebildet

werden müssen zu nden.

29


3. Design und Architektur

Demonstrator Matching-Algorithmus

Eingabe neuer

Datensatz

«extends»

Datensatz

hinterlegen

«uses»

Schlüssel ausgeben

«extends»

Benutzer

alten Datensatz

aufrufen

«extends»

Partner suchen

«uses»

Liste mit möglichen

Partnern ausgeben

Stammdaten pflegen

«extends»

vorgefertigte

Daten einlesen

Administrator

Dynamische Daten

pflegen

«extends»

Daten dynamisch

generieren

Abbildung 3.1.: Anwendungsfälle

Szenarien für Benutzer

Eingabe eines Datensatzes Ein Partner kann einen Datensatz in das System eingeben.

Bevor er eine Aktion mit diesem Datensatz starten kann, wird eine Prüfung

ausgeführt, ob er alle notwendigen Daten eingegeben hat. Sollte das nicht der Fall sein,

erhält er einen Hinweis, welches Datum noch fehlt.

Hinterlegen eines Datensatzes Sobald der Benutzer einen vollständigen Datensatz

in das GUI-P eingegeben hat, kann er diesen im System hinterlegen lassen. Als Ausgabe

erhält er dann einen Identikationsschlüssel, mit dem er diesen Datensatz später wieder

aufrufen kann.

Suchen eines geeigneten Partnerdatensatzes Unabhängig davon, ob der Datensatz

im DBS hinterlegt ist oder nicht, kann der Benutzer eine Liste mit möglichen Partnerauf-

30


3.3. Anwendungsfälle

trägen anfordern. 3 Die Einzelheiten dieser Partneraufträge kann er dann einsehen und

einen Auftrag entweder ablehnen, oder akzeptieren. Im letzten Fall werden automatisch

alle weiteren Datensätze abgelehnt.

Szenarien für Administratoren

Stammdaten pegen Ein Administrator betreut ausschlieÿlich das DBS. Er kann hier

Stammdaten pegen, indem er sie einliest, löscht oder erweitert 4 .

Dynamische Daten pegen Die dynamischen Daten kann der Administrator, ähnlich

den Stammdaten, vor allem durch Einlesen, Löschen oder Erweitern pegen. Allerdings,

gibt es hier beim Erweitern zwei Besonderheiten. Zuerst soll es dem Administrator möglich

sein, auf Knopfdruck eine bestimmte Anzahl an Datensätzen neu zu generieren

und einzulesen. Darüber hinaus soll er die Möglichkeit haben, in einem bestimmten Zeitintervall

(z.B. alle 30 Sekunden) einen neu generierten Auftrag hinzuzufügen. Beide

genannten Besonderheiten dienen einer Nachbildung der Realtiät, in der ein über die

Zeit kontinuierliches Eintreen von neuen Aufträgen im System zu erwarten ist.

3 Man beachte hier, dass in Kapitel 9.3 beschrieben wird, warum eine Partnersuche ohne Hinterlegung

des Datensatzes im DBS nicht mehr möglich ist.

4 Erweitern ist hier im Sinne von weitere Datensätze einlesen gemeint.

31


4. Systemdesign

4.1. Werkzeuge

Bei der Implementierung nden folgende Werkzeuge Anwendung:

1. TurboDelphi 8 (TD) (ehemals Pascal Object) zur Implementierung der GUIs sowie

einiger Unterstützungsprogramme

2. MySQL Workbench (WB) 5.2 zur Modellierung und Inbetriebnahme des Datenbanksystems

3. MySql Server (MS) 5.5 zur Serverbereitstellung (Instance Conguration Wizard)

4. Verschiedene Anwendungsprogramme wie z.B. MS Excel oder Editor für Unterstützungsfunktionen

4.2. Komponenten

• DBS

• GUI-P zur Fahrteingabe und -verwaltung

• GUI-A zur Datenbankadministration

• Programm zur Validierung von GK

• Programm zur Distanzbestimmung zwischen zwei Orten anhand ihrer GK

4.3. Module

Da es mehrere Teilbereiche geben wird, die unabhängig voneinander bearbeitet werden

können, werden folgende Module gebildet:

• Begrüÿungsmaske mit Verbindungsaufbau zum DBS

• Datensatzerfassungs- bzw. Datensatzbearbeitungsmaske mit den Funktionen

einen neuen Datensatz erfassen

einen neuen Datensatz hinterlegen

33


4. Systemdesign

einen passenden Datensatz zum angezeigten Datensatz nden

einen alten Datensatz anzeigen

Vorschlagliste mit möglichen Partnern für den aktuellen Datensatz

einen Datensatz aus der Vorschlagliste mit Details anzeigen

alle Datensätze ablehnen

• Ausgabemaske für Details zu einem möglichen Partner mit den Funktionen

angezeigten Datensatz annehmen

angezeigten Datensatz ablehnen

Vorschlag für Begegnungspunkt berechnen

• Webbrowser, der den vorgeschlagenen Begegnungspunkt in Google-Maps anzeigt

• Datenbankadministrationsmaske mit den Funktionen

Stammdaten (z.B. Auswahllisten) einlesen

vorgefertigte Demonstrationsdaten einlesen

Demonstrationsdaten on-the-y generieren und hinterlegen

• Programm zur Validierung von GK

• Programm zur Distanzbestimmung zwischen je zwei Orten aus einer Liste anhand

ihrer GK

• Datenbanksystem

4.4. Datenbankmodell

Das in [Mac11], Kapitel 5.2 erarbeitete Datenbankmodell dient für diese Implementierung

nur als Vorbild, da es sich nach intensiver Prüfung in mehreren Relationen als

redundant herausgestellt hat. Darüber hinaus umfasst eine Umsetzung dieses Datenmodells

deutlich mehr Informationen, als tatsächlich benötigt werden. Dies wäre einerseits

aus zeittechnischen Gründen nicht machbar, andererseits würde es durch die unnötige

Komplexität den Erfolg der Softwareimplementierung gefährden.

In Abbildung 4.1 ist das schlussendlich verwendete Datenmodell zu sehen. Es umfasst

zehn Relationen. 1 Diese bestehen aus vier Hauptrelationen mit Auftragsdaten und sechs

Relationen mit Stammdaten.

1 Die Relationen Aufträge und Orte sind durch die Längengrade redundant. Eine bessere Lösung ist in

Kapitel 8.1.1 nachzulesen.

34


4.4. Datenbankmodell

















































































Abbildung 4.1.: Datenmodell

4.4.1. Hauptrelationen - Relationen mit dynamischen Daten

Auftragsdaten

Die Relationen Auftraege, Ladungen und FZ_Ausstattung_Rueckfahrt enthalten Daten,

die einen Auftrag direkt betreen. Ein Datensatz besteht aus je einem Eintrag in jeder

der drei Relationen. Jeder dieser Einträge hat dabei den gleichen Primärschlüssel; dies

erspart eine weitere Relation, die die drei verschiedenen Primärschlüssel durch einen

einzigen identizieren würde. Auftraege enthält die Grunddaten des Auftrages, wie z.B.

Start- und Zielort oder Zeitfenster des Transportes. Ladungen enthält Informationen

über die Ladung, die der Partner selbst mitbringt. Hier kann er bestimmen, mit welcher

Ladeeinheit er fahren möchte und welche Anforderungen seine Ladung bzw. Ladeeinheit

an die Zugmaschine des Tauschpartners stellt. FZ_Ausstattung_Rueckfahrt schlussendlich

enthält Informationen darüber, welche Ausstattung man selbst für die Rückfahrt

35


4. Systemdesign

zur Verfügung stellt.

sonstige dynamische Relationen

In der Relation Auftraege_has_Auftraege wird gespeichert, ob ein Auftrag bereits einen

Partner gefunden hat, welcher die Zusammenarbeit aber noch nicht bestätigt hat.

4.4.2. Stammdatenrelationen

In allen anderen Relationen werden Stammdaten wie z.B. mögliche Fahrzeugarten, Geokordinaten

zu Orten und Partnerinformationen verwaltet. Da das GUI-P sehr einfach

gehalten werden soll, müssen hier viele ja-nein-vielleicht-Angaben abgebildet werden.

Die Grundlage hierfür bietet die Relation Auswahl.

36


5. Umsetzung und Implementierung

Das Gesamtsystem des Demonstrators mit seinen verschiedenen GUIs und Nebenprogrammen

wuchs nebeneinander her. Wie immer in der Entwicklung rufen Änderungen

an einer Stelle Probleme an einer anderen Stelle hervor, die wiederum Änderungen an

der entsprechenden Stelle bedingen. Im folgenden wird die Entwicklung des Systems,

geordnet nach den einzelnen Modulen, beschrieben.

5.1. Stammdatenauswahl und Dienstprogramme

Hand in Hand mit der Entwicklung des GUI-P ging die Auswahl der verwendeten Daten

zu späteren Demonstrationszwecken. Hierbei musste auch darüber entschieden werden

• welche Fahrzeuge und Ladeeinheiten,

• welche technischen und rechtlichen Gegebenheiten,

• welche Firmen mit ihren Stammdaten und

• welche Orte mit ihren GK

im System hinterlegt werden. Im folgenden soll nun erst auf die einfachen Listen eingegangen

werden, bevor auf die Liste mit Daten eingegangen wird, die den gröÿten

Arbeitsaufwand mit sich brachte.

5.1.1. Einfache Listen

Die Datenauswahl der einfachen Listen wurde in Abstimmung mit der Leitung des

DTM-Projektes auf die Bedürfnisse der am Projekt beteiligten Unternehmen zugeschnitten.

Es stellte sich jedoch relativ schnell heraus, dass, bedingt durch die breite Aufstellung

des Projektkonsortiums, auÿer bei der Fahrzeugauswahl keine Möglichkeiten bestehen,

den Demonstrator anzupassen. Die wurden ausschlieÿlich die Fahrzeugauswahl

und die technischen Informationen über Ladung und Ladeeinheit in die einfachen Listen

aufgenommen.

Fahrzeugauswahl

Die Ladeeinheitenauswahl sollte mit der Fahrzeugauswahl verbunden werden, da die

Partner des Projektes eine eindeutige Vorstellung präsentierten, wie Fahrzeuge und

Ladeinheiten kombiniert werden und teilweise bereits entsprechende Pools an Ladeeinheiten

und Fahrzeugen betreiben. Die zu verwendenden Kombinationen waren:

37


5. Umsetzung und Implementierung

• Motorwagen mit Wechselbrücke

• Euro-Gliederzug mit Wechselbrücken

• Euro-Sattelzug mit festem Aufbau

• langer Sattelzug mit festem Aufbau (Sattelzugmaschine mit einem längeren Trailer

z.B. dem Euro-Trailer von Kögel (vgl. [Kög11])

Nun gilt es allerdings zu beachten, dass die Planung des Fahrzeugeinsatzes gemäÿ

[Mac11], Kapitel 3.2 + 3.3 erst stattndet, nachdem ein Begegnungspartner gefunden

wurde. Hierdurch ergibt sich die Möglichkeit, dass sich ein Partner auf seinen Gegenüber

einstellt. Es sollten also auch die Auswahlmöglichkeiten gewünschter Sattelzug,

bei der der Partner nur Sattelzüge bedienen kann, aber je nach Wunsch seines Gegenübers

mit einem langen Sattelauieger oder einem Euro-Sattelauieger anfahren kann

und gewünschtes Fahrzeug, bei dem der Partner auf jeglichen Fahrzeugwunsch seines

Gegenübers eingehen kann, berücksichtigt werden. Bezieht man dies alles in die Überlegungen

zur Fahrzeugauswahl mit ein, ergeben sich hieraus die in Tabelle 5.1 aufgezeigten

Kombinationsmöglichkeiten für den Demonstrator:

Fahrzeug

Motorwagen mit Wechselbrücke

Euro-Gliederzug

Euro-Sattelzug

langer Sattelzug

gewünschter Sattelzug

gewünschtes Fahrzeug

mögliche Partner

Motorwagen mit Wechselbrücke

gewünschtes Fahrzeug

Euro-Gliederzug

gewünschtes Fahrzeug

Euro-Sattelzug

gewünschter Sattelzug

gewünschtes Fahrzeug

langer Sattelzug

gewünschter Sattelzug

gewünschtes Fahrzeug

gewünschter Sattelzug

Euro-Sattelzug

langer Sattelzug

gewünschtes Fahrzeug

gewünschtes Fahrzeug

Motorwagen mit Wechselbrücke

Euro-Gliederzug

Euro-Sattelzug

langer Sattelzug

gewünschter Sattelzug

Tabelle 5.1.: Kombinationsmöglichkeiten der Fahrzeuge

38


5.1. Stammdatenauswahl und Dienstprogramme

Technische Informationen über Ladung und Ladeeinheit

Vom zu benutzenden Fahrzeug abgesehen kann auch die Ladung den Ausschlag über

einen möglichen Begegnungsverkehr geben. Über Ja-Nein-Vielleicht-Angaben sollte

hier abgefragt werden:

• ob ein Kühltransport vorliegt, bzw. akzeptiert würde,

• ob eine Jumboladeinheit benötigt wird, bzw. akzeptiert würde,

• und ob für die Auslieferung eine Hebebühne benötigt wird, bzw. gestellt werden

könnte.

Um Änderungen in der Ja-Nein-Vielleicht-Auswahl einfacher gestalten zu können,

wurde auch für diese eine Stammdatenliste angelegt.

Über die genannten Daten hinaus, müssen dringend die Information vorhanden sein,

ob es sich bei der Ladung um Gefahrgut handelt. Hier am besten so detailliert wie

möglich. Daher wurden die zwei wichtigsten Informationen, nämlich die Gefahrgutklasse

und die Verpackungsgruppe, als Stammdatenlisten aufgenommen. Darüber hinaus sollte

über zwei weitere Ja-Nein-Vielleicht-Angaben abgefragt werden, ob Gefahrgut unter

und über 1000 Gefahrgutpunkten vom Partner akzeptiert würde. 1

5.1.2. Geokoordinaten

Auf dem Datenträger zu [Mac11] nden sich Listen zu Firmen und Orten mit GK. Da die

Daten auf dem Datenträger jedoch teilweise nur als Ur-Listen vorhanden sind, musste

der Versuch unternommen werden, die Daten in eine verwendbare Form zu bringen.

Programm zur Validierung von GK

In den beiden vorhandenen Listen mit Orten und ihren GK gibt es Datensätze mit

Validitätsprobleme. Diese sind:

• syntaktische Fehler (Buchstaben als GK z.B. 4,38 N; 3,B O)

• semantische Fehler

Das erste Problem wurde dadurch gelöst, dass ein (algorithmisch unspektakuläres)

Dienstprogramm alle Datensätze eliminierte, die syntaktisch nicht haltbar sind. Nach

erfolgreicher Durchführung dieses Schrittes waren von 177.000 Datensätzen noch 172.000

übrig, was einem Verlust von etwa 3% entspricht. Im nächsten Schritt wurden 5 Orte, die

mehr als einmal in der Liste verzeichnet sind mit ihren Geokoordinaten in Google-Maps

überprüft. Hierbei wurde der zweite Fehler festgestellt. So gab es z.B. vier Einträge für

Ulm. Drei davon betreen Ulm an der Donau während einer Ulm bei Wetzlar betrit.

1 Die Gefahrgutvorschriften unterscheiden zwischen Transporten mit weniger als 1000 Gefahrgutpunkten

und Transporten mit 1000 Gefahrgutpunkten und mehr. In der Praxis unterscheidet sich vor

allem die benötigte Ausrüstung und Fahrerqualikation bei Transporten der jeweiligen Kategorien.

39


5. Umsetzung und Implementierung

Da sich diese Art semantischer Fehler mit den zur Verfügung stehenden Mitteln nur mit

unangebracht hohem Arbeitsaufwand nden und eliminieren lässt, wurden diese Listen

nicht weiter bearbeitet. Da die Listen mit den Firmen in ähnlicher Weise unbrauchbar

waren, wie die Listen mit den Geokoordinaten, wurden schlussendlich durch das DTM-

Team erstellte Listen verwendet. In diesen liegen die Geokoordinaten als Dezimalzahlen

vor.

Programm zur Distanzbestimmung zwischen je zwei Orten aus einer Liste

anhand ihrer Geokoordinaten

Abbildung 5.1.: Maske für Distanzberechnung zwischen Depots und Orten

Um später geeignete Datensätze für Demonstrationszwecke eingeben zu können, benötigt

man Informationen, welcher Ort in welchem Umkreis um ein Depot liegt. Hierfür

wurde das in Abbildung 5.1 gezeigte Dienstprogramm erstellt, das wie folgt arbeitet:

In einer ersten Liste werden Ortsnamen und GK von Depots eingelesen. In einer

zweiten Liste werden alle vorhandenen Orte mit ihren GK, die im Interessenbereich (hier

z.B. Deutschland) liegen eingelesen. Der in Abbildung 5.2 beschriebene Algorithmus 2

testet nun für jedes Depot, ob ein Ort aus der Gesamtliste innerhalb eines bestimmbaren

Umkreises liegt. Ist das der Fall, wird ein Eintrag in einer dritten Liste erfasst.

2 Dieser und folgende Algorithmen in dieser Arbeit werden als Programm Ablauf Plan (DIN 66001)

(PAP) abgebildet.

40


5.1. Stammdatenauswahl und Dienstprogramme

Start

Eingabe Liste mit

Depot-Orten

Eingabe Liste mit

allen Orten im

Interessengebiet

Eingabe gewünschter

Radius des Umkreises

um das Depot

diff_longitude, diff_latitude,

distanz, distanz_max : Real;

A

diff_latitude := 60*1,853 *

(Differenz der Breitengrade

der aktuellen Orte)

diff_longitude := 60*1,853 *

(Differenz der Längengrade

der aktuellen Orte)

Distanz :=

SQRT(diff_longitude² +

diff_latitude²)

Distanz_max := gewünschter

Radius um Depot.

Zielliste löschen

Distanz


5. Umsetzung und Implementierung

5.2. Datenbank

Ausgehend von den Ideen, die in [Mac11], Kapitel 5.2 aufgezeigt sind, wurde zuerst

sondiert, was von diesen Daten wirklich verwendet werden muss. Hierdurch konnte das

DBS auf drei Relationen reduziert werden. Diese enthielten:

• Stammdaten der Firmen,

• GK der Orte,

• und Auftragsdaten mit Informationen zu Hin- und Rückfahrt.

Zu diesem Zeitpunkt musste entschieden werden, ob die Daten für Auswahlcomboboxen,

hart im GUI-P hinterlegt werden oder ob sie in der Datenbank mit hinterlegt

werden sollen, um mögliche Änderungen einfacher durchführen zu können. Die Entscheidung

el auf letztgenannte Möglichkeit, was die in Abbildung 4.1 auf Seite 35 sichtbare

Datenbank in die abgebildete Form brachte. Ein Zusammenfügen der Relationen mit den

eigentlichen Auftragsdaten (Auftraege, Ladungen und FZ_Ausstattung_Rueckfahrt ) zu

einer einzigen Relation wäre nach heutigem Stand durchaus möglich, jedoch erleichtert

die Trennung der Relationen das Verständnis und vor allem die späteren Structured

Query Language (SQL)-Abfragen ungemein.

5.3. Die Anmeldemaske - Ein Zugang zur Datenbank

Die Anmeldemaske des GUI-P entspricht einem oft verwendeten Schema. Nach einem

miÿlungenen Versuch, eine bereits bestehende Maske als Grundgerüst für die Anmeldung

zu verwenden, wurde in mehreren Schritten die in Abbildung 5.3 sichtbare Maske

entwickelt. Die graphische Oberäche der Maske war dabei von geringerer Bedeutung.

Die gröÿte Aufgabe hierbei war, einen Weg zu nden, der es dem in TD entwickelten

GUI-P ermöglicht mit einer SQL-Datenbank auf einem Server zu kommunizieren.

Diese Möglichkeit wurde durch die Verwendung einer GNU General Public License

(GNU GPL) der mysqldirect library (msdl) von Cristian Nicola geschaen. 3 Dieses Softwarepaket

aus dem Jahr 2003 ermöglicht sowohl die Anmeldung, als auch sonstige Datenbankoperationen

auf einer SQL-Datenbank aus einem TD-basierten Programm heraus.

Da einerseits das GUI-P, andererseits aber auch das GUI-A das msdl-Softwarepaket als

eine Art Blackbox verwendet, um mit dem DBS-Modul zu kommunizieren, soll im folgenden

kurz auf die Verwendungsweise des Paketes eingegangen werden: Der PAP in

Abbildung 5.4 zeigt die grundsätzliche Funktionsweise des msdl-Paketes. Ziel des dort

dargestellten Algorithmus ist es, herauszunden wie viele Datensätze sich in der Relation

Orte benden.

3 Das msdl-Paket sowie eine mehr oder weniger ausführliche Anleitung dazu erhält man in [Nic03].

Viele weitere Tipps und Tricks, die maÿgeblich zum Erfolg dieser Implementierung beigetragen

haben, nden sich in [DTT11].

42


5.3. Datenbankzugang

Abbildung 5.3.: Anmeldemaske

In FResult wird immer eine Matrix mit der Ergebnismenge abgespeichert. Im Falle der

count-Anweisung enthält diese nur eine Zeile. Sollte eine Abfrage keine Ergebnismenge

haben, hat auch die Ergebnismatrix keine Zeilen. Hierbei gilt zu beachten, dass die

msdl alle Operationen auÿer dem Anmeldevorgang als Abfragen interpretiert. Um z.B.

Löschoperationen auszuführen muss lediglich der Variablen q der richtige SQL-Befehl

zugeordnet werden; jedoch ist bei einer Löschoperation die Ergebnismenge immer leer.

Innerhalb der Ergebnismatrix FResult wird mit dem Befehl FResult.First die erste

Zeile und mit dem Befehl FResult.Next die jeweils folgende Zeile aufgerufen. Innerhalb

einer Zeile können bestimmte Spalten über FResult.FieldValue(i) aufgerufen werden,

wobei der Index i bei 0 für die erste Spalte beginnt. Zur Verdeutlichung kann Tabelle

5.2 betrachtet werden.

43


5. Umsetzung und Implementierung

0 1 2 3

FResult.First alpha betha gamma delta

FResult.Next ↓ epsilon zeta eta theta

Tabelle 5.2.: Beispiel für Ergebnismatrix

Start

Eingabe von SQL-

Abfrage: "select

count(*) from orte"

q : String;

FResult :

Abfragenergebnismatrix;

q sei die eingegebene

Abfrage

Führe in q gespeicherte

Abfrage aus

Abfrage erfolgreich?

false

true

Speichere die Ergebnismenge

in FResult.

Ausgabe von

entsprechender

Fehlermeldung

Ende

Abbildung 5.4.: Algorithmus des msdl-Paketes

44


5.4. Die Partnersuche

5.4. Die Partnersuche

Kommen wir nun zum Herzstück des Programmes, dem eigentlichen GUI-P. Da dieses

GUI-P mehrere Aufgaben nebeneinander erfüllen muss, wird hier in der Reihenfolge

darauf eingegangen, in der sie ein Benutzer erfahren würde.

5.4.1. Eingabe von Datensätzen

Nach einer erfolgreichen Anmeldung über die Anmeldemaske erscheint die in Abbildung

5.5 gezeigte Maske. Zu Beginn sind alle Comboboxen leer. Ein füllen der Comboboxen

beim On-Create-Ereignis der Maske (Analog zu den Edit-Feldern für die Zeit-Daten) war

zwar vorgesehen, ist aber daran gescheitert, dass man TD-Comboboxen anscheinend erst

füllen kann, wenn sie bereits auf dem Bildschirm sichtbar sind. Die Comboboxen werden

gefüllt, wenn das Edit-Feld Partnernummer den Fokus erhalten und wieder verloren hat.

Dann kann der Benutzer nach und nach die Comboboxen und Edit-Felder ausfüllen.

Abbildung 5.5.: Maske zur Datensatzeingabe

45


5. Umsetzung und Implementierung

5.4.2. Test auf Validität der Daten

Die Funktion DatenOK ist ausschlieÿlich dafür gedacht, zu testen ob in alle Felder ein

(gültiger) Wert eingegeben wurde. Sie wird automatisch aufgerufen, wenn ein Datensatz

hinterlegt oder eine Partnersuche durchgeführt werden soll. Ist eine der Eingaben nicht

in Ordnung wird eine Kennzahl zurückgegeben. Anhand der Kennzahl wird ausgewertet,

welche Fehlermeldung ausgegeben wird. Um prüfen zu können, welche der Comboboxen

gefüllt ist, und welche nicht, bzw. ob eine Combobox vielleicht deaktiviert ist (im Falle

der Comboboxen für Gefahrgut ist das möglich) wurden weitere Funktionen (z.B. idxg0 )

angelegt und zusammen mit DatenOK in einer eigenen Unit untergebracht.

5.4.3. Datensatz in der Datenbank hinterlegen

Bevor wir näher auf den Algorithmus für die Datensatzhinterlegung eingehen, sollte geklärt

werden, wie die Daten, im speziellen die Daten aus den Comboboxen, im DBS

hinterlegt werden. Wie im Datenmodell auf Seite 35 zu sehen ist, werden alle Angaben,

die aus Comboboxen stammen, über ihren Primärschlüssel, welcher immer eine Integerzahl

ist, identiziert. Der Primärschlüssel beginnt immer bei 0 und zählt für jeden

Eintrag um eins hoch. Genau so verhält sich auch der Index der Comboboxen. Der erste

Eintrag erhält eine 0 als Index. Ist in einer Combobox kein Eintrag vorgenommen worden,

hat die Combobox den Indexwert -1. Durch die Gleichsetzung von Primärschlüssel

und Comboboxindex erleichtert sich die Generierung eines neuen Datensatzes, da man

den Index der Combobox direkt in die Datenbank schreiben kann, ohne den Umweg

einer Identizierung (z.B. durch Abgleich des Strings in der Combobox mit den Strings

in der Stammdatenliste) zu gehen. Jedoch ergibt sich hieraus auch der Umstand, dass

zusätzliche Einträge in Stammdatenlisten nur hinten angefügt werden können, um die

benötigte Stabilität zu erhalten. 4

Da ein Datensatz, der in die Maske eingegeben wird, mehrere Relationen des DBS

betrit, spaltet sich der Prozess einer Datensatzhinterlegung in zwei Teile auf. Zuerst

müssen alle notwendigen Daten im Hauptspeicher zwischengespeichert werden. Dann

erst kann, für jede Relation einzeln, ein SQL-Statement erstellt werden, das die Daten

im DBS hinterlegt. Der PAP in Abbildung 5.6 zeigt die Abfolge der Operationen für

eine solche Hinterlegung, die die Maske und das DBS betreen. Der PAP in Abbildung

5.7 zeigt stellvertretend am Beispiel für die Relation FZ_Ausstattung_Rueckfahrt, wie

ein SQL-Statement im Quelltext zusammengestellt wird.

4 Diese Problematik wird in Kapitel 9.1 weiter diskutiert.

46


5.4. Die Partnersuche

Start

Eingabe von

Datensatz in Maske

eingegebene Daten

valide?

false

true

hole die Orts-ID des Depot-Ortes

aus der Datenbank und speichere

sie zwischen

stelle fest, welche ID als nächstes

in der Relation "Auftraege" zu

verwenden ist und speichere sie

zwischen

formatiere das Be-, Entlade- und

Verfallsdatum des Datensatzes so

um, dass die Datenbank sie lesen

kann und speichere sie zwischen

hole die Geokoordinaten für den

Depot-Ort aus der Datenbank und

speichere sie zwischen

hole die Geokoordinaten für den

Start-Ort aus der Datenbank und

speichere sie zwischen

hole die Geokoordinaten für den

Ziel-Ort aus der Datenbank und

speichere sie zwischen

Ausgabe von

entsprechender

Fehlermeldung

A

stelle das SQL-Statement

für die Relation

"Auftraege" zusammen

und führe es aus

stelle das SQL-Statement

für die Relation

"Ladungen" zusammen

und führe es aus

stelle das SQL-Statement

für die Relation

"FZ_Ausstattung_Rueckfah

rt" zusammen und führe es

aus

Ende

A

Abbildung 5.6.: Algorithmus der Datensatzhinterlegung

47


5. Umsetzung und Implementierung

Start

Eingabe von allen

notwendigen Daten

in Eingabemaske

q : String;

newid, Fahrzeug,

Gefahrgutgrößer 1000,

Gefahrgutkleiner1000,

Thermo, Jumbo, Hebebühne

: string

newid := nächste freie id der

Relation "Auftraege"

Fahrzeug := Index der

Combobox

"Fahrzeugauswahl" als

String;

Gefahrgutgrößer1000 :=

Index der Combobox

"Gefahrgutgrößer1000" als

String;

Gefahrgutkleiner1000 :=

Index der Combobox

"Gefahrgutkleiner1000" als

String;

Thermo := Index der

Combobox

"Thermotransport" als String;

Jumbo := Index der

Combobox "Jumbotransport"

als String;

Hebebühne := Index der

Combobox "Hebebühne

nötig" als String;

A

q := 'insert into

fz_ausstattung_rueckfahrt

values ('

q := q +newid + ','

q := q + Fahrzeug + ','

q := q +

Gefahrgutgrößer1000 + ','

q := q +

Gefahrgutkleiner1000 + ','

q := q + Thermo + ','

q := q + Jumbo + ','

q := q + Hebebühne + ')'

Ausgabe des fertigen

SQL-Statements in

der Variablen q

Ende

A

Abbildung 5.7.: Algorithmus zur Vorbereitung eines SQL-Statements

48


5.4.4. Matching

5.4. Die Partnersuche

In [Mac11], Kapitel 4.7 wird der Matching-Algorithmus zum damaligen Stand beschrieben.

Dieser sieht vor, dass erst eine Grobauswahl der Datensätze anhand weniger Kriterien

ausgeführt wird, bevor rechenaufwendigere Kriterien einzeln abgefragt werden.

[Mac11] sieht hierbei die Distanzberechnungen als zu den rechenaufwendigen zugehörig

an. Ebenso ist hier ein Ranking vorgesehen, das besser und schlechter passende Aufträge

gestaelt ausgibt. Allerdings basiert das Ranking auf Informationen, die diese

Implementierung nicht vorsieht. So ist z.B. ein Kriterium die tatsächlich zu fahrende

Strecke. Da diese Implementierung jedoch ausschlieÿlich Luftlinien als Distanzen verwendet,

fehlt diese Information. Ein Ranking der Aufträge ist damit im Demonstrator

also nicht umsetzbar.

Als sehr guter Ansatz erwies sich die Idee der Grobauswahl, bevor eine Feinauswahl

durchgeführt wird. Die Grundidee für die Umsetzung derselben bestand darin, eine Grobauswahl

direkt im DBS durchzuführen und das Ergebnis dieser Grobauswahl im Hauptspeicher

des PCs zur Weiterverarbeitung zwischenzuspeichern. Dies würde zwar relativ

komplexe SQL-Abfragen erfordern, aber jede gestartete Suche benötigt dadurch nur eine

Hauptabfrage plus vielleicht ein bis zwei kleinere Nebenabfragen. Dies minimiert die

Zugrie auf das DBS und verbessert damit die Zugriszeiten sowie die (für spätere Systeme

interessante) Mehrbenutzerfähigkeit. Ein erster Ansatz für diese Umsetzung ist in

Abbildung 5.8 zu sehen.

49


5. Umsetzung und Implementierung

Start

hat der eigene Datensatz bereits

einen Partner?

false

true

Grobauswahl

Anzahl Datensätze > 0 ?

false

true

Daten der Grobauswahl in

den Hauptspeicher laden

Detailprüfung

Anzahl Datensätze > 0 ?

false

true

Ausgabe von Liste

mit passenden

Transporten

Ausgabe von

entsprechender

Fehlermeldung

Ende

Abbildung 5.8.: Grundlegende Vorgehensweise bei der Partnersuche

50


5.4. Die Partnersuche

Grobauswahl

Um die Antwortzeiten des Systems, das in späteren Implementierungen über eine Internetplattform

bedient werden soll, möglichst gering zu halten, müssen in der Grobauswahl

möglichst viele Datensätze ausgeltert werden. Die gröÿten Filtereekte erzielen in der

Regel die Streckenauswahl und das Zeitfenster des Transportes. Nach längerer Diskussion

mit erfahrenen Programmierern stellte sich heraus, dass die Distanzberechnung

zwischen zwei Punkten nicht so rechenaufwendig ist, wie in [Mac11], Kapitel 4.7 vermutet,

wenn man sie direkt im DBS durchführt. So kam es zu folgenden Anforderungen für

die Grobauswahl:

1. Es wird keine Suche ausgeführt, wenn der eigene Datensatz bereits einen Partner

gefunden und bestätigt hat.

2. Es werden alle Datensätze ausgeltert, die bereits einen Partner gefunden und

(einseitig) bestätigt haben.

3. Es werden alle Datensätze ausgeltert, deren Zeitfenster sich nicht um mindestens

fünf Stunden überschneiden.

4. Es werden alle Datensätze ausgeltert, deren Zielort nicht im gewünschten Umkreis

um das eigene Depot, bzw. bei denen der eigene Zielort nicht im gewünschten

Umkreis um das Depot des Partners liegt.

Die ersten zwei Punkte sind selbsterklärend. Trotzdem muss Punkt eins im vorhandenen

DBS mit einer eigenen Abfrage der Relation Auftraege_has_Auftraege geklärt

werden. Diese stellt fest, ob die ID, des Datensatzes in dieser Relation vorhanden ist.

Wenn ja, hat der Datensatz bereits einen Partner gefunden. Datensätze, und für die eine

Suche durchgeführt wird, benötigen diese Prüfung nicht. Zum Verständnis von Punkt

drei bietet Abbildung 5.9 Unterstützung. Im Demonstrator kann für einen Transport nur

ein Zeitfenster deniert werden. Es umschlieÿt die Zeitspanne von der frühesten Abholung

der Ware bis zur spätesten Zustellung. Der Demonstrator geht davon aus, dass ein

Begegnungsverkehr in der Regel erfolgreich durchführbar ist, wenn sich die Zeitfenster

zweier Aufträge um mindestens fünf Stunden überschneiden. Daher wären die Partneraufträge

P1, P2 und P4 auszultern, während P3, P5 und P6 in die Detailprüfung

eingehen dürfen.

Ebenso ist Punkt vier mit Abbildung 5.10 zu erklären. Der eigene Auftrag EZ 1 liegt

im Umkreis von Partner 1. Im Umkreis um das eigene Depot liegen zwei Transportziele.

Da der eigene Auftrag aber nur im Umkreis von Partner 1 liegt kann ausschlieÿlich

dessen Auftrag P1 Z1 in die Detailprüfung eingehen. Die Aufträge P1 Z2 und P2 Z1

müssen ausgeltert werden.

51


5. Umsetzung und Implementierung

Abbildung 5.9.: Überschneidung der Zeitfenster

EZ 1

Partner 1

Depot

P1 Z1

Eigenes

Depot

P2 Z1

P1 Z2

Partner 2

Depot

Abbildung 5.10.: Finden von Transporten mit passendem Ziel

52


5.4. Die Partnersuche

Detailprüfung

In der Detailprüfung müssen nun alle Datensätze, die es durch die Grobauswahl geschat

haben, auf ihre tatsächliche Kombinationsfähigkeit mit dem eigenen Auftrag getestet

werden. Hierbei werden immer die Angaben zur eigenen Ladung mit den Angaben

zur Ausstattung des Fahrzeuges des Partners und umgekehrt verglichen. Aufgrund der

Tatsache, dass in der Maske viele Comboboxen mit Ja-Nein-Vielleicht-Angaben bzw.

sonstiger beschränkter Auswahl verwendet wurden, ergeben sich drei Kategorien von

Vergleichen, die ausgeführt werden müssen:

Fahrzeugauswahl Die möglichen Kombinationen der verschiedenen Fahrzeuge sind

Kapitel 5.1.1 zu entnehmen. Geprüft wird hier ob der auf der Registerkarte Ladung angegebene

Fahrzeug- und Ladeeinheitentyp mit dem vom Partner angegebenen Fahrzeugund

Ladeeinheitentyp auf der Registerkarte Ausstattung Rückfahrt kombinierbar ist. Ist

das nicht der Fall, wird die Prüfung sofort beendet und der nächste Datensatz herangezogen.

Ist das jedoch der Fall, so kann getestet werden, ob der vom Partner angegebene

Fahrzeug- und Ladeeinheitentyp auf der Karte Ladung mit eigenen Angabe auf der Karte

Ausstattung Rückfahrt zusammenpasst. Auch hier wird wieder abgebrochen, falls die

Angaben einen Begegnungsverkehr ausschlieÿen. Ansonsten werden die restlichen Parameter

geprüft.

Thermo, Jumbo und Hebebühne Bei diesen drei Angaben handelt es sich auf beiden

Seiten um Ja-Nein-Vielleicht-Angaben daher können sie vereinfacht beschrieben

werden. In Tabelle 5.3 nden sich alle Kombinationen, die im Demonstrator als nicht

Begegnungsfähig interpretiert werden und den Prüfungsprozess abbrechen. 5 Auch hier

müssen die Daten wieder in beide Richtungen getestet werden.

Karte Ladung

Ja

Nein

Karte Ausstattung Rückfahrt

Nein

Ja

Tabelle 5.3.: Auswertung der Ja-Nein-Vielleicht Angaben

Gefahrgut Gefahrgutangaben sind im Demonstrator die einzigen Angaben, die Auswirkungen

auf die Detailauswertung haben und nicht vollständig über Comboboxen

eingegeben werden. Jedoch ist deren Auswertung immer noch sehr einfach. Die einzige

Angabe, die Gefahrgut auf einen Nenner bringt, ist die Anzahl der Gefahrgutpunkte die

einer Ladung zugeordnet werden. Ausstattungstechnisch und rechtlich wird zwischen

Transporten ohne, mit weniger als 1000 und mit 1000 und mehr Gefahrgutpunkten unterschieden

(vgl. [Gef11], Unterabschnitt 1.1.3.6 der Anlage A). Daher muss nach diesen

5 Während der Erstellung dieser Dokumentation el auf, dass diese Interpretationsweise falsch ist. In

Kapitel 9.2 klärt eine Diskussion über die richtige Interpretation der Daten auf.

53


5. Umsetzung und Implementierung

Kriterien geprüft werden. Falls einer Ladung Gefahrgutpunkte zugeordnet werden, müssen

diese auf der Registerkarte Ladung angegeben werden. Dann kann, wie in Tabelle

5.4 abgebildet, ausgewertet werden. Auch hier sind wieder nur diejenigen Kombinationen

aufgelistet, die zu einer Auslterung des Datensatzes führen. Auf den ersten Blick

erscheint es hierbei als Fehler, dass ein Partner Gefahrgut erst ab 1000 Punkte akzeptiert,

jedoch ist diese Möglichkeit durchaus denkbar, wenn Gefahrgut über 1000 Punkten

besonders vergütet wird.

Karte Ladung

Karte Ausstattung Rückfahrt:

Combobox kleiner

1000Punkte

X>0 Nein Nein

0


5.4. Die Partnersuche

Kombination aus zwei Ids nur zwei Mal eingetragen werden, was auch so geschieht. Der

Vorgang der in Kapitel 5.4.4 zu Punkt eins erklärt wird, verhindert, dass eine Datensatz-

Id mit einer dritten Datensatz-Id einen neuen Primärschlüssel bildet. Daraufhin werden

alle verbleibenden Datensätze aus der Maske gelöscht. Der Partner kann nun auf die

Bestätigung durch sein Gegenüber warten.

5.4.6. Berechnung des Begegnungspunktes

Der Begegnungspunkt ist der Ort, an dem sich zwei Transporte treen, um ihre Ladung

auszutauschen. Neben vielen anderen Anforderungen wie z.B. ausreichendem Platz,

rechtlicher Unbedenklichkeit oder der einfachen Zugänglichkeit des Ortes, ist vor allem

die Lage des Ortes im Verhältnis zu den Start- und Zielorten der beiden Transporte von

Interesse. Die Lage des Begegnungspunktes hat groÿen Einuss auf die benötigte Fahrzeit

der einzelnen Zugmaschine. [Mac11], Kapitel 4.3 erläutert in mehreren Szenarien,

welche Parameter in eine Begegnungsverkehrberechnung aufgenommen werden können.

Der Demonstrator verwendet das in [Mac11], Kapitel 4.3.4 beschriebene Szenario 3 in

Kombination mit der in [Mac11], Kapitel 4.4 beschriebenen Variante 2 zur Gewichtung

der Teilstrecken.

Grundlagen zur Berechnung

Auf den ersten Blick sollte ein Begegnungspunkt in der Mitte zwischen der beiden Depots

liegen. Allerdings sind die beiden Depots nicht die Start- und Zielpunkte der Transporte.

Diese liegen in einem (vom Disponenten) frei denierbaren Umkreis um das Depot.

Abbildung 5.11 zeigt schematisch mehrere Situationen, an denen deutlich wird, dass die

Einbeziehung der Depots eine Begegnungspunktberechnung deutlich verfälschen würde.

In Situation (a) liegen die Start- und Zielorte relativ geschickt, sodass der Mittelpunkt

zwischen den Depots als Begegnungspunkt durchaus in Frage kommt. In Situation (b)

würde eben dieser Begegnungspunkt einen der Partner benachteiligen. In Situation (c)

ist nur der Begegnungspunkt verschoben, sodass wieder gleiche Transportstrecken entstehen.

Bei diesen Transportstrecken werden die Anfahrt zur Abholadresse und die Fahrt

von der Zustelladresse zum Heimatdepot nicht beachtet. Versucht man nun eine Gesetzmäÿigkeit

zu nden, die den Punkt anzeigt, bei dem beide Parteien möglichst gleiche

Fahrstrecken zurückzulegen haben, so stellt sich der Schwerpunkt der vier Start- und

Zielorte der Transporte als 100% zuverlässig heraus. Ein Schwerpunkt lässt sich auch

für GK durch die Bildung des arithmetischen Mittels der Längen- bzw. Breitengrade

ermitteln.

Nun ist es möglich, dass ein Fahrer zu Beginn eines Begegnungsverkehres nicht mehr

die vollen neuen Stunden seiner Tagesfahrzeit (vgl. [Mac11], Kapitel 2.1.3) zur Verfügung

hat. Um zu verhindern, dass einer der Fahrer weiter fahren muss, als seine Restfahrzeit

es zulässt, wäre es in diesem Moment durchaus sinnvoll, den Begegnungspunkt in Richtung

desjenigen Fahrers zu verschieben, der die kürzere Restfahrzeit hat. Um dies zu

erreichen bedient sich der Demonstrator des gewichteten Schwerpunktes. Das Konzept

einer Schwerpunktberechnung anhand von gewichteten Einzelpunkten wird in [Mac11],

55


5. Umsetzung und Implementierung

(a)

EZ 1

ES 1

Partner

Depot

BP

Eigenes

Depot

PS 1

P Z1

(b)

ES 1

Partner

Depot

PS 1

EZ 1

BP

Eigenes

Depot

P Z1

(c)

Partner

Depot

PS 1

EZ 1

BP

Eigenes

Depot

ES 1

P Z1

Abbildung 5.11.: Szenario für die Begegnungspunktberechnung

Kapitel 4.4 anhand eines Beispiels erläutert. Im Demonstrator werden die bis dahin

bekannten Punkte einer tatsächlichen Tour 6 mit der Fahrzeit des jeweils anderen Fahrers

gewichtet. In Abbildung 5.12 sieht man den Algorithmus, wie er im Demonstrator

umgesetzt wurde.

Im Gegensatz zu den Vorschlägen, die in [Mac11], Kapitel 4.3.4 gemacht werden, führt

dieser Algorithmus nur eine relative Verlegung des Begegnungspunktes durch. D.h. der

Begegnungspunkt bleibt gleich, wenn sich die Fahrzeiten der Fahrer ändern, aber im

gleichen Verhältnis zueinander bleiben. Hierdurch bleibt auÿer Acht gelassen, dass eine

Strecke zu lang sein könnte, um einen Begegnungsverkehr innerhalb der Restfahrzeit

durchzuführen, jedoch wären für eine solche Berechnung auch weitere Informationen

wie die tatsächlich zu fahrende Strecke (und nicht Luftlinie) oder die wahrscheinliche

6 Mit tatsächlicher Tour ist hier diejenige Tour gemeint, die einem Fahrzeug bei einem Begegnungsverkehr

zugeteilt wird. In Abbildung 5.11 z.B. EZ1 - BP - PS1

56


5.4. Die Partnersuche

Durchschnittsgeschwindigkeit des Fahrzeuges nötig. Diese Informationen sind für den

Demonstrator jedoch zu detailliert, um sie ohne Übersichtlichkeitsverlust implementieren

zu können.

57


5. Umsetzung und Implementierung

Start

Geokoordinaten von

PS1, ES1, PZ1 und

EZ1

Fahrzeiten der Faher

EF1, PF1

PS1* = Längen- und

Breitengrad PS1 mit Fahrzeit

EF1 multiplizieren

EZ1* = Längen- und

Breitengrad EZ1 mit Fahrzeit

EF1 multiplizieren

ES1 * = Längen- und

Breitengrad ES1 mit Fahrzeit

PF1 multiplizieren

PZ1 * = Längen- und

Breitengrad PZ1 mit Fahrzeit

PF1 multiplizieren

BP(Länge) := Summe der

Längengrade geteilt durch

die Summe der Fahrzeiten

BP(Breite) := Summe der

Breitengrade geteilt durch

die doppelte Summe der

Fahrzeiten

Ausgabe von BP

(Längen- und

Breitengrad)

Ende

Abbildung 5.12.: Algorithmus der Begegnungspunktberechnung

58


Teil II.

Handbuch

59


6. Voraussetzungen und Installation

Ziel dieses Handbuches ist es, den Leser zu befähigen, den Demonstrator zu bedienen

und Präsentationen damit auszuführen. Das Handbuch bezieht sich im Gegensatz zur

Software-Dokumentation, auf Version 1.1 vom 10.08.2011.

6.1. Bestandteile

Der Demonstrator besteht aus vier Teilen:

• Datenmodell

• dem GUI-A

• dem GUI-P

• dem Entfernungsrechner

Auf dem Datenträger Matching-Software (Anhang B auf Seite 79) nden sich im

Ordner Demonstrator V1.1 die drei Anwendungen als .exe-Datei sowie das Datenmodell

als .mwb-Datei. Darüber hinaus ndet sich der Ordner Grunddaten_DTM sowie

drei .txt-Dateien. Im Ordner Grunddaten_DTM benden sich die Daten für die statischen

Tabellen. Die .txt-Dateien, die lose im Ordner Demonstrator V1.1 liegen,

beinhalten die Datensätze für die Auftragstabellen.

6.2. Systemanforderungen

Die Anforderungen des Demonstrators an die Hardware sind nicht der Rede wert. Jeder

handelsübliche PC ist im Stande die Software auszuführen. Interessanter sind die

Anforderungen an das Betriebssystem: Der Demonstrator ist auf Windows-Plattformen

ausgerichtet. Bisher wurde er unter Windows XP und Windows 7 erfolgreich getestet.

Wichtig ist, dass eine Spracheinstellung gewählt ist, in der Dezimalstellen entweder mit

. oder , abgetrennt werden (deutsche oder englische Standardeinstellungen). Um

die Begegnungspunktvorschläge in Google-Maps anzeigen zu können, muss der Computer

über eine Internetverbindung verfügen.

61


6. Voraussetzungen und Installation

6.3. Inbetriebnahme und Präsentationsvorbereitung

6.3.1. Datenbank einrichten

Bevor eine Präsentation mit dem Demonstrator vorgenommen werden kann, muss die

Datenbank eingerichtet werden. Hierfür werden WB und MS benötigt. Beide Tools sind

unter [MT11] kostenlos erhältlich. Tipps zur Einrichtung eines lokalen Servers nden

sich dort ebenfalls. Wenn der Server mit MS eingerichtet wurde, kann die Datenbank

für den Demonstrator mit der WB auf dem Server hinterlegt werden. Hierfür önet man

die Datei Datenmodell.mwb in der WB. Danach wird die Datenbank über das Menü

Forward Engineer (Database → Forward Engineer) aktiviert. Da die Aktivierungsumstände

immer auf den jeweiligen PC angepasst werden müssen, wird hierauf nicht näher

eingegangen.

6.3.2. Stammdaten im DBS hinterlegen

Ist die Datenbank aktiviert, kann diese mit den notwendigen Daten gefüllt werden.

Hierfür wird die Anwendung GUI-A.exe ausgeführt. Zu Beginn ist die in Abbildung 6.1

gezeigte Maske sichtbar. Bevor die Bearbeitung begonnen werden kann, muss das Tool

mit dem DBS verbunden werden.

Anmelden

Nach Bedienen des Button Datenbank verbinden erscheint das in Abbildung 6.2 gezeigte

Anmelde-Dialogfenster. Der Button Speichern hinterlegt die Anmeldedaten in einer

.txt-Datei im Hintergrund. Wurden die Anmeldedaten bei einer vorherigen Anmeldung

hinterlegt, werden diese beim Önen des Dialogfensters automatisch in die entsprechenden

Felder eingetragen. Sobald der Button Anmelden betätigt wird, wird das Tool mit

dem DBS verbunden. Sollte eine Verbindung nicht zustande kommen, erhält man eine

Fehlermeldung. Bei erfolgreichem Verbindungsaufbau erscheint ein Bestätigungsfenster

und der Anmeldedialog schlieÿt sich.

Stammdaten einlesen und hinterlegen

Wenn das GUI-A mit dem DBS verbunden ist, können die Stammdaten eingelesen werden.

Hierfür liest man die jeweiligen Listen in die Listboxen am linken Rand ein (jeweiliger

Button Einlesen). Die Listen nden sich im Ordner Grunddaten_DTM. Es gilt zu

beachten, dass die Daten hier nicht mehr editiert werden können. Erst wenn die Daten

eingelesen wurden, können die Listen im DBS hinterlegt werden. Hierbei ist es ratsam

auf die Reihenfolge zu achten, in der man die Datensätze hinterlegt, da die Relation

Partner von den anderen Relationen abhängig ist. Sollte man versuchen, die Datensätze

im DBS zu hinterlegen, bevor das GUI-A mit dem DBS verbunden ist, erhält man eine

Fehlermeldung. Ebenso erhält man eine Fehlermeldung, wenn ein Datensatz fehlerhaft

ist.

62


6.3. Inbetriebnahme

Abbildung 6.1.: GUI-A

Dynamische Tabellen füllen

Um nicht bei jeder Präsentation mühevoll entsprechende Datensätze von Hand im

DBS hinterlegen zu müssen, gibt es einige (mehr oder weniger gut funktionierende)

Möglichkeiten, diese Arbeit zu automatisieren.

Automatische Datensatzerstellung Im rechten Bereich des GUI-A sind die Möglichkeiten

die dynamischen Tabellen des DBS mit Datensäzen zu bestücken zu nden. Es

gibt hier einerseits die Möglichkeit eine zu bestimmende Anzahl an Datensätzen sofort

zu denieren und zu hinterlegen, oder in bestimmten Zeitintervallen immer einen neuen

Datensatz zu denieren und zu hinterlegen. Diese Funktionen sind jeweils auf die

Angabe der vorhandenen Datensätze in den einzelnen Tabellen angewiesen. Das heiÿt,

63


6. Voraussetzungen und Installation

Abbildung 6.2.: GUI-A Anmeldedialog

bevor diese Funktionen angewendet werden können muss die Funktion Füllstand prüfen

(Datenbank → Füllstand prüfen) ausgeführt werden. Da diese Funktionen zur Datensatzdenition

allerdings sehr einfache Zufallsalgorithmen verwenden, sind die hier erstellten

Datensätze leider oft unbrauchbar.

Vorgefertigte Datensätze Eine recht zuverlässige Möglichkeit, um sinnvolle Datensätze

im System zu hinterlegen, ist diese vorher zu denieren und dann einzulesen. Im

Ordner Demonstrator V1.1 nden sich die Dateien auftraege_1.txt, ladungen_1.txt

und fz_ausstattung_rueckfahrt_1.txt. In ihnen sind Datensätze für die jeweils gleichbenannten

Relationen des DBS enthalten. Diese können über den Menüpunkt Datenbank

→ füllen → Aufträge eingelesen werden. Sie werden am Namen identiziert und können

inhaltlich ersetzt werden. Jedoch ist hierbei darauf zu achten, dass in jeder Datei die

gleiche Anzahl an Datensätzen vorhanden sein muss.

Sobald alle benötigten oder gewünschten Datensätze hinterlegt sind, kann das GUI-

A geschlossen werden und Experimente können beginnen. Falls gewünscht kann es auch

im Hintergrund weiterlaufen. Alle Datensätze bleiben im DBS solange erhalten, bis sie

aktiv gelöscht werden. Auch ein Neustart des PCs ändert nichts an der Verfügbarkeit

der Daten. Somit kann der PC zu Hause auf ein öentliches Experiment vorbereitet und

dann mit den vorbereiteten Daten experimentiert werden.

64


7. Benutzung des Demonstrators

und Durchführung von

Experimenten

7.1. Menüführung

In Abbildung 7.1 sieht man eine schematische Darstellung der Maskenführung. Da der

Demonstrator über relativ wenige Optionen verfügt, gestaltet sich diese recht übersichtlich.

7.2. Anmeldung

Die Anmeldung zum GUI-P erfolgt analog zur Anmeldung zum GUI-A wie sie in Kapitel

6.3.2 auf Seite 62 beschrieben ist. Über die bis dahin bekannten Möglichkeiten hinaus,

hat man hier auch die Möglichkeit die Verbindung des GUI-P zur DBS zu unterbrechen

oder über einen Ping zu testen (vgl. Abbildung 7.2). Über den Menüpunkt Fahrtenverwaltung

(Aktionen → Fahrtenverwaltung) erhält man die Fahrtenverwaltungsmaske,

sollte man diese einmal zwischendurch geschlossen haben. Versucht man die Fahrtenverwaltung

aufzurufen, ohne dass eine Verbindung zur Datenbank besteht, erhält man eine

entsprechende Fehlermeldung.

7.3. Fahrtenverwaltung

Sobald die Fahrtenverwaltungsmaske angezeigt wird, kann man mit der Datensatzerfassung

beginnen. Es bleibt hierbei zu beachten, dass man erst eine Partner-Id (Textfeld

Partnernummer) angeben muss, bevor weitere Angaben gemacht werden können. Man

beachte auÿerdem, dass alle Registerkarten (Grundinformationen, Ladungsinfo und Ausstattung

Rückfahrt) ausgefüllt sein müssen, bevor eine Suche gestartet wird. Aus technischen

Gründen ist eine Suche ohne Hinterlegung des Datensatzes nur dann möglich,

wenn im Textfeld Auftragsnummer kein Eintrag vorhanden ist. Daher wird man fast

immer aufgefordert, den Datensatz zu hinterlegen, bevor eine Suche ausgeführt werden

kann. War eine Suche erfolgreich, so erhält man einen Hinweis und das Ergebnis wird in

der Registerkarte Grundinformationen im Feld mögliche Begegnungspartner angezeigt.

War die Suche nicht erfolgreich, so gibt es zwei mögliche Fehlermeldungen:

65


7. Benutzung des Demonstrators

Begrüßungsbildschirm / Anmeldemaske

Anmelden

Abmelden

Fahrtenverwaltung öffnen

Datenbank pingen

Verbindungsdaten speichern

Beenden

Fahrtenverwaltung

Datensatz eingeben

Alten Datensatz aufrufen

Datensatz hinterlegen

Partner suchen

Details zu möglichem Datensatz einsehen

Fahrtenverwaltung schließen

Alten Datensatz aufrufen

Details zu möglichem Partner anzeigen

Abfrage der ID

Detailansicht schließen

Partner ablehnen

Partner akzeptieren

Begegnungspunkt Berechnung

Begegnungspunkt anzeigen

Begegnungspunkt anzeigen

Google Maps verwenden

Abbildung 7.1.: Maskenführung des GUI-P

1. Es wurden in erster Instanz keine möglichen Partner gefunden bedeutet, dass im

DBS kein Datensatz existiert, der die in Kapitel 5.4.4 beschriebene grobe Filterung

passieren kann.

2. Es wurden in zweiter Instanz keine möglichen Partner gefunden bedeutet, dass

es im DBS zwar einen oder mehrere Datensätze gibt, die die grobe Filterung passieren

konnten, es von diesen aber keiner schat die in Kapitel 5.4.4 beschriebene

Feinauswahl zu durchdringen.

7.4. Detailansicht

War eine Suche erfolgreich, kann man erste Details zu einem möglichen Partner in der

Registerkarte Grundinformationen einsehen. Durch einen Doppelklick auf den Datensatz

önet sich die Detailansichtsmaske. Ebenso kann diese über den Menüpunkt ausgewählte

Fahrt anzeigen (Aktionen → ausgewählte Fahrt anzeigen) erreicht werden.

66


7.4. Detailansicht

Abbildung 7.2.: Verbindung kappen oder testen

7.4.1. Partner akzeptieren

Bevor ein Datensatz akzeptiert werden kann, müssen beide Datensätze hinterlegt sein.

Wenn ein Datensatz initial akzeptiert wurde, also der Partner noch nicht zugestimmt

hat, so werden automatisch alle anderen möglichen Partnerdatensätze abgelehnt und

aus der Registerkarte Grundinformationen gelöscht. Auch wird die Datensatzpaarung

im DBS hinterlegt, sodass der Partner später sehen kann, wer mit ihm gerne einen

Begegnungsverkehr durchführen würde. Wenn der Partner seinen Datensatz das nächste

Mal aufruft ist es ihm ausschlieÿlich möglich, diese Datensatzpaarung einzusehen. Ist

auch er mit dem Partner einverstanden, kann er den Datensatz endgültig bestätigen. Tut

er dies, werden beide Datensätze aus dem Demonstrator gelöscht. In späteren Systemen

würde man die Datensätze vielleicht zu Abrechnungszwecken aufheben, bzw. in einem

Datawarehouse ablegen.

67


7. Benutzung des Demonstrators

7.4.2. Partner ablehnen

Es ist egal ob ein Datensatz von vorne herein oder nach Anfrage eines möglichen Partners

abgelehnt wird. In beiden Fällen wird der Datensatz aus der Registerkarte Grundinformationen

gelöscht. Sollte eine Datensatzpaarung im DBS mit diesem Datensatz

hinterlegt sein, wird auch diese gelöscht. Beide Datensätze können (wieder) neu Partner

suchen.

7.4.3. Begegnungspunkt berechnen und anzeigen

Über den Button Begegnungspunkt wird ein Vorschlag für einen Begegnungspunkt berechnet.

Dieser Begegnungspunkt orientiert sich an den tangierten Orten und der jeweiligen

Restfahrzeit der beiden Fahrer (vgl. Kapitel 5.4.6). Er wird im Label Begegnungspunkt

in GK ausgegeben. Mit einem Klick auf das Label oder über den Menüpunkt

Anzeigen (Begegnungspunkt → Anzeigen) erhält man Zugang zu einem Webbrowser,

der ausschlieÿlich Google-Maps anzeigen kann. Er ist automatisch angewiesen, den Begegnungspunkt

zu markieren und anzuzeigen. Jedoch ist es auch möglich, die Touren der

Fahrzeuge in den Routennder von Google-Maps einzugeben und so den Begegnungsverkehr

auf einer Karte zu begutachten.

7.5. Entfernungsrechner

Der Entfernungsrechner ist ein Unterstützungswerkzeug. Er berechnet, ausgehend von

einer Liste mit Orten, an denen sich die Partnerunternehmen benden, diejenigen Orte,

die im gewünschten Umkreis um das jeweilige Depot liegen. Dieses Unterstützungsprogramm

wurde bereits in Kapitel 5.1.2 beschrieben.

7.6. Mögliche Paarungen

Auf dem Datenträger Matching Software benden sich bereits einige Datensätze, die

für eine Präsentation geeignet sind. Folgend ist in Tabelle 7.1 eine Liste der Datensätze,

die für bestimmte Demonstrationen besonders wertvoll sind, zu nden.

Demonstrationszweck

Datensatz-ID(s)

Datensätze ohne mögliche Partner 11, 12, 17, 19, 20, 24, 25, 27, 28,

32, 33, 37, 38, 47,

Datensätze mit einem möglichen Partner 0-4, 6-10, 13-16, 18, 21, 22, 26, 29-

31, 34, 35, 41, 42, 45, 46,

Datensätze mit mehreren möglichen Partnern 5, 23, 36, 39, 40, 43, 44,

Tabelle 7.1.: Datensätze mit besonderen Ausprägungen

68


Teil III.

Kritische Diskussion

69


8. Konzeptfehler

Im letzten Teil der Arbeit soll nun auf Fehler, die während der Erstellung des Konzeptes

und der Implementierung gemacht wurden, eingegangen werden. Gleichzeitig werden

Vorschläge unterbreitet, wie sich diese Probleme in Zukunft lösen lassen könnten.

8.1. Datenbank

8.1.1. Redundante Datenhaltung

Die Relationen Aufträge und Orte enthalten redundante Daten. Diese redundanten Daten

ermöglichen jedoch die Ausführung der Grobauswahl, des Matching-Algorithmus.

Dieses Vorgehen war, nach Stand der Technik, bereits bei der Planung veraltet. Eine

bessere (also redundanzlose) Lösung wäre es gewesen, hier sogenannte Views zu denieren.

Views sind virtuelle Relationen, die die Ergebnismenge einer Abfrage beinhalten.

Obwohl sie nicht Teil des physikalischen Datenbankschemas sind, kann man sie wie physikalische

Relationen verwenden. Die Verwendung solcher Views würde das DBS stabiler

und weniger speicherintensiv machen.

8.1.2. Fehlende Relation für Fehlermeldungen

In der gesamten Anwendung GUI-P werden auftretende Fehler immer mit Nummern

identiziert und an die Funktion Info übergeben. In dieser Funktion sind Klartexte zu

den Fehlercodes hinterlegt, die dann als Dialogfenster ausgegeben werden. Die Fehlermeldung

hart zu hinterlegen ist eine funktionale, aber im Alltagsbetrieb schlecht pegbare

Möglichkeit, mit Fehlermeldungen umzugehen. Ein kleines Beispiel: Sollte eine Fehlermeldung

bearbeitet werden müssen (z.B. wegen eines Rechtschreibfehlers) müsste, da der

Quelltext geändert wurde, danach der komplette Quelltext, mit allen Funktionen und

Prozeduren, einer kompletten Prüfung unterzogen werden, bevor die geänderte Version

des Programmes den Betrieb aufnehmen darf. Hinterlegt man die Texte für die Fehlermeldungen

jedoch in einer Datenbank, kann der geänderte Eintrag einzeln überprüft

werden. Eine Überprüfung des restlichen Programmes kann damit umgangen werden,

was auf lange Sicht sowohl Zeit als auch Geld sparen würde.

8.2. GUI-A - Automatische Datensatzerstellung

Die automatische Datensatzerstellung, die das GUI-A zur Verfügung stellt, erstellt Datensätze,

die für den Demonstrator unbrauchbar sind. Dies liegt daran, dass die Daten-

71


8. Konzeptfehler

satzerstellung zufällig zwei Orte als Start- bzw. Zielort bestimmt, ohne darauf zu achten,

ob diese Orte im Umkreis des, zufällig gewählten, eintragenden Partners sind. Aus der

Sicht des Algorithmus ist also die Kombination - Auftraggeber in Hamburg, Startort in

München, Zielort in Köln - möglich. Dies sollte allerdings nicht passieren. Der Startort

für einen Begegnungsverkehr sollte in der Nähe des Depots liegen. Um den Algorithmus

zu verbessern, müsste dieser erst ein Depot bestimmen, zu dem der Auftrag gehört und

dann anhand einer Liste mit Orten, die in der Nähe dieses Depots liegen, einen Startort

auswählen. Der Zielort würde analog bestimmt: Erst ein Depot auswählen mit dem eine

Partnerschaft möglich sein soll, dann anhand einer Liste der Orte im Umkreis, einen

Zielort auswählen. Die restlichen Eingaben dürften wieder rein zufällig geschehen.

72


9. Ausführungsfehler

9.1. Stabilität durch starre Stammdatenlisten

Wie in Kapitel 5.4.3 bereits erwähnt werden die Informationen aus den Comboboxen

über die Indizes der Einträge in der Datenbank gespeichert. Dies wurde schon während

der Erstellung des Systems als Hack bezeichnet und steht dieser Bezeichnung in keinem

Detail nach. Auch wenn sich hierdurch ein Vorteil in der Detailprüfung der Datensätze

ergibt, überwiegen doch die Nachteile. Durch diese Art und Weise die Informationen

abzuspeichern, wird das DBS und damit das ganze System des Demonstrators sehr instabil.

Dies zeigt sich dadurch, dass eine Erweiterung der Stammdatenlisten während

einer Präsentation nur möglich ist, indem man die neuen Daten an das Ende der Liste

stellt. Allerdings kann das System diese neuen Informationen nicht auswerten, d.h. eine

Erweiterung der Stammdatenlisten müsste durch eine Erweiterung der Auswertungsalgorithmen

begleitet werden. Dies ist wiederum auch im folgenden Verbesserungsvorschlag

der Fall.

Eine exiblere Möglichkeit die Daten zu speichern, wäre es, die Strings aus den Comboboxen

direkt in die Datenbank zu schreiben. Dies hätte zwar den Nachteil, dass man

in der Detailprüfung komplexere (oder besser längere) Algorithmen zur Auswertung benötigt,

jedoch würde die eigentliche Information nicht verschlüsselt in die Datenbank

geschrieben. Auch der zusätzliche Speicherplatzbedarf, der sich durch die Speicherung

ganzer Strings anstatt von Zahlen ergibt, steht einem groÿen Gewinn an Systemstabilität

gegenüber.

9.2. Ja-Nein-Vielleicht

Die Auswertung der Ja-Nein-Vielleicht-Angaben leiden in Version 1.0 unter einem

Denkfehler, der allerdings der Ausführung zuzuschreiben ist. In Tabelle 5.3 ist zu sehen,

dass Datensätze, die genau gegenteilige Angaben gemacht haben, vom System nicht als

Partner interpretiert werden. Dies ist richtig für den Fall, dass Partner 1 einen Kühltransport

durchführen will, Partner 2 solche Transporte aber nicht annehmen kann (oder

will). Partner 1 würde dann die Combobox für Kühltransporte in der Registerkarte Ladungen

auf Ja setzen, Partner 2 würde die Combobox für Kühltransporte auf der

RegisterkarteAusstattung Rückfahrt auf Nein setzen.

Im umgekehrten Fall, nämlich dass Partner 2 in der Registerkarte Ausstattung Rückfahrt

einen Kühltransport anbietet und Partner 1 jedoch für seine Ladung keinen Kühltransport

benötigt, ist eine Filterung durch das System falsch. Nur weil der angebotene

73


9. Ausführungsfehler

Kühltransport nicht benötigt wird, heiÿt das nicht, dass diese Partner keinen Begegnungsverkehr

durchführen können. Die zweite Zeile der Tabelle 5.3 muss also wegfallen. 1

9.3. Partnersuche ohne Hinterlegen des Datensatzes

Bevor eine Partnersuche durchgeführt wird, prüft der Algorithmus, ob der aktuelle Datensatz

bereits einen Partner (einseitig) bestätigt hat. Zum Abgleich mit der Relation

Auftraege_has_Auftraege wird die Datensatz-Id, die in der Maske im Feld Auftragsnummer

steht verwendet. Da es keine Funktion neuen Datensatz eingeben, die die Comboboxen

und Eingabefelder zurücksetzt, gibt und die Comboboxen und Eingabefelder auch

nicht zurückgesetzt werden, wenn eine Angaben geändert wird, bleibt die Datensatz- Id

des letzten angezeigten Datensatzes im entsprechenden Feld vorhanden. Ob eine Suche

ausgeführt wird, ist also davon abhängig, ob der letzte aufgerufene Datensatz bereits

einen Partner gefunden hat oder nicht. Darüber hinaus besteht die Gefahr, dass eine

mögliche Partnerschaft mit der falsch angezeigten Datensatz-Id hinterlegt wird, da der

tatsächlich aktuell angezeigte Datensatz eigentlich gar keine Id hat. Dieser Umstand

ist für den Demonstrator gerade noch haltbar, kann aber selbst hier (z.B. in einer Präsentation)

durchaus zu Verwirrungen führen. Daher muss hier in einer kommerziellen

Implementierung ein Sicherheitsmechanismus vorgesehen werden.

9.4. GUI-P - Gestaltung fehlende Übersichtlichkeit

Das GUI-P leidet unter einer mäÿigen Übersichtlichkeit. Zwar ist die in Kapitel 3.2.2

geforderte Übersichtlichkeit gegeben, jedoch sollte diese für ein kommierzelles System

genauso wie die Benutzerfreundlichkeit verbessert werden. Auch sollte die Maskengestaltung

und die Programmführung nochmals überarbeitet werden.

1 Dieser Fehler wurde in Version 1.1 ausgebessert.

74


10. Zusammenfassung und Ausblick

Der Demonstrator zur Partnersuche erfüllt die grundsätzlichen Anforderungen und erreicht

das gegebene Ziel: Eine Filterung von vielen vorhandenen Datensätzen um eine

Liste mit möglichen Begegnungspartnern zu erstellen. Er ist der Beweis, dass eine automatisierte

Partnersuche für Begegnungsverkehre prinzipiell möglich ist. Eine Umsetzung

des Demonstrators wäre jedoch ohne die Erfahrungen, die im DTM-Projekt gemacht

wurden, nahezu unmöglich gewesen, da hier Know-How der Transportbranche und abstrakte

Denkweisen zusammenieÿen. Auch zeigt die Implementierung des Systems, dass

die Anforderungen an den Disponenten (Einarbeitung in das System und zeitlicher Aufwand

für die Eingabe der Datensätze) relativ gering gehalten werden können. Einer

kommerziellen Entwicklung eines solchen Systems steht also nichts mehr im Wege. Jedoch

sollten bei einer kommerziellen Entwicklung eines solchen Dienstes weiterhin die

Grundvoraussetzungen zum Gelingen desselben nicht auÿer Acht gelassen werden. Ein

solches Suchsystem alleine ist, wie bei den heute bekannten Frachtenbörsen ersichtlich,

wertlos. Erst die Benutzung des Systems durch möglichst viele Anwender macht das

System lebendig. Je mehr Anwender dieselbe Suchplattform verwenden, um so wahrscheinlicher

ist es auch, dass hierdurch Partnerschaften entstehen.

Darüber hinaus ist ein Begegnungsverkehr, gerade wenn er nicht langfristig geplant

abläuft, eine sehr dynamische (und eventuell instabile) Angelegenheit. Daher sollte immer

eine einheitliche Kommunikationsplattform gefunden werden, zu der beide Parteien

Zugang haben. Der DTM-Prozess- und Informationsstandard, der in diesen Tagen fertig

gestellt wird, bietet für genau diesen Zweck eine Kommunikationsplattform. Dieser sollte

natürlich auch Eingang in eine kommerzielle Entwicklung eines Partnersuchsystems

nden.

Zuletzt liegen aber auch noch gröÿere Herausforderungen vor einer kommerziellen Entwicklung.

So ist zum Beispiel die Berechnung eines Begegnungspunktes noch alles andere

als ausgereift. Wie in Kapitel 5.4.6 bereits erwähnt, orientiert sich der Algorithmus ausschlieÿlich

an Luftlinienentfernungen und dem Verhätlnis der Restfahrzeiten der Fahrer.

Dies ist jedoch nur der erste Schritt auf dem Weg zu einem sinnvollen Begegnungspunkt.

Um zu verhindern, dass ein Begegnungsverkehr in Müllers Scheune stattnden

soll, ist eine Denition von Points of Interest (POI) unumgänglich. Diese müssten dann

als mögliche Begegnungspunkte abgeprüft werden. Die hierbei entstehenden Probleme

und Risiken sind vielfältig und komplex; jedoch ist es unwahrscheinlich, dass sie nicht

lösbar sind.

Noch während der Laufzeit des DTM-Projektes haben verschiedene Firmen des projektbegleitenden

Ausschusses Interesse an einer Weiterentwicklung des Matching-Algorithmus,

sowie einem Einsatz des DTM-Prozess- und Informationsstandards bekundet.

Die Räder rollen also weiter und man darf gespannt sein, wie die Ergebnisse des DTM-

75


10. Zusammenfassung und Ausblick

Projektes in Zukunft Verwendung nden.

76


Anhang A.

Datenträger Programmcode

Hier sollte eine CD sein!

Auf diesem Datenträger benden sich die Quelltextdateien der Komponenten des Matching-Software-Paketes

zu den Versionen 1.0 und 1.1. Sollte TD nicht zur Verfügung

stehen, können die jeweiligen Quelltextdateien (.pas-Dateien) mit dem Text-Editor geönet

werden. Man beachte hierbei, dass alle relevanten Dateien mit Unit* benannt

sind.

77


Anhang A. Datenträger Programmcode

Die auf diesem Datenträger enthaltenen Quelltexte sind urheberrechtlich geschützt.

Eine Verwendung derselben ist der Hochschule Ulm vorbehalten. Diese kann auf Anfrage

dritten die Verwendung der Quelltexte genehmigen. Sollten Sie Interesse an einer solchen

Genehmigung haben, kontaktieren Sie bitte Herrn Professor Dr.-Ing. Baumgärtel unter

baumgaertel@hs-ulm.de

78


Anhang B.

Datenträger Matching-Software

Hier sollte eine CD sein!

Auf diesem Datenträger benden sich die Komponenten des Matching-Software-Paketes

in der Version 1.1 sowie die Präsentation über das DTM-Projekt für die Transport

Logistics am 10.05.2011 in München. Um das DBS in Betrieb nehmen zu können, werden

MS und WB benötigt (vgl. Kapitel 6.3).

79


Literatur

[Bau11]

Prof. Dr.-Ing. Hartwig Baumgärtel. Studienbrief - Supply Network Management

- Publikation in Vorbereitung. AKAD-Verlag Stuttgart, 2011.

[DT11] DTM-Team. Projekt Dynamic Truck Meeting. Dynamic Truck Meeting. 2011.

url: Dynamic-Truck-Meeting.org.

[DTT11]

[Gef11]

[Gmb11]

[Kög11]

[Kön10]

[MT11]

[Mac11]

[Nic03]

[ver11]

Delphi-Tre-Team. delphi-tre.de. 2011. url: delphi-treff.de.

Redaktion Gefahrgut. WEKA - Praxislösungen, Gefahrgutrecht Straÿe/ Schiene

ADR/RID2011 + Nationale Vorschriften. WEKA Media GmbH & Co.

KG, 2011.

23karat GmbH. luftlinie.org. 2011. url: luftlinie.org.

Kögel. EuroTrailer. 2011. url: www.koegel-trailer.com/de/produkte/sp

editionsgewerbe/koegel-euro-trailer.html.

Frank König. Die Region Ulm spielt eine Vorreiterrolle bei der Kooperation

Wirtschaft/Wissenschaft. In: Südwest Presse (2010). url: http : / / www .

swp . de / ulm / lokales / ulm _ neu _ ulm / Wissenschaftsstadt - staerkt -

Region;art4329,546557.

MySQL-Team. www.mysql.de/downloads. 2011. url: www.mysql.de/downlo

ads.

Martin Mack. Konzeption und prototypische Implementierung eines Tools

zum Auftragsmatching für dynamischen Begegnungsverkehr. Magisterarb.

Hochschule Ulm, 2011.

Cristian Nicola. mysql direct library. 2003. url: delphi-treff.de/tutoria

ls/datenbanken/mysql-direct/einleitung/.

verschiedene. wikipedia.org/wiki/Deutschland. 2011. url: wikipedia.org/w

iki/Deutschland#Physische_Geographie.

81

Weitere Magazine dieses Users
Ähnliche Magazine