Fortgeschrittene Testarchitektur für Raketentriebwerke für erweiterte Systemunabhängigkeit und ‑wartung

Im Jahr 2021 wurden mehr Orbitalversuche unternommen als jemals zuvor.¹ Unternehmen und Regierungen auf der ganzen Welt versuchten 146 Flüge, von denen 135 erfolgreich die Erde umkreisten. Im Jahr 2021 wurde der bisherige Rekord von 139 Versuchen gebrochen, der 1967 auf dem Höhepunkt des Weltraumrennens aufgestellt wurde, als die UdSSR und die USA heftig darum konkurrierten, in den Weltraum und darüber hinaus zu gelangen. Am Weltraumrennen der 2020er Jahre sind mehr als nur zwei Länder beteiligt. Starts erfolgen nun unter anderem in den USA, dem Vereinigten Königreich, Europa, Russland, China, Indien, Türkei, Iran, Israel. Bereits im ersten Halbjahr 2022 setzte sich der Trend mit 72 erfolgreichen Flügen fort. Und das Rennen ist kein staatliches Projekt mehr, denn viele private Raumfahrtunternehmen konkurrieren und bringen große Mengen an Investorengeldern auf den Markt.

Neue Raketentechnologien ermöglichen diesen Anstieg der Weltraumstarts. SpaceX startete 2021 31 Falcon-9-Missionen, allesamt erfolgreich. Ihr neuer Ansatz zur Entwicklung von Raketen ermöglichte es ihnen, alle diese Missionen mit zuvor verwendeten Raketenkernen zu starten. Zur Unterstützung dieser Starts wurden lediglich zwei neue Falcon-9-Erststufen eingeführt. Da Unternehmen und Länder weiterhin investieren, um Weltraumstarts zuverlässiger, wiederverwendbarer und erschwinglicher zu machen, werden die Anzahl und Reichweite dieser Starts weiter zunehmen.

Auch die Infrastruktur zur Unterstützung dieser Starts nimmt zu. Es gibt 35 aktive Weltraumhäfen und Startanlagen, die suborbitale, orbitale und extraorbitale Missionen unterstützen können. Die Liste der Standorte umfasst alle Kontinente und mehr als 13 Länder,² weitere Länder bauen derzeit neue Anlagen. Und zusätzliche Standorte werden für Tests der Raketen verwendet, die von diesen Anlagen starten. Es ist eine aufregende Zeit, um Teil der Raumfahrtindustrie zu sein.

Die FAA regelt Raketenstarts für alle Starts auf US-Boden oder außerhalb der USA für jeden Start durch US-Bürger oder US-Einrichtungen.³ Andere Länder haben ähnliche Vorschriften und Regulierungsbehörden. Ein Unternehmen kann keine Rakete in den Weltraum starten, ohne die erforderlichen technischen Schritte durchzuführen. Einer dieser entscheidenden Schritte besteht darin, das Raketenfahrzeug zu testen und nachzuweisen, dass eine hohe Erfolgswahrscheinlichkeit besteht.

Das Testen einer Rakete beginnt mit dem Testen der verschiedenen Komponenten der Rakete. Ingenieurteams testen separat die Materialien und Komponenten, aus denen die Struktur, die Brennstoffe und die Elektronik bestehen. Diese Komponenten werden dann als Subsysteme montiert und getestet und schließlich vollständig zu einem Abnahmetest zusammengesetzt.

Produkte von NI werden in allen Bereichen des Fahrzeugs eingesetzt. Die Plattform für statische und Materialermüdungs-Strukturtests eignet sich ideal, um die Festigkeit des Treibstofftanks zu prüfen, damit er den Belastungen eines Fluges standhält. PXI-basierte modulare Messgeräte und Software für automatisierte Tests von NI bieten eine leistungsstarke Plattform zum Testen der Avionik-Schalttechnik. Die LRU-HIL-Testarchitektur von NI eignet sich ideal zum Generieren einer Vielzahl von Testfällen zum Testen von Avionik-Controllern. 

In diesem Dokument liegt der Schwerpunkt auf dem Testen des Raketentriebwerks, viele der darin enthaltenen Elemente gelten jedoch auch für den abschließenden Test des gesamten Fahrzeugs.

Raketentriebwerkstests sind ein wesentlicher Bestandteil des Tests aller Raketentriebwerkstypen. Diese Tests sind erforderlich, um die FAA-Bestimmungen zu erfüllen. Der Wert der Testergebnisse geht jedoch über die Einhaltung von Vorschriften hinaus. Ein NASA-Bericht zeigte, dass es eine positive Korrelation zwischen dem Zeitaufwand für das Testen von Raketentriebwerken und der Zuverlässigkeit dieser Triebwerke gab.⁴ Jeder Triebwerkshersteller muss entscheiden, wie er die Investitionen und Kosten zusätzlicher Tests einerseits und den erwarteten Nutzen dieser Tests andererseits ins Gleichgewicht bringt.

Ein Raketentriebwerksteststand ist eine Struktur, die dazu dient, Raketentriebwerke zu halten und zu testen. Sie bietet die notwendigen Support- und Steuerungssysteme, darunter Schubhalterungen, Bodenunterstützungsausrüstung für Treibstoffe, Kühlsysteme, Abgasumleitung und Automatisierung für die Sicherheit und Betriebsführung während der Tests. Zum Testen eines Raketentriebwerks wird das Triebwerk in einen Teststand montiert und für eine begrenzte Zeit gezündet. Der Raketentriebwerksteststand muss über notwendige Schubhalterungen, Bodenunterstützungsausrüstung für Treibstoffe, Kühlsysteme, Abgasumleitung sowie ein Steuerungssystem für die Automatisierung des Tests und Gewährleistung der Sicherheit während des Betriebs und der Tests verfügen. Ingenieure müssen entscheiden, ob die Rakete vertikal oder horizontal montiert wird – für beide Ausrichtungen gibt es Vorteile. Messungen lassen sich einfacher mit einem vertikal montierten Triebwerk korrelieren, da die Kräfte eher den Kräften im Flug entsprechen. Ein vertikal montiertes Triebwerk stellt jedoch ein Problem dar, das Abgas während des Tests von der Rakete wegzuführen, was üblicherweise mithilfe eines Flammenumlenkers geschieht.

