Modellbasiertes Systems Engineering für Verteidigungsprogramme: SysML, Digital Thread und DoDAF-Integration

Verteidigungsprogramme stehen vor einem Systems-Engineering-Problem, das schlecht skaliert. Ein großes Waffensystemprogramm – ein neues Infanterie-Kampffahrzeug, ein Radar-Upgrade, ein luftgestütztes Kommunikationsrelais – kann 10.000 bis 50.000 einzelne Anforderungen umfassen, die auf Dutzende Subsysteme verteilt sind, die von verschiedenen Ingenieurteams und oft verschiedenen Auftragnehmern entwickelt werden. Anforderungen werden in Microsoft Word geschrieben. Die Architektur wird in Visio gezeichnet. Schnittstellendefinitionen leben in Interface Control Documents, die von jedem Team asynchron aktualisiert werden. Testpläne referenzieren Anforderungsabsatznummern, die sich lautlos geändert haben. Wenn ein Engineering Change Proposal eintrifft, verbringen drei Ingenieure eine Woche damit, manuell durch fünfzig Dokumente zu suchen, um zu verstehen, was die Änderung betrifft.

Modellbasiertes Systems Engineering (MBSE) ersetzt dieses Dokumentennetz durch ein einziges, semantisch reiches Modell – ein strukturiertes Repository von Anforderungen, Architekturelementen, Verhaltensspezifikationen und Rückverfolgbarkeitsbeziehungen, das die maßgebliche Quelle ist, aus der alle Dokumente generiert werden. SysML stellt die Modellierungssprache bereit. Werkzeuge wie Cameo Systems Modeler und IBM Rhapsody stellen die Umgebung bereit. Der Digital Thread verbindet das Modell mit Simulation, Codegenerierung und Testautomatisierung. DoDAF-Architekturansichten werden als Berichte aus dem Modell erzeugt, anstatt als separate Artefakte gepflegt zu werden.

Dieser Artikel ist eine praktische Engineering-Referenz für Verteidigungsprogrammmanager, leitende Systems Engineers und Softwarearchitekten, die MBSE evaluieren oder implementieren. Er behandelt den Kontrast zwischen dokumentenzentrischem und modellzentrischem Ansatz, die Verwendung von SysML-Diagrammtypen für Verteidigungssysteme, Anforderungsverfolgbarkeit im Modell, den Digital Thread von Anforderungen bis zum Prototyp, DoDAF-Ansichtsgenerierung, Überlegungen zum Werkzeug-Ökosystem sowie die organisatorischen und Governance-Herausforderungen, die darüber entscheiden, ob eine MBSE-Initiative erfolgreich ist oder in die Dokumentenzentriertheit zurückfällt.

Warum MBSE für Verteidigungsprogramme wichtig ist

Das grundlegende Problem mit dokumentenzentrischem Systems Engineering ist, dass Dokumente voneinander getrennt sind. Eine System Requirements Specification wird geschrieben; eine Architekturbeschreibung wird verfasst, die auf SRS-Absatznummern verweist; ein Interface Control Document wird geschrieben, das auf die Architektur verweist; ein Testplan wird erstellt, der auf das ICD verweist. Jedes Dokument ist eine Momentaufnahme. Wenn sich Anforderungen ändern – und in Verteidigungsprogrammen ändern sich Anforderungen immer – bricht die Kette manueller Querverweise, die diese Dokumente konsistent hält. Die SRS-Absatznummer ändert sich, und die Architekturbeschreibung verweist lautlos auf eine Anforderung, die nicht mehr existiert. Das ICD beschreibt eine Schnittstelle, die neu gestaltet, aber nie aktualisiert wurde. Der Testplan verifiziert ein Verhalten, das vor sechs Monaten durch einen ECP abgelöst wurde.

MBSE begegnet diesem Problem, indem es das Modell zur einzigen Quelle der Wahrheit macht. Anforderungen, Architekturblöcke, Schnittstellen und Verhaltensspezifikationen sind alle Elemente im selben semantischen Modell mit typisierten Beziehungen zwischen ihnen. Wenn sich eine Anforderung im Modell ändert, zeigt das Werkzeug sofort alle Architekturblöcke, die ihr zugeordnet sind, alle Schnittstellen, die diese Blöcke exponieren, und alle Testfälle, die das Verhalten verifizieren. Eine Änderungsauswirkungsanalyse, die in einem dokumentenzentrierten Programm eine Woche dauert, dauert in einem gut gepflegten MBSE-Modell Minuten.

