TAK-Ökosystem und C2-Integration: ATAK mit eigenen Plugins erweitern

Das Team Awareness Kit (TAK)-Ökosystem ist eine der am weitesten verbreiteten taktischen Softwareplattformen, die heute von alliierten Bodentruppen eingesetzt wird. Es basiert auf einem offenen Protokoll und einer plugin-erweiterbaren Client-Architektur und ermöglicht es Verteidigungssoftware-Teams, spezialisierte Fähigkeiten hinzuzufügen — Sensorfeeds, C2-Backend-Anbindung, Logistikdaten, Feuerunterstützungskoordination — ohne die Kernanwendung zu forken. Dieser Artikel behandelt die Struktur des Ökosystems, die Funktionsweise der Plugin-API und was erforderlich ist, um ein Plugin zu entwickeln, das zuverlässig mit einem bestehenden Führungs- und Kontrollsystem integriert.

Architektur des TAK-Ökosystems

Das TAK-Ökosystem ist eine Familie von Lagerbewusstseins-Clients und Server-Software. Auf Client-Ebene: ATAK (Android Team Awareness Kit) läuft auf robusten Android-Geräten und ist die dominierende Formfaktor für abgesessene Kräfte. WinTAK ist das Windows-Äquivalent, das häufig an Befehlsposten und fahrzeugmontierten Workstations eingesetzt wird, wo Bildschirmgröße und Rechenleistung weniger eingeschränkt sind. iTAK läuft auf iOS und wird in einigen Beobachter- und Luftfahrtrollen verwendet. Alle drei Clients teilen dasselbe Datenmodell und Protokoll, sodass eine Position, die von einem ATAK-Gerät gemeldet wird, sofort auf einer WinTAK-Konsole erscheint, die mit demselben Server verbunden ist.

TAK Server — verfügbar als Open-Source-Projekt FreeTAKServer sowie als mehrere kommerzielle Distributionen einschließlich CloudTAK — steht im Mittelpunkt der Architektur. Seine Aufgabe ist die Föderierung von Cursor-on-Target-(CoT-)Ereignisströmen: CoT von verbundenen Clients über TCP/TLS annehmen, diese Ereignisse an andere verbundene Clients verteilen, das operative Lagebild persistieren und WAN-verbundenen Clients ermöglichen, dasselbe gemeinsame Lagebild (COP) wie lokale Mesh-verbundene Einheiten zu teilen.

Die Föderierung erweitert dies noch weiter. Zwei TAK-Server-Instanzen können einen Föderationslink aufbauen, sodass Ereignisse aus dem Client-Pool eines Servers auf dem anderen sichtbar werden — der Mechanismus, durch den alliierte Kräfte ein partielles COP teilen, ohne ihre gesamten Netzwerke zu verschmelzen. Benutzerdefinierte C2-Backends greifen in diese Architektur auf der TAK-Server-Ebene ein, nicht auf der Client-Ebene. Das bedeutet, dass eine gut konzipierte C2-Integration keine Änderungen an der ATAK-Anwendung selbst erfordert.

Plugin-Architektur: wie ATAK-Plugins funktionieren

Ein ATAK-Plugin ist ein Android-APK, das neben der ATAK-Host-Anwendung installiert wird. Zur Installationszeit liest ATAK das Manifest des Plugins, registriert es im Plugin-Manager und macht den Einstiegspunkt des Plugins über ATAKs Plugin-Schublade verfügbar. Das Plugin ersetzt keinen Teil von ATAK — es erweitert ihn. ATAK funktioniert weiterhin vollständig, wenn das Plugin deinstalliert oder deaktiviert wird.

Lebenszyklus-Hooks

Der Plugin-Einstiegspunkt erweitert AbstractPlugin und implementiert zwei primäre Lebenszyklusmethoden. onCreate wird aufgerufen, wenn ATAK das Plugin lädt — hier registriert das Plugin seine Tools, Overlay-Ebenen und Ereignis-Listener und startet alle erforderlichen Hintergrunddienste. onDestroy wird aufgerufen, wenn ATAK das Plugin entlädt — alle Ressourcen müssen hier sauber freigegeben werden, einschließlich Hintergrund-Threads, Netzwerkverbindungen und Kartenebenen. Speicherlecks in onDestroy sind die häufigste Quelle für ATAK-Instabilität durch Drittanbieter-Plugins.

UI-Erweiterungspunkte

