DE19857894A1 - Flugkörper - Google Patents

Abstract

Bei einem Flugkörper sind zur Erhöhung der Verfügbarkeit des Flugkörpers Mittel zur Funktionsüberwachung, Fehlerdetektion und -lokalisierung und Rekonfiguration der Flugkörper-Hardware und -Software vorgesehen. Dafür können verschiedene an sich bekannte Verfahren angewandt werden, die z. B. bei Flugreglern der Erhöhung der Sicherheit dienen.

Description

Einleitende Bemerkungen

An Flugkörper werden als Teil eines integrierten Missions-Systems (IMS) außer den üblichen generellen Anforderungen (wie sehr gute Leistungsdaten, niedrige Kosten, geringes Gewicht, kleines Volumen) zunehmend besondere Forderungen wie hohe Verfügbarkeit, Erhalt der Leistungsfähigkeit über eine lange Lebensdauer, lange Lagerzeit ohne Leistungsverlust, möglichst große Wartungsintervalle, gestellt.

Die Konsequenz aller dieser Forderungen ist eine entsprechend hohe Zuverlässigkeit des Flugkörpers und seiner Sub-Systeme mit Hard- und Software-Elementen. Unter Zuverlässigkeit eines Systems, Sub-Systems etc. wird dessen Fähigkeit verstanden, eine vorgegebene Funktion innerhalb ebenfalls vorgegebener Grenzen und für eine bestimmte Zeit zu erfüllen. Als Maßzahl für die Zuverlässigkeit wird üblicherweise die Mean-Time Between Failure (MTBF) oder deren Reziprokwert (Ausfälle pro Zeiteinheit) als Ausfallrate benutzt.

Die MTBF ermittelt sich auf der Basis wahrscheinlichkeitstheoretischer Zusammenhänge, auf die hier nicht eingegangen werden muß, da diese Stand der Technik sind.

Weiterhin ist der Begriff der o. g. Verfügbarkeit zu klären. Sie ist die Wahrscheinlichkeit dafür, das betrachtete System, Sub-System etc. zu einem bestimmten Zeitpunkt in funktionsfähigem Zustand anzutreffen. Auch sie ermittelt sich aufgrund wahrscheinlichkeitstheoretischer Zusammenhänge. Es soll einmal angenommen werden, daß stets Abfolgen gemäß Fig. 1 vorliegen. Dann läßt sich die Verfügbarkeit in einer vereinfachten Form (stationäre Verfügbarkeit) ohne Abhängigkeit von einem bestimmten Zeitpunkt angeben als

Darin ist MDT die Mean Down Time, d. h. die mittlere Ausfallzeit. Sie setzt sich aus der mittleren Zeit zur Fehlerentdeckung und der mittleren Zeit zur Fehlerreparatur zusammen.

Es wurde bereits erwähnt, daß die zuvor genannten Attribute eine sehr hohe Zuverlässigkeit fordern, mit der dann eine hohe Verfügbarkeit einher geht, falls die MDT klein ist, was durch leistungsfähige Methoden für die Fehlerentdeckung und Lokalisierung unterstützt wird.

Die Entwicklung und Herstellung eines hochzuverlässigen Systems erfordert einen sehr hohen Aufwand und entsprechende Kosten. Wegen der statistischen Natur der genannten Zuverlässigkeitmaße besteht immer eine gewisse Wahrscheinlichkeit dafür, daß ein für hohe Zuverlässigkeit ausgelegtes System kurzfristig ausfällt.

Wesentlich effektiver und kostengünstiger ist deshalb der Weg die hohe Zuverlässigkeit eines Systems durch Fehlertoleranz zu erreichen. Ein fehlertolerantes System besitzt die Fähigkeit, seine spezifizierte Funktion auch beim Auftreten von Hardware- und/oder Software-Fehlern uneingeschränkt fortzusetzen.

An dieser Stelle ist es sinnvoll, den etwas unscharfen deutschen Begriff "Fehler" durch die englischen Begriffe "fault, error, failure" zu ersetzen und diese im folgenden auch weiter zu verwenden.

Es gibt einen Ursache-Wirkung-Zusammenhang zwischen diesen Begriffen, der in Fig. 2 erklärt ist. Faults verursachen danach errors und errors ihrerseits failures. Ein fault ist ein Defekt, der in der physikalischen Welt des Systems auftritt; einige Ursachen sind in Fig. 2 gezeigt. Auftretende faults manifestieren sich als errors in der informationstechnischen Welt des Systems und äußern sich als Unkorrektheiten der im System generierten (aus Sensoren), verarbeiteten, angezeigten und zur Ausführung von Aktionen benutzten Informationen. Die errors führen ihrerseits zu failures in der externen (bezogen auf das System) Nutzerwelt.

Auch beim Entwurf fehlertoleranter Systeme sind alle Maßnahmen zur Vermeidung von faults (fault-avoidance) von höchster Bedeutung. Weiterhin ist es wichtig, durch geeignete Mittel und Maßnahmen zu verhindern, daß auftretende faults sich zu errors fortpflanzen können. Schließlich ist das Hauptziel der Fehlertoleranz failures des Systems zu verhindern und damit die Verfügbarkeit des Systems zu gewährleisten.

