Feldanwendungen

Blue Force Tracking auf Android: ATAK, CoT und Netzarchitektur

Von Corvus Intelligence Engineering Team · Über das Team →

25. Juni 2026 11 Min. Lesezeit

Blue Force Tracking (BFT) ist eine der folgenreichsten Fähigkeiten, die ein abgesessener Verband mitführen kann: die Möglichkeit, in nahezu Echtzeit zu sehen, wo sich jedes eigene Element auf der Karte befindet. Jahrelang war diese Fähigkeit die exklusive Domäne teurer Spezialterminals. Android-basierte Plattformen mit ATAK (Android Team Awareness Kit) haben diese Gleichung verändert — ein robustes Smartphone oder Tablet mit einem MANET-Funkgerät liefert heute dauerhaftes BFT zu einem Bruchteil der Kosten der alten Hardware, mit einer offenen Plug-in-Architektur, die es ermöglicht, dass kundenspezifische Sensorfeeds, KI-Overlays und Missionsplanungswerkzeuge mit der Tracking-Schicht koexistieren. Dieser Artikel behandelt den gesamten BFT-Stapel: CoT-Positionsereignis-Schema, ATAK-SA-Konfiguration, TAK-Server-Feed-Verwaltung, MANET-Funk-Transportintegration, Profiling der Aktualisierungsrate vs. Akku und das Verhalten des Systems bei Verlust der Konnektivität.

BFT-Anforderungen für taktische Verbände

Bevor Sie Softwarekonfiguration angehen, erfordert eine BFT-Bereitstellung eine explizite Anforderungsgrundlage. Die Parameter, die jede nachfolgende Entscheidung steuern, sind Positionsgenauigkeit, Aktualisierungsfrequenz, Anzeigelatenz und die durch die eingesetzten Geräte und Funkgeräte auferlegten Einschränkungen.

Positionsgenauigkeit. BFT für abgesessene Infanterie zielt auf einen Circular Error Probable (CEP) von 10 Metern oder besser ab — ausreichend zur Entzerrung im urbanen Gelände, wo Gebäudeauflösung zählt. Fahrzeuggebundenes BFT akzeptiert typischerweise CEP 50 m. Android-Geräte mit Multi-Konstellations-GNSS (GPS + GLONASS + Galileo) erreichen im offenen Gelände 3–5 m CEP; dichter Bestand oder städtische Canyons verschlechtern dies ohne Augmentierung auf 15–30 m. SBAS (WAAS/EGNOS) unterstützt GNSS-Empfänger in ATAK-kompatiblen Geräten und verschärft die Genauigkeit in unterstützten geografischen Gebieten weiter.

Aktualisierungsfrequenz. Die Positionsaktualisierungsrate bestimmt, wie aktuell die Spuren auf den Karten benachbarter Verbände sind. Intervalle von 5–10 Sekunden sind Standard für Verbände in unmittelbarem Kontakt oder bei Operationen in unmittelbarer Nähe. Intervalle von 30–60 Sekunden sind für Verbände in Unterstützungs- oder Reservepositionen ausreichend. Die Aktualisierungsrate multipliziert direkt die Kanallast: Jede Verdoppelung der Verbände oder Halbierung des Aktualisierungsintervalls verdoppelt den Bandbreitenverbrauch im gemeinsamen Funknetz.

Anzeigelatenz. Die Ende-zu-Ende-Anzeigelatenz — vom auf dem Quellgerät erzeugten Positionsereignis bis zum Erscheinen der Spur auf allen verbundenen Anzeigen — muss für Operationen, bei denen die Entzerrung von Echtzeitpositionen abhängt, unter 3 Sekunden bleiben. Latenzbeiträge umfassen GPS-Fixzeit, CoT-Ereigniserzeugung, Funkübertragung, Serververarbeitung und Client-Rendering. In einem gut konfigurierten MANET mit lokalem TAK Server liegt die Gesamtlatenz typischerweise im Bereich 500 ms–1,5 s. Satelliten-Backhaul-Konfigurationen fügen 600 ms–1,2 s Verzögerung in einer Richtung hinzu.

Geräte- und Funkeinschränkungen. Robuste Android-Geräte für BFT — Samsung XCover Pro, Kyocera DuraForce Pro 2, Getac PS336 — tragen Akkus, die für 8–16-Stunden-Schichten ausgelegt sind, aber GPS- und Funkübertragungen belasten diese Kapazität stark. MANET-Funkgeräte verbinden sich typischerweise über USB-OTG oder WLAN-Hotspot; die Hotspot-Verbindung selbst fügt Antennen- und HF-Last hinzu. Thermische Grenzen in heißen Umgebungen reduzieren die dauerhafte Sendeleistung sowohl am Android-Gerät als auch am Funkgerät, was die effektive Reichweite senken und daher kürzere Aktualisierungsintervalle erfordern kann, um erhöhten Paketverlust auszugleichen.

Cursor-on-Target-(CoT)-Positionsereignisse

Der CoT-Standard definiert ein XML-Ereignis-Schema, das jedes Element im BFT-Netzwerk spricht. Das Verständnis des Schemas ist wesentlich für die Diagnose von BFT-Fehlern und für das Schreiben kundenspezifischer Plug-ins, die Positionsdaten injizieren oder verarbeiten.

