Missionsrisiko-Szenario-Simulation

Das echte Ausmaß des Problems

Jede Raumfahrtmission ist ein Geflecht aus Hunderten von Subsystemen, die unter sich ständig ändernden Umgebungsbedingungen interagieren. Für jedes Subsystem kann die Zuverlässigkeit separat bewertet werden, aber das sagt wenig über das Systemverhalten aus, wenn Komponenten gleichzeitig unter kombinierten Belastungen arbeiten.

Historische Daten zeigen, wie fatal das sein kann:

• Mars Polar Lander (1999): Die wahrscheinlichste Ursache laut Untersuchungsbericht: Die Schwingungen beim Ausfahren der Landebeine erzeugten ein Signal, das die Software als Bodenkontakt deutete, und sie schaltete die Triebwerke ab, bevor die Sonde den Boden berührt hatte. Sicher belegen ließ sich das mangels Telemetrie nicht. Die Mission kostete rund 165 Millionen US-Dollar. Das Muster: eine Wechselwirkung zwischen Mechanik und Software, die in keinem Test gekoppelt geprüft wurde.

• Hubble Space Telescope (1990): Der berühmteste optische Fehler der Raumfahrtgeschichte: Der Hauptspiegel war am Rand um rund 2,2 Mikrometer zu flach geschliffen, weil eine Linse im Prüfgerät 1,3 Millimeter falsch saß. Ältere Prüfverfahren hatten die Abweichung sogar angezeigt, ihre Ergebnisse wurden verworfen. Eine Monte-Carlo-Analyse hätte diesen Fehler nicht gefunden, er war systematisch, nicht zufällig. Das Beispiel zeigt die Grenze jeder Simulation: Sie findet nur, was ihre Annahmen enthalten.

• Iridium-33-Kollision (2009): Die erste bekannte Kollision zweier intakter Satelliten im Orbit erzeugte über 2.000 verfolgbare Trümmerstücke. Probabilistische Kollisionsanalysen, wie sie NASA in ihrem CARA-Programm betreibt, sollen genau solche Ereignisse vorhersagen und vermeiden helfen.

Wie oft Raumfahrtmissionen ganz oder teilweise scheitern, hängt stark von Missionsklasse und Betreiber ab, eine belastbare Durchschnittsquote, die sich hier zitieren ließe, haben wir nicht gefunden. Klar ist: Selbst ein partieller Misserfolg, der Verlust eines Payload-Instruments, ein vorzeitiger Orbit-Decay, kann einen großen Teil des Missionswerts kosten.

Das Problem ist grundsätzlicher Natur: Manuelle Risikoanalysen können nur eine begrenzte Anzahl von Szenarien durchdenken. Die Anzahl möglicher Zustandskombinationen in einem modernen Raumfahrtsystem wächst exponentiell mit der Komplexität, und liegt weit jenseits menschlicher Rechenkapazität.

Mit vs. ohne KI, ein ehrlicher Vergleich

Die Zeitangaben für die KI-gestützte Variante setzen voraus, dass ein valides Systemmodell bereits existiert, und sie sind unsere Einschätzung, keine Messwerte. Der Modellaufbau selbst, und das ist die ehrliche Aussage dieses Vergleichs, ist die eigentliche Arbeit.

Einschätzung auf einen Blick

Zeitersparnis, hoch (4/5) Das Potenzial ist erheblich: Ein Simulationslauf mit 50.000 Szenarien läuft auf einem modernen Rechner in wenigen Stunden, bei einfachen Modellen in Minuten. Was manuell Wochen gekostet hätte, ist in einem Arbeitstag durchgerechnet. Der Vorbehalt: Der eigentliche Zeitgewinn gilt für die Ausführungsphase nach dem Modellaufbau. Der Aufbau valider Eingangsverteilungen, Zuverlässigkeitsdaten aus Subsystemtests, Wetterfensterhistorien, operationelle Constraints, ist selbst eine aufwändige Ingenieurarbeit. Wer das System einmal aufgebaut hat, gewinnt für jede folgende Missionsvariante erheblich Zeit.

Kosteneinsparung, maximal (5/5) Das ist die stärkste Dimension dieses Anwendungsfalls. Ein Designfehler, der erst beim Integrations- oder Betriebstest entdeckt wird, kostet ein Vielfaches gegenüber einer Entdeckung in der Konzeptionsphase, in der Raumfahrt oft Millionenbeträge. Ein Satellit, der nach dem Start versagt, ist ohne Bergungsoption verloren. Die Kosteneinsparung durch frühes Erkennen ist kontrafaktisch, du siehst nicht, was vermieden wurde, und ein gefundenes Risiko ist nicht automatisch eines, das eingetreten wäre. Die 5 gilt für das Potenzial, nicht für einen sicheren Ertrag, deshalb steht die ROI-Sicherheit nur auf 3.

