Abstrakte Illustration modularer Systemarchitekturen im Verteidigungssektor: Hexagonale Blöcke in Dunkelblau und Türkis, angeordnet auf horizontalen Ebenen und verbunden durch leuchtende Linien. Vier Domänen werden durch minimalistische Icons dargestellt – Flugzeug (Luft), Satellit (Weltraum), Panzerfahrzeug (Land) und Schiff (See) – mit Verbindungslinien zwischen den Domänen als Symbol für Interoperabilität.
Erstellt mit FhGenie / Z-Image

MOSA, SOSA, SDD & Co.: Der strukturierte Überblick über Akronyme und modulare Systemarchitekturen im Verteidigungssektor

Posted in Digitale Transformation, Sicherheit Published on Authors

MOSA, SOSA, FACE, SDD, NGVA: Wer im Verteidigungssektor mit modularen Systemarchitekturen zu tun hat, begegnet diesen Kürzeln ständig. Doch wo genau verlaufen die Grenzen? Dieser Artikel ordnet für alle interessierten Akteure, ob Amtsseite, Systemhersteller oder Forschung, die wichtigsten Initiativen, Standards und Rahmenwerke auf zwei Achsen ein (Abstraktionsebene und Dimension), liefert Definitionen und stellt eine Übersichtstabelle zum Download bereit.

Der Verteidigungssektor ist bekannt für seine markante Abkürzungslogik. Doch mit steigender Systemkomplexität, insbesondere durch Softwareanteile, müssen sich der Beschaffungsprozess von Verteidigungsministerien und die Entwicklungsprozesse der Systemhersteller anpassen. Hierzu entstehen einige Initiativen, wie z. B. MOSA, SOSA, FACE, SDD, NGVA etc., um der ausufernden Komplexität von Beschaffungen, hohen Kosten und mangelnder Ausbaufähigkeit über den Produktlebenszyklus entgegenzuwirken. Allerdings unterliegen die Initiativen einer Abkürzungslogik hinsichtlich Anzahl und Ähnlichkeit, die Akteure im Verteidigungssektor den Überblick verlieren lässt.

So sitzen verschiedene Akteure in einem Meeting und jeder meint etwas anderes, wenn der Begriff »MOSA« fällt. Manche denken an Beschaffungsstrategie, andere direkt an Softwarearchitektur, und wiederum Dritte halten es für ein Synonym zu SOSA. Währenddessen warten irgendwo im Hintergrund noch FACE, NGVA, SDD und ein Dutzend weitere Abkürzungen auf ihre Einordnung.

Dieses Durcheinander ist kein Zeichen von Unwissenheit, sondern das Symptom einer Branche, die mit wachsender Systemkomplexität und einem Überangebot an Initiativen kämpft, die alle dasselbe Oberziel verfolgen: Modularität und Interoperabilität. Genau diese inhaltliche Nähe macht die Abgrenzung so schwierig. Durch die beiden Eigenschaften sollen die zuvor genannten Herausforderungen gelöst werden (Kostensenkung bei der Beschaffung, kontinuierliche Fähigkeitsgewinne, Sicherstellung von Wettbewerbsfähigkeit).

Zum Beispiel kommen in Diskussionen typische Sätze vor:

  • »Wir wollen doch SDD umsetzen, wozu brauchen wir MOSA?«
  • »FACE ist doch IMA und IMA ist SDD.«
  • »SOSA regelt alles Technische«
  • »NGVA ist doch MOSA«
  • »Wir modellieren nach NAF, da ist doch alles geregelt«

Mit diesen Sätzen liegen die handelnden Personen nicht ganz falsch – aber eben auch nicht ganz richtig. Denn Schnittmengen der Standards werden dadurch so vermischt, dass Ambiguität entsteht und in kritischen Beschaffungs- oder Entwicklungsprozessen jeder von etwas anderem redet, ohne dass es jemandem auffällt. Das Resultat von lückenhaftem »Vokabular« zeigt sich dann erst in späteren Entwicklungsprozessen und führt zu Verzögerungen und Kostenexplosionen. Eine Auflösung, wie man die Sätze einordnet, folgt ebenfalls in diesem Artikel.

Einordnungsmodell: Zwei Achsen für Klarheit

Die folgende Abbildung 1 zeigt einen Ansatz zur Einordnung der verschiedenen bekannten Rahmenwerke, Standards und Referenzarchitekturen, wie MOSA, SOSA, NGVA, VICTORY, SDD, NAF4.0 etc. Abbildung 2 stellt den Versuch dar, die verschiedenen Begrifflichkeiten einzuordnen, um Klarheit zu schaffen. Hierfür gelten im Grunde zwei Bereiche zur Einordnung: das Abstraktionslevel und die Dimension.

 

Dimensionen (Luft, Land, See, Weltraum)

Die Dimension ordnet ein, ob der Ansatz oder Standard explizit für Luft, Land, See oder Weltraum konzipiert wurde oder ob es ein allgemeingültiger, also dimensionsübergreifender Standard ist. Während der Recherche ist aufgefallen, dass die maritime Dimension und der Weltraum deutlich unterrepräsentiert sind. Nach unserem aktuellen Kenntnisstand existiert in der maritimen Dimension zwar NMEA 2000/IEC 61162 (Digital interfaces for navigational equipment within a ship), jedoch ist keine militärische Verbindung bekannt.

Abstraktionsebenen

Das Abstraktionslevel hingegen ordnet ein, ob sich ein Rahmenwerk oder Standard eher auf betriebswirtschaftliche und organisatorische Aspekte bezieht oder auf die technische (Detail-)Ebene:

  • Organisation und Amtsseite
    • Die Amtsseite und die organisatorische Ebene stellen den Teil dar, der am entferntesten von den technischen Details ist, gewissermaßen die »oberste Ebene«.
    • In dieser Ebene werden Beschaffungsprozesse (MOSA, PYRAMID) geregelt, Strategien abgeleitet (SDD, MDO) und einheitliche Vorgehensweisen festgelegt (MBSE, NAF4.0).
  • Plattform
    • 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.
    • So wird etwa die komplette Sensorik eines Systems adressiert (SOSA) oder aber auch die elektronischen Fähigkeiten und Entwicklungsherangehensweisen einer gesamten Luftplattform (FACE, IMA).
  • (Teil-)System
    • Detaillierter wird es nun bei der Ebene der Teil- oder Subsysteme der Plattformebene, da es hier um einen klar eingegrenzten Bereich geht.
    • So regeln Standards und Rahmenwerke die Interoperabilität von Waffensystemen (WOSA) innerhalb einer Plattform oder definieren die Komponente der Netzwerktechnik (VICTORY) von Plattformen
  • Realisierung und Umsetzung
    • Der höchste Detailgrad ist auf der Umsetzungsebene zu finden, da hier konkrete technische, etablierte und standardisierte Protokolle festgelegt sind.
    • Hier geht es tatsächlich um »Bits und Bytes« und es werden Schnittstellen spezifiziert (ARINC 654, NGVA) bis zu physischen Steckverbindungen und deren Nutzung (VITA65, IEEE 802.3)

