ATAK & CoT: Ein technischer Deep Dive ins Herz moderner Lagebewusstseinssysteme

Einführung

Das Android Team Awareness Kit (ATAK) ist eine Android-basierte Softwareplattform für räumliches Lagebewusstsein und Zusammenarbeit, die ursprünglich für militärische Zwecke (dort „Android Tactical Assault Kit“) entwickelt wurde und inzwischen auch in einer zivilen Variante (CivTAK) verfügbar ist. ATAK ermöglicht die Darstellung von Geodaten in Echtzeit – z.B. Positionen von Einsatzkräften, Gefahrbereichen, Missionszielen – auf digitalen Karten und unterstützt Nutzer bei Navigation, Einsatzplanung und Kommunikation. Wichtige Merkmale sind die hochperformante Kartenanzeige (2D/3D) mit Online- und Offline-Karten, die gemeinsame Nutzung von Objekten (Punkte, Routen, Gebiete) sowie integrierte Kommunikationsfunktionen wie Textchat, Dateifreigabe, Live-Video und Tracking. Besonders hervorzuheben ist die erweiterbare Plugin-Architektur von ATAK, mit der zusätzliche Funktionen für spezifische Einsatzzwecke integriert werden können. CivTAK (ATAK-CIV) wurde 2020 für die öffentliche Nutzung freigegeben und als „Android Team Awareness Kit“ umbenannt. Im Folgenden wird eine technische Analyse von ATAK und CivTAK präsentiert, mit Fokus auf der Systemarchitektur, verfügbaren APIs/Schnittstellen, der Plugin-Entwicklung, implementierten Sicherheitsmechanismen, dem Cursor-on-Target (CoT) Protokoll, den Unterschieden zwischen militärischer und ziviler Version sowie den verfügbaren Open-Source-Ressourcen und SDKs für Entwickler. Beispiele und Codeausschnitte verdeutlichen die wichtigsten Konzepte.

Systemarchitektur

ATAK ist als modulares Client-Server-System konzipiert, wobei der Haupt-Client eine Android-App ist und die TAK-Server-Komponente (optional) als zentrales Backend zur Koordination mehrerer Clients dienen kann. Die Architektur der Android-App ist in mehrere Zentralbestandteile gegliedert, die in der folgenden Tabelle zusammengefasst sind:

Funktionsweise: Im Betrieb bezieht der ATAK-Client seine eigene Position vom internen GPS und zeigt dem Nutzer die Umgebung auf der Karte an. Ereignisdaten (Positionen, Icons, Meldungen) werden über CoT mit anderen verbundenen Clients ausgetauscht, entweder direkt im Ad-hoc-Netz (per Multicast/Broadcast) oder via Weiterleitung über einen TAK-Server in der Mitte. Alle verbundenen Teilnehmer erhalten so Echtzeit-Updates und teilen ein gemeinsames Lagebild. Der TAK-Server dient als zentrale Instanz zur Synchronisierung und Datenspeicherung: er empfängt CoT-Nachrichten von allen Clients und sendet sie an alle anderen weiter. Zusätzlich bietet der Server Dienste wie Benutzerverwaltung, Persistenz (Datenbank der Missionsdaten) und ggf. Schnittstellen zu weiteren Systemen. ATAK selbst läuft auf Android (Java/Kotlin) mit performance-kritischen Teilen in C/C++ (Rendering Engine). Durch die Plugin-Modularität ist die Architektur offen für vielfältige Erweiterungen – so können etwa Kommunikations-Plugins alternative Übertragungsmedien einbinden (z.B. akustisches Modem über Funk) oder Daten-Plugins externe Feeds einlesen (z.B. ADS-B Flugtracker, Drohnen-Telemetrie). Dieses offene Design macht ATAK äußerst anpassbar an unterschiedliche Einsatzzwecke (Militär, BOS, Outdoor, etc.), da spezifische Funktionen als Plugin ergänzt werden können, ohne den Core zu verändern. Die militärische und die zivile App-Version sind dabei praktisch identisch in der Architektur und vollständig miteinander kompatibel – Unterschiede liegen hauptsächlich in zusätzlichen Plugins oder Konfigurationen für Militär (siehe Abschnitt Unterschiede ATAK vs. CivTAK).

APIs und Schnittstellen

ATAK/CivTAK stellt mehrere Schnittstellen für Entwickler bereit, um Daten einzuspeisen, abzurufen oder die Anwendung zu erweitern. Im Wesentlichen gibt es zwei Ansätze: (1) Verwendung des CoT-Protokolls zur externen Datenintegration und (2) Entwicklung von Plugins innerhalb der ATAK-App mittels der bereitgestellten API.