Schnelle Umsetzung, sehr niedrig (1/5) Dieser Anwendungsfall gehört zu den aufwändigsten Einstiegen in der Kategorie. Bevor auch nur ein Simulationslauf sinnvolle Ergebnisse liefert, braucht es: ein valides Systemmodell mit klar definierten Schnittstellen, Zuverlässigkeitsdaten aus Komponenten- und Subsystemtests, statistische Verteilungsannahmen für alle unsicheren Parameter und ein Validierungsschritt gegen bekannte Referenzmissionen. Realistische Timeline: 6 bis 18 Monate für einen produktionsfähigen Einsatz. Teams, die das unterschätzen, erhalten Simulationsergebnisse, die zuverlässig aussehen, aber auf unbegründeten Annahmen basieren.

ROI-Sicherheit, mittel (3/5) Der Nutzen ist real, aber er ist kontrafaktisch. Du misst die Missionen, die nicht gescheitert sind. Es gibt keine Kontrollgruppe. In der Praxis wird der ROI indirekt sichtbar: Investoren fragen nach probabilistischen Risikoaussagen, Versicherer nutzen sie in der Prämienkalkulation, und Auftraggeber schreiben Zuverlässigkeitsanalysen vertraglich vor. Diese Einbettung in externe Anforderungen stabilisiert den Nutzen, für die eigene Kostenrechnung bleibt aber die Lücke zwischen theoretischem Kostenrisiko und tatsächlich vermiedenem Schaden.

Skalierbarkeit, hoch (4/5) Das ist das langfristige Stärkeargument: Ein valides Simulationsmodell für eine Missionsfamilie lässt sich für Varianten (andere Bahnen, andere Nutzlasten, andere Startfenster) ohne vollständigen Neuaufbau erweitern. Parameterstudien über das gesamte Designraumraster sind trivial, sobald die Modellarchitektur steht. Einschränkung: Radikal andere Missionsarchitekturen oder neue Systemtechnologien brauchen neue Modelle, die Skalierbarkeit gilt innerhalb einer Missionsfamilie, nicht über alle Missionstypen hinweg.

Richtwerte, stark abhängig von Missionskomplexität, verfügbaren Zuverlässigkeitsdaten und Teamgröße.

Was die Simulation konkret macht

Der technische Kern ist Monte Carlo Simulation in Verbindung mit Machine Learning-Methoden zur Beschleunigung des Samplingprozesses.

Schritt 1, Systemmodell aufbauen. Das Missionsystem wird in ein physikalisch-mathematisches Modell überführt: Welche Subsysteme existieren? Welche Schnittstellen bestehen zwischen ihnen? Welche Umgebungsparameter (orbitale Bedingungen, thermische Last, atmosphärischer Drag, Strahlungsumgebung) beeinflussen welche Komponenten? Dieses Modell ist keine Blackbox, es muss von Fachingenieurteams validiert werden.

Schritt 2, Unsicherheiten als Verteilungen kodieren. Statt eines festen Parameterwertes erhält jeder unsichere Eingangsparameter eine statistische Verteilung: Der Antriebsimpuls hat eine Normalverteilung mit Mittelwert und Standardabweichung aus Testreihen. Das Startzeitfenster hat eine Gleichverteilung über das geplante Fenster. Die atmosphärische Dichte auf 400 km Höhe folgt einer empirischen Verteilung aus Solardaten der letzten 20 Jahre.

Schritt 3, Tausende Szenarien simulieren. Der Simulator zieht zufällige Kombinationen aus allen Verteilungen und berechnet für jede das Missionsergebnis. Nach 10.000 bis 100.000 Läufen entsteht eine statistische Verteilung von Missionsergebnissen, keine binäre Aussage “bestanden / nicht bestanden”, sondern eine Wahrscheinlichkeitsdichte.

Wo ML hineinkommt: Klassische Monte-Carlo-Simulation ist rechenintensiv, besonders wenn das Systemmodell selbst komplex ist. Zwei Wege helfen: klassische Stichprobenverfahren wie Latin Hypercube oder Importance Sampling, die mit weniger Läufen auskommen, und ML-Surrogate-Modelle. Dabei lernt ein neuronales Netz die Transferfunktion des physikalischen Modells und sagt Simulationsausgaben für neue Eingabekombinationen in Millisekunden voraus, statt das vollständige Modell auszuführen. Wie das in der Praxis aussieht, zeigt ein Überblick des NASA-Teams für Kollisionsbewertung (CARA) von 2025: Dort werden unter anderem LSTM-Netze beschrieben, die aus der Folge von Konjunktionsmeldungen Werte vorhersagen.