Unterscheidung: Rahmenwerk, Standard und Referenzarchitektur

Für das weitere Verständnis des Beitrags ist eine kurze Definition bzw. Unterscheidung von häufig verwendeten Begrifflichkeiten sinnvoll:

  • Rahmenwerk: Ein flexibler Leitfaden oder eine Struktur, die Prinzipien und Methoden vorgibt, aber Anpassungen erlaubt. Beispiele: Scrum, ITIL.
  • Standard: Eine festgelegte, verbindliche Norm mit klar definierten Anforderungen, oft von offiziellen Organisationen (z. B. ISO, DIN) veröffentlicht.
  • Referenzarchitektur: Ein allgemeines, vorgefertigtes Architekturmodell als Vorlage/Basis für konkrete Umsetzungen.

Beispielhafte Anwendung der Begrifflichkeiten

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.

Modulare Entwicklungsansätze in der Dimension Luft

In folgender Abbildung wird beispielhaft gezeigt, wie HOST, FACE, SOSA und WOSA im Entwicklungsprozess einer Drohne Verwendung finden könnten. Hierbei würde die Aufklärungssensorik mithilfe von SOSA modular und interoperabel an die gesamte Luftplattform angebunden werden. Die Fähigkeiten der Luftplattform würden konform und mithilfe von FACE spezifiziert werden, wodurch eine nahtlose Integration weiterer Komponenten erfolgen kann. So können dann Computing-Module, die dem HOST-Hardwaredesign folgen, problemlos miteinander verbunden oder ausgetauscht werden. Dazu ergänzen die einheitlichen Schnittstellen von Waffensystemen (WOSA) die modulare Logik der gesamten Luftplattform.

Schematische Darstellung einer Drohne mit farblich hervorgehobenen Bereichen, die den Standards SOSA (Aufklärungssensorik), FACE (Softwarefähigkeiten der Plattform), HOST (Hardware-/Computing-Module) und WOSA (Waffensystemschnittstellen) zugeordnet sind.
Abbildung 2: Beispielhafte Zuordnung von SOSA, FACE, HOST und WOSA an einer Drohne: Jeder Standard adressiert eine andere Ebene der modularen Luftplattform.

Modulare Entwicklungsansätze in der Dimension Land

Die Abbildung zeigt in Form eines Beispiels, wie in einer Landplattform das Zusammenspiel von NGVA, MORA, SOSA, CMOSS, VICTORY und OpenVPX/VITA65 erfolgen könnte. Angefangen mit SOSA und CMOSS würden im Entwicklungsprozess zunächst die größeren Bestandteile der Plattform definiert werden: Sensorik und Kommunikationstechnologie. Weiterführend wird dann die Kommunikation innerhalb und außerhalb der Plattform verfeinert. Sprich: MORA stellt Modularität und Interoperabilität in den verwendeten Kommunikationssystemen außerhalb der Plattform bzw. auf größeren Distanzen sicher. Innerhalb des Fahrzeugs würden einheitliche Fahrzeugsignale durch NGVA geregelt werden, einheitlicher Netzwerkverkehr durch VICTORY umgesetzt und die physischen Einbaumaße durch OpenVPX sichergestellt werden.

Schematische Darstellung eines militärischen Landfahrzeugs markierten Bereichen, die den Standards SOSA und CMOSS (Sensorik und Kommunikationstechnologie), MORA (externe Kommunikationssysteme), NGVA (Fahrzeugsignale), VICTORY (interner Netzwerkverkehr) und OpenVPX/VITA65 (physische Einbaumaße) zugeordnet sind.
Abbildung 3: Beispielhafte Zuordnung von SOSA, CMOSS, NGVA, VICTORY, MORA und OpenVPX/VITA65 an einem Landfahrzeug: Von der Sensorik über die Netzwerkkommunikation bis zu physischen Einbaumaßen adressiert jeder Standard eine eigene Ebene.

Was meinen Akteure wirklich, wenn sie MOSA, SOSA oder FACE sagen?

Die in der Einleitung genannten Sätze werden nun aufgelöst und dieser Abschnitt soll zeigen, mit welcher Vielschichtigkeit Diskussionen geführt werden sollten, da Nuancen entscheidend sind für eine sinnvolle Diskussion.

»Wir wollen doch SDD umsetzen, wozu brauchen wir MOSA?«

Software Defined Defense ist zunächst 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ähiger zu gestalten. Hierbei forcieren beide Ansätze Modularität und Anpassungsfähigkeit, allerdings aus verschiedenen Betrachtungswinkeln, nämlich Software-Entwicklung (SDD) und Beschaffung (MOSA). Abschließend bereichern sich SDD und MOSA gegenseitig, da softwaredefinierte Produkte möglichst interoperabel entwickelt sind, was exakt der Beschaffung von modularen Systemen mit offenen Standards entspricht.

»FACE ist doch IMA und IMA ist SDD.«

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ät der Hardware, wie z. B. Baumaße und generelle Leistungsfähigkeit der Computing Unit. Schnittstellen der darauf laufenden Software werden vielmehr im FACE-Standard adressiert. Somit findet ein fließender Übergang von IMA (Hardware-Fokus) zu FACE (Software-Fokus) statt. FACE ist hierbei ein hervorragendes Beispiel dafür, wie für das Paradigma SDD technische Richtlinien geschaffen werden können. 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ät und Interoperabilität. 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ühren.

»SOSA regelt alles Technische«

SOSA ist auf technischer Ebene konkreter angelegt als bspw. das SDD-Paradigma. Jedoch gilt es zu beachten, dass sich SOSA auf die Sensorik fokussiert, welche natürlich einen großen 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, IEEE802.3), welche berücksichtigt werden sollten. Ergänzend dazu sei gesagt, dass SOSA den VITA65-Standard integriert und auch auf der Software-Ebene Profile für den FACE-Standard anbietet. Hierbei wird deutlich, dass SOSA sehr mächtig ist, jedoch sollte der Fehler vermieden werden, sich allein auf SOSA-Regelungen zu verlassen.

»NGVA ist doch MOSA«

Im Prinzip ist diese Aussage sinnvoll, da NGVA eine sinnvolle Komponente ist. Die zu beschaffenden Landsysteme sollten möglichst integriert sein, um Modularität vorweisen zu können. Allerdings ist NGVA für die Dimension Land und MOSA auf höchster strategischer Ebene angesiedelt. Dieser Artikel und insbesondere Abbildung 1 geben deshalb eine Übersicht, um einen roten Faden zu erkennen, der sich über diese Vorhaben und Standards erstreckt.

»Wir modellieren nach NAF, da ist doch alles geregelt«