Die spezifischen Vorteile für Verteidigungsprogramme – im Unterschied zu kommerziellen Softwareprojekten – ergeben sich aus der formalen Überprüfungsstruktur des Programms. Der Defense-Software-Entwicklungslebenszyklus umfasst System Requirements Review (SRR), Preliminary Design Review (PDR) und Critical Design Review (CDR) als vertraglich vorgeschriebene Gates mit definierten Eingangs- und Erfolgskriterien. MBSE verändert den Charakter dieser Reviews: Anstatt die Konsistenz eines Dokumentenstapels zu bewerten, fragen Prüfer das Modell nach Abdeckungsmetriken ab – welcher Prozentsatz der Anforderungen wurde Architekturelementen zugeordnet, welcher Prozentsatz der Schnittstellen wurde formal spezifiziert, welcher Prozentsatz der Testfälle wurde mit Anforderungen verknüpft. Dies sind objektive, automatisierbare Maße der technischen Vollständigkeit, keine subjektiven Bewertungen der Dokumentenqualität.

Mehrdeutigkeitsreduzierung ist der andere wesentliche Vorteil. Anforderungen in natürlicher Sprache sind von Natur aus mehrdeutig – derselbe Satz kann vom Systems Engineer, der ihn schrieb, vom Softwareingenieur, der ihn implementiert, und vom Testingenieur, der ihn verifiziert, unterschiedlich gelesen werden. Wenn eine Anforderung als SysML-Requirement-Element mit einer spezifischen Schnittstellenzuordnung, einer spezifischen parametrischen Einschränkung und einem spezifischen Testfall ausgedrückt werden muss, wird die Mehrdeutigkeit ans Licht gebracht. Wenn das Modellierungsteam sich nicht einigen kann, wie die Anforderung im Modell dargestellt werden soll, wurde eine echte Mehrdeutigkeit in der Anforderung identifiziert, die vor der Implementierung gelöst werden muss – nicht danach.

SysML für Verteidigungssysteme

SysML (Systems Modeling Language) ist die OMG-Standardsprache für MBSE. Sie erweitert UML um Diagrammtypen, die speziell für das Systems Engineering entwickelt wurden: Block Definition Diagrams, Internal Block Diagrams, Requirement Diagrams, Parametric Diagrams und Allocation Tables. Zu verstehen, welche Diagrammtypen in einem Verteidigungskontext echten Wert liefern – und welche Aufwand verbrauchen ohne proportionalen Nutzen – ist für ein produktives MBSE-Programm unerlässlich.

Block Definition Diagrams (BDD) sind das wertvollste SysML-Artefakt für Verteidigungssysteme. Ein BDD definiert die strukturelle Taxonomie des Systems: welche Blöcke existieren, welche Eigenschaften und Operationen sie haben, wie sie durch Generalisierungsbeziehungen spezialisiert werden und welche typisierten Ports sie für die Verbindung mit anderen Blöcken exponieren. Im Kontext eines Waffensystems beantwortet das BDD: Was sind die Subsysteme, welche Zerlegungsbeziehungen bestehen, und was sind die Schnittstellentypen zwischen ihnen? Das BDD ist keine Zeichnung – es ist eine formale Strukturdefinition, aus der alle nachgelagerten Artefakte abgeleitet werden. Ein auf einem BDD-Port definierter Schnittstellentyp ist die maßgebliche Spezifikation für diese Schnittstelle; das ICD ist ein daraus generierter Bericht.

Internal Block Diagrams (IBD) zeigen, wie Blockinstanzen für einen bestimmten Kontext verbunden sind. Während das BDD den Typ „Sensor Subsystem hat einen Port vom Typ DataLink" definiert, zeigt das IBD die spezifische DataLink-Verbindung zwischen der Sensor-Subsystem-Instanz und der Mission-Computer-Instanz in der Systemassemblierung auf oberster Ebene. IBDs sind das primäre Architekturdiagramm für IntegrationsIngenieure: Sie spezifizieren genau, was mit was verbunden ist, über welchen Porttyp und auf welcher Systemassemblierungsebene. Aus IBDs generierte ICDs sind von Natur aus subsystemübergreifend konsistent – eine Eigenschaft, die unmöglich zu garantieren ist, wenn ICDs unabhängig gepflegt werden.

Activity Diagrams modellieren das Systemverhalten in Form von Aktionen und Kontrollfluss. In Verteidigungskontexten sind sie am nützlichsten für Missionsausführungssequenzen (die Abfolge von Schritten von der Missionsplanung über die Ausführung bis zur Post-Mission-Analyse), zur Spezifikation des Verhaltens sicherheitskritischer Modi und zur Definition des operationellen Workflows, den das System unterstützen muss. Activity Diagrams werden übermäßig aufwendig, wenn sie auf Low-Level-Softwarealgorithmen angewendet werden – diese Granularität gehört in das Softwaredesign, nicht in die Systemarchitektur.

