Table of Contents

DODAF verstehen: Die Grundlage für OV- und SV-Diagramme

Das Department of Defense Architecture Framework (DODAF) bietet eine strukturierte Methodik für die Gestaltung, Bewertung und Kommunikation komplexer Systeme in den Bereichen Verteidigung und Luft- und Raumfahrt. Um sicherzustellen, dass Architekturbeschreibungen konsistent, wiederverwendbar und auf die Bedürfnisse der Stakeholder abgestimmt sind, ist DODAF in sechs Gesichtspunkte unterteilt: All Viewpoint (AV), Capability Viewpoint (CV), Operational Viewpoint (OV), Project Viewpoint (PV), Systems Viewpoint (SV) und Standards Viewpoint (StdV).

Die Operational View (OV) beschreibt die für die Erfüllung von Missionen notwendigen operativen Konzepte, Tätigkeiten, Aufgaben und Informationsflüsse. Sie konzentriert sich auf das, was von wem und mit welchen Informationen zu tun ist. Die Systems View (SV) dokumentiert wiederum die physikalischen und logischen Systeme, ihre Schnittstellen und den Austausch, der die operativen Tätigkeiten unterstützt. Eine entscheidende Erkenntnis für Architekten ist, dass die SV direkt auf die OV zurückverfolgen muss; jede Systemfunktion sollte vorhanden sein, um mindestens eine operative Tätigkeit zu erfüllen. Diese Rückverfolgbarkeit wird durch Matrizen wie die Operational Activity to Systems Function Traceability Matrix (SV‐5) formalisiert.

Die korrekte Entwicklung von OV- und SV-Diagrammen ermöglicht es den Stakeholdern, Abhängigkeiten zu verstehen, Lücken in der Kapazität zu erkennen, Alternativen zu bewerten und Akquisitionsentscheidungen zu treffen. Die folgenden Abschnitte bieten einen tiefen Einblick in die Produkte in jeder Ansicht und eine praktische, schrittweise Methodik für deren Erstellung.

Die Operational View (OV) in der Tiefe

DODAF definiert sieben Standard-OV-Produkte, die jeweils einem bestimmten Zweck dienen. Obwohl nicht jedes Projekt alle Produkte erfordert, umfasst eine ausgereifte Architektur typischerweise mindestens OV‐1, OV‐2, OV‐5 und OV‐6.

OV‐1: Hochrangige Betriebskonzeptgrafik

Die OV‐1 ist eine bildliche Darstellung des operativen Konzepts. Sie zeigt die wichtigsten operativen Knoten (z.B. Hauptquartier, Sensorplattformen, Kommandozentralen), ihre geografische oder logische Anordnung und den Informationsaustausch auf hoher Ebene. Primäre Stakeholder – leitende Entscheidungsträger und nichttechnische Sponsoren – nutzen OV‐1, um schnell den Umfang der Mission und die Rollen der teilnehmenden Einheiten zu erfassen. Eine gut konstruierte OV‐1 erzählt die operative Geschichte mit klaren Icons, Labels und einer Kontexterzählung, ohne dass ein tiefes technisches Wissen erforderlich ist.

OV‐2: Beschreibung des operativen Ressourcenflusses

OV‐2 fügt detaillierte Informationsflüsse zwischen operativen Knoten hinzu, identifiziert die spezifischen Ressourcen (Informationen, Material, Personal), die über Schnittstellen fließen. Für jeden Fluss dokumentiert der Architekt die Erzeuger- und Verbraucherknoten, die Häufigkeit und die Art der Ressource (z. B. Sensordaten, Logistikaufträge, Situationsbewusstseinsberichte). Dieses Produkt wird zur Grundlage für spätere SV‐1 und SV‐2-Diagramme, so dass Systemschnittstellen genau die erforderlichen betrieblichen Austausche durchführen.

OV‐3: Operationelle Ressourcenflussmatrix

OV‐3 ist eine tabellarische Darstellung der in OV‐2 enthaltenen Informationen. Sie listet jeden Ressourcenfluss zeilenweise auf, gibt Quelle, Ziel, Datenformat, Qualitätsattribute und Sicherheitsklassifizierung an. Diese Matrix unterstützt detaillierte Analysen wie Data‐Flow-Balancing, Durchsatzberechnungen und Audits der Sicherheitsklassifizierung.