Der generelle Ansatz zur Fehlertoleranz besteht in der Implementierung von Mitteln zur Detektion und Lokalisierung von faults und der anschließenden Rekonfiguration des Systems. Voraussetzung für die Rekonfiguration sind verschiedene Formen der Redundanz durch Verwendung zusätzlicher Information, Ressourcen und Zeit gegenüber dem Aufwand der für die eigentlichen Systemfunktionen erforderlich ist.

Im folgenden Teil dieses Kapitels geht es um die Anwendung neuartiger wissensbasierter Elemente wie Neuronale Netze, Fuzzy Assoziativspeicher, Fuzzy Neuronale Netze zur Detektion und Lokalisierung von faults und errors sowie zur Rekonfiguration des Flugkörpersystems. Dabei müssen die zur Implementierung der Fehlertoleranz zusätzlich benötigten Maßnahmen natürlich in einem für zukünftige Flugkörper vertretbaren Rahmen bleiben.

Als abgekürzter Sammelbegriff für die zuvor genannten Fuktionen wird die Bezeichnung "FDIR" (fault detection, identification and reconfiguration) eingeführt.

FDIR-Elemente der Flugkörper-Missionseinheit und des Flugkörpers

Generelle Problemstellung ist es, mit allen im Flugzeug und im Flugkörper zur Verfügung stehenden Mitteln die Zuverlässigkeit und Verfügbarkeit eines Flugkörpers automatisch in Echtzeit zu beurteilen und in die Entscheidungsunterstützung des Piloten für den Einsatz eines Flugkörpers mit einzubeziehen. Dabei geht es natürlich in erster Linie und auschlaggebend um die FDIR-Mittel im Flugkörper selbst (möglichst autonomer Flugkörper), jedoch auch um die in der FMW. Zur Veranschaulichung der Problematik zeigt das Blockdiagramm in Fig. 3 die Funktionselemente im Flugkörper und im Flugzeug, die zum Einsatz eines zukünftigen Hochleistungsflugkörpers bzw. zu dessen Einsatzvorbereitung erforderlich sind. Weiterhin ist angenommen, daß über DATA-LINK ein Sog. "Third Party Targeting" möglich ist.

Flugkörper und Flugzeug sind Teil eines hoch-integrierten Missionssystems. Eine hohe Verfügbarkeit dieses Missionssystems erfordert eine hierarchische System-Management- Struktur wie in Fig. 4 vereinfacht dargestellt ist. Dieses System-Management umfaßt mit dem Integritäts- und Redundanzmanagement die FDIR-Konzeption und Implementierung für das Gesamtsystem und deren Verteilung auf die funktionalen und physikalischen Systeme, Sub-Systeme, Elemente etc. bis runter zu austauschbaren Baugruppen.

Ein auf alle Ebenen des IMS anwendbares vereinfachtes Blockdiagramm zur Implementierung der FDIR-Funktionen zeigt Fig. 5. Dort sei zunächst auf die Mittel zur Hardware- und Sub-System-Überwachung hingewiesen, wobei letztere natürlich auch Software-Module enthalten. Mit Hilfe des heute üblichen Built-In-Test (BIT) werden definierte Signale überwacht, bei redundanten Informationen durch Mehrheitsentscheidungen Fehler detektiert und je nach Redundanz auch lokalisiert. Zur Unterstützung der Signalüberwachung sind auch Plausibilitätsprüfungen üblich.

Neuere Ansätze bieten die Möglichkeit Wissens-, Modell-, Muster- und Paritäts-basierte Methoden zur fault Detektion und Identifikation (FDI) in Echtzeit zu implementieren.

Von besonderer Bedeutung ist auch die Überwachung der operationellen Software, da diese einen immer bedeutenderen Teil der Systeme, Sub-Systeme und Module ausmacht.

Die Ergebnisse der Detektions- und Identifikationsmaßnahmen werden einem Schlußfolgerungs- und Entscheidungsmodul zugeführt, in dem gewissermaßen laufend ein Bild über den Verfügbarkeitszustand der Systemelemente und damit des betreffenden Systems erzeugt wird. Dieses ist die Basis für eine je nach Fehlerzustand notwendige Rekonfiguration des Systems mit dem Ziel, eine möglichst uneingeschränkte Funktion wie spezifiziert aufrechtzuerhalten.

Konzeptionelle Ansätze zum Entwurf und zur Realisierung von FDIR-Elementen für zukünftige Flugkörper

Der Flugkörper muß als weitgehend autonome Einheit unabhängig von der FME über ein leistungsfähiges, eigenes BIT-FDIR-System verfügen.

Es wird zunächst davon ausgegangen, daß der Flugkörper leistungsfähige BIT-Mittel enthält. Als Voraussetzung für eine hohe Verfügbarkeit werden im folgenden neuartige Konzepte für FDIR-Maßnahmen im Flugkörper beschrieben, die mit den zuvor eingeführten wissensbasierten Elementen zu realisieren sind und das BIT im Sinne der FDIR entscheidend ergänzen. Der Status des BIT und der FDIR wird in der Phase vor dem Abschluß zur FME übertragen. Die FDIR-Struktur ist in Fig. 6 dargestellt. Die vorgeschlagenen Konzepte beziehen sich auf die Sensorik, die Regelung und Lenkung, die Software sowie auf die Aktuatoren.