ATAK bietet drei primäre Erweiterungspunkte für Plugin-UIs. Das Radialmenü — das kreisförmige Kontextmenü, das bei langem Drücken eines Kartenelements erscheint — kann Plugin-Aktionen eingebettet bekommen, sodass das Rechtsklicken auf einen Positionsbericht einen plugin-spezifischen Workflow auslösen kann, wie das Generieren einer Feuermission aus einem Zielpunkt. Die Plugin-Toolbar ermöglicht es dem Plugin, einen Button zur ATAK-Haupttoolbar hinzuzufügen, der ein benutzerdefiniertes Dropdown-Panel öffnet. Vollbild-Fragments können für komplexere Workflows wie Dateneingabeformulare auf den ATAK-Navigations-Stack gepusht werden.

Alle Plugin-UIs müssen für einhändigen Handschuh-kompatiblen Betrieb ausgelegt sein. Touch-Targets unter 56dp sind nicht akzeptabel. Jeder Dateneingabe-Workflow, der mehr als drei Interaktionen erfordert, sollte überdacht werden — Operatoren im Kontakt haben keine Zeit für komplexe Formulare.

Datenzugriffsmuster

Plugins greifen über MapView auf Kartendaten zu, das Methoden zum Hinzufügen, Aktualisieren und Entfernen von Kartenelementen bereitstellt. Punktelemente (Positionsmarkierungen, Sensorkontakte) sind PointMapItem-Instanzen. Flächen- und Linienelemente sind Shape-Unterklassen. Jedes Kartenelement trägt eine UID, die über Aktualisierungen hinweg stabil sein muss — das Ändern einer UID erstellt ein doppeltes Element anstatt das vorhandene zu aktualisieren, was einer der häufigsten Plugin-Fehler in Produktionssystemen ist.

CoT im Detail: das Protokoll, das alles verbindet

Cursor on Target ist das XML-basierte Ereignisprotokoll, das dem gesamten Datenaustausch im TAK-Ökosystem zugrunde liegt. Jedes Objekt auf der ATAK-Karte wird als CoT-Ereignis dargestellt. Ein gründliches Verständnis von CoT ist Voraussetzung für jede C2-Integrationsarbeit.

Ereignisstruktur

Ein CoT-Ereignis hat drei obligatorische Elemente auf oberster Ebene. Das event-Wurzelelement trägt den Ereignistyp (eine durch Punkte getrennte Taxonomie, die mit a- für Atome, b- für Bits oder t- für Aufgaben beginnt), die UID, die Zeitstempel für Zeit/Start/Stale, das How (wie das Ereignis generiert wurde — maschinell oder menschlich) sowie die Zugriffs- und QoS-Attribute für Klassifizierung und Dienstqualität. Das point-Element trägt Breitengrad, Längengrad, Kreisfehler (ce), linearen Fehler (le) und Höhe über dem Ellipsoid (hae). Das detail-Element ist ein erweiterbarer Container für alles andere.

Der Detail-Block ist der Ort, an dem integrationsspezifische Daten leben. Standardunteremente umfassen contact (Rufzeichen und Endpunktadresse), __group (Gruppenname und Rolle), status (Batterie, Bereitschaft) und remarks (Freitext). Benutzerdefinierte Daten werden in Namespace-Unterelementen transportiert: Ein Feuerunterstützungs-Plugin könnte ein <fireMission>-Element mit Zielnummer, Angriffsmethode und Gefahrnähe-Radius hinzufügen. Standard-ATAK rendert diese benutzerdefinierten Elemente als unbekannte Details und ignoriert sie; ein Begleit-Plugin, das das Schema kennt, zeigt sie korrekt an.

Wichtige Ereignistypen für die C2-Integration

Die Ereignistyp-Taxonomie umfasst Tausende spezifischer Typen. Für die C2-Integration sind die relevantesten: a-f-G-U-C (befreundete Bodeneinheit, Kombattant — die Standard-Blaukraft-Spur), a-h-G (feindliche Bodenspur), a-u-G (unbekannter Boden), b-m-p-w (Wegpunkt), b-r-f-h-c (Feuerunterstützungsanfrage) und t-x-m-c (Chat-Nachricht). Das Verständnis der Typhierarchie — die Präfixbuchstaben kodieren Zugehörigkeit, Gefechtsdimension und Funktion — ermöglicht es einem Plugin, korrekt gerenderte Icons ohne plugin-spezifische Icon-Assets zu generieren.

