Bewertung militärischer C2-Software: 12 Kriterien für Beschaffungsentscheidungen

Die Auswahl von Führungs- und Steuerungssoftware (C2) gehört zu den folgenreichsten Beschaffungsentscheidungen, die eine Verteidigungsorganisation trifft. Die falsche Wahl — eine Plattform, die unter degradierten Kommunikationsbedingungen versagt, Ihre Sensor-Feeds nicht integrieren kann oder Sie in ein proprietäres Ökosystem einschließt — hat operative Konsequenzen, die ein Jahrzehnt andauern. Anders als bei kommerzieller Unternehmenssoftware wird der Preis einer schlechten C2-Beschaffung nicht in verschwendetem Budget gemessen, sondern in eingeschränktem Lagebewusstsein genau dann, wenn es am meisten darauf ankommt.

Dieser Artikel stellt einen strukturierten Bewertungsrahmen vor, der auf 12 Kriterien basiert, die Beschaffungsteams vor der Vertragsvergabe prüfen sollten. Für jedes Kriterium benennt der Rahmen, worauf es ankommt, welche Warnsignale einen Anbieter disqualifizieren und wie das Kriterium in einer kontrollierten Demonstration getestet werden kann. Der Rahmen ist sowohl auf maßgeschneiderte Entwicklungsprogramme als auch auf die Beschaffung kommerzieller Standardlösungen (COTS) für C2-Plattformen anwendbar.

Kriterium 1: Latenz bei der Echtzeit-Datenaufnahme

Worauf zu achten ist. Die Track-Update-Latenz — die Zeit von einem eingehenden Positionsbericht bis zur Anzeige des aktualisierten Symbols im gemeinsamen Lagebild — sollte im 95. Perzentil unter repräsentativer Last 500 ms nicht überschreiten. Für schnell bewegliche Luftkontakte oder zeitkritische Zielerfassung sind niedrigere Schwellenwerte (≤200 ms) angemessen. Die End-to-End-Latenz muss bei operativen Track-Dichten gemessen werden, nicht in einer leicht belasteten Demo-Umgebung.

Warnsignale. Anbieter, die keine Latenzmessungen unter festgelegter Last vorweisen können oder die nur durchschnittliche Latenz ohne Perzentilverteilungen angeben, sind entweder ungetestet oder verschleiern Degradierungen bei hoher Auslastung. Die durchschnittliche Latenz ist als operationale Kennzahl nahezu wertlos — ein System mit durchschnittlich 300 ms, das bei 2.000 Tracks auf 8 Sekunden ansteigt, ist operativ unzuverlässig.

Demo-Test. Verlangen Sie, dass der Anbieter einen automatisierten Lastgenerator betreibt, der Positionsupdates mit Ihrer angegebenen Track-Zählobergrenze einspielt (z. B. 3.000 gleichzeitige Tracks mit je 0,1 Hz). Messen Sie die End-to-End-Latenz anhand von Zeitstempel-Nachrichten von der Einspielung bis zur Kartenaktualisierung. Fordern Sie die p50-, p95- und p99-Latenzwerte an.

Kriterium 2: Breite der Multi-Source-Integration

Worauf zu achten ist. Operative C2-Systeme müssen Tracks aus heterogenen Quellen fusionieren: UAV-Bodenkontrollstationen (über Cursor on Target oder MAVLINK), SIGINT-Feeds, OSINT-Aggregatoren, Logistikmanagementsysteme und Legacy-Sensornetzwerke. Bewerten Sie die Breite nativer Adapter und den Aufwand für die Anbindung einer neuen Quelle. Eine Plattform mit zwanzig zertifizierten Integrationen, aber ohne offenes SDK für eigene Konnektoren, ist langfristig eine Integrationsbelastung.

Warnsignale. Integrations-Roadmaps, die Konnektoren als „geplant" oder „auf Anfrage verfügbar" ausweisen, entsprechen nicht dem gleichen Wert wie bereits ausgelieferter Code. Verlangen Sie eine Demonstration mit mindestens zwei Datenquellen, die Sie tatsächlich betreiben. Proprietäre, geschlossene Nachrichtenformate ohne veröffentlichte Schema-Dokumentation weisen auf künftige Anbieterabhängigkeit hin.