NAF regelt und strukturiert lediglich die Art der System-Modellierung, gleichermaßen 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önnte. Die Systemhersteller sind selbst dafür 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.

Übersichtstabelle & Kurzdefinition der Acronyme

(Übersichtstabelle auch als Download im OpenDocument-Format erhältlich)

Begriff
MOSAModular Open Systems Approach des US-Verteidigungsministeriums, stellt Beschaffungs- und Entwicklungsstrategie zur Förderungen der Verwendung von offenen Standards im militärischen Kontext dar.
SOSASensor Open System Architecture ist ein technischer Standard, der gemeinsame Schnittstellen für Sensorik (Hardware+Software) spezifiziert
PYRAMIDBeschaffungs- und Entwicklungsstrategie zur Förderungen der Verwendung von offenen Standards in der militärischen Avonik des UK-Verteidigungsministeriums.
SDDSoftware Defined Defense ist ein Paradigma, um Hardware und Software zu entkoppeln, um Softwarebasierte Fähigkeitsgewinnung zu erzeugen.
MDOMulti-Domain Operations steht für ein koordiniertes Vorgehen über verschiedene militärische Dimensonen (Luft, Weltraum, See, Land, Cyberraum) hinweg.
IMAIntegrated Modular Avionics, Konzept um in Flugzeugen wenige hochmodulare Computer (anstelle von vielen Spezialcomputer) zu verwenden, um Gewicht, Kosten und Komplexität einzusparen.
FACEFuture Airborne Capabilty Environment stellt eine Referenzarchitektur für Luftplattformen, insb. Avioniksysteme dar, um ein Common Operating Enviroment in der militärischen Luftfahrt zu erreichen. FACE ist Teil der CMOSS-Sammlung.
CMOSSC5/ISR/EW Modular Open Suite of Standards ist eine Sammlung von Standards der US Army, mit denen eine SOSA-Referenzarchitektur erreicht werden kann.
C2, ISR, C4/ISR, C5/ISTARBegriffe, um die Fähigkeiten von militärischen Führungs- und Aufklärsystemen einzuordnen. Hierber steht C2 für Command & Control, C4 erweiterert dies und ISR steht für Aufklärungsmethoden (Intelligence, Surveillance, Reconnaissance).
HOSTHardware Open Systems Technologies von der US Navy bezieht sich auf das Hardwaredesign von Embedded Computing in der Avionik und spezifiziert auf dieser Ebene um offene Schnittstellen. HOST ist Teil der CMOSS-Sammlung.
REDHAWKSoftware bzw. Entwicklerwerkzeug für die Signalaufklärung (SIGINT) und ist Teil der CMOSS-Sammlung.
VICTORYVehicular Integration for C4ISR/EW Interoperability ist ein Standard, mit Fokus auf modularität in der Netzwerkebene (z.B. Ethernet) für Landfahrzeuge. VICTORY gehört zur CMOSS-Sammlung.
MORAModular Open Radio Frequence (RF) Architecture erweitert VICTORY um den Aspekt von modularer Hochfrequenzkommunikation. MORA ist Teil der CMOSS-Sammlung.
NGVANATO Generic Vehicle Architecture, ist ein Standard für modulare, interoperable Landfahrzeuge und regelt Hardware- und Software-Schnittstellen, auch bekannt unter STANAG 4754.
WOSAWeapon Open Systems Architecture ist ein Standard für modulare Waffensysteme, der quasi als Untermenge von SOSA und FACE gilt, aufgrund des speziellen Fokus.
STANAGKurzfor für NATO Standardization Agreement
STANG4626NATO Standard für offene Architekturen in der Avionik, auch bekannt unter EN4660 und stützt die Ansätze IMA und FACE. Dieser STANAG weißt Ähnlichkeit zu ARINC 654 und wurde vom UK-Militär und europ. Unternehmen getrieben.
ARINC 653Avionics Application Software Standard, der Partitionierung + Virtualisierung von Software, insb. Betriebssystemen, in Avonik-Computern regelt, sowie Programmierschnittstellen (APIs) spezifiziert. ARINC 653 ist für IMA hochrelevant und in FACE wird darauf auch verwiesen.
DO 178CSoftware Considerations in Airborne Systems and Equipment Certification, relevante Norm zur Zertifizierung von Software in der Avionik und so wird Flugsoftware auf Konformität im Entwicklungsprozess geprüft.
MIL-STD-1553US-Militär-Standard aus den 1970er den serielle Datenbus und findet bis heute noch eine große Verbreitung
OpenVPX / VITA 65OpenVPX ist ein Konzept wie Slot-Cards (Platinen) in Backplane-Systeme miteinander verbunden werden können und VITA 65 regelt die technsiche Umsetzung dessen. Beides ist Teil der CMOSS-Sammlung
SpaceWire / ECSS-E-ST-50Standard für einen Seriellen Datenbus für Raumfahrzeuge, welcher von NASA, ESA, JAXA koordiniert wird – bis heute noch in breiter Verwendung
USAF AFMC GuidelineLeitfaden des Air Force Materiel Command, der die MOSA Prinzipien konkret auf die eigene Organisation und Prozesse überträgt.
MBSEModellbasiertes Systems Engineering ist ein Ansatz bei dem Systeme mithilfe von Modellen statt tradionellen Dokumenten entwickelt werden.
TOGAFThe Open Group Architecture Framework ist ein Rahmenwerk für Unternehmensarchitekturen, also wie Geschäftsprozesse oder die IT-Infrastruktur innerhalb von Unternehmen abgebildet werden kann.
NAF 4.0Das NATO Archiecture Framework gibt in einer Rasterdarstellung an, wie Systemarchitekturen innerhalb der NATO modellbasiert abgebildet werden sollen.
ADMBwArchitekturdokumentenmethode Bundeswehr und stellt eine Umsetzung des NAF für die deutsche Bundeswehr dar
IEEE 802.3. / EthernetStandard für die Netzwerktechnologie Ethernet, die immer mehr an Beliebtheit in sicherheitskritischen und militärischen Systemen gewinnt.
JCADie Identifizierung von Joint Capability Areas wurde Mitte der 2000er vom US-Militär initiiert, um einen gemeinsamen Rahmen für militärische Fähigkeiten über alle Teilstreitkräfte hinweg zu erhalten.

 

Klarheit als Grundlage für erfolgreiche Beschaffung und Entwicklung

Die Vielfalt der Initiativen wie MOSA, SOSA, FACE, SDD, NGVA und viele weitere ist kein Widerspruch, sondern ein Zeichen dafür, wie vielschichtig modulare und interoperable Systemarchitekturen in der Praxis sind. Jeder Standard, jedes Rahmenwerk adressiert eine spezifische Ebene: von der politischen Beschaffungsstrategie bis zur physischen Pinbelegung eines Steckverbinders.