OV‐4: Organi-sche Beziehungs-Tabelle

OV-4 zeigt die Kommandostruktur, Beziehungen und Autoritätslinien zwischen den operativen Knoten. Es gibt die Antwort: Wer ist verantwortlich, wer berichtet wem und welche Koordinationsmechanismen gibt es? Das Diagramm kann hierarchisch (organisatorische Aufgliederung) oder dynamischer (Verbindungsbeziehungen, aufgabenorganisierte Teams) sein.

OV‐5a und OV‐5b: Operationelle Tätigkeitsmodelle

OV‐5a (Operational Activity Decomposition Tree) gliedert die Mission auf oberster Ebene in Aktivitäten auf unterer Ebene. OV‐5b (Operational Activity Model) zeigt die Reihenfolge, Inputs/Outputs und Performer jeder Aktivität. Gemeinsam beschreiben sie das funktionale Verhalten der Operation. Bei der Entwicklung von OV‐5 wird eine standardmäßige aktionsorientierte Sprache (Non‐verb-Paare) verwendet und sichergestellt, dass jede Aktivität mit mindestens einer Systemfunktion später im SV verknüpft werden kann.

OV‐6a, OV‐6b, OV‐6c: Betriebsregeln, Zustandsübergänge und Ereignis-Spurenmodelle

OV‐6 Produkte erfassen Verhaltensbeschränkungen und Dynamik. OV‐6a dokumentiert Geschäftsregeln und Betriebsbeschränkungen (z.B. „Wenn sich Flugzeuge innerhalb von 10 Seemeilen nähern, Warnung ausgeben). OV‐6b (State Transition Description) modelliert die möglichen Zustände von Betriebsknoten und erlaubten Übergängen. OV‐6c (Event‐Trace Description) verwendet Sequenzdiagramme, um den zeitlich geordneten Austausch zwischen Knoten darzustellen. Diese Modelle sind für die Validierung der Betriebslogik und für die Spezifizierung des Systemverhaltens in der Serie SV‐10 unerlässlich.

Die Systemansicht (SV) in der Tiefe

Die Systemsicht umfasst mindestens zehn Produkte von SV‐1 bis SV‐10c. Die SV muss nachweisen, wie Systeme die im OV definierten operativen Tätigkeiten und Ressourcenflüsse realisieren.

SV‐1: Beschreibung des Systeminterfaces

SV‐1 ist das strukturelle Rückgrat der Systemarchitektur. Sie stellt Systeme (Hardware, Software, Datenbanken) als Knoten ab und zeigt die logischen und physikalischen Schnittstellen zwischen ihnen. Jede Schnittstelle ist mit den Ressourcen gekennzeichnet, die über sie fließen, was den in OV‐2 dokumentierten Ressourcenflüssen entsprechen sollte. Architekten identifizieren mit SV‐1 fehlende Schnittstellen, Single Points of Failure und unnötige Redundanz.

SV‐2: Beschreibung des Systemressourcenflusses

SV‐2 fügt jeder in SV‐1 gezeigten Schnittstelle zusätzliche Details hinzu. Sie spezifiziert Protokollstacks, Datenverbindungstypen, Bandbreite und Dienstqualitätsattribute. Beispielsweise könnte eine Schnittstelle zwischen einem Bodenleitsystem und einem UAV als "Link 16, 1 Mbps, verschlüsselt, mit maximaler Latenz von 200 ms" beschrieben werden. Dieses Produkt fließt direkt in die Handelsstudien des Systems Engineering und Interoperabilitätsbewertungen ein.

SV‐3: System‐Systemmatrix

SV‐3 ist eine Matrix, die zeigt, welche Systempaare Schnittstellen haben und gegebenenfalls deren Art (z.B. Zwei-Wege-, Ein-Wege-, Funkfrequenz-, drahtgebundene) und hilft Architekten, Schnittstellenlücken oder übermäßige Kopplung schnell zu erkennen.

SV‐4: Beschreibung der Systemfunktionalität