Sequence Diagrams modellieren Nachrichtenaustausche zwischen Systemkomponenten über die Zeit. Sie sind wertvoll zur Spezifikation sicherheitskritischer Protokolle (Authentifizierungs-Handshakes, Schlüsselaustauchsequenzen), zeitkritischer Koordinationsprotokolle (Feuerleitkopplung zwischen Sensor, C2 und Effekteur) und Mensch-System-Interaktionssequenzen für sicherheitskritische Operationen. Sequence Diagrams sind eine schlechte Wahl für die Modellierung des Großteils des Systemverhaltens – die kombinatorische Explosion von Sequenzvarianten macht sie im großen Maßstab unwartbar. Verwenden Sie sie für die 5–10 % der Verhaltensweisen, bei denen die präzise Inter-Komponenten-Nachrichtenreihenfolge architektonisch bedeutsam ist.

Parametric Diagrams sind für Verteidigungssysteme einzigartig wertvoll, wo Leistungseinschränkungen zugeordnet und verfolgt werden müssen. Ein parametrisches Diagramm drückt mathematische Einschränkungen zwischen Blockeigenschaften aus – zum Beispiel die Einschränkung, dass die End-to-End-Latenz einer Ziellösung die Summe aus Sensorerfassungslatenz, Verarbeitungslatenz und Kommunikationslatenz ist und dass die Gesamtsumme weniger als 500 ms betragen muss. Diese Einschränkungen können mit Simulationsparametern verbunden und gegen tatsächliche Messungen beim Integrationstest ausgewertet werden, wodurch ein modellgesteuerter Leistungsverifizierungsprozess entsteht.

Was nicht zu modellieren ist: Vermeiden Sie die Erstellung von Sequence Diagrams oder Activity Diagrams für jede Funktion im System. Übermodellierung erzeugt eine Wartungslast, die den Rückverfolgbarkeitsnutzen übersteigt. Modellieren Sie die Architekturstruktur erschöpfend (BDD und IBD); modellieren Sie das Verhalten selektiv, mit Fokus auf sicherheitskritische, schutzrelevante und architektonisch bedeutsame Interaktionen.

Anforderungsmodellierung und Rückverfolgbarkeit

Anforderungsverfolgbarkeit ist die Fähigkeit, die MBSE-Investitionen in Verteidigungsprogrammen am konsequentesten rechtfertigt. Die Disziplin des Anforderungsmanagements in der Verteidigungssoftware hat sich von tabellenbasierten Rückverfolgbarkeitsmatrizen zu modellintegrierter Rückverfolgbarkeit entwickelt, bei der die Beziehungen selbst erstklassige Modellelemente mit semantischen Typen sind.

In SysML wird die Anforderungsverfolgbarkeit durch vier typisierte Abhängigkeitsbeziehungen implementiert:

• «derive» – verbindet eine Systemanforderung mit dem Stakeholder-Bedarf oder der übergeordneten Anforderung, die sie verfeinert. Jede Systemanforderung sollte mindestens eine «derive»-Beziehung haben; eine Anforderung ohne eine solche ist entweder nicht gerechtfertigt, oder ihr Stakeholder-Bedarf wurde nicht modelliert.
• «satisfy» – verbindet ein Architekturelement (Block, Komponente, Schnittstelle) mit der Anforderung, die es erfüllt. Dies ist die Kernrückverfolgbarkeitsbeziehung: Sie beantwortet „Welcher Teil des Systems erfüllt diese Anforderung?" Eine zugeordnete Anforderung ohne «satisfy»-Beziehung ist nicht implementiert.
• «verify» – verbindet einen Testfall oder eine Testprozedur mit der Anforderung, die er verifiziert. Eine Anforderung mit einer «satisfy»-Beziehung, aber ohne «verify»-Beziehung, ist entworfen, aber unverifiziert – eine Lücke, die in einem dokumentenzentrierten Programm beim TRR entdeckt würde, aber im Modell kontinuierlich sichtbar ist.
• «refine» – verbindet ein detaillierteres Modellelement (wie eine Zustandsmaschine oder Aktivität) mit der Anforderung, die es ausarbeitet. Verwendet, wenn die Anforderung durch eine Verhaltensspezifikation und nicht direkt durch ein strukturelles Element erfüllt wird.

Die Zuordnungsmatrix – die die meisten MBSE-Werkzeuge als interaktiven Bericht generieren – stellt Anforderungen gegenüber Architekturelementen in einer Querverweistabelle dar, wobei jede Zelle angibt, ob eine «satisfy»-Beziehung existiert. Diese Matrix ersetzt die manuell gepflegte Rückverfolgbarkeitsmatrix-Tabellenkalkulation, die das Zentrum dokumentenzentrierter Compliance-Nachweise ist. Im Gegensatz zur Tabellenkalkulation ist die modellabgeleitete Matrix stets aktuell: Sie wird aus dem Live-Modell neu generiert, nicht manuell aktualisiert.