Die zentrale Erkenntnis dieses Artikels lässt sich in einem Satz zusammenfassen.Wer MOSA sagt, meint noch lange nicht dasselbe wie jemand, der SOSA oder FACE sagt, auch wenn alle drei dasselbe Ziel verfolgen. Fehlende konzeptionelle Klarheit in frühen Phasen eines Beschaffungs- oder Entwicklungsprozesses manifestiert sich unweigerlich als Kostenexplosion oder Verzögerung in späteren Phasen.

Das Fraunhofer IESE unterstützt Amtsseiten, Systemhersteller und Forschungseinrichtungen dabei, diese konzeptionelle Klarheit herzustellen. Das Spektrum reicht von der Architekturmodellierung nach MBSE und NAF über die Bewertung offener Systemarchitekturen bis hin zur konkreten Entwicklungsbegleitung.

Sprechen Sie uns an, wenn Sie Orientierung in diesem Themenfeld suchen.

Die Übersichtstabelle aller hier vorgestellten Begriffe steht als Download zur Verfügung, sei es zur eigenen Nutzung, als Grundlage für interne Workshops oder als Einstieg in weiterführende Diskussionen. Haben wir eine Initiative oder einen Standard übersehen? Schreiben Sie uns – dieser Artikel wird kontinuierlich aktualisiert.

Detaildefinitionen von A-Z

Im folgenden Abschnitt werden die Acronyme und Begrifflichkeiten ausführlicher dargestellt. Zusätzlich sind weiterführende Links hinterlegt zur tiefgehenden Recherche.

  1. MOSA
  2. SOSA
  3. PYRAMID
  4. SDD
  5. MDO
  6. IMA
  7. FACE
  8. CMOSS
  9. C2ISR
  10. HOST
  11. REDHAWK
  12. VICTORY
  13. MORA
  14. NGVA
  15. WOSA
  16. STANAG
  17. STANAG 4626
  18. ARINC 653
  19. DO 178C
  20. MIL STD 1553
  21. OpenVPX
  22. SpaceWire
  23. USAF AFMC
  24. MBSE
  25. TOGAF
  26. NAF 4.0
  27. ADMBw
  28. IEEE802.3
  29. JCA

MOSA

MOSA steht für Modular Open Systems Approach und stellt einen Ansatz dar, der technologische und betriebswirtschaftliche Strategie kombiniert. Mit dem »MOSA-Ansatz« sollen Anreize für wettbewerbsfähige und kostenoptimierte Beschaffung, sowie Instandhaltung, über den gesamten Systemlebenszyklus geschaffen werden. Hierbei handelt es sich um Systeme wie Luft-, Land-, und Wasserfahrzeuge, sowie Fähigkeitsträger im Cyber- und Weltraum. Unter Verwendung dieser Beschaffungs- und Konstruktionsstrategie forciert das US-Verteidigungsministerium Systemarchitekturen, die aus offenen Standards und modularen Komponenten bestehen, bei gleichbleibender Konsistenz.
MOSA wurde 2013 erstmals öffentlich vorgestellt. Bereits im Jahr 2019 beschloss der US-Kongress, dass alle großen Beschaffungsprogramme im Verteidigungsbereich unter Verwendung des »MOSA-Ansatzes« entworfen und entwickelt werden müssen (US Law Title 10 U.S.C. 4401b), um eine inkrementelle Entwicklung zu ermöglichen, und Wettbewerb, Innovation und Interoperabilität zu fördern.

MOSA basiert auf fünf Prinzipien:

  1. Establish Enabling Environment
  2. Employ Modular Design
  3. Designate Key Interfaces
  4. Use Open Standards
  5. Certify Conformance

Hinweis: In diesem Abschnitt wurde bewusst die Dopplung »MOSA-Ansatz« gewählt, um zu verdeutlichen, dass dies explizit ein Ansatz ist und keine konkrete Architektur oder Standard. Das »A« in MOSA steht bereits für Approach = Ansatz, weshalb im Nachfolgenden auf die Dopplung korrekterweise verzichtet wird. Außerdem ist es ein großer Trugschluss, dass sich MOSA lediglich auf die Softwarekomponenten bezieht, was zu kurz gegriffen ist, da MOSA im gleichen Maße für mechanische und mechatronische Systeme gilt.

Relevante Links:

SOSA

SOSA bedeutet Sensor Open Systems Architecture und stellt einen technischen Standard dar, der die MOSA-Prinzipien realisieren möchte. Wie der Name schon erahnen lässt, fokussiert sich SOSA auf Spezifikationen für Sensorik (Software- und Hardwareelemente) sowie für elektrische und mechanische Schnittstellen. SOSA setzt in diesem Bereich auf bereits etablierte Standards, erweitert diese bei Bedarf für den militärischen Einsatz und definiert hieraus einzelne Architekturmodule, die als Referenz dienen. In den Publikationen der »SOSA Technical Standard Reference Architecture« findet man beispielhafte Architekturmodule und eine Taxonomie zur Vorhabenseinordnung nach SOSA-Logik. Das SOSA-Konsortium ist in der Organisation »Open Group« beheimatet. Die Open Group Organisation fördert herstellerneutrale Standards im IT-Bereich seit Mitte der 1990er und agiert weltweit. Die Open Group ist zwar äußerst von der Industrie geprägt, dennoch finden sich einige staatliche und wissenschaftliche Akteure in ihr wieder. So wird SOSA stark vom US Air Force Life Cycle Management Center (AFLCMC) getrieben. Auch wenn MOSA und SOSA ähnlich klingen, sowohl in der abgekürzten wie in der ausgeschriebenen Form, so unterscheiden diese sich deutlich. MOSA stellt einen strategischen Ansatz dar und SOSA befindet sich näher an der technologischen Ebene.

Relevante Links:

PYRAMID

PYRAMID wurde 2014 vom UK-Verteidigungsministerium (MOD) als Initiative gestartet, um kosteneffiziente und schnell anpassbare Missionssysteme in der Luftfahrt zu entwickeln. Hierbei wurde bei PYRAMID erkannt, dass offene Systemarchitekturen ein Schlüsselelement sind. Es ist schnell zu erkennen, dass PYRAMID in der selben Zeit wie MOSA entstanden ist und dementsprechend oft als »britisches MOSA« bezeichnet wird. Dies trifft genau den Kern von MOSA, da es wie beschrieben kein »das eine wahre MOSA« gibt, sondern immer eine individuelle Übertragbarkeit der Weg zu wirkungsvollen offenen Systemarchitekturen ist. Zu PYRAMID existiert eine Referenzarchitektur PRA (PYRAMID Reference Architecture), die direkt bei der Systementwicklung dazu dient, die Konformität zu PYRAMID zu beachten. Eine Auflösung, wofür das Akronym PYRAMID steht, ist der Öffentlichkeit nicht bekannt.

Relevante Links:

SDD