Sensorik

Die Sensorik eines Flugkörpers läßt sich unterteilen in die Sensorik zur Messung des Eigenbewegungszustands in einem vorgegebenen Bezugssystem und solche zur Zielentdeckung und Verfolgung.

Die Eigenbewegung wird mit Inertialsensoren zur Beschleunigungs- und Drehgeschwindigkeitsmessung erfaßt. Zukünftig eingesetzte Sensortechnologien umfassen Lichtleiter-Drehgeschwindigkeitssensoren sowie mikromechanische Drehgeschwindigkeits- und Beschleunigungssensoren in Quarz und Siliziumtechnologie.

Darüberhinaus werden in einigen Fällen GPS-Systeme (Global Positioning Satellite (GPS)) zur genauen Positionsbestimmung eingesetzt werden.

Zukünftige Suchköpfe zur Zielerfassung und Verfolgung werden entweder als fortschrittliche Infrarot-Sucher mit Bildverarbeitung, als ebenfalls bildverarbeitende Radarsucher oder im Sinne einer synergetisch komplementären Multi-Sensorik als kombinierte Infrarot/Radar-(passiv/aktiv)Sucher aufgebaut sein. Dabei können zukünftige Infrarot-Sucher auch eine Laserkomponente zur Abstandsmessung in der Endphase der Flugkörper-Ziel-Bewegung beinhalten.

Es soll hier von den folgenden Annahmen ausgegangen werden:
Die zur Fehlertoleranz und als Voraussetzung für eine Rekonfiguration notwendige Redundanz in der Messung von Eigenbewegungszustandsgrößen wird durch folgende Maßnahmen alternativ oder in Kombination erreicht:
Vermehrfachung der Inertialsensoren (Drehgeschwindigkeit, Beschleunigung). So wird z. B. das Degradationsverhalten "fail-operational" mit jeweils minimal 5 (statt 3) Drehgeschwindigkeits- und Beschleunigungssensoren erreicht, wobei diese in einer speziellen Geometrie zu den Flugkörperachsen angeordnet sein müssen. Insbesondere bei mikro-mechanischen Sensoren ist dieser zusätzliche Aufwand gering und auch bei Verlustobjekten zur Steigerung der Verfügbarkeit in jedem Falle zu vertreten.

Multi-Kanal-GPS (z. B. 6-10 Kanäle), so daß auch redunte GPS-Information verfügbar ist, die zur Überwachung und zur Auswahl der momentan günstigsten GPS-Kanäle benutzt werden kann.

Bewegungsinformation auch aus den Infrarot- und Radarsensoren.

Ein Konzept der Sensor-FDI im Zusammenhang mit der Messung des Eigenbewegungszustands zeigt Fig. 7.

Mit Hilfe der Neuronalen Netzwerke werden Sensorfehler detektiert und lokalisiert, so daß die Sensorinformation fehlertolerant zur Gewinnung der Bewegungszustandsgrößen rekonfiguriert werden kann.

Der Meßvektor m umfaßt die Ausgangssignale der Sensoren. Er ist eine Funktion des physikalischen Bewegungszustands des Flugkörpers, dem im Fehlervektor ε zusammengefaßte Fehler überlagert sind, so daß m = f(x, ε), mit x als Bewegungszustandsvektor. Der Fehlervektor ε kann Sprung- oder rampenförmig sowie stochastische Fehler beinhalten und weiterhin Totalausfälle wie Meßsignal null oder konstanter Vollausschlag abbilden.

Im ersten Neuronalen Netzwerk wird durch Projektion des Meßvektors in den zum Meßraum orthogonalen Fehlerraum (Paritätsraum) eine Trennung von Nutzsignal (m(x)) und Fehler (m(ε)) durchgeführt und damit ein Merkmals- oder Validierungsvektor (v) erzeugt, auf den sich Fehler abbilden. Damit kann durch dieses Netzwerk bereits eine Detektion erfolgen.

Mit dem Merkmalsvektor als Eingangsgröße erfolgt im zweiten Netzwerk die Lokalisierung eines aufgetretenen Fehlers, d. h. der defekte Sensor(-Kanal) wird identifiziert. Damit hat dieses Netzwerk die Funktion eines Klassifikators bezogen auf den Fehlerraum, in dem die Merkmalsvektoren auf bestimmte Fehler-Cluster zeigen.

Die Netzwerke werden mit Vorwissen aus einer analytischen Lösung des FDI-Problems ausgestattet und dann in einer Trainingsphase entweder durch Simulation der Sensorik und typischer Fehler oder mit der realen Sensorik mit simulierten Fehlern trainiert. Bemerkenswert ist, wie erste Untersuchungen gezeigt haben, daß die Netzwerke nicht nur Einzelfehler sondern Simultanfehler oder kurz aufeinanderfolgende Fehler detektiert und lokalisieren können. Darüberhinaus sensieren und lokalisieren sie das Verschwinden von vorübergehenden Fehlern, z. B. infolge starker Manöver, so daß die Sensorik selbstregenerierend arbeiten kann.