Die Hierarchie von Stakeholder- zu Systemanforderungen verdient besondere Aufmerksamkeit. Verteidigungsprogramme erhalten Stakeholder-Bedürfnisse aus mehreren Quellen: dem operationellen Nutzer (ausgedrückt im Concept of Operations), der Beschaffungsbehörde (ausgedrückt in der System Performance Specification) und abgeleiteten internen Anforderungen (ausgedrückt in Subsystem-ICDs und untergeordneten Spezifikationen). Das Modellieren all dieser Quellen als Anforderungshierarchie in SysML macht die Ableitungsgrundlage explizit: Eine bestimmte Systemanforderung existiert, weil sie einen spezifischen operationellen Bedarf erfüllt, der seinerseits eine spezifische Missionsanforderung aus dem ConOps erfüllt. Wenn eine Systemanforderung in Frage gestellt wird – was bei Programmkostenreduzierungsübungen häufig passiert – zeigt das Modell genau, welche operationellen Bedürfnisse unerfüllt blieben, wenn die Anforderung gestrichen würde, und gibt dem leitenden Systems Engineer eine strukturierte Grundlage für die Kompromissentscheidung.

-- SysML 2.0 textuelle Notation: Fragment der Anforderungshierarchie
requirement def MissionCommunicationsNeed {
    doc /* Das System soll während des gesamten Missionseinsatzraums
         eine Kommunikationsverbindung mit dem C2-Knoten aufrechterhalten. */
}

requirement def DataLatencyRequirement :> MissionCommunicationsNeed {
    doc /* Die End-to-End-Sprach-/Datenlatenz von der Quelle zum C2-Knoten
         soll unter allen Bedingungen 500 ms nicht überschreiten. */
    assume constraint { latencyBudget <= 500 [ms] }
}

requirement def LinkAvailabilityRequirement :> MissionCommunicationsNeed {
    doc /* Die Verfügbarkeit der Kommunikationsverbindung soll über
         jeden 24-stündigen Missionszeitraum gemittelt 99,5 % überschreiten. */
}

Die oben gezeigte textuelle SysML-2.0-Notation veranschaulicht die Ableitungshierarchie: DataLatencyRequirement und LinkAvailabilityRequirement sind Spezialisierungen des Stakeholder-Bedarfs und erben seinen Kontext, während sie messbare Abnahmekriterien spezifizieren. Die parametrische Einschränkung (latencyBudget <= 500 [ms]) ist eine formale Eigenschaft, die mit Simulationsparametern und gemessenen Testergebnissen verknüpft werden kann – nicht nur ein Satz, den Testingenieure interpretieren müssen.

Der Digital Thread: Kontinuität vom Modell zum Prototyp

Der Digital Thread ist die verknüpfte Datenkette, die Modellelemente mit ihren nachgelagerten Implementierungen und Verifizierungsergebnissen verbindet. Im Kontext von Defense-MBSE hat der Digital Thread drei Hauptstränge: Modell-zu-Code-Generierung, Modell-zu-Testautomatisierung und Modell-zu-Simulation.

Modell-zu-Code-Generierung ist der ausgereifteste Strang des Digital Thread. IBM Rhapsody bietet seit zwei Jahrzehnten C- und C++-Codegenerierung aus UML/SysML-Zustandsmaschinen und Klassendiagrammen. Cameo integriert sich in SysML-zu-Ada- und SysML-zu-C++-Transformationen. Der generierte Code ist ein Gerüst oder Framework: Das Modell spezifiziert die Schnittstellenstruktur, die Zustandsmaschinenübergänge und die Datentypen; Ingenieure implementieren den Recheninhalt in generierten Methodenrümpfen. Der Wert liegt in der Schnittstellenkonsistenz: Wenn das SysML-BDD spezifiziert, dass der Ausgangsport eines Blocks eine Struktur vom Typ TargetTrack_t mit den Feldern position, velocity und classification trägt, sind die generierten Header-Dateien auf beiden Seiten jeder Schnittstelle, die diesen Typ verwendet, identisch. Die Klasse von Integrationsfehlern, die dadurch entsteht, dass zwei Ingenieure unabhängig voneinander eine ICD-Textbeschreibung interpretieren und leicht unterschiedliche Struct-Layouts erhalten, wird strukturell eliminiert.

Modell-zu-Testautomatisierung verbindet SysML-TestCase-Elemente mit Testausführungs-Frameworks. In den ausgereiftesten Implementierungen spezifiziert ein Testfall im Modell: die Anforderung, die er verifiziert (via «verify»), die Eingaben in das zu testende System (abgeleitet aus den Abnahmekriterien der Anforderung), die erwarteten Ausgaben (abgeleitet aus der Soll-Aussage der Anforderung) und das Besteh-/Versagenskriterium. Aus diesen Modellelementen erzeugt ein Generator Testskripte im Ziel-Test-Framework – Robot Framework für Tests auf Systemebene, pytest für Tests auf Komponentenebene oder proprietäre HIL-Skriptsprachen für Hardware-Integration. Wenn sich eine Anforderung ändert, führt der Generator einen erneuten Durchlauf durch und kennzeichnet Testfälle, deren erwartete Ausgaben nun inkonsistent mit der aktualisierten Anforderung sind – anstatt darauf zu warten, dass ein Mensch die Diskrepanz beim TRR bemerkt.