SDD ist das Akronym für Software Defined Defense und überträgt das Software Defined X-Paradigma auf den Verteidigungsbereich. An zentraler Stelle bei softwaredefinierten Vorhaben steht die Entkopplung von Software und Hardware. Kurz gesagt wird eine solche Fähigkeitsgewinnung via Software-Update möglich. Hierzu müssen organisatorische Rahmenbedingungen geschaffen werden, als auch die technologische Infrastruktur, um Updatefähigkeit plattformübergreifend, schnell und sicher (Safety, Cybersecurity, Trustworthy) herzustellen. Somit vereint SDD zum einen den gesamtheitlichen Ansatz von MOSA und zum anderen fokussiert sich SDD noch klarer (im Vergleich zum Sensorfokus von SOSA) auf die Softwarekomponente. Bei SDD konvergieren die Handlungsstränge der Amtsseite und der Industrie: Während die Amtsseite Software-seitige Innovation und Modularität fordert, entwickeln Unternehmen aus Wettbewerbssicht Systeme, die via Software-Update eine technologische Vorreiterrolle einnehmen. Weiterhin ist Software Defined Defense verknüpft mit MDO (Multi Domain Operations).

Relevante Links:

MDO

Multi Domain Operation, kurz MDO, umfasst ein Konzept zur gesamtheitlichen Operationsführung in allen Dimensionen (Cyberraum, Weltall, Luft, Land, See). Dazu ist ein entscheidender Unterschied zum länger bekannten Begriff »Joint Operations«, dass MDO das Lagebild mit militärischen und nicht-militärischen Informationen synchronisiert. Außerdem sind die Begriffe »Multi Domain Operation« und »Software Defined Defense« eng miteinander verknüpft (sozusagen zwei Seiten einer Medaille). Während MDO ein Konzept zur taktischen Umsetzung darstellt, so ist SDD die operative und infrastrukturelle Komponente, um dies zu realisieren. Sind Systeme sämtlicher Domänen also mit dem Software-Defined-Paradigma entwickelt oder nachgerüstet, so sind Modularität, Updatefähigkeit und Vernetzung gegeben. Durch diese Systemeigenschaft können Informationen gebündelt werden, um dimensionsübergreifend Operationen auszuführen. Als technischer Bestandteil von MDO spricht man auch von der Multi Domain Combat Cloud. Die Combat Cloud ist eine technische Lösung, auf der alle relevanten Sensoren und Effektoren vernetzt werden. Diese Cloudlösung dient zur Kollaboration, stellt eine förderierte Cloud zur Verfügung und unterliegt den höchsten Sicherheitsanforderungen. Um MDO realisieren zu können, sind die Beschaffung nach MOSA und das Entwicklungsparadigma SDD wichtige Initiativen.

Relevante Links:

IMA

IMA bedeutet ausgeschrieben Integrated Modular Avionics. Aus der Luftfahrt kommend, steht IMA im Prinzip dafür, viele verschiedene Spezial-Computer durch einen oder nur wenige universelle Computer zu ersetzen. Hierdurch entstehen eine Komplexitätsreduzierung, eine große Modularität, sowie die Konzentration auf die eigentliche Software-Funktionalität, ohne Hardware-Randbedingungen berücksichtigen zu müssen (Hardware-Abstraktion). In anderen Worten: IMA SwaP (Space, Weight and Power) möchte Probleme lösen. Vor der Anwendung des IMA-Konzepts, noch bis in die 1990er, wurden Funktionalitäten von Luftfahrzeugen auf dedizierten Computern ausgeführt, was zu mehr Gewicht, geringer Flexibilität, Wartungsaufwand und aufwändigerer Zertifizierung führte. IMA wird auch als »Plug-and-Play« bezeichnet, da die hochperformanten Computer und Netzwerke zum einen miteinander kompatibel sind (durchgängige Nutzung) und zum anderen die Fähigkeit besitzen, jede Art an Software auszuführen (Mehrfachnutzung). IMA bezieht sich also stark auf die Ebene der Hardware/Computer, sowie Netzwerktechnik und stellt somit auf dieser Ebene einen Baustein dar, um MOSA und SDD zu ermöglichen. Standards wie ARINC 653 und STANAG 4626 zielen aktiv auf die Umsetzung von IMA ab. Diese beiden Standards werden auch in diesem Beitrag behandelt.

FACE

FACE steht für Future Airborne Capability Environment und ist – wie SOSA ein Konsortium innerhalb der Open Group. FACE liefert eine konkrete Referenzarchitektur für Systeme der Avionik. Die FACE-Referenzarchitektur unterteilt sich in fünf Segmente:

  1. Operting System Segment (OSS)
  2. Portable Components Segment (PCS)
  3. Transport Services Segment (PCS)
  4. Platform-Specific Services Segment (PSSS)
  5. I/O Services Segment (IOSS).

So besteht beispielsweise das Operating Systems Segment aus verschiedenen Profilen, die POSIX APIs und die Umsetzung von ARINC 653 kombinieren. Mit FACE soll ein »Common Operating Environment (COE)« in der militärischen Luftfahrt erreicht werden, um strukturiert Software Produktlinienmanagement betreiben zu können. Hiermit sollen Anreize in Geschäfts- und Beschaffungsprozessen geschaffen werden, die die Interoperabilität von Software mithilfe von gemeinsamen Standards fördern. So existieren beispielsweise eine FACE-Datenarchitektur und Semantik, vorgefertigte Definitionen in der IDL-Sprache inklusive Mappings relevanter Programmiersprachen aus der Luftfahrt (C, C++, ADA).

SOSA und FACE interagieren miteinander, denn das SOSA-Konsortium übernimmt insbesondere Schnittstellen der FACE-Architektur. IMA und FACE unterscheiden sich in Nuancen, die aber ausschlaggebend sind: FACE hat den Fokus mehr auf Software und Schnittstellen, anstelle von Netzwerk und Hardware. Im Bereich der Betriebssysteme überschneiden sich die Ansätze etwas, aber von Bedeutung ist, dass modulare und interoperable Ansätze auf verschiedenen Ebenen angewandt werden müssen.

Relevante Links:

CMOSS

C5ISR/EW Modular Open Suite of Standards, oder in Kurzform CMOSS, ist eine Sammlung der US Army von MOSA und SOSA-artigen Standards. CMOSS versteht sich hierbei als eine konkretere Instanziierung der SOSA-Referenzarchitektur, sodass auch die US-Army die Ziele von MOSA (Interoperabilität, Modularität …) erreichen kann. CMOSS achtet darauf, eine Übereinstimmung mit dem SOSA-Konsortium sicherzustellen. Folgende Standards umfasst CMOSS: FACE/Redhawk für das Software-Layer, OpenVPX/VITA für das Hardware-Layer, VICTORY/MORA für das Kommunikationslayer. CMOSS versucht also eine Harmonisierung, Koordinierung und einen Überblick über verschiedene Initiativen zu errichten, sodass auch die Standards selbst domänenübergreifend wiederverwendet werden können.