1. CoT-Protokoll als externe Schnittstelle: Da ATAK alle Lageinformationen als Cursor-on-Target (CoT)-Events transportiert, kann ein externes System durch das Senden oder Empfangen von CoT-Nachrichten in die Datenverteilung eingebunden werden. Beispielsweise kann ein Sensor oder ein anderes Programm eine CoT-Nachricht mit einem bestimmten Ereignis (z.B. Position eines Fahrzeugs, Alarmmeldung) per UDP/TCP an die ATAK-Clients oder den TAK-Server schicken – alle Teilnehmer, die diese CoT empfangen, stellen dann das entsprechende Objekt auf ihrer Karte dar. Auf diese Weise lässt sich ATAK relativ leicht in Fremdsysteme integrieren, indem man CoT-Nachrichten gemäß dem erwarteten XML/Proto-Format generiert. Umgekehrt kann man CoT-Daten von ATAK abgreifen, um sie in anderen Anwendungen weiterzuverwenden (z.B. Lagebildübertragung in eigene Software). Use Case: Ein einfaches Node-RED-Flow oder ein Python-Skript könnte z.B. periodisch CoT-XML mit GPS-Koordinaten eines Trackers generieren, um diesen als „virtuellen Teilnehmer“ im ATAK-Netz anzuzeigen. Da CoT gut dokumentiert und standardisiert ist, existieren Bibliotheken für verschiedene Sprachen (z.B. node-cot in JavaScript oder takproto in Python) zur Serialisierung/Deserialisierung von CoT-Nachrichten. Zusätzlich implementieren manche TAK-Server (insb. der Open-Source FreeTAKServer) eine REST-API, über die Drittanwendungen beispielsweise neue Ziele oder Nachrichten einstellen können – dies wird als benutzerfreundliche Alternative zur direkten CoT-UDP/TCP-Einspeisung angeboten. Der übliche Datenpfad bleibt aber CoT; die REST-API beim Server wandelt Anfragen letztlich auch in CoT-Events für die Clients um.

2. ATAK-Plugin-API: Für tiefergehende Integration und Erweiterung von ATAK selbst stellt die Plattform eine interne API im Rahmen des Plugin-SDK bereit. Ein Plugin läuft innerhalb der ATAK-App und kann auf Funktionen und Events des ATAK-Core zugreifen. Technisch implementiert ATAK dies über ein Event-Bus ähnliches Muster und definierte Schnittstellenklassen. Zentrale Klassen sind u.a. der ToolDropDownReceiver (oder kurz DropDownReceiver) und MapComponent, welche im Plugin-Code abgeleitet werden. Der MapComponent fungiert als Einstiegspunkt des Plugins, wird beim Laden initialisiert und kann z.B. UI-Komponenten (Tools, Overlays) registrieren. Der DropDownReceiver ist als Broadcast-Receiver implementiert und empfängt ATAK-spezifische Broadcast-Events (z.B. Benutzeraktionen oder Systemereignisse) – über seine onReceive-Methode verarbeitet das Plugin diese und kann darauf reagieren. ATAK stellt über seine API zahlreiche Services zur Verfügung, etwa um auf die Kartenanzeige zu zeichnen, Marker hinzuzufügen, auf das interne Datenmodell (CoT-Events) zuzugreifen oder Netzwerk-Nachrichten zu versenden. So kann ein Plugin beispielsweise programmatisch ein neues Objekt erzeugen und auf der Karte publizieren, indem es einen CoT-Event über den internen Dispatcher einspeist. Listing 1 zeigt einen vereinfachten Codeausschnitt (Kotlin/Java) eines Plugins, das einen CoT-Marker erzeugt und lokal der ATAK-App hinzufügt:

// Innerhalb eines ATAK-Plugins: Erstellen eines CoT-Events und Dispatch im lokalen Client
CotEvent cot = new CotEvent();
cot.uid   = "Demo-1";                        // eindeutige ID
cot.type  = "a-f-G-U-C";                     // CoT-Typ (hier z.B. "friendly Ground Unit, Unit, Civilian")
cot.time  = new CoordinatedTime();           // aktuelle Zeitstempel
cot.start = cot.time;
cot.stale = cot.time.addMinutes(5);          // Gültigkeit 5 Minuten
cot.how   = "m-g";                           // how = Methode der Positionsbestimmung (z.B. m-g = GPS)
cot.setPoint(new CotPoint(50.775, 6.083, 0.0, 50.0, 50.0));  // Position (lat, lon, hae, ce, le)
CotMapComponent.getInternalDispatcher().dispatch(cot);       // Event intern verteilen (auf Karte anzeigen)

Der Code nutzt ATAK-Klassen (CotEvent, CotPoint, CotMapComponent) aus dem SDK. Zunächst wird ein neuer Event erstellt, diverse Attribute gesetzt (siehe CoT-Protokoll), dann über den internen Dispatcher publiziert. Die Folge: Der eigene ATAK-Client rendert das Ereignis sofort im Kartenbild (hier z.B. als Symbol einer „freundlichen Einheit“ gemäß Typcode). Bei Bedarf würde ATAK diesen Event auch an verbundene Peers/Server weiterleiten, sofern er nicht als rein lokal markiert ist. Dieses Beispiel illustriert, wie Plugins die ATAK-Funktionen programmatisch nutzen können – etwa um externe Datenquellen einzubinden (Drohnentelemetrie, IoT-Sensoren) oder neue Werkzeuge zu implementieren. So hat ein Community-Plugin beispielsweise Mavlink-Drohnensteuerung integriert, indem es über das Plugin die Drohnenpositionen als CoT einspielt und Steuerschnittstellen anbietet.

Zusätzlich zur CoT- und Plugin-Schnittstelle unterstützt ATAK auch klassische Datei-Interfaces: Über den Overlay Manager können Nutzer KML-, KMZ- oder GPX-Dateien importieren, und sogenannte Data Packages ermöglichen das Bündeln von Layern, Schlüsseldateien oder Missionsdaten in einem Paket zur Verteilung an andere (z.B. per Datei oder Server). Diese Mechanismen sind jedoch eher für Endanwender und Datenaustausch gedacht und weniger API für Entwickler, werden daher hier nur der Vollständigkeit halber erwähnt. Zusammenfassend stehen Entwicklern somit insbesondere CoT (für lose Kopplung externer Systeme) und das ATAK Plugin SDK (für enge Integration mit voller Funktionalität) als hauptsächliche Schnittstellen zur Verfügung.