SV‐4 zerlegt jedes System in seine Funktionen. Im Gegensatz zu OV‐5, das sich auf operative Tätigkeiten konzentrierte, konzentriert sich SV‐4 auf das, was das System leistet: z. B. „Rechenfeuerleitlösung, „Manöversensor, „Link halten. Funktionen in SV‐4 sollten über SV‐5 auf Tätigkeiten in OV‐5 rückführbar sein.

SV‐5: Operationelle Aktivität zur Systemfunktions-Rückverfolgbarkeitsmatrix

SV‐5 ist eines der wichtigsten Produkte für Konsistenz. Es bildet jede operative Aktivität in OV‐5a einer oder mehreren Systemfunktionen in SV‐4 zu. Ein komplettes SV‐5 stellt sicher, dass jeder operative Bedarf durch eine gewisse Systemfähigkeit gedeckt wird. Lücken deuten darauf hin, dass eine erforderliche Funktion im Systemdesign fehlt. Redundante Abbildungen können auf Konsolidierungsmöglichkeiten hindeuten.

SV‐6: Systemressourcenflussmatrix

SV‐6 ist das systemorientierte Gegenstück zu OV‐3. Es listet alle Ressourcenflüsse zwischen Systemen auf, die jeweils an die in SV‐1 definierten Schnittstellen gebunden sind. Konsistenz wahren: Jeder automatisierte Fluss in OV‐3 sollte einen entsprechenden Fluss in SV‐6 haben.

SV‐7: Systemmaßematrix

SV‐7 dokumentiert Leistungsparameter wie Durchsatz, Zuverlässigkeit, Latenz, Verarbeitungsgeschwindigkeit und Kapazität, die mit Systemfunktionen verknüpft sind und quantitative Kompromisse ermöglichen. So kann eine Radarfunktion ein Maß für "Erkennungsbereich: 500 km mit 90% Wahrscheinlichkeit" aufweisen. Eine zentrale Analysemaßnahme ist die Ausrichtung auf die von Stakeholdern definierten Leistungsziele.

SV‐10a, SV‐10b, SV‐10c: Systemregeln, Zustandsübergänge und Ereignis-Spurenmodelle

Diese Produkte spiegeln OV‐6, aber auf Systemebene wider. SV‐10a definiert Geschäftsregeln oder -beschränkungen auf Systemebene. SV‐10b modelliert die Zustandsmaschinen für jedes System oder jede Funktion. SV‐10c illustriert anhand von Sequenzdiagrammen den zeitlich geordneten Nachrichtenaustausch zwischen Systemschnittstellen. Zusammengenommen bestätigen sie, dass das kollektive Systemverhalten der in OV‐6 beschriebenen Betriebsdynamik entspricht.

Eine schrittweise Methodik zur Entwicklung von OV- und SV-Diagrammen

Die folgende Methode verbindet die Top-Down-Zerlegung mit der von Stakeholdern gesteuerten Verfeinerung und soll konsistente, validierte Diagramme erstellen, die sowohl die Analyse als auch die Kommunikation unterstützen.

Schritt 1: Definieren Sie den Zweck und den Umfang

Bevor Sie ein Diagramm zeichnen, beantworten Sie drei Fragen: Was ist die Mission oder das Problem, das die Architektur anspricht? Was ist der vorgesehene Nutzen der Architektur (z. B. Akquisitionsunterstützung, Lückenanalyse, Interoperabilitätsbewertung)? Was sind die Grenzen - organisatorisch, geografisch, zeitlich? Definieren Sie diese in der Architekturbeschreibung (AV‐1). Dies verhindert das Einschleichen des Umfangs und stellt sicher, dass spätere Diagramme fokussiert bleiben.

Schritt 2: Identifiziere Stakeholder und ihre Anliegen

Zu den Stakeholdern gehören operative Kommandeure, Systemingenieure, Programmmanager und Akquisitionsbeamte. Jeder hat spezifische Bedenken: Kommandanten müssen betriebliche Flexibilität sehen; Ingenieure benötigen detaillierte Schnittstellendefinitionen; Manager wollen Risiko- und Kostenauswirkungen. Dokumentieren Sie diese Bedenken und ordnen Sie sie den OV- und SV-Produkten zu, die sie ansprechen. Diese Zuordnung wird zur Grundlage für Ihre Diagrammauswahl.