Demo-Test. Stellen Sie dem Anbieter einen Live- oder aufgezeichneten Datenfeed eines Ihrer aktuellen Sensoren in seinem nativen Format bereit. Beobachten Sie, ob die Integration nativ ist oder einen kostenpflichtigen Professional-Services-Einsatz des Anbieters erfordert.

Kriterium 3: Offline- und Degraded-Mode-Fähigkeit

Worauf zu achten ist. Feld-C2-Systeme operieren in umkämpften elektromagnetischen Umgebungen, in denen die Verbindung zu einem zentralen Server intermittierend oder vollständig unterbrochen ist. Das System muss während Netzwerkausfällen ein nutzbares Lagebild aus lokal zwischengespeicherten Daten aufrechterhalten, den Zustand automatisch synchronisieren, sobald die Verbindung wiederhergestellt ist, und ausgehende Befehle ohne Datenverlust in einer Warteschlange halten. Bewerten Sie die maximal unterstützte Offline-Dauer und die Qualität der Zustandsabstimmung nach der Wiederverbindung.

Warnsignale. Systeme, die eine dauerhafte Serververbindung benötigen, um die Karte darzustellen oder Befehle auszugeben. Jede Architektur, bei der das Bedienerdisplay ein reiner Thin-Client ohne lokalen Zustand ist, ist in einer umkämpften Umgebung operativ fragil. Klären Sie, ob der mobile oder dismountete Client eine unabhängige Track-Datenbank unterhält oder nur vom Server streamt.

Demo-Test. Trennen Sie während der Demonstration physisch den Client-Knoten vom Server. Beobachten Sie, ob das Bedienerdisplay funktionsfähig bleibt, welche Daten sich verschlechtern und ob Befehle, die während des Ausfalls in der Warteschlange standen, bei Wiederverbindung automatisch übertragen werden.

Kriterium 4: NATO-Interoperabilitätsstandards (STANAGs)

Worauf zu achten ist. Programme, die innerhalb von oder gemeinsam mit NATO operieren, müssen die einschlägigen Standardisierungsabkommen einhalten. Wichtige STANAGs für die C2-Interoperabilität umfassen STANAG 5522 (taktische Datenverbindungen), STANAG 4677 (NFFI Friendly Force Information), STANAG 4559 (NSILI-Bildlokalisierungsschnittstelle) und APP-6D (NATO-Militärsymbologie). Überprüfen Sie die Konformität mit spezifischen Ausgaben, nicht nur mit dem Standardnamen — APP-6C und APP-6D haben erhebliche Unterschiede im Symbolsatz, die die Interoperabilität bei Koalitionsübungen beeinflussen.

Warnsignale. Anbieter, die STANAG-Konformität ohne Konformitätstestbericht oder CWIX-Teilnahmeprotokoll (Coalition Warrior Interoperability eXploration, eXperimentation, eXamination, eXercise) behaupten. Selbst deklarierte Konformität ohne Drittvalidierung ist für den Einsatz in Koalitionsprogrammen unzureichend.

Demo-Test. Fordern Sie die aktuellste CWIX-Teilnahmezusammenfassung des Anbieters oder Konformitätstestergebnisse für die in Ihren Anforderungen genannten STANAGs an. Stellen Sie für die Symbol-Darstellung einen Satz von APP-6D-Testfällen bereit und überprüfen Sie die korrekte Darstellung anhand des Referenz-Symbolsatzes.

Kriterium 5: Handhabung von Dateneinstufungen

Worauf zu achten ist. C2-Systeme, die klassifizierte Informationen verarbeiten, müssen Datenkennzeichnung, Zugangskontrolle und Beschränkungen der domänenübergreifenden Datenflüsse auf Objektebene durchsetzen — nicht nur am Netzwerkperimeter. Jeder Track, jedes Dokument und jede Nachricht muss Klassifizierungsmetadaten tragen, die steuern, was jeder Benutzer sehen und exportieren kann. Bewerten Sie das Systemverhalten, wenn ein Benutzer mit niedrigerem Klassifizierungsniveau versucht, einen auf einer höheren Stufe markierten Track einzusehen oder zu exportieren.