Plugin-Entwicklung

Die Entwicklung eigener Plugins für ATAK/CivTAK ist ein zentraler Weg, die Plattform zu erweitern und auf spezifische Anforderungen zuzuschneiden. ATAK bietet hierfür ein offizielles Plugin Development Kit (SDK) und Vorlagen, mit denen Entwickler relativ zügig eigene Erweiterungen erstellen können. Im Folgenden die wichtigsten Schritte und Aspekte der Plugin-Entwicklung:

• SDK und Entwicklungsumgebung: Der Quellcode von ATAK-CIV ist frei verfügbar (GitHub), ebenso stellt das TAK Product Center ein Plugins SDK bereit. Entwickler laden das ATAK-CIV Projekt bzw. das SDK-Paket, welches Beispiel-Plugins (HelloWorld etc.) und benötigte Bibliotheken enthält. Es empfiehlt sich die Verwendung von Android Studio als IDE. Nach Einrichten des Projekts (Import der Plugin-Template als Modul und Verweis auf das ATAK SDK im local.properties) kann man die Beispielplugins kompilieren und auf einem Android-Gerät testen. Wichtig: Für Entwicklung ist es ratsam, eine spezielle Debug-Build von ATAK zu nutzen (im SDK enthalten oder via civTAK.org erhältlich), da die Play-Store-Version ggf. signierte Plugins erwartet.
• Projektstruktur eines Plugins: Ein ATAK-Plugin ist im Grunde eine eigenständige Android-App (APK), die jedoch keine eigene UI im Launcher hat, sondern von ATAK geladen wird. Die Plugin-Vorlage enthält typischerweise zwei zentrale Klassen, z.B. PluginTemplateDropDownReceiver und PluginTemplateMapComponent (Namen variieren je nach Vorlage). Diese leiten von den ATAK-Basisklassen ab und werden über Einträge in der AndroidManifest.xml des Plugins vom ATAK-Core erkannt. Wenn der Nutzer in ATAK das Plugin aktiviert (Plugins werden meist automatisch erkannt, z.B. anhand Paketname oder Manifest), instanziert ATAK den MapComponent des Plugins. Darin registriert das Plugin z.B. neue Menüeinträge (Dropdown-Buttons in der ATAK Toolbar) oder Overlays. Der DropDownReceiver empfängt Klicks auf diese Plugin-UI-Elemente und kann daraufhin Logik ausführen. Plugins können auch Hintergrund-Services nutzen oder eigene Activities starten, die in ATAK als Fenster eingebettet erscheinen.
• Nutzung der ATAK-API: Innerhalb des Plugins kann man auf zahlreiche Funktionen der Kern-App zugreifen. Dies erfolgt über vom ATAK-Core bereitgestellte Manager- und Helper-Klassen (im SDK in Form von JARs oder Maven-Dependencies eingebunden). Beispiele: Der MapView-Zugriff, um Grafiken zu zeichnen; der MissionPackageUtils, um Datenpakete zu erzeugen; der GeoChat-Service, um Programmatisch Nachrichten an den Chat zu senden; oder auch direkte Nutzung der CoT-Klassen, wie in Listing 1 gezeigt. Die Dokumentation im Plugin Development Guide (PDF im SDK) erläutert die wichtigsten Klassen und Lifecycle-Hooks. Da ATAK auf Android basiert, gelten viele übliche Android-Entwicklungsmuster (Activity-Lifecycle, Permissions etc.) eingeschränkt auch im Plugin – allerdings laufen Plugins im Kontext der ATAK-App, nicht als vollwertige unabhängige App. Entwickler müssen z.B. beachten, UI-Aktionen im richtigen UI-Thread/Context durchzuführen (Map-UI vs. Plugin-Context).
• Tools und Debugging: Für die Entwicklung hilft es, ATAK-Logs zu beobachten. ATAK loggt viele Ereignisse (auch Plugin-Events) über Android’s Logcat. Im SDK-Dokument sind Filter angegeben, um relevante Logs (z.B. alle atak-Tags) anzuzeigen. Da Plugins gemeinsam mit ATAK laufen, können sie im Debugger von Android Studio angehängt werden, sobald ATAK mit dem Plugin gestartet ist.
• Beispiele und Vorlagen: Das offizielle SDK enthält ein HelloWorld-Plugin, das minimal demonstriert, wie ein Plugin einen Button hinzufügt und eine Toast-Nachricht anzeigt. Von dort aus können Entwickler schrittweise komplexere Funktionen einbauen. Es existieren Community-Tutorials – etwa eine RIIS-Workshopserie – die anhand von Beispielen (z.B. Integration eines MAVLink-Drohnenfeeds) die Entwicklung nachzeichnen. Zudem stellt die Open-Source-Community Plugins bereit, deren Quellcode als Lernvorlage dienen kann (z.B. CloudRF’s SOOTHSAYER-Plugin für ATAK auf GitHub oder das atak-forwarder LoRa-Plugin).
• Verteilung und Installation: Fertige Plugins können als normale APKs verteilt werden. CivTAK-Nutzer können ein Plugin-APK einfach via Dateiinstallation hinzufügen; ATAK erkennt das Plugin und es erscheint in der Plugin-Liste. Einige zivil nutzbare Plugins werden sogar über den Google Play Store angeboten – z.B. das WASP-Plugin (Wide Area Search Planning) oder HAMMER (ein akustisches Modem-Plugin für Funkgeräte). Militärisch genutzte Plugins werden meist über die behördliche Plattform TAK.gov bereitgestellt (nur für berechtigte Nutzer). Bei der Entwicklung sollte man im Hinterkopf behalten, dass Kompatibilität mit zukünftigen ATAK-Versionen wichtig ist – die Plugin-API kann sich ändern, daher werden Plugins i.d.R. neu kompiliert, wenn eine neue ATAK-Version erscheint (das TAK Produkt Center bemüht sich aber um Rückwärtskompatibilität).