Was herauskommt: Keine Liste von „das ist riskant / das ist nicht riskant”, sondern:

• P(Missionsziel erreicht | Baseline-Annahmen) = 94,7 %
• Welche Parameterkombinationen sind für 80 % der Missionsausfälle verantwortlich?
• Unter welchen Bedingungen sinkt P(Erfolg) unter 90 %, und welche Designänderung verbessert das am effizientesten?

Monte Carlo oder ML, wann welcher Ansatz dominiert

Das ist die Frage, die Missionsrisikoexperten am häufigsten diskutieren, und wo viele Teams falsche Erwartungen haben.

Monte Carlo ist das Grundverfahren, wenn:

• Das Systemmodell valide und bereits implementiert ist
• Die Rechenzeit für einzelne Simulationsläufe akzeptabel ist (Sekunden bis Minuten je Lauf)
• Tail-Risiken und seltene Ereignisse explizit untersucht werden sollen
• Vertragsanforderungen probabilistische Nachweise fordern

Ansys STK mit seinem Analyzer-Modul ist die Referenzimplementierung für diesen Ansatz in der Raumfahrt: Physikbasierte Bahnmechanik, Sensormodelle und probabilistische Coverage-Analysen in einer integrierten Umgebung. MATLAB Aerospace Toolbox ist die zweite Wahl für Teams, die ohnehin in MATLAB/Simulink entwickeln und keine eigenständige Mission-Engineering-Plattform brauchen.

ML-Surrogate-Modelle sind die richtige Ergänzung, wenn:

• Das physikalische Simulationsmodell zu rechenintensiv für direkte Monte-Carlo-Läufe ist (typisch: > 10 Minuten je Lauf)
• Optimierungsläufe über den Designraum durchgeführt werden sollen (10.000+ Evaluierungen nötig)
• Vorhersagen für neue Missionsparameter in Echtzeit gebraucht werden (z. B. für automatisierte Kollisionsvermeidungsmanöver)

OpenMDAO von NASA eignet sich für den zweiten Fall gut: analytische Gradienten und Optimierungsrahmen ermöglichen effiziente Designoptimierungen über gekoppelte Disziplinen. Für reine Surrogate-Modellierung ohne Optimierung sind PyTorch oder scikit-learn mit einem sorgfältig kuratierten Trainingsdatensatz aus Monte-Carlo-Referenzläufen die pragmatische Wahl.

Die häufigste Fehlannahme: ML-Modelle ersetzen das physikalische Simulationsmodell nicht, sie beschleunigen seine Auswertung. Wer ML-Vorhersagen für Missionsrisiken ohne valides physikalisches Grundmodell einsetzt, extrapoliert auf einem Fundament aus unverifizierten Annahmen. Das kann zuverlässig aussehende Zahlen produzieren, die katastrophal falsch sind.

Zusammenfassung:

• Valides Physikmodell vorhanden, Rechenzeit akzeptabel → Monte Carlo direkt mit Ansys STK oder MATLAB Aerospace Toolbox
• Rechenintensives Modell, viele Designiterationen → Surrogate-Modell trainieren, dann Monte Carlo auf Surrogate
• Keine Physikmodell-Basis vorhanden → erst Modell bauen, nicht mit ML starten
• Open-Source-Team, Forschungsumgebung → OpenMDAO für MDAO, externe Bibliotheken für probabilistische Analyse

Konkrete Werkzeuge, was wann passt

Ansys STK , die Industrieplattform für Missionsanalyse Vollständige Mission-Engineering-Umgebung mit physikbasierter Bahnmechanik, Sensor- und Kommunikationsmodellen sowie probabilistischer Analyse. Verbreitet bei Raumfahrtagenturen und großen Luft- und Raumfahrtkonzernen. Die Free-Version ist verfügbar, aber ohne probabilistische Analysemodule. Für produktive Monte-Carlo-Missionsrisikoanalysen ist das separat lizenzierte Analyzer-Modul nötig, Preis ausschließlich auf Anfrage, typisch Enterprise-Jahresverträge. STK fällt selbst unter US-Exportkontrolle (EAR, einzelne Module ITAR), für europäische Kunden heißt das Endnutzer-Erklärungen und womöglich Lizenzanträge. Geeignet für: Raumfahrtagenturen, Satellitenbetreiber, große Verteidigungsprogramme.