Stale-Management

Jedes CoT-Ereignis trägt einen Stale-Zeitstempel. ATAK entfernt Ereignisse von der Karte, wenn sie veralten — das ist der Mechanismus für das automatische Altern von Blaukraft-Spuren. Ein Plugin, das Positionsberichte generiert, muss diese vor dem Veralten aktualisieren — typische Positionsaktualisierungen werden alle 30–60 Sekunden mit einem Stale-Fenster von 5 Minuten gesendet. Ein Plugin, das ein Ereignis einmal generiert und nicht aktualisiert, wird sehen, wie seine Elemente von der Karte verschwinden — ein häufiger Fehler in C2-Integrationen der ersten Version.

C2-Integrationsmuster

Es gibt zwei primäre Muster für die Integration eines C2-Systems mit dem TAK-Ökosystem. Das Gateway-Muster arbeitet auf der TAK-Server-Ebene, ohne dass ein Geräte-Plugin erforderlich ist. Das Plugin-Muster läuft auf dem ATAK-Gerät und ist geeignet, wenn die Integration auf Aktionen des Operators auf dem Gerät reagieren muss.

Gateway-Muster: TAK Server zu C2-Backend

Das Gateway ist ein eigenständiger Dienst, der sich mit dem CoT-Stream des TAK-Servers (über die Föderations-API oder als TAK-Server-Plugin) und mit der API des C2-Systems verbindet. Wenn ein neuer Positionsbericht vom TAK Server eintrifft, übersetzt das Gateway ihn von CoT-XML in das Track-Format des C2-Systems und sendet ihn an die C2-API. Wenn das C2-System einen neuen Kontakt oder eine Aufgabe generiert, erzeugt das Gateway ein CoT-Ereignis und veröffentlicht es auf dem TAK Server, von wo es sich auf alle verbundenen ATAK-Clients propagiert.

Dieser Ansatz erfordert kein Geräte-Plugin und keine Änderungen an der ATAK-Anwendung. Er ist die richtige Wahl, wenn die Integration primär server-zu-server erfolgt und das C2-System die Autorität ist. Die größte Herausforderung ist die Latenz: Ein Positionsaktualisierungszyklus, der ATAK-Gerät → TAK Server → Gateway → C2-API → Gateway → TAK Server → ATAK-Gerät durchläuft, kann abhängig von Polling-Intervallen und Netzwerkbedingungen Verzögerungen von mehreren Sekunden einführen. Für nahezu echtzeitliches Track-Sharing ist das TAK-Server-Abonnementmodell mit WebSocket-Verbindungen gegenüber REST-Polling zu bevorzugen.

Plugin-Muster: On-Device-C2-Integration

Das Plugin-Muster führt die C2-Integration direkt auf dem ATAK-Gerät aus. Das Plugin unterhält eine Verbindung zur C2-API (REST oder WebSocket) und schleust CoT-Ereignisse direkt in ATAKs internen Ereignisbus ein, wobei der TAK Server für den eingehenden Datenfluss vollständig umgangen wird. Dies eliminiert einen Netzwerk-Hop und ermöglicht es dem Plugin, gerätespezifischen Kontext hinzuzufügen — die aktuelle Position des Operators, ausgewählte Kartenelemente, aktive Aufgaben — zu ausgehenden C2-Berichten.

Der Rückfluss — von ATAK zum C2-System — funktioniert durch das Abonnieren von ATAKs CoT-Ereignisbus über CotEventListener. Der Listener empfängt alle CoT-Ereignisse, die ATAK sieht, einschließlich derer von anderen Geräten. Das Plugin muss sorgfältig filtern: Es sollte nur Ereignisse weiterleiten, die das aktuelle Gerät initiiert hat (UID-Präfix prüfen), und es darf keine Ereignisse erneut weiterleiten, die über das Gateway vom C2-System eingegangen sind, sonst entsteht eine Rückkopplungsschleife, die das C2 mit duplizierten Spuren überflutet.

Sicherheit: Signierung, Zertifikate und Klassifizierungshandling

Die ATAK-Plugin-Sicherheit wird auf zwei Ebenen durchgesetzt: der Plugin-Signierungsanforderung und der CoT-Transportverschlüsselungsanforderung. Beide müssen für jedes Plugin, das für den operativen Einsatz vorgesehen ist, berücksichtigt werden.