Ausgangsgröße des zweiten Netzwerks ist der Lokalisierungs-/Identifikations-/Klassi­ fikationsvektor. Er wird - möglicherweise zusammen mit dem Merkmalsvektor - einen Entscheidungsnetzwerk zugeführt, das vorzugsweise als Fuzzy-Neuronales- Netzwerk realisiert werden sollte.

Diesem Netzwerk werden außerdem die gemessenen (nicht die berechneten!) Kovarianzsignale des Kalman-Filters (oder SDRE-Filters (State Dependent Riccati Equation) zugeführt, mit dessen Hilfe die GPS- und Inertialsensordaten optimal integriert werden. In den Kovarianzen der Meßdifferenz bilden sich sowohl Meßfehler als auch Sensorausfälle ab. Die Verläufe dieser Signale können deshalb nutzbringend bei der Entscheidung ob Fehler aufgetreten sind und wenn ja, wo, mit einbezogen werden.

Gleiches gilt für die Verläufe der Kovarianzen des für die Initialisierung und Kalibrierung des Flugkörper-Inertialsystems (MSL-IRS) zu implementierenden Kalman- Filters. Wie im Kapitel . . . . . . . beschrieben, verarbeitet dieses Filter Informationen vom Flugzeug-Inertialsystem sowie des MSL-IRS. Die Kovarianzsignale sind damit ein Maß für die Funktion und die momentane Güte des MSL-IRS.

Die dem Entscheidungsnetzwerk zugeführten Signale sind stochatische Variable mit Mittelwert und Varianz. Durch faults verändern sich diese Werte. Üblicherweise werden diese Symptome beim Überschreiten eines vorgegebenen Schwellwertes zur (binären) Entscheidung für das Auftreten eines fault herangezogen. Es läßt sich eine geringere Falschalarmrate durch die Einführung eines fuzzy-Schwellwertes erreichen, wie veranschaulicht durch die Darstellungen in Fig. 8. Dadurch steht ein graduelles Maß für das Überschreiten eines Schwellwertes zur Verfügung, das in Kombination Veränderungen der Varianz und des Mittelwertes berücksichtigt.

Aufgabe des Entscheidungsnetzwerkes ist es, aus den analytischen (Symptom-)Signalen (z. B. Identifikationsvektor) und heuristischem Wissen (regelbasiert) über die betreffenden Sensoren und ihr Zusammenwirken im System (Systemdaten und Fakten) eventuelle faults nach Typ, Ort und Zeitpunkt des Auftretens zu identifizieren. Hierzu ist eine einheitliche Darstellung der Symptome wichtig. Dies wird wiederum durch fuzzy- Logik möglich, indem sowohl analytische als auch heuristische Symptome durch Zugehörigkeitsfunktionen zu fuzzy-Mengen für die Entscheidungsfindung einheitlich repräsentiert werden.

In Fig. 9 ist eine Repräsentation gezeigt, bei der die Zu- oder Abnahme eines Symptoms oder Merkmals durch Einführung linguistischer Wertebereiche (fuzzy-Mengen) wie z. B. "stark angewachsen (much increase)", mit assoziierten Zugehörigkeitsfunktionen beschrieben wird. Die analytischen und heuristischen Symptome oder Merkmale wurden so einheitlich fuzzyfiziert für eine Weiterverarbeitung in der Inferenzeinheit. Diese ist Teil der fuzzy-Logik-Einheit in Fig. 10, die ihrerseits das wesentliche Element des Entscheidungsnetzwerks ist.

Zur Entscheidungsfindung werden nach den Gesetzen der fuzzy-Logik "IF (Prämisse) . . .. THEN (Konsequenz)" Regeln verknüpft (fuzzy reasoning), die den logischen Zusammenhang zwischen beobachteten Symptomen oder Merkmalen und den faults beschreiben. Die Abbildung aufgetretener faults auf beobachtbare Symptome oder Merkmale folgt physikalischen Ursache-Wirkung-Zusammenhängen (Fig. 2), wobei häufig die analytische Beschreibung dieser Zusammenhänge sehr schwierig ist.

In diesem Falle ist der Einsatz lernfähiger Netzwerkstrukturen angezeigt. Darüberhinaus kann - wie bereits erwähnt - heuristisches Wissen in Form von IF . . . THEN-Regeln zur linguistisch-qualitativen Beschreibung der Zusammenhänge ganz wesentlich mit einbezogen werden.

Der auf den ersten Blick kompliziert scheinende Aufbau der fuzzy Logik Einheit (Fig. 10) führt zu einer einfachen hardware-mäßigen Realisierung als Fuzzy Neuronales Netzwerk, wie in Fig. 7 in dem Block des Entscheidungsnetzwerks angedeutet.

Das Ausgangssignal des Entscheidungsnetzwerks ist der Sensor Status Vektor, mit dessen Hilfe die Signale der jeweils intakten Sensoren zur Weiterverarbeitung im System (re-)konfiguriert werden können.

Das hier bisher beschriebene Konzept zur Sensor FDIR ist eine Paritätsvektor-basierte, Merkmal-gestützte, wissensbasierte Methode. Sie kommt ohne jede mehr oder weniger aufwendige Sensor- oder Subsystem-Modellierung aus. Weiterhin zeichnet sie die Fähigkeit zur Detektion und Lokalisierung gleichzeitiger oder in kurzer Folge auftretender Fehler aus, mit der Möglichkeit der Selbstregeneration.

Die zur Implementierung notwendigen drei Netzwerke (Fig. 7) sind in Hardware als ASICS realisierbar, so daß Probleme mit Software Zuverlässigkeit an dieser Stelle vermieden werden können. Durch die Hardware-Realisierung sind die Netzwerke schnell und fehlertolerant (parallele Struktur) sowie kostengünstig produzierbar. Sie sind an Veränderungen anpaßbar durch Lernen und nicht durch Umprogrammieren.

Das hier beschriebene Sensor FDIR Konzept setzt Sensor-Redundanz (similar oder dissimilar) voraus. Es kann in seiner grundsätzlichen Struktur auch für die Multi Sensorik zur Zeiterfassung sowie für nicht redundante Sensorkonfiguration angewendet werden. Letzteres erfordert allerdings analytische Redundanz mit Model-basierten Ansätzen, wobei wiederum auf wissensbasierte Darstellungen zurückgegriffen werden kann.

Informations- und Datenverarbeitung Hardware

Die Prozessor- und Speicherhardware wird mit üblichen, bewährten BIT-Mitteln überwacht. Fehlertoleranz ist durch Vermehrfachung mit mechanischer und elektrischer Segregation in Verbindung mit Voting/Monitoring Techniken grundsätzlich implementierbar. Wegen der Zuverlässigkeit der betreffenden Hardware Bausteine auch bei langer Lagerung kann auf diese Maßnahme zur Gewährleistung der Verfügbarkeit verzichtet werden.

Beachtenswert ist jedoch die Tatsache, daß die Speichermodule (EEPROMS, FLASHPROMS) bei langer Lagerfähigkeit (< 10 Jahre) ihre Inhalte teilweise oder sogar ganz verlieren können. Diesem kann jedoch ggfs. durch Wiederladen der Software bei der Einsatzvorbereitung Rechnung getragen werden.

Wegen des bekannten Verlaufs der Zahl der Ausfälle über der Nutzungszeit bei Hardware Bauteilen (sog. "Badewannenkurve") treten Hardware faults statistisch gesehen nach einer exponentiellen Wahrscheinlichkeitsverteilung auf. Sie sind damit statistisch vorhersagbar, so daß die Verfügbarkeit des betreffenden Systems in diesem Punkt durch präventive Wartungsmaßnahmen gewährleistet werden kann.

Software

Die top-down Software Struktur für die Hauptkontroll-, Lenk- und Regelfunktionen des Flugkörpers ist stark vereinfacht in Fig. 11 dargestellt.

Im Gegensatz zur Hardware treten Softwarefehler nach völlig anderen Gesetzmäßigkeiten auf. Sie "schlummern" latent von Anfang an im System und werden bei bestimmten Kombinationen der Eingangsgrößen und der inneren Zustandsgrößen des betreffenden Moduls getriggert. Auch bei umfangreichen Maßnahmen zur Verifikation und Validierung können sie nicht vollständig identifiziert und beseitigt werden.

Aufwendige Techniken wurden und werden angewendet, um Software faults zu vermeiden, wie z. B. die sog. "N-Version Programmierung", bei der dissimilare Software in N redundanten Software- und Hardware-Kanälen verwendet wird. Wegen des extrem hohen Entwicklungs- und Implementierungsaufwands ist dieser Weg für Flugkörperanwendungen ausgeschlossen.

Es soll hier deshalb eine alternative Möglichkeit zur Implementierung von Software fault Toleranz und damit ein Potential zu verbesserter Verfügbarkeit des Flugkörpers aufgezeigt werden. Dieser Ansatz basiert auf der zuvor erwähnten Erkenntnis, daß nicht alle Software Entwurfs- und Implementierungsfehler während der Test- und Validierungsphase identifizierbar sind. Da Software faults durch bestimmte Eingangsdaten getriggert werden, geht das hier vorgeschlagene Konzept von minimal zwei Software-Versionen aus, denen nicht identische Eingangsdaten zugeführt werden (data diversity). Die technische Umsetzung dieses Konzepts wird im folgenden beschrieben. Die Struktur ist vereinfachend in Fig. 12 veranschaulicht.

Zum Zeitpunkt "nT" (n-te Iteration) werden im Kanal 1 von der Nominalsoftware (N) mit den Eingangsdaten des Zeitpunkts "nT" die Ausgangsgrößen ρ _n-1, berechnet, während das Nominalprogramm in Kanal 2 verzögerte Eingangsdaten erhält (N_n-1) und damit ρ _n-1, berechnet.

Zur Überprüfung der Korrektheit der Ausgangsdaten ρ _n ^N der Nominalsoftware zum Zeitpunkt "nT" (N_n) wird eine Monitorversion (M) der Nominalsoftware eingeführt. In den beiden Softwarekanälen werden mit dem M-Programm ebenfalls Ausangsgrößen mit momentanen (M_n) bzw. verzögerten Eingangsdaten (M_n-1) berechnet.

Die M_n-, N_n-Softwarestruktur in Fig. 12 ist eine Duo-Duplex-Konfiguration für die Software. Im Gegensatz zur Hardware Redundanz mit räumlicher Separation der Module erfolgt hier eine zeitliche Segregation durch unterschiedliche Eingangssignale (data diversity).

Die Überwachung der Software, die Detektion von faults sowie die Rekonfiguration zur Erzeugung nutzbarer fehlerfreier Ausgangsgrößen ist in Fig. 13 als konzeptioneller Vorschlag dargestellt. Zum Zeitpunkt der n-ten Iteration werden, wie bereits erwähnt und in Fig. 12 gezeigt, mit den momentanen bzw. verzögerten Eingangsdaten die Ausgangsgrößen ρ _n ^N, ρ _n ^M bzw. ρ _n-1 ^N _, ρ _n-1 ^M, berechnet.

Mit prädizierten Ausgangsgrößen p _n ^N, p _n ^M können in der Form von Differenzen eine Reihe von Symptomsignalen berechnet werden, die zur Detektion inkorrekter Ausgangsgrößen des Nominalprogramms (N_n) mit den momentanen Eingangsgrößen dienen können. Prinzipiell ist mit der Prozedur in Fig. 13 auch die Korrektur der Ausgänge des M-Programms überprüfbar.

An dieser Stelle ist folgende Anmerkung wichtig: Die zuvor erwähnten latenten Software faults (Entwurfs- und/oder Implementierungsfehler) können zusammenhängen mit der Auswahl der Algorithmen, der Art der Erstellung des Quellenprogramms oder - jedoch eher unwahrscheinlich - durch Compilerfehler verursacht sein. Aus diesen Gründen ist es sehr wichtig, daß die Monitorsoftware alternative Algorithmen und/oder Strukturen für alle algorithmischen, logischen sowie Ein-/Ausgangsmodule gegenüber dem N- Programm enthält. Hierauf wird später noch näher eingegangen. Wegen dieser Situation ist es sehr unwahrscheinlich - ja praktisch ausgeschlossen - daß bei gleichen Eingangsdaten sowohl das N- als auch das M-Programm unkorrekte Ausgangsgrößen liefern.

Die zuvor genannten Symptomsignale können nun in einer Fuzzy Entscheidungslogik, wie im vorangehenden Abschnitt erläutert, zur Generierung eines Software Status Vektors benutzt werden. Je nach Software Status (Fig. 13) werden die verfügbaren korrekten Daten zur Erzeugung der Ausgangsgröße rekonfiguriert.

Monitorsoftware

Die Monitorsoftware sollte einfache algorithmische und logische Elemente (Standardmodule) verwenden, die in generell validierbaren Strukturen angeordnet eine Vielzahl von (softwaremäßigen) Problemlösungen abbilden können. Diese Voraussetzungen erfüllen in geradezu idealer Weise Neuronale Netze und Fuzzy Neuronale Netze. Sie definieren eine vorgegebene Standardstruktur mit einheitlichen, einfachen Prozessorelementen.

Die freien Parameter der Struktur werden in einer Trainingsphase eingestellt. Dabei werden als Trainingsdaten Ein- und Ausgangsvektoren der Ein- bzw. Ausgangsvektorräume des betreffenden zugehörigen Nominalsoftware Moduls verwendet. Es besteht die Möglichkeit, durch genetische/evolutionäre Algorithmen die Struktur und/oder die Parameter nach vorgegebenen Kriterien zu optimieren. Damit ist eine automatische Erzeugung der Monitorsoftware möglich. Zum ebenfalls automatischen Test der generierten Software werden andere als die Trainingsvektoren aus den Ein-/Ausgangsräumen benutzt (Fig. 14).

Natürlich ist diese Methode ganz generell zur automatischen Erzeugung von Softwaremodulen anwendbar!

Die Monitorsoftware wird auf der Basis einer Neuronalen oder Fuzzy Neuronalen Netzwerkstruktur generiert. Damit bietet sich die Realisierung des M-Software-Moduls als Hardware-Modul an (z. B. ASIC). Dies hat folgende Vorteile:

• - Die Zuverlässigkeit des Moduls kann nach den Gesetzen des Ausfalls von Hardware beurteilt werden.
• - Es wird keine Software zur Überwachung von Software verwendet.
• - Die parallele Informationsverarbeitung in der Hardware liefert - in gewissen Grenzen - eine inhärente Fehlertoleranz des Moduls.

Wegen dieser Attribute liegt folgendes Konzept als Schlußfolgerung nahe:

• - Ersatz auch der Nominalsoftware Module durch Ein/Ausgangs-abbildungsgleiche Hardware Module, wo immer dies möglich ist.
• - Vermehrfachung dieser Hardware Module dort, wo die inhärente Fehlertoleranz zur Erzielung der erforderlichen Zuverlässigkeit und damit Verfügbarkeit nicht ausreicht. Damit entfallen die Monitormodule.
• - Die Software ist auf Hardware Module hoher Zuverlässigkeit abgebildet, wobei die Anpassung an unterschiedliche Aufgaben durch Lernen erfolgt.

Bemerkenswert ist, daß dieses Konzept durch die fortschrittlichen Ansätze im Bereich der Lenkung und Regelung von Flugkörpern nachhaltig unterstützt wird. Es werden dort gegenwärtig optimale, lernfähige Strukturen in Form Neuronaler und Fuzzy Neuronaler Netze für die Regelung und Lenkung zukünftiger Flugkörper in Betracht gezogen.

Aktuatoren

Auch im Falle der Implementierung einer Multi-Aktuatorik mit aerodynamischen Rudern, Jet-Vanes zur Schubvektorregelung sowie Querschubtriebwerken wie in Fig. 15 gezeigt, ist die Aktuatorik zur Beeinflussung der Flugkörperbewegung nur simplex vorhanden. Weder die aerodynamischen Ruder noch die Jet Vanes und schon gar nicht die Querschubtriebwerke sind als Einzelaktuator in der Lage, den Flugkörper in den verschiedenen Flugphasen zu regeln und zu lenken.

Damit ist das Stellsystem eines Flugkörpers als Simplexkonfiguration zu betrachten, so daß in diesem Punkt praktisch keine Rekonfigurationsmöglichkeit besteht. Umso wichtiger ist es, außer dem üblichen Monitoring Maßnahmen zur "intelligenten" FDI mit dem Ziel in Erwägung zu ziehen, die Wahrscheinlichkeit für die Detektion und Lokalisierung von faults in der Vorflugprüfung sowie möglichst bis unmittelbar vor dem Abgang zu erhöhen.

Wie in Fig. 16 angedeutet, muß zwischen externen und internen faults unterschieden werden (externe: z. B. Beschädigung durch Kollision, Stromversorgung; interne: z. B. Getriebe, Lager, nicht ausreichende Schmierung, Komponentenfehler).

Wie bereits erwähnt, kann durch Monitoring eine erste Überwachung erfolgen, wobei durch Messung bestimmter Signale (z. B. Eingangsstrom, Auslenkung) und Vergleich mit vorgegebenen (fuzzy) Toleranzschwellen (Fig. 8) eine generelle Aussage über die Funktion des Aktuators.

Eine Verbesserung der fault Detektion und vor allem auch die Möglichkeit einer Lokalisierung erscheint zukünftig mit Hilfe wissensbasierter Elemente realisierbar. Dabei wird - wie in Fig. 16 gezeigt - von der neuronalen oder fuzzy-neuronalen Implementierung nichtlinearer (Reibung, Hysterese, Begrenzung) dynamischer Zustands- und Parametermodelle ausgegangen. Primär durch die Messung im Aktuator zugänglicher Signale, möglicherweise ergänzt durch Informationen aus dem Lenk- und Regelteil, erfolgt eine Echtzeitschätzung der Zustandsgrößen (x) und der Parameter (p) des Aktuators. Gegebenenfalls erhalten diese Schätzwerte die Fehleranteile Δx bzw. Δp. Mit Kenntnis der betreffenden Nominalwerte kann so kontinuierlich eine Aussage über den Status des Aktuators gemacht werden. Wie bereits erwähnt, ist eine Rekonfiguration der Aktuatorik wegen der fehlenden Redundanz nicht möglich.

Die benötigten Netzwerkmodule können im Aktuator per Hardware (ASIC) oder Mikropozessor implementiert werden und ermöglichen dadurch eine sich selbst überwachende "intelligente" Aktuatorbaugruppe.

Inferenz, Flugkörper-Status

In Fig. 6 ist eine Inferenz/Status-Einheit gezeigt, der die Ergebnisse der Sensor-, Informations-, Datenverarbeitungs- sowie der Aktuatorüberwachung zusammen mit der Status-Information aus dem BIT zugeführt werden.

Diese Einheit erzeugt daraus durch Schlußfolgerungs- und Inferenzprozesse (Fuzzy- Logik) die resultierende Information bezüglich des Funktionsstatus des Flugkörpers, seiner wesentlichen Funktionselemente (Sub-Systeme) und damit über dessen Verfügbarkeit.

Claims (22)

1. Flugkörper, dadurch gekennzeichnet, daß zur Erhöhung der Verfügbarkeit des Flugkörpers Mittel zur Funktionsüberwachung, Fehlerdetektion und -lokalisierung und Rekonfiguration der Flugkörper-Hardware und -Software vorgesehen sind.

2. Flugkörper nach Anspruch 1, dadurch gekennzeichnet, daß die Mittel zur Funktionsüberwachung wissensbasierte Mittel enthalten.

3. Flugkörper nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß die Mittel zur Funktionsüberwachung modellbasierte Mittel enthalten.

4. Flugkörper nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß die Mittel zur Funktionsüberwachung musterbasierte Mittel enthalten.

5. Flugkörper nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß die Mittel zur Funktionsüberwachung paritätsbasierte Mittel enthalten.

6. Flugkörper nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, daß die Mittel zur Funktionsüberwachung Mittel zur Überwachung von redundanter Hardware durch Mehrheitsbetrachtung enthalten.

7. Flugkörper nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, daß die Mittel zur Funktionsüberwachung Mittel zur Überwachung von redundanter Hardware durch unmittelbare Funktionsprüfung enthalten.

8. Flugkörper nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, daß die Mittel zur Funktionsüberwachung Mittel zur Überwachung von der Hardware durch Plausibilitätsbetrachtung enthalten.

9. Flugkörper nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, daß die Mittel zur Funktionsüberwachung Mittel zur Überwachung der operationellen Software enthalten.

10. Flugkörper nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, daß

• a) Sensoren zur Messung des Eigenbewegungszustandes des Flugkörpers selbst und Sensoren zur Zielerfassung und -verfolgung derart vorgesehen sind, daß Informationen über den Eigenbewegungszustand des Flugkörpers redundant erhalten werden,
• b) die Mittel zur Funktionsüberwachung Mittel zur Rekonfiguration derart enthalten, daß bei Unbrauchbarwerden einer Information eines Sensors diese Information aus den Informationen der anderen Sensoren gewonnen wird.

