Wir hatten die Möglichkeit, die On-Board Unit mit der Software näher unter die Lupe zu nehmen. Was wir dabei herausfanden und wie sich die Unit bewährte, lesen Sie hier in unserem Praxistest.
Ein Reservierungssystem? Gibt es das nicht schon? RESI oder Yebu, wohl die bekanntesten Vertreter für Vereine und Flugschulen, gibt es seit geraumer Zeit. Charterware von Otmar Ripp bietet genau wie die Konkurrenten eine graphische Benutzeroberfläche zur Reservierung von Flugzeugen. Wie ich es von den anderen Systemen gewohnt bin, logge ich mich mit Benutzername und Passwort in das System ein. Ein weiterer Bestandteil dieses Systems ist die „On Board Unit“ (OBU). Mit einem 80mm Normgehäuse passt sie in die Ausschnitte vieler Panels. So wirkt das Gerät nicht als Zusatz sondern als Teil des Cockpits – für viele ein wichtiges Kriterium.
Die 80mm-On Board Unit (OBU) von charterware wird entweder in das Cockpit-Panel eingebaut, oder für temporären Betrieb wie für unseren Testbericht mittels Klett befestigt und an der 12 Volt-Steckdose angeschlossen.
Wer als Pilot, das heißt als Kunde zuhause übers Festnetz, unterwegs per Handy oder PDA sich einloggt, hat nur Zugriff auf zwei Bedienkommandos: Anfrage und Storno. Man kann sich dann entweder eine Liste freier Flugzeuge in einem Zeitraum geben lassen oder man lässt sich den Belegungskalender eines Wunschflugzeuges zeigen. Mit ein paar weiteren Klicks hat man eine Buchungsanfrage gestartet, welche je nach Kundenstatus automatisch vom System oder vom Personal bestätigt wird. Loggt man sich als Unternehmenspersonal (Flugschule, Vercharterer, Verein oder Haltergemeinschaft)in das System ein, erhält man eine ganze Reihe zusätzliche Möglichkeiten. Man kann für anrufende Kunden/Piloten Buchungen vornehmen, Anfragen bestätigen oder ablehnen, Flugzeuge und Kunden administrieren, manuell Flugbucheinträge durchführen und natürlich die Abrechnungen auf Knopfdruck erzeugen und Letzteres ist genau das, was die Administration für den Anbieter so sehr erleichtert. Auf dem Bildschirm sieht es bei den Flugschulen aus wie auf einer Anzeigetafel am Airport mit künftig erwarteten Flugbewegungen. Nach der Buchung für unseren Testflug sah es wie folgt aus :
Wie man aus diesen zwei Buchungen über charterware erkennen kann, hatte ich mit Otmar Ripp am 15.01.08 um 09:00 bis 11:00 Uhr in Bad Endorf den Testflug vereinbart, obere Zeile, sowie einen weiteren Flug von 11:00 bis 12:00, untere Zeile.
Für unseren Test haben wir die OBU mit Klettband auf dem Cockpit befestigt, haben Plus / Minus an die 12 V Bordnetzversorgung angebracht – das war’s (siehe Abbildung 2). Man benötigt keine Verbindung zu anderen Flugzeugsensoren oder GPS. Die OBU ist ein autarkes, einfach zu installierendes Gehäuse mit integriertem GPS-Empfänger. Die Antennen am Gehäuse sind für den GPSEmpfänger und für den persönlichen Transponder-Chip.
Die erste OBU fliegt versuchsweise seit Weihnachten 2007 in Trier bei www.drive-and-fly.de in einer Remos G3 und liefert die Daten an den Server ab. Grund genug für uns, das neue System einem Praxistest zu unterziehen. Otmar Ripp, Erfinder der Lösung und Gründer von charterware.net war bereit, uns in die Technik einzuweisen und mit einem Testprogramm mit diversen Flügen Einblick zu verschaffen. Als virtuelle Flugschule wurde uns mit der D-MRLR ein Konto als Direktkunde auf dem Server eingerichtet.
Ein ID-Chip zur Identifikation, den später jeder Charterkunde ausgehändigt bekommt, war bei dem Demonstrator mit dabei. Der Transponder-Chip in Größe eines 50 Centstücks ermöglicht das berührungslose Einloggen mit den persönlichen Daten an die OBU. Unser Testfl ug sollte mit möglichst vielen Herausforderungen an charterware durchgeführt werden. So planten wir einen Dreiecksflug von Bad Endorf mit Zwischenlandung in Landshut (beide bekannte Plätze in der Datenbank), dann weiter nach Mühldorf, wobei Mühldorf bewusst aus der Flugplatzdatenbank gelöscht wurde, um zu erfahren, wie charterware in so einem Fall reagiert.
Zwischendrin war noch ein Stall exakt über dem Platz in Landshut geplant, um dem System eine Landung vorzutäuschen. Nun, wie so oft in der Fliegerei, kam es wetterbedingt etwas anders; nach der kontaktlosen Piloten Identifi zierung mit Otmars ID-Chip und dem Start in Bad Endorf bei bestem Wetter, lag im Norden dichter Nebel, den wir im Westen nahe der Kontrollzone des Münchner Flughafens umflogen. Die Isar sorgte durch Konvektionswärme für eine nebelfreie Einfl ugschneise und für das „Loch vom Dienst“ am Flugplatz Landshut Ellermühle.
Nach der Landung in EDML: Hauptschalter aus (dies ist der Befehl für die Übertragung der Daten per GSM). Taxi-Start, Taxi-Stopp, sowie Start- und LandezZeiten, Koordinaten, Piloten-ID sowie Flugzeugkennung liegen kurze Zeit später auf dem Server von charterware.net. Die OBU bedient sich eines eigenen Akkus nachdem der Hauptschalter ausgeschaltet wurde, um der Handyverordnung zu genügen und auch keine Avionik des Flugzeuges zu stören. So wird die Mobilfunkfunktionalität erst bei stillgelegtem Flugzeug aktiv. „TX (transmission) erfolgreich“ meldete das OBU-Display und ein Kontrollanruf per Handy in München bei den charterware-Programmierern bestätigte dies auch.
10:55 Uhr, Mühldorf liegt immer noch im dichtesten Nebel - Flugplanänderung. Allerdings sollte Mühldorf eigentlich unser „unbekannter Platz“ Test sein. Einen Test auslassen wollten wir keinesfalls. Deshalb bat Otmar die Programmierer den Platz EDPC Bad Endorf aus der Serverdatenbank vorübergehend zu entfernen, welchen wir dann als unseren „unbekannten Platz“ verwendeten. Otmar Ripp erklärte, dass keine dezentralen Updates im Flugzeug nötig sind, die OBU verlangt von den Flugschulen keinerlei Datenwartung. Nach Zahlung der Landegebühr machten wir uns an den Rückfl ug nach Bad Endorf, dem jetzt im System von charterware „unbekannten EDPC“. Nach dem Take off meldeten wir Landshut Info noch eine Stallübung über dem Platz. Die OBU quittierte mit der Anzeige Taxiing, sobald wir 65 km/h im UL unterschritten. Die jeweilige Stallspeed zur Start- und Landeerkennung muss bei einem Umbau in ein anderes Muster nicht justiert werden, erklärt Otmar. Diesen Wert richtet die Flugschule bzw. der Vercharterer bei den Flugzeugstammdaten auf dem Server ein.
Außer einem Akkutausch alle zwei Jahre braucht man an der OBU nichts zu warten. Das System sollte unseren Stall wegen unserer Sicherheitshöhe von mehr als 1000 ft GND über EDML erkennen und im Protokoll unterdrücken statt als Landung zu werten. Wir würden sehen. Zurück nach EDPC unterwegs noch eine weitere Stallübung und Abschlusslandung auf der Piste 35. Wir sind gespannt, ob uns das System all die Daten auf den Server richtig übertragen hat. Würden wir ohne auch nur eine einzige Zeit notiert zu haben, ohne Flugbücher zu wälzen, ohne Eintragungen zu überprüfen, ohne manuelle Zeiteingaben in den Computer auf Knopfdruck die Monatsabrechnung erzeugen können? Wir loggen uns als Flugschule ins System ein.
