Erfahrungen mit dem System TROSS beim DRK Part 1

Seite 24 Seite

Textversion

Grafikversion

Übersicht

<=<=
<=<=
<=<=
<=<=
<=
<=
<= <=
<=

<=
<= <=
<=

<=
<= <=
<= <=
<=

<=
<=

<=
<= <=
<=

<=
<=
<=
<=

<=
<=

Universität Stuttgart

Fakultät Informatik

Institut für Informatik

Breitwiesenstraße 20-22

D-70565 Stuttgart

Erfahrungen mit dem

System TROSS beim

DRK

Friedhelm Buchholz, Frank Wagner

Report Nr. 2000/01

24. Januar 2000

Seite 24 Seite Textversion Grafikversion Übersicht

Seite 1 Seite Textversion Grafikversion Übersicht

Die Projektgruppe Transportoptimierung hat in einem Jahr (WS 97/98, SS 98) das System \Transportorganisation für soziale Serviceanbieter" (TROSS) zur Disposition für die Fahrdienste des Deutschen Roten Kreuzes (DRK) Stuttgart erstellt. In den Berichten [3] und [4] wird TROSS im Detail vorgestellt. Weil keine Wartung gewährleistet werden kann und das System auch noch einige Fehler hat, wird TROSS vom DRK nicht bei der täglichen Disposition benutzt. Trotzdem ist das Interesse vom DRK an einer computerunterstützten Planung und Optimierung bei der Organisation der Fahrdienste sehr groß. Aus diesem Grund hat man sich dort intensiv mit TROSS beschäftigt. Die dabei gesammelten Erfahrungen und daraufhin durchgeführten Korrekturen an TROSS werden in diesem Bericht zusammengefasst. Am Ende des Berichts werden dann mögliche Erweiterungen des Systems vorgestellt.

Seite 1 Seite Textversion Grafikversion Übersicht

Seite 2 Seite Textversion Grafikversion Übersicht

1 Geplante Benutzung von TROSS

TROSS ist ein Programm zur Verwaltung und Kontrolle der (planungsrelevanten) Daten der Abteilung Mobile Dienste beim DRK Stuttgart. Unterstützt werden folgende Dienste: Schulfahrdienst, Behindertenfahrdienst, Altenpflege und Essen auf Rädern.

Bevor man richtig mit TROSS arbeiten und seine Touren planen kann, müssen zunächst die zur Verfügung stehenden Ressourcen (Mitarbeiter und Fahrzeuge) eingegeben werden.

Abbildung 1: Maske mit den planungsrelevanten Daten eines Mitarbeiters

Die Maske für die Eingabe von Mitarbeiterdaten besteht aus zwei Teilen. Der erst Teil enthält die eindeutige Mitarbeiternummer und den Namen des Mitarbeiters sowie dessen Adressen und Telefonnummern.

Der zweite Teil (Abb. 1) enthält Randbedingungen für die Planung. Dienstantrittsdatum und das Datum des Ausscheidens sind Grenzen für die Verfügbarkeit. Das Arbeitszeitprofil gibt den Spielraum für die Einsatzzeiten des Mitarbeiters an. Die Profile können in TROSS definiert werden. Dabei gibt es drei Typen:

1. das Vollzeitprofil: hier wird die wöchentliche und die maximale tägliche Arbeitszeit festgelegt. Zivildienstleistende arbeiten zum Beispiel 35 Stunden pro Woche und maximal 10 Stunden am Tag.

2. Teilzeit tageweise: hier wird für jeden Tag festgelegt, wann der Mitarbeiter

Seite 2 Seite Textversion Grafikversion Übersicht

Seite 3 Seite Textversion Grafikversion Übersicht

einsetzbar ist. Diese Profile sind für Mitarbeiter gedacht, die nebenberuflich beim DRK arbeiten (630 Mark Jobs). Bei diesem Typ hat in der Regel jeder Mitarbeiter sein eigenes Profil.

3. Teilzeit wochenweise: Hier wird eine monatliche Arbeitszeit und eine maximale tägliche Arbeitszeit festgelegt.

Im Rahmen Verfügbarkeit werden die Tage festgelegt, an denen der Mitarbeiter verfügbar ist. Der Zeitrahmen gibt den Beschäftigungszeitraum an. Ausnahmen sind z.B. Ferien und Schulungen.

Die Qualifikationen können frei definiert werden. Gedacht sind sie zum Beispiel für \Lasten heben" oder \Spritze setzen". Die Qualifikationen können von den Kunden gefordert werden, was dann bei der Planung berücksichtigt wird. Der TROSS-Benutzer kann daraus resultierende Konsistenzverletzungen aber auch einfach akzeptieren.