Warnsignale. Eine nur beim Login durchgesetzte Klassifizierung (alle authentifizierten Benutzer sehen alle Daten) ist für jede Betriebsumgebung mit mehreren Klassifizierungsstufen unzureichend. Das Fehlen von Audit-Logs für Datenzugriffs-, Export- und Herabstufungsereignisse ist ein Compliance-Ausschlusskriterium für die meisten Verteidigungszertifizierungsrahmen.

Demo-Test. Erstellen Sie Testkonten mit zwei verschiedenen Klassifizierungsstufen. Überprüfen Sie, dass das Konto mit niedrigerer Klassifizierung keine Objekte oberhalb seiner Stufe einsehen, exportieren oder Benachrichtigungen dazu erhalten kann. Prüfen Sie das Audit-Log, um zu bestätigen, dass der Zugriffsversuch aufgezeichnet wurde.

Kriterium 6: Granularität der rollenbasierten Zugangskontrolle

Worauf zu achten ist. Operativer C2-Betrieb erfordert feinkörnige Zugangskontrolle über Funktionsrollen hinweg: ein Geheimdienstoffizier, der SIGINT-Tracks einsehen, aber keine Bewegungsbefehle erteilen kann; ein Verbindungsoffizier einer alliierten Nation, der gemeinsame Tracks einsehen, aber nicht auf die eigene Kräftedisposition zugreifen kann; ein Logistikkoordinator, der Nachschubüberlagerungen sieht, aber keine Zieldaten. Bewerten Sie, ob das RBAC-Modell attributbasierte Richtlinien unterstützt, die diese Einschränkungen ausdrücken können, oder ob es auf grobe Rollenzuweisungen beschränkt ist.

Für eine tiefergehende technische Behandlung von RBAC-Architekturen in Verteidigungsplattformen siehe den Artikel über rollenbasierte Zugangskontrolle in Defense-C2-Systemen.

Warnsignale. Systeme mit weniger als fünf vordefinierten Rollen und ohne Unterstützung für die Erstellung eigener Rollen. RBAC-Modelle, die den Zugriff nicht auf Datenobjektebene einschränken können (nur auf UI-Feature-Ebene), schaffen Lücken, durch die ein Benutzer über eine API oder Exportfunktion, die die UI-Einschränkung umgeht, auf sensible Daten zugreifen kann.

Demo-Test. Definieren Sie eine benutzerdefinierte Rolle — zum Beispiel einen Koalitionspartner mit Lesezugriff auf Blue-Force-Tracks in einem bestimmten geografischen Gebiet — und überprüfen Sie, ob das System diese Einschränkung ohne einen kostenpflichtigen Professional-Services-Einsatz des Anbieters ausdrücken und durchsetzen kann.

Kriterium 7: Skalierbarkeit bei hoher Track-Dichte

Worauf zu achten ist. Bewerten Sie die Leistungsmerkmale des Systems über drei Skalierungsdimensionen: Track-Dichte (gleichzeitige Objekte im C2-Dashboard), gleichzeitige Benutzer (Bediener, die gleichzeitig auf das System zugreifen) und Nachrichtendurchsatz (eingehende Datenrate von allen Quellen zusammen). Holen Sie vom Anbieter bereitgestellte Benchmark-Ergebnisse ein und replizieren Sie diese nach Möglichkeit während der Evaluierung unabhängig.

Warnsignale. Anbieter, die keine Leistungsdaten bei Track-Zahlen über 1.000 oder gleichzeitigen Benutzerzahlen über 20 bereitstellen können. Eine Architektur, die auf einem einzelnen Datenbankknoten ohne horizontalen Skalierungspfad basiert, stellt eine Kapazitätsgrenze dar, die das Programm beim Wachstum einschränkt.

Demo-Test. Verwenden Sie den Lastgenerierungstest aus Kriterium 1, erweitert um mehrere gleichzeitige Benutzersitzungen, die jeweils aktive Karteninteraktionen durchführen (Zoomen, Filtern, Abfragen). Messen Sie, ob die Pro-Benutzer-Latenz linear oder nichtlinear ansteigt, wenn die Anzahl gleichzeitiger Benutzer zunimmt.

Kriterium 8: Sicherheitszertifizierungen des Anbieters

