DE60218090T2 - Elektronisches Wartungsverzeichnis und Wartungssystem für ein Luftfahrzeug - Google Patents

Elektronisches Wartungsverzeichnis und Wartungssystem für ein Luftfahrzeug Download PDF

Info

Publication number
DE60218090T2
DE60218090T2 DE60218090T DE60218090T DE60218090T2 DE 60218090 T2 DE60218090 T2 DE 60218090T2 DE 60218090 T DE60218090 T DE 60218090T DE 60218090 T DE60218090 T DE 60218090T DE 60218090 T2 DE60218090 T2 DE 60218090T2
Authority
DE
Germany
Prior art keywords
data
user
flight
storage unit
aircraft
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60218090T
Other languages
English (en)
Other versions
DE60218090D1 (de
Inventor
Stephen Terenure Hardgrave
Jonathan Killaloe Brennan
Bernard Malahide Hensey
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Flightman Research Ltd Malahide
Flightman Res Ltd
Original Assignee
Flightman Research Ltd Malahide
Flightman Res Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Flightman Research Ltd Malahide, Flightman Res Ltd filed Critical Flightman Research Ltd Malahide
Publication of DE60218090D1 publication Critical patent/DE60218090D1/de
Application granted granted Critical
Publication of DE60218090T2 publication Critical patent/DE60218090T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B7/00—Radio transmission systems, i.e. using radiation field
    • H04B7/14—Relay systems
    • H04B7/15—Active relay systems
    • H04B7/185—Space-based or airborne stations; Stations for satellite systems
    • H04B7/18502—Airborne stations
    • H04B7/18506—Communications with or from aircraft, i.e. aeronautical mobile service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/105—Multiple levels of security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Aviation & Aerospace Engineering (AREA)
  • Astronomy & Astrophysics (AREA)
  • Physics & Mathematics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Debugging And Monitoring (AREA)
  • Radio Transmission System (AREA)

Description

  • Gebiet der Erfindung
  • Diese Erfindung betrifft den Bereich der Nutzung und Wartung von Flugzeugen, insbesondere den Nutzen von technischen Logbüchern und/oder Flugbetriebsinformationen. Außerdem betrifft es den Nutzen von Informationen für die Flugbesatzung zur Durchführung eines Flugs und/oder die Instandhaltung und/oder gesammelte Daten über das Flugpersonal für ein Flugzeug und/oder die Fluggesellschaften.
  • Hintergrund der Erfindung
  • Es wird geschätzt, dass kommerzielle Fluggesellschaften weltweit knapp 400 Milliarden US-Dollar für Betriebskosten ausgeben. Es gibt eindeutige ökonomische Gründe für Fluggesellschaften, die an operationaler Effizienz interessiert sind, diese Kosten für Flottenwartung, Lagerhaltungskosten, Kraftstoffverbrauch, Personalkosten, Flughafengebühren und andere Kosten möglichst zu minimieren, und das Potenzial von jeglichen Möglichkeiten, die die gesamten Operationskosten senken könnten, voll auszuschöpfen.
  • Es gibt vier Interessengruppen in der Luftfahrtindustrie:
    Fluggesellschaften. Diese Gruppe beinhaltet kommerzielle Personenbeförderungsgesellschaften, ein Sektor, der in zwei große Kategorien unterteilt werden kann: Vollservice-Fluggesellschaften und auf spezielle Services zugeschnittene Anbieter (wie zum Beispiel Billigflieger oder konzerninterne Reisespezialisten). Die beiden anderen großen Bereiche der Fluggesellschaf ten umfassen Frachtflieger und nationale Luftverteidigungs- und Aufklärungskräfte.
  • Erstausrüster (OEM). Hier gibt es vier Hauptkategorien von OEMs: Flugzeugrümpfe (hauptsächlich Boeing und Airbus); Motoren (hauptsächlich GE, Pratt & Whitney und Rolls Royce); Luftfahrtselektronik (z.B. Honeywell, Raytheon, Rockwell, Collins, etc.); Komponenten (z.B. Allied Signal, Hamilton Sundstrand, BF Goodrich, etc.).
  • Wartungs-, Reparatur- und Überholungsdienstleister (MRO). Hier gibt es zwei Hauptkategorien von MRO-Firmen: Unabhängige Firmen wie die FLS Aerospace, die MRO-Dienstleistungen für Fluggesellschaften anbietet, bei der aber die Fluggesellschaften keinerlei Anteile an der MRO-Firma halten, sowie Tochterunternehmen, bei dem der Hauptkunde die MRO-Firma besitzt (z.B. Lufthansa Technik). Man kann den MRO-Bereich auch anhand der verschiedenen Angebote kategorisieren. Viele der großen MRO-Firmen versuchen ein leicht verständliches Servicepaket anzubieten, so dass eine Fluggesellschaft die gesamte Verantwortung der Wartung an die MRO-Firma abgeben kann, oder aber sie bieten eine Auswahl von gewünschten Services. Andere MRO Firmen spezialisieren sich auf spezifische MRO-Aktivitäten, wie zum Beispiel das Überholen von Motoren.
  • Drittparteien. Diese Gruppe umfasst Regierungen (durch ihren stetigen Besitz von Fluggesellschaften), Regulierungsbehörden, Flughäfen und unabhängige Dienstleistungsanbieter.
  • Das Outsourcing von Nicht-Kern-Aktivitäten durch Fluggesellschaften ist eine fortwährende Schlüsselstrategie in einem immer härter werdenden Wettbewerbsmarkt. Die meisten großen Fluggesellschaften outsourcen nun riesige Teile ihrer Wartungsarbeiten an unabhängige MROs, führen aber kleinere Wartungen weiterhin intern durch. Die Tatsache, dass nicht der gesamte Wartungszyklus outgesourct wird, liegt laut interner Quellen hauptsächlich im Widerstand der Gewerkschaften begründet. Aus diesem oft genannten Grund ist immer noch ein bedeutender Teil der MROs im Besitz der Fluggesellschaften und diese versuchen ihren Marktanteil an Dienstleistungen für Dritte zu erhöhen, um damit ihre Profitabilität zu verbessern.
  • Der andere Hauptgrund für den Widerstand der Fluggesellschaften, ihre gesamte Wartung outzusourcen, verbirgt sich in der Angst, dass sie Kontrolle bezüglich der Informationen über ihre Flotte einbüßen könnten. Die Profitabilität der Fluggesellschaften wird durch die Flugzeugauslastung bestimmt: Sitzplätze füllen und Gewinne einfahren, die Nutzlast ausschöpfen und das Flugzeug durch Minimierung der Wartungszeiten in der Luft halten. Daher, sollte es dazu kommen, dass eine Fluggesellschaft ihre Flugzeuge an eine MRO-Firma überträgt, tritt sie damit tatsächlich auch die Kontrolle über einen der Hauptfaktoren für ihren Profit an eine Drittfirma ab. (Es gibt darüber hinaus auch eine Regulierung, die von den Fluggesellschaften verlangt, die Wartung ihrer Flotten zu „beaufsichtigen").
  • Nur einige wenige führende Fluggesellschaften haben es geschafft, ihre MRO-Operationen in profitable Betriebe umzuwandeln (z.B. Lufthansa und Air France). Dennoch ist deren Profitabilität selbst in Bestzeiten höchstens marginal. Alle der großen Fluggesellschaften aus den USA boten in den 1980ern das gesamte MRO-Servicepaket an Dritte an, doch nur vergleichsweise wenige haben sich im Markt behauptet.
  • Es gibt drei zentrale Geschäftsströme in der Luftfahrts-MRO, und zwar:
    Flugzeugrümpfe, Motor, Luftfahrtselektronik und Komponentenwartung
    Einfache Wartung (Line Maintenance) und Flugzeugchecks
    Komponentenmanagement
  • Die Grundrundumüberholung bzw. die Grundwartungsarbeiten werden in MRO-Hangars ausgeführt. Das Flugzeug wird dabei außer Betrieb genommen und durch die Fluggesellschaft zum Hangar gebracht. Typischerweise werden anschließend die meisten Aktivitäten an Dritte outgesourct, wie zum Beispiel an spezialisierte Motorenreparaturbetriebe (die oft besondere Motoreneinzelteile wiederum an Spezialisten outsourcen). Kurzum, Ziel ist es, das Flugzeug schnellstmöglich zu runderneuern und wieder betriebsfähig zu machen.
  • Einfache Wartungen (Line Maintenance) und Flugzeugchecks (Maintrol) sind die leichten Wartungsarbeiten, die gemacht werden, während das Flugzeug in Betrieb ist. Diese Arbeiten müssen bei allen Zielflughäfen, die von der Fluggesellschaft angeflogen werden, ausgeführt werden (inklusive ihrem zentralen Knotenflughafen). „Maintrol" umfasst das Aufzeichnen der geflogenen Runden und Strecken, die Überwachung des Motoren- und Flugzeugrumpfzustands, und das Austauschen von Komponenten. Die wichtigste Aufgabe von „Maintrol" ist sicherzustellen, dass der nächste Flug des Flugzeug plangemäß vollzogen werden kann.
  • Das Komponentenmanagement kümmert sich darum, dass eine Fluggesellschaft einen ökonomisch möglichst effizienten Lagerbestand an Ersatzteilen hält. Dies umfasst eine Logistik, die dafür Sorge trägt, dass genügend Ersatzteile verfügbar sind, wenn an einem Flugzeug Teile ersetzt werden müssen.
  • Die wichtigste Voraussetzung für all diese MRO-Aufgabenbereiche ist nicht technische Kompetenz (da dies unabdingbarer Standard ist), sondern die Fähigkeit, Informationen auszutauschen und Aufgaben zu koordinieren. Es ist offensichtlich, dass dieser Prozess der Wartung ein aufgeteilter Prozess ist (die Wartung wird mittels der MRO-Industriezuliefererkette outgesourct) und dass „Maintrol"-Dienstleistungen auch an entfernten Flughafenstandorten durchgeführt werden. Wenn ein Flugzeug in einem Hangar liegt, kann die Fertigungszeit durch die Leistung des kleinsten Zulieferers in der Kette beeinflusst werden. Wenn ein Flugzeug in einem Flughafen liegt, kann es sein, dass es nicht starten darf solange ein bestimmtes Ersatzteil nicht beschafft worden ist. Die Auswirkungen dieser Situation sind eine Unterbrechung der Flugpläne und die damit zusammenhängenden, der Industrie wohl bekannten Probleme. Verzögerungen können daher nicht nur kostspielig werden, sondern auch der öffentlichen Wahrnehmung der Fluglinie schaden.
  • Im Vergleich zum Design und Bau von Flugzeugrümpfen, Motoren und Komponenten ist die Luftfahrt im MRO-Sektor „unterentwickelt". MRO setzt sich zusammen aus einem Prozess des Auseinanderbauens, Überprüfens, Reparierens und/oder Ersetzens. Die Teile werden anschließend wieder dorthin zurück gebaut, wo sie gefunden wurden. Jeder dieser Prozesse wird strikt nach von den OEMs zugelassenen Protokollen durchgeführt, und diese Prozesse werden von verschiedenen Regulierungsbehörden überwacht und genehmigt, die für die Flugsicherheit verantwortlich sind.
  • Es stellt sich somit heraus, dass der Prozess des Luftfahrts-MROs ein extrem komplexer und informationssensibler Prozess ist. Er beinhaltet das Sammeln von riesigen Mengen an Daten, detailgenaue Planung und eine präzise logistische Überwachung. Das Management dieses Prozesses bestimmt nicht nur die Effizienz der MRO-Firmen, sondern beeinflusst direkt den Endgewinn der Fluggesellschaften.
  • Die MRO-Firmen, wie auch die OEMs und die Fluggesellschaften haben derzeit eine Vielfalt von Enterprise Resource Planning (ERP-)Systemen im Einsatz, um den Informationsfluss innerhalb des Unternehmens zu steuern. Jedoch gibt es so gut wie keine Integration von IT-Systemen zwischen den Hauptparteien der Industrie. Außerdem werden Daten hauptsächlich auf Papier gesammelt und die Dateneingabe ist manuell. Die Quelle jeglicher Wartungsdaten ist das Flugzeug. Nach jeder Landung wird ein technisches Logbuch (ein Protokoll auf Papier) durch einen Flughafeningenieur und/oder ei nen Piloten ausgefüllt und vom Kapitän des Flugzeuges unterzeichnet. Diese „Tech logs" werden danach an den Hauptstandort der Fluggesellschaften geschickt, für gewöhnlich mittels eines zurückkehrenden Flugzeuges, und dort werden die Details per Hand in ein Computersystem eingegeben, um Managementprotokolle zu erhalten. Fluggesellschaften nutzen diese Protokolle, um ihre Flotten zu verwalten und Rundumüberholungschecks anzuordnen. Wenn für ein Flugzeug die Zeit für eine Rundumüberholung gekommen ist, werden viele Stapel Papier von den Fluggesellschaften an die MRO-Firma transferiert, die diese dann manuell in das MRO-IT-System eingeben.
  • Es kann zu erheblichen Verzögerungen bei der Eingabe der Daten kommen (die technischen Angaben einer Gesellschaft können einige Tagen bis einige Wochen „zu spät" eintreffen). Es kommt darüber hinaus zu wiederholter Arbeit und dem Potenzial von Fehlern bei der mehrfachen Eingabe des gleichen Ausgangsmaterials in verschiedene Systeme. Viele Formulare sind oft so unleserlich, dass genaue Eingaben ins System durch sie nicht mehr gemacht werden können. Manche Formulare gehen sogar ganz verloren. Wenn Probleme aufgrund von inakkuraten Daten auftauchen, ist es meist schon zu spät, eine andere zufriedenstellende Lösung zu finden.
  • Die Kommunikation zwischen den verschiedenen Industrieparteien findet immer noch hauptsächlich via Telefon und Fax statt, wenn es um die Überwachung der Wartung oder Ersatzteilbeschaffung geht. Denn obwohl es das Bemühen gibt, Kommunikationssysteme auf den neuesten Stand zu bringen, ist dieser Fortschritt langsam.
  • Die europäische Patentanmeldung EP 0810558 A2 (08.12.1997) eröffnet einen neuen Ansatz mittels eines elektronischen Systems zur Wartung von Flugzeugen.
  • Ein bedeutsamer Teil des Gesamtprozesses der Papiertransaktionen betrifft technische und operationale Logbücher für Flugzeuge. Typischerweise umfassen die gesammelten Daten eine gewisse Anzahl von Bereichen, so zum Beispiel Tank- und Beladungskalkulationen, Leistungskalkulationen, Gewichts- und Balancekalkulationen und Störungsmeldungen. Die Notwendigkeit für Fluggesellschaften, diese Papierdokumentation für jeden Flug durchzuführen und dann zurückzuschicken ist zeitraubend, arbeitsintensiv, kompliziert und fehleranfällig. Zusätzlich können, aus der Sicht der Instandhaltung, die derzeitigen Verfahren zum Transport und zur Eingabe von flugtechnischen und operationalen Logbuchdaten zu verzögerten Reaktionen auf beschlossene Maßnahmen führen und zu Flugverboten für Flugzeuge führen, die es versäumt haben, rechtzeitig einfache Störungen zu beheben.
  • Daher gibt es einen großen Bedarf an einem verbesserten System zur Sammlung von flugtechnischen Logdaten und/oder allgemeinen flugoperationalen Daten.
  • Überblick über die Erfindung
  • Die Erfindung ist ein Gerät, das elektronische Versionen der von Gesellschaften genutzten Formulare beinhaltet und/oder Formulare, die über den Inhalt konventioneller Formulare hinausgehen, und eine Vielfalt von wertvollen Funktionen hinzufügen, die im Folgenden beschrieben werden. Das Gerät ist dafür ausgerichtet, sich via einer oder mehrerer Kommunikationsmedien bei einem Server anzumelden und Daten zu übertragen und zu empfangen, und eine via Internet zugängliche Benutzeroberfläche (über „remote access") bereitzustellen, die den Zugang und die Aktualisierung von Daten ermöglicht, welche auf Serverseite und/oder Clientseite vorliegen. Das Gerät ist im besten Fall robust gebaut und portabel, kann jedoch jegliche elektronische Form annehmen.
  • Gemäß einer ersten Ausführungsform ist diese Erfindung ein Flugzeugdatenaufzeichnungsgerät zur Verwendung durch eine Vielzahl von Be nutzern, wobei jeder Benutzer ein eigenes zugewiesenes Sicherheitslevel hat, wobei das Datenaufzeichnungsgerät aufweist:
    eine Sicherheitsvorrichtung, um einen Benutzer zu identifizieren und sein zugehöriges Sicherheitslevel festzustellen,
    eine Benutzeroberfläche, die von einem oder mehreren Benutzern aus der Vielzahl von Benutzern technische und/oder operationale Daten sammelt, die mit einem Zyklus eines Flugzeugfluges zusammenhängen, wobei jeder Eintrag von technischen und/oder operationalen Daten ein eigenes zugewiesenes Sicherheitslevel hat,
    wobei die Benutzeroberfläche darauf ausgerichtet ist, nur Dateneingaben von einem Benutzer anzunehmen, wenn das Autorisierungslevel des Benutzers wenigstens dem Autorisierungslevel des Eintrags technischer und/oder operationaler Daten entspricht.
  • Mittels dieser Vorkehrungen haben nur die Personen mit einer passenden Autorisierung Zugang zu Daten auf dem Gerät, können sich diese in den entsprechenden Feldern der Formulare anschauen und/oder ändern und/oder entfernen. Dies ist eine wichtige Voraussetzung aus regulatorischen Gründen.
  • Das Datenaufzeichnungsgerät kann des weiteren Kommunikationsmöglichkeiten bieten, um eingegebene technische und/oder operationale Flugdaten an eine externe Datenspeicherungsmöglichkeit zu übertragen (z.B. einen entfernten Server).
  • Der Anschluss kann über ein Kabel und/oder ein schnurloses (wireless) Anschlussterminal erfolgen, das für die Verbindung zu einem Netzwerk genutzt werden kann, um eingegebene technische und/oder operationale Da ten auf eine Datenspeichereinheit auf einen Remote (fernen) Server zu überspielen.
  • Die Kommunikationsmöglichkeiten können auch ein Speicherlesegerät umfassen, z.B. ein Diskettenlaufwerk, das daran angepasst ist eine Speichereinheit zu lesen, z.B. eine Diskette. Zusätzlich dazu oder stattdessen können die Kommunikationsmöglichkeiten eine Flashkarte beinhalten, ein „dongle" (eine kleine elektronische Datenspeichereinheit, in Größe und Aussehen ähnlich eines Autoalarmmelders, das üblicherweise über einen USB-Anschluss mit dem Computer verbunden wird), oder andere tragbare Datenspeichereinheiten, auf denen eingegebene technische und/oder operationale Daten gespeichert werden können.
  • Die Benutzeroberfläche kann weiterhin daran angepasst werden, Daten, die vorher von Benutzern eingegeben und/oder durch die Kommunikationsmöglichkeiten empfangen wurden, auf dem Bildschirm anzeigen zu lassen. In diesem Fall kann die Benutzeroberfläche darauf abgestimmt werden, nur die Daten anzeigen zu lassen, für die der Benutzer das entsprechende Sicherheits- oder Benutzerlevel hat.
  • Gemäß einer zweiten Ausführungsform kann eine Autorisierungsvorrichtung vorgesehen sein, die so ausgerichtet ist, dass sie das Überspielen von Daten an den Server verhindert, solange nicht genügend Daten für eine vorher festgelegte Anzahl von Bereichen eingegeben wurden.
  • In einer weiteren Anwendungsform kann die Autorisierungsvorrichtung derart vorgesehen sein, dass die den Arbeitsfluss festlegt. Zum Beispiel kann die Dateneingabe bezüglich eines nachfolgenden Flugzyklus verhindert werden, solange die eingegebenen Flugdaten zu einem vorherigen Zyklus noch nicht lokal auf dem Gerät gespeichert und/oder an eine externe Speichermöglichkeit übertragen worden sind. Der logisch intuitivste Arbeitsfluss kann darauf angepasst werden, die bestehende papierbasierte Aufzeichnung von Flugdaten nachzuahmen, aber zusätzlich noch bereits bestehende Funktionen zu erweitern, um zusätzliche Nutzen für die Kunden zu schaffen.
  • Gemäß einer weiteren Ausführungsform kann die Benutzeroberfläche Listenmenüs enthalten, die mit Kategorien gefüllt sind, die zu den jeweiligen einzelnen Bereichen passen. Bevorzugt können diese Menüs automatisch über eine Referenz zu einer Speichereinheit aufgebaut werden. Auf diese Weise kann das System durch die Überspielung der Datenbank aktualisiert werden, ohne dass die Menüs neu verschlüsselt werden müssten.
  • Gemäß einer weiteren Ausführungsform kann die Benutzeroberfläche eine erste Serie von Listenmenüs enthalten, die mit Kategorien besetzt werden, die zur Identifizierung von Systemen eines Flugzeugs gebraucht werden. Diese können von einem Benutzer ausgewählt werden. Sobald dieser ein System eines Flugzeuges ausgewählt hat, werden die entsprechenden Menüpunkte aufgelistet, die eine vorher festgelegte Liste von Probleme anzeigen, die zum jeweiligen System des Flugzeuges passt. Optional können auch Eingabefelder für eingetippte Informationen bereitgestellt werden.
  • Die Benutzeroberfläche kann optional ein Störungsmeldesystem enthalten, wobei das Störungsmeldesystem aufweist:
    eine Menügenerierungsvorrichtung, um eine hierarchische Serie von Menüs zu generieren,
    eine Benutzerauswahlvorrichtung, um eine Benutzerauswahl von jeder der Serien von Menüs zu akzeptieren,
    eine Datenspeichereinheit, die eine Definition von Flugzeugmaschinenteilen enthält, wobei jedes Maschinenteil der Definition entweder ein Unterteil ist oder eines oder mehrere Unterteile enthält,
    wobei nach Erhalt einer Auswahl von der Benutzeroberfläche die Menügenerierungsvorrichtung ein Menü generiert, das eine Liste von Maschinenteilen aus der Definition enthält, die in der Datenspeichereinheit als Unterteile der Benutzerauswahl identifiziert werden.
  • Gemäß einer weiteren Ausführungsform der Benutzeroberfläche kann die Datenspeichereinheit mögliche Fehler enthalten, und jedes Maschinenteil, dass kein Menüunterteil hat, wird mit einem oder mehreren möglichen Fehlern verknüpft. Für diese Maschinenteile eines Menüs, die keine Unterteilung in der Datenbank haben, wird bei Selektion durch einen Benutzer ein Menü generiert, das eine Liste von möglichen Fehler mit dem entsprechenden Maschinenteil verknüpft. Hier soll bevorzugt die Datenspeichereinheit mit jedem einzelnen Maschinenteil und jedem möglichen Fehler einen Code verbinden. In diesem Fall wird die Auswahl des Benutzers eine Ausgabe (Output) generieren, die das Maschinenteil und den Fehler mittels des entsprechenden Codes identifiziert. Das Maschinenteil kann dann durch seinen Code und/oder den Code des Teiles, von dem es ein Unterteil ist, identifiziert werden.
  • Mit der Erfindung wird desweiteren ein Verfahren zum Sammeln von Flugdaten von einer Mehrzahl von Benutzern erstellt, wobei jeder Benutzer ein eigens zugewiesenes Sicherheitslevel hat, mit folgenden Schritten:
    Identifizieren eines Benutzers und Ermitteln des dem Benutzer zugewiesenen Sicherheitslevels,
    Gewinnen mit einem Zyklus eines Flugzeugflugs zusammenhängender Daten vom Benutzer, wobei jeder Dateneintrag ein eigens zugewiesenes Sicherheitslevel hat,
    wobei der Schritt der Datengewinnung vom Benutzer nur durchgeführt wird, wenn der Benutzer ein Autorisierungslevel hat, das wenigstens dem Autorisierungslevel des Dateneintrags entspricht.
  • Durch dieses Verfahren haben nur Personen mit passender Autorisierung Zugriff auf die Dateneingabe bei jeweils passenden Einträgen in den dazu zugehörigen Formularen. Dies ist eine wichtige Voraussetzung aus regulatorischen Gründen.
  • Dieses Verfahren der Aufnahme von Flugdaten könnte des weiteren beinhalten, technische und/oder operationale Flugdaten an eine externe Datenspeichereinheit zu übertragen.
  • Der Schritt, diese eingegebenen technischen und/oder operationalen Flugdaten an eine externe Datenspeichereinheit zu übertragen, kann auch die Verbindung mit einem Netzwerk beinhalten und das Überspielen von eingegebenen technischen und/oder operationalen Flugdaten an eine Datenspeichereinheit auf einem Remote Server.
  • Der Schritt, diese eingegebenen technischen und/oder operationalen Flugdaten an eine externe Datenspeichereinheit zu übertragen, kann auch das Speichern von technischen und/oder operationalen Flugdaten auf einer Datenspeichereinheit, z.B. einer Diskette, Flashkarte, „Dongle" oder anderen Datenspeichereinheiten beinhalten.
  • Dieses Verfahren kann auch die Anzeige von Daten umfassen, die zuvor von Benutzern eingegeben und/oder abgerufen worden waren. In diesem Fall kann die Datenanzeige auf diejenigen Benutzer beschränkt werden, die das diesen Daten entsprechende Sicherheitslevel haben.
  • Gemäß einer weiteren Ausführungsform kann ein Schritt eingebaut werden, der die Datenüberspielung an den Server verhindert, solange nicht genügend Daten für eine vorher festgelegte Anzahl von Bereichen eingegeben wurden.
  • Des weiteren kann die Dateneingabe bezüglich eines nachfolgenden Flugzyklus verhindert werden, solange die Eingabe der Flugdaten zu einem vorherigen Zyklus an ein/e externe/s Speichermöglichkeit oder -gerät noch nicht übertragen worden ist, oder bis Daten auf einen „Dongle" und/oder andere tragbare Datenspeichereinheiten kopiert worden sind.
  • Gemäß einer weiteren Ausführungsform kann dieses Verfahren eine Benutzeroberfläche anbieten mit einer ersten Serie von Listenmenüs, die mit Kategorien aufgefüllt werden können, die Sektionen oder Systemen eines Flugzeugs identifizieren. Diese Sektionen oder Systeme können dann von einem Benutzer ausgewählt werden und nach der Selektion einer Sektion oder eines Systems eines Flugzeugs dem Benutzer ein entsprechendes Listenmenü präsentiert werden; dieses beinhaltet eine Liste von vorher festgelegten Problemen, die mit der ausgewählten Sektion oder dem ausgewählten System des Flugzeugs verbunden sind.
  • Der Schritt der Ausarbeitung der Benutzeroberfläche kann außerdem ein Verfahren eines Störungsmeldesystems beinhalten. Dieses generiert ein Menü in einer hierarchischen Serie von Menüs, ausgehend von einer Datenspeicherung, die eine Definition von Flugzeugteilen enthält, in der jedes Maschinenteil der Definition entweder ein Unterteil ist oder mehrere Unterteile enthält. Nach dem Erhalt der Auswahl des Benutzers entsteht ein generiertes Menü, welches eine Liste von Teilen der Definition enthält, die in der Datenspeicherung als Unterteile der Benutzerauswahl identifiziert worden sind.
  • Dieses Verfahren, eine Benutzeroberfläche zu bieten, kann beinhalten, mögliche Störungen in der Datenspeichereinheit zu speichern, und diese Störungen mit und ineinander zu assoziieren, so dass wenn der Benutzers ein Teil eines Menüs selektiert, welches keine Unterteile auf der Datenspeichereinheit gespeichert hat, ein Menü generiert wird, das eine Liste von möglichen Störungen für bestimmte selektierte Maschinenteile anzeigt.
  • Dieses Verfahren kann auch den Schritt der Verknüpfung eines Codes mit jedem Maschinenteil und möglichen Störungen beinhalten, wobei die Datengenerierung zu einer Maschinenteilstörung dieses Teil und diese Störung durch den entsprechendem Code benennt. Das Maschinenteil kann durch seinen Code und/oder des Codes, von dem es ein Unterteil ist oder ähnliches, identifiziert werden.
  • Die Erfindung bietet eine Vielfalt von Vorzügen und Vorteilen, wobei nicht zuletzt die Verbesserung von Geschäftsprozessen, und der Aufbau von Effizienz in einer Vielzahl von wichtigen Geschäftsfeldern genannt werden sollten. Die zahlreichen Vorteile und Ausführungsformen werden in der folgenden, detaillierten Beschreibung aufgeführt.
  • Kurzbeschreibung der Zeichnungen
  • Die Erfindung wird nun detaillierter beschrieben und Bezug auf die beigefügten Graphiken nehmen, die folgendes zeigen:
  • 1 zeigt ein Überblicks-Blockdiagramm eines Systems gemäß der Erfindung,
  • 2 zeigt ein Beispiel eines Flussdiagramms gemäß der Erfindung,
  • 3 zeigt ein Beispiel eines Menüs gemäß der Erfindung,
  • 4 zeigt Beispiel eines Überspielungsprozesses gemäß der Erfindung,
  • 5 zeigt eine schematische Repräsentation von Datenaufzeichnung/Datenabrufung des Offline-Datenspeichermoduls (Off-line Stora ge Support Module), wie sie in der vorliegenden Erfindung genutzt wird, und
  • 6a und 6b zeigen den Überspielungsprozess gemäß der Erfindung beim Server.
  • Detaillierte Beschreibung der Erfindung
  • In diesem Dokument gibt es einige Tabellen. Es wird um Nachsicht gebeten und darauf hingewiesen, dass diese Tabellen nur Repräsentationen von beispielhaften Datensätzen enthalten und in keinster Weise den Möglichkeiten ein Limit setzen sollen. Das vollständige System (1) der Erfindung, so wie es in Graphik 1 gezeigt wird, enthält ein Datenaufzeichnungsgerät, das ein dazugehöriges Offline-Datenspeichermodul (3) und Möglichkeiten der Kommunikation via einem oder mehreren passenden Kommunikationsnetzwerken (4) zu einem Systemserver (5) hat. Das Offline-Datenspeichermodul ist im Grunde ein Softwaremodul, das auf dem Datenaufzeichnungsgerät aufsitzt, mit entsprechenden zugewiesenen Dateien. Der Systemserver (5) enthält ein Datenübertragungs und -abrufungsmodul (6), mit dem es möglich ist, Daten vom Datenaufzeichnungsgerät (2) auf einen Datensicherungsserver (7) zu übertragen und zu speichern. Der Datensicherungsserver (7) agiert dabei als eine Art Zwischenablage für alle von Flug- und Bodenpersonal gesammelten Informationen über die Nutzung und die Wartung eines Flugzeugs. Der Systemserver kann darüber hinaus auch ein „Remote Data Access Module" (fernes Datenzugriffsmodul) (8) haben, das es erlaubt, das Datenaufzeichnungsgerät (2) für den Zugang zu/die Abholung von gespeicherten Daten auf dem Datensicherungsserver (7) zu nutzen.
  • Optional kann ein Systemintegrationsmodul (9) die Interaktion zwischen dem System der Erfindung und anderen Flugzeugmanagementsyste men ermöglichen. Durch die Implementierung eines elektronischen Systems, das zum Beispiel die ERP-Systeme von verschiedenen Interessengruppen zu einem gewissen Grad integriert und im System der Erfindung vereinigt, können die Vorzüge geteilter Information optimiert werden. Zum Beispiel kann es in dem Unterfangen, die Wartung der Flugzeuge zu prüfen und/oder die Ersatzteile zu beschaffen, sinnvoll und wünschenswert sein, dass die betroffenen Mitglieder der Zuliefererkette Zugang zu diesen notwendigen Informationen haben, was in den bestehenden, papierbasierten Systemen nicht möglich ist.
  • Der Zweck des Datenaufzeichnungsgerätes (2) ist die Vereinfachung der Aufzeichnung von Flug- und Wartungsinformationen eines Flugzeuges, sowohl vom Flug- als auch vom Bodenpersonal. Es ersetzt effektiv das derzeitig vorherrschende papierbasierte, technische und/oder operationale Logbuch und Störungsmeldeformulare. Außerdem vereinfacht es auch die Integration einer Anzahl anderer wertvoller Funktionen (z.B. die Validierung, Leistungskalkulationen, Aufnahme der Lieferanteninformationen, erweiterte Datenschutzmaßnahmen, eine Reduktion von potenziellen Fehlerquellen) in den elektronischen Datenaufzeichnungsprozess. Das Datenaufzeichnungsgerät (2) kann vor allen Dingen zur Datenaufzeichnung genutzt werden, die von zwei verschiedenen Gruppen von Nutzern eingegeben wird; dies wären zum einen die Flugbesatzung und zum anderen das Boden- und Wartungspersonal, obwohl andere Nutzungsgruppen eingebunden werden können (z.B. Tankwagenfahrer, Mechaniker, die leichte Wartungsarbeiten durchführen (Line Maintenance), Caterer, Teilezulieferer, im Gepäck Beschäftigte, etc.). Jedem dieser Nutzer kann ein Sicherheitslevel zugewiesen werden. Verschiedene Nutzer in der gleichen Gruppe können verschiedene Sicherheitslevel zugewiesen bekommen. Zum Beispiel mag der Kapitän eines Flugzeuges ein höheres Sicherheitslevel haben als ein Co-Pilot oder ein Flugingenieur.
  • Das Datenaufzeichnungsgerät (2) sollte bevorzugt ein Personal Computer (PC) – am besten in einer Grafiktablett- oder Laptopkonfiguration- oder ein Personal Digital Assistant (PDA) oder ein vergleichbares Gerät mit einem passenden Betriebssystem sein. PDA ist der Begriff für ein mobiles tragbares Gerät, das EDV- und Informationssicherungsmöglichkeiten für den privaten oder geschäftlichen Bereich anbietet. Ein Beispiel für ein passendes Gerät und Betriebssystem wäre ein Fujitsu Stylistic LPT-600 Tablett-PC, auf dem Windows 2000 läuft, oder ein Fujitsu PenCentra 200 tragbarer PC mit Windows HPC, obwohl es hier zahllose Variationen gibt. Mobiltelefone mit einer PDA-Funktion sind eine weitere Option, denn sie bieten auch ein integriertes Kommunikationsgerät.
  • Das Datenaufzeichnungsgerät der Erfindung ist darauf ausgerichtet eine Benutzeroberfläche anzubieten, vorwiegend menübasiert. Die Benutzeroberfläche soll eine elektronische Repräsentation der zur Zeit üblichen papierbasierten technischen Fluglogbücher und allgemeinen Flugbetriebsformulare darstellen. Durch das Aufrechterhalten der Ähnlichkeit mit dem bestehenden papierbasierten System wird angenommen, dass die Anforderungen für die Zustimmung und das Training nicht so extensiv ausfallen wie es andernfalls sein dürfte, wenn auch vielleicht dieses System nicht das Effizienteste für die Dateneingabe und das Softwaredesign sein dürfte.
  • Jedoch ist die Benutzeroberfläche nicht darauf begrenzt, ausschließlich eine elektronische Repräsentation zu sein, und alternative Repräsentationen können entwickelt werden. In ähnlicher Art und Weise können weitere Formulare neben den bisher bestehenden Formularen bereitgestellt werden, die die Möglichkeiten der derzeitigen papierbasierten Formulare erweitern, und einige wertvolle Funktionen anbieten, wie zuvor beschrieben.
  • Ein enormer Vorteil, der durch die Erfindung ermöglicht wird, liegt in der Möglichkeit, akkurate Informationen in einer zeitnahen und zuverlässigen Art und Weise bereitzustellen. Die Genauigkeit wird über eine Vielzahl von Faktoren sichergestellt, darunter die Nutzung eines digitalen Datenaufzeichnungsgerätes. Die Reduzierung der Auswahl an Eingabefeldern und Menüs in bekannten Zusammenhängen verringert noch zusätzlich die Wahrscheinlichkeit von menschlichen Eingabefehlern. Ein Resultat dieses Wechsels von einem papierbasierten System ist, dass die Dateneingabe nur noch einmalig ist, wodurch die Notwendigkeit von mehrfachen Eingaben entfällt (ein Prozess, der stark fehleranfällig ist). So werden auch damit verbundene Arbeitskosten und Zeitverzögerungen reduziert.
  • Auch Probleme mit der Lesbarkeit sind nicht länger vorhanden, da alle Dateneingaben mittels eines digitalen Eingabegerätes ausgeführt werden (z.B. Tastatur oder virtuelle Tastatur).
  • Ein weiterer wichtiger Vorteil ist, dass relevante Informationen zum Flugzeug während der Wendephase normalerweise innerhalb von Minuten nach der Landung eines Flugzeuges übertragen werden können. Auch die Nutzung eines Computergerätes zur Datenaufnahme bedeutet, dass Kalkulationen an Bord geschehen können. Zum Beispiel können durch die Eingabe von Werten in die entsprechenden Felder oder durch die Auswahl von Werten aus einer vorbereiteten Werteliste Leistungskalkulationen, Umrechnungen von Einheiten, Zeitkalkulationen und/oder andere mathematische Operationen ausgeführt werden, und dann während der Wendephase an die richtigen Personen weitergeleitet werden.
  • Die Lieferkosten von Teilen können reduziert werden. So können zum Beispiel, nachdem Daten wesentlich schneller als mittels der papierbasierten Verfahrens, das mehrmals ausgeführt werden muss, an den Server gesendet worden sind, benötigte Teile früher bestellt werden und daher zeitnah ausgeliefert werden, wodurch die Notwendigkeit von teuren Last-Minute Teiletransportkosten eliminiert wird.
  • Die durch Flugstunden entstehenden Kosten können optimiert werden. (Darunter fallen unter anderem: Personalkosten, Flugzeug-, Motoren- und Komponentenmieten, „Arbeit-pro-Stunde-Wartungsverträge", etc.) Ver lorene Segmente können reduziert und die Auslastung der Flugzeuge optimiert werden.
  • In Bezug auf die Zuverlässigkeit lässt sich sagen, dass die Flugzeugdaten garantiert ihre intendierten Rezipienten erreichen. Es gibt keine verschwundenen Formulare. Falls benötigt, kann ein System eingerichtet werden, mit dem jedes Formular digital signiert und verifiziert werden muss, damit sichergestellt wird, dass die Informationsquelle einer Datenübertragung zuverlässig ist. Ein System, welches das Abschließen oder Abschicken von Formularen unterbindet, falls es leere Felder gibt, kann ergänzt werden. Dies hängt wiederum von den Anforderungen des Benutzers ab. Es kann bei der Übermittlung der Daten vom Gerät zum Server eine Akzeptanzprüfung hinzugefügt werden, die sicherstellt, dass die Daten ihr Ziel erfolgreich erreicht haben. Falls ein Ereignis eintritt, nachdem Daten aus irgendeinem Grund nicht mittels einer Internetverbindung übertragen werden können, kann das mobile Datenspeicherbackupsystem (wie zuvor beschrieben) genutzt werden.
  • Eine Fülle von wertvollen Funktionen kann in die Erfindung integriert werden, wie im folgenden näher erläutert.
  • Die Abflug- und Landeleistungskalkulationen können während der Wendephase an Bord ausgeführt werden und an den Server innerhalb weniger Augenblicke nach der Landung gesendet werden.
  • Gewichts- und Balancekalkulationen können auch an Bord vor dem Abflug durchgeführt werden. Diese Kalkulationen hängen von einer großen Anzahl an Eingaben ab, von denen der Gewichtsschwerpunkt für das reale Nettogewicht (mit leerem Tank), das tatsächliche Abfluggewicht und das tatsächliche Landegewicht berechnet werden können. Diese drei Anhaltspunkte können daraufhin auf einen Index-Gewichts-Graphen angelegt werden, um die Kontrollierbarkeit des Flugzeuges während des gesamten Fluges zu bele gen. Diese Erfindung unterstützt das von vielen Fluglinien genutzte „Flexweight"-Programm. Fiexweight-Daten können automatisch auf dem Server aufgenommen werden. Daten, die aufgezeichnet werden, betreffen u.a. das Gesamtfluggewicht, die Flugnummer, „außen/aus/an/innen"-Daten und die Rumpfnummer. Die aufgezeichneten Flexweight-Daten können dann analysiert werden und Berichte können auf dieser Basis generiert werden, mit der Zusammenfassung der Daten in ein finales Berichtformat (wie es von Eurocontrol, der Federal Aviation Administration/Authority (FAA), der Civil Aviation Authority (CAA) und von Boeing verlangt wird). Die Anwendung kann so aufgebaut sein, dass letzte Veränderungen schnell und leicht gemacht und die Resultate berechnet werden können. Dies kann Änderungen an der tatsächlichen Flugzeugkonfiguration oder der Ladung des Flugzeugs, z.B. der Passagiere (PAX), Betankung oder dem Cargo bedeuten. Gemäß einer weiteren Ausführungsform kann die Anwendung einen Graphen generieren, der sich am Standard der IATA zur Präsentation der Gewichtsdaten und der Balancedaten eines Flugzeuges orientiert.
  • Lieferantenmanagement ist ein wichtiger wertvoller Posten, der durch diese Erfindung erleichtert wird. Zum Beispiel können Kosten leichter abgestimmt werden, wenn elektronische Aufzeichnungen bezüglich Betankung, Flughafenservices und anderen Fluggesellschaften/Lieferanten-Transaktionen gemacht werden. Durch die Buchhaltung mittels genauer digitaler Dokumentationen von Käufen und Verkäufen, wodrunter beispielsweise auch das Lagerbestandsmanagement, Währungswechsel und Preissysteme fallen können, gibt es beträchtliche Möglichkeiten zur Schaffung von Wertsteigerung für Kunden in diesem Gebiet.
  • Um nur eines der oben genannten Gebiete genauer zu betrachten, ist das Tankmanagement ein Gebiet, das historisch betrachtet eines der Hauptprobleme in Bezug auf Kontrollierbarkeit der Kosten darstellt und das immer schwer genauer zu beschreiben war. Die große Menge an Tanktransaktionen hat es Fluglinien in der Vergangenheit schwer gemacht, ihre Kosten zu kon trollieren, die ihre internen Systeme kalkulieren. Sie sollten aber nur tatsächliche Rechnungen ihrer Lieferanten bezahlen. Durch die Verbesserung der Geschäftsprozesse und indem die elektronische Sammlung von Daten zu Tankmengen und -kosten für jedes Flugzeug, an jedem Flughafen, an jedem Tag, begonnen wird, können die Kosten der Fluglinien einfacher nachvollzogen und abgestimmt werden.
  • Tanknachweise (zum Beispiel Kalkulationen zu Tankladungen und Währungswechsel, genau aufgeschlüsselt vom Lieferanten falls notwendig) können besser gehandhabt und genauer eingegeben werden, wenn der Datenaufnahmeprozess der Erfindung genutzt wird. Es ist auch einfacher, genauer die Spritverbrennungmessungen aufzuzeichnen und so die Übersicht darüber zu erhalten. Alles in allem ist eine striktere Einhaltung der Tankpläne möglich und somit ist der Prozess der Tankkostenkontrolle in großem Maße vereinfacht.
  • Gemäß einer weiteren Ausführungsform bietet die Erfindung die Technologie, papierbasierte technische und/oder Betriebshandbücher und Dokumentationen in ein elektronisches Format zu konvertieren. Diese Technologie kann auf der ferngesteuerten Einheit installiert werden. Die elektronischen Versionen von Handbüchern aller Art können zu jedem Zeitpunkt kreiert, angesehen und bearbeitet Betriebshandbücher, Checklisten, Wartungsmanuale und/oder „Minimum Equipment Lists" (minimale Ausrüstungslisten) bzw. MEL-Handbücher zu speichern und anzuzeigen. Die Erfindung kann es auch erlauben, dass auf jede dieser Anwendungen zu jeder Zeit zugegriffen und/oder diese aktualisiert werden kann. Aktualisierungen können zwischen dem Datenaufzeichnungsgerät und dem Server durchgeführt werden.
  • Hilfstexte oder Onlinehilfe können für das Datenaufzeichnungsgerät zur Verfügung gestellt werden, um Informationen über die Bedienung jedes Formulars zu liefern und bei Problemen zu helfen.
  • Webbasiertes Training kann zur Einführung in die Benutzung der Erfindung angeboten werden. Der Inhalt kann auf die verschiedenen Benutzergruppen zugeschnitten werden, z.B. auf Piloten, Wartungsingenieure, Flug- und Bodenpersonal. Das Training kann aufgabenbasiert sein.
  • Durch die Nutzung des Client/Server-Modells, und mittels Internettechnologien, kann eine große Auswahl an externen Systemen an den Server der Erfindung angeschlossen werden. Zum Beispiel können „Extended Markup Language" (XML-)Daten an bestehende Fluglinien-ERP-Systeme exportiert werden, oder XML kann zur Verbindung von Daten von einer beliebigen Anzahl von verschiedenen ERP-Systemen genutzt werden. Darüber hinaus können Fluglinienpersonal, Auftragsnehmer, Geschäftspartner, Zulieferer oder andere relevante Interessengruppen Zugang zum Flugzeugstatus auf dem Server erlangen, und Berichte vom Server beziehen, Trends analysieren, die auf auf dem Server vorliegende Informationen aufbauen, oder Aktualisierungen zu Informationen auf dem Server vornehmen. Solche „remote access"-Möglichkeiten geben auch die Gelegenheit der interne Mitarbeiter und wichtige Lieferanten betreffenden Weitergabe von wichtigen operationalen, personellen, und kundenspezifischen Informationen.
  • Die Benutzeroberfläche hat bevorzugt eine Bildschirmeinheit mit einer dazugehörigen Anzahl von Formularen, z.B. Dateien in Hypertext Mark-Up Language (HTML) und/oder Extensible Mark-Up Language (XML), die, wenn sie auf dem Datenaufzeichnungsgerät angesehen werden, die einzelnen Sektionen der vergleichbaren papierbasierten flugtechnischen Logbücher und/oder der flugoperationalen Formulare anzeigt. Es wäre vorteilhaft, wenn mehr als eine Sektion zur Eingabe oder zur Betrachtung von Flugzeugdaten in einer einzelnen Datei gespeichert werden könnte und auch mehrere Sektionen gleichzeitig dargestellt werden können. Die Beschreibungssprache (HTML oder XML) diktiert der Bildschirmeinheit genau, wie sie Text und Bilder für den Benutzer darstellen soll. Jeder einzelne Markierungscode wird als ein Element definiert (obwohl viele es auch als „tag" bezeichnen). Manche Ele mente tauchen in Pärchen auf, die genau beschreiben, wann ein Bildschirmeffekt beginnen und wann er enden soll. XML ist flexibel darauf ausgerichtet, gängige Informationsformatierungen zu kreieren und sowohl die Formatierungen als auch den Inhalt im „World Wide Web" (WWW), in Intranets, etc. zu präsentieren. Zum Beispiel können Computerhersteller sich auf einen gemeinsamen Standard einigen, wie man die Informationen über ein Computerprodukt (Prozessorgeschwindigkeit, Speichergröße, usw.) beschreibt, und dann diese Produktinformation mit XML beschreiben. Solch ein standardisierter Prozess zur Beschreibung von Daten würde es einem Benutzer ermöglichen, einen intelligenten Agenten (ein Programm) an die Website jedes einzelnen Computerherstellers zu senden, diesen Agenten Daten sammeln zu lassen, und dann einen gültigen Vergleich zu berechnen. XML kann von jedem Individuum, jeder Gruppe von Individuen, oder Firmen genutzt werden, die ihre Informationen in einem einheitlichen Format mitteilen möchten.
  • Zusätzliche Funktionalität kann in die Formulare integriert werden, z.B. indem Java Script zusätzliche Funktionen für die Benutzeroberfläche anbietet, und indem die Oberfläche so einfach wie möglich zu nutzen und zu erlernen ist, und so effizient wie möglich ist, und dabei die Fehleranfälligkeit durch Menschenhand minimiert wird.
  • Die Formulare können zur Optimierung in hierarchischer Form gespeichert/generiert/angezeigt werden, um all die benötigten Informationen aufzuzeichnen, die von den jeweiligen verschiedenen Benutzern des Systems eingegeben werden müssen.
  • Das Datenaufzeichnungs- und Datenwiedergabegerät (2) wird auch ein passendes Kommunikationsinterface haben, um Daten vom Server abzuholen und dort aufzuspielen.
  • Gemäß einer Ausführungsform kann das Kommunikationsnetzwerk (4) das „General Packet Radio Services" (GPRS) nutzen, wodurch eine stän dige Verbindung zum Internet durch das Mobiltelefon, PDA und Computernutzer aufrecht erhalten werden kann. Mit GPRS werden Kommunikationskanäle auf einer geteilten Basis genutzt, die Datenpakete versendet, wenn diese gebraucht werden. Datenübertragungsraten von bis zu 114 KBps sind nach derzeitigem Stand möglich. Die hohen Datenraten geben Benutzern die Möglichkeit, mit einer verbesserten Geschwindigkeit mit Webseiten und vergleichbaren Anwendungen zu arbeiten und dabei mobile tragbare Geräte als auch Laptops zu nutzen.
  • Gemäß einer weiteren Ausführungsform kann das Kommunikationsnetzwerk (4) ein „Global System for Mobile Communication" (GSM-)Netzwerk (10) enthalten, in Kombination mit dem Internet (11), das durch einen Internet Service Provider (ISP) erreicht werden kann. GSM ist ein digitales mobiles Telefonsystem, das in Europa und anderen Teilen der Welt sehr verbreitet ist. GSM nutzt eine Variation des „Time Division Multiple Access" und ist die am häufigsten verwendete Technologie unter den drei digitalen schnurlosen Telefontechnologien (TDMA, GSM und CDMA). GSM digitalisiert und komprimiert Daten, und sendet sie dann über einen Kanal mit zwei anderen Datenströmen, jeder einzelne von diesen in seinem eigenen Zeitfenster. Es operiert bei einer Frequenz von entweder 900/1800 oder 1900 MHz. GSM liefert ein relativ günstiges, im hohen Maße verfügbares Angebot, es ist weit verbreitet und wird im hohen Maße eingesetzt, und es ist leicht in Datenaufzeichnungsgeräte integrierbar. Im besten Fall sollte der ausgewählte GSM-Netzwerkanbieter eher „High Speed Circuit Switched Data" (HSCSD) anbieten, eine Technologie, die schnellere Übertragungsraten (von bis zu 43.2 KBps, je nach Anbieter) ermöglicht als das konventionelle CSD (9.6 KBps).
  • Andere mögliche Kommunikationskanäle sind „International Maritime Satellite phone" (Inmarsat), „Very High Frequency Data Link, Mode 4" (VDL mode 4)- der Standard für digitale Kommunikationen, der mobile Kommunikationen zwischen Flugzeug und Flugzeug ermöglicht, und zwischen Flugzeug und Boden, „VDL mode 2" und Bluetooth. Die Kommunikation kann zum Bei spiel über eine TCP/IP-Verbindung entstehen, und die oben angegebenen Möglichkeiten sind nur die physikalischen Verbindungen (Kommunikationskanäle).
  • Gemäß einer weiteren Ausführungsform kann das Kommunikationsnetzwerk auch das „Very High Frequency" (VHF-)Spektrum von Radiowellen nutzen. Ein großer Teil der Satellitenkommunikation und -übertragung wird via VHF hergestellt. Die Breitbandmodulation kann von manchen Services genutzt werden. Kanäle und Subbänder innerhalb der VHF-Frequenzen des Radiospektrums werden von der Internationalen Telekommunikationsgesellschaft (ITU) vergeben.
  • Gemäß einer weiteren Ausführungsform kann das Kommunikationsnetzwerk das Aircraft Communications and Reporting System (ACARS) nutzen, das zwischen Flugzeug und Bodenstation mittels eines VHF-Netzwerkes kommuniziert. Dieses Netzwerk kann ein öffentlich zugängliches Netzwerk nutzen, wie z.B. GSM- und/oder GPRS-Netzwerke und/oder Industrienetzwerke.
  • Im Bezug auf die Benutzeroberfläche des Datenaufzeichnungsgerätes (2) müssen verschiedene Möglichkeiten für unterschiedliche Flugzeugtypen berücksichtigt werden, wie es auch schon bei den existierenden papierbasierten Systemen angesprochen wurde.
  • Beispiele von denkbaren Formularen können folgende Eingaben von Benutzern beinhalten. Diese Vorschläge sind aber nicht beschränkend gemeint:
    Anmeldeinformationen. Dieses Formular kann einfach nur Felder und/oder Menüs beinhalten, in denen Benutzernamen und Kennworte oder ähnliche Formen der Zugangsprüfung für das System abgefragt werden.
  • Flugbesatzunginformationen. Dieses Formular kann Felder und/oder Menüs zur Eingabe und/oder Selektion von Namen und Positionen von individuellen Besatzungsmitgliedern beinhalten (siehe auch Tabelle 6 für ein Beispiel).
  • Reiseaufzeichnungen (siehe auch Tabelle 4). Dieses Formular kann Felder und/oder Menüs zur Eingabe und/oder Selektion von Details beinhalten, die mit einer oder mehreren Flugstrecken zusammenhängen, die eine Flugreise konstituieren.
  • Tank- und Beladungsinformationen (siehe auch Tabelle 5). Dieses Formular kann Felder und/oder Menüs zur Eingabe und/oder Selektion von Details beinhalten, die mit verbrauchten Spritmengen zusammenhängt, z.B. verbranntem Sprit.
  • Informationen für Flieger (NOTAMs), die primär dazu genutzt werden können, Informationen über unerwartete oder temporäre Änderungen an Landebahnen und Flughäfen zu erhalten und auszuwerten.
  • Details zur Erteilung der Flugfähigkeit. Dieses Formular kann Felder und/oder Menüs zur Eingabe und/oder Selektion von Daten beinhalten, die dazu genutzt werden können herauszufinden, ob ein Flugzeug fliegen darf.
  • Öl- und Hydraulikinformationen. Dieses Formular kann Felder und/oder Menüs zur Eingabe und/oder Selektion von Details zum Ölverbrauch und -fluss beinhalten.
  • Leistungsdaten und -kalkulationen. Dieses Formular kann Felder und/oder Menüs zur Eingabe und/oder Selektion von Informationen beinhalten, das Aspekte der Flugzeugleistung bei verschiedenen Flugphasen betrifft (z.B. Ab- und Anflug).
  • Der Abflug des Flugzeugs, der Anflug und Fluginformationen. Dieses Formular kann Felder und/oder Menüs zur Eingabe und/oder Selektion von Informationen bezüglich der verschiedenen Flugphasen beinhalten.
  • Motoren- und Hilfsenergieeinheit (Auxiliary Power Unit=APU). Dieses Formular kann Felder und/oder Menüs zur Eingabe und/oder Selektion von Daten beinhalten, die mit dem Antrieb des Flugzeuges zusammenhängen.
  • Überschreitungen. Dieses Formular kann Felder und/oder Menüs zur Eingabe und/oder Selektion von Daten beinhalten, die eine Fülle von Parametern betreffen, z.B. ob sichere Temperaturstände oder Geschwindigkeiten überschritten worden sind.
  • Flugzeugwartung und Störungsvorgeschichte. Dieses Formular kann Felder und/oder Menüs zur Eingabe und/oder Selektion von Daten beinhalten, die mit Flugzeugwartung, Störungen und Teilelieferungen zusammenhängen.
  • Gewichts- und Balanceinformationen und -kalkulationen (siehe auch Tabelle 8). Dieses Formular kann Felder und/oder Menüs zur Eingabe und/oder Selektion von Daten beinhalten, die zum Beispiel mit Passagier- und Cargobeladungen zusammenhängen, und Graphen, die aus den eingegebenen Informationen erstellt werden können.
  • Bodenpersonalinformation. Dieses Formular kann Felder und/oder Menüs zur Eingabe oder Selektion von Namen und Positionen der Bodencrew beinhalten.
  • Bodenserviceinformationen (siehe auch Tabelle 7). Dieses Formular kann Felder und/oder Menüs zur Eingabe oder Selektion von Details beinhalten, die mit der Auswahl der Ausrüstung für jedes Flugzeug zusammenhängen.
  • Bodenpersonalinformationen, die an weitergeleitete Störungsmeldungsdaten angepasst werden.
  • Bodenpersonalinformationen, die an aufgeschobene Störungsmeldedaten angeglichen werden.
  • Bodenpersonalinformationen für Checklogbücher von Flughafenterminals.
  • Inhalte, die auf manchen der oben genannten Formularen gefunden werden können, sind in den Tabellen 4 bis 8 illustriert. Es bleibt unbedingt anzumerken, dass die Informationen in diesen Tabellen nur veranschaulichend sein sollen und nicht notwendigerweise das Layout oder den tatsächlichen Inhalt der Formulare repräsentieren.
  • Das dazugehörige Offline-Datenspeichermodul (3) erlaubt es dem Datenaufzeichnungsgerät (2), die aktuellen technischen Logbuchinformationen und allgemeinen Flugbetriebsinformationen auf einer Offline-Speichereinheit zu speichern, für den Fall, dass die Kommunikation mit dem Server nicht möglich sein sollte. Die Offline-Speichereinheit kann auch für die Verfolgung von Wartungsarbeiten genutzt werden, um zurückliegende Informationen zu behalten, so z.B. über Leistungskalkulationen, Lieferantenaufzeichnungen (z.B. zollfreie Verkäufe, Tankmanagement, und Komponentenmanagement), NOTAM Informationen, finanzielle Informationen und andere ältere Fluginformationen. Der minimale Speicherzeitraum von Daten wird ein kompletter Monat sein, obwohl längere Zeiträume angestrebt werden. Die genaue Dauer kann dann berechnet werden, wenn die Menge an Informationen, die archiviert werden, der gesamte verfügbare Speicherplatz und die verfügbare Rechnerleistung der tragbaren Geräte eingeschätzt worden ist. Die Informationen werden in einer adäquaten Struktur abgespeichert, um effizienten Zugang und effiziente Arbeit (z.B. mit einer relationalen Datenbank) zu ermöglichen. Dies kann durch die Implementierung von Benutzerauthentifizierungsmechanismen sichergestellt werden.
  • Eine Löschmöglichkeit kann eingebunden werden, um automatisch ältere Daten vom Aufzeichnungsgerät nach einer vorher festgelegten Zeit zu löschen, um so Datenüberfluss zu verhindern.
  • Ein beispielhafter Arbeitsfluss (20) zeigt Eingabemöglichkeiten von Benutzern des Datenaufzeichnungsgerätes (2), wie es in Graphik 2 gezeigt wird, und dieser Arbeitsfluss beginnt mit der Eingabe (21) von Flugsegmentdaten von der Flugbesatzung. Anschließend können Informationen (22, 23) von der Flugbesatzung während des Fluges und dann während der Ankunft eingegeben werden. Die Flugbesatzung kann (24) dazu verpflichtet werden eine Störungsmeldung und/oder allgemeine Eingaben zu Operationen während des Fluges und/oder bei der Ankunft zu machen.
  • Falls es keine Störungen am Flugzeug gibt, kann eine Störungsmeldung mit dem Eintrag „NIL", „keine Störungen", angefertigt werden. Das Bodenpersonal kann auch (26) zusätzliche Störungsmeldungen zu jedem Zeitpunkt der Wendephase ergänzen.
  • Wenn in Graphik 2 ein Arbeitseintrag mittels einer durchgezogenen Linie übergangen wird, bedeutet dies, dass dieser Eintrag ein optionales und/oder ein unregelmäßiges Element des Arbeitsflusses ist, so wie das Enteisen (28) u.ä.
  • Die Öl-, Hydraulik- und Tankeinträge (25, 27) sind üblicherweise verpflichtend, aber eine Reihe von anderen wertvollen Funktionen können genutzt werden, z.B. Leistungskalkulationen und Verkaufskalkulationen. Von diesen Berechnungen können verschiedene Protokolle erstellt werden.
  • Gemäß den Regulationen müssen alle Störungen während des Störungsbehebungsprozesses geklärt werden. Alle dafür nötigen Schritte (30) werden von einem Mechaniker eingegeben bevor das Flugzeug wieder für startklar und flugtauglich erklärt wird.
  • Der Terminalcheck (29) ist kein optionaler Eintrag, muss aber nur nach bestimmten Intervallen ausgefüllt werden.
  • Aus der Illustration sollte ersichtlich sein, dass verschiedene Gruppen (z.B. Flugpersonal, Bodenpersonal, Tankwart, Kapitän) für das Ausfüllen von verschiedenen Aspekten der Formulare verantwortlich sind.
  • Jedem Benutzer wird eine digitale Signatur und das lokale Speichern von aufgenommenen Benutzerdaten über das Drücken des „Abschicken"-Knopfs möglich sein. Sobald das Ausfüllen eines Formular abgeschlossen worden ist, können Fehleraufdeckungsmechanismen von Java oder ähnlichen Programmen dafür sorgen, dass die Korrektheit der Daten jedes einzelnes Eingabefeldes im betreffenden Formular geprüft wird. Falls ein Feld ausgelassen oder fehlerhaft ausgefüllt wurde, kann der Benutzer darauf aufmerksam gemacht und dazu angehalten werden, alle Fehler zu korrigieren, bevor er fortschreiten darf. Das Validieren von Formularen ist ein wichtiges Instrument des elektronischen Datenaufnahmeverfahrens, da es einen eindeutigen Vorteil vor papierbasierten Systemen bietet. Formulare, die korrekt ausgefüllt wurden, werden anschließend lokal in einer Übertragungswarteliste gesichert.
  • Die Übertragungswarteliste sorgt dafür, dass die von den Benutzern eingegebenen Daten auch sicher an die Hauptdatensicherungseinheit (7) übertragen und dort gespeichert werden.
  • Kam es bislang dazu, dass ein Pilot ein Problem berichten musste, z.B. dass die automatische Drosselung nicht korrekt funktionierte, mussten sie etwas wie folgt in das Textfeld der Störungssektion des Papierformulars bei Störungsmeldungen schreiben: „Automatische Drosselung klemmt". Andere Piloten konnten andere Formulierungen für die Meldung einer Störung verwenden. Zusätzlich konnte die Qualität der Handschrift zu Problemen bei der Interpretation der geschriebenen Beschreibung des Problems führen.
  • Die Umstellung auf eine computerbasierte Eingabe beseitigt die Probleme der Lesbarkeit der Handschrift, aber da unterschiedliche Beschreibungen von unterschiedlichen Leuten genutzt werden können, kann die automatische Übernahme von Textdaten in eine zentralisierte Datenbank immer noch schwierig bis unmöglich sein.
  • Um den Dateneingabeprozess zu vereinfachen und zu standardisieren, kann dementsprechend die Benutzeroberfläche unserer Erfindung mit einem Störungsklassifikationssystem ausgestattet werden, das genaue und standardisierte Beschreibungen von Störungen (und entsprechenden Reaktionen) erlaubt. Dieses beseitigt die Notwendigkeit, dass das Flugpersonal eine in Fließtext gehaltene Beschreibung der Probleme in der Störungssektion des flugtechnischen Logbuchs eingeben muss, und in ähnlicher Weise beseitigt es auch die Verpflichtung für das Bodenpersonal, Angaben zu Problemen in Fließtext bei der Sektion der flugtechnischen Logbücher über die Reaktion auf die Störung zu halten.
  • Das Störungsklassifikationssystem beinhaltet alle existierenden Standards, um Flugzeugsysteme zu beschreiben. Darunter fallen die ATA 100 und ATA Spec 2200 Standards, so wie die „Minimum Equipment List" (MEL) und Wartungsmanuale (MM) von OEMs aus der Luftfahrt sowie Fluggesellschaften.
  • Ein beispielhafter Auszug ist in Tabelle 1 dargestellt.
  • Figure 00310001
    Tabelle 1. Auszug einer Klassifikation eines Autodrosselungssystems
  • Dieser Standard wird in die Serie von Pull-Down-Menüs (ausklappbare Menüs) (40, 41, 42, 43) des Datenaufzeichnungsgerätes (2) eingebunden (wie in Graphik 3 ersichtlich), was beispielhaft in Graphik 3 illustriert wird, in dem ein Benutzer einen Bereich auswählen kann (z.B. Elektrik, 44), ein Untersystem (z.B. bei Elektrik: Autoflug, 45) und eine Komponente des Untersystems (z.B. Autodrosselung, 46). Das Menüsystem kann weiterhin daraufhin erweitert werden, eine Serie von Störungen (47, 48, 49) mit jeder Komponente zu assoziieren. Beispielsweise können in dem Fall der Autodrosselung folgende Störungen möglich sein: funktioniert nicht (47), klemmt (48) und zeitweise defekt (49).
  • Durch diese Menüführung und der damit verbundenen Möglichkeit für den Piloten, das Problem mit einer Serie von Menüs oder mit automatisch vorgegebenen Pull-Down-Listen zu klassifizieren, werden alle denkbaren Doppeldeutigkeiten bei der Beschreibung von Störungen und auch die Notwendigkeit einer eingetippten Beschreibung ausgeschlossen. Dadurch wird die Aufgabe für die Person, die die Störung melden muss ebenso einfacher wie für die Person, die aufgrund dieser Störungsmeldung agieren muss.
  • Bevorzugt sollten die Menüs automatisch durch eine Abfrage bei einer Datenbank, die passend nach dem AT-100 Standard codiert ist, gefüllt werden und nach diesem Standard die Flugzeugteile zusammen mit den entsprechenden Problemen codiert sein. So kann das System aktualisiert werden, indem einfach die Datenbank aktualisiert wird, ohne dass die Menüs auch neu programmiert werden müssten. Techniken, um eine Menüvorlage automatisch durch eine Datenbank auffüllen zu lassen und ausgewählte Selektionen abzuspeichern, sind in der Branche wohl bekannt.
  • Wie das Störungsklassifikationssystem genau funktioniert wird im folgenden genauer erläutert werden, wobei Bezug genommen wird auf das oben angegebene Beispiel der „nicht funktionierenden Autodrosselung".
  • In der Praxis wird die Person, die die Störung meldet (z.B. der Pilot) ein Störungsklassifikationssystem aktivieren, das ein erstes Menü (40) anzei gen wird, so wie es in Graphik 3 die Hauptbereiche identifiziert. Diese Bereiche sind im Beispiel wie folgt: Navigation, Elektrik (44), Hydraulik, Flugzeugrumpf, Motor/APU, andere.
  • Bei diesem Beispiel hat der Pilot zuerst die Option Elektrik (44) gewählt. Nach der Verarbeitung dieser Auswahl hat das Störungsklassifikationssystem ein zweites Menü (41) generiert, das Untersysteme des elektrischen Systems anzeigt, in diesem Beispiel: Autoflug (45), Kommunikation, Stromversorgung, Instrumente, Licht. Im angegebenen Beispiel wählt der Pilot aus dem zweiten Menü die Option „Autoflug" (45). Nach der Verarbeitung dieser Auswahl generiert das Störungsklassifikationssystem ein drittes Menü (42), das Komponenten des Autoflugsystems in der Elektrik anzeigt, in diesem Beispiel: Autopilot, Geschwindigkeitskorrektur, Autodrosselung (46), etc. Im angegebenen Beispiel wählt der Pilot aus dem dritten Menü (42) die Option „Autodrosselung" (46). Nach der Verarbeitung dieser Auswahl generiert das Störungsklassifikationssystem ein viertes Menü (43), das Störungsmeldungen zur Autodrosselungskomponente anzeigt, in diesem Beispiel: funktioniert nicht (47), klemmt (48), zeitweise defekt (49), anderes. Hier hat der Pilot die Option „funktioniert nicht" gewählt.
  • Als Reaktion auf die Auswahl der Störung aus dem Menü kann das Klassifikationssystem die Störung wie folgt speichern: „02-21-33-42", womit das Problem definiert ist als
    • (02) Elektrik
    • (21) Autoflug
    • (33) Autodrosselung
    • (42) klemmt.
  • Diese Störungsmeldung kann von jeder Person oder jedem System mit einem Wissen um das verwendete Kodierungsformat interpretiert werden.
  • Die Sicherheitsinfrastruktur der Erfindung garantiert, dass Nachrichten sicher über das öffentliche Internet verschickt werden können. Das Nachrichtensystem der Anwendung erfüllt die vier Grundprinzipien des sicheren Internets, und zwar:
    Authentifizierung – Die Identifizierung des Senders und die Verifizierung, dass der Sender der ist, der er vorgibt zu sein.
    Unleugbarkeit – Eine digitale elektronische Signatur kann dafür verwendet werden, einen Unterzeichner davon abzubringen abstreiten zu wollen, dass er oder sie eine Signatur an eine spezifische Aufzeichnung, einen Aufzeichnungseintrag oder an ein Dokument gehangen hat.
    Vertraulichkeit – Die Information bleibt verschlüsselt und sicher.
    Integrität – Die Absicherung, dass Nachrichten nicht während der Übertragung verändert werden.
  • Die gleichen Sicherheitsmaßnahmen können auf das Speichern von Informationen auf den tragbaren Speichereinheiten angewandt werden (zum Beispiel ein „dongle", eine Diskette, eine Speicherkarte oder andere Speichereinheiten) wie auch bei der Transmission von Daten über ein Netzwerk. Die gleichen Verschlüsselungs- und Autorisierungsprinzipien und -verfahren können hier auch genutzt werden, falls sie benötigt werden.
  • Die Joint Aviation Requirements (JAR-)145-Regulationen erfordern, dass die Arbeit an Flugzeugen von ausreichend qualifizierten Personen durchgeführt wird. JARs sind die Anforderungen, die von der Joint Aviation Authorities (JAA) in den Bereichen des Luftfahrtdesigns und -bau, Flugzeugnutzung und -wartung, und in der Ausbildung von Luftfahrtspersonal herausgegeben wird. JAA ist ein Verband der European Civil Aviation Conference (ECAC), das die zivilen luftfahrtsregulatorischen Autoritäten einer Reihe von europäischen Staaten vertritt, die sich darauf geeinigt haben, eine Kooperation in der Entwicklung und der Implementierung von gemeinsamen sicherheitsregulatorischen Standards und Prozeduren anzustreben. Diese Kooperation soll hohe und konsistente Standards der Sicherheit bieten, sowie ein „faires Spielfeld" für Wettbewerb in Europa. Es wird auch besonderen Wert auf die Abstimmung der JAA-Regulationen mit denen der USA gelegt. Aus diesem Grund wird eine Sicherung in Form eines Sicherheitsmodules bereitgestellt, um das einem Benutzer zugewiesene Sicherheitslevel abzufragen. Das Sicherheitsmodul ist fähig, einem Benutzer Zugang zu spezifischen Bereichen eines Formulars oder einzelner Formulare zu geben, wenn nachgewiesen werden kann, dass der Benutzer tatsächlich dazu qualifiziert ist diese Sektion zu vervollständigen, d.h. dass dieser Benutzer über ein Sicherheitslevel verfügt, das dem des Formulars oder Sektion des Formulars zugehörige Sicherheitslevel entspricht.
  • Gemäß einer Ausführungsform ist das Sicherheitsmodul durch Softwareroutinen implementiert, die den Benutzer mittels eines Benutzernamen und Kennworts autorisieren, die lokal auf dem Datenaufzeichnungsgerät gespeichert sind. Benutzern könnte der Zugang zu den Formularen verweigert werden, solange nicht eine gültige Benutzeridentifizierungs- und Kennwortkombination eingegeben worden ist. Zusätzlich könnte, jedes Mal wenn ein Benutzer eine Sektion als Teil eines Formulars elektronisch signieren möchte (in dieser Sektion ist dies verpflichtend), dieser zunächst erneut re-autorisiert werden, um abzugleichen, ob er zur Signierung gerade dieser Sektion autorisiert ist. Andere Optionen können auch implementiert werden, so kann zum Beispiel jeder Benutzer mit einem einmaligen digitalen Schlüssel versehen werden, den er dann in das Datenaufzeichnungsgerät eingeben kann. Der digitale Schlüssel kann beispielsweise den Benutzer und sein Autorisierungslevel identifizieren. In dieser Option kann zum Beispiel ein digitales Zertifikat für jeden Benutzer lokal auf dem Gerät gespeichert werden, oder jeder Benutzer könnte mit einem individuellen digitalen Zertifikat versehen werden, das auf einem externen Hardwareteil gespeichert werden könnte, welches an den Austausch mit dem Datenaufzeichnungsgerät angepasst wird, um das digitale Zertifikat bereitzustellen. Ein Benutzer kann auch dadurch authentifiziert werden, dass er einen Benutzernamen und ein Passwort eingibt, oder irgendeine Kombination der genannten Möglichkeiten.
  • Zusätzlich zu der Spezifikation der Qualifikationen (Sicherheitslevel), die ein Benutzer benötigt, um ein bestimmtes Set von elektronischen Formularen auszufüllen, kann das System auch daran angepasst werden, einem Benutzer eine Aktion zu erlauben, die einer handgeschriebenen Signatur entspricht.
  • Eine Verfahren, diese Signaturfunktion auszuführen, kann die Anfrage der Reauthentifizierung des Benutzers nach der Vervollständigung jeder Sektion eines Formulars oder eines ganzen Formulars sein. Eine digitale Signatur kann der bereitgestellten Identifikation entnommen werden (z.B. dem digitalen Zertifikat). Wie zuvor gesagt kann jedes Mal wenn ein Benutzer elektronisch eine Sektion als Teil eines Formular signieren möchte, er erst dazu verpflichtet werden, eine Reauthentifizierung durchzuführen, um festzulegen, ob er autorisiert und/oder qualifiziert ist diese bestimmte Sektion zu signieren.
  • Allgemeiner gesagt können auch andere Typen von elektronischen Signaturen zur Sicherstellung der Authentizität der Benutzer verwendet werden. Eine elektronische Signatur kann eine oder mehrere der folgenden Eigenschaften enthalten, ergänzend oder anstelle von der zuvor genannten digitalen Signatur: PINs, Benutzeridentifikationen und -kennwörter, digitalisierte Signaturen und biometrische Verfahren.
  • Das Sicherheitsmodul kann zu einer vollständig PKCS#11 zertifikatbasierten vertrauenswürdigen „Public Key Infrastructure" (PKI-)Infrastruktur oder einem ähnlichen Schema erweitert werden, falls notwendig. PKI gibt Benutzern eines ungesicherten öffentlichen Netzwerks die Möglichkeit, sicher und privat Daten auszutauschen durch die Nutzung eines öffentlichen und ei nes privaten kryptographischen Schlüsselpärchens, das über eine vertrauenswürdige Autorität gewonnen und verteilt wird. Die öffentliche Schlüsselinfrastruktur macht ein digitales Zertifikat möglich, das Personen oder Organisationen identifizieren kann und Zuweisungsregister, die diese Zertifikate speichern und, falls notwendig, ungültig machen.
  • Die öffentliche Schlüsselinfrastruktur bedient sich der öffentlichen Schlüsselkryptographie, welche das am weitesten verbreitete Verfahren im Internet zur Authentifizierung eines Nachrichtenversenders oder Verschlüsselers einer Nachricht ist. Traditionelle Kryptographie umfasst für gewöhnlich die Generierung und die Teilung eines geheimen Schlüssels für die Ver- und Entschlüsselung einer Nachricht. Dieses geheime oder private Schlüsselsystem hat den wesentlichen Nachteil, dass wenn der Schlüssel entdeckt oder von jemand anders abgefangen wird, Nachrichten einfach entschlüsselt werden können. Aus diesem Grund ist die öffentliche Schlüsselkryptographie und die öffentliche Schlüsselinfrastruktur der bevorzugte Ansatz zur Kommunikation übers Internet.
  • Nachdem ein Formular abgeschlossen worden ist, können die eingegebenen Daten auf die Datenspeichereinheit aufgespielt werden, zusammen mit den elektronischen digitalen Signaturen als Nachweis, dass der Benutzer der eingegebenen Information zustimmt oder dazu seine Zustimmung gibt.
  • Nachdem ein Formular vollständig ausgefüllt worden ist (und, falls notwendig, vom Benutzer signiert worden ist), kann es an die Datenspeichereinheit gesendet werden. Dies kann über das Drücken des „Abschicken"-Knopfes geschehen oder eines Knopfes mit ähnlichen Funktionen. Die einzelnen Formulare können einzeln oder zusammen aufgespielt werden.
  • In einer Anwendungsmöglichkeit kann der Kapitän des Flugzeuges, nachdem alle Formulare durch die dafür beauftragten Personen ausgefüllt wurden, dazu verpflichtet werden, seine Zustimmung zu geben und die ein gegebenen Daten gegenzuzeichnen, in dem Wissen, dass alle Daten, die aufgespielt werden, vollständig und wahrheitsgemäß sind.
  • Nachdem der Kapitän seine Zustimmung gegeben hat, können die Daten vom Datenaufzeichnungsgerät (2) via Kommunikationsnetzwerk (4) an den Server (5) übertragen werden.
  • Ein Zweck der vorliegenden Erfindung ist es, das gegenwärtige papierbasierte flugtechnische Logbuch und Störungsmeldungsformulare zu ersetzen. Jedoch verlangen die JAA-Regulierungen, dass eine Kopie dieser Informationen im Fall eines Flugunfalls an jeden Flughafen geschickt wird. Dementsprechend besteht die sehr wichtige Anforderung an das Aufzeichnungsgerät, eine Möglichkeit zu bieten, die Information in einem fernen Schutzort zu speichern (d.h. außerhalb des Flugzeugs).
  • Einer der Hauptanforderungen der JAA ist es, eine Kopie des flugtechnischen Logbuchs von der vorherigen Reise vor dem nächsten Flug der Maschine zu entfernen. Dies soll sicherstellen, dass eine Aufzeichnung jeglicher Fehler existiert, falls ein Flugzeug abstürzen sollte. Das Überspielen von Daten vom Datenaufzeichnungsgerät (2) an den Server (5) entspricht unter normalen Umständen diesen Anforderungen.
  • In manchen Fällen könnte die Kommunikation zwischen dem Datenaufzeichnungsgerät (2) und dem Server (5) nicht möglich sein, z.B. bei einem Kommunikations- und/oder Netzwerkfehler. Unter diesen Umständen wird üblicherweise eine ausgefüllte Papierkopie des flugtechnischen Logbuchs vor dem Abflug des Flugzeuges eingefordert. Dies wäre eine lästige Pflicht und in den meisten Fällen unpraktikabel, da das Kommunikationsproblem sich erst manifestieren könnte, nachdem alle notwendigen Schritte abgeschlossen worden sind und das zuständige Personal gegangen ist. Um dies auszuschließen ist das Datenaufzeichnungsgerät (2) im besten Fall mit einer tragbaren Speichereinheit ausgerüstet, z.B. einer Diskette, einem „pen drive", „dongle" oder einem PCMCIA-Speicherkartenslot. Die Daten, die aufgespielt werden sollen, können auf einer solchen tragbaren Speichereinheit im Fall eines Versagens der Kommunikation gespeichert werden. Die tragbare Speichereinheit kann dann vom Datenaufzeichnungsgerät getrennt werden. Die Speichereinheit kann dann aus dem Flugzeug transportiert werden und mit konventionellen Mitteln zurück zur Fluggesellschaft zur Überspielung geschickt werden. So wird ein Flugzeug nicht wegen eines Kommunikations-, Netzwerks- oder Serverfehlers vom Abflug abgehalten.
  • Demnach kann es drei Operationsmodi für das Datenaufzeichnungsgerät geben:
    • 1) Das lokale Speichern von gesammelten Daten auf einer Speichereinheit (d.h. einer Festplatte).
    • 2) Das Überspielen der gesammelten Daten auf den Server (mittels einer oder mehrerer der zuvor vorgestellten Kommunikationskanäle).
    • 3) Das Speichern der gesammelten Daten auf einer tragbaren Speichereinheit.
  • Ein exemplarischer Überspielungsprozess (50), wie in Graphik 4 zu sehen, beginnt mit der Vervollständigung der Dateneingabe (51). Die finale Verantwortung über die Flugtauglichkeit des Flugzeuges liegt beim Kapitän des Flugzeuges. Aus diesem Grund kann die Signatur des Kapitäns zum Zustimmungsformular zur Feststellung genutzt werden, dass alle Formulare zur Zufriedenheit abgeschlossen worden sind (52). Dieser Abschluss wird das Überspielen auf den Server auslösen. Der Benutzer kann dazu aufgefordert (53) werden die Überspielung zu beginnen. Zu diesem Zeitpunkt werden alle gespeicherten (XML-)Dokumente, die die von den Benutzern eingegebenen Daten genauer auflisten, an den Server gesendet (54). Der Umstand, dass die Komponenten eines vollständigen XML-Dokuments eines Flugzeugs in separaten Dateien liegen wiegt nicht so schlimm, da die XML mittels des Elements „include" die XML-Dateien vereinigen kann.
  • Nach der Selektion der Option, Daten aufzuspielen, wird eine Verbindung über das Kommunikationsnetzwerk mit dem Server hergestellt. Sicherheit kann hergestellt werden durch die Implementierung von einfachen HTML-Authentifizierungen, die für ferngesteuerten Datenzugriff und zum Schutz von Webseiten gegeben werden. Fortschrittlichere Sicherheitsverfahren können, falls notwendig, implementiert werden.
  • Die Kommunikation zwischen einem PC oder einem PDA-Gerät (2) und dem Server (5) kann über das HTTP-Protokoll erfolgen, das über eine TCP/IP-Verbindung mit einem öffentlichen Telefonnetzwerk kommuniziert. Der Kommunikationskanal könnte mittels Verschlüsselung der Datenpakete vor der Datenübertragung abgesichert werden. Diese Verschlüsselung kann zum Beispiel durch den dreifachen Data Encryption Standard (DES) implementiert werden. DES ist ein weit verbreitetes Verfahren der Datenverschlüsselung, die einen privaten (geheimen) Schlüssel nutzt, der als von der US-Regierung so schwierig zu knacken eingeschätzt wird, dass das Verfahren auf die Ausfuhr in andere Länder beschränkt wurde. DES nutzt einen 56-Bit-Schlüssel zu jedem 64-Bit-Datenblock. Dieser Prozess kann in verschiedenen Modi angewandt werden und umfasst 16 Durchläufe oder Operationen. Obwohl dies als „starke" Verschlüsselung bezeichnet wird, nutzen viele Firmen „dreifaches DES", das nacheinander drei Schlüssel zusammenfügt. Falls eine Verbindung nicht entstehen kann, werden die XML-Daten im Ausgangsordner bleiben (55), der als Variante einer „First In First Out-"Warteschlangenverarbeitung funktioniert und auf die nächste erfolgreiche Netzwerkverbindung mit dem Server (5) wartet. Falls es als notwendig angesehen wird, kann Nachrichten und Dokumenten eine einzigartige Kommunikations-ID zugewiesen werden, um die Kontinuität und die Zuverlässigkeit der versendeten Daten zu gewährleisten. Eine Kopie der erfolgreich aufgespielten Dateien kann lokal (56) auf dem Datenaufzeichnungsgerät gespeichert werden, z.B. in einem „Versendet-Ordner".
  • Der Webserver kann die Gültigkeit der XML-Daten überprüfen, indem er einen Nachrichtenabriss oder eine digitale Signatur, die lokal berechnet wurden, mit dem Abriss oder der digitalen Signatur, vergleicht, die von einem Offline-Datenspeichermodul stammen, und welche als Teil der XML-Benutzerdaten gesendet wurden.
  • Wenn die XML-Daten beim Server ankommen, kann die digitale Signatur validiert werden, um die Authentizität des Benutzers zu bestätigen, bevor die XML-Daten auf der Serverspeichereinheit gesichert werden. Falls die Signatur dem System nicht bekannt ist, werden die Daten nicht auf der Speichereinheit gesichert. Stattdessen wird eine Nachricht vom Server an den Benutzer des Datenaufzeichnungs- oder Datenübertragungsgerätes gesendet, dass die digitale Signatur nicht validiert worden ist.
  • Gemäß einer weiteren Ausführungsform kann das Konzept der Biometrik als Mittel eines höheren Authentifizierungsstandards genutzt werden. Biometrik sind Technologien, die menschliche Körperwerte, wie z.B. Fingerabdrücke, Augenretinas und Augenirises, Stimmlagen, Gesichtsabdrücke, und Handmessungen, besonders für Authentifizierungsmaßnahmen messen und analysieren. Solch eine Biometrik kann als Ersatz oder Ergänzung zur Nutzung von Computerpasswörtern und anderen Sicherheitsmaßnahmen verwendet werden.
  • Fingerabdrücke und andere biometrische Merkmale bestehen aus einem Lese- oder Scannergerät, und Software, die eingescannte Informationen in digitale Form konvertiert. Immer wenn Daten analysiert werden müssen, gibt es eine Datenbank, die biometrische Daten für den Vergleich mit älteren Datensätzen speichert. Wenn die biometrische Eingabe konvertiert wird, identifiziert die Software bestimmte Punkte der Daten als übereinstimmende Kontrollpunkte. Diese übereinstimmenden Punkte werden mit einem Algorithmus in einen Wert verarbeitet, der mit biometrischen Daten verglichen werden kann, die eingescannt wurden, als ein Benutzer sich Zugang verschaffen wollte.
  • Fingerabdrücke, Gesichts- oder andere biometrische Daten können auf einer Chipkarte gespeichert werden und Benutzer können sowohl die Chipkarte als auch ihre Finger- oder Gesichtsabdrücke für einen zusätzlichen Authentizierungsgrad prüfen lassen.
  • Nach den JAR-145-Regulationen muss eine Kopie der flugtechnischen Logbuchinformationen bei jedem Flughafen, bei dem Station gemacht wird, eingereicht werden. Sollte es jedoch in einem Fall keine Netzwerkabdeckung aus Gründen des Standortes geben oder eine Störung vorliegen, muss das Datenaufzeichnungsgerät dazu imstande sein, eine Kopie der Informationen durch das Speichern der Daten auf einem externen Gerät zu erstellen. Dieses Gerät kann dann vor dem Abflug aus dem Flugzeug gebracht werden, wie zuvor beschrieben.
  • Das Serverdatensicherungsgerät enthält eine zentrale Zwischenablage für jegliche eingereichte flugtechnische Logbücher und dazugehörige Störungsmeldungen und/oder eine Vielzahl von anderen allgemeinen Flugoperationen und verwaltungstechnischen Daten wie zuvor beschrieben.
  • Um abzusichern, dass das System eine charakteristisch offene, auf Standards basierende skalierbare Architektur bewahrt, sollten alle Interfaces, die zu den Daten, die in der Zwischenablage gelagert werden, bevorzugt XML/HTML-basiert sein und über das HTTP-Protokoll laufen. Das Interface zur Datenspeichereinheit kann jedoch über unterschiedliche Kanäle laufen, wie z.B. Open Database Connectivity (ODBC) oder Java Database Connectivity (JDBC). Auf Dateien kann durch mehrere verschiedene Datenbanken zugegriffen werden, wenn ODBC-Aussagen in einem Programm genutzt werden. JDBC ist ein Application Programm Interface (API) mit Spezifikationen, um Programme, die in Java geschrieben wurden, mit Daten in bekannten Daten banken zu verknüpfen. Mit einem kleinen „Brücken"-Programm kann das JDBC-Interface zum Zugang von Datenbanken via des ODBC-Interface genutzt werden.
  • Gemäß einer Ausführungsform kann es zwei primäre Interfaces zur Datenspeichereinheit des Servers geben, ein Datenaufzeichnungsinterface (6) und ein ferngesteuertes Datenzugriffsinterface (8).
  • Mit dem Datenaufzeichnungsinterface (6) können PCs oder PDAs Informationen an die Datenspeichereinheit übertragen und von ihr empfangen. Flugtechnische Logbücher, weitergeleitete Störungsmeldungen und andere flugoperationale Daten können z.B. via HTTP beim Datenaufzeichnungsinterface des Servers eingereicht werden. Das Datenaufzeichnungsinterface kann dann die Daten auf die Datenspeichereinheit laden.
  • Das ferngesteuerte Datenzugriffsinterface (8) gibt Clients (Sendern) mit Netzwerkzugang die Möglichkeit, z.B. via Internet die Datenspeichereinheit des Servers zu erreichen. Beispielsweise können Clientseiten auf ihre Daten, die in der Zwischenablage stehen, über ein JDP-fähiges Webinterface zugreifen. Das Interface kann Javaserverseiten und JavaBeans zur maximalen Skalierbarkeit nutzen, während ein eindeutiger Zusammenhang zwischen der Datenpräsentation (z.B. HTML oder XML) und der Datenspeichereinheit (7) gewährleistet wird.
  • Das „remote access"-Dateninterface kann es beispielsweise erlauben, dass Kunden Datenanalysen und Datenbankauswertungen vornehmen können. Optional kann dies beispielsweise über einen Zugriff via Web- und/oder WAP-Interface integriert werden, muss aber nicht auf diese Interfaceverfahren begrenzt sein.
  • Die Datenüberspielungskomponente (6) wird nun detaillierter beschrieben, und dabei wird auf eine beispielhafte Anwendungsmöglichkeit Be zug genommen. Der Datentransfer, der von dieser Komponente durchgeführt wird, ist eine XML-Codierung der Informationen, die von Benutzern in Formularen zusammen mit tatsächlichen kontextabhängigen Informationen vom Formular selber eingegeben wurden. Dies wird es dem System erlauben, das vollständige Formular zusammenzufügen, mit den darauf eingegeben Daten; dies ist eine Anforderung aus gesetzlichen Gründen.
  • Daraus resultierend, dass ein Benutzer erfolgreich und korrekt ein Formular oder eine Reihe von Formularen vollständig ausgefüllt hat, dann die Daten als vollständig oder korrigiert und akzeptiert digital signiert hat und den „Abschicken"-Knopf oder einen Knopf mit ähnlicher Funktion gedrückt hat, kommen die Daten bei der Überspielungskomponente (6) an. Die Benutzeroberflächenkomponente des Datenaufzeichnungsgerätes wird dann eine digitale Signatur zu den Informationen hinzufügen, um sicherzustellen, dass die Datenintegrität gewahrt wird, bevor schließlich die Informationen an die Datenüberspielungskomponente gesendet werden. Gemäß einer Ausführungsform kann ein „Message Digest 5" (MD5-)Auszug an die Information angehängt werden, um die Datenintegrität, wie zuvor beschrieben, sicherzustellen. MD5 ist ein Algorithmus, der 1991 von der RSA Security Inc. für digitale Signaturanwendungen entwickelt wurde. Der Algorithmus nimmt eine Nachricht willkürlicher Länge als Eingabe und produziert als Ausgabe einen 128-bit „Fingerabdruck" oder „Nachrichtenauszug" (Hash) der Eingabe. Es wird angenommen, dass es technisch nicht möglich ist, zwei Nachrichten mit dem selben Hash zu produzieren, oder eine Nachricht zu erstellen, die genau einem vorgegebenen ausgewählten Zielhash entspricht. Der MD5-Algorithmus ist für digitale Signaturanwendungen ausgelegt, in denen eine große Datei in einer abgesicherten Weise „komprimiert" werden muss, bevor sie mit einem privaten (geheimen) Schlüssel vermittels eines öffentlichen Verschlüsselungsystems, wie dem RSA, verschlüsselt wird. Der MD5-Algorithmus ist darauf ausgelegt, relativ schnell auf 32-Bit Maschinen zu sein. Zusätzlich braucht der MD5-Algorithmus keine großen Kodierungstabellen, so dass der Algorithmus ziemlich kompakt kodiert werden kann.
  • Die Kommunikation zwischen dem Datenaufzeichnungsgerät und der Überspielungskomponente kann mittels HTTP über das „Transmission Control Protocol/Internet Protocol" (TCP/IP) stattfinden, um eine Verbindung zum Webserver herzustellen, welcher der Hauptteil dieser Komponente ist.
  • Wie zuvor gesagt werden Daten an den Server (5) mittels eines HTTP-PUT- oder POST-Anfrageverfahrens gesendet, so dass bei der Ankunft der Daten (60) der Webserver (5) die Daten aus seinem Standardeingabekanal einlesen kann. Die Daten werden darauf geprüft, ob sie für das Datenüberspielungsmodul gedacht sind. Die Daten werden dann an den XML-Schnittstellenserver (61) des Datenüberspielungsmoduls weitergeleitet. XML-Daten werden aus dem HTTP-Anfragesatz extrahiert (63). Eine Kopie der extrahierten Daten wird in einem temporären Verzeichnis (64) gespeichert. Die digitale Signatur wird geprüft und bestätigt (65). Die Datei wird dann wie gefordert in Unter-XML-Dateien unterteilt (66). Die Daten von diesen Dateien werden dann auf die Datenspeichereinheit geladen (67). Die Übertragungsprüfungsinformation wird dann eingeloggt (68). Eine Bestätigung (69) wird zusätzlich zum Clientgerät gesendet. Falls eine der oben genannten Schritte nicht funktioniert, wird eine „Not Acknowledged" (NAK = „Nicht bestätigt-) Nachricht an den Client geschickt (70), eine Benachrichtigung über einen Übertragungsfehler. Nach der Komplettierung aller Schritte wird die HTTP-Verbindung geschlossen.
  • Der XML-Schnittstellenserver, der oben erwähnt wurde, agiert als Schnittstelle zwischen den Offline-Modulen der Datenaufzeichnungsgeräte, die von den Clients genutzt werden, und der technischen Abwicklung, z.B. den Datenspeichereinheiten des Servers, und nutzt dabei die zuvor beschriebenen Prozedur. Die Schnittstelle wird die Gültigkeit der XML-Daten durch den Vergleich eines lokal erstellten Hashes oder einer digitalen Signatur mit denen der mit den XML-Benutzerdaten Versendeten sicherstellen. Für den Fall, dass diese Hash- oder digitalen Signaturwerte nicht übereinstimmen, wird das System annehmen, dass der Kommunikationskanal die XML-Daten korrumpiert hat und wird den Benutzer darüber informieren, während es die Operationen der Ladeliste rückgängig macht. Bei weiteren Ausführungsformen kann die Validität der XML-Daten auch durch eine Reihe von anderen Prozeduren, die aber auf den gleichen Prinzipien aufbauen, bestätigt werden. Die Struktur des XML-Dokumentes kann durch den Vergleich mit der XML-Dokumentenvorlage oder dem XML-DTD-Dokument bestätigt werden.
  • Abschließend wird die digitale Signatur des Benutzers des Formulars validiert und die XML-Daten in der Datenspeichereinheit der Erfindung via des Datenintegrationsservice gespeichert. Falls die Signatur dem System nicht bekannt ist, werden die Daten nicht auf der Datenspeichereinheit gespeichert werden, und das System wird den Benutzer darüber informieren, während es die Operationen der Ladeliste rückgängig macht
  • Sobald die Formulare validiert worden sind werden sie an einen XML-kompatiblen Datenintegrationsservice weitergeleitet, um auf die Datenspeichereinheit transferiert zu werden.
  • Das „remote access"-Datenmodul (8) erlaubt es Benutzern, Anfragen an die Datenspeichereinheit (7) zu stellen. Der „remote access" kann durch eine webbasierte HTTP-Schnittstelle in die Datenspeichereinheit integriert werden, und so kann er zum Beispiel Fluggesellschaften ermöglichen, Anfragen zu stellen und Meldungen zu Betriebsdaten und zu Wartungsdaten von Flugzeugen zu erhalten, deren Daten vom System gesammelt werden.
  • Die Benutzeroberfläche könnte beispielsweise eine Sammlung von auf HTML- und/oder XML-basierenden Formularen sein, die es einem Benutzer ermöglichen, Informationen einzugeben, die relevant für die Suche sind, die sie durchführen möchten. In diesem Beispiel werden die Formulare durch eine „JavaServer Pages"-Technologie erstellt, die XML-ähnliche Tags und Elemente in Javasprache enthalten. So wird dann die logische Struktur, mit der der Inhalt der Seite generiert wurde, mit eingebracht. Die Struktur der Anfragelogik ist vom Rest getrennt, so dass diese innerhalb von Javakomponenten liegt, auf die von HTML- und/oder XML-Formularen zugegriffen werden kann. Dadurch, dass die Logik der Seite von ihrem Design und ihrer Anzeige getrennt wird, und durch die Unterstützung eines wiederverwendbaren komponentenbasierten Designs erlaubt die Logik der Seite eine schnellere und leichtere Erweiterung ihrer möglichen Auswahl an Anfragemöglichkeiten. Eine festgelegte Auswahl von Standardbenutzeroberflächen kann kreiert werden, aber diese Oberflächen können auch auf die Bedürfnisse jedes einzelnen zusätzlichen Benutzers zugeschnitten werden.
  • Gemäß einer Ausführungsform können Nachrichten- und Dokumentenlayouts auf zum Beispiel XML-Vorlagen basieren, die Flexibilität ermöglichen, wenn Struktur und Inhalt von Nachrichten und Dokumenten kreiert werden sollen.
  • Durch die Implementierung einer einfachen HTTP-Benutzerlevelautorisierung kann diese Komponente geschützt werden. Webbasierte einfache HTTP-Autorisierung verweigert den Benutzern den Zugang zum Web, die keine gültigen Benutzernamen und Kennwörter eingeben. Dieses Autorisierungsverfahren ist ein Standardverfahren, das von vielen Webseitenbetreibern genutzt wird, um Zugang zu bestimmten Datenverzeichnissen zu verweigern. Die Benutzernamen und -kennwörter werden in einer ähnlichen Weise gespeichert wie die einer Standard-Unix-Kennwortdatei. Kennwörter in einfacher HTTP-Autorisierung sind „base 64" zwischen dem Client und dem Webserver kodiert.
  • Die Datenaufzeichnungskomponente im Datenaufzeichnungsgerät wird durch das zuvor vorgestellte Offline-Speichermodul implementiert; dieses Offline-Speichermodul trägt eine Menge der einzelnen Geschäftsregeln gerade dieser Implementation in sich. Eine beispielhafte Architektur für das Offline-Speichermodul wird in Graphik 5 gezeigt.
  • Bei dieser Ausführungsform ist das Offline-Speichermodul (3) ein Sicherheitsproxyservice, der zwischen der Bildschirmeinheit bzw. dem „Bildschirmgerät" (82) und dem Internet sitzt. Als eine unabhängige Anwendung erlaubt es die Integration von Software, die auf dem System verfügbar ist.
  • Die Hauptkomponente des Offline-Speichermoduls (3) ist das Kontrollmodul, oder einfach gesagt, der „Kontroller" (80). Dieses Modul ist die zentrale Softwarekomponente, die für die Integration von den anderen angeforderten Komponenten zuständig ist, und welche die passende Geschäftsprozesslogik des Projekts enthält. Das Kontrollmodul kann alle Hauptelemente nutzen, die der Bildschirmeinheit zur Verfügung stehen, z.B. Kryptographie, digitale Signierungen, Dokumentenobjektmodell und XML-Datendarstellung. Wegen der Anforderung des Offline-Dienstes muss ständig eine Möglichkeit, d.h. eine lokale Speicherung, aufrecht erhalten werden zwischen verschiedenen Anwendungsformen von Geschäftsdaten – dies ist essentiell. Um diese Funktionalität zu erreichen, müssen Module und/oder Dateien XML-Konfigurationen (83), Datenspeicherprozesse (84), Datenspeicherung (85) und PKI-Verarbeitung (81) durchführen können.
  • Lokales Speichern kann den Gebrauch von XML-offenen Standard-Metadataformaten beinhalten; dies ist wegen ihrer Lesbarkeit, Erweiterbarkeit und weit verbreiteten Akzeptanz als Datenmodell im Geschäftsbereich. Kombiniert mit der Möglichkeit, XML mittels XSLT abzufragen und zu verarbeiten, ist das System dazu fähig, komplette „copy/read/update/delete" (CRUD-)Funktionen anzubieten, wodurch es zu einem Datenbanksystem wird. Das Offline-Speichermodul kann auch Sicherheitsfunktionen und Sicherheitsintegration mit Verschlüsselungen und digitale Signaturen bieten, z.B. für Universal Serial Bus (USB-)Anschlüsse, die die öffentlichen und privaten Verschlüsselungsschlüssel des Benutzers enthalten, die an den PKCS#11-Standard oder einen vergleichbaren Standard angepasst sind.
  • Die XML-Softwareschnittstelle kann lokal eine dreifach gefächerte Architektur auf dem Datenaufzeichnungsgerät enthalten, und somit ein offenes flexibles System bieten. Der Hauptvorteil dieser Lösung ist, dass die Wiedergabeebene durch eine Bildschirmeinheit bzw. ein „Bildschirmgerät" (82) gegeben ist, der auf dem Datenaufzeichnungsgerät (2) läuft; und da die Benutzeroberfläche bevorzugt in HTML oder XML beschrieben wird, kann die Wiedergabeebene einfach angepasst werden, um maximale Flexibilität und reduzierte Entwicklungszyklen für die Benutzeroberfläche zu ermöglichen.
  • Das Verfahren der Dateneingabe wird nun detaillierter beschrieben, und dabei wird auf eine Definition aus Dokumenten Bezug genommen, die die gesamte Flugtechnikinformation beschreibt. In der Praxis vervollständigen die Flugbesatzung und das Bodenpersonal Teilprotokolle, die sich auf Teile dieser gesamten Definition aus Dokumenten beziehen.
  • Die Benutzer füllen jeweils nur die Teilprotokolle aus, zu denen sie nach den JAR-OPS-Regulationen berechtigt sind. Nachdem die einzelnen Teilprotokolle jeweils ausgefüllt worden sind, darf sich der Kapitän die Informationen ansehen und den Gesamtabschluss bestätigen, wobei er dazu eine Benutzernamen- und Kennwortkombination nutzen kann.
  • Der Kapitän ist dazu bemächtigt, alle Teilprotokolle zu lesen, die von verschiedenen anderen Personen im Prozess ausgefüllt wurden.
  • Ein Benutzer kann all diese Teilprotokolle lesen, wenn er das bereitgestellte Interface nutzt. Der Kapitän kann dann das Formular signieren und den „Abschicken"-Knopf oder einen Knopf mit ähnlicher Funktion drücken. All diese Teilformulare, durch mehrere XML-Dokumente repräsentiert, werden an ein Backendsystem gesendet. Die Vereinigung dieser Komponenten des gesamten XML-Flugzeugdokumentes, die in separaten Dateien vorliegen, wird durch das XML-Tag „include" erreicht.
  • Flugtechnische Daten und/oder flugoperationale Daten können als eine hierarchische Sammlung von komprimierten (vom Client konfigurierbaren) XML-Dateien in einem funktionierenden Ordner im lokalen Hauptverzeichnis gespeichert werden (85). Nach dem Ausfüllen der technischen Logbücher und/oder der operationalen Formulare kann eine zusammengefügte XML-Datei, die die aufgezeichnete Information enthält, in der Offline-"Zuversenden"-Ablage gespeichert werden, welche die FIFO-Ladeliste des Datenaufzeichnungsgerätes darstellt.
  • Ein Beispiel eines Datenordners und seine zugedachten Inhalte werden in Tabelle 2 dargestellt.
  • Figure 00500001
    Tabelle 2
  • Aus der Perspektive der Wartung werden eine Reihe von Regeln und Voraussetzungen bei der Implementierung des Datenaufzeichnungsgerätes gemacht. Diese Voraussetzungen sind wie folgt:
    Jede Störung wird eine zugewiesene Reaktion und eine optional weitergeleitete Störung haben.
  • Jede weitergeleitete Störung wird bevorzugt eine assoziierte Reaktion auf die Störung und eine oder mehrere optionale Aktualisierungsaktionen für die Störung haben.
  • Aktualisierungsaktionen können nur als Resultat auf eine weitergeleitete Störung ergriffen werden.
  • Wenn eine weitergeleitete Störung eingereicht wird, kann es sein, dass das Clientsystem den Server mit der originalen zugewiesenen Flugtechniklogbuchnummer und der ursprünglichen Störungsnummer versorgen muss, von der die Meldung der Störung kam. Dies macht es möglich, einen Verweis an die weitergeleitete Störung anzuhängen, der eine Rückverfolgung zur ursprünglichen Störung ermöglicht.
  • Daher sollten diese Details bei der Weiterleitung der Störung in der XML-Datei beibehalten werden, die auf dem Client gespeichert wird.
  • Wenn eine weitergeleitete Störung zur Hauptbasis der Fluggesellschaft geschickt wird, kann es notwendig sein, dass das Clientsystem den Server mit der originalen zugewiesenen Nummer des Flugtechniklogbuchs und der ursprünglichen Störungsnummer versorgt, von der die Meldung der Störung kam. Dies ermöglicht es, einen Verweis an die zur Hauptbasis weitergeleitete Störung anzuhängen, der eine Rückverfolgung zur ursprünglichen Störung und zur weitergeleiteten Störung ermöglicht. Ebenso sollten diese Störungen detailliert erhalten bleiben, zum Beispiel sollte eine weitergeleitete Störung in einer XML-Datei auf dem Client gespeichert werden.
  • Wenn eine Reaktion auf eine Störung eingereicht wird, muss das Clientsystem den Backendserver über den Typ der Störung, auf die sich die Reaktion bezieht (z.B. Störung, weitergeleitete Störung oder an die Hauptbasis weitergeleitete Störung), und die originale zugewiesene Nummer des Flugtechniklogbuchs und die ursprüngliche Störungsnummer, von der die Meldung der Störung kam, informieren. Diese Kombination macht es möglich, einen Verweis an die Reaktion auf die Störung anzuhängen, der eine Rück verfolgung zur Störung, zur weitergeleiteten Störung oder zur Hauptbasis weitergeleiteten Störung, auf die sich die Reaktion bezieht, ermöglicht.
  • Eine Hauptfunktion der Benutzeroberfläche des Datenaufzeichnungsgerätes ist es, die Eingabe von Daten gemäß der alten Papierformularvorlagen zu erlauben. Papierbasierte technische Logbücher und Störungsmeldeprotokolle für Flugzeuge können folgende in Tabelle 3 enthaltene Elemente beinhalten, sind aber nicht darauf beschränkt.
  • Figure 00520001
    Tabelle 3: Komponenten technischer Logbüchern und Störungsmeldungen
  • Tabelle 4 illustriert ein beispielhaftes Reiseprotokoll, indem die Dateneingabe im elektronischen Format vereinfacht wird, da die Eingabe nur in den vorgegebenen Feldern möglich ist. Obwohl es eine allgemeine Voraussetzung sein kann, dass jedes Feld des Formulars aus Validierungsgründen ausgefüllt werden muss, kann es in dem Fall des Reiseprotokolls dazu kommen, dass es weniger als die vorgegebene Anzahl von Flugstrecken in einer Reise gibt, und daher kann es sein, dass die üblichen Regelungen dahingehend verändert werden müssen, leere Felder zu erlauben. Die Felder können durch ein Pull-Down-Menü oder via Tastatur vom Benutzer ausgefüllt werden, je nach den Systemspezifikationen.
  • Figure 00520002
  • Figure 00530001
    Tabelle 4: Reiseprotokoll
  • Tabelle 5 zeigt ein beispielhaftes Formular fürs Tankmanagement, das in der Erfindung enthalten sein kann. Wie es in diesem Dokument diskutiert wurde können die Tankaufzeichnungen besser gehandhabt und genauer eingegeben werden, wenn der Datenaufzeichnungsprozess der Erfindung genutzt wird.
  • Figure 00530002
    Tabelle 5: Ein beispielhaftes Formular eines Grundtankmanagements
  • Tabelle 6 zeigt ein Beispiel eines Formulars – wiederum basierend auf existierenden papierbasierten Standards – das genutzt werden kann, um aufzuführen, welche Besatzungsmitglieder an einer Reise teilnehmen.
  • Figure 00540001
    Tabelle 6: Grundformular zu Details über Besatzungsmitglieder
  • Figure 00540002
    Tabelle 7: Grundformular zu Aufgaben des Bodenstationsservices
  • Tabelle 7 zeigt ein einfaches Beispiel eines Formulars, das mehr für die Aufnahme von Informationen genutzt wird, die sich auf die möglicherweise ausgeführten Bodenstationsservices beziehen, als dass dieses Formular für das eigentliche Flugzeug gebraucht wird. Es kann sich als ebenso wichtig erweisen, diese Daten so genau wie die flugtechnischen und/oder operationalen Daten aufzunehmen, und mittels des Datenaufzeichnungsgerätes der Erfindung kann diese Aufnahme von Daten schnell und einfach vonstatten gehen.
  • Figure 00550001
  • Figure 00560001
    Tabelle 8: Beispiel eines Gewichts- und Balanceformulars
  • Tabelle 8 zeigt ein einfaches Beispiel eines Formulars, das für die Aufnahme von Informationen genutzt wird. Durch das Datenaufzeichnungsgerät der Erfindung kann diese Aufnahme von Daten wiederum schnell und einfach vonstatten gehen. Wie es zuvor mit Bezug auf das Gewicht/die Ladung und Balance diskutiert wurde, kann die Erfindung auch zum Anlegen von Graphen genutzt werden, die auf die vom Benutzer eingegebenen Informationen basieren.
  • Der tatsächliche Datenüberspielungsprozess an den Server wird nun detailliert beschrieben, und dabei wird Bezug genommen auf die Graphen 6A und 6B. Der XML-Schnittstellenserver kann als eine CGI-Anwendung auf einem Webserver laufen und als Schnittstelle zwischen dem Offline-Modul des Clients und den Datensicherungssystemen auf dem Backend agieren. Nachdem der Kapitän das Bestätigungsformular ausgefüllt und signiert hat, werden die Daten an die Server gesendet.
  • Der Server erhält eine HTTP-Verbindung (60) mit einer POST- oder PUT-Anfrage nach einer URL vom Datenaufzeichnungsgerät; diese URL ist so konfiguriert, dass sie die XML-Schnittstelle aufruft (62). Die verschlüsselte XML-Datei oder -Nachricht wird vom HTTP-POST- oder PUT-Anfragensatz extrahiert (63), und eine Kopie wird sogleich in einem temporären Verzeichnis platziert (64). Die digitale Signatur (65) wird geprüft und validiert. Die Datei wird dann in Unter-XML-Dateien (66) unterteilt. Die XML-Daten werden dann als einfacher Text an einen entfernten Datenintegrationsservice via eines zum Laden in die Datenspeichereinheit aufgerufenen TCP/IP-Sockels gesendet (67). Die Information der Übertragungsprüfung wird dann eingeloggt (68). Wenn all diese Schritte erfolgreich waren, kann ein Bestätigungssignal (ACK-Signal) an den Client gesendet werden (69), um das erfolgreiche Überspielen zu bestätigen; jedoch kann ein Nichtbestätigt-Signal (NAK-Signal) versendet werden (70), um das Versagen einer oder mehrerer Schritte zu übermitteln. Die HTTP-Verbindung kann dann geschlossen werden. Sollte einer der zuvor genannten Schritte nicht durchgeführt werden können, wird eine NAK-Nachricht an den Client gesendet (70), was auf einen Fehler deutet. Nach Abschluss wird die HTTP-Verbindung geschlossen.
  • Eine wichtige Voraussetzung des Datenüberspielungssystems ist es, eine Lenkbarkeit von einem Ende zum anderen Ende und ein Fehlermeldesystem an den Client zu gewährleisten, der den Prozess initiiert hat, und dies in einer klaren und visuell benutzerfreundlichen Art und Weise. Der Benutzer, der den Prozess initiiert hat, sollte nicht nur auf erfolgreiche Überspielungen aufmerksam gemacht werden, sondern auch auf alle Fehler, die möglich sind. Diese Lenkbarkeit von einem Ende zum anderen Ende sollte ein gesamtes Übertragungsprotokoll vom Datenaufzeichnungsgerät bis zur Datenspeichereinheit auf dem Backend des Systems bieten.
  • Die digitale Signatur wird geprüft und die XML-Daten werden auf der Datenspeichereinheit via des Datenintegrationsservices gespeichert. Falls die Signatur dem System nicht bekannt ist, werden die Daten nicht auf der Datenspeichereinheit gespeichert, und das System wird den Benutzer darüber informieren, während die Operationen der Ladeliste rückgängig gemacht werden.
  • Datenintegration beginnt, wenn der XML-Schnittstellenserver das XML-Dokument dekodiert und die Signaturen, die in den XML-Daten enthalten sind, bestätigt und validiert. Danach ist es notwendig, diese unverschlüsselten XML-Daten in der Datenbank zu speichern. Die Wörter „enthält/enthalten" und „umfasst/hat", wenn sie hier im Rahmen der Erfindung verwendet werden, deuten die Verwendung von zitierten Merkmalen, Ganzzahlen, Schritten oder Komponenten an, schließen aber nicht die Verwendung oder Ergänzung von einem oder mehreren anderen Merkmalen, Ganzzahlen, Schritten, Komponenten, oder Kombinationen dieser aus.

Claims (28)

  1. Flugzeugdatenaufzeichnungsgerät zur Verwendung durch eine Vielzahl von Benutzern, wobei jeder Benutzer ein eigenes zugewiesenes Sicherheitslevel hat, wobei das Datenaufzeichnungsgerät aufweist: eine Sicherheitsvorrichtung, um einen Benutzer zu identifizieren und sein zugehöriges Sicherheitslevel festzustellen, eine Benutzeroberfläche, die von einem oder mehreren Benutzern aus der Vielzahl von Benutzern technische und/oder operationale Daten sammelt, die mit einem Zyklus eines Flugzeugfluges zusammenhängen, wobei jeder Eintrag von technischen und/oder operationalen Daten ein eigenes zugewiesenes Sicherheitslevel hat, wobei die Benutzeroberfläche darauf ausgerichtet ist, nur Dateneingaben von einem Benutzer anzunehmen, wenn das Autorisierungslevel des Benutzers wenigstens dem Autorisierungslevel des Eintrags technischer und/oder operationaler Daten entspricht.
  2. Datenaufzeichnungsgerät nach Anspruch 1, ferner mit einer Kommunikationsvorrichtung, um eingegebene flugtechnische und/oder operationale Daten an eine externe Datenspeichereinheit zu senden.
  3. Datenaufzeichnungsgerät nach Anspruch 2, bei dem die Kommunikationsvorrichtung ein schnurloses Verbindungsterminal oder -modem zur Verbindung mit einem Netzwerk enthält, um eingegebene Flugdaten in die externe Datenspeichereinheit zu laden.
  4. Datenaufzeichnungsgerät von Anspruch 2, bei dem die Kommunikationsvorrichtung einen Speicherkartenleser enthält, der Daten auf einer herausnehmbaren Speichereinheit sichern kann.
  5. Datenaufzeichnungsgerät nach einem der vorherigen Ansprüche, bei dem die Benutzeroberfläche zuvor von Benutzern eingegebene Daten und/oder Daten, die durch die Kommunikationsvorrichtung erhalten wurden, anzeigen kann.
  6. Datenaufzeichnungsgerät nach Anspruch 5, bei dem die Benutzeroberfläche ferner Daten nur denjenigen Benutzern anzeigt, die für das Sicherheitslevel, das mit den anzuzeigenden Daten verknüpft ist, die Berechtigung haben.
  7. Datenaufzeichnungsgerät nach irgendeinem der vorherigen Ansprüche, ferner mit einer Autorisierungsvorrichtung, welche die Übermittlung von Daten an die Datenspeichereinheit verhindert, bis Daten für eine Anzahl vorbestimmter Sektionen eingegeben worden sind.
  8. Datenaufzeichnungsgerät nach Anspruch 7, bei dem die Autorisierungsvorrichtung darauf ausgerichtet ist, die Dateneingabe zu einem nachfolgenden Flugzyklus zu verhindern, bis eingegebene Flugdaten zu dem vorherigen Zyklus an eine externe Datenspeichereinheit gesendet worden sind.
  9. Datenaufzeichnungsgerät nach irgendeinem der vorherigen Anspruche, bei dem die Benutzeroberfläche eine erste Serie von Listenmenüs aufweist, die mit Kategorien gefüllt sind, die Sektionen und/oder Systeme eines Flugzeuges identifizieren, wobei die Kategorien von einem Benutzer ausgewählt werden können, und wobei nach Auswahl einer Sektion oder eines Systems eines Flugzeugs dem Benutzer ein nach folgendes Listenmenü präsentiert wird, welches eine Liste von vorausgewählten Problemen identifiziert, die mit der gewählten Sektion oder dem gewählten System eines Flugzeugs zusammenhängen.
  10. Datenaufzeichnungsgerät nach irgendeinem der Anspruche 1 bis 8, bei dem die Benutzeroberfläche ferner ein Störungsmeldesystem enthält, wobei das Störungsmeldesystem aufweist: eine Menügenerierungsvorrichtung, um eine hierarchische Serie von Menüs zu generieren, eine Benutzerauswahlvorrichtung, um eine Benutzerauswahl von jeder der Serien von Menüs zu akzeptieren, eine Datenspeichereinheit, die eine Definition von Flugzeugmaschinenteilen enthält, wobei jedes Maschinenteil der Definition entweder ein Unterteil ist oder eines oder mehrere Unterteile enthält, wobei nach Erhalt einer Auswahl von der Benutzeroberfläche die Menügenerierungsvorrichtung ein Menü generiert, das eine Liste von Maschinenteilen aus der Definition enthält, die in der Datenspeichereinheit als Unterteile der Benutzerauswahl identifiziert werden.
  11. Datenaufzeichnungsgerät nach Anspruch 10, bei dem die Datenspeichereinheit ferner mögliche Fehler enthält, die mit den jeweiligen Teilen zusammenhängen, und bei der nach Benutzerwahl eines Teils aus einem Menü, das kein Unterteil in der Datenspeichereinheit abgespeichert hat, die Menügenerierungsvorrichtung ein Menü aus der Datenspeichereinheit generiert, das mögliche Fehler auflistet, die mit dem ausgewählten Teil verknüpft sind.
  12. Datenaufzeichnungsgerät nach Anspruch 11, bei dem die Datenspeichereinheit einen dazugehörigen Code für jedes Teil und jeden Fehler speichert.
  13. Datenaufzeichnungsgerät nach Anspruch 12, bei dem die Benutzerauswahlvorrichtung eine Ausgabe generiert, die das Teil und den Fehler durch ihre jeweiligen zugeordneten Codes identifiziert.
  14. Datenaufzeichnungsgerät nach Anspruch 1, bei dem die Benutzeroberfläche eine Serie von Listenmenüs erstellen kann, die mit sich auf das Flugzeug beziehenden Optionen aufgefüllt sind, die vom Benutzer ausgewählt werden können.
  15. Verfahren zum Sammeln von Flugdaten von einer Mehrzahl von Benutzern, wobei jeder Benutzer ein eigens zugewiesenes Sicherheitslevel hat, mit folgenden Schritten: Identifizieren eines Benutzers und Ermitteln des dem Benutzer zugewiesenen Sicherheitslevels, Gewinnen mit einem Zyklus eines Flugzeugflugs zusammenhängender Daten vom Benutzer, wobei jeder Dateneintrag ein eigens zugewiesenes Sicherheitslevel hat, wobei der Schritt der Datengewinnung vom Benutzer nur durchgeführt wird, wenn der Benutzer ein Autorisierungslevel hat, das wenigstens dem Autorisierungslevel des Dateneintrags entspricht.
  16. Verfahren zum Sammeln von Flugdaten nach Anspruch 15, ferner mit dem Schritt des Übermittelns eingegebener Flugdaten an eine externe Datenspeichereinheit.
  17. Verfahren zum Sammeln von Flugdaten nach Anspruch 16, bei dem der Schritt des Übermittelns eingegebener Flugdaten an eine externe Datenspeichereinheit die Schritte der Herstellung einer Verbindung zu einem Netzwerk und des Ladens eingegebener Flugdaten in eine Datenspeichereinheit auf einem entfernten Server enthält.
  18. Verfahren zum Sammeln von Flugdaten nach Anspruch 17, bei dem der Schritt des Übermittelns eingegebener Flugdaten an eine externe Datenspeichereinheit das Speichern von Flugdaten auf einem tragbaren Speichergerät enthält.
  19. Verfahren zum Sammeln von Flugdaten nach irgendeinem der Ansprüche 15 bis 18, ferner mit der Option, zuvor von Benutzern eingegebene Daten und/oder erhaltene Daten anzeigen zu lassen.
  20. Verfahren zum Sammeln von Flugdaten nach Anspruch 19, bei dem das Anzeigen von Daten auf Benutzer begrenzbar ist, die das passende Sicherheitslevel zu den anzuzeigenden Daten haben.
  21. Verfahren zum Sammeln von Flugdaten nach irgendeinem der Ansprüche 15 bis 20, bei dem der Schritt des Übermittelns der Daten an eine externe Datenspeichereinheit blockiert werden kann, bis Daten für eine vorgegebene Anzahl von Sektionen eingegeben worden sind.
  22. Verfahren zum Sammeln von Flugdaten nach irgendeinem der Ansprüche 15 bis 21, bei dem die Dateneingabe bezüglich eines nachfolgenden Flugzyklus verhindert wird, bis eingegebene Flugdaten, die mit dem vorherigen Flugzyklus zusammenhängen, an eine externe Datenspeichereinheit oder ein externes Speichergerät übertragen worden sind.
  23. Verfahren zum Sammeln von Flugdaten nach irgendeinem der Ansprüche 15 bis 22, bei dem ferner eine Benutzeroberfläche vorgesehen ist, die eine erste Serie von Listenmenüs aufweist, welche mit Kategorien ausgefüllt werden kann, die Sektionen oder Systeme eines Flugzeuges identifizieren, wobei diese Sektionen oder Systeme von einem Benutzer ausgewählt werden können, und bei dem nach der Auswahl einer Sektion oder eines Systems eines Flugzeuges dem Benutzer ein nachfolgendes Listenmenü angezeigt wird, welches eine Liste von vorher festgelegten Problemen anzeigt, die mit der ausgewählten Sektion oder dem ausgewählten System des Flugzeuges zusammenhängen.
  24. Verfahren zum Sammeln von Flugdaten nach irgendeinem der Ansprüche 15 bis 22, ferner mit einem Verfahren zur Störungsmeldung mit den Schritten der Menügenerierung in einer hierarchischen Serie von Menüs aus einer Datenspeichereinheit, die eine Definition von Flugzeugteilen enthält, wobei jedes Teil der Definition entweder ein Unterteil ist oder eine oder mehrere Unterteile enthält, und, nach Erhalt einer Wahl des Benutzers, des Ausfüllens des generierten Menüs mit einer Teileliste der Definition, die in der Datenspeichereinheit als Unterteile der Benutzerauswahl gespeichert sind.
  25. Verfahren zum Sammeln von Flugdaten nach Anspruch 24, ferner mit dem Schritt des Speicherns von möglichen Fehlern in der Datenspeichereinheit, und des Assoziierens von Fehlern zu Teilen, und wobei nach der durch den Benutzer durchgeführten Auswahl eines Teils von einem Menü, das keine Unterteile in der Datenbank gespeichert hat, ein Menü generiert wird, das eine Liste möglicher Fehler beinhaltet, die mit dem ausgewählten Teil assoziiert worden sind.
  26. Verfahren zum Sammeln von Flugdaten nach Anspruch 25, mit dem Schritt des Assoziierens eines Codes mit jedem Teil und einem möglichen Fehler, wobei durch die Generierung von Daten bezüglich eines Teilefehlers der Teil und der Fehler mittels ihrer jeweiligen Codes erkannt werden.
  27. Verfahren zum Sammeln von Flugdaten nach Anspruch 26, bei dem jedes Teil durch seinen Code plus dem Code des Teiles, von dem es ein Unterteil ist, identifizierbar ist.
  28. Verfahren nach Anspruch 15, ferner mit dem Schritt des Erstellens einer Serie von Listenmenüs mit auf das Flugzeug bezogener Optionen, die von einem Benutzer ausgewählt werden können.
DE60218090T 2001-07-17 2002-07-17 Elektronisches Wartungsverzeichnis und Wartungssystem für ein Luftfahrzeug Expired - Lifetime DE60218090T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
IE20010666 2001-07-17
IE20010666A IES20010666A2 (en) 2001-07-17 2001-07-17 An electronic operations and maintenance log and system for an aircraft

Publications (2)

Publication Number Publication Date
DE60218090D1 DE60218090D1 (de) 2007-03-29
DE60218090T2 true DE60218090T2 (de) 2007-10-25

Family

ID=11042817

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60218090T Expired - Lifetime DE60218090T2 (de) 2001-07-17 2002-07-17 Elektronisches Wartungsverzeichnis und Wartungssystem für ein Luftfahrzeug

Country Status (5)

Country Link
US (1) US6816762B2 (de)
EP (1) EP1280316B1 (de)
AT (1) ATE354240T1 (de)
DE (1) DE60218090T2 (de)
IE (1) IES20010666A2 (de)

Families Citing this family (160)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2827055B1 (fr) * 2001-07-05 2005-02-04 Airbus Ind Procede pour struturer et gerer la configuration de produits industriels, notamment d'avions
JP2003044333A (ja) * 2001-08-01 2003-02-14 Fujitsu Ltd ディレクトリ管理方法およびプログラム，装置，記憶媒体
US7564375B2 (en) * 2001-09-11 2009-07-21 Zonar Systems, Inc. System and method to associate geographical position data collected from a vehicle with a specific route
US8400296B2 (en) * 2001-09-11 2013-03-19 Zonar Systems, Inc. Method and apparatus to automate data collection during a mandatory inspection
US7557696B2 (en) * 2001-09-11 2009-07-07 Zonar Systems, Inc. System and process to record inspection compliance data
US8972179B2 (en) 2006-06-20 2015-03-03 Brett Brinton Method and apparatus to analyze GPS data to determine if a vehicle has adhered to a predetermined route
US20110068954A1 (en) 2006-06-20 2011-03-24 Zonar Systems, Inc. Method and apparatus to collect object identification data during operation of a vehicle and analysis of such data
US6671646B2 (en) 2001-09-11 2003-12-30 Zonar Compliance Systems, Llc System and process to ensure performance of mandated safety and maintenance inspections
US11341853B2 (en) 2001-09-11 2022-05-24 Zonar Systems, Inc. System and method to enhance the utility of vehicle inspection records by including route identification data in each vehicle inspection record
US20150170521A1 (en) 2001-09-11 2015-06-18 Zonar Systems, Inc. System and method to enhance the utility of vehicle inspection records by including route identification data in each vehicle inspection record
US7680595B2 (en) 2006-06-20 2010-03-16 Zonar Systems, Inc. Method and apparatus to utilize GPS data to replace route planning software
US10185455B2 (en) 2012-10-04 2019-01-22 Zonar Systems, Inc. Mobile computing device for fleet telematics
US20050256681A1 (en) * 2001-09-11 2005-11-17 Brinton Brett A Metering device and process to record engine hour data
US8810385B2 (en) 2001-09-11 2014-08-19 Zonar Systems, Inc. System and method to improve the efficiency of vehicle inspections by enabling remote actuation of vehicle components
US9563869B2 (en) 2010-09-14 2017-02-07 Zonar Systems, Inc. Automatic incorporation of vehicle data into documents captured at a vehicle using a mobile computing device
US6992596B2 (en) * 2002-04-04 2006-01-31 Megadata Simplified flight track display system
US7904081B2 (en) 2002-08-20 2011-03-08 Arinc Incorporated ACARS messages over iridium
US7398057B2 (en) * 2002-08-20 2008-07-08 Arinc Inc. Security messenger system
US6915189B2 (en) * 2002-10-17 2005-07-05 Teledyne Technologies Incorporated Aircraft avionics maintenance diagnostics data download transmission system
US8068519B2 (en) * 2002-12-20 2011-11-29 Britesmart Llc Method and system to use, share and manage digital content by assigning MAC and IP adress to each device and peripheral
US20040172314A1 (en) * 2003-02-28 2004-09-02 Ajay Patel Engine induction booking system
US8010282B2 (en) * 2003-05-28 2011-08-30 Passur Aerospace, Inc. System and method to display operational and revenue data for an airport facility
US7668744B2 (en) * 2003-07-31 2010-02-23 The Boeing Company Method and system for conducting fleet operations
AT412379B (de) * 2003-08-04 2005-01-25 Johannes Ing Hainzl Verfahren zum verwalten von arbeitsvorgängen
US6940426B1 (en) * 2003-09-05 2005-09-06 Ridgeback Systems Llc Aircraft flight risk measuring system and method of operation
US7251550B2 (en) 2003-10-01 2007-07-31 Honeywell International Inc. Aircraft accessory monitor
CA2445220C (en) * 2003-10-10 2009-03-17 Nav Canada Air traffic information display system
GB2409299B (en) * 2003-12-18 2007-11-07 Ibm A system for preparing data
US7376495B2 (en) * 2004-01-20 2008-05-20 Varec, Inc. Fuel information messaging system
US7463971B2 (en) * 2004-01-20 2008-12-09 Varec, Inc. Wireless data collection unit for fuel management system
US7584420B2 (en) * 2004-02-12 2009-09-01 Lockheed Martin Corporation Graphical authoring and editing of mark-up language sequences
US20050240555A1 (en) * 2004-02-12 2005-10-27 Lockheed Martin Corporation Interactive electronic technical manual system integrated with the system under test
US7801702B2 (en) * 2004-02-12 2010-09-21 Lockheed Martin Corporation Enhanced diagnostic fault detection and isolation
US20050223288A1 (en) * 2004-02-12 2005-10-06 Lockheed Martin Corporation Diagnostic fault detection and isolation
US8417590B2 (en) * 2004-03-26 2013-04-09 Jet X Aerospace, Llc Method of maintaining aircraft
US20050289447A1 (en) * 2004-06-29 2005-12-29 The Boeing Company Systems and methods for generating and storing referential links in a database
DE102004036269A1 (de) * 2004-07-26 2006-04-13 Ripp, Otmar Automatisches Verfahren zur elektronischen Flugdatenerfassung, zur nachfolgenden Weiterverarbeitung in einer Unternehmens DV für Abrechnung und Flugbuchführung
US20060059169A1 (en) * 2004-08-13 2006-03-16 Sergey Armishev Method and system for extensible automated data testing using scriptlets
FR2875357B1 (fr) * 2004-09-13 2008-04-18 Stephane Pomies Systeme de gestion et de mise en relation de machines avec des utilisateurs, ou autres machines, distants
US20060120181A1 (en) * 2004-10-05 2006-06-08 Lockheed Martin Corp. Fault detection and isolation with analysis of built-in-test results
US20060085692A1 (en) * 2004-10-06 2006-04-20 Lockheed Martin Corp. Bus fault detection and isolation
US20080052281A1 (en) * 2006-08-23 2008-02-28 Lockheed Martin Corporation Database insertion and retrieval system and method
US8244412B2 (en) * 2005-02-25 2012-08-14 The Boeing Company System and methods for on-board pre-flight aircraft dispatching
US20060235741A1 (en) * 2005-04-18 2006-10-19 Dataforensics, Llc Systems and methods for monitoring and reporting
US7427025B2 (en) * 2005-07-08 2008-09-23 Lockheed Marlin Corp. Automated postal voting system and method
US8732233B2 (en) * 2005-07-13 2014-05-20 The Boeing Company Integrating portable electronic devices with electronic flight bag systems installed in aircraft
US7403844B2 (en) 2005-08-31 2008-07-22 Invacare Corporation Method and apparatus for programming parameters of a power driven wheelchair for a plurality of drive settings
WO2007027846A2 (en) * 2005-08-31 2007-03-08 Invacare Corporation Method and apparatus for automated positioning of user support surfaces in power driven wheelchair
US20070106549A1 (en) * 2005-11-04 2007-05-10 Stocking Christine A Turnkey aviation budget management
US7689329B2 (en) * 2005-11-16 2010-03-30 The Boeing Company Integrated maintenance and materials services for fleet aircraft using aircraft data to improve quality of materials
US20070112576A1 (en) 2005-11-16 2007-05-17 Avery Robert L Centralized management of maintenance and materials for commercial aircraft fleets with fleet-wide benchmarking data
US7548802B2 (en) * 2005-11-16 2009-06-16 The Boeing Company Centralized management of maintenance and materials for commercial aircraft fleets
US7761200B2 (en) * 2005-11-16 2010-07-20 The Boeing Company Centralized management of maintenance and materials for commercial aircraft fleets with access to real-time information
US7761201B2 (en) * 2005-11-16 2010-07-20 The Boeing Company Integrated maintenance and materials services for fleet aircraft using aircraft data to improve maintenance quality
US10248914B2 (en) * 2005-11-29 2019-04-02 The Boeing Company Sustaining a fleet of configuration-controlled assets
CA2631763A1 (en) * 2005-12-01 2007-06-07 Firestar Software, Inc. System and method for exchanging information among exchange applications
US20070156496A1 (en) * 2005-12-02 2007-07-05 Avery Robert L Methods and systems for managing aircraft maintenance and material supply
US7769499B2 (en) * 2006-04-05 2010-08-03 Zonar Systems Inc. Generating a numerical ranking of driver performance based on a plurality of metrics
FR2900008B1 (fr) * 2006-04-18 2008-05-30 Airbus France Sas Procede et dispositif de communication sur une liaison de communication entre un aeronef et une station sol
US8723645B2 (en) * 2006-06-09 2014-05-13 The Boeing Company Data synchronization and integrity for intermittently connected sensors
US7957853B2 (en) * 2006-06-13 2011-06-07 The Mitre Corporation Flight restriction zone detection and avoidance
US9230437B2 (en) 2006-06-20 2016-01-05 Zonar Systems, Inc. Method and apparatus to encode fuel use data with GPS data and to analyze such data
US10056008B1 (en) 2006-06-20 2018-08-21 Zonar Systems, Inc. Using telematics data including position data and vehicle analytics to train drivers to improve efficiency of vehicle use
US20130164713A1 (en) 2011-12-23 2013-06-27 Zonar Systems, Inc. Method and apparatus for gps based slope determination, real-time vehicle mass determination, and vehicle efficiency analysis
US20130164715A1 (en) 2011-12-24 2013-06-27 Zonar Systems, Inc. Using social networking to improve driver performance based on industry sharing of driver performance data
US20080010107A1 (en) * 2006-07-10 2008-01-10 Small Gregory J Methods and systems for providing a global view of airline operations
US7747382B2 (en) * 2006-07-10 2010-06-29 The Boeing Company Methods and systems for real-time enhanced situational awareness
US20080046167A1 (en) * 2006-07-10 2008-02-21 Small Gregory J Methods and systems for providing a resource management view for airline operations
US7765476B2 (en) * 2006-08-28 2010-07-27 Hamilton Sundstrand Corporation Flexible workflow tool including multi-lingual support
US8055526B2 (en) * 2006-09-08 2011-11-08 Varec, Inc. Method for the automated dispatch of fueling operations
US20080126352A1 (en) * 2006-09-27 2008-05-29 Rockwell Automation Technologies, Inc. Client side state cache for industrial control systems
US7962748B2 (en) * 2006-10-04 2011-06-14 The Boeing Company Methods and systems for securing a computer network
US20080114507A1 (en) * 2006-11-10 2008-05-15 Ruth Robert S System and method for situational control of mobile platform maintenance and operation
US8156536B2 (en) * 2006-12-01 2012-04-10 Cisco Technology, Inc. Establishing secure communication sessions in a communication network
US9037317B2 (en) * 2006-12-21 2015-05-19 The Boeing Company System and method for automatic dependent surveillance collection and analysis
FR2912578B1 (fr) * 2007-02-13 2009-05-22 Airbus France Sas Methode d'authentification d'un document electronique et methode de verification d'un document ainsi authentifie.
US20080222179A1 (en) * 2007-03-11 2008-09-11 The Boeing Company Apparatus and method for sharing and reuse of structured knowledge artifacts
FR2916068B1 (fr) * 2007-05-10 2009-11-20 Airbus France Systeme de gestion des droits d'acces a des applications et des donnees avioniques et procede mis en oeuvre par ce systeme
US8082277B1 (en) * 2007-06-05 2011-12-20 The Board of Trustees of the University of Alabama, for and on behalf of the University of Alabamaiin Huntsville Systems and methods for generating technical documents
FR2917201B1 (fr) * 2007-06-05 2009-09-25 Airbus France Sa Procede et dispositif de gestion,de traitement et de controle de parametres utilises a bord d'aeronefs
US8442751B2 (en) * 2007-11-27 2013-05-14 The Boeing Company Onboard electronic distribution system
US8185609B2 (en) * 2007-11-27 2012-05-22 The Boeing Company Method and apparatus for processing commands in an aircraft network
US20090138873A1 (en) * 2007-11-27 2009-05-28 The Boeing Company Method and Apparatus for Loadable Aircraft Software Parts Distribution
US8490074B2 (en) * 2007-11-27 2013-07-16 The Boeing Company Aircraft software part library
US8930310B2 (en) * 2007-11-27 2015-01-06 The Boeing Company Proxy server for distributing aircraft software parts
US20090138874A1 (en) * 2007-11-27 2009-05-28 The Boeing Company Software Maintenance Tool
US8165930B2 (en) * 2007-11-27 2012-04-24 The Boeing Company Crate tool
SG194376A1 (en) * 2007-11-27 2013-11-29 Boeing Co Method and apparatus for loadable software airplane parts (lsap) distribution
US9208308B2 (en) * 2007-11-27 2015-12-08 The Boeing Company Alternate parts signature list file
US8571747B2 (en) * 2007-12-06 2013-10-29 The Boeing Company System and method for managing aircraft maintenance
US8548879B2 (en) * 2007-12-14 2013-10-01 The Boeing Company Materials management system
US8090462B2 (en) * 2007-12-19 2012-01-03 Mobideo Technologies Ltd Maintenance assistance and control system method and apparatus
US8204802B2 (en) * 2007-12-20 2012-06-19 United Parcel Service Of America, Inc. Fuel accounting system and methods
US8321083B2 (en) * 2008-01-30 2012-11-27 The Boeing Company Aircraft maintenance laptop
US20090254403A1 (en) * 2008-04-07 2009-10-08 Sinex Aviation Technologies Line maintenance manager
US9172709B2 (en) 2008-06-24 2015-10-27 Raytheon Company Secure network portal
US20100005179A1 (en) * 2008-07-03 2010-01-07 Raytheon Company Multi-Level Secure Network
US8359357B2 (en) 2008-07-21 2013-01-22 Raytheon Company Secure E-mail messaging system
FR2935512B1 (fr) * 2008-08-26 2011-03-25 Airbus France Dispositif de communication entre le personnel navigant commercial d'un aeronef et le sol et procede mettant en oeuvre ce dispositif
FR2935573B1 (fr) * 2008-09-03 2010-09-17 Airbus France Procede de communication d'une signature numerique pour certifier une transmission, systeme et aeronef associes.
US8195535B2 (en) * 2008-10-22 2012-06-05 Sinex Aviation Technologies Aircraft MRO manager
US8359641B2 (en) 2008-12-05 2013-01-22 Raytheon Company Multi-level secure information retrieval system
US8209638B2 (en) * 2008-12-31 2012-06-26 Sap Ag Customization abstraction
US9652899B2 (en) * 2009-04-09 2017-05-16 Honeywell International Inc. Methods, apparatus and systems for accessing vehicle operational data using an intelligent network router
DE102009018772B4 (de) 2009-04-24 2011-02-17 Airbus Operations Gmbh Verfahren und System zum Sammeln von Zustandsinformationen von Bauteilen in einer Passagierkabine eines Fahrzeugs
US8271709B2 (en) * 2009-05-11 2012-09-18 Honeywell International Inc. Bus protocol for control of communications between two computers
US8706323B2 (en) * 2009-05-15 2014-04-22 The Boeing Company Aircraft dispatch information
US8849690B1 (en) * 2009-06-24 2014-09-30 American Airlines, Inc. Optimized bill of work for aircraft maintenance based on task prioritization and time slot proximity analysis
US8306689B2 (en) * 2009-08-11 2012-11-06 The United States Of America As Represented By The Secretary Of The Navy Integrated net-centric diagnostics dataflow for avionics systems
US8495722B1 (en) * 2009-09-25 2013-07-23 Rockwell Collins, Inc. Method and system for controlling access to an aircraft-based wireless network
FR2952258B1 (fr) * 2009-11-05 2011-11-11 Airbus Procede et dispositif pour acceder a des fonctions de maintenance d'un aeronef a partir d'un terminal mobile de maintenance
WO2011128833A2 (en) 2010-04-12 2011-10-20 Flight Focus Pte. Ltd. Sms communication to and from messaging devices in an aircraft
US8811616B2 (en) 2010-04-12 2014-08-19 Flight Focus Pte. Ltd. Secure aircraft data channel communication for aircraft operations
US8359542B2 (en) 2010-08-13 2013-01-22 Lockheed Martin Corporation Machines, program products, and computer-implemented methods for interactive aircraft performance substantiation
US10102687B1 (en) 2010-08-17 2018-10-16 The Boeing Company Information management system for ground vehicles
DE102010035374A1 (de) 2010-08-25 2012-03-01 Airbus Operations Gmbh System und Verfahren zum Sammeln von Defektdaten von Bauteilen in einer Passagierkabine eines Fahrzeugs
US10665040B2 (en) 2010-08-27 2020-05-26 Zonar Systems, Inc. Method and apparatus for remote vehicle diagnosis
US20120136743A1 (en) * 2010-11-30 2012-05-31 Zonar Systems, Inc. System and method for obtaining competitive pricing for vehicle services
US10600096B2 (en) 2010-11-30 2020-03-24 Zonar Systems, Inc. System and method for obtaining competitive pricing for vehicle services
US9527515B2 (en) 2011-12-23 2016-12-27 Zonar Systems, Inc. Vehicle performance based on analysis of drive data
US10706647B2 (en) 2010-12-02 2020-07-07 Zonar Systems, Inc. Method and apparatus for implementing a vehicle inspection waiver program
US10431020B2 (en) 2010-12-02 2019-10-01 Zonar Systems, Inc. Method and apparatus for implementing a vehicle inspection waiver program
US8736419B2 (en) 2010-12-02 2014-05-27 Zonar Systems Method and apparatus for implementing a vehicle inspection waiver program
US9041548B2 (en) 2010-12-30 2015-05-26 Qt Technologies Battery-powered fuel data collection unit
US8666586B2 (en) 2010-12-30 2014-03-04 Qt Technologies Enterprise fuel management system
WO2012115705A1 (en) 2011-02-25 2012-08-30 Qt Technologies Fuel data collection unit with temperature compensation and over-fill prevention
US9845734B2 (en) 2011-04-20 2017-12-19 Honeywell International Inc. Air turbine start system with monopole starter air valve position
US20120290486A1 (en) * 2011-05-09 2012-11-15 Dobrowolski John M Automated method and system for interactive compulsory reporting of lease application adjudication decisions, ongoing tenancy histories and debtor collections
BE1019979A5 (nl) 2011-05-17 2013-03-05 Aviovision Gegevensselectie voor transportsector.
US10748092B2 (en) 2011-06-07 2020-08-18 The Boeing Company Systems and methods for creating intuitive context for analysis data
GB201117278D0 (en) * 2011-10-06 2011-11-16 Fuel Matrix Ltd Method and system
US10061745B2 (en) 2012-04-01 2018-08-28 Zonar Sytems, Inc. Method and apparatus for matching vehicle ECU programming to current vehicle operating conditions
US9659336B2 (en) 2012-04-10 2017-05-23 Bags, Inc. Mobile baggage dispatch system and method
FR2990529B1 (fr) 2012-05-11 2021-09-10 Thales Sa Procede et dispositif de capture du besoin pour un systeme de maintenance centralisee pour aeronef
US9334063B2 (en) * 2012-09-10 2016-05-10 Rosemount Aerospace, Inc. Aircraft avionics tablet interface module
US9424696B2 (en) 2012-10-04 2016-08-23 Zonar Systems, Inc. Virtual trainer for in vehicle driver coaching and to collect metrics to improve driver performance
WO2014122445A1 (en) * 2013-02-08 2014-08-14 Bae Systems Plc A data processing method and apparatus
US9336248B2 (en) * 2013-04-24 2016-05-10 The Boeing Company Anomaly detection in chain-of-custody information
US9237022B2 (en) 2013-05-07 2016-01-12 The Boeing Company Use of multiple digital signatures and quorum rules to verify aircraft information
US9160543B2 (en) 2013-05-07 2015-10-13 The Boeing Company Verification of aircraft information in response to compromised digital certificate
ITBO20130218A1 (it) * 2013-05-10 2014-11-11 Remorides S R L Sistema automatizzato e metodo per la gestione della manutenzione di attrazioni per parchi di divertimento o similari
US9694903B2 (en) 2013-06-27 2017-07-04 Airbus Operations (Sas) Secure aircraft-based mobile device connectivity systems and methods
US8930068B1 (en) * 2013-07-15 2015-01-06 American Airlines, Inc. System and method for managing instances of damage within a transportation system
US20150051756A1 (en) * 2013-08-14 2015-02-19 The Boeing Company Aircraft System Control and Reporting via a Mobile Device
US9446860B2 (en) 2013-10-04 2016-09-20 Airbus Operations (Sas) Aircraft part and subassembly damage reporting method, system and mobile computer software application
US11030559B2 (en) * 2014-02-14 2021-06-08 Borealis Technical Limited Method for maintaining a supply of available aircraft equipped with non-engine drive means for use by airlines
US9916701B2 (en) * 2014-09-10 2018-03-13 The Boeing Company Vehicle auditing and control of maintenance and diagnosis for vehicle systems
US9660719B2 (en) 2014-11-17 2017-05-23 Honeywell International Inc. Minimizing propagation times of queued-up datalink TPDUs
US9998360B2 (en) * 2014-11-17 2018-06-12 Honeywell International Inc. Minimizining message propagation times when brief datalink interruptions occur
BE1023406B1 (fr) * 2016-01-21 2017-03-09 Safran Aero Boosters S.A. Turbomachine d'aéronef
US20170213196A1 (en) * 2016-01-27 2017-07-27 Power Werks, Inc. Method and apparatus for selection of aircraft parts
FR3050555B1 (fr) * 2016-04-21 2019-09-27 Thales Procede de traitement d'un fichier de mise a jour d'un equipement avionique d'un aeronef, produit programme d'ordinateur, dispositif electronique de traitement et systeme de traitement associes
US10936618B2 (en) * 2016-11-08 2021-03-02 General Electric Company Systems and methods for managing aviation records
US10297162B2 (en) * 2016-12-28 2019-05-21 Honeywell International Inc. System and method to activate avionics functions remotely
US10097615B1 (en) * 2017-06-13 2018-10-09 Kitty Hawk Corporation Method for vehicle data collection
US10564637B2 (en) 2017-10-05 2020-02-18 Honeywell International Inc. Wireless e-signoff system
US11030828B2 (en) 2018-03-22 2021-06-08 Honeywell International Inc. System and method to auto create aircraft maintenance records by aircraft data
US11579948B2 (en) * 2019-03-12 2023-02-14 The Boeing Company Application programming interface for web page and visualization generation
CN114239012B (zh) * 2021-12-15 2024-07-12 成都飞机工业（集团）有限责任公司 一种适用于caa二次开发软件的rsa离线加密技术
FR3131999B1 (fr) * 2022-01-18 2023-12-29 Globalsys Procédé de sécurisation d’une communication radio entre un aéronef et un agent de piste

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5931877A (en) * 1996-05-30 1999-08-03 Raytheon Company Advanced maintenance system for aircraft and military weapons
US5890079A (en) 1996-12-17 1999-03-30 Levine; Seymour Remote aircraft flight recorder and advisory system
US6003808A (en) 1997-07-11 1999-12-21 Pratt & Whitney Canada Inc. Maintenance and warranty control system for aircraft
US6225890B1 (en) * 1998-03-20 2001-05-01 Trimble Navigation Limited Vehicle use control
US6278913B1 (en) 1999-03-12 2001-08-21 Mil-Com Technologies Pte Ltd. Automated flight data management system
US6243628B1 (en) 1999-09-07 2001-06-05 General Electric Company System and method for predicting impending failures in a locomotive
US6606544B2 (en) 2001-05-01 2003-08-12 Glenn, Iii Floyd A. Electronic flight kit and method

Also Published As

Publication number Publication date
DE60218090D1 (de) 2007-03-29
EP1280316A2 (de) 2003-01-29
ATE354240T1 (de) 2007-03-15
US20030109973A1 (en) 2003-06-12
EP1280316B1 (de) 2007-02-14
EP1280316A3 (de) 2003-10-15
US6816762B2 (en) 2004-11-09
IES20010666A2 (en) 2002-11-13

Similar Documents

Publication Publication Date Title
DE60218090T2 (de) Elektronisches Wartungsverzeichnis und Wartungssystem für ein Luftfahrzeug
US20200184548A1 (en) Systems and methods for leasing equipment or facilities using blockchain technology
US7636568B2 (en) Remote aircraft manufacturing, monitoring, maintenance and management system
US10275952B2 (en) System for automated recording of aircraft flight and maintenance information and associated methods
KR20190109542A (ko) 항공우주 상거래 교환소
DE202014002582U1 (de) Computergerät zur Verwendung während des Fluges für eine Flugzeugkabinenbesatzung
Fielding et al. The National Transportation Safety Board: A model for systemic risk management
EP2820816B1 (de) Authentifizierungsverfahren für einen passagier und korrespondierende software
US8306685B2 (en) Electronic logbook flight preparation system and method
US20090265393A1 (en) System and method for synchronizing databases
EP1358585A1 (de) Logbuch-datenbanksystem
DE112021003971T5 (de) Nachhaltige token für eine lieferkette mit datenschutzerhaltendem protokoll
WO2007089307A2 (en) Turnkey aviation budget management
Munene An application of the HFACS method to aviation accidents in Africa
US20070156785A1 (en) Method and system for revising manuals
DE112017007948T5 (de) System und Verfahren zur Verwaltung des Betriebs eines kommerziellen Transportfahrzeugs
US20030120501A1 (en) Storage and updating of electronic documents in aircraft
Gartz Commercial systems development in a changed world
US20070225990A1 (en) Custody calculation system
Vance et al. Autonomous airliners anytime soon?
Ateş Electronic flight bag in the operation of airline companies: Application in Turkey
Cronkhite et al. Operational evaluation of a health and usage monitoring system (HUMS)
Vetter et al. Enterprise architecting applied to small unmanned aircraft system integration into low-altitude urban airspace
CN114841786B (zh) 远程辅导巡查方法及系统、存储介质、电子装置
Tsuruta The analysis of flight operational quality assurance (FOQA) data: exploration of a proposed list of improved safety parameters

Legal Events

Date Code Title Description
8364 No opposition during term of opposition