CoT-XML-Schema für SA-Ereignisse

Ein minimales Positionsereignis einer eigenen Bodeneinheit sieht so aus:

<?xml version="1.0" standalone="yes"?>
<event version="2.0"
  uid="ANDROID-BFT-ALPHA-1"
  type="a-f-G-U-C"
  time="2026-06-25T08:30:00.000Z"
  start="2026-06-25T08:30:00.000Z"
  stale="2026-06-25T08:30:45.000Z"
  how="m-g">
  <point lat="49.8391" lon="24.0297"
         hae="320.0" ce="9.0" le="999999.0"/>
  <detail>
    <contact callsign="ALPHA-1"/>
    <uid Droid="ALPHA-1"/>
    <group name="Cyan" role="Team Member"/>
    <status battery="72"/>
    <track speed="1.4" course="045.0"/>
    <precisionlocation geopointsrc="GPS" altsrc="GPS"/>
  </detail>
</event>

Die Schlüsselfelder für BFT sind:

uid — eindeutiger Bezeichner für die Spur. Muss über Positionsaktualisierungen hinweg stabil bleiben; ATAK nutzt die IMEI des Geräts oder eine generierte UUID.
type — CoT-Typcode (siehe unten), der Zugehörigkeit, Dimension und Plattformtyp kodiert.
time / start — Zeitstempel der Ereigniserzeugung in ISO 8601 UTC. Die Uhrgenauigkeit ist hier kritisch: Uhrenversatz verursacht Stale-Ablehnung auf dem empfangenden Server.
stale — Zeitstempel, nach dem das Ereignis als abgelaufen gilt. ATAK setzt stale standardmäßig auf time + (Aktualisierungsintervall × 3), was drei verpasste Aktualisierungen lässt, bevor die Spur ausgegraut wird.
how — Eingabemethode für die Position: m-g (GPS des Geräts), h-g-i-g-o (manuell eingegebenes GPS), m-g-i (abgeleitetes GPS).
point — WGS84-Koordinaten: lat/lon in Dezimalgrad, hae (Höhe über dem WGS84-Ellipsoid) in Metern, ce (circular error) und le (linear error) in Metern.

CoT-Typcodes für freundlich, feindlich und neutral

CoT-Typcodes folgen einem hierarchischen Schema: a-[Zugehörigkeit]-[Gefechtsdimension]-[Funktion]. Für BFT ist das Zugehörigkeitszeichen der kritische Diskriminator:

Typpräfix	Zugehörigkeit	ATAK-Symbolfarbe	Beispiel
`a-f-`	Freundlich	Blau	`a-f-G-U-C` — freundliche Bodeneinheit, Kampf
`a-h-`	Feindlich	Rot	`a-h-G-U-C` — feindliche Bodeneinheit, Kampf
`a-n-`	Neutral	Grün	`a-n-G-E-V-C` — neutrales Bodenfahrzeug, zivil
`a-u-`	Unbekannt	Gelb	`a-u-G-U` — unbekannte Bodeneinheit

Stale-Timeout-Verwaltung

Der Stale-Zeitstempel ist der Hauptmechanismus zum Bereinigen der Spuren vom COP. Der Standard-Stale-Multiplikator von ATAK beträgt das 3-fache des konfigurierten SA-Aktualisierungsintervalls: Bei einer Aktualisierungsrate von 10 Sekunden wird stale 30 Sekunden in der Zukunft gesetzt. Wenn drei aufeinanderfolgende Positionsereignisse verloren gehen (Paketverlust, Funkausfall, Geräteabschaltung), geht die Spur in den Stale-Zustand über, und ATAK rendert sie mit ausgegrautem Symbol. Nach einer vom Bediener konfigurierbaren Schonfrist (in den meisten Einsätzen Standard 5 Minuten) wird die Stale-Spur vollständig von der Karte entfernt.

Für BFT in Umgebungen mit hohem Paketverlust (dichte Bebauung, Dachkrone des Dschungels, SATCOM-Backhaul-Verbindungen) erhöhen Sie den Stale-Multiplikator auf das 6- bis 10-fache, um übermäßige Spurenpersistenz zu vermeiden. Das wird pro Gerät in ATAK unter Einstellungen → Netzwerk → SA-Berichterstattung → Stale-Timer konfiguriert. Auf der TAK-Server-Seite steuert die eigene Stale-Schwelle des Servers (Standard 600 Sekunden), wie lange der Server eine Spur in seiner Datenbank behält, bevor er sie ablaufen lässt — neu verbundene Clients erhalten keine Spuren, die die Server-Stale-Schwelle überschritten haben.

ATAK als BFT-Client

ATAK handhabt BFT vollständig über sein SA-Subsystem (Situational Awareness). Für grundlegendes BFT ist kein zusätzliches Plug-in erforderlich — die Fähigkeit ist in die Kern-ATAK-Anwendung eingebaut. Plug-ins erweitern BFT um kundenspezifische Datenquellen, Anzeigeoverlays und Übertragungswege jenseits der Standard-Server- und Multicast-Optionen.

