Ein Führungs- und Kontroll-Dashboard ist kein Business-Intelligence-Tool in Militäroptik. Die Architekturentscheidungen, die für ein BI-Dashboard ausreichende Leistung sicherstellen — Abfrageintervalle, Seitenaktualisierungszyklen, synchrone API-Aufrufe — sind genau die Entscheidungen, die ein verteidigungsspezifisches C2-Dashboard im Feld zum Scheitern bringen. Das Bedrohungsmodell, die Netzwerkumgebung und die operativen Einsätze sind grundlegend verschieden.

Dieser Artikel behandelt die wichtigsten Architekturentscheidungen, mit denen ein Entwicklungsteam beim Aufbau eines C2-Dashboards für Verteidigungszwecke konfrontiert wird: wie Frontend vom Backend getrennt wird, wie Echtzeitdaten aufgenommen werden, ohne die Benutzeroberfläche zu überlasten, welche Kartenrendering-Technologie gewählt werden soll, wie rollenbasierte Zugriffskontrolle für verschiedene Führungsebenen strukturiert wird, und wie die Leistung bei Spurenzahlen von fünf oder sechs Stellen aufrechterhalten wird.

Frontend/Backend-Trennung in Verteidigungs-Dashboards

Das dominante Muster in der modernen C2-Dashboard-Entwicklung ist eine React- oder Vue-Single-Page-Application (SPA), die Daten von einem Satz Backend-Microservices über WebSocket-Verbindungen für Live-Daten und REST für Konfiguration und historische Abfragen konsumiert. Diese Trennung bietet eine klare Trennung der Zuständigkeiten: das Frontend ist für das Rendering des Zustands verantwortlich, das Backend für die Aufrechterhaltung des autoritativen Zustands und die Übertragung von Deltas.

Das Microservices-Backend besteht typischerweise aus mindestens vier Diensten in einer minimalen Bereitstellung: ein Spurdienst (pflegt die Live-Objektdatenbank), ein Nachrichtendienst (verarbeitet CoT- und NFFI-Eingaben), ein Alarmdienst (wertet Regeln aus und veröffentlicht Benachrichtigungen) und ein Authentifizierungsdienst (validiert JWT-Token und setzt RBAC-Richtlinien durch). Jeder Dienst ist containerisiert — typischerweise Docker auf Kubernetes für Hauptquartier-Bereitstellungen oder Docker Compose auf einem gehärteten Server für vorwärts stationierte Konfigurationen.

Eine kritische Architekturanforderung, die Verteidigungs-Dashboards von kommerziellem SaaS unterscheidet, ist die Anforderung, in Air-Gap- oder stark bandbreitenbeschränkten Umgebungen zu betreiben. Das bedeutet, dass das gesamte Frontend-Bundle, alle Kartenkacheln und alle Geodaten-Bibliotheken lokal verfügbar sein müssen — eine vollständig eigenständige Artefakt ohne CDN-Abhängigkeiten.

Echtzeit-Datenaufnahme: WebSocket vs. Polling

Für Spuraktualisierungen ist WebSocket die einzige praktikable Wahl bei taktischen Latenzanforderungen. Ein HTTP-Polling-Ansatz mit 5-Sekunden-Intervall führt zu einer durchschnittlichen Latenz von 2,5 Sekunden plus Server-Verarbeitungszeit, was für Luftspuren, wo die 10-Sekunden-Veralterungs-Schwelle gilt, inakzeptabel ist. WebSocket-Verbindungen liefern bei ordnungsgemäßer Verwaltung eine End-to-End-Latenz unter 200 ms in einem lokalen Netzwerk und unter 500 ms über einen taktischen Funklink.

Das Standardimplementierungsmuster ist ein Fan-out-WebSocket-Gateway. Der Backend-Spurdienst veröffentlicht Spur-Deltas (nicht den vollständigen Zustand) auf einem internen Message-Bus — Redis Pub/Sub oder NATS JetStream sind gängige Optionen. Das WebSocket-Gateway abonniert den Bus, pflegt einen Verbindungspool authentifizierter Browsersitzungen und verteilt relevante Ereignisse an jede Sitzung basierend auf der Rolle der Sitzung und dem Interessensbereichsfilter.

Backpressure ist ein kritisches Anliegen, das viele frühe C2-Implementierungen übersehen. Wenn das Frontend Ereignisse nicht so schnell verarbeiten kann, wie sie ankommen — beispielsweise während eines intensiven Gefechts, wenn Hunderte von Spuren gleichzeitig aktualisiert werden — kann sich der WebSocket-Puffer füllen und die Verbindung unterbrechen. Die Lösung ist eine clientseitige Ereigniswarteschlange mit konfigurierbarer Tiefe und einer Verwerfungsrichtlinie.

Kartenebenen-Technologien

Die Kartenebene ist die visuell kritischste Komponente eines C2-Dashboards und diejenige mit den bedeutendsten Auswirkungen der Technologieauswahl. Drei Optionen dominieren die Bundeswehr-nahe C2-Entwicklung: Mapbox GL JS, Cesium.js und benutzerdefiniertes WebGL-Rendering auf Basis von OpenLayers oder Leaflet.