Abbildung 1: Elemente eines Raketentriebwerksteststands

Die Abgasanlage stellt die Testanlage vor mehrere Herausforderungen. Zusätzlich zur Hitze ist die Abgasanlage laut und schmutzig. Das Hinzufügen einer Wassersprühanlage zur Abgasanlage kann als Puffer dienen, um Wärme vom Motor abzuleiten, und als Schild, um die Umgebung vor Geräuschen und Schadstoffen zu schützen.

Es gibt viele Variationen bei einem Raketentriebwerkstest. Ein Standardtest auf Höhe des Meeresspiegels kann auf einem Teststand ohne viel zusätzliches Equipment durchgeführt werden, aber andere Tests erfordern möglicherweise spezielle Testumgebungen. Um z. B. ein Raketentriebwerk für die Lageregelung auf einem Satelliten im All zu testen, benötigt der Teststand eine Vakuumkammer, um die beabsichtigten Betriebsbedingungen des Triebwerks nachzubilden. Für andere Tests sind möglicherweise eine Thermovakuumkammer oder zusätzliche mechanische Geräte zum Testen der kardanischen Aufhängung des Triebwerks erforderlich.

Teststationen variieren auch je nach Entwicklungsstufe des Triebwerks. Bei einem Triebwerkstest in einer frühen Entwicklungsstufe können viele zusätzliche Sensoren zum Einsatz kommen, da Ingenieure versuchen, mehr Dynamik der Triebwerksleistung zu erfassen. Ein Teststand, auf dem vor dem Flugbetrieb Qualifikations- oder Abnahmetests durchgeführt werden, kann weniger Signale testen, um die ordnungsgemäße Funktion zu überprüfen.

Ein mit der Planung eines Raketentests betrautes Ingenieurteam muss bei der Konstruktion eines neuen Teststands alle diese potenziellen Anforderungen berücksichtigen. Angesichts der rasanten Weiterentwicklung der Raketentechnologie müssen Ingenieure auch zukünftige Tests einplanen. Das Testdesign muss leistungsfähig genug sein, um die bekannten Anforderungen zu erfüllen, und gleichzeitig flexibel genug, um den sich im Laufe der Zeit weiterentwickelnden Anforderungen gerecht zu werden.

Ingenieure von NI arbeiten seit mehr als 30 Jahren eng mit Ingenieuren zusammen, die Raketentestsysteme entwickeln. Im Laufe dieser Zeit sind die Architekturen durch die Einführung neuer Technologien und Softwaretechniken ausgereifter geworden. Best Practices aus verwandten Anwendungen – Triebwerkstests, Windkanäle und andere große Testanlagen – haben die Entwicklung von Systemen zum Testen von Raketentriebwerken beeinflusst. Für den Erfolg eines architektonischen Entwurfs zum Testen von Raketentriebwerken haben sich einige Schlüsselprinzipien als entscheidend erwiesen.

Eine Raketentestanlage kann einen einzelnen Teststand oder mehrere Teststände unterstützen. Jeder Teststand erfordert Unterstützung von verschiedenen Subsystemen oder Pads, die einem Stand zugeordnet sein oder von mehreren Ständen oder Standorten innerhalb der Testanlage gemeinsam genutzt werden können. Ein anlagenweiter Supervisor des Bodensteuerungssystems vereint alle Pads und Teststände, um ein koordiniertes Betriebsmanagement der Anlagenressourcen zu gewährleisten.

Abbildung 2. Subsysteme der Raketentestanlage

Pad-Steuerungssysteme müssen Zuverlässigkeit für die Steuerung sowie Messfunktionen bieten, um die Leistung zu überwachen und zu verbessern.

Die erfolgreiche Implementierung eines Raketentestgeländes erfordert eine sorgfältige Abstimmung zwischen diesen Systemen. Im Laufe der Jahre hat sich in großen Raumfahrteinrichtungen ein Steuerungssystem entwickelt, das ein Entwurfsmuster mit der nötigen Flexibilität bietet, um der Kommunikation zwischen diesen Systemen und der Variabilität der Systeme zwischen Tests gerecht zu werden. Bei Raumfahrtunternehmen, die sowohl Test- als auch Starteinrichtungen betreiben, werden viele Komponenten des Musters gemeinsam genutzt, um die Unterschiede zwischen dem, was getestet wird, und dem, wie es gestartet wird, zu verringern.

Diese Architektur verwendet ein für alle Teststände und Pads gemeinsames Systementwurfsmuster. Das Muster bietet die lokale Steuerung, die jedes System benötigt, während Informationen zwischen den Systemen ausgetauscht werden, um die Synchronisation von Testvorgängen zu gewährleisten.

Abbildung 3: Allgemeines Entwurfsmuster für Steuerungssysteme

In diesem Muster lesen Steuerungssysteme Eingaben aus Kommunikationsprozessen, die später in diesem Dokument beschrieben werden.

Ein Skalierungsprozess wandelt diese Roheinheiten in für das Subsystem geeignete wissenschaftliche Einheiten um. Ein Skalierungsprozess kann auch mehrere Kanäle in einem einzigen berechneten Kanal kombinieren, z. B. durch Summierung aller Schubkraftmessdosen zu einem einzigen Schubwert. Ein Skalierungsprozess wendet zudem rekonfigurierbare Kalibrierungen an, da sich die Messgeräte zwischen Tests oder während des Betriebs ändern können.