SA-Konfiguration in ATAK

Die primären BFT-Konfigurationssteuerelemente finden Sie unter Einstellungen → Netzwerk → Berichtspräferenzen:

Meldegeschwindigkeit (in Bewegung) — CoT-Übertragungsintervall, wenn das Gerät in Bewegung ist. Für abgesessene Infanterie auf 5–10 s einstellen, für fahrzeuggebunden mit externer Stromversorgung auf 3–5 s.
Meldegeschwindigkeit (stationär) — Intervall, wenn sich das Gerät nicht über die Bewegungsschwelle hinaus bewegt hat. Auf 30–120 s einstellen, um Akku während statischer Phasen zu schonen.
Dynamische SA-Berichterstattung — wenn aktiviert, wechselt ATAK automatisch zwischen Bewegungs- und Stationärraten basierend auf dem Beschleunigungssensor. Das ist der empfohlene Modus für alle operativen BFT-Einsätze.
Mein Team — weist das Gerät einer Gruppe zu (Cyan, Magenta, Gelb usw.), was die Symbolfarbe bestimmt, die andere Verbände für diese Spur sehen, und die serverseitige Gruppenfilterung steuert.
Meine Rolle — setzt den Funktionsuntertyp im CoT-Typcode (Teammitglied, Teamleiter, HQ, Sanitäter, Vorhutbeobachter usw.).

Netzwerkverbindungstypen

ATAK unterstützt drei Netzwerkverbindungstypen für die BFT-Datenübermittlung:

TCP/TLS zum TAK Server (Port 8089). Das ist der operative Standardmodus. ATAK baut eine dauerhafte TLS-Verbindung auf, die mit einem PKCS#12-Client-Zertifikat authentifiziert wird. Der Server liefert alle abonnierten Spuren über diese Verbindung an den Client und empfängt die Positionsereignisse des Clients zur Verteilung. TCP bietet zuverlässige Zustellung und unterstützt große Nachrichtennutzlasten (Missionspakete, Datenpakete) zusätzlich zu CoT-Ereignissen.

UDP-Multicast. ATAK kann CoT-Ereignisse auf einer UDP-Multicast-Adresse senden und empfangen (Standard 239.2.3.1:6969). Dieser Modus arbeitet ohne jegliche Serverinfrastruktur — die Geräte finden sich über die gemeinsame Multicast-Gruppe. Er eignet sich für Peer-to-Peer-BFT auf lokalen Netzwerksegmenten (WLAN-Hotspot oder MANET-Funk-IP-Raum), unterstützt aber keine Federation, Filterung oder persistente Spurenhistorie. Paketverlust im Multicast-Modus wird nicht erneut gesendet: ein verpasstes Positionsereignis erscheint einfach nicht.

TCP-Streaming (veraltet). Ein älterer unverschlüsselter XML-Stream-Modus, der jetzt zugunsten von TLS veraltet ist. Nicht in irgendeinem operativen Einsatz verwenden.

Plug-in-Architektur für kundenspezifische BFT-Feeds

Die Plug-in-API von ATAK ermöglicht es Drittanwendungen, CoT-Ereignisse in die lokale ATAK-Karte zu injizieren, ohne über den Server zu leiten. Ein kundenspezifisches BFT-Plug-in kann Positionsdaten aus einer proprietären Funkwelleform, einem Hardware-Tracker-Gerät (über USB-Seriell) oder einer KI-abgeleiteten Positionsschätzung empfangen und sie als Standard-CoT-Ereignis injizieren, das auf der ATAK-Anzeige sichtbar ist. Das Plug-in kommuniziert mit dem ATAK-Kern über die Intent-Schnittstelle CotMapComponent und sendet Broadcast-Intents com.atakmap.android.maps.COT_RECEIVER mit der CoT-XML-Nutzlast. Siehe unseren Leitfaden zu ATAK-Integration Feldoperationen für eine detaillierte Plug-in-Entwicklungsanleitung.

TAK-Server-SA-Feed-Verwaltung

Der TAK Server ist die Nabe, die BFT-Positionsereignisse aller verbundenen ATAK-Clients aggregiert und an Abonnenten verteilt. Die korrekte Serverkonfiguration ist für zuverlässiges BFT genauso wichtig wie die Client-Einstellungen.

Server-Federation für verbandsübergreifende SA

Wenn BFT mehrere unabhängige TAK-Server-Instanzen überspannen muss — etwa einen Kompanie- und einen Bataillonsserver oder eine vordere und hintere Ebene —, bietet TAK-Server-Federation-Einrichtung die Vernetzung. Die Federation leitet ausgewählte CoT-Typen nahezu in Echtzeit über die Servergrenze hinweg. Konfigurieren Sie für BFT den Federationsfilter so, dass er a-f--Ereignisse (freundliche Atome) bidirektional durchlässt. Lassen Sie a-h- (feindlich) nicht über Federationsgrenzen hinweg, es sei denn, die Klassifizierungsbehandlung an beiden Enden ist geprüft — feindliche Positionslage ist häufig sensibler als eigene Positionsdaten.

SA-Feed-Abonnement und Gruppenisolation

