Testen missionskritischer C2-Systeme: Strategien für Verteidigungs-Software-QA

Das Testen eines C2-Systems unterscheidet sich grundlegend vom Testen kommerzieller Software. Bei kommerzieller Software bedeutet ein Ausfall ein verschlechtertes Benutzererlebnis oder Datenverlust. Bei einem C2-System kann ein Ausfall während einer Live-Operation bedeuten, dass Operateure die Sichtbarkeit eigener Kräfte in einem kritischen Moment verlieren, ein Feuerauftrag an die falsche Einheit übermittelt wird oder ein Verwundetenbericht wegen Überlastung des Nachrichtenbusses verzögert wird. Die Teststrategie muss diesen operativen Kontext widerspiegeln.

Verteidigungs-Software-QA für C2-Systeme — ob für Bundeswehr-Programme oder BMVg-Beschaffungsvorhaben — deckt fünf Kategorien ab: Unit- und Integrationstests einzelner Komponenten, Systemtests der integrierten Plattform, Leistungstests unter operativer Last, Resilienztest unter degradierten Bedingungen sowie Abnahmetests gegen militärische Anforderungen.

Unit- und Integrationstests für C2-Komponenten

Unit-Tests für C2-Komponenten folgen Standardpraktiken — jede Komponente isolieren, externe Abhängigkeiten mocken, Verhalten gegen Spezifikation verifizieren. Die C2-spezifische Herausforderung ist, dass viele Komponenten mit zeitkritischen externen Daten interagieren: GPS-Positionen, Funkmeldungen, Sensorfeeds. Testvorrichtungen müssen realistische Zeitreihendaten mit angemessenen Aktualisierungsraten, Zeitstempelformaten und Nachrichtenstrukturen generieren.

CoT-Nachrichten-Parser erfordern beispielsweise Testvorrichtungen, die den gesamten Bereich der Ereignistypen abdecken, fehlerhaftes XML, fehlende Pflichtattribute und veraltete Zeitstempel einschließen. Ein Parser, der fehlerhafte Nachrichten stillschweigend verwirft, ist funktional korrekt in der Isolation, aber operativ gefährlich: Eine Freund-Kraft-Position kann stillschweigend aus dem Lagebild verschwinden, ohne jeden Hinweis für den Operateur.

Integrationstests verifizieren, dass Komponenten korrekt funktionieren, wenn sie verbunden sind. Die kritischen Integrationspunkte in einem Bundeswehr-C2-System: die Datenaufnahmepipeline (Sensor → Nachrichtenbroker → Track-Speicher), der Echtzeit-Push-Pfad (Track-Speicher → WebSocket → Kartenrenderer) und der Befehlspfad (Operateur-Aktion → Befehlsdienst → externes System).

Leistungstests: Track-Durchsatz, FPS und Nachrichtenlatenz

Leistungstests für ein C2-System definieren spezifische quantitative Schwellenwerte — nicht "das System soll schnell sein", sondern "das System muss ≥30 FPS auf dem Kartenanzeige bei 2.000 gleichzeitigen Tracks aufrechterhalten, die mit 0,1 Hz aktualisiert werden, mit einer Track-Positions-Aktualisierungslatenz von ≤500ms am 95. Perzentil."

Track-Durchsatz. Die maximale Anzahl von Tracks, die das System pro Sekunde aufnehmen und verarbeiten kann, ohne dass Warteschlangen entstehen. Gemessen durch Einspritzen von CoT-Nachrichten mit zunehmenden Raten, bis die internen Warteschlangen des Systems unbegrenzt anwachsen. Für ein C2-System auf Brigadeebene muss der Track-Durchsatz 200 Aktualisierungen/Sekunde übersteigen.

Karten-Render-FPS. Frames pro Sekunde auf der Kartenanzeige bei der operativen Track-Obergrenze. Gemessen mit Browser-Leistungs-APIs mit einem synthetischen Track-Generator, der Positionsaktualisierungen über WebSocket sendet. Ziel: ≥30 FPS bei der maximalen operativen Track-Anzahl.

End-to-End-Latenz. Zeit von einer Positionsaktualisierung, die ins System eintritt, bis zur gerenderten aktualisierten Position auf dem Display des Operateurs. Ziel: ≤500ms am 95. Perzentil unter normaler Last.

Befehlsumlaufzeit. Zeit von der Befehlseinreichung durch einen Operateur bis zur Bestätigung im System. Ziel: ≤2 Sekunden am 95. Perzentil.

Chaos Engineering für degradierte Netzwerkbedingungen

C2-Systeme der Bundeswehr operieren in umkämpften elektromagnetischen Umgebungen, wo die Netzwerkkonnektivität intermittierend ist, die Bandbreite eingeschränkt ist und Paketverlust normal ist. Das Testen nur unter idealen Netzwerkbedingungen produziert Software, die in der Kaserne funktioniert, aber im Einsatz versagt.