11. Flugkörper nach Anspruch 10, dadurch gekennzeichnet, daß Inertialsensoren vermehrfacht vorgesehen sind.

12. Flugkörper nach Anspruch 10 oder 11, dadurch gekennzeichnet, daß der Flugkörper einen Mehrkanal-GPS-Empfänger enthält.

13. Flugkörper nach einem der Ansprüche 10 bis 12, dadurch gekennzeichnet, daß Mittel zur Erzeugung von Bewegungsinformationen aus den Daten von zielerfassenden Infrarot- und Radarsensoren.

14. Flugkörper nach einem der Ansprüche 1 bis 13, dadurch gekennzeichnet, daß zur Überwachung der Sensorfehler ein Fuzzy-Netzwerk vorgesehen ist.

15. Flugkörper nach einem der Ansprüche 1 bis 14, dadurch gekennzeichnet, daß

• a) ein von den redundanten Sensorsignalen gebildeter Meßvektor auf ein neuronales Projektions- und Detektions-Netzwerk geschaltet ist, durch welches durch Projektion des Meßvektors in den zum Meßraum orthogonalen Fehlerraum (Paritätsraum) eine Trennung von Nutzsignal und Fehler durchgeführt und damit ein Merkmals- oder Validierungsvektor erzeugt wird, auf den sich Fehler abbilden,
• b) der Merkmalsvektor als Eingangsgröße auf ein neuronales Identifizierungs- Netzwerk aufgeschaltet ist, durch welches eine Lokalisierung des aufgetretenen Fehlers erfolgt.