MATLAB Aerospace Toolbox , der Allrounder für Teams im MATLAB-Ökosystem Wer bereits MATLAB/Simulink in der Entwicklung einsetzt, findet die Aerospace Toolbox als natürliche Erweiterung: Koordinatensysteme, Atmosphärenmodelle, Quaternion-Algebra und Monte-Carlo-Infrastruktur (parfor, Statistics Toolbox) in einem vertrauten Werkzeug. Im deutschen MathWorks-Store kostet MATLAB 2.410 Euro im Jahr, die Aerospace Toolbox 1.770 Euro im Jahr zusätzlich (kommerzielle Einzellizenz). Geeignet für: Ingenieurteams mit bestehender MATLAB-Infrastruktur, Forschungsgruppen, industrielle Entwicklungsprojekte.

OpenMDAO , kostenlos, NASA-entwickelt, für Forschung und Startups Open-Source-Framework für multidisziplinäre Design-Analyse und -Optimierung. Keine Lizenzkosten, Apache 2.0, Python-basiert. Besonders stark für Designoptimierung mit analytischen Gradienten, weniger für reine Monte-Carlo-Risikosimulation, aber gut als Grundgerüst für eigene probabilistische Analysen mit externen Bibliotheken ( SALib , UQpy, PyDOE). Geeignet für: Universitäten, Forschungsgruppen, Startups mit Python-Kompetenz ohne Budget für Kommerziallizenzen.

Python mit SALib + scikit-learn , die flexible Open-Source-Kombination Für Teams, die Surrogate-Modelle bauen oder Sensitivitätsanalysen (Sobol-Indizes, Morris-Methode) durchführen wollen: SALib (Sensitivitätsanalyse), scikit-learn (Surrogate-Modell-Training), NumPy/SciPy (Numerik) sind kostenlos und flexibel. Kein fertiges Missionsmodell enthalten, die Integration von Domänenphysik ist Eigenleistung. Geeignet für: Data-Science-affine Engineering-Teams, Surrogate-Modeling-Experimente, akademische Forschung.

Zusammenfassung:

• Raumfahrtprogramm mit großem Budget und Agentur-/Defense-Kontext → Ansys STK
• MATLAB bereits im Einsatz → MATLAB Aerospace Toolbox
• Open-Source, Python-nativ, Forschung/Startup → OpenMDAO oder SALib -Stack
• Surrogate-Modelle für rechenintensive Simulationen → scikit-learn auf Basis von Referenz-Monte-Carlo-Daten

Datenschutz und Datenhaltung

Missionsrisikosimulationen arbeiten mit Daten, die in der Regel keine personenbezogenen Informationen enthalten, Zuverlässigkeitskennzahlen, Umgebungsmodelle, Missionsspezifikationen. Das verändert aber nicht die Notwendigkeit sorgfältiger Datengovernance.

Export- und Geheimschutzrecht statt DSGVO: In der Luft- und Raumfahrt dominieren nicht DSGVO-Überlegungen, sondern Export-Regularien. Missionsdaten für Verteidigungs- oder Dual-Use-Programme unterliegen in Deutschland dem Außenwirtschaftsgesetz (AWG) und der EU-Dual-Use-Verordnung (EU) 2021/821, in US-Programmen dem ITAR (International Traffic in Arms Regulations) und EAR. Die Dual-Use-Verordnung behandelt schon die elektronische Übertragung gelisteter Technologie an einen Ort außerhalb der EU als Ausfuhr, ein Upload in einen US-Cloud-Dienst kann also genehmigungspflichtig sein. Ansys STK läuft als Desktop-Anwendung lokal, nur die Cloud-Komponenten laufen auf US-Servern. Für kontrollierte Missionsparameter bleiben die Analysen deshalb in der eigenen, oft netzwerkisolierten Umgebung.

Zivile kommerzielle Missionen: Auch zivile Satellitentechnik steht oft auf der Dual-Use-Liste, das klärt der Exportkontrollbeauftragte, nicht das Projektteam. Für Programme ohne gelistete Technologie gelten normales IT-Sicherheitsrecht und die AVV-Anforderungen der DSGVO, sobald personenbezogene Daten (Ingenieuraccounts, interne Review-Dokumentationen) im System gespeichert werden. OpenMDAO und die MATLAB Aerospace Toolbox können vollständig on-premises betrieben werden, keine Daten verlassen die eigene Infrastruktur.

Empfehlung: Klärung mit dem Datenschutzbeauftragten und, wo relevant, dem Exportkontrollbeauftragten vor Einführung jedes Cloud-basierten Simulationstools, unabhängig davon, ob personenbezogene Daten verarbeitet werden oder nicht.

Was es kostet, realistisch gerechnet

