EIN TRIEBWERKSDIAGNOSESYSTEM MIT REPRÄSENTATION DER KOMPONENTEN

ALS ZELLULARES NETZWERK

R.Lo*), J.Leppich*), W.Landvogt**)

*) Technische Universität Berlin, Institut für Luft- und Raumfahrt, Vortrag am DGLR RF-Kongress in Mün-
chen, 17.Okt.1997
**) ehem. Fraunhofer-Institut für Produktionssysteme und Entwurfstechnologie (IPK), Berlin

Abstract:
In diesem Vortrag wird auf ein computergestütztes Diagnosesystem eingegangen, dessen Konzept zur Anwendung in
einem fortschrittlichem, wiederverwendbaren europäischen Raketentriebwerk im Rahmen des internationalen ESA
FESTIP Technologieforschungsprogramms entwickelt wurde. Darüber hinaus wird auf eine Erweiterung eingegangen,
welche nach der Fertigstellung des FESTIP Anteils als Resultat eines Kooperationsprojektes mit der Moskauer Techni-
schen Universität „Bauman“ von russischen Wissenschaftlern entwickelt wurde.
Die meisten Betreiber von Raumtransportsystemen setzen heute Triebwerksdiagnosesysteme unterschiedlicher Kom-
plexität ein. Die diagnostische Auswertung wird dabei Off-Line von menschlichen Experten durchgeführt. Als Konse-
quenz hat die viel billigere und dem Zweck mehr entsprechende, bedarfsorientierte Wartung die routinemäßige bereits
zu einem gewissen Grade ersetzt. Allgemeine Übereinstimmung herrscht darüber, daß Wissensbasierte Systeme (WBS)
und künstliche Intelligenz (KI) hier ein großes Potential für weitere Verbesserungen darstellen.
Die im vorliegenden Fall angewendeten Strategien spielen sich auf drei Ebenen ab: einer Signalverarbeitungsebene,
einer Repräsentationsebene für den Triebwerksstatus und als höchstes auf einer dritten Ebene, in welcher Wartungs-
und Reparaturarbeiten empfohlen werden.
Auf unterster Ebene wurden unter Berücksichtigung der Anforderungen verschiedener Triebwerkskomponenten Inter-
faces für diagnostische Hardware und die zugehörige Signalverarbeitungssoftware definiert. Das System funktioniert,
indem es den Informationsoutput operationeller Agenten sammelt und kombiniert. Der Zustand von Komponenten und
Submodulen wird erfasst und führt schließlich zu einer Bewertung des Zustandes des ganzen Triebwerks.
Auf mittlerer Ebene werden Prozessdaten mit Fehlersymptomen und Versagens zuständen des Triebwerks und seiner
Komponenten korreliert. Als Resultat wird eine kompilierte Beschreibung des Zustandes erhalten.
Auf Systemebene wurde eine regelbasierte Architektur definiert, die Entscheidungen über die weitere Verwendbarkeit
von Komponenten trifft und Vorschriften für deren Wartung und Reparatur generiert. Insgesamt entsteht so eine Folge
von Maßnahmen, die darauf abzielen, das Triebwerk sicher in die nächste Anwendung einzubringen. Somit ist ein Moni-
toring, Diagnose und Wartungs- Plan (MDW) für das Triebwerk das Produkt der höchsten Ebene des WBS.
Die Integration externer Datenbasen mit antriebsspezifischer Information wurde ebenfalls untersucht und in den Grund-
zügen definiert. Auf einen für diese Zwecke besonders attraktiven Formalismus wird näher eingegangen, nämlich ein
zellulares Netzwerk der Raketentriebwerkskomponenten. In einem solchen Netzwerk werden alle Komponenten funktio-
nell zu Subsystemen verknüpft. Alle Komponenten haben topologisch korrekte Schnittstellen mit den Komponenten des
gleichen oder anderer Subsysteme. Über die Schnittstellen werden folgende Ströme ausgetauscht: statische und dyna-
mische Kräfte (im mechanischen oder strukturellen Interface), Vibrationen (dynamisches Interface), Massen (Strömungs-
oder fluiddynamisches Interface), Energie (Wärmestrom- oder thermodynamisches Interface, wobei mechanische Ener-
gie durch Kräfte repräsentiert wird) und Informationen (Kommando- und sensorisches Interface). Die externe System-
grenze des Triebwerks bildet eine weitere Schnittstelle mit der Umgebung des Triebwerks. Die Summe aller Wechsel-
wirkungen unter den Komponenten eines Subsystems mit jenen eines anderen definiert den Input und Output des Sub-
systems, welches die betreffenden Komponenten konstituieren.
Eine regelbasierte Expertise menschlichen Ingenieurwissens bildet das allem zugrundeliegende Softwaremodell. Im
gegenwärtigen Entwicklungsstand beschränkt sich dieses auf einen Beispielfall auf Subsystemebene (Health monitoring
einer Raketenturbopumpe). Die Parameter verschiedener Antriebssysteme sind in einer Datenbasis verfügbar, die das
Modell eines Prototyps für eine externe Datenbasis bildet. Im Rahmen der Kooperation mit der Moskauer TU-"Bauman"
war es möglich, hier einen wichtigen Schritt weiter zu kommen. Auf neueste Ergebnisse der Modellierung von Raketen-
turbinen und Turbopumpen wird eingegangen, wie sie als Ergänzung und Erweiterung dieser Untersuchungen erarbeitet
wurden.

1EINFÜHRUNG
Ziel dieser Arbeit ist die Definition eines Modells für ein computergestütztes Managementkonzept zur Sta-
tusdiagnose und Wartung von wiederverwendbaren Raketentriebwerken. Das System soll nach dem Flug
des jeweiligen Triebwerks zum Einsatz kommen. Wann immer sich im Lebenszyklus des Triebwerks diag-
nostische Anforderungen ergeben, also bei Bodentests oder während der Mission, werden Sensordaten, die