Der TAK Server verwaltet über sein Gruppensystem, welche Clients welche Spuren erhalten. Wenn sich ein ATAK-Client mit einem Zertifikat verbindet, das der Gruppe "PLATOON-1" zugeordnet ist, erhält er automatisch alle CoT-Ereignisse anderer Clients derselben Gruppe sowie aller Gruppen, die PLATOON-1 sehen darf (z. B. "COMPANY-HQ"). Dieses gruppenbasierte Abonnementmodell beseitigt jegliche Client-spezifische Spuren-Abonnementkonfiguration — die Gruppenzugehörigkeit bestimmt das gesamte SA-Bild.

Die Benutzergruppenisolation ist auch der Mechanismus für die Klassifizierungstrennung. Weisen Sie ATAK-Clients im SECRET-Netz einer Gruppe ohne Sichtbarkeitsüberschneidung mit UNCLASSIFIED-Gruppen zu. Der Server wird SECRET-Spuren niemals an UNCLASSIFIED-Clients leiten, unabhängig von CoT-Typ oder Inhalt. Für harte Klassifizierungsgrenzen betreiben Sie vollständig getrennte TAK-Server-Instanzen auf physisch getrennten Netzwerksegmenten ohne Federation-Verbindung zwischen ihnen.

CloudTAK-SA-Feed-Konfiguration

# Create a user group for BFT population
curl -s -X POST https://tak.yourdomain.com:8443/api/groups \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "PLATOON-1",
    "direction": "BOTH",
    "description": "1st Platoon BFT group",
    "bitpos": 0
  }'

# Assign a user certificate to the group
curl -s -X PUT https://tak.yourdomain.com:8443/api/users/alpha-1/groups \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '["PLATOON-1", "COMPANY-HQ"]'

Das Feld direction steuert, ob die Gruppe eine Eingangsgruppe ist (Ereignisse fließen VON diesem Client herein), eine Ausgangsgruppe (Ereignisse fließen ZU diesem Client hinaus) oder BOTH. Für BFT ist die Einstellung BOTH Standard — jedes Gerät liefert und empfängt Spuren innerhalb seiner zugewiesenen Gruppen.

Mesh-Funk-Transport für BFT

Die Funkverbindung ist das operativ am stärksten eingeschränkte Element im Android-BFT-Stapel. MANET-Funkgeräte stellen das Peer-to-Peer-IP-Netzwerk bereit, das ATAK-Geräte verbindet, wenn WLAN-Infrastruktur und Mobilfunkabdeckung nicht verfügbar sind. Das Verständnis, wie ATAK mit MANET-Hardware integriert, ist entscheidend für vorhersehbare BFT-Leistung bei abgesessenen Operationen. Unser Artikel über Militärische Mesh-Netzwerke MANET behandelt die zugrunde liegende Netzwerkschicht im Detail; dieser Abschnitt konzentriert sich speziell auf die ATAK-Integration.

MANET-Funk-Integration mit ATAK

Harris RF-7800W (Falcon III). Das RF-7800W verbindet sich über USB-OTG mit dem Android-Gerät und stellt eine RNDIS-(USB-Ethernet)-Netzwerkschnittstelle bereit. Die IP-Adresse des Funkgeräts auf dieser Schnittstelle ist typischerweise 192.168.100.1. ATAK behandelt die RNDIS-Schnittstelle als Standard-Netzwerkschnittstelle — kein spezieller Treiber oder Begleit-App ist erforderlich. Konfigurieren Sie die Serververbindung von ATAK so, dass sie auf die IP-Adresse des TAK Servers zeigt, wie sie über das Mesh-Netzwerk des Funkgeräts erreichbar ist. Für lokales Peer-to-Peer-BFT ohne Server konfigurieren Sie die UDP-Multicast-Ausgabe von ATAK auf der RNDIS-Schnittstellenadresse.

Persistent Systems MPU5. Das MPU5 arbeitet als WLAN-Access-Point oder als USB-RNDIS-Gerät. Im Access-Point-Modus verbindet sich das Android-Gerät mit dem WLAN-SSID des MPU5; die Verwaltungs-IP des Funkgeräts ist standardmäßig unter 10.168.1.1 erreichbar. Persistent Systems stellt eine Begleit-Android-Anwendung (Wave Relay Mobile) bereit, die sich mit ATAK integriert, um Wellenformstatus, Knotenkarte und Verbindungsqualitätsmetriken als natives ATAK-Overlay bereitzustellen. ATAK-CoT-Ereignisse fließen über den Standard-TCP- oder UDP-Pfad durch das IP-Mesh des MPU5.

Bandbreitenzuteilung für SA-Verkehr

Die Quantifizierung des BFT-Bandbreitenbudgets vor dem Einsatz verhindert eine Überlastung des Mesh zum denkbar ungünstigsten Zeitpunkt. Ein einzelnes CoT-Positionsereignis mit vollem Detailblock umfasst 800–1200 Bytes. Bei einem Aktualisierungsintervall von 10 Sekunden für einen Trupp mit 12 Personen:

Units:          12
Event size:     1000 bytes
Update rate:    10 seconds
Raw BFT load:   12 × 1000B / 10s = 1200 B/s ≈ 9.6 kbps