Ein Alarmprozess wertet die Ausgabe der Datenpunkte aus dem Skalierungsprozess aus, um Alarme zu identifizieren. Alarme können in mehrere Kategorien unterteilt werden, z. B. Warnungen zum sofortigen Abbruch eines Tests oder zur Benachrichtigung eines Bedieners über ein potenzielles Problem. Ein Alarmprozess kann das erfolgreiche Beenden einer Testsequenz verwalten oder Befehle an andere Systeme senden, um diese Aktionen zu verwalten. Testoperatoren können mit dieser Architektur einen Notstopp oder ein ordnungsgemäßes Herunterfahren einrichten.

Wenn keine Alarme vorliegen, die den Testfortschritt verhindern, analysiert ein Logikprozess die Werte aus den Lese-, Skalierungs- und Alarmprozessen, um die nächsten Aktionen zu bestimmen. Ein Logikprozess kann z. B. feststellen, dass die Temperatur eines Flüssigkeitsverteilers den Punkt erreicht hat, an dem ein Ventil geöffnet werden muss, um eine Flüssigkeit durch die Rohrleitung strömen zu lassen (z. B. Kühlung in einem Lox-Verteiler). Daraufhin wird ein Befehl an ein anderes Subsystem im Netzwerk ausgegeben oder ein Befehl an den Sequenzprozess weitergeleitet, das Ventil lokal zu öffnen.

Ein Sequenzprozess führt dann die Aktionen aus, die durch geordnete und zeitlich gesteuerte Ereignisse mit Bedingungen (Grenzwerten, Begrenzungen und roten Linien) festgelegt werden, die von Testbetreibern entwickelt werden und durch Fluganforderungen (simulierte Flugsteuerung) oder Start-/Anlagenanforderungen (simulierter Start oder nominaler Testbetrieb) definiert sind. Einfache Aktionen können sofort ausgeführt werden; bei komplexen Aktionen kann zur sequenziellen Ausführung ein paralleler Prozess angestoßen werden. Ein Sequenzprozess verwendet Werte aus den Lese-, Logik- und Alarmprozessen als Eingaben und aktualisiert die Ausgaben des parallelen Sequenzprozesses nach Bedarf.

Abbildung 3 zeigt diese Funktionen als eine Reihe von Schritten. In der Anwendung ermöglicht dieses Muster jedoch separate parallele Module, die ihren eigenen Thread ausführen, jedoch mit dem Haupt-Thread der operativen Orchestrierung synchronisiert sind. Dadurch kann der Haupt-Thread mit konstanter Geschwindigkeit ausgeführt werden, ohne auf den Abschluss einer Aktion zu warten. Eine Steuerungssystemschleife arbeitet in der Regel zwischen 1 Hz und 400 Hz, abhängig vom zu steuernden System.

Dieses allgemeine Entwurfsmuster kann auf jedes Steuerungssystem angewendet werden, aber in einfachen Systemen können einige Elemente optional sein oder in einem anderen System verarbeitet werden. Beispielsweise verfügt eine einfache Motorsteuerung möglicherweise nicht über einen Alarmprozess. Stattdessen werden die Alarmbedingungen möglicherweise von einem anderen System basierend auf der Ausgabe des Systems, welches den Motor steuert, verarbeitet. Ein einfaches System hat möglicherweise keinen Sequenzprozess, sondern wird bei sehr einfachen Steuerungssystemen direkt vom Logikprozess oder vom Sequenzprozess eines anderen Steuerungssystems gesteuert, beispielsweise iDDS oder gRPC.

Abbildung 4. Kommunikationsdienste

Ein Steuerungssystem liest und schreibt Fernbefehle und Telemetrie über Kommunikationsdienste (z. B. Befehl zum Öffnen eines Ventils oder Starten einer Sequenz auf einem anderen Fernbedienungssystem, das ein Support-Pad steuert). Diese Dienste sind Daemons oder Mikrodienste, die im Hintergrund und nicht direkt in der Hauptanwendung ausgeführt werden. Wenn die Hauptanwendung über einen Dienst kommuniziert, anstatt sich auf die Funktion zum Lesen von Eingaben selbst zu verlassen, kann sie die Metriken des Mikrodienstes überwachen, so dass Probleme die Ausführung der Hauptanwendung nicht beeinträchtigen. Dadurch wird die Kommunikation vom Hauptsteuerungskreis abstrahiert und es wird einfacher, Ausrüstung und Konfigurationen im Laufe der Zeit zu aktualisieren, wenn neue Geräte mit neuen Kommunikationsschnittstellen verfügbar werden.

Einige Beispiele für Kommunikationsdienste sind in Abbildung 4 aufgeführt, es gibt aber viele Möglichkeiten für die Kommunikation. Das Anlagenplanungsteam kann ein benutzerdefiniertes Kommunikationsprotokoll für die Anlage erstellen oder Standardprotokolle auswählen, die die in der Anlage verwendeten Geräte unterstützen.

Ein entscheidender Faktor bei der Anschaffung neuer Geräte ist die Unterstützung der bestehenden Kommunikationsdienste in der Anlage. Die Regulierung der Anzahl der Kommunikationsprotokolle auf der Anlage vereinfacht die Entwicklung und Wartung der Software. Die Verwendung von Serviceleistungen verbessert den Prozess, wenn ein neues Kommunikationsprotokoll zugelassen wird.

Abbildung 5 Entwurfsmuster für Kommunikationsdienst

Jeder Kommunikationsdienst muss so konzipiert sein, dass er die Anforderungen eines Geräts und Protokolls erfüllt.

