Teile 1 und 2 haben vertrauenswürdige Tracks geliefert. Teil 3 baut die Oberfläche, die der Bediener tatsächlich sieht. Das Gemeinsame Lagebild ist die Schicht, an der die Plattform gemessen wird — macht man es richtig, fließt Nachsicht nach unten durch den Rest des Stacks; macht man es falsch, wird eine technisch korrekte Fusions-Pipeline in der zweiten Einsatzwoche stillgelegt. Die architektonischen Muster sind etabliert (siehe Gemeinsames Lagebild (COP): Wie es in moderner Verteidigungssoftware gebaut wird); Teil 3 verwandelt sie in konkrete Engineering-Entscheidungen.

Schritt 1: Frontend-Stack

Für die laufende Beispielplattform ist das COP eine browserbasierte Anwendung. Die Wahl zwischen nativ und Web ist seit über einem Jahrzehnt zugunsten von Web entschieden; der verbleibende native Fußabdruck liegt bei spezialisierten Handheld-Plattformen (das ATAK-Ökosystem — siehe ATAK-Plugin-Entwicklung) und nicht bei Anzeigen am Gefechtsstand.

Der vertretbare Stack:

  • React mit TypeScript für die Anwendungshülle. Die Reife des Ökosystems, die Verfügbarkeit von Personal und das akkreditierungsfreundliche Tooling machen es zur sicheren Wahl für eine 20-Jahre-Plattform. Vue ist vertretbar; Svelte ist noch keine beschaffungsreife Wahl für die Verteidigung.
  • Cesium für die Globusansicht und 3D — Gelände, Luftraumvolumen, Satellitenspuren. WebGL-beschleunigt, ausgereift, der De-facto-Standard für geospatiales 3D in der Verteidigung.
  • Mapbox GL oder MapLibre für die 2D-Kartenansicht. Vektorkacheln für Geschwindigkeit; Rasterkacheln als Offline-Fallback. Die Abwägungen und die Performance-Obergrenze finden sich in Echtzeit-Kartendarstellung für militärisches C2.
  • Zustand oder Redux Toolkit für State. Das Volumen an Streaming-Track-Updates macht naiven React-State unhaltbar; verwenden Sie einen Store mit referenzstabilen Selektoren und Shallow-Equal-Vergleichen.
  • Ant Design oder Mantine für die umgebende UI — Panels, Modals, Formulare. Widerstehen Sie der Versuchung, im ersten Build ein maßgeschneidertes Designsystem zu bauen; wählen Sie eine ausgereifte Bibliothek und passen Sie das Theme an Verteidigungskonventionen an.

Eine nicht offensichtliche Entscheidung: Halten Sie das COP als Single-Page-Application, nicht als Multi-Page-Site. Bediener navigieren nicht. Sie öffnen das COP einmal und nutzen es stundenlang. Seiten-Reloads sind die falsche Abstraktion; Ansichten und Panels innerhalb einer einzigen Hülle sind die richtige.

Schritt 2: Militärische Symbologie, richtig gemacht

Tracks werden als Symbole gerendert. Der Symbolkatalog wird durch MIL-STD-2525D (oder die entsprechende NATO-APP-6-Variante) geregelt. Handgestrickte Symbologie ist eine rote Flagge in der Beschaffung und ein Interoperabilitätsblocker: In dem Moment, in dem die Plattform mit einem alliierten System integriert wird, lösen nicht passende Symbole ein sofortiges Compliance-Versagen aus.

Verwenden Sie eine gepflegte Bibliothek. Die Open-Source-Implementierung milsymbol ist die De-facto-Wahl für webbasierte COPs; sie erzeugt den Standardsymbolsatz als SVG- oder Canvas-Drawables. Die Bibliothek behandelt die Zugehörigkeit (freund, feindlich, neutral, unbekannt), Echelon-Marker, identifizierenden Text und die Modifikatoren, die ein generisches Infanteriesymbol in „1. Bataillon, mechanisiert, in Verteidigungsstellung" verwandeln.

Das Integrationsmuster: Die Fusions-Engine emittiert Tracks mit Identitätsattributen; das COP schlägt den passenden MIL-STD-2525-SIDC (Symbol Identification Code) für diese Attribute nach; die Bibliothek rendert das Symbol. Cachen Sie gerenderte Symbole nach SIDC; dasselbe Symbol wird in einem typischen Lagebild tausendfach wiederverwendet.

Ein praktisches Detail, das erwähnenswert ist: MIL-STD-2525D enthält Tausende verschiedener Symbole. Fast keine operativ relevanten Szenarien nutzen mehr als ein paar hundert. Bauen Sie den Katalog von innen nach außen auf — beginnen Sie mit dem, was die Sensoren der Plattform produzieren, und erweitern Sie ihn, wenn neue Sensorklassen hinzukommen.