With TCP/TLS overhead (≈15%): ~11 kbps
With zlib CoT compression (≈50% reduction): ~5.5 kbps

MPU5 capacity (typical multi-hop mesh):  500 kbps–5 Mbps
RF-7800W capacity (typical):             200–500 kbps

BFT as % of RF-7800W at 200 kbps:        ~5.5% — acceptable
BFT as % of HF/SATCOM backhaul (32 kbps): ~17% — significant

Im Kompanieumfang (100+ Einheiten bei 10-Sekunden-Intervallen) übersteigt die rohe BFT-Last vor Overhead 80 kbps — einen bedeutsamen Anteil jedes HF- oder SATCOM-Backhauls. Erhöhen Sie in diesen Umgebungen die stationären Aktualisierungsintervalle auf 120+ Sekunden und verlassen Sie sich auf bewegungsausgelöste Bursts, um die Gesamtlast auf der Backhaul-Verbindung unter 20 kbps zu halten.

Positionsaktualisierungsrate vs. Akkulaufzeit

Die Positionsaktualisierungsrate ist der wirksamste BFT-Konfigurationsparameter für die Akkulaufzeit. GPS-Erfassung und Funkübertragung sind die beiden größten Stromverbraucher auf einem ATAK-BFT-Gerät; beide skalieren direkt mit der Aktualisierungsfrequenz.

Akkuprofiling unter Einsatzbedingungen

Auf einem Samsung Galaxy XCover Pro (4050-mAh-Akku) mit ATAK und dauerhaftem GPS-Lock:

Aktualisierungsrate	GPS-Verbrauch	Funkverbrauch (MPU5-Hotspot)	Geschätzte BFT-Laufzeit
5 s (aggressiv)	~120 mA	~180 mA	~8–9 h
10 s (Standard)	~120 mA	~120 mA	~10–12 h
30 s (Patrouille)	~90 mA	~60 mA	~15–18 h
120 s (statisch)	~60 mA	~20 mA	~22–26 h

Der GPS-Verbrauch ist unabhängig von der Aktualisierungsrate relativ stabil, da ATAK den GPS-Empfänger im Dauertracking-Modus hält, damit die Position bei ausgelöster Aktualisierung immer aktuell ist. Die Variable ist der Tastgrad der Funkübertragung: bei 5-Sekunden-Intervallen ist das Funkgerät nahezu dauerhaft aktiv; bei 120-Sekunden-Intervallen belegen Sendungsbursts nur 1–2 % des Tastgrads.

Strategien für adaptive Aktualisierungsraten

Der Dynamic-SA-Reporting-Modus von ATAK implementiert eine adaptive Zweiraten-Strategie. Ein anspruchsvollerer Ansatz nutzt ATAK-Plug-ins oder serverseitige Push-Befehle, um Aktualisierungsraten basierend auf dem operativen Kontext anzupassen:

Bewegungsbasierter Ratenwechsel — beschleunigungsausgelöst: wenn sich das Gerät seit der letzten Übertragung mehr als 10 m bewegt hat, sofort senden, unabhängig vom geplanten Intervall. ATAK setzt das nativ im Dynamic-SA-Modus um.
Geo-Fence-ausgelöste Aktualisierungsbursts — wenn ein Verband eine definierte Geo-Fence-Grenze überschreitet (Eintritt in das Zielgebiet, Überschreiten der Phasenlinie), lösen Sie eine 5-Sekunden-Burst-Aktualisierungsrate für 60 Sekunden aus und gehen Sie dann zur Hintergrundrate zurück. Konfigurieren Sie Geo-Fence-Auslöser über ATAK-Geo-Fencing-Plug-ins oder die TAK-Server-Geo-Fence-API.
Kontaktgesteuerte Rateneskalation — wenn der TAK Server eine feindliche Spur innerhalb eines definierten Radius um eine eigene Einheit erkennt, sendet er eine Push-Benachrichtigung über den Server-zu-Client-CoT-Kanal an den ATAK-Client der eigenen Einheit und löst beim Client den Wechsel zur schnellen Aktualisierungsrate aus. Das erfordert ein kundenspezifisches serverseitiges Plug-in oder eine KI-Integrationsschicht.
Ratenreduzierung bei Akkuschwelle — ein Geräteverwaltungsagent (MDM-Profil oder ATAK-Plug-in) überwacht den Geräteakku und erhöht das SA-Intervall automatisch, wenn der Akku unter 30 % fällt, und tauscht Positionsgenauigkeit gegen den Fortbetrieb durch eine kritische Phase.

Lagebewusstsein im Trennungsmodus

Kein MANET-Funknetzwerk arbeitet über ein gesamtes Operationsgebiet hinweg perfekt. Geländemaskierung, elektronische Kampfführung, Funksausfall und bewusste Emcon (Emissionskontrolle) erzeugen allesamt Phasen des getrennten Betriebs. Ein robustes BFT-Design muss exakt definieren, was das System tut, wenn die Funkverbindung fehlt.

Anzeige der zuletzt bekannten Position