Schritt 3: Aufbau des High-Level Operational Concept (OV‐1)

Erstellen Sie die OV‐1-Grafik mit einem einfachen Zeichenwerkzeug oder einer modellbasierten Umgebung. Platzieren Sie die primären operativen Knoten (z. B. Joint Task Force, Surface Ship, Unmanned Aerial Vehicle, Satellite) und zeigen Sie den Informationsaustausch auf hoher Ebene. Fügen Sie eine Textbeschreibung hinzu, die das Betriebsszenario erfasst. Überprüfen Sie die Darstellung mit den operativen Stakeholdern, um die Erzählung zu validieren. Die OV‐1 wird oft mehrmals überarbeitet, da spätere Schritte fehlende Elemente aufdecken.

Schritt 4: Modellbetriebliche Tätigkeiten und Ressourcenflüsse (OV‐2, OV‐5a/b)

Unter Verwendung des OV‐1 als Skeletts jeden operativen Knoten in seine Aktivitäten unter Verwendung einer funktionalen Zerlegung (OV‐5a) zerlegen. Für jede Aktivität Inputs und Outputs bestimmen. Dann die Ressourcenflüsse zwischen Knoten in OV‐2 hinzufügen. Wenn beispielsweise die Aktivität „Response Response“ in einem Knoten einen „Response Plan“ erzeugt, muss dieser Plan zu einem anderen Knoten fließen. Die Eigenschaften jedes Flusses (Frequenz, Datenvolumen, Sicherheit) dokumentieren. Diese Flüsse mit Fachexperten validieren.

Schritt 5: Organisationsbeziehungen definieren (OV‐4)

Fügen Sie die Berechtigungs- und Berichtszeilen zwischen den Knoten hinzu. Dies kann einfach (Hierarchie) oder komplex (Koalitionspartner mit gemeinsamem Befehl) sein. OV-4 hilft zu identifizieren, welche Knoten berechtigt sind, welche Ressourcen anzufordern oder zu empfangen - Informationen, die für die Zugriffskontrollregeln in SV-10a oft entscheidend sind.

Schritt 6: Verhaltensmodelle etablieren (OV‐6)

Für kritische Operations-Threads Zustandsdiagramme (OV‐6b) und Ablaufdiagramme (OV‐6c) erstellen, beispielsweise kann ein Zustand "nicht bereit" nach Erhalt einer Autorisierungsnachricht in "bereit" übergehen. Das Ablaufdiagramm kann die genauen Nachrichten zwischen Knoten im Laufe der Zeit, einschließlich Bedingungen und Ausnahmen, anzeigen. Diese Modelle sind die formale Spezifikation von Operationen und werden direkt zur Steuerung des Systemdesigns verwendet.

Schritt 7: Systemschnittstellenbeschreibungen entwickeln (SV‐1)

Wechseln Sie nun zur Systemdomäne. Identifizieren Sie die Systeme, die die operativen Knoten implementieren. Für jeden operativen Knoten listen Sie die Systeme oder Systemkomponenten auf (z. B. C2-Software-Suite, Radio, Server). Zeichnen Sie die Systeme als Knoten in SV‐1 und verbinden Sie sie mit Schnittstellen, die den operativen Ressourcenflüssen in OV‐2 entsprechen. Beschriften Sie jede Schnittstelle mit ihren Implementierungssystemen und den Ressourcen, die sie trägt. In diesem Schritt können Sie feststellen, dass ein einziger operativer Fluss über mehrere Systemschnittstellen aufgeteilt werden muss (z. B. Sprache und Daten, die über separate Links gesendet werden).

Schritt 8: Detail Systemfunktionalität und Rückverfolgbarkeit (SV‐4, SV‐5)

Zerlegen Sie jedes System in seine Funktionen (SV-4). Das System "Ground Control Station" kann beispielsweise Funktionen wie "Receive Telemetry", "Update Track Database" und "Transmit Commands" enthalten. Anschließend erstellen Sie die SV-5-Matrix, indem Sie jede SV-4-Funktion mit einer oder mehreren OV-5-Aktivitäten verknüpfen. Hier werden Rückverfolgbarkeitslücken deutlich. Wenn eine erforderliche Betriebstätigkeit keine unterstützende Systemfunktion hat, müssen Sie entweder eine Funktion hinzufügen oder argumentieren, dass die Aktivität manuell ist. Führen Sie diese Überprüfung mit beiden durch Operationen und Engineering-Stakeholder.