Ein typischer Kommunikationsdienst hat einige übliche Elemente. Kernstück eines Dienstes ist ein Zustandsautomat, der den aktuellen Zustand der Hardware nachverfolgt und den nächsten gewünschten Zustand ermittelt. Ein Gerät muss möglicherweise initialisiert werden, bevor ein Befehl gesendet werden kann. Der Zustandsautomat verfolgt den Initialisierungsstatus des Geräts nach, fordert die Initialisierung und dann das Senden des Befehls an. Der Dienst stellt Metriken bereit, die von anderen Netzwerkanwendungen überwacht werden können, z. B. wenn bei einem Schritt eine Zeitüberschreitung auftritt oder die Kommunikation mit einem Gerät verloren geht. Diese können Aktionen in anderen Systemen auslösen.

Abbildung 6: Bedienkonsolen

Eine Hardwareschnittstelle kommuniziert mit der Hardware über die API des Herstellers.

Eine Kommunikationsschnittstelle verpackt die Daten für das Protokoll – einschließlich spezifischer Formatierung, Metadaten, Verschlüsselung oder Komprimierung. Einige Protokolle erfordern Handshaking oder Konfigurationsmanagement, das zur Verwaltung an den Zustandsautomaten übergeben wird.

Um den Bedienerzugriff zu ermöglichen, kann jedes Steuerungssystem über eine Bedienkonsole oder mehrere Konsolen verfügen. Um Verwirrung im Steuerungssystem zu vermeiden, gibt es in der Regel nur eine aktive Bedienkonsole. Dabei kann es sich um eine dedizierte Bedienkonsole oder eine Konsole mit Steuerungszuteilung handeln, mit der ein Bediener die Steuerung anfordern kann.

Ein zu berücksichtigendes Entwurfsmerkmal ist die Rekonfigurierbarkeit der Konsolen. Aufgrund wechselnder Testanforderungen zwischen Tests oder sogar während eines Tests benötigen Testingenieure oft Zugriff auf zusätzliche Daten in diesen Konsolen. Da die meisten benötigten Daten in den Kommunikationsdiensten verfügbar sind, können Konsolen erstellt werden, mit denen Benutzer neue Datenpunkte abonnieren können, ohne dass der eigentliche Softwarecode geändert werden muss. Dies bietet Flexibilität für die Ingenieure, die die Daten benötigen, und schützt den Rest des Systems vor Änderungen an der Software. So kann die Konsole z. B. alle Datenkanäle in den Kommunikationsdiensten abonnieren und dem Konsolenbenutzer die Auswahl der anzuzeigenden Signale überlassen. Dieses Entwurfsmuster wurde von NI bei der Erstellung des Static Data Viewers mithilfe der NI G Web Development Software verwendet.

Ebenso sollten Konstrukteure überlegen, ob Befehlssignale an den Bedienkonsolen konfigurierbar sein sollen. Dadurch können Testingenieure die Steuerungsfunktionen ändern, ohne Aktualisierungen an der Software erforderlich zu machen, was die Produktivität in der schnelllebigen Raketentestumgebung erhöht. Diese Funktion muss in den Kommunikationsdienst integriert werden, der die Daten während des Lesevorgangs an das Steuerungssystem weiterleitet.

Eine Konsole kann ein dediziertes Gerät oder ein Bildschirm für ein bestimmtes Steuerungssystem sein oder mit anderen Konsolen zu einer Bedienstation kombiniert werden. Eine Bedienstation bietet Sicht und Steuerung von einem Ort aus über den gesamten Teststand.

Zusammengefügt ergibt dies eine vollständige Architektur.

Abbildung 7: Architektur einer Raketentestanlage

Diese Architektur bietet folgende Vorteile:

• Jedes System wird unabhängig von anderen Systemen ausgeführt, wodurch Verzögerungen durch das Warten auf die Antwort eines anderen Systems vermieden werden.
• Unabhängig kann jedes System die am besten geeignete Technologie nutzen, ohne die Entscheidungen über Technologien auf anderen Systemen zu beeinflussen.
• Das typische Entwurfsmuster für alle Systeme vereinfacht die Entwicklung und Wartung für Hardware- und Softwareteams.
• Die Architektur kann mit der Anlage wachsen und unterstützt eine beliebige Anzahl von Testständen und Supportsystemen.
• Die Architektur unterstützt Komponenten aller Hersteller und kann aktualisiert werden, wenn neue Technologien verfügbar sind.

Eine vollständig montierte Raketentestanlage kann in etwa so aussehen wie in Abbildung 8:

Abbildung 8: Raketentestanlage

Die in diesem Dokument beschriebene Architektur bietet ein Entwurfsmuster für den Entwurf eines Raketentestsystems. Zur Implementierung dieser Architektur müssen viele technische Entscheidungen getroffen werden. Ziel dieses Dokuments ist es, ein Team durch die Aspekte der Architektur zu führen, um sicherzustellen, dass die kritischsten Aspekte zu Beginn des Entwurfsprozesses berücksichtigt werden.

Bei Entscheidungen zur Implementierung der Architektur haben sich die folgenden Themen als die kritischsten erwiesen, die so früh wie möglich berücksichtigt werden sollten.

Systemlatenz

Welche Verzögerung ist innerhalb jedes Subsystems und in der gesamten Testanlage tolerierbar, um die Kontrolle und Sicherheit im Testbereich aufrechtzuerhalten?

Latenz im gesamten System ist das Ergebnis mehrerer Entwurfsentscheidungen. Schnellere Schleifen erhöhen die Kommunikationsgeschwindigkeit zwischen einer Komponente in einem System und einer anderen Komponente in einem anderen System. Ingenieure müssen jedoch auch die Anzahl der Sprünge zwischen Systemen berücksichtigen. Wenn Daten zwischen mehreren Systemen ausgetauscht werden müssen, um das endgültige Zielsystem zu erreichen, sind die kumulierten Verzögerungen größer, als bei direkter Datenübertragung zwischen Steuerungssystemen. Berücksichtigen Sie bei Entwurfsentscheidungen, wie Daten anderen Systemen zur Verfügung gestellt werden: entweder direkt oder durch mehrfaches Kopieren zwischen den Systemen.