Wenn ATAK die Verbindung zum TAK Server verliert (oder im Peer-to-Peer-Modus den Multicast-Empfang verliert), zeigt es weiterhin alle Spuren an ihren zuletzt empfangenen Positionen an. Die visuelle Unterscheidung zwischen aktuellen und veralteten Spuren wird durch den CoT-Stale-Zeitstempel gesteuert: Sobald die Stale-Zeit einer Spur überschritten ist, rendert ATAK sie mit einer Transparenzschicht und einer Zeitstempelannotation, die zeigt, wie lange die Position zuletzt empfangen wurde. Spuren bleiben in diesem Stale-Zustand, bis sie die Stale-Entfernungsschwelle der ATAK-Karte erreichen (pro Einsatz konfigurierbar; Standard 5 Minuten).

Bediener müssen darin geschult werden, Stale-Spur-Anzeigen zu erkennen und danach zu handeln. Eine Spurposition, die 3 Minuten alt ist für einen abgesessenen Verband, der sich im Infanterietempo bewegt, könnte 180–360 Meter tatsächliche Verschiebung bedeuten — genug, um das Risiko von Eigbeschuss zu verursachen, wenn sie als aktuell behandelt wird. Die SOP sollte festlegen, dass Stale-Spuren nur zur allgemeinen Gebietsübersicht dienen, nicht zur Feuerunterstützungs-Entzerrung.

Integration der Koppelnavigation-Anzeige

ATAK unterstützt die Extrapolation von Spuren durch Koppelnavigation über das Detail-Element track in CoT-Ereignissen, das Geschwindigkeit und Kurs trägt. Wenn eine Spur veraltet, kann ein Koppelnavigations-Plug-in die geschätzte aktuelle Position der Spur aus dem letzten bekannten Fix unter Verwendung der gemeldeten Geschwindigkeits- und Kursvektoren fortprojizieren. Die projizierte Position wird mit einem eigenen Symbol dargestellt (typischerweise ein offenes/strichliertes Symbol), um sie von einer GPS-bestätigten Position zu unterscheiden.

Die Genauigkeit der Koppelnavigation degradiert für abgesessene Infanterie rasch (Geschwindigkeit und Kurs ändern sich ständig) und ist zuverlässiger für Fahrzeuge auf bekannten Straßennetzen. Implementieren Sie die Koppelnavigationsanzeige nur, wenn die Bediener ihre Einschränkungen verstehen und die SOP projizierte von bestätigten Positionen klar unterscheidet.

Wiederverbindung und SA-Abgleich

Wenn ATAK nach einer Trennungsphase wieder eine Verbindung zum TAK Server herstellt, führt der Server einen vollständigen SA-Zustands-Push durch: Er liefert das aktuelle (oder zuletzt vorhandene) CoT-Ereignis für jede Spur in den abonnierten Gruppen des Clients. Dieses Burst-Update überschreibt die veralteten zuletzt bekannten Positionen auf der Client-Karte mit aktuellen serverseitigen Daten. Der Abgleichsvorgang ist für typische Verbandsgrößen (unter 200 Spuren) innerhalb von 1–3 Sekunden abgeschlossen.

# Verify reconnection burst via CloudTAK events WebSocket
# (Use wscat or a browser WebSocket client for testing)
# wss://tak.yourdomain.com:8443/api/events?groups=PLATOON-1
#
# On reconnect, expect a rapid burst of CoT events — one per known
# track — within the first 2–3 seconds of the WebSocket session.
# Monitor the event count to confirm all expected tracks are delivered.
#
# If the burst is partial, check server-side stale threshold:
# GET /api/config/cot-stale-seconds
# Default: 600s — tracks older than 10 min are not pushed to reconnecting clients

Ein Sonderfall, den Sie einplanen müssen: Wenn die Trennungsphase die Stale-Schwelle des Servers überschreitet (Standard 600 Sekunden für CloudTAK), hat der Server die veralteten Spuren bereits aus seinem aktiven Speicher ablaufen lassen. Bei der Wiederverbindung erscheinen diese Spuren nicht im Burst-Update und tauchen erst wieder auf, wenn die Quellgeräte neue Positionsereignisse senden. Für Operationen, bei denen Wiederverbindungen mehrstündige Kommunikationsausfälle folgen können, erhöhen Sie die Server-Stale-Schwelle auf die erwartete maximale Ausfalldauer.

BFT für Ihren Verband oder Ihre Organisation einführen

Wir entwerfen und implementieren ATAK-basierte Blue-Force-Tracking-Systeme für Verteidigungs- und Regierungsorganisationen — einschließlich TAK-Server-Konfiguration, MANET-Funk-Integration, TAKpilot-KI-Copilot und missionsbezogener Plug-in-Entwicklung.

TAKpilot KI-Copilot → Briefing buchen

Diese Analyse wurde von Ingenieurinnen und Ingenieuren von Corvus Intelligence erstellt, die einsatzkritische Software für Verteidigungs- und Regierungsorganisationen entwickeln. Lernen Sie unser Team kennen →

Häufig gestellte Fragen

Was ist Blue Force Tracking auf Android-Militärgeräten?