Schritt 3: Echtzeit-Updates über WebSocket

Die Aufgabe des COP ist es, den Track-Store nahezu in Echtzeit widerzuspiegeln. Polling skaliert nicht; WebSocket ist die strukturelle Antwort. Das architektonische Muster:

Ein Gateway-Dienst hält offene WebSocket-Verbindungen zu jedem Browser. Er abonniert die Topics tracks.updates und tracks.lifecycle der Fusions-Engine. Wenn ein Track-Update eintrifft, wertet das Gateway den verbindungsspezifischen Filter aus (welcher Bereich, welche Rollen, welche Klassifizierungen) und pusht das Update an den Browser. Der Browser wendet das Update auf seinen lokalen State-Store an; React rendert nur die betroffenen Symbole neu.

Die nicht offensichtlichen Engineering-Details, die darüber entscheiden, ob das im Maßstab funktioniert:

Filterung geschieht serverseitig. Jeden Track an jeden Browser zu pushen funktioniert nicht — bei 10.000 Tracks, die sich mehrmals pro Minute aktualisieren, ersticken sowohl die Leitung als auch der Browser. Jede Verbindung hat einen Subscription-Filter (Viewport-Grenzen, rollenbasierte Layer, Klassifizierungsfilter), und nur passende Updates fließen.

Delta-Updates, keine vollständigen Ersetzungen. Ein Track-Update ist ein Teilstück — Position geändert, Lifecycle-Status geändert, Identität präzisiert. Der Browser wendet den Patch auf seine lokale Kopie an. Vollständige Track-Payloads werden nur beim initialen Abonnement und bei Schema-Migrationen gesendet.

Reconnect mit State-Wiederherstellung. WebSocket-Verbindungen brechen ab, besonders in taktischen Netzwerken. Beim Reconnect tauscht der Browser seine zuletzt gesehene Sequenznummer mit dem Gateway aus, das verpasste Updates aus dem Bus wiedergibt. Kein State-Verlust, kein vollständiger Refetch.

Backpressure-Handhabung. Ein langsamer Client darf das Gateway nicht ins Stocken bringen. Die Queue-Tiefe pro Client ist begrenzt; läuft die Queue über, wird der Client getrennt und gezwungen, sich mit einem vollständigen State-Abruf neu zu verbinden. Lieber ein Bediener, der neu verbindet, als alle Bediener eingefroren.

Schritt 4: Rollenbasierte Filterung und Klassifizierung

Nicht jeder Bediener sieht jeden Track. Das COP eines Infanteriezugführers zeigt keine Flugabwehr-Engagement-Zonen. Ein NATO-RESTRICTED-Konto sieht keine SECRET-klassifizierten Tracks. Die Plattform setzt das an zwei Stellen durch: dem Gateway-Filter (was gesendet wird) und der Policy-Engine (ob überhaupt gesendet wird).

Der Rollenfilter ist eine benutzer- und sitzungsbezogene Konfiguration: welche Track-Typen, welche Einsatzbereiche, welche Anzeige-Layer. Der Benutzer kann innerhalb seiner Berechtigung anpassen; das System erzwingt die Obergrenze. Der Klassifizierungsfilter ist nicht verhandelbar: Die effektive Klassifizierung eines Tracks (in der Fusion berechnet, an das Gateway propagiert) muss auf oder unter der Freigabestufe des Benutzers liegen. Querprüfungen in der API- und Datenbankschicht — niemals nur in der UI — sind die Regel. Das detaillierte Muster findet sich in Rollenbasierte Zugriffskontrolle in Verteidigungs-C2-Systemen.

Ein operativer Hinweis: Bauen Sie die UI zur Rollenkonfiguration gemeinsam mit der Bediener-Community, nicht in Isolation. Standardwerte zählen. Ein Infanteriebenutzer möchte nicht jede Sitzung damit beginnen, sechs Layer irrelevanter Flugabwehrdaten zu deaktivieren. Ein Wing-Operator möchte nicht jede Sitzung damit beginnen, die Flugabwehr-Layer zu aktivieren, die sein Vorgänger deaktiviert hat. Rollenbasierte Standardwerte, die zur tatsächlichen Aufgabe des Bedieners passen, halbieren die Frustrationsbasis der Bediener.

Schlüssel­erkenntnis: Das COP, das eine Demo gewinnt, ist dicht, animiert und voller Overlays. Das COP, das den Einsatz gewinnt, ist zurückhaltend, schnell und zeigt nur das, was der Bediener braucht. Standardmäßig weniger, größere, kontrastreichere Symbole. Lassen Sie Bediener Details hinzufügen; starten Sie sie nicht bei maximaler Informationsdichte.

Schritt 5: Bedienerergonomie