Modell-zu-Simulation (MBSE + SIL/HIL) ist der Strang des Digital Thread mit dem höchsten potenziellen Wert und der höchsten Implementierungskomplexität. SysML-Parametric Diagrams definieren die mathematische Struktur des Leistungsmodells des Systems – welche physikalischen Parameter welche Leistungseigenschaften einschränken, ausgedrückt als Constraint-Blöcke. Diese Constraint-Blöcke können durch MBSE-Werkzeugintegrationen (Cameo-MATLAB-Integration, Rhapsody-Simulink-Kosimulation) mit Simulink- oder Modelica-Simulationsmodellen verknüpft werden. Das Ergebnis ist eine Simulationskonfiguration, die aus dem Architekturmodell abgeleitet wird, anstatt parallel dazu gepflegt zu werden.

Die praktische Reife dieser Integration variiert erheblich. Die Modell-zu-Simulink-Parametersynchronisierung wird von den wichtigsten MBSE-Werkzeuganbietern gut unterstützt. Vollständige Modell-zu-HIL-Testautomatisierung – bei der eine SysML-Anforderungsänderung ohne manuellen Eingriff durch das Modell in aktualisierte HIL-Testskripte propagiert – erfordert erheblichen Integrationsengineering-Aufwand und wird von weniger als 15 % der Verteidigungsprogramme erreicht, die MBSE-Adoption beanspruchen (laut INCOSE-Umfragedaten). Die Programme, die dies erreichen, berichten von den dramatischsten Reduzierungen der Integrationstest-Zykluszeit, typischerweise 35–50 % kürzere Integrationsphasen im Vergleich zu dokumentenzentrierten Referenzprogrammen ähnlicher Systemkomplexität.

Die Verbindung zwischen MBSE und formaler Verifikation für Verteidigungssoftware verläuft durch den Digital Thread: SysML-Verhaltensmodelle (Zustandsmaschinen, Aktivitätsdiagramme) können in formale Spezifikationssprachen (TLA+, SPIN Promela) übersetzt werden für Model Checking, das mathematische Nachweise der Verhaltenskorrektheit liefert und die strukturelle Rückverfolgbarkeit des MBSE-Modells ergänzt.

DoDAF-Architekturansichten aus dem Modell

Das Department of Defense Architecture Framework (DoDAF) Version 2.02 definiert die obligatorischen Architektur-Viewpoints, die Verteidigungsbeschaffungsprogramme für das Capability Portfolio Management und die Interoperabilitätsbewertung von System-of-Systems erstellen müssen. In dokumentenzentrierten Programmen werden DoDAF-Ansichten als eigenständige Visio-Diagramme oder PowerPoint-Folien produziert, vor jeder Programmüberprüfung manuell aktualisiert und chronisch nicht synchron mit dem Engineering-Modell, das das eigentliche Systemdesign repräsentiert.

MBSE eliminiert den manuellen DoDAF-Produktionsaufwand, indem DoDAF-Ansichten zu generierten Ausgaben des Engineering-Modells werden. Die Abbildung von SysML-Modellelementen auf DoDAF-Datenelemente ist im Unified Profile for DoDAF and MODAF (UPDM) standardisiert, das als Plugin oder natives Profil in allen wichtigen MBSE-Werkzeugen unterstützt wird.

Die wichtigsten DoDAF-zu-SysML-Abbildungen für Verteidigungsprogramme sind:

• OV-1 (High-Level Operational Concept Graphic) – abgeleitet aus dem Use-Case-Diagramm des Systems auf oberster Ebene kombiniert mit Aktivitätsdiagrammen auf Kontextebene, die die operationelle Umgebung zeigen. Im Modell sind die Akteure der operationellen Umgebung, ihre Interaktionen mit dem System und die Missionsphasen als Use-Case- und Akteur-Elemente dargestellt; OV-1 ist eine stilisierte Darstellung dieser Elemente im operationellen Kontext statt in Engineering-Notation.
• OV-2 (Operational Resource Flow Description) – abgeleitet aus IBD-Konnektoren, die mit operationellen Informationstypen annotiert sind. Wenn IBD-Konnektortypen operative Semantik einschließen (ein Konnektor trägt „taktische Zieldaten" statt nur eines Datentypnamens), wird der OV-2 aus dem nach operationalem Fluss-Annotation gefilterten Konnektorsatz automatisch generiert.
• SV-1 (Systems Interface Description) – direkt abgeleitet aus dem IBD des Systems auf oberster Ebene, das physische Blockinstanzen und ihre Verbindungen zeigt. Dies ist die unkomplizierteste DoDAF-aus-Modell-Generierung: Der SV-1 ist im Wesentlichen das System-IBD, das mit DoDAF-konformer Ikonographie und Legende gerendert wird.
• SV-4 (Systems Functionality Description) – abgeleitet aus dem Aktivitätsmodell des Systems und zeigt, welche Funktionen von welchen Systemknoten ausgeführt werden. In SysML ist dies die Zuordnung von Aktivitätselementen zu Blockinstanzen, dargestellt in Zuordnungstabellen, die direkt auf SV-4-Inhalt abbilden.
• TV-1 (Technical Standards Profile) – abgeleitet aus den Standard-Elementen des Modells, wobei anwendbare Standards (MIL-STD-1553, Link 16, STANAG 4586) als Tagged Values oder Stereotyp-Eigenschaften an die Schnittstellen- und Blockelemente angehängt sind, die sie implementieren.

Die automatische Veröffentlichung in einem DoDAF-Daten-Repository – wie dem DoDAF Architecture Registry, einem Enterprise-Architecture-Werkzeug oder einem programmspezifischen SharePoint/Confluence-Repository – wird durch MBSE-Werkzeug-Scripting-APIs unterstützt. Ein nächtlicher automatisierter Auftrag kann alle DoDAF-Ansichten neu generieren, sie im Architektur-Repository veröffentlichen und die Veröffentlichung zeitstempeln, sodass Prüfer wissen, dass die Ansichten den gestrigen Modellzustand repräsentieren. Dies ist eine qualitative Verbesserung gegenüber DoDAF-Ansichten, die von einem dedizierten Architekten vor Überprüfungen aktualisiert werden – die modellabgeleiteten Ansichten sind stets aktuell, und ihr Inhalt ist auf Engineering-Modellelemente rückverfolgbar statt auf die Interpretation des Architekten des Designs.

MBSE-Werkzeug-Ökosystem für die Verteidigung

Das Defense-MBSE-Werkzeug-Ökosystem hat drei Hauptoptionen, jede mit unterschiedlichen Stärken, die verschiedenen Programmkontexten entsprechen.

Cameo Systems Modeler (Dassault Systèmes, früher No Magic) ist das dominante MBSE-Werkzeug im US-Verteidigungsmarkt. Seine Stärken sind umfassende SysML-1.x-Konformität, reife DoDAF/UPDM-Profilunterstützung, ein reiches Plugin-Ökosystem einschließlich Cameo Simulation Toolkit für parametrische Simulation und Teamwork Cloud für skalierbare Mehrbenutzer-Kollaborationsmodellierung mit detaillierter Zugriffskontrolle. Cameo wird von den meisten US-Hauptauftragnehmern bei großen Beschaffungsprogrammen eingesetzt. Seine Schwächen sind die Kosten (Enterprise-Lizenzen sind teuer), eine steile Lernkurve für Ingenieure ohne vorherige Modelliererfahrung und begrenzte native Unterstützung für die SysML-2.0-textuelle Notation (erwartet im Release-Zyklus 2026–2027). Für Programme, bei denen DoDAF-Konformität und Interoperabilität mit US-Hauptauftragnehmern primäre Anforderungen sind, ist Cameo die Standardwahl.

IBM Rhapsody ist das Werkzeug der Wahl, wenn modellgetriebene Codegenerierung eine primäre Programmlieferung ist. Die Codegenerierung von Rhapsody aus UML/SysML-Zustandsmaschinen ist die ausgereifteste in der Branche, und die Integration mit IBM Rational DOORS für Anforderungsmanagement über IBM Systems Design Rhapsody Model Manager schafft eine ausgereifte Rückverfolgbarkeitspipeline von DOORS-Anforderungen zu Rhapsody-Modellelementen bis zum generierten Code. Rhapsody ist das primäre Werkzeug für die Entwicklung eingebetteter Avioniksoftware in Programmen, bei denen das Modellierungsteam den Großteil des Softwarerahmens aus dem Modell generiert und Ingenieure die Implementierungen innerhalb generierter Frameworks fertigstellen. Die DoDAF-Unterstützung ist weniger ausgereift als bei Cameo, und die SysML-parametrische Unterstützung ist schwächer. Für Programme mit starkem Mandat für eingebettete Software-Modell-zu-Code-Generierung und bestehender IBM-Toolchain-Investition ist Rhapsody die angemessene Wahl.

Capella ist ein Open-Source-MBSE-Werkzeug, das von Thales entwickelt und nun unter dem Eclipse-Polarsys-Projekt gepflegt wird. Capella verwendet die ARCADIA-Modellierungsmethode statt SysML – seine Viewpoint-Hierarchie (Operational Analysis, System Analysis, Logical Architecture, Physical Architecture) entspricht nicht direkt SysML-Diagrammtypen, bildet aber natürlich auf die Phasen des Verteidigungsbeschaffungslebenszyklus ab. Die ARCADIA-Methode hat eine disziplinierte Abfolge der Architekturentwicklung, die Modellierungsteams durch die richtige Reihenfolge von Modellierungsentscheidungen führt, was die methodische Mehrdeutigkeit reduziert, die SysML-basierte Programme plagt, wo das Werkzeug Fähigkeiten bietet, aber keine Methodenführung. Capella hat keine Lizenzkosten, was es für Programme mit begrenzten Budgets, kleinere Auftragnehmer und akademische/Schulungskontexte zugänglich macht. Add-ons bieten DoDAF-Ansichtsgenerierung und Simulink/FMI-Kosimulation. Für europäische Verteidigungsprogramme – insbesondere solche in der französischen und britischen Verteidigungsindustriebasis, wo der Thales-Einfluss stark ist – wird Capella zunehmend zum Standard.

Die Werkzeugqualifizierung für sicherheitskritische Entwicklung ist eine Überlegung, die unabhängig von der Werkzeugwahl gilt. Jede MBSE-Werkzeugfunktion, die zur Generierung von Artefakten verwendet wird, die als Compliance-Nachweise behandelt werden – generierter Code, generierte Testskripte, generierte Verifizierungsberichte – muss unter DO-330 (für Luftfahrtprogramme) oder dem anwendbaren Softwarewerkzeug-Qualifizierungsstandard des Programms qualifiziert werden. Werkzeugqualifizierung ist typischerweise nicht für die Modellierungs- und Rückverfolgbarkeitsfunktionen von MBSE-Werkzeugen erforderlich, da Ingenieure die generierten Ansichten vor der Verwendung überprüfen. Sie ist erforderlich, wenn die Werkzeugausgabe ohne unabhängige Überprüfung verwendet wird – insbesondere für Code-Generatoren und Testskript-Generatoren, die als DO-178C-Werkzeugkredit beansprucht werden.

Werkzeug	Primäre Stärke	DoDAF-Unterstützung	Lizenzmodell	Beste Eignung
Cameo Systems Modeler	SysML-Konformität, DoDAF/UPDM, Kollaboration	Ausgereift (UPDM-Plugin)	Kommerziell (hohe Kosten)	US-DoD-Beschaffungsprogramme, Hauptauftragnehmer
IBM Rhapsody	Modell-zu-Code-Generierung, eingebettete Systeme	Moderat	Kommerziell (hohe Kosten)	Eingebettete Avionik, softwareintensive Systeme
Capella (Eclipse)	ARCADIA-Methode, keine Lizenzkosten	Via Add-on	Open Source (kostenlos)	Europäische Verteidigung, budgetbeschränkte Programme

Einführungsherausforderungen und Erkenntnisse

Die MBSE-Einführung in Verteidigungsprogrammen scheitert häufiger an organisatorischen Faktoren als an technischen. Die Werkzeuge sind ausgereift, die Methoden sind gut dokumentiert, und der ROI-Nachweis ist erheblich. Was MBSE-Programme zum Scheitern bringt, sind organisatorischer Widerstand, Modell-Governance-Versagen und die Unfähigkeit, ROI so zu messen und zu demonstrieren, dass das Management-Engagement durch die anfängliche Overhead-Periode aufrechterhalten wird.

Organisatorischer Widerstand gegen Modellierung tritt in zwei Formen auf. Die erste ist kompetenzbasiert: Systems Engineers, die in der Word-und-Visio-Dokumentenproduktion geschult wurden, werden nicht automatisch zu kompetenten MBSE-Modellierern nach einem zweitägigen SysML-Kurs. Sie kennen die Notation, aber nicht die Methode – sie wissen nicht, wie man ein System in die richtigen Blöcke zerlegt, wie man entscheidet, was in ein Verhaltensmodell gehört versus was in eine Textanforderung gehört, oder wie man die Modellkonsistenz aufrechterhalten kann, wenn das Design sich entwickelt. Angemessenes MBSE-Training umfasst 40–80 Stunden pro Ingenieur für anfängliche Kompetenz, zuzüglich 6–12 Monate Mentoring beim ersten Programm. Programme, die diese Investition überspringen und erwarten, dass sich Ingenieure aus der Werkzeugdokumentation selbst unterrichten, produzieren konsequent Modelle, die strukturell korrekt, aber methodisch falsch sind – Diagramme im Modellierungswerkzeug ohne Rückverfolgbarkeitsbeziehungen, die daher keinen der Änderungsauswirkungsanalysewerte liefern, der die Werkzeuginvestition rechtfertigt.

Die zweite Form des Widerstands ist kulturell: Erfahrene Ingenieure, die erfolgreiche Programme mit dokumentenzentrierten Methoden geliefert haben, nehmen MBSE als von der Geschäftsführung auferlegten Overhead wahr statt als Fähigkeit, die das Engineering einfacher macht. Diese Wahrnehmung ist kurzfristig nicht völlig falsch – die ersten 6 Monate MBSE in einem neuen Programm sind tatsächlich mehr Overhead als das dokumentenzentrierte Äquivalent, da die Modellinfrastruktur (Governance, Werkzeuge, Repositories, Templates) aufgebaut werden muss, während die Ingenieurarbeit fortschreitet. Der ROI wird beim ersten großen ECP-Zyklus positiv, typischerweise 12–18 Monate in ein Programm, wenn die Änderungsauswirkungsanalyse am Modell Stunden statt Wochen dauert. Programme, die MBSE aufgeben, bevor dieser Wendepunkt erreicht wird, tragen die Kosten, ohne den Nutzen zu erhalten.

Modell-Governance-Versagen ist die häufigste technische Ursache für das Scheitern von MBSE-Programmen. Ohne definierte Modelleigentümerschaft, Namenskonventionen für Modellelemente, einen an Programmmeilensteinen ausgerichteten Baseline-Zeitplan und einen CCB-Prozess für kontrollierte Modellelemente häuft das Modell lokale Variationen an. Ingenieure erstellen eigene Pakete, um Koordinationsaufwand zu vermeiden. Das „maßgebliche" Modell divergiert von der Engineering-Realität, die tatsächlich entworfen wird. Innerhalb von 18 Monaten ist das Programm effektiv wieder dokumentenzentriert – Ingenieure pflegen das echte Design in separaten Dokumenten und aktualisieren das Modell vor Programmüberprüfungen, um vertragliche Anforderungen zu erfüllen.

Effektive Modell-Governance erfordert die explizite Definition: wer jedes Modellpaket besitzt (namentlich, nicht nur nach Rolle), welche Genehmigung erforderlich ist, um ein Baseline-Element zu ändern, wie der Modell-Baseline-Zeitplan mit PDR/CDR übereinstimmt und welche Modellabdeckungsmetriken bei jeder Programmüberprüfung berichtet werden. Diese Richtlinien müssen im SEMP dokumentiert und von der Programmführung durchgesetzt werden – der leitende Systems Engineer muss eine nicht genehmigte Änderung an einem Baseline-Modellelement mit der gleichen Schwere behandeln wie eine nicht genehmigte Änderung an einer CDR-Baseline-Zeichnung.

MBSE-ROI-Messung ist eine anhaltende Herausforderung, da die Vorteile größtenteils die vermiedenen Kosten von Problemen sind, die nicht auftreten. Die Schnittstellenfehler, die das typkonsistente IBD des Modells verhindert hat, wurden nie entdeckt – ihre Abwesenheit ist unsichtbar. Die Anforderungs-Orphans, die Modellkonsistenzprüfungen vor CDR entdeckt haben, wurden nie zu CDR-Abweichungen – daher gibt es keine Posten in den Programmmetriken, die die Kosten zeigen, die sie verursacht hätten. Programme, die MBSE-ROI erfolgreich demonstrieren, tun dies, indem sie Baselines vor der MBSE-Implementierung festlegen und danach spezifische Metriken messen: ECP-Änderungsauswirkungsanalyse-Stunden pro ECP, Schnittstellenfehler, die während des Integrationstests pro Schnittstelle entdeckt wurden, DoDAF-Produktionsstunden pro großer Überprüfung und CDR-Eingangsabweichungen pro Anforderungsanzahl. Ohne Pre-MBSE-Baselines für diese Metriken stützt sich das ROI-Argument auf Branchen-Benchmarks statt auf programmspezifische Nachweise – und dieses Argument ist für Programmmanager, deren Budgetdruck unmittelbar und konkret ist, weniger überzeugend.

Die Programme, die konsequent positiven MBSE-ROI erzielen, teilen drei Merkmale: Sie starten MBSE bei Programmbeginn statt es auf ein bestehendes dokumentenzentriertes Programm nachzurüsten; sie investieren in Modell-Governance-Infrastruktur, bevor die Modellierung beginnt, statt Governance-Lücken beim PDR zu entdecken; und sie messen und berichten Modellabdeckungsmetriken (Anforderungszuordnungsabdeckung, Schnittstellenformalisierungsrate, Testverknüpfungsrate) bei jeder Programmüberprüfung, wodurch die Engineering-Vollständigkeit des Modells so sichtbar gemacht wird wie Zeitplan und Budget.

MBSE ist kein Softwarewerkzeug – es ist eine Ingenieursdisziplin, die zufällig durch Softwarewerkzeuge ermöglicht wird. Verteidigungsprogramme, die diesen Unterschied verstehen, in den erforderlichen organisatorischen Wandel investieren und während des gesamten Programm-Lebenszyklus Governance-Disziplin aufrechterhalten, stellen konsequent fest, dass der Digital Thread von Stakeholder-Bedarf bis zur verifizierten Systemleistung die Investition wert ist.