Schritt 9: Modellsystemressourcenflüsse und -dynamiken (SV‐2, SV‐10)

Jede Schnittstelle in SV‐1 mit detaillierten technischen Attributen in SV‐2 verfeinern (Protokoll, Sicherheit, Performance) und dann Zustands- und Sequenzmodelle (SV‐10b/c) auf Systemebene entwickeln, die das Betriebsverhalten aus OV‐6 widerspiegeln. So soll nun das gleiche Sequenzdiagramm aus OV‐6c auf Systemebene erweitert werden, das Nachrichtennamen, Datenformate und Timing-Anforderungen zeigt. Die SV‐10a-Regeln können Systemeinschränkungen wie „Empfang ungültiger Daten darf keinen Systemausfall verursachen dokumentieren.

Schritt 10: Validieren, Verfeinern und Verwalten der Konfiguration

Durchführen von Review-Sitzungen mit den ursprünglichen Stakeholdern und zusätzlichen Fachexperten. Gehen Sie durch die OV- und SV-Produkte, beginnend mit OV-1, und bestätigen Sie, dass jedes OV-Element im SV angesprochen wird und dass die SV-Lösung machbar und standardkonform ist. Verwenden Sie dieses Feedback, um Diagramme zu aktualisieren und dann die Architektur zu basieren. Einmal basisch implementiert Versionskontrolle mit einem modellbasierten Konfigurationssystem. Alle Änderungen an den Betriebsanforderungen müssen sich auf die SV-Produkte übertragen; Verwenden Sie SV-5 als primären Rückverfolgbarkeitsanker.

Best Practices und häufige Fallstricke

Best Practices

  • Verwenden Sie ein modellbasiertes Tool. Tools wie Cameo Systems Modeler, MagicDraw oder Sparx Enterprise Architect mit UPDM/UAF-Profilen erzwingen Konsistenz, ermöglichen die automatisierte Berichtsgenerierung (einschließlich Matrizen) und erleichtern die Rückverfolgbarkeit über OV- und SV-Produkte hinweg.
  • Aufrechterhaltung einer Standardnotation. Das Unified Profile for DoDAF/MODAF (UPDM) oder das Unified Architecture Framework (UAF) bietet Standard-Stereotypen und Diagrammtypen.
  • Beginnen Sie mit dem operativen Bedarf. Selbst erfahrene Systemingenieure sollten sich weigern, direkt zu SV-Diagrammen ohne solide OV-Grundlage zu springen. OV‐5 und OV‐2 sind die wertvollsten Ausgangspunkte.
  • Halten Sie Diagramme nützlich, nicht vollständig. Es ist besser, einen gut organisierten Satz von fünf OV-Produkten zu haben, die überprüft und genau sind, als alle 30 Standardprodukte mit minimaler Qualität zu generieren.
  • Dokumentannahmen und Entscheidungen. Jedes Diagramm sollte von einer Erzählung begleitet werden, die erklärt, warum ein bestimmter Fluss existiert, warum eine Funktion einem bestimmten System zugewiesen wird und welche Annahmen über die Betriebsumgebung getroffen wurden.