Worauf zu achten ist. Mindestakzeptable Sicherheitszertifizierungen hängen vom Zertifizierungsrahmen ab, der Ihr Programm regelt. Häufige Referenzpunkte: ISO/IEC 27001 (Informationssicherheitsmanagement), SOC 2 Type II (relevant für cloud-gehostete Lösungen), Common Criteria EAL-Zertifizierung (für Systeme, die formale Sicherheitszusicherungen erfordern) und programmspezifische Akkreditierung (z. B. DISA STIG-Konformität, FedRAMP für US-Bundesprogramme, NCSC-Leitlinien für britische Programme).

Warnsignale. Zertifizierungen, die abgelaufen sind, im Geltungsbereich auf einen Teil des Produkts beschränkt sind oder auf einer Version basieren, die erheblich älter als die aktuelle Version ist. Ein Anbieter mit ISO 27001, das nur für seine Corporate-IT-Umgebung, nicht aber für die Lieferpipeline des C2-Produkts zertifiziert ist, bietet begrenzte Sicherheit. Fordern Sie die Geltungsbereichsbeschreibung der Zertifizierung an.

Demo-Test. Fordern Sie das eigentliche Zertifikatsdokument mit Ausstellungsdatum, Geltungsbereich und Ablaufdatum an. Fordern Sie für STIG-Konformität die STIG Viewer-Ergebnisdatei an, keine Übersichtstabelle. Kontaktieren Sie die Zertifizierungsstelle zur Überprüfung der Aktualität.

Kriterium 9: Flexibilität der Bereitstellung

Worauf zu achten ist. Bewerten Sie, ob die Plattform alle Bereitstellungsmodelle unterstützt, die Ihr Programm über seinen Lebenszyklus hinweg benötigt: kommerzielle Cloud (für Übungen und Trainingsumgebungen), On-Premises in einem gehärteten Rechenzentrum, taktischer Rand (Betrieb auf widerstandsfähiger Hardware im Feld) und vollständig air-gapped (keine externe Netzwerkverbindung). Viele Plattformen sind für ein Bereitstellungsmodell optimiert und verschlechtern sich bei anderen — eine cloud-native SaaS-Plattform bietet möglicherweise keinen praktikablen Pfad zum Air-Gapped-Betrieb.

Warnsignale. Abhängigkeit von externen Diensten (Lizenzserver, Update-Server, Telemetrie-Endpunkte), die in einer Air-Gapped-Umgebung nicht funktionieren können. Lizenzmodelle, die eine regelmäßige Cloud-Anmeldung erfordern, um aktiv zu bleiben, werden im abgekoppelten Betrieb stillschweigend versagen. Klären Sie, ob für den Offline-Betrieb eine spezielle Lizenzstufe erforderlich ist.

Demo-Test. Fordern Sie eine Demonstration der Air-Gapped-Bereitstellungsvariante an, sofern Ihr Programm diese erfordert. Viele Anbieter werden die Cloud-Version demonstrieren und die Air-Gapped-Fähigkeit behaupten — testen Sie das tatsächliche Bereitstellungsmodell, nicht die Fähigkeitszusicherung.

Kriterium 10: UI/UX unter Stressbedingungen

Worauf zu achten ist. Eine C2-Oberfläche, die ein Bediener unter Zeitdruck, mit unvollständigen Informationen und in einer lauten Umgebung verwendet, hat grundlegend andere Anforderungen an die Benutzerfreundlichkeit als Unternehmenssoftware. Bewerten Sie die Informationsdichte (sind relevante Daten ohne Menünavigation auffindbar), die Alarmmüdigkeit (unterscheidet das System kritische Alarme von Routinebenachrichtigungen) und die Aufgabenabschlusszeit bei gängigen Aktionen: eine bestimmte Einheit lokalisieren, einen Auftrag erteilen und eine Spur als feindlich markieren.

Warnsignale. Oberflächen, die mehr als zwei Klicks erfordern, um eine zeitkritische Aktion auszuführen (Änderung der Zugehörigkeit einer Spur, Versenden eines Kontaktberichts). Systeme mit undifferenzierten Alarmströmen, die Systemereignisse niedriger Priorität neben kritischen operativen Meldungen präsentieren, werden von Bedienern ignoriert und lassen kritische Ereignisse durch.