Die Maske für Fahrzeugdaten ist auf zwei Seiten verteilt. Die erste Seite (Abb. 2) enthält zunächst die KFZ-Nummer und eine eindeutige Bezeichnung für das Fahrzeug. Die \technischen Termine" prüft TROSS beim Starten und informiert den Benutzer gegebenenfalls über demnächst fällige TÜV- und ASU- Termine. Die Verfügbarkeit wird wie bei den Mitarbeitern festgelegt.

Die zweite Seite beschreibt die Ausstattung des Fahrzeuges. Im oberen Teil können bewegliche Hilfsmittel und deren Anzahl festgelegt werden, die im Fahrzeug mitgenommen werden sollen. Der untere Teil gibt die nicht so leicht veränderbare Ausstattung an. Zunächst können zu jedem Fahrzeugtyp verschiedene Konfigurationen definiert werden, von denen dann eine für das Fahrzeug ausgewählt wird. Das Fahrzeug in der Abbildung hat gegenwärtig drei normale Sitzplätze, keine festen Sitzhilfen und drei Plätze für Rollstuhlfahrer.

Die Eingabe von Kundendaten gliedert sich in drei Teile: persönliche Daten, dienstbezogene Daten und Dienstwünsche. Die persönlichen Daten (Abb. 3) enthalten unter anderem die maximale Fahrdauer pro Fahrt und die Heimadresse, die als Vorgabe für den Startort von Dienstwünschen verwendet wird.

Die Abneigungen und Zuneigungen der dienstbezogenen Daten (Abb. 4) beeinflussen die Auswahl der Mitarbeiter; Hilfsmittel und zulässige Fahrzeuge schränken die Wahl des Fahrzeugs ein. Die Bezugspersonen dagegen sind mehr informativ. Bezugspersonen sind z.B. der Hausarzt oder auch Verwandte. Sie können auf dem Tourplan als Information für die Fahrer ausgedruckt werden.

Im dritten Teil werden die Dienstwünsche des Kunden aufgelistet. Hier können Dienstwünsche eingefügt, geändert oder gelöscht werden. Ein Beispiel für einen Dienstwunschdialog ist in Abbildung 9 zu sehen.

Nach der Eingabe der Dienstwünsche können diese zu Touren gruppiert werden. In einem Tour-Dialog (Abb. 5) wird zunächst eine Nummer und eine Bezeichnung für die Tour vergeben. Mit dem nächsten Feld kann die Tour für folgende Optimierungen gesperrt werden. Als nächstes werden dann die Mitarbeiter, die die Tour fahren sollen, und das entsprechende Fahrzeug gewählt. Im mittleren Teil der Maske werden die Dienstwünsche ausgewählt, von denen dann im unteren Teil noch einige zusammengefasste Daten angezeigt werden.

Die Touren sind nur Mengen von Dienstwünschen, die Reihenfolge der Stationen und die Zeiten werden in Untertouren festgelegt. Hin- und Rückfahrten einer Tour sind somit zwei Untertouren. Abbildung 6 zeigt einen Dialog zur Eingabe von Untertouren. Die Anfangs- und Endstationen können z.B. für eine

Seite 3 Seite Textversion Grafikversion Übersicht

Seite 4 Seite Textversion Grafikversion Übersicht

Abbildung 2: Eingabemasken für die Daten zu einem Fahrzeug: Bezeichnungen, Termine, Hilfsmittel, Fahrzeugtyp und Konfiguration

Seite 4 Seite Textversion Grafikversion Übersicht

Seite 5 Seite Textversion Grafikversion Übersicht

Abbildung 3: Kundendaten: persönliche Daten

tourübergreifende Planung der Fahrzeuge verwendet werden. Der untere Teil des Dialogs gibt die anzufahrenden Stationen mit den jeweiligen Zeiten an. Hier können dann auch Stationen vertauscht oder Zeiten geändert werden.

Damit sind dann alle Eingaben beendet. Der TROSS-Benutzer kann nun Einsatzpläne ausdrucken (Abb. 8) oder Analysen vornehmen (Abb. 10, 11), um seine Planung zu optimieren.

2 Bisherige Verwendung beim DRK

Ein DRK-Mitarbeiter hat damit angefangen, Stammdaten (Fahrzeuge, Mitarbeiter und Kunden) in das System einzugegeben. Es wurden leider nicht die von der Projektgruppe angelegten \Testdaten" verwendet. Diese Daten dienten der Projektgruppe zwar auch zum Testen, sie enthielten jedoch reale Daten vom DRK mit allen Mitarbeitern und Fahrzeugen sowie den Schultouren mit ihren

Seite 5 Seite Textversion Grafikversion Übersicht

Seite 6 Seite Textversion Grafikversion Übersicht

Abbildung 4: Kundendaten: Dienstbezogene Daten