Einmalige Einrichtungskosten Der mit Abstand größte Kostenblock ist keine Software, sondern Ingenieurzeit. Ein Systemzuverlässigkeitsmodell für einen Kleinsatelliten erfordert nach unserer Einschätzung 3–6 Personenmonate erfahrener Systems-/Reliability-Ingenieure, bei rund 12.000 Euro Arbeitgeberkosten je Personenmonat also 36.000–72.000 Euro. Hinzu kommen Kosten für historische Zuverlässigkeitsdaten (Komponentendatenbanken, Qualifikationsberichte): je nach Quelle zwischen kostenlos (NASA/ESA-Publikationen) und mehreren Zehntausend Euro für kommerzielle Datenbanken wie EPRD (Electronic Parts Reliability Data). Zusammen mit Lizenzen und Rechenzeit liegt die Einrichtung damit bei rund 40.000 bis gut 200.000 Euro, je nachdem, ob STK-Lizenzen und kommerzielle Zuverlässigkeitsdaten dazukommen.

Softwarelizenzen:

• MATLAB Aerospace Toolbox : im deutschen MathWorks-Store 2.410 Euro plus 1.770 Euro im Jahr für MATLAB und Toolbox
• Ansys STK Analyzer: Preis nur auf Anfrage, laut unserer Toolseite im fünf- bis sechsstelligen Bereich jährlich je Sitz
• OpenMDAO + Python-Stack: kostenlos

Laufende Kosten Hauptkostentreiber im Betrieb: Ingenieurzeit für Modellpflege (ca. 0,5–1 Personenmonat je Missionsstudie) und HPC-Compute für große Simulationsläufe (100.000+ Samples bei komplexen Modellen: 200–2.000 EUR je Rechenzentrumsauftrag). Softwarelizenzen laufen jährlich weiter.

Wie der ROI sichtbar wird Die direkte Messgröße ist nicht die Anzahl verhindeter Schäden, das lässt sich nicht beobachten. Valide Indikatoren:

1. Designänderungen, die durch Simulationsergebnisse ausgelöst wurden, bevor Hardware gebaut war, und der geschätzte Kostenvorteil gegenüber einer Änderung nach der Hardware-Integration
2. Reduzierte Anzahl teurer Late-Stage-Reviews durch frühzeitig geklärte Risikovektoren
3. Günstigere Versicherungskonditionen durch probabilistische Risikodokumentation, wenn der Versicherer sie honoriert
4. Erfüllung von Agentur- und Vertragsanforderungen an die Zuverlässigkeitsanalyse (bei ESA-Programmen ECSS-Q-ST-30C „Dependability”, bei anderen Auftraggebern die jeweiligen Vertragsvorgaben)

ROI-Beispiel mit offenen Annahmen: Ein Kleinsatellitenprogramm (Gesamtkosten 15 Mio. EUR) investiert rund 150.000 EUR in eine Monte-Carlo-Missionsrisikoanalyse: 6 Personenmonate zu je rund 12.000 Euro, also 72.000 Euro, dazu Lizenzen, Zuverlässigkeitsdaten und Rechenzeit. Zwei kritische Designrisiken werden identifiziert und in der Konzeptionsphase behoben, Kosten je Behebung: 50.000 EUR. Dieselben Änderungen nach der Hardwareintegration: geschätzte 500.000–1.500.000 EUR. Die Investition zahlt sich aus, wenn auch nur eine dieser Änderungen sonst erst nach der Integration aufgefallen wäre. Genau das weißt du aber nicht: Vielleicht hätte die FMEA das Risiko ebenfalls gefunden, vielleicht wäre es nie eingetreten. Deshalb gehört neben die Rechnung die ehrliche Frage, welche der gefundenen Risiken die bisherigen Methoden übersehen hatten.

Drei typische Einstiegsfehler

1. Mit dem Simulationsmodell starten, bevor die Eingangsverteilungen valide sind. Das ist der häufigste und folgenreichste Fehler: Ein elaboriertes Monte-Carlo-Setup mit sorgfältig programmierten Systemmodellen, aber die Zuverlässigkeitsverteilungen für Komponenten basieren auf Default-Annahmen aus generischen Handbüchern, nicht aus missionsspezifischen Qualifikationstests. Ergebnis: Präzise Wahrscheinlichkeitsaussagen auf falscher Datenbasis. Die Simulation liefert P(Missionserfolg) = 96,3 %, eine Zahl, die falsche Sicherheit vermittelt, weil die echten Komponentenausfallraten nicht bekannt sind. Lösung: Zuerst eine ehrliche Inventur der vorhandenen Zuverlässigkeitsdaten. Was ist durch Tests belegt, was ist eine Annahme? Nur für belegte Parameter lohnt sich der Aufbau des Simulationsmodells.