Blue Force Tracking (BFT) auf Android-Militärgeräten bezeichnet die Echtzeitdarstellung und -übertragung eigener Verbandspositionen auf einer gemeinsamen digitalen Karte. ATAK (Android Team Awareness Kit) ist der primäre BFT-Client: Er liest die GPS-Position vom Gerät, verpackt sie als Cursor-on-Target-(CoT)-XML-Ereignis und überträgt dieses Ereignis an einen TAK Server oder direkt an Peer-Geräte über Multicast oder MANET-Funk. Der Server aggregiert Positionsereignisse aller verbundenen Verbände und sendet sie an jeden ATAK-Client, sodass jeder Soldat alle eigenen Spuren gleichzeitig sieht. Aktualisierungsraten, Kartensymbolik und Verbindungswege sind alle in den SA-Einstellungen von ATAK konfigurierbar.

Was ist Cursor on Target und wie wird es für BFT genutzt?

Cursor on Target (CoT) ist ein XML-basiertes Nachrichtenformat, das ursprünglich von der US Air Force zur gemeinsamen Nutzung taktischer Positions- und Statusdaten zwischen unterschiedlichen Systemen entwickelt wurde. Für BFT ist der wichtigste CoT-Ereignistyp das 'atom'-Ereignis (Typpräfix 'a-'), das ein Point-Element mit lat/lon/hae-Koordinaten, einen Stale-Zeitstempel, der angibt, wann die Position abläuft, und einen Detailblock mit Rufzeichen, Teamfarbe und Rolle trägt. ATAK erzeugt diese Ereignisse automatisch aus dem Geräte-GPS in einem konfigurierbaren Intervall (typischerweise alle 5–30 Sekunden) und überträgt sie an den TAK Server, der sie an alle abonnierten Clients weiterleitet. Der Stale-Zeitstempel stellt sicher, dass die Spur eines Verbandes automatisch von den Anzeigen anderer Verbände verschwindet, wenn dieser aufhört zu senden, nach Ablauf des definierten Gültigkeitsfensters.

Welche Aktualisierungsrate sollte ich für ATAK BFT in taktischen Operationen konfigurieren?

Die optimale BFT-Aktualisierungsrate hängt von Missionstyp, Funkbandbreite und Akkubeschränkungen ab. Für abgesessene Infanterie im Kontakt bietet eine Aktualisierungsrate von 5–10 Sekunden ausreichende Positionsgenauigkeit; für fahrzeuggebundene Verbände mit externer Stromversorgung sind 3–5 Sekunden praktikabel. Auf bandbreitengeschränkten MANET-Verbindungen erhöhen Sie das Intervall für nicht manövrierende Verbände auf 30–60 Sekunden und verlassen sich auf bewegungsausgelöste Bursts (Geo-Fence-Austrittsereignisse) für sofortige Aktualisierungen, wenn sich ein Verband bewegt. Die adaptive SA-Berichterstattung von ATAK kann automatisch zwischen einer langsamen Hintergrundrate und einer schnellen Kontaktrate wechseln, basierend auf der vom Beschleunigungssensor des Geräts erkannten Bewegungsgeschwindigkeit.

Wie verbindet sich ATAK mit einem TAK Server für BFT?

ATAK unterstützt drei primäre Verbindungstypen für BFT: (1) TCP-Streaming — eine dauerhafte TCP/TLS-Verbindung zu TAK-Server-Port 8089, genutzt für zuverlässige Unicast-Zustellung mit zertifikatbasierter Authentifizierung; (2) UDP-Multicast — CoT-Ereignisse, die auf einer Multicast-Adresse innerhalb eines lokalen Netzwerksegments gesendet werden, geeignet für LAN- oder MANET-Umgebungen ohne Serverinfrastruktur; und (3) Streaming-XML — ein veralteter TCP-Modus mit unverschlüsselten XML-Strömen, der jetzt veraltet ist. Für operative Einsätze ist TCP/TLS zu einem TAK Server Standard. Die Netzwerkeinstellungen von ATAK akzeptieren einen Server-Hostnamen, einen Port und ein PKCS#12-Zertifikatsbündel für gegenseitige TLS-Authentifizierung.

Welche MANET-Funkgeräte integrieren sich mit ATAK für BFT?

ATAK integriert MANET-Funkgeräte über Android-USB-OTG oder die Begleit-App des Funkgeräts. Häufig integrierte Funkgeräte sind Harris RF-7800W (Falcon-III-Serie), Persistent Systems MPU5, Domo Tactical PRC-ACM und Silvus StreamCaster. Jedes Funkgerät stellt eine virtuelle Netzwerkschnittstelle oder einen CoT-Relay-Dienst bereit, den ATAK als TAK-Datenverbindung erkennt. Das Funkgerät übernimmt die IP-Routenfindung über das Mesh, und ATAK sendet Standard-CoT-UDP-Multicast- oder TCP-Pakete an die lokale IP-Adresse des Funkgeräts. Manche Funkgeräte stellen auch eine Wellenform-Verwaltungs-API bereit, die ATAK-Plug-ins abfragen können, um die Verbindungsqualität zu überwachen und die SA-Übertragungsparameter entsprechend anzupassen.

Wie verwaltet der TAK Server SA-Feeds für BFT?