Kindern.

Tabelle 1 listet die getätigten Eingaben auf, wobei nicht immer klar zwischen den eingegebenen Daten und den zu spät doch noch eingefügten Testdaten unterschieden werden konnte. Insbesondere wurden nur bei fünf Kunden Dienstwünsche eingegeben, wobei jeweils der Rhythmus fehlte, der die Zeiten festlegt (in Abb. 9 ganz unten). Von den eingegebenen Touren hatte nur die erste Tour eine Menge von Dienstwünschen, bei den anderen Touren waren nur der Name, die beteiligten Mitarbeiter und ein entsprechendes Fahrzeug vergeben.

Nach schätzungsweise mindestens fünf Stunden wurden die Versuche wegen den im folgenden Abschnitt beschriebenen Fehlern und Systemabstürzen abgebrochen, ohne dass eine Tour vollständig mit ihren Untertouren eingegeben wurde. Die Unterstützung der ersten Schritte bei der Verwendung des Systems ist anscheinend zu gering. Eine Benutzereinführung für TROSS wäre hier sinnvoll gewesen.

Seite 6 Seite Textversion Grafikversion Übersicht

Seite 7 Seite Textversion Grafikversion Übersicht

Abbildung 5: Eine Tour

Seite 7 Seite Textversion Grafikversion Übersicht

Seite 8 Seite Textversion Grafikversion Übersicht

Abbildung 6: Eine Untertour

Das Verkehrstool Map&Guide, das zur Ermittlung der Fahrzeiten verwendet wird, ist nicht installiert. Da noch keine Untertouren eingegeben wurden, wurden Fahrzeiten von TROSS auch noch nicht benötigt.

3 Fehlerbeseitigung

3.1 Doppelte Einträge in den Listen

Wie in Abbildung 7 zu sehen ist, traten Einträge mehrfach auf. Der Grund dafür ist der Menüpunkt Testdaten aufnehmen, der in der Endversion von TROSS nicht enthalten sein sollte. Der Fehler wurde durch Beseitigung der doppelten Einträge und die Entfernung des Menüpunktes behoben.

3.2 Fahrzeuge ohne korrekte Nummer

In der Fahrzeugliste waren drei Fahrzeuge enthalten, deren Fahrzeugnummern leer waren (die Lücke oben in der Liste in Abbildung 7). Es stellte sich heraus, dass Aufrufe von Methoden der Klasse TRO.Konsistenztests.FahrzeugPruefer konsequent vergessen wurden. An ihrer Stelle standen nur Kommentare, die auf die offenen Arbeiten hinwiesen. Die Aufrufe wurden eingefügt und in der Folge aufgetretene kleinere Fehler an diesem Konsistenzprüfer wurden beseitigt.

Seite 8 Seite Textversion Grafikversion Übersicht

Seite 9 Seite Textversion Grafikversion Übersicht

Datentyp Anzahl
Fahrzeugtypen 15
Fahrzeuge 55
Hilfmittel 7
Essensarten 17
Qualifikationen 0
Kunden 50
Dienstwünsche 5
Touren 43
Untertouren 0

Tabelle 1: Anzahl der eingegebenen Daten je Datentyp

Abbildung 7: Die fehlerhafte Fahrzeugliste: ganz oben drei Fahrzeuge ohne Nummern gefolgt von mehreren doppelten Fahrzeugnummern

3.3 Löschen von Fahrzeugen funktioniert nicht

Der DRK-Mitarbeiter versuchte die Fahrzeuge mit den leeren Nummern zu löschen. Dies klappte zwar zunächst in der angezeigten Liste, jedoch waren die gelöschten Fahrzeuge nach einem erneuten Aufruf der Fahrzeugliste wieder da.

Der Grund für dieses Verhalten ist eine doppelte Speicherung: Java verwendet für die Anzeige eine eigene Liste, die unabhängig von den TROSS-Daten verwaltet wird (es wurden die AWT-GUI-Klassen und nicht Swing verwendet, da es Swing damals noch nicht gab). Die erste Vermutung war daher, dass der Löschaufruf für die Daten vergessen wurde. Die Methode für das Löschen wurde aber durchaus an den betroffenen Stellen im Programm aufgerufen.

Um das Problem zu erklären, zunächst ein kurzer Einblick in die Datenhaltung: In der Klasse TRO.Szenario werden alle Daten sortiert nach ihrem Listentext gespeichert (bei Fahrzeugen ist das z.B. die Fahrzeugnummer). Wird nun in einem Dialog der Listentext verändert, ändert sich somit auch der Sortierschlüssel. Jedoch wurde diese Tatsache übersehen und die Daten wurden

Seite 9 Seite Textversion Grafikversion Übersicht