1
während der Brennzeiten des Triebwerks aufgezeichnet wurden, in das wissensbasierte Wartungs- und Di-
agnose Management System (WDMS) integriert und ausgewertet.
Die im Rahmen des ESA-FESTIP Technologieprogramms durchgeführte Studie umfasste im ersten Teil eine
intensive Auswertung der Literatur zu Diagnosemodulen für Raketen und Luftfahrttriebwerke. Als Ergebnis
dieser Arbeiten wurde vorgeschlagen die Entwicklungen für das SSME als Richtungsweiser für zukünftige
Arbeiten heranzuziehen. Im zweiten Teil wurden Kataloge von Diagnoseaufgaben bei Antriebssystemen,
zugehörige Diagnoseprozeduren, notwendige Triebwerksüberwachung, Diagnosegeräte und computerge-
stützte Datenanalysemethoden definiert und zusammengestellt. Auf Basis dieser Arbeiten wurde drittens
eine Diagnosearchitektur entworfen und in ein Referenzmodell eines regelbasierten Diagnosesystems inte-
griert.

MD R operations for a
re-usable rocket engine

s chedul ed diagnos tic refurbi shment mis s ion component des ign
maintenance monitoring
operations s ervices equi ppi ng modificati ons
(health ass es sment)

high pres sure turbo pump
. torque checks
. turbine blade inspect ion
. seal leakage check
low pres sure pumps
. torque checks
heat exchanger s ystem
. leakage t es t
. vi sual inspection
combustion chamber drying of H P TP bearing fueli ng
temperatures
drying of nozzle and charging
on request of pump discharge pres sure pipes
results of arming
monitoring and propel lant flow s
function testi ng
turbine shaft s peed
turbo pump vibrati ons

press ure chamber

. vi sual inspection
. drying

propel lant duct s/manifolds

. leakage check

val ves
. hydraulic and pneumatic
tes ts groundoperations in-flight operations
test firing

Bild 1: Monitoring, Diagnose und Refurbishment Operations eines wiederverwendbaren Raketentriebwerks

(Bild: NASA).

2 ÜBERWACHUNGS- UND DIAGNOSETECHNIKEN FÜR RAKETEN- UND