Plugin-Signierung

ATAK in Regierungskonfigurationen erfordert, dass Plugins von einer vertrauenswürdigen Zertifizierungsstelle signiert werden. Dies ist getrennt von der Google-Play-Signierung — der Vertrauensanker ist die CA des TAK-Servers, nicht Google. Das Plugin-APK muss mit einem Zertifikat dieser CA signiert werden, bevor ATAK es lädt. Unsigned Plugins oder mit einer nicht vertrauenswürdigen CA signierte Plugins werden stillschweigend abgelehnt.

In Entwicklungsumgebungen ist es üblich, eine selbst signierte CA zu verwenden und das CA-Zertifikat manuell auf Testgeräten zu verteilen. In der Produktion ist die CA typischerweise dieselbe PKI-Infrastruktur, die für die Client-Authentifizierung bei TAK-Server-TLS-Verbindungen verwendet wird.

Verschlüsselter CoT-Transport

CoT-Datenverkehr in Produktionsumgebungen wird über TLS mit gegenseitiger Authentifizierung übertragen — sowohl der Client als auch der Server präsentieren Zertifikate. Das bedeutet, dass jedes ATAK-Gerät ein vom TAK-Server-CA ausgestelltes Client-Zertifikat benötigt und der TAK Server ein Server-Zertifikat braucht, dem die Clients vertrauen. Die Zertifikatsregistrierung erfolgt über den Registrierungsendpunkt des TAK-Servers, der Client-Zertifikate auf Basis eines vorher vereinbarten Registrierungspassworts oder -tokens ausstellt.

Ein Plugin, das eigene Netzwerkverbindungen zum C2-Backend öffnet, muss ebenfalls TLS mit Certificate Pinning verwenden. Das Plugin einen Fallback auf Klartext zuzulassen — auch vorübergehend während der Entwicklung — schafft eine Gewohnheit, die sich in die Produktion überträgt. Entwickeln Sie von Anfang an mit TLS.

Klassifizierungsmarkierungen in CoT

CoT-Ereignisse mit klassifizierten Daten verwenden das Unterelement detail/classification, um das Ereignis mit einer Klassifizierungsstufe zu markieren. ATAKs Standard-Rendering unterscheidet visuell nicht zwischen klassifizierten und nicht klassifizierten Ereignissen — es liegt in der Verantwortung des Plugins und des Systemadministrators sicherzustellen, dass klassifizierte Ereignisse nur über klassifizierte Netzwerke übertragen und nur auf genehmigten Geräten gespeichert werden. Ein für klassifizierte Umgebungen konzipiertes Plugin sollte die Klassifizierung empfangener Ereignisse prüfen, bevor es sie anzeigt oder weiterleitet, und es sollte die Weiterleitung klassifizierter Ereignisse an nicht autorisierte Systeme verweigern.

Typische Plugin-Anwendungsfälle

Die operativ wertvollsten ATAK-Plugins folgen einem wiederkehrenden Muster: Sie verbinden eine spezialisierte Datenquelle mit dem gemeinsamen Lagebild und reduzieren so die Anzahl der Bildschirme, die ein Operator gleichzeitig überwachen muss.

UAV-Video-Overlay. Das Plugin empfängt einen Videostream von einer UAV-GCS (Bodenkontrollstation) über RTSP oder HLS und zeigt ihn in einem ATAK-Panel an. Gleichzeitig empfängt es Telemetrie von der GCS — UAV-Position, Kamerakopf-Azimut und -Depressionswinkel, Sensor-Sichtfeld — und rendert ein Footprint-Polygon auf der ATAK-Karte, das genau zeigt, was die UAV-Kamera aktuell betrachtet. Operatoren können einen Punkt innerhalb des Footprints antippen, um präzise Koordinaten zu erhalten, was eine schnelle Zielübergabe ohne eine separate GCS-Workstation ermöglicht.

SIGINT-Kontaktanzeige. Ein Richtungsfindeempfänger meldet Peillinien — die Richtung von einem bekannten Erfassungspunkt zu einem interessanten Sender. Das Plugin konvertiert diese in CoT-Peillinienereignisse und zeigt sie auf der ATAK-Karte als strahlende Linien mit Unsicherheitskegeln an. Wenn sich zwei oder mehr Peillinien schneiden, kann das Plugin eine geschätzte Senderposition berechnen und anzeigen. Diese Fähigkeit integriert sich direkt in das taktische Lagebild, ohne eine separate SIGINT-Workstation zu benötigen. Weitere Informationen zur Integration von RF-Datenquellen finden Sie in unserem Artikel zur Integration taktischer Funksoftware.

