So sitzen verschiedene Akteure in einem Meeting und jeder meint etwas anderes, wenn der Begriff \u00bbMOSA\u00ab f\u00e4llt. Manche denken an Beschaffungsstrategie, andere direkt an Softwarearchitektur, und wiederum Dritte halten es f\u00fcr ein Synonym zu SOSA. W\u00e4hrenddessen warten irgendwo im Hintergrund noch FACE, NGVA, SDD und ein Dutzend weitere Abk\u00fcrzungen auf ihre Einordnung.<\/p>\n
Dieses Durcheinander ist kein Zeichen von Unwissenheit, sondern das Symptom einer Branche, die mit wachsender Systemkomplexit\u00e4t und einem \u00dcberangebot an Initiativen k\u00e4mpft, die alle dasselbe Oberziel verfolgen: Modularit\u00e4t und Interoperabilit\u00e4t. Genau diese inhaltliche N\u00e4he macht die Abgrenzung so schwierig. Durch die beiden Eigenschaften sollen die zuvor genannten Herausforderungen gel\u00f6st werden (Kostensenkung bei der Beschaffung, kontinuierliche F\u00e4higkeitsgewinne, Sicherstellung von Wettbewerbsf\u00e4higkeit).<\/p>\n
Zum Beispiel kommen in Diskussionen typische S\u00e4tze vor:<\/p>\n
- \n
- \u00bbWir wollen doch SDD umsetzen, wozu brauchen wir MOSA?\u00ab<\/em><\/li>\n
- \u00bbFACE ist doch IMA und IMA ist SDD.\u00ab<\/em><\/li>\n
- \u00bbSOSA regelt alles Technische\u00ab<\/em><\/li>\n
- \u00bbNGVA ist doch MOSA\u00ab<\/em><\/li>\n
- \u00bbWir modellieren nach NAF, da ist doch alles geregelt\u00ab<\/em><\/li>\n<\/ul>\n
Mit diesen S\u00e4tzen liegen die handelnden Personen nicht ganz falsch \u2013 aber eben auch nicht ganz richtig. Denn Schnittmengen der Standards werden dadurch so vermischt, dass Ambiguit\u00e4t entsteht und in kritischen Beschaffungs- oder Entwicklungsprozessen jeder von etwas anderem redet, ohne dass es jemandem auff\u00e4llt. Das Resultat von l\u00fcckenhaftem \u00bbVokabular\u00ab zeigt sich dann erst in sp\u00e4teren Entwicklungsprozessen und f\u00fchrt zu Verz\u00f6gerungen und Kostenexplosionen. Eine Aufl\u00f6sung, wie man die S\u00e4tze einordnet, folgt ebenfalls in diesem Artikel.<\/p>\n
Einordnungsmodell: Zwei Achsen f\u00fcr Klarheit<\/h2>\n
Die folgende Abbildung 1<\/strong> zeigt einen Ansatz zur Einordnung der verschiedenen bekannten Rahmenwerke, Standards und Referenzarchitekturen<\/strong>, wie MOSA<\/a>, SOSA<\/a>, NGVA<\/a>, VICTORY<\/a>, SDD<\/a>, NAF4.0<\/a> etc. Abbildung 2<\/strong> stellt den Versuch dar, die verschiedenen Begrifflichkeiten einzuordnen, um Klarheit zu schaffen. Hierf\u00fcr gelten im Grunde zwei Bereiche zur Einordnung: das Abstraktionslevel und die Dimension.<\/p>\n
\n\t\t\t\n\t\t\t\t![\"Diagramm](\"https:\/\/www.iese.fraunhofer.de\/blog\/wp-content\/uploads\/2026\/04\/mosa-sosa-layer-dimensionen-698x579.png\")
<\/a>\n\t\t\t<\/div>\n\t\t\t\t\n\t\t\t\tAbbildung 1: Einordnungsmodell: Rahmenwerke, Standards und Referenzarchitekturen auf vier Abstraktionsebenen (Organisation bis Realisierung) und nach Dimensionen (Luft, Land, \u00fcbergreifend).\n\t\t\t\t<\/figcaption><\/figure>\n\t\t<\/div>\n\n <\/p>\n
Dimensionen (Luft, Land, See, Weltraum)<\/h3>\n
Die Dimension<\/strong> ordnet ein, ob der Ansatz oder Standard explizit f\u00fcr Luft, Land, See oder Weltraum konzipiert wurde oder ob es ein allgemeing\u00fcltiger, also dimensions\u00fcbergreifender Standard ist. W\u00e4hrend der Recherche ist aufgefallen, dass die maritime Dimension und der Weltraum deutlich unterrepr\u00e4sentiert sind. Nach unserem aktuellen Kenntnisstand existiert in der maritimen Dimension zwar NMEA 2000\/IEC 61162<\/em> (Digital interfaces for navigational equipment within a ship)<\/em>, jedoch ist keine milit\u00e4rische Verbindung bekannt.<\/p>\n
Abstraktionsebenen<\/h3>\n
Das Abstraktionslevel<\/strong> hingegen ordnet ein, ob sich ein Rahmenwerk oder Standard eher auf betriebswirtschaftliche und organisatorische Aspekte bezieht oder auf die technische (Detail-)Ebene:<\/p>\n
- \n
- Organisation und Amtsseite<\/strong>\n
- \n
- Die Amtsseite und die organisatorische Ebene stellen den Teil dar, der am entferntesten von den technischen Details ist, gewisserma\u00dfen die \u00bboberste Ebene\u00ab.<\/li>\n
- Dennoch werden in dieser Ebene strategische Vorhaben (Beschaffungsprozesse MOSA, PYRAMID oder einheitliche Vorgehensweisen MBSE, NAF4.0), sowie operative Enabler (SDD) und taktische Konzepte (MDO) festgelegt.<\/li>\n<\/ul>\n<\/li>\n
- Plattform<\/strong>\n
- \n
- Innerhalb der Ebene der Plattform werden schon konkrete Systeme umrissen, aber auf einem Level, welches z. B. ein gesamtes Flugzeug (Luftplattform) oder ein gesamtes Transportfahrzeug (Landplattform) darstellt.<\/li>\n
- So wird etwa die komplette Sensorik eines Systems adressiert (SOSA) oder aber auch die elektronischen F\u00e4higkeiten und Entwicklungsherangehensweisen einer gesamten Luftplattform (FACE, IMA).<\/li>\n<\/ul>\n<\/li>\n
- (Teil-)System<\/strong>\n
- \n
- Detaillierter wird es nun bei der Ebene der Teil- oder Subsysteme der Plattformebene, da es hier um einen klar eingegrenzten Bereich geht.<\/li>\n
- So regeln Standards und Rahmenwerke die Interoperabilit\u00e4t von Waffensystemen (WOSA) innerhalb einer Plattform oder definieren die Komponente der Netzwerktechnik (VICTORY) von Plattformen<\/li>\n<\/ul>\n<\/li>\n
- Realisierung und Umsetzung<\/strong>\n
- \n
- Der h\u00f6chste Detailgrad ist auf der Umsetzungsebene zu finden, da hier konkrete technische, etablierte und standardisierte Protokolle festgelegt sind.<\/li>\n
- Hier geht es tats\u00e4chlich um \u00bbBits und Bytes\u00ab und es werden Schnittstellen spezifiziert (ARINC 654, NGVA) bis zu physischen Steckverbindungen und deren Nutzung (VITA65, IEEE 802.3)<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
Unterscheidung: Rahmenwerk, Standard und Referenzarchitektur<\/h3>\n
F\u00fcr das weitere Verst\u00e4ndnis des Beitrags ist eine kurze Definition bzw. Unterscheidung von h\u00e4ufig verwendeten Begrifflichkeiten sinnvoll:<\/p>\n
- \n
- Rahmenwerk<\/strong>: Ein flexibler Leitfaden oder eine Struktur, die Prinzipien und Methoden vorgibt, aber Anpassungen erlaubt. Beispiele: Scrum, ITIL.<\/li>\n
- Standard<\/strong>: Eine festgelegte, verbindliche Norm mit klar definierten Anforderungen, oft von offiziellen Organisationen (z. B. ISO, DIN) ver\u00f6ffentlicht.<\/li>\n
- Referenzarchitektur<\/strong>: Ein allgemeines, vorgefertigtes Architekturmodell als Vorlage\/Basis f\u00fcr konkrete Umsetzungen.<\/li>\n<\/ul>\n
Beispielhafte Anwendung der Begrifflichkeiten<\/h2>\n
Es folgen zwei beispielhafte Darstellungen (Abb. 2 und Abb. 3), die zeigen, wie die oben genannten Begrifflichkeiten konkret an einer Luft- und Landplattform Anwendung finden.<\/p>\n
Modulare Entwicklungsans\u00e4tze in der Dimension Luft<\/h3>\n
In folgender Abbildung wird beispielhaft gezeigt, wie HOST, FACE, SOSA und WOSA im Entwicklungsprozess einer Drohne Verwendung finden k\u00f6nnten. Hierbei w\u00fcrde die Aufkl\u00e4rungssensorik mithilfe von SOSA modular und interoperabel an die gesamte Luftplattform angebunden werden. Die F\u00e4higkeiten der Luftplattform w\u00fcrden konform und mithilfe von FACE spezifiziert werden, wodurch eine nahtlose Integration weiterer Komponenten erfolgen kann. So k\u00f6nnen dann Computing-Module, die dem HOST-Hardwaredesign folgen, problemlos miteinander verbunden oder ausgetauscht werden. Dazu erg\u00e4nzen die einheitlichen Schnittstellen von Waffensystemen (WOSA) die modulare Logik der gesamten Luftplattform.<\/p>\n
![\"Schematische](\"https:\/\/www.iese.fraunhofer.de\/blog\/wp-content\/uploads\/2026\/04\/sosa-face-flugzeug-beispiel-698x474.png\")
Abbildung 2: Beispielhafte Zuordnung von SOSA, FACE, HOST und WOSA an einer Drohne: Jeder Standard adressiert eine andere Ebene der modularen Luftplattform.<\/figcaption><\/figure>\n Modulare Entwicklungsans\u00e4tze in der Dimension Land<\/h3>\n
Die Abbildung zeigt in Form eines Beispiels, wie in einer Landplattform das Zusammenspiel von NGVA, MORA, SOSA, CMOSS, VICTORY und OpenVPX\/VITA65 erfolgen k\u00f6nnte. Angefangen mit SOSA und CMOSS w\u00fcrden im Entwicklungsprozess zun\u00e4chst die gr\u00f6\u00dferen Bestandteile der Plattform definiert werden: Sensorik und Kommunikationstechnologie. Weiterf\u00fchrend wird dann die Kommunikation innerhalb und au\u00dferhalb der Plattform verfeinert. Sprich: MORA stellt Modularit\u00e4t und Interoperabilit\u00e4t in den verwendeten Kommunikationssystemen au\u00dferhalb der Plattform bzw. auf gr\u00f6\u00dferen Distanzen sicher. Innerhalb des Fahrzeugs w\u00fcrden einheitliche Fahrzeugsignale durch NGVA geregelt werden, einheitlicher Netzwerkverkehr durch VICTORY umgesetzt und die physischen Einbauma\u00dfe durch OpenVPX sichergestellt werden.<\/p>\n
![\"Schematische](\"https:\/\/www.iese.fraunhofer.de\/blog\/wp-content\/uploads\/2026\/04\/sosa-ngva-victory-beispiel-698x423.png\")
Abbildung 3: Beispielhafte Zuordnung von SOSA, CMOSS, NGVA, VICTORY, MORA und OpenVPX\/VITA65 an einem Landfahrzeug: Von der Sensorik \u00fcber die Netzwerkkommunikation bis zu physischen Einbauma\u00dfen adressiert jeder Standard eine eigene Ebene.<\/figcaption><\/figure>\n Was meinen Akteure wirklich, wenn sie MOSA, SOSA oder FACE sagen?<\/h2>\n
Die in der Einleitung genannten S\u00e4tze werden nun aufgel\u00f6st und dieser Abschnitt soll zeigen, mit welcher Vielschichtigkeit Diskussionen gef\u00fchrt werden sollten, da Nuancen entscheidend sind f\u00fcr eine sinnvolle Diskussion.<\/p>\n
\u00bbWir wollen doch SDD umsetzen, wozu brauchen wir MOSA?\u00ab<\/em><\/h3>\n
Software Defined Defense ist zun\u00e4chst ein Paradigma, welches sich explizit auf die digitale Ebene von Systemen bezieht und hierbei auf den Entwicklungsprozess. MOSA hingegen bezieht sich auf den Beschaffungsprozess von gesamten Systemen, also Luftplattformen, Fahrzeugen etc., welche offensichtlich nicht nur aus Software bestehen. MOSA und SDD widersprechen sich keineswegs, sondern verfolgen beide auf strategischer Ebene das Ziel, Verteidigungssysteme flexibler, modularer und anpassungsf\u00e4higer zu gestalten. Hierbei forcieren beide Ans\u00e4tze Modularit\u00e4t und Anpassungsf\u00e4higkeit, allerdings aus verschiedenen Betrachtungswinkeln, n\u00e4mlich Software-Entwicklung (SDD) und Beschaffung (MOSA). Abschlie\u00dfend bereichern sich SDD und MOSA gegenseitig, da softwaredefinierte Produkte m\u00f6glichst interoperabel entwickelt sind, was exakt der Beschaffung von modularen Systemen mit offenen Standards entspricht.<\/p>\n
\u00bbFACE ist doch IMA und IMA ist SDD.\u00ab<\/em><\/h3>\n
Der Begriff IMA wird schon seit den 1990ern verwendet und ist somit weitverbreitet, im Gegensatz zu FACE oder SDD. Wie in diesem Beitrag beschrieben konzentriert sich IMA viel mehr auf die Modularit\u00e4t der Hardware, wie z. B. Bauma\u00dfe und generelle Leistungsf\u00e4higkeit der Computing Unit. Schnittstellen der darauf laufenden Software werden vielmehr im FACE-Standard adressiert. Somit findet ein flie\u00dfender \u00dcbergang von IMA (Hardware-Fokus) zu FACE (Software-Fokus) statt. FACE ist hierbei ein hervorragendes Beispiel daf\u00fcr, wie f\u00fcr das Paradigma SDD technische Richtlinien geschaffen werden k\u00f6nnen. SDD bezieht sich allerdings nicht nur auf die Dimension Luft, wie IMA und FACE. Diese verkettete Schlussfolgerung von FACE, IMA und SDD mag auf einer abstrakten Ebene sinnvoll sein, da auf dieser Ebene wieder die Ziele die gleichen sind: Modularit\u00e4t und Interoperabilit\u00e4t. Allerdings ist wichtig, genauer hinzuschauen, welche Komponenten und welche Ebenen genau betrachtet werden, um mithilfe dieser Standards Systeme zu entwickeln oder konstruktive Diskussionen zu f\u00fchren.<\/p>\n
\u00bbSOSA regelt alles Technische\u00ab<\/em><\/h3>\n
SOSA ist auf technischer Ebene konkreter angelegt als bspw. das SDD-Paradigma. Jedoch gilt es zu beachten, dass sich SOSA auf die Sensorik<\/em> fokussiert, welche nat\u00fcrlich einen gro\u00dfen Anteil an Verteidigungssystemen darstellt, aber eben nicht das umfassende System. Dazu existieren auch innerhalb von Sensorsystemen weitere Subsysteme mit entsprechenden (Sub-)Standards (wie z. B. WOSA<\/a>, IEEE802.3<\/a>), welche ber\u00fccksichtigt werden sollten. Erg\u00e4nzend dazu sei gesagt, dass SOSA den VITA65-Standard integriert und auch auf der Software-Ebene Profile f\u00fcr den FACE<\/a>-Standard anbietet. Hierbei wird deutlich, dass SOSA sehr m\u00e4chtig ist, jedoch sollte der Fehler vermieden werden, sich allein auf SOSA-Regelungen zu verlassen.<\/p>\n
\u00bbNGVA ist doch MOSA\u00ab<\/em><\/h3>\n
Im Prinzip ist diese Aussage sinnvoll, da NGVA eine sinnvolle Komponente ist. Die zu beschaffenden Landsysteme sollten m\u00f6glichst integriert sein, um Modularit\u00e4t vorweisen zu k\u00f6nnen. Allerdings ist NGVA f\u00fcr die Dimension Land und MOSA auf h\u00f6chster strategischer Ebene angesiedelt. Dieser Artikel und insbesondere Abbildung 1 <\/b>geben\u00a0deshalb eine \u00dcbersicht, um einen roten Faden zu erkennen, der sich \u00fcber diese Vorhaben und Standards erstreckt.<\/p>\n
\u00bbWir modellieren nach NAF, da ist doch alles geregelt\u00ab<\/em><\/h3>\n
NAF regelt und strukturiert lediglich die Art der System-Modellierung, gleicherma\u00dfen so wie Programmcode den Ablauf von Software bestimmt. Aber nur weil etwas codiert ist, muss dies noch langen nicht offenen Schnittstellen folgen, genauso wie die Modellierung mithilfe von NAF auch ein geschlossenes, nicht-modulares System hervorbringen k\u00f6nnte. Die Systemhersteller sind selbst daf\u00fcr verantwortlich und NAF ist hierbei nur eine Vereinheitlichung der Modellierung innerhalb des NATO-Verbunds. Dennoch lassen sich mithilfe von NAF sehr strukturiert modulare und offene Systeme entwickeln, wie im MOSA-Ansatz vorgesehen.<\/p>\n
\u00dcbersichtstabelle & Kurzdefinition der Acronyme<\/h2>\n
(\u00dcbersichtstabelle auch als Download<\/a><\/strong> im OpenDocument-Format erh\u00e4ltlich)<\/p>\n\n
- Standard<\/strong>: Eine festgelegte, verbindliche Norm mit klar definierten Anforderungen, oft von offiziellen Organisationen (z. B. ISO, DIN) ver\u00f6ffentlicht.<\/li>\n
- Rahmenwerk<\/strong>: Ein flexibler Leitfaden oder eine Struktur, die Prinzipien und Methoden vorgibt, aber Anpassungen erlaubt. Beispiele: Scrum, ITIL.<\/li>\n
- \u00bbFACE ist doch IMA und IMA ist SDD.\u00ab<\/em><\/li>\n