2. Monte-Carlo mit physikalischer Simulation verwechseln. Missionsanalyse-Teams mit MATLAB-Hintergrund bauen oft ein Simulink-Modell und nennen jeden Parametervariationsrun „Monte Carlo”. Das ist technisch korrekt, aber häufig mit Missverständnissen verbunden: Varianzanalyse (was ist sensitiv?) ist kein Ersatz für Zuverlässigkeitsanalyse (wie wahrscheinlich ist ein Ausfall?). Ein Modell, das ausschließlich physikalische Parameterstreuung abbildet, erfasst keine Komponentenausfälle durch Erschöpfung oder Herstellungsdefekte. Lösung: Explizit zwischen Parametervarianzstudien und echten Zuverlässigkeits-/Risikoanalysen unterscheiden, beide sind nützlich, aber sie beantworten verschiedene Fragen.

3. Das Modell nach dem ersten Lauf nicht validieren. Das Simulationsmodell produziert Ergebnisse, aber sind sie plausibel? Stimmen die Ausfallraten mit dem Betriebsverhalten vergleichbarer Missionen überein? Gibt es öffentliche Referenzdaten, etwa aus Veröffentlichungen von NASA und ESA zur Produktsicherung, gegen die die Modellannahmen kalibriert werden können? Wer diesen Validierungsschritt überspringt, hat kein Risikomodell, er hat einen aufwändig programmierten Zufallszahlengenerator. Lösung: Mindestens zwei unabhängige Validierungspunkte vor dem ersten produktiven Einsatz: Vergleich mit historischen Missionen ähnlicher Klasse und Review durch eine nicht am Modellbau beteiligte Gruppe. Behandle das Modell danach als lebendes Dokument: Für jede wesentliche Missionsentscheidung explizit prüfen, welche Modellannahmen betroffen sind, und eine namentlich benannte Person für die Pflege verantwortlich machen.

Was mit der Einführung wirklich passiert, und was nicht

Die Technik ist das Einfachste.

Das Schwierige an der Einführung von Missionsrisiko-Szenario-Simulation sind weder die Tools noch die Mathematik hinter der Simulation. Es sind drei menschliche und organisatorische Dynamiken, die in nahezu jedem Programm auftreten:

Der Kampf um die Modellhoheit. Sobald ein Simulationsmodell Risikoaussagen produziert, wird es politisch: Welche Designentscheidung war zu riskant? Welches Subsystemteam hat ein riskantes Element geliefert? Subsystemverantwortliche neigen dazu, konservativere Zuverlässigkeitsannahmen für sich selbst zu bestreiten, weil sie potenzielle Designkritik vermeiden wollen. Das Simulationsteam braucht eine klare, formale Governancestruktur für die Eingabedaten: Wer verifiziert welche Verteilung? Wer kann Eingangsparameter mit welcher Begründung ändern? Ohne diesen Prozess wird das Modell ein Verhandlungsinstrument, kein Analyseinstrument.

Die Ergebnisunsicherheit, die niemand kommunizieren will. Eine valide Simulation liefert keine scharfen Aussagen, sie liefert Verteilungen und Konfidenzintervalle. Wenn der Output lautet „P(Missionserfolg) = 91,2 % mit 90-%-Konfidenzintervall [84,1 %, 96,4 %]”, ist das für Ingenieursmanager oft schwer zu kommunizieren, und für Investoren oder Auftraggeber zuweilen unangenehm. Der Druck, eine runde, sichere Zahl zu nennen, ist real. Das darf nicht dazu führen, die Konfidenzintervalle aus den Berichten wegzulassen. Sie sind das Ergebnis, nicht der Fehler.

Der fehlende Feedback-Loop. Missionen, die erfolgreich verlaufen, liefern kein direktes Feedback über die Qualität der Risikovorhersage, weil wir nicht wissen, wie nahe sie einer Fehlfunktion waren. Teams, die Missionssimulationsmodelle aufbauen, sollten explizit planen, wie sie Telemetriedaten aus dem Betrieb zurück in die Modelle fließen lassen. Das ist die einzige Möglichkeit, die Qualität der Eingangsverteilungen systematisch zu verbessern.

Was konkret hilft:

• Simulationsmodell-Governance früh formalisieren: wer genehmigt Parameteränderungen?
• Unsicherheitsaussagen in Berichten explizit einfordern, Ergebnisskommunikation schulen, nicht glätten
• Review-Checkpoint nach der ersten abgeschlossenen Mission: was haben wir gelernt, welche Verteilungsannahmen waren falsch?
• Einen internen Simulationsexpert als kontinuierlichen Ansprechpartner etablieren, nicht nur für die Aufbauphase