C2, ISR, C4/ISR, C5/ISTAR

Diese Begrifflichkeiten werden in Kombination benutzt und bauen aufeinander auf:

  • C2: Command, Control
  • C4: Command, Control, Communications, Computers
  • C5: Command, Control, Communications, Computers, Cyber-Defense
  • ISR: Intelligence, Surveillance, Reconnaissance
  • ISTAR: Intelligence, Surveillance, Target Acquisition, Reconnaissance
  • Beispiel »C5/ISR«: Command, Control, Communications, Computers, Cyber-Defense / Intelligence, Surveillance, Reconnaissance

Grundsätzlich sei gesagt, dass Command and Control (C2) organisatorische Prozesse, sowie eine Klassifikation von technischen Systemen umfasst. Wie eine deutsche Übersetzung von C2 erahnen lässt, fließen in ein C2-System Ergebnisse der Aufklärung ein, woraus Maßnahmen umgesetzt werden können. Häufig werden die o.g. Begrifflichkeiten wie C4/ISTAR verwendet, um technische Attribute von Führungssystemen zu beschreiben – also eine Klassifikation zum Grad der Vernetzung eines Systems. Insofern sind die Abkürzungen C5/ISR kein technischer Standard oder etwa ein Ansatz für offene Systeme. Sondern die Fähigkeiten der Führungssysteme können damit kategorisiert werden. Egal, ob es sich dabei um ein System nach MOSA handelt oder nicht. Ziel ist es, von derartigen Informationssystemen ein genaueres Lagebild zu erhalten, und die Entscheidungsfindung zu beschleunigen, um somit die Führungsfähigkeit zu verbessern.

Relevante Links:

HOST

HOST bedeutet im Zusammenhang dieses Beitrags Hardware Open Systems Technologies und ist eine Initiative, die vom Naval Air Systems Command der US Navy ausgeht. HOST ist ähnlich zu FACE, fokussiert sich jedoch mehr auf das Hardwaredesign und die zugehörigen Schnittstellen. HOST stellt eine Sammlung bzw. ein Rahmenwerk von offenen Standards, sowie Spezifikationen dar, die auf der Ebene des militärischen (Avionics) Embedded Computing angewandt werden. Das Ziel ist auch, Modularität, Interoperabilität und Wiederverwendbarkeit der Komponenten herzustellen. Konkret bedeutet dies, dass Computing-Module dasselbe Slotprofil aufweisen, also standardisierte (Hardware-)Schnittstellen. So stellt der VITA/OpenVPX-Standard ein Fundament in HOST dar. In der Praxis findet HOST beispielsweise im modernen F-35 Kampfjet Anwendung. HOST ist kein Teil eines industriellen Standardisierungskonsortiums wie die Open Group, sondern die US-Navy (Navair) verantwortet das Rahmenwerk selbst.

Relevante Links:

REDHAWK

REDHAWK ist ein Software-Framework, um Software Defined Radio (SDR)-Lösungen zu entwickeln, und eignet sich ebenfalls für die Signalaufklärung (SIGINT, Signal Intelligence). Somit ist REDHAWK also ein Entwicklerwerkzeug und Teil der CMOSS-Sammlung.

Relevante Links:

VICTORY

Vehicle Integration for C4ISR/EW Interoperability trägt die Abkürzung VICTORY und ist Teil der CMOSS-Sammlung. Der VICTORY-Standard zielt hauptsächlich auf Netzwerkebene (insb. Ethernet-basiert) in Bodenfahrzeugen ab. Er kann aber prinzipiell auf andere See-/Unterwasser-/Luftplattformen angewandt werden. Hierbei wurde VICTORY von der US Army entwickelt, wird aber nun an das SOSA-Konsortium transferiert, um die Bemühungen zwischen CMOSS und dem SOSA-Konsortium zu transferieren. Eine zentrale Komponente ist der VICTORY Data Bus (VDB), der nach dem Prinzip einer Middleware verschiedene Nachrichtenprotokolle vereint. Somit können verschiedene Services wie GPS, Video Display, Audio Alarm etc. auf einem Gerät dargestellt werden, anstelle von vielen (nicht interoperablen) Geräten.

Relevante Links:

MORA

Mora steht für Modular Open Radio Frequency (RF) Architecture, erweitert den VICTORY-Standard und nutzt Formate des VITA-Standards. MORA ist dabei auf Hochfrequenzkommunikation ausgerichtet und zerlegt die Hochfrequenzsignalkette (funktionale Dekomposition) in verschiedene modulare Komponenten. Hierbei liegt ein weiterer Fokus von MORA auf Signalen, die niedrige Latenzen (also nahe Echtzeitfähigkeit) als Transportmechanismus erfordern. MORA nutzt für Zugriffskontrolle den Victory Data Bus (VDB) und danach das MORA Data Message (MDM) Format, welches dem VITA49.2 Standard entspricht. Dieses Nachrichtenformat kann dann über den MORA Low Letency Bus (ML2B) fließen.

Relevante Links:

NGVA

NGVA steht für NATO Generic Vehicle Architecture, stellt den STANAG 4754 dar und wird vom Fraunhofer FKIE seit 2011 gemeinsam mit Partnern entwickelt. Der STANAG 4754 richtet sich an Landfahrzeuge und stellt einen Standard dar, der offene Architekturen fördert. Dem NATO-Standard folgend werden die elektronischen und elektrischen Schnittstellen für militärische Landfahrzeuge (und Teilsysteme) interoperabel ausgelegt. So werden z. B. Anforderungen an den Datenaustausch, die Stromversorgung sowie ein einheitliches Datenmodell (Syntax + Semantik) spezifiziert.
Somit sollen dann Landfahrzeuge mit verschiedenen (Teil‑)Systemen von unterschiedlichen Herstellern nahtlos miteinander Nachrichten austauschen können. Dadurch entsteht auch eine Modularität und die NGVA folgt somit den MOSA-Prinzipien.

Relevante Links:

WOSA

WOSA steht für Weapon Open Systems Architecture und fokussiert sich rein auf Waffensysteme wie Raketen. WOSA ist somit ein nicht proprietärer technischer Standard, der vom Air Force Research Laboratory (AFRL) entwickelt und gepflegt wird. Die Ziele von WOSA decken sich mit MOSA (offene Schnittstellen, Modularität, Reduzierung der Kosten im Lebenszyklus, Integrationsvereinfachung etc.). Der explizite Fokus auf Waffensysteme macht WOSA so besonders, da bspw. FACE sich auf die gesamte Luftfahrzeugplattform bezieht und SOSA lediglich auf die Sensorik. Besonders im Zentrum von WOSA steht der Munitions Data Bus (MDB), der als zentrales Nachrichtenprotokoll gilt und Schnittstellen zu SOSA beinhaltet.

Relevante Links:

STANAG