Timing

Über die Anlage verteilte Systeme verfügen über unterschiedliche Zeituhren. Welche Laufzeitunterschiede können Sie bei Ihren Messungen tolerieren?

Die meisten Systeme kennzeichnen Messungen mit der Systemuhr des lokalen Geräts. Bei der systemübergreifenden Analyse von Daten ist es hilfreich, die Daten systemübergreifend korrelieren zu können. Eine gängige Lösung ist die Vorgabe einer absoluten Zeit für alle Systeme mithilfe von IEEE-1588 oder einem ähnlichen Protokoll. Die Zeit kann vom Anlagenüberwachungssystem bereitgestellt werden oder Systeme können auf ein GPS-Signal als Zeitbasis zurückgreifen.

Eine damit verbundene Überlegung ist, wie die Daten zwischen dem Prozesscomputer und dem Bodensystem korreliert werden. In einem Raketentest ist dies recht einfach, bei einem Start wird es jedoch komplizierter, da beim Start sämtliche Verbindungen zwischen dem Bodensystem und der Rakete verloren gehen. Da Testsysteme Startbedingungen nachbilden, sollte dies beim Entwurf des Teststands berücksichtigt werden.

Verteilung gemeinsam genutzter Ressourcen

Welche Subsysteme werden von Testständen gemeinsam genutzt und welche Subsysteme werden einem bestimmten Teststand zugewiesen?

Bei der gemeinsamen Nutzung von Ressourcen müssen zwei Kosten abgewogen werden: die Kosten für die Duplizierung von Ressourcen und die Kosten für die gemeinsame Nutzung von Ressourcen. Die Einrichtung eines Kryotanksystems ist mit erheblichen Kosten verbunden. Allerdings ist die Versorgung zweier separater Teststände mit kryogenen Flüssigkeiten auch mit erheblichen Kosten und Aufwand verbunden. Durch die gemeinsame Nutzung von Ressourcen ist es möglicherweise nicht möglich, zwei Aktivitäten parallel auszuführen, wenn für beide die Ressource erforderlich ist.

Umgang mit Laufzeitproblemen

Wie werden gemeinsam genutzte Ressourcen vor konkurrierenden Anweisungen von Steuerungssystemen geschützt?

Bei jedem Steuerungssystem, das von mehreren Befehlssystemen gesteuert werden kann, besteht das Risiko, dass aufgrund mangelnder Disziplin im Kommunikationssystem eine unbeabsichtigte Aktion ausgeführt wird. So kann z. B. ein Ventil auf Anforderung eines Teststands eine Operation starten, aber wenn ein zweiter Teststand den Sollwert überschreibt, kommt es zu einem katastrophalen Ausfall in beiden Testständen.

Das Entwurfsteam muss das System sorgfältig auf mögliche Laufzeitprobleme prüfen, um sicherzustellen, dass es eine ordnungsgemäße Sperrprozedur für jedes Befehlssignal im System gibt.

Laufzeitprobleme können sich auch auf Messdaten auswirken, wenn Daten überschrieben werden, bevor ein Speichersystem die Daten abruft. Die abgerufenen Daten entsprechen möglicherweise nicht den beabsichtigten Daten.

Redundanz

Welche Systeme müssen redundante Elemente haben? Wie hoch ist die Redundanz?

Redundanz kann an vielen Stellen innerhalb eines Systems angewendet werden – es kann redundante Sensoren, Verkabelungen, Erfassungsgeräte, Prozessoren, Algorithmen oder Stromversorgungen geben. Manche Raumfahrtunternehmen fordern für maximale Sicherheit eine dreifache Redundanz im gesamten System. Andere ermitteln die Ausfallpunkte mit dem höchsten Risiko und konzentrieren ihre Redundanzmaßnahmen darauf.

Für jeden Punkt im System stehen dem Entwurfsteam verschiedene Redundanzmodelle zur Auswahl. Bei der Standby-Redundanz wird die Primäreinheit durch eine identische Sekundäreinheit gesichert. Bei einem Cold-Standby-System ist die Sekundäreinheit im Ruhezustand und funktioniert nur, wenn ein Watchdog erkennt, dass die Primäreinheit ausgefallen ist. Bei einem Hot-Standby-System ist die Sekundäreinheit eingeschaltet und überwacht das System aktiv, aber ihre Ausgänge werden erst verwendet, wenn ein Watchdog die Steuerung auf sie umschaltet. Dadurch kann sich die Stillstandszeit bei einem Ausfall verkürzen, aber die Zuverlässigkeit der Sekundäreinheit bleibt nicht erhalten, da sie sich im aktiven Betrieb befindet.

Die modulare Redundanz ähnelt dem Hot-Standby-Ansatz, jedoch werden beide Systeme parallel ausgeführt und beide erzeugen Ausgaben für das System. Ein Abstimmungssystem, manchmal Auktionator oder Voter genannt, entscheidet, welche Ausgänge verwendet werden sollen. Dies ermöglicht reibungslose Übertragungen bei Ausfall einer der Steuerungen. Dieses Modell kann über zwei Steuerungen hinaus auf mehrere Steuerungen erweitert werden. Diese und andere Beispiele werden im NI-Whitepaper über Grundlegende Konzepte redundanter Systeme erläutert.

Umweltanforderungen

Welchen Umgebungen sind die Messgeräte ausgesetzt? Welche zusätzliche Infrastruktur ist zum Schutz der Mess- und Steuertechnik erforderlich?

Während eines Antriebstests werden die Geräte auf oder in der Nähe des Teststands extremen Umgebungsbedingungen ausgesetzt. Dazu können plötzliche Erschütterungen, kontinuierliche Vibrationen und hohe Temperaturen gehören.