Realistischer Zeitplan mit Risikohinweisen

Wichtig: Diese Timeline gilt für einen seriösen, validen Aufbau. Programme, die schnellere Ergebnisse brauchen, müssen den Scope explizit einschränken, lieber eine Missionsfunktion vollständig modelliert als fünf Funktionen auf unsicherer Datenbasis.

Häufige Einwände, und was dahintersteckt

„Wir machen schon FMEA und Fault Tree Analysis, wozu noch Monte Carlo?” FMEA und FTA sind systematische Methoden zum Aufspüren bekannter Ausfallmodi. Sie sind unverzichtbar und kein Ersatz für Monte-Carlo-Simulation, die umgekehrt auch kein Ersatz für FMEA/FTA ist. Der Unterschied: FMEA fragt „Was kann schiefgehen und warum?” Monte-Carlo fragt „Wie wahrscheinlich ist es, dass das kombinierte System unter realen Betriebsbedingungen sein Missionsziel erreicht?” Beide Antworten braucht man. Programme unter ECSS-Q-ST-30C („Dependability”) müssen ohnehin Zuverlässigkeitsanalysen liefern, welche Methode der Auftraggeber dafür erwartet, steht im Vertrag.

„Für unsere Mission haben wir keine historischen Zuverlässigkeitsdaten.” Das ist ein reales Problem, und ehrlicher als Teams, die es verschweigen und generische Default-Werte aus Handbüchern verwenden. Mögliche Auswege: Expert-Elicitation (strukturierte Befragung von Subsystemexperten mit formaler Unsicherheitsquantifizierung), konservative Sensitivitätsstudie (welche Parameter dominieren das Ergebnis, und wie viel Unsicherheit in diesen Parametern ist tolerierbar?), und schrittweise Kalibrierung während des Qualifikationstests. Das ist aufwändig, aber transparenter als Zahlen, die nicht auf Daten basieren.

„Das ist alles zu komplex für unser Team, wir sind keine Simulationsspezialisten.” Das stimmt, und es ist kein Vorwurf, sondern ein wichtiger Erkenntnisstand. Eine Missionsrisikosimulation, die durch ein Team ohne Simulationserfahrung auf Basis falscher Annahmen aufgebaut wird, ist gefährlicher als keine Simulation, weil sie falsche Sicherheit erzeugt. Die Lösung ist nicht, das zu ignorieren, sondern: entweder externe Expertise einzukaufen (spezialisierte Beratungsunternehmen für Raumfahrtzuverlässigkeit), oder mit einem klaren Scope-Limit zu starten, zum Beispiel nur Launcher-Kompatibilitätsanalyse und Startfensterbewertung als ersten Schritt.

Woran du merkst, dass das zu dir passt

• Du planst eine Mission mit einem Missionswert von mehr als 10 Mio. EUR, unter dieser Schwelle ist der Aufbau einer vollständigen probabilistischen Risikoanalyse selten zu rechtfertigen; für Kleinstmissionen genügen konservative deterministische Worst-Case-Analysen.
• Dein Programm unterliegt Vertragsanforderungen, die Zuverlässigkeits- oder probabilistische Risikoanalysen fordern, etwa ESA-Programme nach ECSS-Q-ST-30C oder entsprechende Anforderungen anderer Auftraggeber
• Du hast oder kannst aufbauen: Zuverlässigkeitsdaten aus Komponentenqualifikation oder vergleichbaren Vorgängermissionen, ohne Datenbasis keine validen Verteilungen, ohne valide Verteilungen kein valides Modell
• Du hast ein Systems-Engineering-Team mit mindestens 3 erfahrenen Ingenieuren, darunter einen für Zuverlässigkeit, mit Kapazität für Modellaufbau, Validierung und Pflege

Wann es sich (noch) nicht lohnt, drei harte Ausschlusskriterien:

1. Deine Mission ist eine echte Erstausführung ohne vergleichbares Vorgängerprogramm. Für vollständig neue Missionsarchitekturen (erste Constellation-Mission eines neuen Betreibers, erste Nutzung einer neuen Triebwerkstechnologie) fehlen die Priorendaten für valide Verteilungen. Monte-Carlo auf Basis von Expertenmeinungen und Handbuch-Defaults ist besser als nichts, aber es gibt eine echte Gefahr, dass die Ergebnisse präziser wirken als sie sind. Ehrlicher ist hier: Sensitivitätsanalyse statt vollständiger Probabilistik, und explizite Kommunikation der Modellgrenzen.