Demo-Test. Stellen Sie einen Evaluator bereit, der die Plattform noch nicht gesehen hat, und bitten Sie ihn, drei definierte Aufgaben ohne Anbieterunterstützung abzuschließen. Messen Sie Aufgabenabschlusszeit und Fehlerquote. Dieser strukturierte Usability-Test deckt Workflow-Reibungspunkte auf, die eine anbieterzentrierte Demo verbirgt.

Kriterium 11: Support- und SLA-Bedingungen

Worauf zu achten ist. Operative C2-Software erfordert Support-Bedingungen, die den operativen Verfügbarkeitsanforderungen entsprechen — nicht kommerziellen SaaS-SLAs. Bewerten Sie: Verfügbarkeitsgarantie (99,9 % Betriebszeit erlaubt immer noch 8,7 Stunden jährlicher Ausfallzeit), Reaktionszeit bei Vorfällen für kritische Defekte (Stunden, nicht Werktage), Patch-Lieferungszeitraum für Sicherheitslücken und die Fähigkeit des Anbieters, klassifizierte Deployments unter eingeschränkten Zugangsbedingungen zu unterstützen.

Warnsignale. Support-Stufen, die schnellere Reaktion nur zu erheblich höheren Kosten bieten, was Support auf operativem Niveau faktisch zu einem Premium-Add-on macht. Anbieter, die keine nachgewiesene Erfahrung mit der Unterstützung klassifizierter Deployments mit sicherheitsüberprüftem Personal vorweisen können, sind ein Risiko für Programme mit Klassifizierungsanforderungen.

Demo-Test. Fordern Sie anonymisierte Beispiele vergangener Vorfallsreaktionsnachweise für Schweregrad-1-Probleme an. Kontaktieren Sie Referenzkunden gezielt, um nach der Support-Reaktionsfähigkeit bei tatsächlichen Vorfällen zu fragen, nicht nach allgemeiner Zufriedenheit.

Kriterium 12: Gesamtbetriebskosten (TCO)

Worauf zu achten ist. C2-Software-TCO über einen Fünf-Jahres-Programmlebenszyklus umfasst: anfängliche Beschaffungs- oder Entwicklungskosten, jährliche Lizenz- oder Wartungsgebühren, Infrastrukturkosten (Cloud-Abonnements oder On-Premises-Hardware), Integrationskosten (Anbindung an vorhandene Sensor- und Logistiksysteme), Schulungskosten für Bediener und Administratoren sowie geschätzte Upgrade-Kosten. Open-Architecture-Plattformen mit veröffentlichten APIs und portablen Datenformaten haben erheblich niedrigere langfristige Integrations- und Migrationskosten als proprietäre Systeme.

Warnsignale. Preisstrukturen, die pro Sitzplatz für jeden gleichzeitigen Benutzer berechnen, was zu eskalierenden Kosten führt, wenn das Programm wächst. Proprietäre Datenformate ohne Exportfähigkeit erzeugen Wechselkosten, die das Programm bei der Vertragsverlängerung effektiv einschließen. „Basispreis"-Angebote, die obligatorische Support-Stufen, Infrastruktur oder Integrationsmodule ausschließen, unterschätzen die TCO routinemäßig um 40–60 %.

Demo-Test. Fordern Sie von jedem Anbieter ein detailliertes 5-Jahres-TCO-Modell auf Basis Ihrer angegebenen Programmparameter an (Benutzeranzahl, Track-Dichte-Obergrenze, Bereitstellungsumgebung). Verlangen Sie, dass das Modell alle Kostenkomponenten aufschlüsselt, einschließlich Infrastruktur, Support und Integration. Vergleichen Sie die Gesamtlebenszykluskosten, nicht den Anschaffungspreis.

So führen Sie eine C2-Software-Bewertung in 6 Wochen durch

Eine strukturierte 6-Wochen-Bewertung verdichtet die technische Beurteilung in einen verteidigungsfähigen, dokumentierbaren Prozess, ohne an Strenge zu verlieren.

Woche 1: Anforderungen und Raster. Übersetzen Sie operative Anforderungen in quantitative Schwellenwerte für jedes der 12 Kriterien. Weisen Sie Gewichtungen zu. Veröffentlichen Sie das Raster an das Bewertungsgremium, bevor ein Anbieterkontakt stattfindet. Passen Sie Gewichtungen nach Beginn der Demos nicht mehr an.