Auch zwischen den Tests sind die Geräte extremen Umwelteinflüssen ausgesetzt. Heiße oder kalte Temperaturen, Luftfeuchtigkeit und Salzspray sind spezifische Bedrohungen für die Verfügbarkeit der Geräte für einen Test.

Ingenieure müssen die Umgebungsbedingungen des Teststands kennen. Mit diesen Informationen müssen sie Geräte auswählen oder entwerfen, die die potenziellen Anforderungen des Systems übertreffen. Dies kann den Kauf robusterer Geräte, zusätzliche Schutzmaßnahmen wie eine Schutzbeschichtung oder den Schutz der Geräte in einem Schrank oder einem Nebengebäude mit kontrollierter Klimatisierung erfordern.

Netzwerktopologie

Welche Netzwerktechnologien bieten die optimale Leistung für den Datenaustausch im Netzwerk, einschließlich Redundanz bei einem Komponentenausfall?

Beim Entwerfen einer Netzwerktopologie stehen viele Optionen zur Verfügung. Eine erfolgreiche Anlagentopologie erfordert detaillierte Konversationen zwischen dem IT-Infrastrukturteam und den Testentwicklungsteams. Testteams müssen Anforderungen an Datenbandbreite, Latenz und Technologie beschreiben. Das IT-Team muss sich mit Verschlüsselung, Layout und Redundanz auskennen, um das Netzwerklayout zu planen.

Zu den Entscheidungen beim Entwurf des Netzwerks gehört auch die Entscheidung über ein Redundanzmodell, das die Verlegung redundanter Netzwerkkabel in der gesamten Anlage, die Verwendung des Rapid Spanning Tree Protocol (RSTP) sowie die Verwendung mehrerer Verteilungs-Switche umfassen kann.

I/O-Abdeckung

Welche Signale müssen gemessen oder gesteuert werden?

Eine der ersten Aufgaben des Ingenieurteams ist das Erstellen einer Liste der Signale, die im Teststand gemessen oder gesteuert werden müssen. Während der Dokumentation von Signalen müssen Typ, Position, Auflösung, Datenrate, Erregungsbedarf, Sicherheitsanforderungen sowie Spannungs- und Stromstärke des Signals aufgelistet werden.

Mit diesen Informationen können Ingenieure die Signale in Messbänken sammeln und dann die richtige Hardware für den Zugriff auf alle Signale auswählen.

Datenbandbreite

Kann die Netzwerktopologie die während eines Tests erwartete Datenmenge verarbeiten?

Der Entwurf des Netzwerks, einschließlich Computergeräte, Switch-Hardware und Subnetzwerkarchitektur, legt die Grenze für die Menge der Daten fest, die über das Netzwerk übertragen werden können. Das Entwurfsteam muss die Komponenten des Netzwerks sorgfältig prüfen und nach Engpässen im System suchen.

Eine theoretische Berechnung kann Hinweise für einen Systementwurf geben, aber Netzwerkanwendungen erreichen nie die volle theoretische Datenrate. Daten-Overhead und Latenzen beeinflussen den Gesamtdurchsatz im Netzwerk. Beim Entwurf eines Netzwerks ist es ratsam, die Datenraten deutlich unter dem theoretischen Grenzwert zu halten.

Sicherheit

Welche Sicherheitssysteme müssen vorhanden sein?

Eine Raketenanlage hat viele gefährliche Bedingungen. Ein Fehler in der Konstruktion, Implementierung oder im Betrieb der Systeme kann einen katastrophalen Unfall zur Folge haben. Das Entwurfsteam muss mit den Sicherheitsprotokollen vertraut sein, die durch Bundes- und Kommunalgesetze vorgeschrieben sind. Das Entwurfsteam muss auch darüber nachdenken, wie das Personal, die Ausrüstung und der Bereich der Teststation in einer Weise geschützt werden, die nicht durch Gesetze abgedeckt ist.

Einige Bereiche einer Raketenanlage sind aufgrund der zum Antrieb des Raketentriebwerks verwendeten Gase Gefahrenzonen. Einige dieser Gase können nicht vollständig eingedämmt werden, wodurch eine Zone entsteht, in der jeder elektrische Funke einen Brand oder eine Explosion verursachen kann. Um dies zu verhindern, müssen alle Geräte in der Gefahrenzone eigensicher sein, d. h. sie dürfen keinen Funken erzeugen können. Dies kann erreicht werden, indem elektrische Geräte außerhalb der Gefahrenzone positioniert werden. Ein elektrisch gesteuertes Ventil kann außerhalb der Zone platziert werden, so dass sich in der Zone nur die vom Ventil wegführende Leitung befindet.

Muss ein Gerät innerhalb der Gefahrenzone aufgestellt werden, so muss es vom Hersteller als eigensicher zertifiziert sein. In den USA bedeutet dies eine Zertifizierung nach Class 1 Div 1. In Europa bedeutet dies eine ATEX-Zertifizierung basierend auf der Gasart.

Wenn ein Gerät außerhalb der Gefahrenzone aufgestellt ist, aber ein Signal in diese leitet, muss das Gerät eine intrinsische Barriere haben, um zu verhindern, dass ein im Gerät erzeugter Funke in die Zone gelangt. Selbst Low-Level-Geräte, wie Thermoelementmessgeräte, benötigen eine intrinsische Barriere, um zu verhindern, dass Strom vom Gerät (wie eine angeschlossene Stromversorgung) in die Zone gelangt. In den Signalweg zwischen Gerät und Gefahrenzone kann eine intrinsische Barriere eingefügt werden, die sowohl vor Spannungs- als auch Stromspitzen schützt. Beachten Sie, dass intrinsische Barrieren je nach Signaltyp variieren. Daher wäre eine Barriere für ein Thermoelement für eine Ventilsteuerung nicht geeignet.

Zertifizierungen

Welche Zertifizierungen müssen die Anlage, die Supportsysteme und der Teststand erfüllen?