Zusammengefasst erlaubt die Plugin-Architektur es Entwicklern, maßgeschneiderte Erweiterungen für ATAK/CivTAK zu entwickeln – von der Integration spezieller Kommunikations-Hardware, über die Einbindung proprietärer Datenbanken bis hin zur Implementierung komplett neuer Funktionen im UI. Durch das bereitgestellte SDK und die aktive Community ist der Einstieg erleichtert, sodass ATAK inzwischen eine breite Palette an Plugins in verschiedenen Domänen vorweisen kann (viele davon Open-Source oder als Referenz verfügbar).

Sicherheitsmechanismen

ATAK/CivTAK wird häufig in sicherheitskritischen Umgebungen eingesetzt, daher spielen Sicherheitsmechanismen auf mehreren Ebenen eine Rolle: (a) Sicherung der Kommunikation (Netzwerkverschlüsselung, Authentisierung), (b) Zugriffsschutz und Rollen, sowie (c) Schutz lokal gespeicherter Daten auf dem Gerät.

Netzwerkverschlüsselung und -sicherheit: Von Haus aus verschickt ATAK CoT-Nachrichten im Klartext über IP-Netzwerke (UDP/TCP) – das Protokoll selbst bringt also zunächst keine eigene Ende-zu-Ende-Verschlüsselung mit. Die Sicherheit der Datenübertragung hängt daher stark vom eingesetzten Transportmedium ab. In militärischen Szenarien läuft ATAK typischerweise über bereits geschützte Funknetze oder VPN-Tunnel. Für zivile Nutzer gibt es Empfehlungen, z.B. ein ZeroTier-VPN für Teamkommunikation einzurichten, um CoT-Daten verschlüsselt über das Internet zu senden.

Ab ATAK CIV 4.0 wurde eine eingebaute Ende-zu-Ende-Verschlüsselung für Ad-hoc/Mesh-Netzwerke ergänzt: Hierbei können Benutzer optional einen AES-256-Schlüssel generieren und mit Teammitgliedern teilen, so dass CoT-Daten im lokalen Netzwerk verschlüsselt ausgetauscht werden () (). Sobald alle beteiligten Geräte den gleichen Schlüssel geladen haben, akzeptieren sie nur noch verschlüsselte CoT-Nachrichten voneinander; Geräte ohne Schlüssel sind ausgeschlossen () (). Diese AES-Mesh-Verschlüsselung stellt sicher, dass selbst auf einem unsicheren Funkkanal (z.B. MANET ohne VPN) die Positionsdaten, Chats etc. nicht im Klartext mitgelesen werden können. Die Konfiguration erfolgt in den ATAK-Einstellungen unter Configure AES-256 Mesh Encryption und ermöglicht das Erzeugen eines Schlüssels (Key-Datei), der dann per Data Package oder Vorab-Verteilung auf alle Geräte gebracht wird (). Für Verbindungen zwischen ATAK-Clients und einem zentralen TAK-Server wird üblicherweise TLS/SSL eingesetzt – der offizielle TAK-Server unterstützt verschlüsselte WebSocket/SSL-Verbindungen. Laut Dokumentation implementiert der TAK-Server „verschlüsselte Datenübertragung“ und Zugriffskontrolle, was in der Praxis TLS (für Daten im Transit) und Authentifizierung bedeutet. Der Server kann so konfiguriert werden, dass Clients nur mit gültigen Zertifikaten oder Zugangstokens eine Verbindung herstellen können (Client-Auth). Zudem erlauben VPN- oder private APN-Lösungen im behördlichen Umfeld eine zusätzliche Abschottung des TAK-Verkehrs. Wichtig ist: ATAK selbst verschlüsselt CoT-Daten nur, wenn man es konfiguriert oder ein sicheres Transportmittel nutzt – out-of-the-box versendet CivTAK im lokalen Netz unverschlüsselt, lässt dem Nutzer aber die Wahl, Sicherheitsmaßnahmen zu aktivieren.

Authentifizierung und Zugriffskontrolle: Im reinen Peer-to-Peer-Einsatz gibt es innerhalb von ATAK keine Benutzer-Authentifizierung – jeder, der in das Mesh-Netz gelangt (und den evtl. gesetzten AES-Key hat), sieht alle Daten. In Server-basierten Setups hingegen meldet sich jeder Benutzer am TAK-Server mit einem Account an. Der Server verwaltet Benutzerkonten, Gruppen und Rollen. So kann z.B. gesteuert werden, welche Informationen welcher Nutzer sehen oder senden darf (Role-Based Access Control). Beispielsweise könnten bestimmte CoT-Events als nur für Führungskräfte sichtbar markiert werden. Der TAK-Server 5.x unterstützt solche Rollen und Filterregeln. Außerdem protokolliert der Server Zugriffe, so dass ein Audit Trail entsteht, wer wann welche Daten geschickt/empfangen hat.