2. Dein Team hat keinen dedizierten Systemzuverlässigkeitsingenieur. Missionsrisikosimulation ist keine Software-Tool-Aufgabe, die man nebenbei macht. Jemand muss die Eingangsverteilungen verantworten, das Modell validieren und Ergebnisse interpretieren. Fehlt diese Person, sind die Simulationsergebnisse nicht vertrauenswürdig, egal welches Werkzeug genutzt wird.

3. Deine Missionsdauer ist unter 6 Monate und das Systemdesign ist bereits abgeschlossen. Monte-Carlo-Simulation zur Missionsrisikoabschätzung entfaltet ihren Hauptnutzen in der Konzeptionsphase. Für eine Mission, die in 6 Monaten startet und deren Hardware fertig gebaut ist, ist eine vollständige neue Simulationsinfrastruktur keine sinnvolle Investition, du kannst das Ergebnis nicht mehr in Designänderungen umsetzen.

Das kannst du heute noch tun

Der beste Einstieg ohne Verpflichtung: Lade OpenMDAO herunter und führe das enthaltene Sellar-Tutorial durch. Du wirst in zwei Stunden sehen, wie multidisziplinäre Optimierungen strukturiert werden, und ob die Denkweise auf dein Team und deine Mission passt.

Für eine erste ehrliche Risikoabschätzung ohne eigene Simulation kannst du LLMs wie ChatGPT oder Claude als strukturierte Denkunterstützung einsetzen, nicht für die Simulation selbst, sondern für die Frage, welche Parameter die größten Unsicherheiten darstellen und welche Wechselwirkungen du noch nicht durchdacht hast. Beschreib die Mission dabei so allgemein wie im Beispiel unten. Konstruktionsdaten, Qualifikationsberichte oder Missionsparameter aus Dual-Use- und Verteidigungsprogrammen gehören nicht in einen US-Chat-Dienst, siehe Exportkontrolle oben, im Zweifel fragst du vorher den Exportkontrollbeauftragten:

Quellen & Methodik

• NASA CARA-Programm (Conjunction Assessment Risk Analysis): Mashiku, A. K.; Newman, L. K., „NASA Conjunction Assessment Risk Analysis (CARA) Compendium for Artificial Intelligence and Machine Learning for Satellite Collision Avoidance”, AMOS-Konferenz 2025, NTRS-20250002065. Überblick über ML-Ansätze, darunter LSTM-Netze auf Conjunction Data Messages.
• Mars Polar Lander (1999): Missionskosten rund 165 Mio. USD (Entwicklung, Start, Betrieb); wahrscheinlichste Fehlerursache laut Failure Review Board die vorzeitige Triebwerksabschaltung, weil die Software Schwingungen beim Ausfahren der Landebeine als Bodenkontakt deutete (NASA Mars Polar Lander Failure Review Board Report, 2000).
• Hubble-Spiegelfehler (1990): Rand des Hauptspiegels rund 2,2 Mikrometer zu flach, Ursache eine um 1,3 Millimeter versetzte Linse im Prüfgerät, abweichende Ergebnisse älterer Prüfverfahren wurden verworfen (Wikipedia, „Hubble Space Telescope”, Abschnitt zum Spiegelfehler, abgerufen September 2026).
• Hanson & Beard (2010): NASA/TP-2010-216447, „Applying Monte Carlo Simulation to Launch Vehicle Design and Requirements Analysis”, NASA Marshall Space Flight Center, methodischer Standardreferenzrahmen für probabilistische Launchvehicle-Analyse.
• Kostendaten MATLAB: Deutscher MathWorks-Store, laut unserer Toolseite zur MATLAB Aerospace Toolbox (Stand Juli 2026).
• Ansys STK: Preisrahmen, Desktop-Betrieb und Exportkontrolle laut unserer Toolseite zu Ansys STK.
• OpenMDAO: openmdao.org, Apache 2.0 Lizenz, NASA Glenn Research Center, kostenlos, aktiv entwickelt.
• ECSS-Q-ST-30C Rev.1: European Cooperation for Space Standardization, „Space product assurance, Dependability” (15. Februar 2017), ecss.nl. Legt das Dependability-Programm und die Zuverlässigkeitsanforderungen für Raumfahrtsysteme fest.
• Ausfuhrbegriff im EU-Recht: Verordnung (EU) 2021/821 (Dual-Use-Verordnung), Artikel 2 Nummer 2.
• Personenmonat, Einrichtungskosten, Kosten je Designänderung: Annahmen für die Rechnung, keine veröffentlichten Branchenwerte.

Du willst wissen, ob eine probabilistische Risikoanalyse für dein Programm sinnvoll ist und wie groß der Aufwand wäre? Meld dich, das klären wir in einem kurzen Gespräch.