STANAG steht für Standardization Agreement und wird vom NATO Standardization Office herausgegeben. STANAGs sind Standardisierungsabkommen der NATO und legen innerhalb der Mitgliedstaaten gemeinsame Prozesse und technische Standards fest. Sie ermöglichen eine Basis für Interoperabilität von Ausrüstung, Abläufen, Logistik und Systemen zwischen den Streitkräften der NATO-Länder. Zwei konkrete STANAGs werden auch in diesem Artikel erklärt (STANAG 4754: NATO Generic Vehicle Architecture, STANAG 4626: Modulare und offene Avionikarchitekturen).

Relevante Links:

STANAG 4626

STANAG 4626 befasst sich mit modularen und offenen Avionikarchitekturen. Dieser STANAG wurde von dem Allied Standards Avionics Architecture Council (ASAAC) entwickelt, hinter dem hauptsächlich das UK-Verteidigungsministerium steht, sowie weitere europäische Unternehmen aus der Avionik. STANAG 4626 vereinbart auf NATO-Ebene, wie moderne Avionikarchitekturen angewandt werden sollen, z. B. regelt er die Trennung von genutzten Ressourcen der Software- und Hardware-Komponenten. Somit soll STANAG 4626 Konzepte wie IMA praktisch unterstützen und zu Richtlinien wie FACE beitragen. STANAG 4626 weist eine gewisse Ähnlichkeit zu ARINC 653 auf, hat aber den klaren militärischen Bezug. Ergänzend dazu, ist STANAG 4626 gleichzeitig auch eine europäische Norm (EN 4660).

ARINC 653

ARINC steht für Aeronautical Radio Incorporated und definiert hierbei technische Spezifikationen für Kommunikation, Schnittstellen und Interoperabilität des Flugzeugnetzwerks, sowie Kabinensysteme. ARINC-Normen werden bereits eingesetzt: von Fluggesellschaften, Flugzeugherstellern, Lieferanten der Avionik, Softwareherstellern etc. Die Standards werden kooperativ zwischen zuvor genannten Akteuren und dem SAE Industry Technologies Consortia erarbeitet, um so die Praxistauglichkeit, Interoperabilität, technische Fähigkeit und funktionale Sicherheit bestens festzulegen. Besonders bekannt ist z. B. ARINC 429, welcher in den 1980ern als Standard für den digitalen Datenbus in Verkehrsflugzeugen eingeführt wurde (serielle Schnittstelle). ARINC 653 ist im Kontext dieses Beitrags hoch relevant. Die Bezeichnung von ARINC 653 lautet »Avionics Application Software Standard« und befasst sich mit der Partitionierung und Virtualisierung von (Echtzeit-)Betriebssystemen von Avionik-Computern. Ergänzend zu IMA soll ARINC 653 sicherstellen, dass verschiedene Software-Anwendungen mit unterschiedlichen Kritikalitätsleveln auf derselben Hardware betrieben werden können – ohne ungewünschte gegenseitige Beeinflussung und mit deterministischem Verhalten. Außerdem werden in dem Standard Programmierschnittstellen (APIs) festgelegt. Spannend ist, dass ARINC 653 im hier erwähnten FACE (Future Airborne Capability Environment) auftaucht. Die Kombination von FACE und ARINC 653 erfolgt konsequenterweise auf dem »Operating Systems Segment«. Insofern ist ARINC 653 eine sehr technische und konkrete Norm, die sinnvollerweise von FACE aufgegriffen wird. Ebenfalls wird im hier dargestellten Kontext von IMA (Integrated Modular Avionics) auch ARINC 653 angewandt.

Relevante Links:

DO-178C

DO-178C ist eine Norm bzw. Richtlinie zur Zertifizierung von Software in der Avionik (Software Considerations in Airborne Systems and Equipment Certification) und wird von der RTCA (Radio Technical Commission for Aeronautics), sowie EUROCAE (European Organisation for Civil Aviation Equipment) entwickelt. Behörden wie die EASA (Europäische Agentur für Flugsicherheit) sind für die Zulassung von Software (z. B. Flugsteuerung, Navigation, Kommunikation) in Flugzeugen und weiteren Luftplattformen zuständig. Hierbei wird im Zertifizierungsprozess die Einhaltung der Vorgaben von DO-178C geprüft, wie z. B. des Software-Designprozesses, des Software-Testprozesses, des Konfigurations- und Qualitätsmanagements usw. DO-178C verfolgt für die Luftfahrt ähnliche Ziele wie die IEC 61508-Norm (internationale Norm für die funktionale Sicherheit für elektronische Systeme). DO-178C weist außerdem noch eine ergänzende Richtlinie DO-254 (Design Assurance Guidance for Airborne Electronic Hardware) auf, worin Sicherheitslevel definiert werden, d.h., ob ein Fehlerfall geringe oder katastrophale Auswirkungen auf das fliegende System hätte.

Wichtig ist im Kontext des Beitrags, dass DO-178C große Implikationen für modulare Entwicklungsvorhaben induziert, da Systeme in der Avionik eine DO-178C-Zertifizierung durchlaufen. Demnach gilt in MOSA, FACE oder ähnlichen Ansätzen eine kontinuierliche Berücksichtigung dieser Richtlinie.

MIL-STD-1553

Der MIL-STD-1553-Standard wurde in den 1970er Jahren als serieller Datenbus von der US-Luftwaffe eingeführt. Dieser Avionik-Standard sticht durch seine Einfachheit, Zuverlässigkeit und deterministische Kommunikation hervor. MIL-STD-1553 ist in Bestandssystemen (Legacy-Systeme) und auch in Organisationen wie NATO, NASA, ESA noch sehr weitverbreitet und es gilt eine entsprechende Berücksichtigung dessen bei Ansätzen wie IMA oder FACE – dennoch steht der Standard nicht im Widerspruch mit diesen Ansätzen, man muss ihn nur berücksichtigen.

Relevante Links:

OpenVPX / VITA65

OpenVPX ist ein Konzept, wie eingebettete Systeme (z. B. Prozessor-, Speicher-, Netzwerk- oder FPGA) in Form von Slot-Cards in einem Backplane-System (Chassis mit Rückwandplatine) miteinander verbunden werden können. Ziel ist eine hohe Modularität, Flexibilität und Kompatibilität zwischen verschiedenen Herstellern. VITA65 ist hierbei der eigentliche technische Standard, der OpenVPX umsetzt und wird von VMEbus International Trade Association (VITA) spezifiziert. So wird in VITA65 festgelegt welche Profile es für Module und Backplanes gibt, wie die Signalzuweisung aussieht (Pins für Ethernet, PCIe, …) und wie die physikalischen Maße der Steckverbinder aussehen. Dies führt zu einer infrastrukturellen Grundlage, sodass herstellerneutral eingebettete Systeme kombiniert oder ausgetauscht werden können. SOSA und VITA/OpenVPX enthalten teilweise Synergien und referenzieren aufeinander, enthalten aber auch Differenzen zueinander.