Lokaler Datenschutz: Wenn CivTAK erstmals gestartet wird, generiert die App automatisch eine Verschlüsselungs-Passphrase zur Sicherung lokaler Dateien (). Diese Passphrase (vom Nutzer änderbar) wird genutzt, um z.B. gecachte Karten, gespeicherte Missionsdaten oder Einstellungen auf dem Gerät verschlüsselt abzulegen. So soll verhindert werden, dass bei Verlust des Geräts sensible Einsatzdaten ausgelesen werden können. Der Mechanismus arbeitet transparent im Hintergrund. Zusätzlich bietet ATAK die Möglichkeit, über Wipe oder Clear Data schnell alle gespeicherten Inhalte zu löschen.

Weiteres: ATAK selbst läuft als normale App auf Android, d.h. es profitiert auch von den Sicherheitsfunktionen des OS (Sandboxing, Berechtigungen). Beispielsweise müssen Plugins signiert sein bzw. die App muss dem Laden unsignierter Plugins explizit zustimmen (eine Maßnahme, um unautorisierte Code-Injektion zu verhindern). Insgesamt verfolgt das TAK-Ökosystem ein Konzept, bei dem Transport-Sicherheit oft auf Netzwerkebene (VPN, TLS) angesetzt wird und Inhalts-Sicherheit durch Verschlüsselung auf Anwendungsebene optional ergänzt werden kann. Für maximalen Schutz empfiehlt das TAK-Best-Practice daher eine Kombination: gesicherte Netzwerkkanäle (z.B. VPN), starke Authentifizierung der Nutzer, aktivierte AES-Verschlüsselung für CoT und physischer Geräteschutz. In der militärischen Version von ATAK kommen gegebenenfalls noch spezielle zertifizierte Verschlüsselungs-Module (Type1 Krypto) hinzu, die in CivTAK nicht enthalten sind – hierzu gibt es öffentlich jedoch kaum Informationen, da diese Komponenten unter ITAR/Beschränkungen fallen.

Cursor-on-Target (CoT)-Protokoll

Das Cursor-on-Target (CoT)-Protokoll bildet das Rückgrat der Datenkommunikation im TAK-Ökosystem. Es handelt sich um ein ursprünglich von MITRE entwickeltes XML-basiertes Nachrichtenformat, das eine gemeinsame „Sprache“ schafft, um zeitkritische Ziele und Positionsdaten zwischen Systemen auszutauschen (Cursor on Target: Research for a Sensor Network – PMC). ATAK und alle anderen TAK-Clients (WinTAK, iTAK, etc.) verwenden CoT, um Informationen wie Standort, Bewegungsrichtung, Ereignistyp, Nachrichten und vieles mehr in standardisierter Form zu kodieren und zu teilen.

Nachrichtenstruktur: Eine CoT-Nachricht besteht typischerweise aus einem einzigen XML-Element <event> mit verschiedenen Attributen und Unterelementen. Ein Beispiel für ein CoT-Event (stark vereinfacht) ist in Listing 2 dargestellt:

<event version="2.0" uid="UID12345" type="a-f-G-U-C" time="2025-02-26T17:30:00Z" start="2025-02-26T17:30:00Z" stale="2025-02-26T17:35:00Z" how="m-g">
    <point lat="50.7762" lon="6.0838" hae="123.0" ce="5.0" le="10.0"/>
    <detail>
        <contact callsign="Alpha1"/>
        <usericon iconsetpath="apps://icons/alpha.png"/>
    </detail>
</event>

Beispiel einer CoT-XML-Nachricht (freundliche Einheit „Alpha1“ mit Position)

Jedes event hat obligatorische Attribute:

• uid: eindeutige Kennung des Events (z.B. Geräteseriennummer, Rufzeichen o.Ä.). Damit werden Aktualisierungen bestehender Objekte erkannt.
• type: Typ des Ereignisses, kodiert als hierarchischer String. Das erste Zeichen steht für die Kategorie (z.B. a = „Atom“ für physische Objekte). Es folgen durch Bindestrich getrennte Kürzel für Feind/Freund, Domäne, und ggf. weitere Untertypen. Im obigen Beispiel a-f-G-U-C steht dies für atom-friend-Ground-Unit-Civilian (freundliche Bodeneinheit, Zivilist). Viele dieser Typ-Codes lehnen sich an den Militärstandard MIL-STD-2525 (NATO-Symbole) an, was eine konsistente Darstellung auf der Karte ermöglicht (FTS Documentation).
• time, start, stale: Zeitstempel. time ist die Erstellungszeit des Events, start der Beginn der Gültigkeit (oft identisch mit time) und stale das Ablaufdatum, wann das Event als veraltet betrachtet wird und vom System entfernt werden kann. Dadurch hat jedes Objekt eine definierte Lebensdauer, was wichtig ist für temporäre Ereignisse (z.B. Position eines beweglichen Ziels, die nach X Sekunden ohne Update als „nicht mehr vertrauenswürdig“ markiert wird).
• how: (optional) Gibt an, wie die Information erhoben wurde – z.B. m-g für „militärisch GPS“ oder h-e für „von Hand eingegeben“ (human-entered). Dies kann die Zuverlässigkeit oder Quelle andeuten.

Unterelemente:

• : Enthält die geographische Position und Genauigkeit. Attribute sind lat (Breitengrad), lon (Längengrad), hae (Höhe über Ellipsoid, in Meter), ce (Kreisfehlerradius, m – also horizontaler Genauigkeitsradius) und le (Linearerror, m – vertikale Ungenauigkeit). Im Beispiel hat Alpha1 eine Höhe von 123 m, und die Positionsgenauigkeit beträgt 5 m horizontal / 10 m vertikal.
• : Hier können zusätzliche Details als strukturierte Unterelemente stehen. Dies ist ein flexibles Feld, das je nach Event-Typ unterschiedliche Informationen enthalten kann. Im Fall von Positions-/Identifikationsereignissen sind übliche Detail-Einträge: <contact> mit Attributen wie callsign (Rufzeichen/Name des Nutzers), <remarks> für Freitext-Bemerkungen, <group> für Team-Zugehörigkeit, <status> (z.B. ack/nack, Activity-Status) u.v.m. Im Beispiel enthält das Detail den Kontakt „Alpha1“ sowie einen usericon-Eintrag, der einen bestimmten Icon-Pfad angibt (für benutzerdefinierte Symbole). Das Detail-Element ist extensibel – so werden etwa Chat-Nachrichten, Video-Streams oder Sensorwerte ebenfalls im Detail-Block spezifiziert (oft mit eigenen XML-Namensräumen je nach Datenart).

Ein minimales CoT-Event kann auch ganz ohne Detail auskommen, wie das MITRE-Beispiel eines einfachen Punktes zeigt. Häufig nutzen ATAK-Plugins das Detail-Element, um proprietäre payloads oder Flags unterzubringen, solange alle Clients diese interpretieren können.

Verteilung und Transport: CoT-Meldungen werden in ATAK entweder per UDP-Broadcast/Multicast (für Mesh/Team direkt) oder per TCP/SSL an einen Server gesendet, der sie dann an andere weiterverteilt. Frühe Versionen von ATAK nutzten ausschließlich XML; neuere Versionen unterstützen auch eine Binary-COT-Variante auf Basis von Google Protocol Buffers (genannt TAK Proto oder CoT Proto) (TAK Protocol Description – Encode and Decode TAK data with Python). Dabei werden die gleichen Felder in ein kompaktes Binärformat gegossen, was die Bandbreite schont und die Parsing-Geschwindigkeit erhöht. ATAK 4.0+ sendet z.B. im Standard-„Mesh SA“-Modus CoT-Meldungen als Protobuf mit einem festen Header (191 Byte), während im Server-Stream-Modus ein variabler Längenheader genutzt wird. Für Entwickler heißt das: Die Integration kann entweder mit dem XML-Format (leicht test- und lesbar) oder dem Proto-Format (effizienter, erfordert aber das .proto-Schema) erfolgen – beide sind interoperabel und vom Inhalt identisch.

Anwendungsfälle: CoT wurde entworfen, um sehr vielfältige Ereignisse abbilden zu können. Neben Positionspunkten können auch Gebiete (Polygone), Routen (Polylinien), Sensor-Spuren oder Missionsaufträge als CoT-Events modelliert werden (dann meist mit komplexeren Detail-Blöcken oder Verweis auf externe Dateien). ATAK nutzt CoT nicht nur für tracking, sondern auch für Dinge wie das Versenden von Chat-Nachrichten (im Detail steht dann z.B. <chat> mit Textinhalt) oder das Auslösen von Alarmevents. Durch die lose Kopplung via CoT können auch andere Systeme – sofern sie das Protokoll sprechen – Teil des Netzwerks werden, ohne ATAK-Plugin. Beispielsweise existieren IoT-Sensor-Plattformen, die Ereignisse (etwa Schusserkennung) direkt als CoT publizieren, woraufhin sie in ATAK aufpoppen.

Zusammengefasst bietet Cursor-on-Target ein einheitliches, ereignisbasiertes Datenformat für die Echtzeit-Interoperabilität zwischen verschiedensten Geräten und Anwendungen. Die Standardisierung (XML-Schema verfügbar) und breite Nutzung in Militär und zivilen BOS macht CoT zu einem Schlüsselprotokoll für Lageinformationssysteme. ATAK selbst hat CoT stark popularisiert, da es zeigt, wie mächtig ein gemeinsames Schema sein kann, um „Jeder mit Jedem“ Daten auszutauschen.

Unterschiede zwischen ATAK und CivTAK

Die militärische ATAK-Version und die zivile CivTAK-Version basieren auf der gleichen Codebasis und sind funktional größtenteils identisch. CivTAK wurde aus ATAK herausgelöst, um eine Version zu haben, die frei verbreitet und von zivilen Behörden, Organisationen und Privatpersonen genutzt werden kann, ohne Exportbeschränkungen. Technisch gibt es nur geringfügige Unterschiede:

• Verfügbare Funktionen/Plugins: Bestimmte militärspezifische Funktionen sind in CivTAK nicht enthalten oder standardmäßig deaktiviert. Beispielsweise könnte ATAK (Mil) zusätzliche Plugins für Waffenwirkung, militärische Sensoren oder verschlüsselte Funkgeräte enthalten, die CivTAK fehlen. Die Entwickler geben an, dass es nur „kleine, militär-spezifische Add-ons“ in der militärischen Version gibt. Dies können z.B. spezifische Symbolsets oder Integrationen sein, die für Zivilnutzer keine Rolle spielen. Ein Indiz: Im öffentlichen ATAK-CIV Quellcode finden sich teils Funktionen, die (noch) nicht über die UI zugänglich sind (The TAK Ecosystem: Military Coordination Goes Open Source | Hackaday) – möglicherweise, weil sie nur für Militär relevant sind. Die Kernfeatures wie Karten, Navigation, CoT, Plugin-Schnittstelle etc. sind aber identisch.
• Sicherheitsmodule: Wie erwähnt, nutzt CivTAK ausschließlich kommerzielle/öffentlich erlaubte Kryptografie (AES-256, TLS). Hochgeheime Verschlüsselungsmodule der Militärversion (z.B. für NATO-Geheimschutz) sind in CivTAK nicht vorhanden. Stattdessen muss man sich in CivTAK mit AES und VPN behelfen, was aber für die meisten Anwendungen ausreichend ist. ATAK-Mil könnte darüber hinaus mit speziellen Hardware-Geräten (Krypto-Chips, sicheren Funkgeräten) gekoppelt sein – diese Schnittstellen sind in CivTAK nutzlos und daher ausgelassen.
• Namensgebung und Symbolik: In der Außendarstellung wird ATAK für Militär oft als „Assault Kit“ bezeichnet, während CivTAK als „Team Awareness Kit“ firmiert. Innerhalb der App sind jedoch Begriffe und Symbole weitgehend gleich. Militärische Einheiten werden in CivTAK mit den gleichen MIL-STD-2525 Symbolen dargestellt; die App verzichtet aber auf kampfbezogene Bezeichnungen. Man hat also nicht das Gefühl einer „abgespeckten“ Version – CivTAK ist ATAK, nur offiziell freigegeben für zivile Nutzung.
• Versionierung und Veröffentlichung: ATAK (mil) wird durch die TAK Product Center an berechtigte Nutzer verteilt (über TAK.gov), CivTAK hingegen ist offen verfügbar (Download via civtak.org, Google Play Store, GitHub). Seit 2020 erscheinen CivTAK-Versionen meist kurz nach den TAK.gov-Releases, sodass beide weitgehend synchron sind. Beispielsweise wurde ATAK-CIV Version 4.3 öffentlich kurz nach ATAK-Mil 4.3 freigegeben. Die Open-Source-Veröffentlichung von ATAK-CIV hat den Vorteil, dass Community-Beiträge einfließen können – allerdings entscheidet das TAK Program Office, welche Änderungen in den offiziellen Build übernommen werden.
• Unterstützung und Nutzung: ATAK-Mil wird vor allem von US- und verbündeten Militärnutzern in Übungen und Einsätzen verwendet; CivTAK hat eine wachsende Nutzerbasis bei US-Behörden (Feuerwehr, Polizei, Katastrophenschutz) und auch Privatnutzern (z.B. Jäger, Wanderer). Beide Varianten können aber miteinander kommunizieren – ein Feuerwehr-Team auf CivTAK kann z.B. mit Soldaten auf ATAK (Mil) an gemeinsamen CoT-Servern Lagebilder teilen, solange sie die gleichen Netzwerkschlüssel/Certs nutzen.

Im Fazit sind ATAK und CivTAK technisch nahezu gleichwertig, sodass Entwickler, die Plugins für CivTAK entwickeln, diese mit minimalen Anpassungen auch im militärischen ATAK nutzen könnten. Der größte Unterschied liegt in der Vertriebs- und Lizenzfrage: CivTAK ist Open-Source (teilweise Public-Domain) während die militärische ATAK-Version Government-off-the-shelf (GOTS) ist und nur mit Zustimmung genutzt werden darf. Für die meisten Entwicklungszwecke reicht CivTAK völlig aus – sollte ein Plugin allerdings hochspezialisierte militärische Hardware ansprechen, müsste dies in Kooperation mit den militärischen Entwicklern erfolgen.

Open-Source-Ressourcen & SDKs

Die Öffnung von ATAK-CIV hat eine engagierte Entwicklergemeinschaft hervorgebracht. Es existieren zahlreiche Open-Source-Ressourcen, SDKs und Community-Projekte, die den Einstieg erleichtern und die Möglichkeiten erweitern:

• ATAK-CIV Quellcode: Der offizielle Code ist auf GitHub (Dept of Defense Repository) einsehbar (GitHub – deptofdefense/AndroidTacticalAssaultKit-CIV). Dort findet man auch eine vorgefertigte Plugin SDK ZIP mit Template-Code (GitHub – deptofdefense/AndroidTacticalAssaultKit-CIV). Die README und CONTRIBUTING-Dateien geben Hinweise zum Build-Prozess (GitHub – deptofdefense/AndroidTacticalAssaultKit-CIV). Entwickler können den Code studieren, um versteckte Features oder API-Details zu verstehen – es gibt z.B. Kommentare zu TAK Protocol v1 (ProtoBuf) im Code (TAK Protocol Description – Encode and Decode TAK data with Python). Lizenzrechtlich ist viel des Codes Public Domain (US Govt Work) oder unter einer liberalen Lizenz, was freie Weiterentwicklung ermöglicht (GitHub – deptofdefense/AndroidTacticalAssaultKit-CIV).
• TAK Server (Open Source): Auch der TAK Server wurde 2020 open-sourced. Der Java-basierte Server ist auf GitHub verfügbar (The TAK Ecosystem: Military Coordination Goes Open Source | Hackaday) und kann von Organisationen selbst gehostet werden. Für leichtere Alternativen sorgen Community-Projekte: FreeTAKServer (FTS) in Python ist ein schlanker Server mit REST-API und einfacher Installation (The TAK Ecosystem: Military Coordination Goes Open Source | Hackaday) (TAK Server open apis : r/ATAK). Taky ist ein weiterer minimaler TAK-Server (ebenfalls Python) für z.B. Raspberry Pi Deployments (The TAK Ecosystem: Military Coordination Goes Open Source | Hackaday). Diese Projekte sind ideal, um Tests durchzuführen oder eigene Integrationen (via API) zu bauen, ohne auf den großen offiziellen Server angewiesen zu sein.
• Dokumentation & Community-Wikis: Offizielle Endnutzer-Dokumente (z.B. das ATAK User Manual () ()) und Plugin-Entwicklerhandbücher sind vorhanden. Die Community unterhält zudem ein Wiki (CivTAK JumpStart) auf Reddit (GitHub – FreeTAKTeam/openTAKpickList: a list of hardware and software to be used in conjunction with ATAK platform) mit How-Tos und FAQs. Auf civtak.org gibt es eine Dokumentationssektion mit Tutorials, z.B. zum Erstellen von Data Packages (Documentation – CivTAK / ATAK). Die FreeTAKTeam (FTS) stellt auf ihrer GitHub-Seite ebenfalls Dokus bereit, z.B. zum MIL-STD-2525 Symbolsatz und CoT-Typen (FTS Documentation) (FTS Documentation), was für Entwickler hilfreich ist, die eigene Symbole oder Typen nutzen wollen.
• Entwickler-Communities: Es existiert ein reger Austausch über Reddit (r/ATAK) (TAK Server open apis : r/ATAK) und Discord (TAK Community Server) (Android Team Awareness Kit or ATAK / CivTAK – CivTAK / ATAK), wo Entwickler Fragen stellen und Lösungen teilen. Ebenfalls finden seit 2020 jährliche OpenTAK-Konferenzen statt (Android Team Awareness Kit or ATAK / CivTAK – CivTAK / ATAK), in denen neue Plugins, Anwendungsfälle und Best Practices vorgestellt werden.
• Open-Source-Plugins und Tools: Viele Plugins wurden quelloffen veröffentlicht oder inoffiziell nachimplementiert. Beispiele: atak-forwarder (GitHub) ermöglicht die Anbindung von ATAK an LoRa-Meshtastic Funkmodule (The TAK Ecosystem: Military Coordination Goes Open Source | Hackaday). HAMMER – das akustische Modem für Sprechanlagen – wurde als Code veröffentlicht, um CoT über Audio zu senden (The TAK Ecosystem: Military Coordination Goes Open Source | Hackaday). APRS-TAK verbindet ATAK mit dem Amateurfunk-Positionssystem APRS (The TAK Ecosystem: Military Coordination Goes Open Source | Hackaday). Weiter gibt es Visualisierungs- und Analysewerkzeuge, z.B. TAK Reader zum Offlinesichten von CoT-Daten, TAK Graph für Verbindungsdiagnose usw. Eine von der Community gepflegte openTAK-PickList sammelt über 100 Links zu TAK-bezogenen Ressourcen, Plugins, Hardware und Tutorials (GitHub – FreeTAKTeam/openTAKpickList: a list of hardware and software to be used in conjunction with ATAK platform) (GitHub – FreeTAKTeam/openTAKpickList: a list of hardware and software to be used in conjunction with ATAK platform). Diese Liste ist ein guter Startpunkt, um sich einen Überblick zu verschaffen.
• SDKs und Bibliotheken: Neben dem offiziellen ATAK-Plugin-SDK existieren Bibliotheken, um CoT/TAK-Daten in anderen Umgebungen zu verarbeiten. TakProto (Python) erlaubt das Encoden/Decoden von CoT sowohl in XML als auch in Proto-Format (dfpc-coe/node-CoT: Javascript Cursor-On-Target Library – GitHub). Node-CoT (JavaScript) ähnliches für Node.js-Anwendungen (About MIL-STD-2525 and CoT – FreeTAKTeam). Für .NET gibt es CoT-Parser und sogar Ansätze, Teile der Funktionalität von ATAK nachzubilden (z.B. WinTAK als Windows-App wird vom DoD bereitgestellt, und eine Community-Version namens ITAK (unrelated to iOS) etc.).
• Karten und Daten: Open-Source-Tools erleichtern das Laden zusätzlicher Geo-Daten in ATAK. Z.B. das ATAK-Maps-Projekt stellt eine Sammlung von Kartendiensten bereit, inkl. OpenStreetMap, Google Maps, Satellitendaten – einfach importierbar als Datenpaket (The TAK Ecosystem: Military Coordination Goes Open Source | Hackaday). OpenElevation-Datensätze können ebenfalls eingebunden werden (The TAK Ecosystem: Military Coordination Goes Open Source | Hackaday). Dadurch können Entwickler/Nutzer das volle Potential der Kartenengine ausschöpfen, ohne auf proprietäre Daten angewiesen zu sein.

Mit diesen Ressourcen ausgestattet, kann ein Entwickler relativ autonom im TAK-Ökosystem arbeiten: vom Aufsetzen einer eigenen Server-Infrastruktur über das Bauen von Plugins bis zum Testen mit anderen Community-Mitgliedern. Die Offenheit von CivTAK fördert Innovation – so entstehen ständig neue Plugins und Integrationen, die wiederum zurück an die Community gegeben werden. Für Entwickler, die eigene Erweiterungen schreiben wollen, sind insbesondere das ATAK Plugin SDK, die offiziellen Beispiele und der Austausch mit erfahrenen Plugin-Entwicklern wertvoll. Die Kombination aus einer stabilen Kernplattform (ATAK) und der Flexibilität von Open-Source-Plugins macht das System einzigartig in diesem Anwendungsbereich und ermöglicht es, komplexe Lageinformations-Anwendungen mit vergleichsweise geringem Aufwand zu realisieren.