Ein COP, das ergonomisch versagt, versagt operativ. Die Disziplin entsteht aus einer Handvoll nicht verhandelbarer Regeln.

Anzeige veralteter Tracks. Wenn der Lifecycle-Status eines Tracks „fading" oder „verloren" lautet, ändert sich das Symbol — typischerweise gedimmt, möglicherweise umrandet, mit einem Altersindikator. Bediener müssen auf einen Blick erkennen, welchen Tracks sie vertrauen können.

Konfliktauflösungs-UI. Wenn zwei Bediener gleichzeitig denselben Track oder Auftrag bearbeiten, muss die Plattform den Konflikt sichtbar machen, nicht stillschweigend eine Seite überschreiben. Last-Writer-Wins auf Attributebene ist der Standard; explizite Versöhnung bei sicherheitskritischen Attributen.

Keyboard-first-Design. Reine Maus-UIs versagen in belasteten Einsätzen. Jede häufige Aktion hat ein Tastaturkürzel; die Kürzel sind im Produkt dokumentiert und auffindbar.

Touch- und Handschuhbedienung für ruggedized Ziele. Dasselbe COP läuft auf Workstations in Gefechtsständen und auf gehärteten/ruggedized Tablets an brigadenahen vorgeschobenen Positionen. Trefferflächen sind für Handschuhe dimensioniert; Hochkontrastmodi sind erstklassig. Das umfassendere Muster findet sich in Ruggedized UX für militärische Bediener.

Offline-Betrieb. Deployments am taktischen Edge verlieren Konnektivität. Das COP muss aus seinem lokalen Cache funktionieren, in der Warteschlange befindliche Bediener-Aktionen beim Reconnect wiedergeben und klar anzeigen, welche Daten veraltet sind. Das architektonische Muster findet sich in Offline-First-Militär-Apps; die Offline-Karten-Seite in Offline-Karten mit MBTiles und PMTiles.

Schritt 6: Jenseits der Karte — Dashboards und Panels

Das COP ist mehr als eine Karte. Bediener brauchen Auftragsschnittstellen, Nachrichtenkomposition, Planungstools, Aufklärungspanels, Log-Ansichten. Die plattformweite UX-Regel: Jedes Panel folgt denselben Interaktionskonventionen. Wenn die Auswahl eines Tracks in der Karte ihn in einem Seitenpanel hervorhebt, dann hebt die Auswahl eines Tracks in einem beliebigen Panel ihn auch in der Karte hervor. Inkonsistenz in dieser Schicht ist das häufigste UX-Versagen in Verteidigungssoftware.

Die architektonische Trennung, die es zu wahren gilt: Die Kartenansicht ist ein Panel; die Dashboards und Seitenpanels sind andere Panels; sie teilen denselben Auswahl-State über den zentralen Store. Das Hinzufügen eines neuen Analyse-Tools ist ein neues Panel, keine neue Anwendung. Die Dashboard-Architekturmuster finden sich in C2-Dashboard-Architektur.

Schritt 7: Performance-Ziele

Die Ziele des COP sind enger, als sie klingen:

  • Initiale Ladezeit unter 3 Sekunden auf einem taktischen Edge-Laptop mit zwischengespeicherten statischen Assets.
  • Track-Update-Latenz unter 200 ms vom Gateway-Emit bis zum sichtbar bewegten Symbol im Browser.
  • Anhaltende 60 FPS Kartendarstellung mit bis zu 10.000 sichtbaren Tracks.
  • Schwenken und Zoomen reaktionsschnell in typischen taktischen Kartenmaßstäben (1:50.000 bis 1:1.000.000).
  • Speicher begrenzt — der Browser muss den ganzen Tag laufen, ohne Speicher zu lecken. Profilieren Sie jedes Release.

Die Ziele sind mit dem gewählten Stack erreichbar; sie zu verfehlen ist meist das Ergebnis einer architektonischen Abkürzung weiter oben in der Pipeline (serverseitige Filterung nicht implementiert, vollständige Payloads statt Deltas / inkrementelle Updates, naives State-Management).

Wie es weitergeht

Teil 3 hat das COP gebaut. Tracks rendern mit korrekter Symbologie; Updates streamen über WebSocket; Bediener sehen nur das, wozu sie berechtigt sind; die Ergonomie trägt reale Einsätze. Die Plattform ist nun für einen Bediener nutzbar — aber noch nicht auslieferungsreif.

Teil 4 schließt den Kreis: NATO-Interoperabilitätsbrücken (CoT, MIP4, STANAG 4559), Klassifizierungs-Kennzeichnung und Durchsetzung der Releasability, die DevSecOps-Pipeline, die Akkreditierungsbeweise produziert, und Air-Gap-Deployment für den taktischen Edge-Einsatz. Nach Teil 4 ist die Plattform operativ einsetzbar.