-
HINTERGRUND DER ERFINDUNG
-
Bereich der Erfindung
-
Diese
Erfindung bezieht sich auf ein eingebettetes Diagnosesystem und
eine Diagnosemethode für
den Gebrauch in computerbasierten Systemen, die repetitive redundante
Subsysteme haben.
-
Beschreibung
des verwandten Standes der Technik
-
Moderne
elektronische Systeme, wie Flugzeugavioniksysteme, können eine
Vielzahl von elektrischen und elektronischen Subsystemen haben,
die für
Kommunikation, Navigation, Flugzeugkontrolle, Fernsensorik, Leistungsverteilung,
Lebensunterstützung,
elektronische Kriegsführung,
verschiedene Sensoren, etc., benutzt werden. Weil die Komplexität dieser
Systeme ansteigt, steigt auch die Zahl der potentiellen Fehler generell
an. Auch ist die Beziehung zwischen den vielfältigen Subsystemen und einem Fehlersignal
zunehmend komplex, was es schwieriger macht, den tatsächlichen
Grund eines Fehlersignals zu determinieren. Als Ergebnis benötigen moderne
Diagnosesysteme unter Umständen
signifikante Analysearbeit, um die Ursache eines Fehlersignals zu
isolieren.
-
Echtzeit
eingebettete Diagnosesoftwaresysteme wurden entwickelt, um in computerbasierten Systemen
(„Hostsystemen"), während des
Betriebes Fehler zu entdecken und zu isolieren. Die Hostsysteme
haben einen Zentral- oder Wartungscomputer, welcher den Speicher
zum Speichern der Diagnosesoftware und einen Prozessor hat, um die
Systemdiagnose durchzuführen.
Der zentrale Computer akzeptiert Fehlersignale von den vielfältigen Subsystemen
und führt
die Diagnosesoftware aus, um eine Determinierung der wahrscheinlichen
Ursache des Fehlers durchzuführen.
Unabhängig
davon, hat sich, weil die Komplexität moderner Systeme sich erhöht hat,
auch die Komplexität
von Diagnosesoftware erhöht
und diese Komplizität
erfordert eine prohibitive Menge an Speicher und/oder Computerprozessordurchsatzleistung.
Um diesen Beschränkungen
entgegenzukommen, ist es für
Systementwickler oft erforderlich, den Umfang oder die Tiefe des
Diagnosesoftwaresystems zu skallieren.
-
Ein üblicher
Ansatz für
eingebettete Echtzeitdiagnose ist die Entwicklung eines kausalen
Netzwerkmodells, basierend auf den Verhaltenscharakteristiken von
den vielfältigen
Subsystemen, die in dem übergreifenden
Hostsystem enthalten sind. [Darwiche, A. 1998. Model-based Diagnosis
Using Structured System Descriptions. J. of Al Research, 8: 165–222, June
1998]. Ein kausales Netzwerkmodell stellt für ein bestimmtes Hostsystem
einen abgestuften Satz von Diagnosen bereit, bei gegebenen Eingaben
und Ausgaben der vielfältigen
Subsysteme, der leitungsersetzbaren Einheiten (line replaceable
units, LRUs), Sensoren oder anderer Komponenten. Im Betrieb wird
das kausale Netzwerk zusammen mit einem kausalen Netzwerkinterferenzcode
in den Speicher innerhalb des Zentralcomputers des Systems geladen.
Der Zentralcomputer akzeptiert Eingaben von dem System, welche auf
einen Fehler hinweisen können,
und nutzt die Eingabe in Verbindung mit dem kausalen Netzwerk, um
die Wahrscheinlichkeitsverteilung in Relation zu den Fehlervariablen
zu berechnen. Das kausale Netzwerk wird dann unter Benutzer des
Interferenzcodes abgefragt und die wahrscheinliche Ursache des Fehlers
wird generiert. All diese Schritte werden komplettiert, während das
Hostsystem weiter arbeitet. Ein Nachteil dieses Ansatzes ist, dass
das kausale Netzwerk und der Interferenzcode eine große Menge
an Speicher verbrauchen und eine signifikante Prozessordurchsatzleistung
erfordern, um es zu ermöglichen,
dass das Interferenzieren schnell getan werden kann, insbesondere
für Diagnosesysteme
in der realen Welt (z.B. Netzwerke, die eine vernünftige Zahl
von Fehlern in einem System selbst diagnostizieren können). Abhängig von
dem System kann möglicherweise
kein ausreichender Speicher oder keine ausreichende Durchsatzleistung vorhanden
sein, um diesen Prozess zu implementieren.
-
Um
diese Schwierigkeiten abzustellen, wurde ein flexiblerer Ansatz
erdacht, um das kausale Netzwerk unter Benutzung von abfrageorientierten azyklischen
Graphen (query directed acyclic graphs, Q-DAGs) zu implementieren.
Im kausalen Netzwerk wird die meiste Arbeit durch Standard-Algorithmen durchgeführt, welche
unabhängig
sind von den spezifischen Nachweisen, welche durch die Fehlervariablen
gesammelt werden. D.h. es gibt grundsätzlich keinen Unterschied zwischen
den Läufen
der Algorithmen, welche mit unterschiedlichen Werten für die Variablen
durchgeführt
werden und der Algorithmus wird sich bei einer Schlüsselentschei dung,
die er macht, nicht unterschiedlich verzweigen. Daher kann ein Standardinterferenzalgorithmus
auf ein kausales Netzwerk angewendet werden, wobei die Variablen Parameter
anstatt spezifischer Werte sind. Das Ergebnis, das der Algorithmus
zurückgibt,
ist ein Q-DAG der eine Arithmetik oder ein logischer Ausdruck ist,
welcher einige Parameter hat, die von spezifischen Nachweisen abhängen. [Nachzulesen
bei Darwiche A. supra., and Adnan Darwiche, Gregory M. Provan: Query
DAGS: A Practical Paradigm for Implementing Belief-Network Inference.
J. of Al Research 6: 147–176,
1997].
-
Einer
der Vorteile dieses Ansatzes ist, dass der Q-DAG typischerweise
off-Line kompiliert wird unter Benutzung des gegebenen kausalen
Netzwerks, eines Satzes von Variablen darüber, welche Nachweise gesammelt
werden können
(Nachweisvariablen), und eines Satzes von Variablen für die Berechnung
der Wahrscheinlichkeitsverteilung (Abfragevariablen). Der Q-DAG
und ein Auswerter, der spezifisch ist für das Hostsystem werden im
Speicher des Hostsystems gespeichert und benutzt, um Fehler on-Line,
d.h. während
des Betreibens des Hostsystems zu evaluieren. Angenommen, Nachweise
für Systemfehler
treten auf, dann wird der Q-DAG
unter Benutzung einer einfachen Arithmetik oder logischen Operationen,
anstatt durch komplizierte kausale Netzwerkinterferenzierung ausgewertet.
Dieser Ansatz reduziert die Speicheranforderung und die Computerarbeit,
die erforderlich ist, um die on-Line Diagnoseauswertung auszuführen und
kann einfach in verschiedenen Software- und Hardwareplattformen implementiert
werden.
-
In
konventionellen Diagnosesystemen muss ein Diagnoseprogramm für das gesamte
Hostsystem generiert werden und im Speicher gespeichert werden.
In Systemen die Q-DAG-basierte Diagnosen nutzen, wird ein Q-DAG
für das
gesamte System off-Line kompiliert und im Hostsystem Prozessorspeicher,
zusammen mit seinem Interferenzalgorithmus, gespeichert.
-
Unbeachtet
dieser Verbesserungen in den Speicher- und Durchsatzleistungsanforderungen, kann
der Q-DAG-Ansatz immer noch eine prohibitive Menge von Speicher-
und Prozessordurchsatzleistung verbrauchen. Z.B. haben einige moderne
kommerzielle Flugzeuge komplexe Passagierunterhaltungssysteme (passenger
entertainment system) mit einer Vielzahl von Subsystemen und Komponenten. Oft wird
der Computer, der verantwortlich ist für das Durchführen des
Diagnosesystems für
das Entertainmentsystem auch zugeordnet für das Durchführen von
anderen Aufgaben, die nahezu seine gesamte Durchsatzleistung und
Speicher verbrauchen. Demgemäß gibt es
nur eine geringe Durchsatzleistung oder Speicher, die zum Diagnosesystem
zugeordnet werden können.
In anderen Systemen ist der Computer, der die Diagnosen durchführt, einfach
nicht stark genug, um Diagnosen, die Q-DAGs benutzen, adäquat zu
speichern und durchzuführen.
-
A.
Darwiche: „utilizing
device behavior in structure based diagnosis", proceedings on artificial intelligence,
1999 Seiten 1 bis 6 offenbart eine strukturbasierte Diagnose, die
zeigt, wie eine Diagnoseabfrage in einfachere Abfragen zerteilt
werden kann.
-
Unbeachtlich
dieser Einschränkungen
erfordern viele Hostsysteme immer noch eingebettete Echtzeitdiagnosesysteme
für schnelle
und effiziente Echtzeitfehlerdetektierung und Isolation. Dies trifft
im Speziellen zu für
kommerzielle Flugzeuge, die generell unter strikten Durchlaufanforderungen
für Flugzeugreparaturen
stehen.
-
Zusammenfassung
der Erfindung
-
Die
vorliegende Erfindung stellt ein computerbasiertes eingebettetes
Echtzeitdiagnosesystem gemäß Anspruch
1, ein Diagnosecomputerprogramm, wie definiert in Anspruch 4 und
ein Verfahren für
das Detektieren und Isolieren von Fehlern, wie definiert in Anspruch
9, zur Verfügung.
-
Die
vorliegende Erfindung stellt ein neues eingebettetes Echtzeit-Q-DAG-basiertes
Diagnosesystem, welches minimalen Speicher und Prozessordurchsatzleistung
benutzt, während
es immer noch volle Systemdiagnosen bereitstellt. Die Erfindung
ist anwendbar zur Fehlerdetektierung und -isolation in Hostsystemen,
die redundante oder repetitive Subsysteme haben. Durch Benutzen
der vorliegenden Erfindung in Hostsystemen, die repetitive Architekturen
haben, muss der gespeicherte Q-DAG nur eine Instanz von jedem Teil
des Systems aufweisen, in welchem dieser Teil wiederholt auftaucht.
Zusätzlich werden
Algorithmen, die sich darauf beziehen, wie die verschiedenen repetitiven
Subsysteme miteinander verbunden sind, generiert und mit den Q-DAGs gespeichert.
-
Z.B.
muss, in dem Fall, dass die Architektur in vier identische und repetitive
Subsysteme eingeteilt werden kann, nur ein Q-DAG, der eines dieser vier
Subsysteme repräsentiert,
kompiliert und im Speicher des Hostsystems gespeichert werden. Wenn
ein Fehler in dem ersten Subsystem detektiert wird, kann der gespeicherte
Q-DAG abgefangen werden, um die wahrscheinliche Ursache des Fehlers
zu determinieren. Wenn ein Fehler in einem der anderen Subsysteme
detektiert ist, kann durch den Gebrauch eines Replizierungsprogrammes,
welches auch in dem Speicher innerhalb des Hostsystems gespeichert
ist, die notwendige Anzahl von Q-DAGs repliziert werden. Wenn ein
Fehler bei der dritten repetitiven Sektion detektiert wurde, werden
zwei weitere Q-DAGs von dem gespeicherten Q-DAG repliziert. Das Diagnosesystem wird
dann ausreichend viele Q-DAGs haben, um die wahrscheinliche Ursache des
detektierten Fehlers zu determinieren. Nur die notwendige Anzahl
von Q-DAGs wird repliziert, um den spezifischen Fehler zu diagnostizieren,
welches auch in einer Reduktion der erforderlichen Prozessordurchsatzleistung
während
der Fehlerdiagnose resultiert.
-
Ein
anderes wichtiges Merkmal der Erfindung ist der Verbindungsalgorithmus,
welcher bestimmt, wie jeder der Q-DAGs miteinander verbunden ist
oder Informationen austauscht, nachdem sie repliziert sind. Die
Verbindung zwischen dem dritten und zweiten Q-DAG kann unterschiedlich
sein von der Verbindung zwischen dem ersten und zweiten Q-DAG. Die
Verbindungsinformation kann die Form einer Matrix annehmen, welche
bestimmt, wie die individuellen Subsystem-Q-DAGs verbunden sind, wenn
sie einmal repliziert sind. Zusätzlich
wird jeder Q-DAG eine Datentabelle aufweisen, welche Informationen
darüber
enthält,
wie verschiedene Knoten des Q-DAGs miteinander verbunden sind. Die
Fähigkeit,
die gespeicherten Q-DAGs zu replizieren, plus der Verbindungsalgorithmus
erlaubt dem Hostsystem-Computer
einen Q-DAG für
die Fehlerisolation des gesamten Hostsystems zu konstruieren.
-
Die
Erfindung kann in jedem Hostsystem benutzt werden, welches einen
Zentralcomputer hat, der sich auf einer Vielzahl von Eingaben für Fehlerdiagnose
abstützt.
-
Er
ist insbesondere anwendbar für
Passagierunterhaltungssysteme in modernen kommerziellen Flugzeugen,
wie z.B. die Boeing 747 und Boeing 777 der Boeing
Company, welche eine hochgradig repetitive Architektur haben und
einen Wartungscomputer haben, der für Diagnosen limitierten Speicher
und Durchsatzleistung zur Verfügung
hat. Diese Onlinediagnosen erlauben die Reparatur von Hostsystemen, die
unter strengen Durchlaufreparaturanforderungen stehen. In kommerziellen
Flugzeugen müssen
die Systeme oft repariert werden, während das Flugzeug am Terminal
angedockt ist. Durch den Gebrauch des neuen Diagnosesystems kann
das eingebettete Diagnosesystem, falls ein Fehler in einem der Subsysteme
detektiert wird, das wahrscheinliche fehlerhafte Subsystem isolieren,
während
das Flugzeug in Betrieb ist. Oft kann das fehlerhafte Subsystem
repariert oder ersetzt werden, während
das Flugzeug in Betrieb ist. In anderen Fällen kann das Diagnosesystem abgefragt
werden und das fehlerhafte Subsystem kann schnell ersetzt werden,
wenn das Flugzeug landet.
-
Diese
und andere Merkmale und Vorteile der Erfindung werden für den Fachmann
augenscheinlich von der nun folgenden detaillierten Beschreibung zusammengenommen
mit den begleitenden Zeichnungsfiguren, in welchen:
-
Kurze Beschreibung
der Zeichnungsfiguren
-
1 ein
Blockdiagramm eines typischen Hostsystems ist, welches eine repetitive
Architektur hat;
-
2 ein
Blockdiagramm eines Systems ist, welches dazu genutzt wird, Q-DAGs
von kausalen Netzwerken zu generieren;
-
3 eine
Tabelle eines Teils einer Komponenten- oder Subsystembibliothek
ist, welches von dem System, das in 2 gezeigt
ist, genutzt wird, um ein Subsystemmodell zu generieren.
-
4 eine
graphische Repräsentation
eines kausalen Netzwerks für
das Subsystem ist, welches von dem System von 3 aus
dem Systemmodell generiert wurde;
-
5 eine
graphische Repräsentation
von dem Q-DAG ist, welcher von dem System der 3 aus
dem kausalen Netzwerk von 4 generiert wurde;
-
6 eine
Matrix ist, welche die Informationen darüber enthält, welche Subsysteme verbunden sind;
-
7 eine
graphische Repräsentation
von dem Hostsystem-Q-DAG ist, nachdem die Subsystem-Q-DAGs repliziert
wurden und nachdem die Matrix Informationen eingearbeitet wurden;
-
8 eine
graphische Repräsentation
ist, welche die Subsystem-Q-DAGs und Datentabellen illustriert,
welche für
das Hostsystem von 1 gespeichert wurden;
-
9 ein
simplifiziertes Blockdiagramm des umfassenden Unterhaltungssystems
(total entertainment system, TES) für ein modernes kommerzielles Flugzeug
ist.
-
10 ein
stärker
detailliertes Blockdiagramm des TES ist, welches in 9 gezeigt
ist; und
-
11 ein
Flussdiagramm des neuen Fehlerdiagnosesystems ist.
-
Detaillierte
Beschreibung der Erfindung
-
Das
neue Diagnosesystem ist anwendbar auf Hostsysteme, welche redundante
Architekturen haben, wie z.B. das System 10, das in 1 gezeigt ist,
in welchem die verschiedenen Blöcke
elektrische Subsysteme repräsentieren.
Das System 10 umfasst drei identische Subsysteme, X1 bis X3. Jedes dieser Subsysteme
ist verbunden zu zwei von sechs identischen Y Subsystemen, Y1 bis Y6. Jedes Y
Subsystem ist auch verbunden zu zwei von zwölf identischen Z Subsystemen,
Z1 bis Z12. Durch
Benutzung des neuen Diagnosesystems ist jede Klasse von Q-DAGs (d.h.
X, Y, und Z), die Anzahl der Instanzen der Klasse, und die Art,
in welcher jeder Q-DAG mit Instanzen von anderen Q-DAGs verbunden
ist, spezifiziert. Z.B. erscheint die Klasse X als drei Instanzen
X1 bis X3, von welchen
jede mit anderen Instanzen von X verbunden ist, genauso wie auch
mit zwei Instanzen von Y. Klasse Y erscheint als sechs Instanzen,
von denen jede verbunden ist mit einer Instanz von X und zwei Instanzen
von Z. Die Klasse Z erscheint als zwölf Instanzen, von welchen jede
verbunden ist mit einer Instanz von Y.
-
Ein
Q-DAG muss für
jede der Subsysteme X, Y und Z generiert werden. Wie im weiteren
ausführlicher
definiert, ist ein Q-DAG eine kompilierte Repräsentation eines kausalen Netzwerks; 2 zeigt
ein bevorzugtes System 20 für das Generieren eines Q-DAGs.
Die Schritte für
das Generieren eines Q-DAGs schließen im Wesentlichen ein: Entwickeln eines
Modells für
jedes Subsystem für
die diesbezügliche
Busstruktur und die gegenseitigen Verbindungen, Anwenden einer kausalen
Netzwerkinterferenz auf das Modell, Generieren einer kausalen Netzwerkrepräsentation
basierend auf Verhaltenscharakteristiken der Subsysteme innerhalb
des Modells, und Kompilieren der kausalen Netzwerkrepräsentation
in einen Satz von Q-DAG Dateien, welche in dem Computerspeicher
des Hostsystems gespeichert werden können.
-
Um
das Systemmodell zu entwickeln, stellt das Datenerfassungssystem 21 eine
graphische Gestaltungsschnittstelle (graphical design interface)
für das
Erfassen eines Blockdiagramms auf Systemebene und für Analyse,
Simulation und Integration zur Verfügung. Das Datenerfassungssystem
schließt eine
schematische Erfassungsmaschine 22 ein, die das Entwickeln
einer schematischen Sicht des Subsystems und seiner Komponenten
ermöglicht.
Die schematische Sicht kann eingegeben werden durch das händische
Selektieren von Primitiven oder zusammengesetzten Objekten aus einer
Datenbankbibliothek oder es kann automatisch von der Datenbank unter
Benutzung eines Gestaltungswerkzeugs einer dritten Partei erfasst
werden. Die Datenbankbibliotheken 23 stellen die Primitiven
oder zusammengesetzten Objekte bereit, welche spezifisch für das Hostsystem
gestaltet sind und stellt Verhaltensgleichungen bereit, welche die
vielfältigen
Primitiven beschreiben. 3 zeigt Beispiele von Primitiven 31, welche
in der Datenbankbibliothek gespeichert werden können, wobei die Bibliothek
eine graphische Repräsentation
des Primitivs 32 zusammen mit Verhaltensgleichungen 33 enthält. Die
Gleichungen beziehen sich auf die Eingabe und/oder Ausgabe der Primitiven, wenn
diese betriebsbereit oder in einem fehlerhaften Modus sind. Abhängig von
der spezifizierten Ebene können
die primitiven Objekte ein Tor, ein Bus oder eine komplexe leitungsaustauschbare Einheit
(line replaceable unit, LRU) sein; zusammengesetzte Objekte können aus
den verfügbaren
primitiven Objekten aufgebaut werden. Einmal aufgebaut, können zusammengesetzte
Objekte in den Bibliotheken für
Archivzwecke gespeichert werden. Das schematische Modell wird durch
das Auswählen
von Primitiven 30 und das Auswählen von zusammengesetzten
Objekten entwickelt und ein repetitiver Block wird für das System
zum Verbinden jedes Primitiven 30 mit Bussen oder Leitungen
definiert.
-
Einmal
definiert, wird das schematische Modell zu einem kausalen Netzwerkgenerator 24 weitergegeben,
welcher ein kausales Netzwerkmodell entwickelt, basierend auf den
Verhaltenscharakteristiken, welche durch das schematische Modell
bereitgestellt werden. 4 ist eine graphische Repräsentation
eines simplifizierten kausalen Netzwerkmodells 40 für das Subsystem
X1, das die vier Komponenten COMP A–COMP D
enthält.
Das Netzwerk 40 basiert sowohl auf der Architektur des
unterliegenden Systems (d.h. Subsysteme, LRUs, Busse, etc.) als auch
auf Datenflussinformationen. Das Modell zeigt die Ursache-Wirkungs-Beziehungen
zwischen Subsystemen und Komponenten, zusammen mit einer Datenbank,
welche das individuelle Verhalten jeder Komponente in Bezug auf
Eingaben und Ausgaben beschreibt. Die Ursache-Wirkungs-Beziehungen
zwischen Knoten und Eltern können
aus einer boolschen Logik oder einer bedingten Wahrscheinlichkeitsverteilung
folgen. Das kausale Netzwerkmodell kann einen Satz von abgestuften
Diagnosen für
die Fehlerbehebung von Hostsystem Ausfällen, wie z.B. ein „totes" Subsystem oder Hostsystem
Fehlerbedingungen, wie z.B. Fehler, die mit der Zeitablaufsteuerung der
Subsysteme zusammenhängen,
bereitstellen. Diese Verhaltenscharakteristiken beschreiben wie das
modellierte Subsystem unter normalen Umständen arbeiten sollte. Kausale
Netzwerke werden vollständiger
beschrieben in Darwiche A. 1998. "Model based diagnosis using structured
system descriptions. J. of Al Research, 8: 165–222, Juni 1998.
-
Mit
Bezug wiederum zu 2 wird das kausale Netzwerk
von dem kausalen Netzwerkgenerator 24 ausgegeben und zu
dem kausalen Netzwerkinterferenzsystem (causal network interference
system, CNETS) 25 weitergegeben. Das kausale Netzwerkmodell
enthält
die notwendigen Strukturen und Algorithmen für das Entwickeln einer zugehörigen kausalen
Netzwerkinterferenz. CNETS 25 führt eine domänenunabhängige kausale
Netzwerkinterferenz durch das Abbilden der Logikgleichungen in Netzwerkwerte für jedes
Primitive durch. Diese logischen Gleichungen können entweder sehr einfach
oder eher komplex sein, da große
CNETS 25 sowohl boolsche Logik als auch bedingte Wahrscheinlichkeitsbeziehungen
für das
Modellieren der Primitiven unterstützen.
-
Wenn
das Modellieren der kausalen Netzwerkinterferenz abgeschlossen ist,
wird das Modell zu einem Diagnosekompilierer 26 weitergegeben, welcher
benutzt wird, um einen kompilierten Diagnosecode zu generieren,
welcher auch Q-DAG genannt wird. 5 zeigt
eine graphische Repräsentation
eines Q-DAG 50. Die Q-DAG-Generierung basiert auf traditionellen
Algorithmen für
exakte kausale Netzwerkinterferenz, wie von den gegenwärtigen Erfindern
in den folgenden Artikeln diskutiert, Darwiche A. supra., und Adnan
Darwiche, Gregory M. Provan: Query DAGS: A Practical Paradigm for
Implementing Belief-Network Interference. J. of Al Research 6: 147–176, 1997.
-
Ein
symbolisches kausales Netzwerk zeigt einen Q-DAG 50 mit
einem UND-ODER-Baum.
Das wahrscheinlichkeitskausale Netzwerk erzeugt einen Q-DAG, der
analog ist zu dem symbolischen Q-DAG, abgesehen von den folgenden
Unterschieden: es hat Multiplikationsoperatoren (*) an entsprechenden UND-Knoten,
Additionsoperatoren (+) an entsprechenden ODER-Knoten und hat Konstanten-Knoten als Wahrscheinlichkeiten
anstatt von Annahmen. Die Knoten der Baumstruktur können in
fünf verschiedene
Kategorien klassifiziert werden; nachweisspezifische Knoten (Evidence
Specific Nodes, ESN) 51, Konstanten-Knoten (constant nodes,
CONST) 52, UND-Knoten 53, ODER-Knoten 54,
und Abfrage-Knoten 55. ESNs 51 enthalten Informationen über messbare
Zustände
und werden eingestellt, basierend auf dem gegenwärtig gemessenen Status des Systems,
das diagnostiziert wird. Z.B. kann der Knoten anzeigen, dass ein
Fehlerbericht aktiv oder inaktiv ist, oder dass ein Monitor eingestellt
oder gelöscht ist.
CONST-52-Knoten repräsentieren
die Annahmen- oder Modus-Variablen eines kausalen Netzwerks, dessen
Stati vordefiniert oder konstant sind und sind die Knoten, die die
diagnostischen Schlussfolgerungen bereitstellen. Die ESN-51- und CONST-52-Knoten
sind immer an den Blättern 56 des
Q-DAGs zu finden. Die UND-53- und ODER-54-Knoten sind dazwischenliegende Q-DAG-Knoten,
die eine logische Verknüpfbarkeit zwischen
den Blattknoten 56 und dem Ursprungsknoten 57 bereitstellen.
Schlussendlich ist ein Abfrage-Knoten 55 der Ursprung des
Q-DAGs 50 und typischerweise ein (+)-Knoten, kann aber auch ein (*)-Knoten
sein.
-
Die
Baumstruktur des Q-DAGs 50 kann in einem Softwareprogramm
repräsentiert
werden durch den Gebrauch eines Satzes von Matrizen. Die Hauptmatrix
wird Indexmatrix genannt und speichert die Knoten und die Zeiger
zu den anderen Matrizen. Die Knoten des Q-DAGs stehen in einer Eltern-Kind-Beziehung.
Z.B. hat ein Abfrage-Knoten ausschließlich Kinderknoten. Wenn ein
hypothetischer Knoten X ein Elternknoten zum hypothetischen Knoten
Y ist, ist Y das Kind von X. Nachdem Q-DAGs nicht immer als binäre Bäume repräsentiert
werden, kann jeder Knoten eine unterschiedliche Anzahl von Kindern-
oder Elternknoten haben.
-
Um
diese Variabilität
handhaben zu können, werden
die Eltern- und Kindlisten für
jeden Knoten in zwei großen
Matrizen gespeichert, die jeweils Kindermatrix und Elternmatrix
genannt werden. Separate Eltern und Kindermatrizen werden dazu benutzt, die
Liste von Eltern- und Kinderknoten für jeden der Q-DAG-Knoten zu
speichern. Jeder Knoten in der Indexmatrix wird seinen Startpunkt
in diese Matrize hinein spezifizieren, genauso wie die Anzahl von
Eltern und Kindern, die zu diesem Knoten gehören. Die Q-DAG-Knoten haben
Zeiger in diese Matrix hinein, die die Anfangs- und Endepositionen
für die
betreffenden Eltern- und Kinderlisten spezifizieren.
-
Mit
Bezug wiederum zu 2 ist der Q-DAG dann in dem
Hostsystemspeicher, als ein eingebetteter Auswerter 28 gespeichert,
welcher Statusvariablen 29 von dem Hostsystem akzeptiert,
um den Q-DAG auszuwerten. Er generiert dann einen Fehlerreport 30,
der das wahrscheinlich fehlerhafte Subsystem/Komponente identifiziert.
-
Wenn
einmal die X-, Y-, und Z-Subsystem-Q-DAGs geformt sind, muss auch
eine Ereignismatrix erzeugt werden, um Informationen darüber bereitzustellen,
wie die verschiedenen Subsysteme miteinander verbunden sind. Diese
Information ist notwendig, um die Q-DAGs miteinander zu verbinden,
zu dem Zeitpunkt, wo sie repliziert wurden. 6 zeigt
ein Beispiel einer Matrix 60 für das System von 1,
welche erzeugt wird unter Benutzung der Parameter [i, j], wobei
i die Komponenten X, Y oder Z bezeichnet und j die Instanz der Komponente bezeichnet.
A1 in der Matrix bezeichnet eine Konfigurationsbindung oder Verbindung
zwischen spezifischen Q-DAGs. Die Matrix ist als eine binäre (0,1) Matrix
in der Software repräsentiert.
Der System-Q-DAG kann nun repräsentiert
werden als der Satz von Komponenten-Q-DAGs X, Y und Z plus eine Datentabelle,
welche die Konfigurationsmatrix in 6 bereitstellt.
-
Die
Datentabelle wird auf Q-DAG-Ebene Informationen enthalten, welche über die
Matrixinformationen, welche Q-DAGs miteinander verbunden sind, hinausgehen
und spezifische Informationen über
die aktuellen Q-DAG-Knoten bereitstellt. Für jede Instanz einer Q-DAG-Klasse
schließen
die Q-DAG Informationen Daten sowohl über die Abfrage-Knoten und
die ESN-Knoten bereit, einschließlich Werten und Instantiierungen
dieser Knoten, ob diese Knoten mit Knoten in anderen Instanzen verbunden sind
und Gewichten, die zu den ESN-Knoten zugeordnet sind. Die Datentabelle
für die
Q-DAG-Klasse X wird bezeichnet als TX; 7 illustriert
graphisch die Inhalte des CMC Speichers für jede der spezifischen Subsysteme
X, Y und Z.
-
Q1, Q2 und Q3 repräsentieren
jeweils die Q-DAGs für
die Subsysteme X, Y und Z. T1, T2 und T3 repräsentieren
jeweils die Datentabellen für
die Subsysteme X, Y und Z. Die Linien zwischen den Datentabellen
sind eine graphische Repräsentation
der Verbindungen zwischen den Subsystemen und den Q-DAG-Knoten.
-
Der
Speicherplatz, der für
die Datentabelle benötigt
wird, ist abhängig
von der Anzahl der Instanzen des spezifischen Q-DAGs und der Anzahl
von Abfrage-Knoten
und ESN-Knoten. Verbindbarkeit zwischen Q-DAG Instanzen ist daher
auf Tabellenebene spezifiziert durch Instanzen von Abfrage- und ESN-Knoten,
eher als durch die Verbindbarkeit der Q-DAGs selbst. Daher ist das
Diagnosesystem, während
es das System in 1 repräsentiert, zusammengesetzt aus
Komponenten-Q-DAGs für
die Klassen X, Y und Z, Matrixinformationen für das Verbinden aller ihrer
Instanzen und einer Datentabelle, welche Knoteninformationen für jede Instanz
einschließt.
-
Durch
das Speichern von nur einem Q-DAG für jede Klasse, anstatt eines
Q-DAGs für
jede Instanz, wird der Speicher, der für das neue Diagnosesystem gebraucht
wird, stark reduziert. Z.B. braucht der traditionelle Ansatz in
einem System mit 400 Kopien von einer Klasse 1, welche jeweils 200
kB an Speicher benötigt
und 200 Kopien von einer Klasse 2, welche jeweils 300 kB Speicher
benötigt,
140 MB. Der neue Ansatz benötigt
0,5 MB eine Einsparung um mehr als 2 Größenordnungen.
-
Die
Auswertung von Q-DAGs ist eine relativ einfache Aufgabe für den Zentral-
bzw. Wartungscomputer des Hostsystems. Vor dem Betreiben des Hostsystems
werden die Subsystem-Q-DAGs und die entsprechenden Datentabellen
in dem Speicher des Zentralcomputers gespeichert. Systemnachweisvariablen
werden als Eingaben erhalten und in Echtzeit zu dem Computer weitergegeben,
welcher diese ESNs während
der Q-DAG-Auswertung benutzt. Der zentrale Computer repliziert dann
die Subsystem-Q-DAGs. Er kann entweder genügend Q-DAGs replizieren, um
das gesamte Hostsystem zu repräsentieren
oder nur ausreichende Subsystem-Q-DAGs replizieren, um das spezifische
Fehlersignal zu diagnostizieren. An dem Punkt, wo die Q-DAGs repliziert
wurden, wird auf die Datentabelleninformation zugegriffen, um die
Daten, die die verschiedenen Instanzen verbinden, bereitzustellen. Der
resultierende System-Q-DAG ist graphisch in 8 gezeigt,
die Äste,
die die Q-DAGs verbinden, repräsentieren
physische Verbindungen, wie sie durch die Konfigurationsmatrix in 6 beschrieben werden.
-
Abhängig davon,
wie Informationen zwischen den verschiedenen Subsystemen transferiert werden,
kann das neue Diagnosesystem während der
Fehlerisolierung weniger als alle Subsysteme replizieren. Z.B. kann
das Diagnosesystem, falls ein Fehler bei X2 detektiert
wird, seine Fehlerisolierung nach dem Replizieren von X1 in
X2, Y1 in Y2 bis Y4 und Z1 in Z2 bis Z8 und das Einarbeiten der Datentabelleninformationen
durchführen.
Zu dem Zeitpunkt, zu dem der System-Q-DAG konstruiert ist, wird
er, basierend auf den System/Fehlerinformationen, die zu dem Zentralcomputer
gesandt werden, ausgewertet. Jeder Annahme-Knoten in dem Q-DAG hat
ein zugeordnetes Gewicht, welches während des Diagnoseprozesses
genutzt wird. Dieses Gewicht ist entweder basierend auf den gemessenen
Stati des Systems oder wird berechnet, basierend auf den Gewichten seiner
Kinder. Die Gewichte korrespondieren zu Fehlerwahrscheinlichkeiten,
die als ganze Zahlen (integer), anstatt von Wahrscheinlichkeiten
ausgedrückt sind.
Es gibt dabei eine vorbestimmte Beziehung zwischen den Gewichten
und den Wahrscheinlichkeiten.
-
Die
CONST-Knoten benutzen ein konstantes Gewicht, das ihrem Zuverlässigkeitsgewicht
entspricht. Die ESN-Knoten stellen ihre Gewichte basierend auf den
gemessenen Stati des Systems ein. Daher wird, falls der gemessene
Status derselbe ist, wie der Status, der diesem Knoten zugeordnet
ist, das Gewicht auf „wahr" gesetzt. Jede gemessene
Variable (d.h. Fehlerbericht) kann in verschiedene Stati eingestellt
werden, so wie z.B. "aktiv" oder „inaktiv", so dass, falls
ein Fehlerreport eines aktiven ESN-Knoten auf „wahr" gesetzt ist, dann auch der entsprechende
Bericht inaktive ESN-Knoten, die in Beziehung zu dieser Variable
stehen, auf „falsch" einstellen muss.
Falls der Status der messbaren Variablen unbekannt ist, werden alle
ESN-Knoten, die mit dieser Variablen assoziiert sind, auf „wahr" gesetzt. Die Gewichte
werden dann im Baum hinauf zu den Abfrage-Knoten propagiert, indem
die Kindergewichte für UND-Knoten
addiert werden und für
ODER-Knoten das minimale Gewicht der Kinder genommen wird. Auf Basis
dieser generalisierten Struktur nutzt der Auswerter die Datentabellen,
um den Verbindungsvariablen von einer Q-DAG-Klasse zu einer anderen zu
folgen, wobei der gesamte System-Q-DAG ausgewertet wird, welcher
implizit durch die Klassen-Q-DAG-Strukturen
und die Datentabellen repräsentiert
wird.
-
Der
Q-DAG Auswerter generiert dann einen Fehlerbericht, der die möglichen
fehlerhaften Subsysteme auflistet. Der Fehlerbericht kann entweder auf
einem Monitor angezeigt werden oder in einer elektronischen Speicher-/Abfrage-Einrichtung für das Abfragen
während
Wartungsperioden gespeichert werden.
-
Das
neue Diagnosesystem kann in vielen verschiedenen Typen von Hostsystemen,
welche repititve Subsystem haben, benutzt werden, ist aber im Speziellen
anwendbar für
Flugzeugunterhaltungssysteme. 9 zeigt
ein totales Unterhaltungssystem (total entertainment system, TES) 90 für ein kommerzielles
Flugzeug, wie die Boeing 747 und Boeing 777. Das
TES hat eine repititive Architektur, die im We sentlichen eine Kopfstationseinheit
(head end unit, HEU) 92 und bis zu acht identische Bereichsverteilungssysteme
(area distribution systems) ADS1 bis ADS8 einschließt. Das
Diagnosesystem in dem TES stützt
sich auch auf einen zentralen Wartungscomputer (central maintenance
computer, CMC) 98, welcher Computerspeicher für das Speichern
der neuen Diagnosesoftware aufweist und einen Prozessor für das Annehmen
von Fehlerinformationen und das Ausführen der neuen Diagnosesoftware
enthält.
-
Im
Betrieb akzeptiert die HEU 92 Eingaben sowie z.B. Audio/Video
Medien, eine Landschaftswahlkamera oder Passagierinformationen und
distribuiert Video/Audio Informationen durch das gesamte Flugzeug über einen
Bus 94 zu ADS1 bis ADS8, wobei ADS1 die Audio/Video Information
vor den folgenden ADSen erhält,
ADS2 die Information vor den weiterhin folgenden ADSen erhält usw.
Die Information wird dann innerhalb jedes ADS zu 105 individuellen Passagiersitzen
distribuiert. Jedes ADS hat identische Subsysteme oder LRUs und
jedes hat identische Bus- und Kabelverbindungen.
-
10 zeigt
ein Blockdiagramm der HEU und der internen Subsysteme und Verbindungen
von ADS1, welches auch eine repetitive Architektur hat. Die HEU 92 distribuiert
die Audio/Video Information über
eine RF Leitung 102 und ein ARCnet 103 zu einer
Bereichsverteilungsbox (area distribution box, ADB) 104.
An der ADB 104 werden die Informationen zu fünf Kolumnen 105A bis 105E distribuiert,
von welchen jede wiederum die Informationen zu sieben Audio/Video
Einheiten (audio video units, AVUs) 106A bis 106G distribuiert.
Jede AVU distribuiert dann die Audio/Video Informationen zu einer
Passagierschnittstelle (passenger interface, PI) 107, welche die
Informationen zu drei Passagiersitzen distribuiert. Jeder Passagiersitz
hat ein Sitzdisplay 108, eine Passagierkontrolleinheit
(passenger control unit, PCU) 109, und einen Kopfhörer 110.
Jede der ADSen, das der ADS1 folgt hat dieselben Subsysteme und
Verbindungen, wie in 9 gezeigt.
-
Daher
besteht das gesamte TES aus einer HEU, bis zu acht ADBs, bis zu
280 AVUs und 280 Pls. Unter Benutzung des neuen Diagnosesystems
wird ein Q-DAG für
jedes dieser repetitiven Subsysteme entwickelt, wie oben beschrieben,
unter Benutzung des Systems, das in 2 gezeigt
ist. Dies schließt Q-DAGs
für die HEU,
eine ADB, eine AVU und eine PI ein. Es wird dann eine Datentabelle
für jeden Q-DAG
entwickelt, welche die Matrixinformationen, die anzeigt, wie die
verschiedenen Q-DAGs miteinander verbunden sind und die Q-DAG-Ebenen
Informationen über
die Q-DAG-Knoten und wie diese miteinander verbunden sind, enthält. Entsprechend müssen nur
vier Q-DAGs im Speicher zusammen mit den entsprechenden Datentabelleninformationen
gespeichert werden. Traditionellerweise würde ein gesamtes TES-Q-DAG
alle 569 Subsysteme einschließen.
Der CMC 98 wird dazu abgestellt, Systemfehler anzunehmen
und zu diagnostizieren. In anderen Ausführungsformen kann der CMC 98 Teil
des Flugcomputers sein, der die Aufgabe hat, andere Flugzeugfunktionen
auszuführen,
wie z.B. die Navigation. Der CMC 98 schließt generell
einen zentralen Prozessor für
das Ausführen
des Diagnoseprogramms, Programmspeicher für das Speichern des Diagnoseprogramms,
das Speichern von Eingaben für
das Erhalten von Betriebs- oder Leistungsdaten und das Speichern
von Informationen von den Subsystemen, ein. Der CMC 98 schließt bevorzugterweise
auch eine magnetische oder optische Speicher-/Abfrageeinheit, wie z.B. ein Diskettenlaufwerk
oder ein CD-ROM-Laufwerk ein und schließt auch ein bordeigenes visuelles
Display, wie z.B. ein Flüssigkeitskristalldisplay
(LCD) oder ein Videodisplay, ein.
-
Die
vier Q-DAGs und ihre Datentabellen werden in dem CMC Speicher zusammen
mit dem Beziehungsprogramm gespeichert. Der CMC 98 erhält Echtzeitinformationen
von Sensoren, die zu jedem Subsystem innerhalb des TES zugeordnet
sind und konvertiert diese Informationen zu Statusvariablen. Diese
Statusvariablen können
den Betriebszustand der Subsysteme reflektieren. Die Q-DAG-Dateien stellen
Diagnosen bereit, die notwendig sind, um fehlerhafte Subsysteme,
basierend auf den Statusvariablen, die von dem CMC empfangen werden,
zu identifizieren. Beim Erhalten von Systeminformationen repliziert
der CMC die notwendige Anzahl von Q-DAG-Instanzen und vereinigt
damit die Datentabelleninformationen für jeden Q-DAG. Der Q-DAG wird
dann ausgewertet und ein Bericht, der das wahrscheinlich fehlerhafte
Subsystem anzeigt, wird dann in dem CMC Speicher gespeichert oder
angezeigt.
-
In
dem TES werden Video und Audio-Informationen seriell zu den ADS
gesendet. Als Ergebnis brauchen nicht alle Subsysteme repliziert
werden, um eine Diagnose analyse auszuführen. Z.B. werden, falls ein
Fehler in dem fünften
ADS Block delektiert wird, vier ADB Q-DAGs von dem ADB Q-DAG, der
im Speicher gespeichert ist, repliziert. Die gespeicherten AVU-
und PI-Q-DAGs werden jeweils 174-mal
repliziert. Die Matrix und Q-DAG-Ebenen-Informationen werden abgefragt,
um Q-DAG-Verbindungsdaten bereitzustellen. Unter Benutzung des neu
konstruierten Q-DAGs, welcher ADS1 bis ADS5 abdeckt, wird eine Determinierung
durchgeführt,
ob der Fehler, der in ADS5 detektiert wurde, ein Ergebnis eines Fehlers
bei ADS5 ist oder das Ergebnis eines Fehlers bei einer der vorhergehenden
ADSen ist. Daher führt der
Q-DAG Auswerter eine aufsteigende („Up-Stream") Diagnose durch, bevor der fünfte Q-DAG
diagnostiziert wird.
-
11 zeigt
ein Flussdiagramm für
die Erfindung sowohl für
Offline als auch für
Online. Im ersten Schritt 121 wird der Q-DAG Offline durch
das System 20, das in 2 gezeigt
wird, generiert und die entsprechende Datentabelle generiert. In
dem nächsten Schritt 122 werden
die Q-DAGs und die Datentabellen in dem Hostsystemspeicher, gewöhnlicher
Weise der CMC-Speicher, gespeichert. Im Betrieb detektiert der CMC
einen Fehler 123 und repliziert dann die notwendige Anzahl
von Q-DAGs 124. Die Datentabelleninformation wird dann
abgefragt 125, um einen System-Q-DAG zu erzeugen. Der Q-DAG
wird dann ausgewertet 126 unter Benutzung der detektierten Fehlervariablen
und eine Liste von wahrscheinlich fehlerhaften Subsystemen wird
auf dem Host-System-Display angezeigt oder in Speicher 127 für die spätere Abfrage
durch die Wartungsmannschaft gespeichert. Wenn dieser Ablauf komplettiert
wurde, wird die generierte Q-DAG Information gelöscht, bis ein weiterer Fehler
detektiert wird; zu diesem Zeitpunkt wird diese Operation wiederholt.
Dieser Prozess kann auch in einem vorbestimmten Wartungsintervall
komplettiert werden. Durch das Löschen
des Q-DAGs bewahrt das Diagnosesystem wertvollen Computerspeicher.
-
Obwohl
die vorliegende Erfindung in beträchtlichem Detaillierungsgrad
mit Referenz zu bestimmten spezifischen Konfigurationen der Erfindung beschrieben
wurde, sind andere Versionen möglich. Daher
soll der Rahmen der anhängenden
Ansprüche nicht
durch spezifische beschriebene Ausführungsformen limitiert sein.