Je nach Bevölkerungszahl, Zweck der Anlage, örtlichen Gesetzen und Zweck der Raketenausrüstung sind für unterschiedliche Bereiche unterschiedliche Zertifikate erforderlich. Beispielsweise kann ein Raketentest, der an einem US-Luftwaffenstützpunkt ausgeführt wird, vor jeder Raketenaktivität eine AFSPCMAN 91-7108-Zertifizierung erfordern.

Zusätzlich zu den für die Durchführung des Tests erforderlichen Zertifizierungen wirken sich Zertifizierungen auf das Ziel des Tests aus. Wenn der Zweck des Tests darin besteht, das Raketentriebwerk für die Verwendung zu zertifizieren, muss der Teststandsentwurf die Anforderungen dieser Zertifizierung erfüllen. So stellt z. B. MIL-STD-8109 sicher, dass das getestete Gerät die erwarteten Bedingungen für die Verwendung des Produkts erfüllt. MIL-STD-20210 stellt sicher, dass Komponenten unter 300 Pfund die elektrischen und ökologischen Anforderungen einer anspruchsvollen Anwendung erfüllen. Diese können erforderlich sein, wenn das US-Verteidigungsministerium Zielkunde der getesteten Technologie ist.

Der Entwurf einer Raketentestanlage mit Teststand und Supportsystemen ist ein großes und detailorientiertes Projekt. Der Zweck dieses Dokuments ist es, ein allgemeines Entwurfsmuster und einen Ansatz für den Entwurfsprozess bereitzustellen. Es liegt außerhalb des Rahmens dieses Dokuments, jeden einzelnen Schritt im Prozess zu skizzieren, aber der Entwurfsprozess folgt diesen grundlegenden Schritten. Wenn dieser Prozess außerhalb der Möglichkeiten Ihres Entwurfsteams liegt, finden Sie im folgenden Abschnitt Informationen dazu, wie Sie NI und Partner von NI in den Entwurfsprozess einbinden können.

Systemen erkennen

Ausgabe: Blockdiagramm der Systeme und Subsysteme, die in der Anlage entworfen werden

Legen Sie zunächst die Anlagensysteme fest. Planen Sie unter Berücksichtigung der aktuellen und zukünftigen Anforderungen der Anlage Teststände und Supportsystemstandorte. Planen Sie den Datenaustausch zwischen den Systemen und die dazwischenliegenden Verbindungen. Entscheiden Sie, welche Supportsysteme gemeinsam genutzt werden und welche dem Teststand zugewiesen werden.

Systemanforderungen aufstellen

Ausgabe: Detaillierte Anforderungen für jedes System und Subsystem, das in der Anlage entworfen werden soll

Dokumentieren Sie für jedes der identifizierten Systeme deren Anforderungen. Listen Sie die erwarteten Ein- und Ausgänge auf, einschließlich Aktualisierungsraten und Kommunikationsprotokoll. Dokumentieren Sie den erwarteten Funktionsumfang des Systems einschließlich der erforderlichen Leistung. Entscheiden Sie, welches Funktionsteam im Unternehmen für den Entwurf der einzelnen Systeme verantwortlich sein soll.

Anlagenweite Anforderungen erkennen

Ausgabe: Detaillierte Anforderungen an die Systeme und Infrastruktur, die die Anlage miteinander verbinden

Bestimmen Sie anhand der Systemanforderungen die erforderliche Leistung des Anlagensystems zur Unterstützung dieser Systeme. Dokumentieren Sie die Aktualisierungsrate, die erforderlich ist, um die Latenzanforderungen aller Systeme und Komponenten zu erfüllen. Arbeiten Sie mit dem IT-Team zusammen, um herauszustellen, wie sich die Anforderungen der Netzwerkinfrastruktur mit denen der Systeme vereinen lassen. Berechnen Sie die Datenraten der Worst-Case-Szenarien im System.

Technologien auswählen

Ausgabe: Liste der Technologien für die System- und Anlagenanforderungen

Bestimmen Sie anhand der System- und Anlagenanforderungen die spezifischen Technologien, die erworben oder entwickelt werden müssen, um die dokumentierten Anforderungen zu erfüllen. Treffen Sie sich mit Herstellern, um einsetzbare Standardtechnologien zu ermitteln. Arbeiten Sie mit Ingenieurteams zusammen, um einen benutzerdefinierten technischen Ansatz für verbleibende Lücken in den Systemen zu finden. Testen Sie nach Möglichkeit die Leistung der Systeme, um sicherzustellen, dass sie die Anforderungen erfüllen.

Kommunikationsdienste entwerfen

Ausgabe: Dokumentieren Sie die Anforderungen und die Implementierung der einzelnen Kommunikationsdienste für die Systeme und Anlagenausrüstung

Dokumentieren Sie mit einem guten Verständnis der für die Systeme verfügbaren Technologien die Anforderungen aller Kommunikationsdienste. Bestimmen Sie die Eingänge, Ausgänge und die Verarbeitung jedes einzelnen Dienstes. Bestimmen Sie die Fachkenntnisse, die für die vollständige Implementierung der Dienste erforderlich sind.

Systemsteuerungen entwerfen

Ausgabe: Entwerfen Sie Dokumente für jede der Systemsteuerungen in der Anlage

Wenden Sie die Systemanforderungen auf die für die Systeme und Anlagen ausgewählten Technologien an. Dokumentieren Sie die gewünschten Eingänge, Ausgänge und Funktionalität anhand spezifischer Leistungskriterien. Bestimmen Sie die für die Implementierung der Systemsteuerungen erforderlichen Fachkenntnisse.

Systemsteuerungen und Kommunikationsdienste implementieren

Ausgabe: Programmcode, der auf jeder der Systemsteuerungen und zwischen Systemen ausgeführt wird