Relevante Links:

SpaceWire / ECSS-E-ST-50

Der SpaceWire-Standard (auch ECSS-E-ST-50 genannt) wurde als ein serieller Datenbus für Raumfahrzeuge entwickelt. Der Standard wurde inspiriert vom IEEE-1355 (von 1995). Er wird von der ESA, NASA und JAXA koordiniert und in Raumfahrtmissionen verwendet. SpaceWire konzentriert sich klar auf die Dimension Weltraum und stellt einen konkreten technischen Standard zur Kommunikation von Steuergeräten dar.

USAF AFMC-Guideline

Das Air Force Materiel Command (AFMC) ist grundsätzlich zuständig für die Entwicklung, Beschaffung, sowie Wartung der Ausrüstung und Technologie der United States Air Force (USAF). Hinsichtlich MOSA erstellte das AFMC einen Leitfaden, um die abstrakten MOSA-Prinzipien auf die eigene Organisation und Prozesse anzuwenden bzw. zu konkretisieren. Insofern stellt die AFMC-Guideline ein Musterbeispiel dafür dar, wie MOSA auf die eigene Organisationseinheit adaptiert werden kann.

Relevante Links:

MBSE

MBSE steht für modellbasiertes Systems Engineering und ist ein Ansatz, bei dem Systeme mithilfe von Modellen statt mit traditionellen Dokumenten entwickelt werden. Die Modelle dienen als zentrale Informationsquelle und erleichtern die Zusammenarbeit verschiedener Fachbereiche. MBSE unterstützt die Analyse, das Design und die Validierung komplexer Systeme durch Visualisierung und Simulation. Änderungen und Anforderungen können effizienter nachverfolgt und integriert werden. Dadurch erhöhen sich die Qualität und Nachvollziehbarkeit im Entwicklungsprozess. Mittlerweile werden insbesondere im militärischen Umfeld in den operationellen Architekturen MBSE-Ansätze verfolgt. Hierbei erkennt man, dass die MBSE-Methodik MOSA-Vorhaben unterstützt, da auf Modellebene die Modularität explizit dargestellt werden kann.

Relevante Links:

TOGAF

TOGAF ist die Abkürzung für »The Open Group Architecture Framework« und stellt einen Ansatz zum Entwurf von Unternehmensarchitekturen (Enterprise Architecture) dar. TOGAF wird z. B. wie MOSA und SOSA innerhalb der Open Group weiterentwickelt. TOGAF zielt hierbei auf die »höhere Ebene« im Gegensatz zu MBSE-Methodiken (System-Ebene, operationale Architekturen) ab. Sprich: TOGAF kümmert sich um die Bereiche der Geschäftsarchitektur (Prozesse), Informationssystemarchitektur (Daten, Anwendungen) und Technologiearchitektur (IT-Infrastruktur). TOGAF und MBSE stehen nicht im Widerspruch, sondern ergänzen sich auf verschiedenen Abstraktionsleveln.

Relevante Links

NAF v4.0

Das NATO Architecture Framework (NAF) stellt ein Rahmenwerk zur Entwicklung und Dokumentation von Architekturen für militärische Systeme und Organisationen der NATO dar. In einer Rasterdarstellung werden standardisierte (Architektur-)Sichten vorgegeben, sodass Anforderungen, Prozesse, Systeme und Technologien strukturiert abgebildet bzw. modelliert werden können. Somit entsteht ein einheitliches Verständnis von komplexen militärischen Systemen zwischen den NATO-Partnern. NAF orientiert sich an weiteren Frameworks, Sprachen und Ansätzen – nur mit speziellem Fokus auf militärische Organisationsstrukturen und Systeme. So besteht eine gewisse Überschneidung zu TOGAF. Vor allem aber wird NAF in Verbindung mit MBSE gebracht, da diese Methoden zur effizienten Umsetzung geeignet sind. Die modellbasierte Erstellung hilft, die verschiedenen NAF-Sichten konsistent zu halten, nachvollziehbar darzustellen, und ermöglicht eine gezielte Analyse z. B. von Fähigkeitslücken oder Neuentwicklungen.

Relevante Links:

ADMBw

ADMBw steht für Architekturdokumentenmethode Bundeswehr und stellt eine Umsetzung des NAF für die deutsche Bundeswehr dar. ADMBw passt also NAF an die spezifischen Anforderungen der Bundeswehr an und definiert an wenigen Stellen besondere Vorgehensweisen oder Dokumentationsarten. Prinzipiell ist aber ADMBw sinnvollerweise sehr nah an NAF dran und stellt somit die Interoperabilität dazu sicher.

Relevante Links:

IEEE 802.3 / Ethernet

Zunächst einmal steht IEEE für Institute of Electrical and Electronics Engineers und stellt einen Berufsverband der Elektro- und Informationstechnik dar. IEEE ist in der Wissenschaft bekannt durch die eigenen Fachzeitschriften von Konferenzpublikationen. Vor allem aber sind IEEE-Standards bekannt. Diese technischen Standards sind z. B. Wireless LAN, POSIX, JTAG, System Life Cycle Processes etc. Im militärischen Kontext wird häufig vom Standard IEEE 802.3 gesprochen. Die 802-Familie umfasst Netzwerkstandards für lokale Netze (LAN) und in diesem Fall steht ».3« für den Ethernet-Standard bzw. die sich damit befassende Arbeitsgruppe. Ethernet wird im Bereich der sicherheitskritischen Systeme immer mehr zum Wunsch eines Kommunikationsprotokolls, aufgrund der hohen Datenrate und Zuverlässigkeit, die sich bspw. im IT-Sektor bewährt hat. Folglich existiert in der Familie der 802er-Standards auch eine dedizierte Arbeitsgruppe, die zeitsensitive Kommunikation (TSN) in Avionik-Anwendungen spezifiziert: IEEE 802.1DP. IEEE802.3 (Ethernet) oder IEEE802.1DP sind also ein technischer Stand nahe dem physischen Layer von Systemen und bilden weitestgehend die technische Umsetzung ab.

Relevante Links:

JCA

JCA steht für Joint Capability Areas und wurde Mitte der 2000er vom US-Verteidigungsministerium initiiert, um einen gemeinsamen Rahmen von militärischen Fähigkeiten und Aktivitäten unter allen Teilstreitkräften zu erhalten. Somit sollten gemeinsame Operationen besser planbar und durchführbar sein, aufgrund eines einheitlichen Verständnisses. Beispielhafte JCAs sind Force Support, Force Application, Battlespace Awareness, Command and Control (C2) und Logistics. Prinzipiell stellt JCA die Vorgehensweise einer Verheintlichung dar, die zur Interoperabilität dient und so den Grundzügen von MOSA, FACE, SDD… ähnelt.

Relevante Links:

Tagged , ,