Netzwerkpaketverlust (10–40%). Bei 30% Paketverlust überprüfen, dass: die Kartenanzeige weiterhin aktualisiert (mit erhöhter Latenz), das System nicht abstürzt oder hängt, und veraltete Tracks korrekt ablaufen, anstatt als Geistertracks zu persistieren, wenn Aktualisierungen aufhören anzukommen.

Netzwerkpartitionierung (vollständige Trennung für 30–300 Sekunden). Wenn sich eine Netzwerkpartitionierung heilt, muss das System seinen Track-Zustand mit dem aktuellen Zustand aus Upstream-Datenquellen abgleichen. Überprüfen, dass: die Wiederverbindung automatisch erfolgt, Tracks, die während der Partition offline gingen, ablaufen, und der Track-Zustand nach der Wiederverbindung dem autoritativen Upstream-Zustand innerhalb eines Aktualisierungszyklus entspricht.

Knotenausfall (Beenden einer Dienstinstanz). In einer Cluster-Bereitstellung darf das Beenden eines Anwendungsknotens keinen sichtbaren Ausfall aus der Perspektive des Operateurs verursachen. Kubernetes-Gesundheitsprüfungen und Service-Mesh-Routing müssen den Datenverkehr innerhalb von 5 Sekunden auf gesunde Knoten umleiten.

GPS-Spoofing / Positionsdatenkorruption. Einspritzen von Tracks mit unplausiblen Positionen oder Geschwindigkeiten. Die Track-Validierungsschicht muss diese erkennen und filtern, Anomalien für Sicherheitsüberprüfungen protokollieren.

Red-Team-Tests für Sicherheit

Red-Team-Tests — strukturierte gegnerische Tests, bei denen ein separates Team versucht, das System zu kompromittieren — sind für Bundeswehr-C2-Systeme vor der operativen Bereitstellung erforderlich. Das Red Team zielt auf:

Authentifizierungsumgehung. Versuche, auf API-Endpunkte ohne gültige Token, mit abgelaufenen Token oder mit Token eines nicht autorisierten Identity-Providers zuzugreifen.

Privilegien-Eskalation. Authentifizierung als niedrig-privilegierter Benutzer und Versuche, auf Ressourcen zuzugreifen, die höhere Geheimhaltungsgrade erfordern. Testen der ABAC-Richtliniendurchsetzungsschicht auf Lücken.

Daten-Exfiltrationspfade. Versuche, klassifizierte Track-Daten durch Berichts-Export-Funktionen, API-Paginierung oder Fehlermeldungen zu extrahieren, die unbeabsichtigt Daten zurückgeben.

Injektionsangriffe. SQL-Injektion durch Filter-Parameter, Befehlsinjektion durch operative Datenfelder und CoT-XML-Injektion durch fehlerhafte Ereignisnachrichten.

STANAG-Konformitätstests

C2-Systeme, die in NATO-Übungen oder multinationalen Programmen integriert sind, müssen relevante STANAGs einhalten. Die wichtigsten für taktische C2-Interoperabilität:

STANAG 5522 definiert das Nachrichtenprotokoll für den taktischen Datenlink Link 16. C2-Systeme, die Link-16-Tracks anzeigen, müssen J-Serien-Nachrichten korrekt dekodieren.

STANAG 4677 deckt NFFI (NATO Friendly Force Information) ab — den Standard für die Positionsfreigabe von NATO-Einheiten über nationale Grenzen. NFFI-Konformitätstests verifizieren, dass Positionsmeldungen korrekt formatiert sind und Track-Identifikatoren stabil bleiben. Für die Bundeswehr ist NFFI-Konformität eine Anforderung für alle Systeme, die in multinationalen Rahmenstrukturen betrieben werden.

APP-6 (NATO-Militärsymbole) Konformitätstests verifizieren, dass die Kartenanzeige Militäreinheiten-Symbole gemäß APP-6D korrekt rendert, mit korrekten Zugehörigkeitsfarben, Echelon-Bezeichnungen und Modifikatorfeldern.

Abnahmetests unter Feldbedingungen

Feld-Abnahmetests sind die abschließende Verifizierung vor der operativen Bereitstellung. Sie erfolgen in einer Umgebung, die der operativen Umgebung annähert — eine Feldübung mit echten Funknetzen, echten GPS-Empfängern und echten Operateuren, die repräsentative Aufgaben ausführen.

Der Abnahmetestplan definiert spezifische Szenarien: eine Bewegung auf Kompanie-Ebene mit 20 abgesessenen Soldaten mit ATAK, ein Feuerauftrag von der Anforderung bis zur Ausführung mit vollständiger Nachrichtenverfolgung, ein Kommunikations-degradiertes Szenario, bei dem der Bataillons-TAK-Server für 10 Minuten die Verbindung zur Brigade verliert. Jedes Szenario hat definierte Bestehens-/Versagenskriterien.