Entwickeln Sie den Programmcode, der auf jeder der Systemsteuerungen und in jedem Kommunikationsdienst ausgeführt wird. Dokumentieren Sie alle Änderungen aus den Anforderungsdokumenten und stellen Sie sicher, dass Änderungen keine Auswirkungen auf andere Systeme haben. Wenden Sie geeignete technische Grundsätze auf die Entwicklung an, einschließlich Modultests, um zu überprüfen, ob jede Komponente die dokumentierten Anforderungen erfüllt.

Systemsteuerungen verbinden

Ausgabe: Werteaktualisierungen zwischen Steuerungssystemen

Verbinden Sie die Systemsteuerungen und Kommunikationsdienste. Stellen Sie sicher, dass die Systeme ordnungsgemäß und innerhalb der erwarteten Leistungsgrenzen funktionieren. Führen Sie Modultests an Komponenten, Subsystemen und Systemen durch, sobald diese verbunden sind.

Systemleistung validieren

Ausgabe: Validierung der Leistung aller Systemkomponenten, Systeme und miteinander verbundenen Systeme

Führen Sie, sobald das System komplett eingerichtet ist, einen vollständigen Validierungstest der Systeme und des Gesamtsystems durch. Prüfen Sie, ob alle Anforderungen erfüllt sind. Melden Sie unerwartetes Verhalten an Entwickler und wiederholen Sie die Schritte, bis die gewünschte Leistung erzielt wird.

Bedienstationen und Viewer erstellen

Ausgabe: Bedienbildschirme und ‑stationen zur Steuerung und Anzeige der Systeme

Zusammen mit den Systemen werden Bedienkonsolen entwickelt. Wenden Sie Verbesserungen der Bedienbarkeit auf die Konsolen an und erstellen Sie die endgültigen Bedienkonsolen.

Es gibt in letzter Zeit einige Fortschritte bei verfügbaren Technologien, die in dieser Raketentestarchitektur eingesetzt werden können.

gRPC

gRPC ist ein leistungsstarkes Open-Source-Framework, das in jeder Umgebung ausgeführt werden kann. Von Google entwickelt und basierend auf Remote Procedure Call (RPC) hat gRPC in den letzten fünf Jahren als Möglichkeit zum Datenaustausch zwischen Teilen eines Systems rasant an Popularität gewonnen. Mit gRPC kann eine Client-Anwendung direkt eine Methode auf einer Server-Anwendung auf einem anderen Computer aufrufen, als wäre sie ein lokales Objekt. Dies vereinfacht die Erstellung einer verteilten Architektur wie der Raketentestarchitektur. Software und Hardware von NI arbeiten mit gRPC. Finden Sie weitere Informationen zu gRPC Support Resources & Compatibility.

iDDS

iDDS ist ein von Rolls Royce und MDS Aero entwickeltes Datenabstraktionsprotokoll für Strahlturbinen-Triebwerkstests. Es bietet einen Kommunikationsdienst zum Sammeln von Daten von Messgeräteknoten, der für Abonnenten im Netzwerk zur Verfügung gestellt wird. iDDS basiert auf dem DDS-Standard (Data Distribution Service) und dem OMG-Standard (Object Management Group). iDDS definiert die Verpackung von Messgerätedaten im DDS-Netzwerk, einschließlich Messdaten wie Kanalmetadaten, Zeitstempel, Konfiguration und Zustandsüberwachung. Da die Kommunikation zwischen Geräten innerhalb des iDDS-Modells standardisiert ist, werden bestimmte Herstellerfunktionen weggelassen, was den Austausch von Geräten vereinfacht, wenn neue Technologien verfügbar sind, auch wenn sie von einem neuen Hersteller stammen.

NI bietet maßgeschneiderte Hard- und Softwarelösungen für Raketentriebwerkstests, die sich ändernde Sicherheitsanforderungen, neue Sensoren und vom Markt geforderte Technologien integrieren. Unsere Software bietet Tools für benutzerdefinierte Testlösungen, Echtzeit-Datenvisualisierung, Protokollierung und automatisierte Testsequenzierung. Diese Softwarelösungen verbessern die Datenanalyse, die Anlagenverwaltung und die allgemeine Testeffizienz durch leistungsstarke, anpassungsfähige Plattformen.

Hardwareplattformen wie NI PXI, NI CompactDAQ und NI CompactRIO sind so konzipiert, dass sie extremen Bedingungen standhalten und ein breites Spektrum von Signalen unterstützen, wodurch eine zuverlässige und präzise Messung und Steuerung bei Raketentriebwerkstests gewährleistet wird. Diese robusten modularen Systeme bieten verteilte Messungen und lokale Verarbeitungsfunktionen, was die Testgenauigkeit und ‑flexibilität erhöht. Sehen Sie sich unsere Lösungen zum Testen des Antriebs von Raketentriebwerken an, um zu erfahren, wie Sie mehr Triebwerke in kürzerer Zeit testen können als je zuvor.

• Lösung zum Testen des Antriebs von Raketentriebwerken
• NASA-Datenerfassungssystemsoftware für Raketenantriebstests
• Revolutionierung der Effizienz der Raketenentwicklung durch Tests

Fußnoten:

¹ https://arstechnica.com/science/2022/01/thanks-to-china-and-spacex-the-world-set-an-orbital-launch-record-in-2021
² https://www.go-astronomy.com/space-ports.php
³ https://www.ecfr.gov/current/title-14/chapter-III
⁴ https://ntrs.nasa.gov/api/citations/20050182932/downloads/20050182932.pdf

Quellen

• https://static.e-publishing.af.mil/production/1/ssc/publication/sscman91-710v3/sscman91-710v3.pdf
• https://www.atec.army.mil/publications/mil-std-810g/mil-std-810g.pdf
• https://nepp.nasa.gov/DocUploads/1F6AB74B-4517-4AD0-A34813268E75B8EB/MIL-STD-202.pdf