FLUGZEUGTRIEBWERKE
Die Mehrheit der Luftfahrtgesellschaften und nahezu alle großen Anbieter von Raketenstarts nutzen die
Triebwerksüberwachung in unterschiedlicher Komplexität. In beiden Fällen (Luftfahrt und Raumfahrt) wird
die Triebwerksdiagnose "off-line" von menschlichen Experten durchgeführt. Die Überholung der Triebwerke
wird in der Luftfahrt überwiegend nicht mehr nach einem festgelegten Plan (on-schedule) sondern nach Zu-
stand (on-condition) des Triebwerks vorgenommen. In der Raumfahrt wird dies bis zu einem gewissen Grad
nur beim Space Shuttle Haupttriebwerk (SSME) so gehandhabt. Bild 1 zeigt eine Darstellung der im Betrieb
des SSME periodisch durchgeführten Monitoring, Diagnose und Refurbishment Arbeiten:
Planmäßige Wartung / Diagnose von Überwachungsergebnissen / Überwachung (mit Aufzeichnung) / War-
tungsarbeiten / Missionsvorbereitung / Anpassung von Komponenten
Die zwei wichtigsten Konzepte für KI Anwendungen bei solchen Betriebsmaßnahmen sind:
zustandsabhängige Instandhaltung (state-controlled refurbishment)
Ausfallvorhersage (life-prediction).
Anwendungen von KI und WBS im Bereich der Antriebe hinken hinter dem Grad der Anwendung in anderen
Bereichen her (z.B. beim ferngesteuerten Betrieb von Raumfahrzeugen, wo Expertensysteme bereits zum
Stand der Technik gehöre. Man kann aber mit einiger Sicherheit annehmen, daß künstliche Intelligenz mit
steigendem Intelligenzgrad beim Betrieb des SSME und bei zukünftigen Raketentriebwerken eingesetzt
werden wird.

2
2.1 Übersicht der in Gebrauch befindlichen Methoden
Luftfahrtantriebe
Die Aufzeichnungen und Dokumente beginnen mit der Einführung der Triebwerksleistungsüberwachung
mittels manuell aufgezeichneter Daten von Boroskopie- und Röntgenuntersuchungen in den USA 1972 bei
der Fluggesellschaft EASTERN AIRLINES. In Europa folgte die LUFTHANSA 1976 mit systematischer
Überwachung des Triebwerkszustands. Das erste wissensbasierte System über das berichtet wird, ist ein
verteiltes lernfähiges Roboterexpertensystem, das von der Illinois Universität bis 1982 entwickelt wurde.
1987 führten die Firmen Textron und Avco Lycoming unter dem Namen TEXMAS ein Diagnosesystem
(diagnostic reasoner) für Gasturbinentriebwerke ein. Zur gleichen Zeit wenden in Europa die Programme zur
Triebwerksüberwachung von Airbus und ATR wissensbasierte Systeme noch nicht an. Kurze Zeit später
starteten die USA eine Serie experimenteller Programme zur Analyse und Auswertung von Daten von
Triebwerksüberwachungssystemen. Im Rahmen dieser Programme sollten Fehlerbeseitigungswerkzeuge für
Experten sowie Unterstützungssoftware für Wartungstechniker entwickelt werden. Das NASA Forschungs-
zentrum in Langley blickt auf eine lange Geschichte in diesem Bereich zurück. Im Jahre 1989 gab es das
"Langley Restructurable control tool" ein onboard überwachungs- und Diagnosesystem. 1993 wurde ihr "Ca-
se-based Reasoner CBR" als fallbasierter Ansatz zur Behandlung von Flugzeugfehlfunktionen veröffentlicht.
Im selben Jahr wurde in den USA das System "IFES" als ein flugtaugliches Expertensystem zu Diagnose-
zwecken im Großmaßstab angekündigt. Ähnliche Aktivitäten gab es auch in Kanada, Australien, Japan und
sogar in China. Europäische Aktivitäten blieben nur sporadisch. Da gab es das von Rolls-Royce entwickelte
"Condition Monitoring and Performance Analysis Software System COMPASS" und in Deutschland muss
man Studien an der RWTH Aachen im Bereich der Turbotriebwerksdiagnose (EXTEND) erwähnen.

Systeme und Konzepte für das SSME

Zahlreiche wissensbasierten Systeme sind für das SSME in Vorbereitung, aber zur Zeit ist noch keines in
der routinemäßigen Anwendung. Benutzt werden sogenannte "Red Line" Systeme (z.B. "FASCOS") bei
denen das Überschreiten eines bestimmten Grenzwertes bei ausgewählten Schlüsselparametern zum Ab-
schalten des Triebwerks führt. Dieses System befindet sich in einem kontinuierlichen Verbesserungsprozess
um die Verlässlichkeit zu steigern.
Bei Aerojet-General Corp. und an der Universität von Alabama wurde ein post-Test Diagnosesystem PTDS
entwickelt, welches verschiedene Module der Datenanalyse nach Triebwerkstests des SSME integriert. Das
EDIS (Engine Data Interpretation System) als Teil des PTDS fasst verschiedene Wissensquellen zusam-
men. Ein Funktionsmodell des Triebwerks, thermodynamische Prinzipien und durch Befragung von mensch-
lichen Experten gewonnene heuristische Regeln werden als diagnostische Wissensbasis benutzt.
In einem gemeinsamen Boeing/NASA-Kennedy FE-Programm läuft die Entwicklung wissensbasierter Soft-
ware (PAT: Propulsion Advisory Tool) für die Betankung und das Treibstoffmanagement am Boden während
der Startvorbereitungen. Bisher wurden in dieser Phase nur Limit-Checks (go/no go) durchgeführt. Dieses
Programm hat zum Ziel, Anomalien während der Betankungsprozedur on-line zu erkennen und aufzuzeigen
bevor diese zu Fehlfunktionen werden. Der Triebwerksbetrieb wird über die Massenströme und auf Basis
der physischen Verbindungen zwischen den Komponenten (physical connectivity) modelliert und analysiert.
Obwohl das Programm derzeit nur die LOX Seite des SSME umfasst, werden bereits 300 Messkanäle in
Echtzeit überwacht und dabei nicht weniger als 50 000 Messwerte aus dem Startdatenverkehr übernommen
und auf ihre Vertrauenswürdigkeit geprüft.
Ein in Echtzeit arbeitendes Sensorbewertungssystem wurde von NASA-Lewis zusammen mit Boeing und
zwei Software Firmen (Expert Microsystems Inc. und Intelligent Software Associates Inc., ISAI) entwickelt
[4]. Bei allen schnell funktionierenden AI Systemen besteht immer das Sensor-Validierungsproblem, bei dem
es um die Frage nach der Zuverlässigkeit der Sensordaten geht. Das innovative Sensorvalidierungssystem
verwendet analytische Redundanz (mathematische Beziehungen um Erwartungswerte eines Sensors aus
jenen anderer Sensoren vorherzusagen) und Bayes` Entscheidungstheorie zum Aufbau von vernetzten An-
nahmen als rigorose Lösung des hier vorliegenden Problems der Informationsfusion. Das hier seit 1990 ent-
wickelte Sensor Validation System SVS besteht aus einem Netzwerkentwicklungssystem (einem Satz von
Software-tools) für individuelle Sensorgruppen und einem Echtzeit-Modul, der mit Hilfe des Bewertungs-
Netzwerks und einer Abstimmungstabelle (Voting table) die Datenströme der Sensoren on-line bewertet. Der
jetzt fertige Prototyp kann 22 SSME Sensordaten in Echtzeit für alle Flugzustände des Triebwerks mit hoher
Zuverlässigkeit bewerten.
Eine Echtzeit Health Monitoring System für Triebwerkskomponenten wird von NASA-Lewis in Zusammenar-
beit mit Sci. Monitoring Inc. (Tempe, Arizona) vorbereitet [5]. Während beim oben genannten Ansatz konkre-
te Modell-Algorithmen verwendet wurden, werden hier neuronale Netze benützt, die bekanntlich in der Lage
sind, komplexe Zusammenhänge durch Lernen zu erfassen. Das hat den Vorteil, daß keine Modellierung

3
erforderlich ist und den Nachteil, daß physikalische Zusammenhänge nicht erkennbar werden. Der hier ver-
wendete Ansatz stützt sich auf eine sogenannte nicht-lineare Komponentenanalyse, bei der das Problem
als stochastisch betrachtet wird und man lineare Algebra und Kalman Filtern auch in nicht-linearen Syste-
men einsetzt. Real-time Bedingungen wurden bisher noch nicht erreicht. Die wichtigsten Problemkreise be-
stehen in der Wahl der Architektur, der Trainingsdaten und der Methoden. Das System umfasst ebenfalls die
Bewertung von Sensordaten, zielt aber insgesamt weit darüber hinaus.
Situation beim VULCAIN Triebwerk
Vergleichbare Erfahrungen wie beim SSME gibt es in Europa nicht. Obwohl eine große Menge an Testdaten
mit während Entwicklungstests wiederverwendeten Triebwerken gesammelt wurde, war keiner dieser Test-
läufe vergleichbar mit den beim SSME gemachten Erfahrungen.
Die Testauswertung erfolgte unter Zuhilfenahme von "ETNA 5", einer Kombination aus Datenbank und
Netzwerk bestehend aus Computern an 9 verschiedenen Orten. Dieses System ist weiterhin verfügbar für
den ARIANE 5 Betrieb und die VULCAIN Weiterentwicklung. Das System kann alle Testdaten der 1500 wäh-
rend der Entwicklung vorgesehenen Tests speichern. Es ist seit 1988 operationell, stellt natürlich kein
wissensbasiertes System dar, wäre aber eine exzellente Basis für ein solches.
Bei ARIANE 5 wird die Überwachung und Kontrolle über dieses Niveau hinaus gehen. Die Kontrolle der
Startsequenz wurde basierend auf einem AMDEC Ansatz (Funktionenbaum und Fehlermodus-Analyse)
entworfen und benutzt "Red Lines" in Synchronsequenz.

2.2 Stand der Technik bei WBS Anwendungen

Bild 2 zeigt die methodischen Ansätze als hierarchischen Baum. Es vermittelt den Eindruck, die gezeigten
Methoden würden einzeln benutzt. In Wirklichkeit findet man aber in den meisten Systemen Kombinationen.
Um die Verbindung zwischen Methoden und Anwendungen zu zeigen, wurden typische Anwendungsbei-
spiele an den Zweigen des Baums aufgelistet.
Ein Softwaresystem mit komplexen Diagnose- und Überwachungsfunktionen besteht typisch aus mehreren
Modulen mit verschiedenen KI-Techniken. Solch ein Modul kann durch seine Art der Anwendung, sein Mo-
dellierungsparadigma und seine Wissens- und Datenquellen charakterisiert werden. Die existierenden Alter-
nativen wurden in [2] analysiert und vorgestellt. Es sind dies: Wissensbasierte Expertensysteme, Fallbasier-
tes Schlussfolgern (Case-based Reasoning), Fuzzy Logic, Neuronale Netze und Blackboard Systeme.

2.3 Verallgemeinerung des Wartungs-, Diagnose- und Instandhaltungsbetriebs

WDI Betrieb und Lebenszyklus bei Raketentriebwerken
In wiederverwendbaren Systemen können alle bisher genannten Funktionen entweder während des Fluges
oder während der Wartung am Boden eingesetzt werden. Es ergibt sich eine Matrix aus Langzeit-
Zustandsüberwachung (Condition monitoring), Kurzzeit-Fehlerüberwachung (Fault monitoring) und Diagnose
(Diagnostics), welche während des Fluges oder am Boden benutzt wird.
Wartungs-, Diagnose- und Instandhaltungsaufgaben (WDI-Aufgaben) können einzelnen Betriebsphasen des
Transportsystems und des Raketentriebwerks zugeordnet werden. Ihre Durchführbarkeit ist eng mit den
vorhandenen Einrichtungen und mit der Missionsumgebung verknüpft. Im Zusammenhang mit WDI-
Aufgaben wird für die Betriebsphasen von wiederverwendbaren Triebwerken (nach SSME Erfahrungen) eine
Struktur vorgeschlagen, die in Fehler! Verweisquelle konnte nicht gefunden werden. dargestellt ist. In
jeder Phase werden Kontrollen von Leistungen und Zuständen über definierte Mechanismen durchgeführt.
Diagnosegeräte
In [2] wurde eine nach Klassen geordnete Liste der zur Zeit in fortschrittlichen Raketentriebwerken einge-
setzten Sensoren aufgestellt. Einige neue Entwicklungen in der Sensortechnologie wurden ebenfalls berück-
sichtigt. Ziel war eine Auswahl geeigneter Sensoren (speziell für das ACE), die hauptsächlich durch verbes-
serten Missionserfolg und reduzierte Wartungs- und Instandhaltungskosten die Lebenszykluskosten senken
könnten.

4
 AI-Systems

symboli subsymbolic other

approaches approaches approaches

rule-based case-based tree search neural artificial blackboard numerical fuzz

system system (heuristic) network lif system system
planning game classification integration controlling
diagnosis forecasting
pattern recognition
forewar backward hybrid pattern completion cellula genetic model-based statistics
chaining chaining system automata algorithms
planning diagnosis diagnosis simulation optimizing simulation classification
planning forecasting forecasting

Bild 2: Genealogie allgemeiner methodischer Ansätze im Bereich der künstlichen Intelligenz

3 REFERENZMODELL FÜR EIN DIAGNOSE- SYSTEM

In diesem Abschnitt werden verschiedene Wissensklassen identifiziert und deren Einfluss auf den Entwurf
des Expertensystems untersucht.
3.1 Beschreibung der Wissensquellen
Spezialwissen zu bestimmten Bereichen ist in sehr unterschiedlichen Formen verfügbar. Experten eines
Fachgebiets können Wissen auf einer sehr abstrakten Stufe zur Verfügung stellen. Datenbanken sind eine
Quelle historischer Ereignis-Parameter. Normalerweise ist der Zugriff auf das fachspezifische Wissen in
solchen Datenbanken schwierig. Intelligente Suchmethoden oder lernfähige Prozeduren (z.B. mit neuronalen
Netzen) können aber die in der Datenflut versteckten Beziehungen herausarbeiten. Mögliche Wissensklas-
sen sind also:
Expertenwissen
Implizites Wissen versteckt in aufgezeichneten Daten
Mathematische Modelle
Probabilistische Daten
Ein wichtiger Punkt ist die Vorverarbeitung von Informationen ("information pre-processing"), die den Re-
chenaufwand erheblich verringern kann. Beispiele sind Fourier- und logarithmische oder axiale Transforma-
tionen. Die genannten Wissensklassen wurden charakterisiert und den vom Referenzmodell vorgeschlage-
nen verschiedenen Ebenen zugeordnet [2].
3.2 Definition des WDI Referenzmodells
Das Referenzmodell bietet für den vorgeschlagenen Diagnoserahmen einen Überblick über die generelle
Struktur von Software- und Hardwarekomponenten. Es beschreibt die Struktur und das Anwendungsgebiet
der Softwaremodule, den Hauptinformationsfluss innerhalb des Systems, die Kommunikationseinrichtungen
und die Schnittstellenanforderungen des Raketentriebwerks. Das Referenzmodell verdeutlicht, daß die
grundsätzliche Entwurfsphilosophie auf Modularität und Erweiterbarkeit des Systems beruht.
Bild 3 zeigt die hierarchische Zusammensetzung der Softwarekomponenten. Bei der Hardware liefern Sen-
soren und Mess-Einrichtungen Betriebsdaten von Untersystemkomponenten zu jenen Teilen der Überwa-
chungssoftware, die man als Monitoring Agents bezeichnet. Jeder Agent sammelt und transformiert die Da-
ten eines einzigen Sensors oder einer Mess-Vorrichtung. Eine bestimmte Anzahl von Agenten überwacht
den Funktionszustand eines Triebwerksuntersystems. Monitoring Agents dienen hauptsächlich der Trieb-
werkskontrolle und -steuerung, liefern aber auch wichtige Daten an das Diagnosesystem.

5
 Operative Diagnostic Level

Rocket Engine MD MD
Status Derivation Operation Operation
Generato Sequencer

Status Requests Status Reports

S ubsystem Status Level

HPOTP State Hot Gas Ducts Injector State

HPOTP Subsyste Subsyste Subsyste Subsyste

HPOTP HPOTP HPOTP inlet Duc Duc Injecto Injecto
oil tempe- shaf ... valve posi- Monitorin Monitorin Monitorin Monitorin
rature speed
tio Agent 1 Agent 2 Agent 1 Agent 2

M onitoring Agents
Bild 3: Softwareebenen des Diagnosesystems (Beispiel: Oxydatorpumpe)

Jeder Hersteller einer Triebwerkskomponente muss eine detaillierte technische Beschreibung seiner Kom-
ponente in Form eines Datenbankmodells liefern. Der Datenaustausch muss auf einer allgemeinen Kommu-
nikationsschicht aufbauen. Diese Schicht standardisiert den Daten- und Botschaftenfluss innerhalb des Sys-
tems. Jedes neue Modul, das sich an das festgelegte Kommunikationsprotokoll hält, kann so leicht in das
System integriert werden.
Bild 4 zeigt die Aufgabe der Kommunikationsschichten, die zwischen der Überwachungsebene (monitoring
level) und der Untersystemstatusebene (subsystem status level) sowie zwischen dieser und der Triebwerks-
systemebene (engine system level) vermitteln.
Beide Schichten verteilen hauptsächlich Daten, wenn nötig über Netzwerke. Der Hauptinformationsfluss geht
von der untersten Ebene (monitoring agents) zur obersten Ebene um den Zustand des Systems zu diagnos-
tizieren. Wenn eine dem Diagnosesystem unbekannte Fehlfunktion auftritt, kann die oberste Ebene eine
Anfrage zu dem betroffenen Untersystem schicken, um z.B. die erhaltenen Eingabedaten auf Auffälligkeiten
abzusuchen oder um den Zustand der Sensoren zu überprüfen.
Bei der Systemrealisierung hat die Definition der Schnittstellen eine zentrale Bedeutung. Schnittstellendefini-
tion heißt Festlegung eines Kommunikationsprotokolls für den Informationsaustausch zwischen den Ebenen
und Modulen. Datenbanken sind die Quelle für Entwurfs- und Betriebsdaten der Raketentriebwerkskompo-
nenten. Infolgedessen erstreckt sich die Schnittstellendefinition auch auf die Standardisierung beim Daten-
bankzugriff.

6
 Engine Bild 4: Kommunikation zwischen verschiedenen
System Ebenen und Modulen in einer ausgebreiteten Sys-
Level request for subsystem status
unknown error subsystem status temumgebung

System Communication Layer

Engine Manufacturer A Manufacturer B

Subsystem
Level
request for data
abstract description
unknown error
of sensor data

Monitoring Communication Layer

Monitoring Agents

4 SYSTEMARCHITEKTUR UND MODELLIERUNG EINES BEISPIELS FÜR

DIAGNOSEAUFGABEN
4.1 Überwachungsebene (Monitoring Level)
Monitoring Agents sind Module, die sich aus Hardwarevorrichtungen und zugehöriger Software zusammen-
setzen. Wenn man dem Konzept des SSME folgt, kann die Hardware eines Agenten aus bis zu drei
reduntanten Sensoren bestehen. Für ein Maximum an Sicherheit können redundante Instrumente unter-
schiedliche physikalische Prinzipien nutzen, sie müssen sich aber auf dieselbe physikalische Dimension
beziehen.
Verfügbare Sensoren erlauben hohe Flexibilität. Schnelle Datenaufbereitung kann schon beim Sensorent-
wurf integriert werden. Typische Aufbereitungsalgorithmen sind schnelle Fourier Transformationen oder digi-
tale Filteralgorithmen. Spezialisierte Sensoren können auch "Neuro-computing" und unscharfe (fuzzy) Algo-
rithmen benutzen. Der direkt im Sensor integrierte Anteil an Intelligenz bestimmt das Ausmaß der Software
des Monitoring Agent.
Sensorhardware ist in der Regel in Form kommerzieller Produkte verfügbar. Die Entwicklung der Module ist
dagegen Aufgabe des Herstellers der zu überwachenden Komponente. Dies umfasst:
Eine Sensorsteuerung (sensor device controller), die redundante Datenströme integriert. Ein Dateninterpre-
tationsmodul (data interpretation module), das die Transformation des Datenmaterials übernimmt. Ein Ereig-
niskontrollmodul (event controller module) überführt die gemessenen Ereignisse in eine Datenstruktur für die
Kommunikation. Ein Sensoreinstellungsmodul (sensor set-up module) bietet eine Schnittstelle um den Ar-
beitsmodus des Überwachungsagenten zu bestimmen. Ein Dokumentationsmodul (documentation module)
empfängt die Daten des Dateninterpretationsmodul und stellt Archivierungsfunktionen zur Verfügung.
Bild 5 gibt einen zusammenfassenden Überblick über die Architektur eines Überwachungsagenten.
4.2 Untersystemebene (Subsystem Level)
4.2.1 Untersystem-Module
Die Untersystemebene fasst die Informationen der Überwachungsagenten zu Statusberichten über die Sub-
systeme des Antriebssystems zusammen. Bild 6 zeigt die wichtigsten Komponenten eines Untersystemmo-
duls. Die Kommunikationsanforderungen mit der Überwachungsebene (monitorig level) werden durch eine
Gruppe von Ereigniswächtern (event controller group) erfüllt, die Ereignisse aus den Ereigniswarteschlangen
(event queues) sammelt. Ereigniswächter (event controller) sind das abschließende Element der Hierarchie.
Die Statusintegrationsgruppe (status integrator group) verteilt die Information an die Untersystemmodule.
Die Hauptunter-Systemintegratoren (main subsystem integrators) berichten an die Systemebene. Daten und
Überwachungsmeldungen der wichtigsten Untersysteme, z.B. über Zündung, Turbopumpen und Treibstoff-
leitungen, setzen sich zur Beschreibung des Betriebszustands des Antriebssystems zusammen. Die Struktur
der Untersystemstatusmeldungen für jedes überwachte Untersystem wird in der Missionsdatenbank gespei-
chert.

1
BILD 5 Struktur eines Überwachungsagenten (monitoring agent)

2
 s ubs yst em s tatus report l
s ubs yst em s tatus report k
s ubs yst em s tatus report j
s ubs yst em s tatus report i
s ubs yst em id: hpotp_turnbins_s haft TP s ubs ys tem
s ys tem_time: + 124000 ms mis sion database
parameter list : {oi l_temp, s haft_vib, rad_s peed} monitoring s tat us report i
parameter value l ist: {400, 2000, 13000}
monitoring s tat us report i
parameter dim lis t: {k, htz, rad/min}
s tatus : attenti on monitoring s tat us report i
error class lis t: overheating_inner_bearing_race monitoring s tat us report i
s ubs yst em lis t: gas _generator

Subsystem turbine s haft

com muni cation layer to s ys tem s tatus level

TP tech. knowledge manager knowledge library

s pecification
m,athematical funct ions temporal reasoning
fas t filtering of sensor data
parameter analys is
rotational s peed * s qrt(mas flow ) - event driven
s pecifi c speed = (press ure out - pres sure in) ^3/4
TP s haf t status diagnos is procedure - regul ar
analys is of pres sure out for Žt25
component id
time st amp s ubs ymbolic class ification Rule bas e: rule class es HP TP shaft s tatus
oil temp.
s haft vibrat ion if [oil temp] > 450t
rotational s peed cont rol and [s haft vib] in {high, critical}
subsystem I nf ormation and [rot s peed] > 14000
then indicate error turbi ne shaft
f ai liure clas ses related subsystems s ubs ys tem hi erarchy green error class bearing, cavitat ion
s ubs yst em H P O TP
hot bearing turbine shaft
Synchronizer turbine bl ade crack turbine bl ades yel low if [rotational speed] > 15000
cavitation inlet sys tem and [oil temp] > 500
bearing red then indicate error inl et s ys tem
error class val ve posit ion |gas generat or
s ubs yst em H P O TP inlet s ystem

monitored: rotational s peed monitored: s haft vibrat ion monitored: oil temp. monitored:
monitoring agent oil temp.
controller
dimensi on: rad/s dimensi on: {crit ical, hi gh dimensi on 1: K dimensi on 1: K
indicate event: ±5 rad/s ec medium, low} indicate event 1: ±5K -indicate
evaluateevent
s tatus1:of
± monitoring
5K agent
indicate event: new cl as s dimensi on 2: {crit ical, hi gh, ok, -dimensi
query for
on status
2: of
{crit
sensor
ical, devices
hi gh, ok,
medium, low} - send start si gnalmedium, low}
indicate event 2: new cl as s indicate event 2: new cl as s

event sv n
event sv m
reques ts
event v l event sv l event bfl s tatus s2l
• sensor mode
event v k event sv k event bok event bfk s tatus s1k s tatus s2k • device s tatus
event v j event sv j event boj event bfj s tatus s1j s tatus s2j • st art s ignal
event v i event sv i event boi event bfi s ens or s ens or
s tatus s1i s tatus s2i
event queue 1 event queue 2 event queue 3 event queue 3 s ens or s 1 s ens or s 2
s peed s haft s haft vibrat ion s haft bearing oi l s haft bearing oi l s tatus queue s tatus queue
temperature (K) temperature (clas s)

Fig. 2.10Bild Structure of a module

6: Struktur einesforModuls
the computation
für dasof Turbinenwellenuntersystem
the subsystem turbine shaft

Eine Wissensbasis (knowledge library) ist eine Sammlung von Wissensquellen mit grundlegenden Informati-
onen über die Struktur und das Betriebsverhalten eines Untersystems.
Ein Wissensmanager (knowledge manager) ist die aktive Komponente eines Untersystemmoduls. Er emp-
fängt Eingaben vom Synchronisator, der einen Satz an Daten von den Sensoren gesammelt hat. Die Haupt-
aufgabe des Wissensmanagers ist die Durchführung von "off-line" Diagnose. Er muß eine Strategie für die
Bewertung der gelieferten Daten entwickeln. Diese Strategie besteht aus einer Kette von Entscheidungen
zur Aktivierung bestimmter Teile der Wissensbasis. Das Resultat wird auf einer Fehlerklasse und dem zuge-
hörigen Untersystem abgebildet welches die Anomalie verursacht haben könnte.

4.2.2 Zellulares Netzwerk

Die Integration externer Wissensbasen mit antriebsspezifischen Informationen wurde untersucht. Als ein für
diese Zwecke attraktiver Formalismus wurden Zellulare Netzwerke identifiziert. In solchen Netzwerken wer-
den die Zellen in der Regel von den Komponenten der Raketentriebwerke gebildet, die sich funktionsgerecht
und in topologisch korrekter Verbindung (connectivity) zu Untersystemen zusammensetzen. Die Summe
aller Subsysteme konstituiert das eigentliche Triebwerk. Alle Komponenten haben Schnittstellen mit den
Komponenten ihres eigenen oder anderer Subsysteme. Der Datenstrom über diese Schnittstellen umfasst
alle relevanten Arten des Austausches und der gegenseitigen Beeinflussung.

3
Solche sind:
Statische und Druckkräfte (mechanische oder Strukturschnittstelle)
Vibrationen (dynamische Schnittstelle)
Massenströme (Massenfluss- oder strömungsmechanische Schnittstelle)
Energie (Wärmestrom oder thermodynamische Schnittstelle, mechanische Energie wird durch Kräfte und
Momente repräsentiert)
Informationen (Kommando und Sensor-Schnittstelle)

Die Summe aller Wechselwirkungen zwischen den Komponenten eines Subsystems und jenen eines ande-
ren definiert den Austausch zwischen Subsystemen. Die externe Umgebung des Raketentriebwerkssystems
bildet eine weitere Schnittstelle.
Zur Beschreibung des Systems erweisen sich daneben noch komponenteninterne Daten als nützlich. Bei-
spiele sind manche Drucke, Drehzahlen, Gradienten etc. Dies ermöglicht eine flexiblere Handhabung der
Definition der Komponenten- und Subsystemgrenzen.
In der Graphen-Darstellung des dreidimensionalen Netzwerkes können die Schnittstellen zwischen den
Komponenten (Vertices) Ki und Kk z.B. als Kante Sik repräsentiert werden (wo i = k sein kann und i = 0 für die
Umgebung vorbehalten ist). Über jede der Schnittstellen kann jeder der oben beispielhaft definierten Daten-
ströme laufen. Wenn j die laufende Nummer der Daten-Art bezeichnet, hat jeder dieser Ströme mit Sjik be-
reits eine eindeutige Bezeichnung. Bei der Erstellung des Netzwerkes werden zunächst alle Tripel jik ent-
fernt, für deren Komponenten nach Maßgabe der Bauweise des Triebwerks kein Austausch von Daten der
Art j besteht. Danach werden
die im Entwurf bereits mit Sensoren bestückten, also gemessenen Schnittstellendaten S jik gekennzeich-
net. Dabei ist anzumerken, daß die Sensoren selbst auch als Komponenten auftreten
ebenso werden alle Sjik ermittelt, deren Datenwerte über Modelle und physikalische oder sonstige Prinzi-
pien aus gemessenen Daten (im Datenlabor, s.u.) berechnet werden können
im nächsten Schritt wird der Inhalt der Wissensbasen mit den Sjik korreliert. Sjik, die darin nicht vorkom-
men, werden eliminiert. Andrerseits werden kritische als solche gekennzeichnet. Damit werden überflüs-
sige oder fehlende Sensoren identifiziert. Komponentenpaare, die keinerlei Austausch haben, verschmel-
zen dabei zu einer einzigen neuen Komponente
Die Subsysteme werden als Untermengen von Komponenten zusammengefasst und ihr Datenausstoß
steht danach zur Bewertung ihres Zustandes zur Verfügung
Aus den Wissensbasen resultieren insbesondere (scharfe oder weiche) Grenzwerte für die S jik. Diese
Grenzwerte können zudem Funktionen anderer Datenwerte sein (z.B. kann der erlaubte Druck eine Funktion
der Temperatur sein).
4.3 Systemebene (System Level)
4.3.1 Module auf der Antriebssystemebene
Module für vorzuschlagende Diagnosearbeiten und für die Berechnung und Modifizierung des WDI Plans
sind auf der Systemebene angesiedelt. Das strategische Ziel der Systemebenen-Module ist der Schritt von
der turnusmäßigen Routinewartung zur Bedarfs orienten.
Systemebenen-Module haben folgende Aufgaben:
Informationsmanagement
Erstellung von Missionsberichten und Visualisierung von Missionsdaten
Ableitung von Diagnose-Tätigkeiten aufgrund festgestellter Fehlfunktionen
Ableitung von Wartungs- und Reparaturarbeiten
Koordination von WDI-Tätigkeiten,
Berechnung eines Netzplans
Bereitstellung von Werkzeugen für die Datenanalyse des Antriebssystems und der Untersysteme
Abschätzung der Lebensdauer und Bestimmung des Leistungszustands des Systems und seiner Kom-
ponenten.

4
Bild 7 zeigt einen zusammenfassenden Überblick der Module auf Systemebene. Das primäre Produkt des
Diagnosesystems ist ein WDI Plan mit einer Folge von Maßnahmen, die während des Wartungszyklus
durchzuführen sind. Ein Satz an Werkzeugen für die Analyse der Messdaten wird im Datenlaborsegment
(data laboratory segment) bereitgestellt und unterstützt die Untersuchung von nicht überwachten Parame-
tern. Im Datenlabor können neue Neuronale Netze oder "Fuzzy Controller" kalibriert und trainiert werden. In
Übereinstimmung mit der Untersystemebene ist die zentrale Komponente der Systemebene der Wissens-
manager (knowledge manager). Er ist als off-line Modul entworfen, das im Normalfall seine Eingabedaten
aus einer Datenbank erhält. Die Berichte aller "high-level" Untersysteme werden verarbeitet und dargestellt.
Auf der Basis der Untersystemstatusberichte wählt der Wissensmanager Untersysteme zur genaueren Un-
tersuchung aus. Ein Kreuzvergleich mit den Parametern der "high-level" Untersysteme wird durchgeführt um
Kombinationseffekte oder die Fortpflanzung von Fehlerauswirkungen zu untersuchen.
MDR operations
mi ssion MDR subsystem system for system and database experimental
report schedule information performance subsystems access model s

user interface

system list of MDR MDR

performance operations scheduler
data

knowledge manager subsystem

repaire &
maintenance technical
operations analysation of sub- information
system status for sta-tus parameter cross
reports demanding checks among different
attenti on subsystem reports
knowledge
diagnosis library data
operations laboratory
rul es for
trend analysis for - computation of
selected parameters life time assessment & system status
of a status report operation status - prescription of
diagnosis tasks

subsystem
subsystem status report subsystem technical
subsystem
high level mi ssion specifi cation
life cycle
subsystems (e.g.
turbo pump, igniter)

Bild 7: Module auf Systemebene (system level modules)

4.3.2 Diagnose und Wartungsbetrieb mit Klassen von Fehlerzuständen

Die Fehlerklassifikation für das Gesamtsystem und die wichtigsten Untersysteme ist ein essentieller Be-
standteil der Wissensbasis (knowledge library).
Folgende Übereinkünfte bestehen:
Gesamtsystem: das Triebwerk als Ganzes
Untersysteme: Gasgeneratoren, Turbinen, Pumpen, Turbopumpenkombinationen etc.
Komponente: die niedrigste betrachtete Hardware-Ebene
Mission: eine bestimmte notwendige Betriebsdauer während des Fluges oder während eines Testlaufs

5
Tab.1 zeigt die "Matrix of reasoning", eine Skala der Fehlfunktionen, wie sie in [3] vorgeschlagen wurde.

Schwere (Severity) Definition Symptome Konsequenzen

Katastrophale Fehlfunk- Fehlfunktion der Kompo- Totaler Leistungseinbruch Sofortige Abschaltung
tion nente führt unausweich- pflanzt sich bis zur obers- des Triebwerks notwendig
(Lethal malfunction) lich zum Versagen des ten Ebene fort um Fehlerfortpflanzung zu
Untersystems oder des verhindern
gesamten Triebwerks
Schwere Fehlfunktion Fehlfunktion der Kompo- Betriebsparameter der Abschaltung des Trieb-
(Severe malfunction) nente könnte zum Versa- Komponente liegen zu- werks notwendig um Feh-
gen von Untersystem(en) nehmend außerhalb des lerfortpflanzung zu ver-
und des gesamten Trieb- Entwurfsbereichs. Schwe- hindern
werks innerhalb der Mis- rer Leistungseinbruch
sionsdauer führen (zunehmend)
Tolerierbare Fehlfunkti- Leistungseinbußen durch Betriebsparameter der Mission kann beendet
on Fehlfunktion der Kompo- Komponente bleiben im werden. Post flight Unter-
(Tolerable malfunction) nente, wenn vorhanden, Entwurfsbereich und die suchungen werden spezi-
können kompensiert wer- Leistungseinbußen blei- fiziert
den ben daher kompensierbar
Tolerierbare Abnutzung Abfallen der Qualitätspa- Betriebsparameter der Komponente kann wie-
(Tolerable ageing) rameter ohne Leistungs- Komponente bleiben auch derverwendet werden.
einbußen während des bei der nächsten Mission Pre-flight Test könnte
letzten Einsatzes deutlich innerhalb des notwendig werden.
Entwurfsbereichs (durch
Extrapolation bestimmt)
So gut wie neu Kein Abfallen der Quali- Betriebsparameter der Komponente kann wie-
(As good as new) tätsparameter während Komponente bleiben kon- derverwendet werden.
des letzten Einsatzes stant Keine Wartungsarbeiten
notwendig
TAB. 1: Skala der Fehlfunktionen

5 WICHTIGE ERGEBNISSE UND ZUSAMMENFASSUNG

5.1 Sachstand
In Europa wurde bisher wenig Erfahrung in der Überwachungstechnik der Raketenantriebssysteme gesam-
melt. Dieser Zustand sollte durch den Einsatz aller Kräfte verbessert werden
Eine Überwachung des Triebwerkszustands wird von den meisten großen Luftfahrtgesellschaften und von
nahezu allen wichtigen Raketenanbietern "off-line" angewendet. In beiden Fällen wird die Triebwerksdiagno-
se von menschlichen Experten durchgeführt. Die Überholung der Triebwerke wird in der Luftfahrt nicht mehr
"on schedule" sondern "on condition" vorgenommen
On-line Diagnose ist sehr wichtig und in bestimmten Flugzuständen unabdingbar
Bedarfsorientierte Instandhaltung (state controlled refurbishment) und Fehlervorhersage (life prediction) sind
die beiden wichtigsten Konzepte für KI Anwendungen
KI Anwendungen steigender Komplexität werden für das SSME und andere zukünftige Raketentriebwerke
eingesetzt werden. Europa sollte nicht länger zögern.
Das europäische VULCAIN Triebwerk wurde so entworfen, das eine spätere Erweiterung zur Wiederver-
wendbarkeit möglich ist. WBS und KI-Systeme sind hier unverzichtbar für einen sicheren und kostengünsti-
gen Betrieb. Dasselbe gilt für das ACE Triebwerk
Die drei Ebenen des rechnergestützten Diagnosekonzepts sind: eine Signalverarbeitungsebene, eine Dar-
stellungsebene für den Triebwerkszustand und eine strategische Ebene auf der Abfolgen von Instandhal-
tungsarbeiten und Reparaturmaßnahmen generiert werden
Als Ergebnis wurde eine WBDS-Architektur mit eben diesen 3 Ebenen vorgeschlagen. Auf der untersten
Ebene liegt die Hard- und Software für Signalverarbeitung und Diagnose. Das System sammelt und kombi-
niert die Ausgabeinformation von Überwachungsagenten und kommt zu einer Einschätzung des Zustandes

6
Zustands der Komponenten, Untersysteme und des ganzen Triebwerks. Fehlerzustände werden erkannt
und mit den Ausgabeinformationen der Diagnosemodule verknüpft
Die Ausgabe der Überwachungsagenten wird an Module weitergeleitet, welche den Zustand der Untersys-
teme und des Antriebssystems ermitteln. Auf der mittleren Ebene werden die Prozessdaten auf Fehlersymp-
tome und Fehlerzustände des Raketentriebwerks und seiner Komponenten abgebildet. Ergebnis der mittle-
ren Ebene ist eine Beschreibung des Zustands der wichtigsten Triebwerkskomponenten.
Auf Systemebene wurde eine regelbasierte Architektur definiert, welche Entscheidungen über die Wieder-
verwendbarkeit der Untereinheiten fällt und Beschreibungen von Reparatur- und Wartungsmaßnahmen für
diese erstellt. Die Ausgabe der Module der obersten Ebene ist eine Abfolge von Maßnahmen, die auf einen
sicheren Betrieb des Antriebssystems im nachfolgenden Einsatz abzielt. Eine überarbeitete Regelsammlung
menschlicher Experten ist das zugrundeliegende Softwaremodell, welches im jetzigen Zustand nur anhand
von Beispielen auf Subsystemebene skizziert wurde.
Die Integration von externen Datenbanken mit antriebsspezifischen Informationen wurde untersucht und die
wichtigsten Probleme erörtert. Als Modellierungstool wurde ein zellulares Netzwerk vorgeschlagen
5.2 Ausblick
Der nächste Schritt nach dem Entwurf der Referenzarchitektur ist die Entwicklung eine Demonstrator-
Version des wissensbasierten Diagnosesystems und die praktische Arbeit an der Erweiterung hin zu Echt-
zeitüberwachung. Die folgenden zukünftigen Arbeitspakete, welche einen Weg zu einem WBDS Demonstra-
tor aufzeigen, wurden identifiziert.
Aufbau eines off-line WBDS Demonstrators
Systemanalyse eines Echtzeit WBDS. Wissensbasierte Systeme, die in Echtzeit arbeiten sind Gegen-
stand der Forschung, aber es gibt noch keines in praktischer Anwendung, weil diese Systeme datenab-
hängig sind. Ihre Regelbasis ist flexibel und Änderungen unterworfen. Das Verhalten des Systems kann
sich komplett verändern ohne das die Algorithmen (the inference engine) neu programmiert worden sind.
Im allgemeinen sind "Echtzeit" und "wissensbasiert" zwei entgegengesetzte Pole der Dimension "Leis-
tungsfähigkeit".
Kosten-Wirksamkeitsanalyse

6 LITERATUR
[1] Lo, Landvogt, Leppich, Sattler: "Technical Review of Monitoring and Diagnosis Techniques"
in: FESTIP: Technology Developments in Rocket and Air-breathing Propulsion for Reusable Launch Vehicles,
Technical Report WP5100, January 1996
[2]Lo, Landvogt, Leppich, Sattler: "Reference Model of a Diagnosis System for a Reusable Propulsion System", in:
FESTIP: Technology Developments in Rocket and Air-breathing Propulsion for Reusable Launch Vehicles,
Technical Report WP5200, May 1996
[3]Lo, Landvogt, Leppich, Sattler, Rode: "Reference Architecture for a Knowledge based Diagnosis System", in: FESTIP:
Technology Developments in Rocket and Air-breathing Propulsion for Reusable Launch Vehicles, Technical
Report WP5300, August 1996
[4]R.Bickford et al.: "Real-Time Sensor Validation for Autonomous Flight Control", 33rd AIAA Joint Propulsion Confe-
rence, Seattle, AIAA-97-2901, Juli 1997
[5]D.Mattern, Sci.Monitoring Inc.: "Real-Time Simulation of a Neural network Based Engine Health Monitoting System",
33rd AIAA Joint Propulsion Conference, Seattle, AIAA-97-2902, Juli 1997