Der TAK Server führt einen In-Memory-CoT-Ereignisspeicher für alle verbundenen Clients. Wenn ein neues CoT-Positionsereignis eintrifft, tut der Server: (1) das Ereignis in die persistente Datenbank schreiben; (2) Gruppen- und Filterregeln auswerten, um zu bestimmen, welche Clients es erhalten sollen; (3) das Ereignis an alle abonnierten Client-Verbindungen senden. Speziell für BFT verfolgt der Server das letzte Positionsereignis pro UID und stellt es neu verbundenen Clients bereit, damit diese sofort bei der Verbindung ein aktuelles gemeinsames Lagebild erhalten. SA-Feed-Abonnements werden über das Gruppensystem des Servers verwaltet — Clients, die derselben Gruppe zugeordnet sind, teilen BFT-Spuren automatisch ohne manuelle Abonnementkonfiguration.

Wie verhindere ich, dass BFT-Spuren gleichzeitig auf klassifizierten und unklassifizierten ATAK-Instanzen erscheinen?

Die Klassifizierungstrennung in einer TAK-BFT-Umgebung wird durch eine Kombination aus serverseitiger Gruppenisolation und physischer Netzseparation erreicht. Weisen Sie auf dem TAK Server klassifizierte Verbände einer Gruppe zu, die für unklassifizierte Clients nicht sichtbar ist (z. B. eine 'SECRET'-Gruppe ohne Federation oder Abonnement der 'UNCLASSIFIED'-Gruppe). Für harte Trennung betreiben Sie zwei vollständig getrennte TAK-Server-Instanzen — eine auf einem klassifizierten Netzwerksegment und eine auf einem unklassifizierten Segment — ohne Federation-Verbindung zwischen ihnen. Verlassen Sie sich niemals ausschließlich auf Software-Gruppenfilter für die Klassifizierungstrennung; physische oder kryptografische Netzseparation ist erforderlich, um die Standards der Informationssicherheit zu erfüllen.

Was passiert mit BFT-Spuren, wenn ATAK die Verbindung zum TAK Server verliert?

Wenn ATAK die Serververbindung verliert, wechselt es in den Trennungsmodus. Die Karte zeigt weiterhin die zuletzt empfangenen Positionen aller Spuren, visuell unterschieden durch einen Stale-Indikator (typischerweise ein ausgegrauter Symbol oder Zeitstempelannotation), sobald die CoT-Stale-Zeit der Spur überschritten ist. ATAK sendet auch weiterhin seine eigene Position über jeden verfügbaren lokalen Broadcast-Pfad (UDP-Multicast, MANET-Funk). Wenn die Verbindung wiederhergestellt ist, verbindet sich ATAK automatisch wieder und der Server sendet den aktuellen Zustand aller Spuren als Burst-Update, das die veralteten zuletzt bekannten Positionen überschreibt. Administratoren sollten Stale-Timeouts passend zum taktischen Tempo setzen — ein 10-Minuten-Stale-Fenster verhindert Spurenpersistenz in Umgebungen mit schlechter Konnektivität.

Wie viel Bandbreite verbraucht BFT über ATAK auf einer MANET-Verbindung?

Ein einzelnes ATAK-CoT-Positionsereignis (CoT-XML mit Detailblock) umfasst etwa 800–1200 Bytes. Bei einem Aktualisierungsintervall von 10 Sekunden für einen Zug mit 20 Einheiten beträgt der gesamte BFT-Verkehr etwa 20 × 1000 Bytes / 10 s = 2 kB/s oder etwa 16 kbps. Das liegt deutlich innerhalb der Kapazität moderner MANET-Funkgeräte (MPU5 liefert 1–10 Mbps pro Knoten), akkumuliert sich aber in großen Verbänden schnell. Für eine Kompanie mit 100 Einheiten bei 10-Sekunden-Intervallen nähert sich der rohe BFT-Verkehr 80 kbps — beherrschbar, aber bedeutsam auf HF- oder Satelliten-Backhaul-Verbindungen. CoT-Kompression (zlib über den TCP-Strom) reduziert die Nutzlastgröße typischerweise um 40–60 %, und adaptive Aktualisierungsraten können die Last während statischer Phasen um eine Größenordnung senken.

Welche Android-Geräte sind für militärisches BFT mit ATAK zertifiziert?

ATAK MIL (die militärische Variante, die über TAK.gov verteilt wird) läuft auf einer Reihe robuster Android-Geräte. Häufig genutzte Plattformen sind das Samsung Galaxy XCover Pro, Getac PS336, Kyocera DuraForce Pro 2 und Dell Latitude Rugged Tablets. Speziell für BFT umfassen die Geräteauswahlkriterien die GPS-Chipsatz-Empfindlichkeit (für städtische Canyons und Blattdurchdringung), die Akkukapazität (oder Hot-Swap-Fähigkeit), den Betriebstemperaturbereich und die MIL-STD-810-Schock- und Wasserfestigkeit. Geräte mit Multi-Konstellations-GNSS (GPS + GLONASS + Galileo) liefern in beeinträchtigten Umgebungen zuverlässigere Positionsfixes als reine GPS-Chipsätze.