Wochen 1–2: RFI und Vorauswahl. Geben Sie eine strukturierte Auskunftsanfrage (RFI) heraus, die obligatorische Antworten erfordert, die Ihren 12 Kriterien zugeordnet sind. Prüfen Sie Antworten anhand eines Mindestschwellenwerts — Anbieter, die Ihre Latenz-, Zertifizierungs- oder Bereitstellungsanforderungen schriftlich nicht erfüllen können, gelangen nicht zur Demo.

Woche 2: Gestaltung der Demo-Szenarien. Schreiben Sie drei bis vier geskriptete Szenarien, die Ihre Hochrisiko-Kriterien abdecken: ein Degraded-Network-Szenario, ein High-Track-Density-Szenario, einen Klassifizierungsgrenztest und einen Multi-Source-Integrationstest. Stellen Sie Szenario-Skripte den Anbietern im Voraus bereit. Sie bewerten die Software, nicht die Fähigkeit des Anbieters, um seine Schwächen herumzuimprovisieren.

Wochen 3–4: Strukturierte Demonstrationen. Führen Sie jeden Anbieter durch identische Szenarien mit denselben Evaluatoren. Bewerten Sie Kriterien unmittelbar nach jeder Demo. Zeichnen Sie Sitzungen für abwesende Gremiumsmitglieder auf. Erzwingen Sie ein strukturiertes Frageformat — ungestriptete Open-End-Demos erlauben Anbietern, Schwächen zu umgehen.

Wochen 4–5: Dokumentation und Referenzverifizierung. Validieren Sie behauptete Zertifizierungen bei ausstellenden Stellen. Kontaktieren Sie Referenzkunden unabhängig. Fordern Sie tatsächliche SLA-Dokumente statt Marketing-Zusammenfassungen an. Fordern Sie STIG-Ergebnisdateien statt Compliance-Tabellen an.

Wochen 5–6: Bewertung und Quellauswahl-Dokumentation. Aggregieren Sie Evaluatorenbewertungen. Ordnen Sie jede Bewertung spezifischen Beobachtungen oder Dokumentationsbelegen zu. Erstellen Sie ein Quellauswahl-Entscheidungsdokument. Dieser Nachweis ist entscheidend für die Anfechtungssicherheit der Vergabe und für Baselines im Programm-Management nach der Vergabe.

Wie Corvus.Head diese Kriterien erfüllt

Corvus.Head ist ein ISR-C2-Dashboard, das speziell für die in diesem Rahmen beschriebenen operativen Kriterien entwickelt wurde. Es nimmt Multi-Source-Feeds auf — UAV-Telemetrie, SIGINT-Überlagerungen, OSINT-Ebenen und Logistikdaten — über eine offene Adapter-Architektur, die die Entwicklung eigener Konnektoren ohne Anbieterbeteiligung unterstützt. Die Track-Update-Latenz liegt im 95. Perzentil unter Brigade-skaliger Track-Last unter 300 ms. Die Plattform unterstützt Air-Gapped-, On-Premises- und Cloud-Bereitstellung aus derselben Codebasis, mit Offline-Betrieb und automatischer Zustandsabstimmung bei Wiederverbindung. Die rollenbasierte Zugangskontrolle unterstützt attributbasierte Richtlinien bis hinunter auf die Ebene des einzelnen Track-Objekts.

Für Beschaffungsteams, die eine strukturierte Evaluierung durchführen, kann Corvus Intelligence Benchmark-Datenpakete, Referenzarchitektur-Dokumentation und strukturierte Demo-Sitzungen bereitstellen, die auf Ihre Bewertungskriterien zugeschnitten sind — kein standardisierter Marketing-Walkthrough.

Häufig gestellte Fragen

Weiterführende Lektüre: Für eine tiefergehende technische Analyse der Leistungstreiber von C2-Systemen siehe die Artikel über C2-Dashboard-Architektur, C2-System-Tests und -Verifizierung sowie rollenbasierte Zugangskontrolle in Defense-C2-Systemen. Für Hintergrundinformationen zu Standards behandelt der Artikel über den vollständigen Leitfaden zu C2-Systemen den operativen und architektonischen Kontext, der diesen Bewertungskriterien zugrunde liegt.