Logistik- und Nachschubverfolgung. Ein Logistik-Plugin verbindet sich mit dem Versorgungssystem der Einheit und zeigt den aktuellen Standort von Nachschubfahrzeugen, ihre voraussichtliche Ankunftszeit an der vorderen Linie und den Inhalt jedes Fahrzeugs an. Über das Plugin eingereichte Nachschubanfragen generieren strukturierte CoT-Aufgabenereignisse, die über das C2-Gateway an das Logistiksystem zurückfließen und so den Anforderungs-Lieferungs-Kreislauf ohne Sprach-Funkverkehr schließen.

Verwundetenverfolgung. Ein Sanitätsstatus-Plugin ermöglicht es Sanitätern, Verwundetenereignisse — Kategorie (dringend, prioritär, routinemäßig), Verletzungsmechanismus, geleistete Behandlung, Evakuierungsstatus — direkt auf der ATAK-Karte am Verletzungsort zu erfassen. Das Ereignis ist ein CoT-Punkt mit einem medizinischen Detail-Block. Es fließt in Echtzeit auf das WinTAK-Display des Bataillons-Sanitätsoffiziers und über das C2-Gateway zum Medevac-Koordinationssystem — und eliminiert so den 9-Zeilen-Funkbericht als einziges Mittel zur Übermittlung von Verwundetendaten unter Beschuss.

Feuerunterstützungsanfragen. Ein digitales Feuer-Plugin automatisiert die Vorbereitung und Übertragung von Feuerunterstützungsanfragen. Der Operator wählt ein Ziel auf der ATAK-Karte aus, füllt ein strukturiertes Anfrageformular aus (Zielbeschreibung, Angriffsmethode, Gefahrnähe-Markierung), und das Plugin generiert ein standardisiertes CoT-Feuerereignis. Das Ereignis fließt gleichzeitig auf das Display des Feuerunterstützungsoffiziers und zum Feuer-C2-System, ohne erneute Eingabe. Das Plugin kann Beschussbestätigungen und Schussmeldungen vom Feuer-C2 zurückempfangen und auf dem Gerät des Operators anzeigen.

Eine detaillierte Behandlung der Rolle von CloudTAK als Server-Backbone für diese Integrationen in vernetzten Umgebungen finden Sie in unserem Leitfaden zur CloudTAK-API-Integration.

Test und Bereitstellung

Das Testen eines ATAK-C2-Integrations-Plugins erfordert eine repräsentative Testumgebung: eine TAK-Server-Instanz, mindestens zwei ATAK-Geräte (eines generiert Ereignisse, eines beobachtet sie) und eine C2-System-Testinstanz oder einen Simulator. Die häufigsten Integrationsfehler — nicht aktualisierende veraltete Ereignisse, doppelte UIDs, Rückkopplungsschleifen im Rückfluss — manifestieren sich nur unter Last mit mehreren gleichzeitig aktiven Geräten.

Die Bereitstellung erfolgt über TAK-Server-Datenpakete. Ein Datenpaket ist ein ZIP-Archiv, das das Plugin-APK, die Konfigurationsdatei des Plugins (vorausgefüllt mit Serveradressen und Zugangsdaten) und das CA-Zertifikat für TLS enthält. Der Operator installiert das Datenpaket über ATAKs Import-Manager, und alle Komponenten werden in einem einzigen Schritt bereitgestellt. Dies ist unter Feldbedingungen deutlich zuverlässiger als manuelle APK-Installation und Zertifikatsregistrierung.

Batteriebelastungstests verdienen besondere Aufmerksamkeit. Ein Plugin, das eine dauerhafte WebSocket-Verbindung zu einer C2-API unterhält, kann auf einem typischen robusten Gerät 15–25 % zusätzlichen Batterieverlust verursachen. Verwenden Sie Androids Battery-Historian-Tool, um die Wake-Lock- und Netzwerkaktivitätsmuster des Plugins vor der Bereitstellung zu messen und zu optimieren. Operatoren werden ein Plugin bemerken — und deaktivieren —, das ihr Gerät spürbar schneller als das ATAK-Basisniveau entlädt.