Mapbox GL JS ist die am häufigsten verwendete Option für 2D-Lagebilddashboards. Es rendert Vektorkacheln mit WebGL, unterstützt benutzerdefinierte Ebenensortierung und verwaltet dynamisches Styling effizient. Für Bereitstellungen in eingestuften Netzen kann Mapbox GL JS vollständig selbst gehostet werden — bedienen Sie Ihren eigenen Vektorkachelsatz aus TileServer-GL oder MapTiler Server, und die Bibliothek hat keine externen Netzwerkabhängigkeiten. Die Hauptbeschränkung ist ausschließlich 2D-Rendering.

Cesium.js ist der Standard für 3D-Erddarstellung. Es unterstützt ellipsoidalen Globusmodus, genaues 3D-Gelände und zeitdynamische Visualisierung. Der Leistungsaufwand ist real: Cesium benötigt eine diskrete GPU und eine moderne CPU für flüssiges Rendering bei hohen Spurzahlen.

Benutzerdefinierte Kachelserver für eingestufte Netze sind in den meisten nationalen Verteidigungsprogrammen eine Anforderung. Die Bundeswehr und das BMVg verlangen, dass alle geografischen Referenzdaten auf genehmigten lokalen Servern innerhalb des Netzwerkperimeters gespeichert und bedient werden. MapTiler Server Enterprise und TileServer-GL unterstützen MBTiles und können sowohl Raster- als auch Vektorkacheln bedienen.

Rollenbasierte Zugangskontrolle für Führungsebenen

Ein C2-Dashboard bedient Personal mit grundlegend unterschiedlichen Informationsbedürfnissen und Autorisierungsstufen. Ein Kommandeur auf Brigadeebene benötigt das vollständige Lagebild mit Feuerführungsbefugnis. Ein Bediener benötigt Spurverwaltung und Berichtsmöglichkeiten, aber keine Feuermission-Initiierung. Ein Analyst benötigt Lesezugriff auf alle Spurdaten plus Aufklärungsüberlagerungen, aber kein Schreibrecht. Ein Logistikoffizier benötigt Routenüberlagerungen und Logistikknotenstatus, aber keinen Zugriff auf Aufklärungskompartments.

Die Standardimplementierung verwendet JWT-Token mit eingebetteten Claims, die sowohl die Rolle des Benutzers als auch seine Klassifizierungsstufe kodieren. Die Backend-API setzt Zugriff auf Ressourcenebene durch. Das Frontend verwendet dieselben Claims zur bedingten Darstellung von UI-Elementen — der Schaltfläche „Feuermission" wird für Benutzer ohne die Rolle FIRE_CONTROL nicht gerendert, sondern lediglich deaktiviert.

Leistung im Maßstab: 10.000+ gleichzeitige Spuren

Die Skalierbarkeit der Spuranzahl ist die am häufigsten unterschätzte Herausforderung bei der C2-Dashboard-Entwicklung. Ein System auf Brigadeebene in einer hochintensiven Umgebung kann 500–2.000 gleichzeitige Spuren aufweisen. Ein System auf Theaterebene, das Luft-, Boden-, See- und Raumobjekte gleichzeitig verfolgt, kann 50.000 überschreiten.

Die entscheidende Architekturentscheidung ist, ob Spuren als DOM-Elemente, SVG, Canvas 2D oder WebGL gerendert werden. DOM und SVG versagen oberhalb von etwa 1.000 Elementen. WebGL ist die einzige Option, die bei 60 FPS auf 10.000+ Spuren skaliert, wobei instanziertes Rendering verwendet wird, um Tausende identischer Symbol-Geometrien mit einem einzigen Draw-Call zu zeichnen.

Bei 10.000+ Spuren verlagert sich das Flaschenhals auf die JavaScript-Verarbeitung eingehender WebSocket-Ereignisse. Die Lösung ist, die Spurzustandsverwaltung in einen Web Worker zu verlagern, sodass der Haupt-Thread für Benutzerinteraktionen frei bleibt.

Architekturprinzip: Trennen Sie Lesepfade von Schreibpfaden auf der API-Ebene. Spurlesungen sind hochfrequent und latenzsensitiv; Spurschreibungen sind niederfrequent und korrektheitssensitiv. Diese haben unterschiedliche Infrastrukturanforderungen und sollten nicht dieselbe Dienstschicht teilen.

Alarmlogik-Architektur

Die Alarmlogik in einem C2-Dashboard muss deterministisch, auditierbar und schnell sein. Ein Alarm, der 30 Sekunden nach der Auslösebedingung ausgelöst wird, ist operationell nutzlos. Der Alarmdienst wertet Regeln gegen den Live-Spurzustand bei jedem Aktualisierungsereignis vom Message-Bus aus.

Regeln werden als strukturierte JSON-Policy-Dokumente gespeichert: eine Bedingung (räumlich — Spur betritt ein definiertes Polygon; attributbasiert — Spurgeschwindigkeit überschreitet Schwellenwert; zeitlich — Spur wurde seit N Sekunden nicht aktualisiert) und eine Aktion (WebSocket-Benachrichtigung senden, Alarmdatensatz erstellen, externe Integration auslösen). Die Regel-Engine wertet räumliche Bedingungen mit einem räumlichen Index (R-Baum) für O(log n) Polygon-Schnittprüfungen aus.