16. Flugkörper nach den Ansprüchen 14 und 1 S. dadurch gekennzeichnet, daß

• a) der Validierungsvektor auf ein Entscheidungs-Netzwerk aufgeschaltet ist,
• b) das Entscheidungs-Netzwerk ein Fuzzy-Netzwerk mit einer Fuzzyfizierungs- Schicht, einer Regelschicht, einer Inferenz-Schicht und einer Defuzzyfizierungs-Schicht ist und
• c) das Entscheidungs-Netzwerk einen Sensor-Statusvektor liefert.

17. Flugkörper nach Anspruch 16, dadurch gekennzeichnet, daß auf das Entscheidungs-Netzwerk auch der Merkmalsvektor aufgeschaltet ist.

18. Flugkörper nach einem der Ansprüche 1 bis 17, dadurch gekennzeichnet, daß zur Überwachung der Software

• a) zu berechnende Daten einmal mit einem mit einem Hauptprogramm und einmal mit einem Überwachungsprogramm berechnet werden,
• b) aus den schon berechneten Daten durch Extrapolation prädizierte Daten berechnet werden.
• c) die Differenzen zwischen prädizierten Daten und den durch die Programme tatsächlich gelieferten Daten bestimmt werden und
• d) diese Differenzen auf eine Fuzzy-Entscheidungslogik geschaltet sind, welche einen Software-Statusvektor liefert.

19. Flugkörper nach Anspruch 18, dadurch gekennzeichnet, daß die Fuzzy- Entscheidungslogik als Monitor-Software ausgebildet ist, deren Struktur und/oder Parameter durch genetische oder evolutionäre Algorithmen erzeugt ist.

20. Flugkörper nach Anspruch 18 oder 19, dadurch gekennzeichnet, daß die Fuzzy- Entscheidungslogik als Hardware-Modul hergestellt ist.

21. Flugkörper nach einem der Ansprüche 1 bis 20, dadurch gekennzeichnet, daß fehlerdetektierende Mittel für die Aktuatoren vorgesehen sind.

22. Flugkörper nach einem der Ansprüche 1 bis 21, gekennzeichnet durch Mittel zur Erzeugung eines Flugkörper-Statussignals.