Häufige Fallstricke

  • Das Ignorieren der Queransichtskonsistenz. Das häufigste Problem in DODAF-Architekturen sind verwaiste Funktionen oder Flüsse. Eine Systemfunktion in SV‐4, die keine übergeordnete Betriebsaktivität in OV‐5 hat, ist eine Verschwendung, während eine Betriebsaktivität ohne verfolgte Funktion auf ein unvollständiges Systemdesign hinweist. Verwenden Sie automatisierte Validierungsregeln in Ihrem Modellierungstool, um diese Probleme zu erkennen.
  • Overcomplicating OV‐1. Einige Teams versuchen, zu viele Details in die hochkarätige Konzeptgrafik zu packen, so dass sie unlesbar wird. OV‐1 auf einer Seite halten; OV‐2 und OV‐5 für Details verwenden.
  • Vernachlässigung von Performance-Maßnahmen (SV‐7). Viele Projekte definieren Schnittstellen und Funktionen, fügen aber niemals Maßnahmen an. Ohne SV‐7 ist es unmöglich zu beurteilen, ob das System den betrieblichen Anforderungen entspricht.
  • Diagramme isoliert erstellen. Wenn das OV-Team und das SV-Team nicht regelmäßig synchronisieren, driftet das SV von der operativen Realität ab. Gemeinsame Überprüfungen bei jedem Schritt sind unerlässlich.
  • Mit der falschen Granularität. Eine zu grobe Zerlegung verfehlt wichtige Details; eine zu feine Zerlegung macht die Architektur unhandlich. Eine gute Faustregel: Jede Aktivität oder Funktion sollte ein einziges, zusammenhängendes Verhalten darstellen, das einem einzelnen funktionierenden Knoten oder System zugewiesen werden kann.

Tools und Techniken für die DODAF-Diagrammentwicklung

Während es möglich ist, DODAF-Diagramme mit generischen Zeichenwerkzeugen (z. B. Microsoft Visio) zu erstellen, werden aufgrund der Komplexität der Rückverfolgbarkeit und Querverweise modellbasierte Werkzeuge dringend empfohlen.

  • Dassault Systèmes Cameo Systems Modeler (früher MagicDraw) – weit verbreitet in Verteidigungsprogrammen, unterstützt UPDM/UAF, bietet automatisierte Matrix-Generierung (SV‐3, SV‐5, OV‐3) und kann webbasierte Architekturberichte generieren.
  • Sparx Systems Enterprise Architect – bietet ein ausgereiftes UAF-Add-In, unterstützt profilbasierte Modellierung und hat einen niedrigeren Kostenpunkt, der für kleinere Teams geeignet ist.
  • IBM Engineering Rhapsody – stark im System Engineering mit SysML-Unterstützung und kann für DODAF-Sichtpunkte konfiguriert werden.

Bei der Auswahl eines Tools seine Fähigkeit zur Erzwingung der Rückverfolgbarkeit bewerten, SV‐5 Matrizen generieren, Versionskontrolle handhaben und in Standardformate exportieren (z. B. HTML, XMI, PDF). Unabhängig vom Tool ist die Schlüsseltechnik, das Meta‐Modell frühzeitig zu definieren: Welche Arten von Knoten, Flüssen und Funktionen werden verwendet; welche Beziehungen (Zuweisung, Trace, Schnittstelle) sind zulässig; und welche Attribute werden erfasst. Dieser Vorlaufaufwand reduziert die Nacharbeit erheblich.

Für Teams, die neu bei DODAF sind, sollten Sie mit einem Pilotprojekt beginnen, bei dem nur OV‐1, OV‐2, OV‐5, SV‐1 und SV‐5 verwendet werden. Beherrschen Sie diese, bevor Sie verhaltensbezogene und dynamische Modelle hinzufügen.

Schlussfolgerung

Die Entwicklung von DODAF-OV- und SV-Diagrammen ist ein systematischer Prozess, der operative Anforderungen mit dem technischen Systemdesign verbindet. Durch die Einhaltung einer strukturierten Methodik - von der Definition des Umfangs und dem Aufbau von Betriebsmodellen bis hin zur Rückverfolgung von Systemfunktionen und der Validierung mit Stakeholdern - erstellen Architekten Diagramme, die genau, umfassend und umsetzbar sind. Der Aufwand für die Erstellung qualitativ hochwertiger OV- und SV-Produkte zahlt sich während der Systemakquisition, Integration und des Lebenszyklusmanagements aus. Entscheidungsträger erhalten ein klares Verständnis dafür, wie Systeme die Mission unterstützen, und Ingenieure haben eine genaue Spezifikation, um die Entwicklung zu steuern. Für Verteidigungsorganisationen und Systemintegratoren ist die Beherrschung der OV- und SV-Entwicklung eine wesentliche Kompetenz, um erfolgreiche, interoperable Fähigkeiten zu liefern.

Für weitere Informationen siehe die offizielle Website DoD Architecture Framework, die Unified Architecture Framework (UAF) Spezifikation und die SEI-Leitlinien zur DODAF-Architekturentwicklung.