Field Applications

Blue force tracking op Android: ATAK, CoT en netwerkarchitectuur

Door Corvus Intelligence Engineering Team · Over het team →

25 juni 2026 11 min leestijd

Blue force tracking (BFT) is een van de meest ingrijpende capaciteiten die een eenheid te voet bij zich kan dragen: het vermogen om in near-real-time te zien waar elk eigen element zich op de kaart bevindt. Jarenlang was deze capaciteit het exclusieve domein van dure, speciaal gebouwde terminals. Op Android gebaseerde platforms die ATAK (Android Team Awareness Kit) draaien, hebben die vergelijking veranderd — een geharde smartphone of tablet met een MANET-radio levert nu permanente BFT voor een fractie van de kosten van legacy-hardware, met een open plug-in-architectuur die aangepaste sensorfeeds, AI-overlays en missieplanningshulpmiddelen laat coëxisteren met de trackinglaag. Dit artikel behandelt de volledige BFT-stack: CoT-positie-eventschema, ATAK SA-configuratie, TAK Server feedbeheer, MANET-radio-transportintegratie, afstemming van updatesnelheid versus batterij, en het gedrag van het systeem wanneer de connectiviteit wegvalt.

BFT-vereisten voor tactische eenheden

Voordat u aan softwareconfiguratie begint, vereist een BFT-inzet een expliciete basislijn van vereisten. De parameters die elke volgende beslissing sturen zijn positienauwkeurigheid, updatefrequentie, weergavelatentie en de beperkingen van de gebruikte apparaten en radio's.

Positienauwkeurigheid. BFT voor infanterie te voet mikt op een circular error probable (CEP) van 10 meter of beter — voldoende voor deconflictie in stedelijk terrein waar resolutie op gebouwniveau telt. BFT op voertuigen aanvaardt doorgaans CEP 50 m. Android-apparaten met multi-constellatie-GNSS (GPS + GLONASS + Galileo) behalen 3–5 m CEP in open terrein; dichte bladbedekking of stedelijke canyons degraderen dit naar 15–30 m zonder augmentatie. SBAS (WAAS/EGNOS) ondersteunt GNSS-ontvangers in ATAK-compatibele apparaten en verkleint de nauwkeurigheid verder in ondersteunde geografische gebieden.

Updatefrequentie. De positiesnelheid bepaalt hoe actueel de sporen op de kaarten van aangrenzende eenheden zijn. Intervallen van 5–10 seconden zijn standaard voor eenheden in direct contact of bij operaties op korte afstand. Intervallen van 30–60 seconden volstaan voor eenheden in ondersteunings- of reserverposities. De updatesnelheid vermenigvuldigt de kanaalbelasting rechtstreeks: elke verdubbeling van het aantal eenheden of halvering van het updateinterval verdubbelt het bandbreedteverbruik op het gedeelde radionetwerk.

Weergavelatentie. End-to-end weergavelatentie — van het positie-event dat op het bronapparaat wordt gegenereerd tot het spoor dat op alle verbonden beeldschermen verschijnt — moet onder 3 seconden blijven voor operaties waarbij deconflictie afhangt van realtime positie. Latentiebijdragen omvatten GPS-fixtijd, CoT-eventgeneratie, radioverzending, serververwerking en clientrendering. Op een goed geconfigureerde MANET met lokale TAK Server valt de totale latentie doorgaans in het bereik 500 ms–1,5 s. Configuraties met satelliet-backhaul voegen 600 ms–1,2 s enkele-reisvertraging toe.

Apparaat- en radiobeperkingen. Geharde Android-apparaten die voor BFT worden gebruikt — Samsung XCover Pro, Kyocera DuraForce Pro 2, Getac PS336 — dragen batterijen gedimensioneerd op diensten van 8–16 uur, maar GPS- en radioverzending putten die capaciteit zwaar uit. MANET-radio's verbinden doorgaans via USB OTG of Wi-Fi-hotspot; de hotspotverbinding zelf voegt antenne- en RF-belasting toe. Thermische grenzen in hete omgevingen verlagen het duurzame zendvermogen van zowel het Android-apparaat als de radio, wat de effectieve reikwijdte kan verminderen en daarmee kortere update-intervallen vereist om meer pakketverlies te compenseren.

Cursor on Target (CoT) positie-events

De CoT-standaard definieert een XML-eventschema dat elk element in het BFT-netwerk spreekt. Begrip van het schema is essentieel voor het diagnosticeren van BFT-fouten en voor het schrijven van aangepaste plug-ins die positiegegevens injecteren of consumeren.

CoT XML-schema voor SA-events

Een minimaal positie-event van een eigen grondeenheid ziet er zo uit:

<?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>

De sleutelvelden voor BFT zijn:

uid — unieke identifier voor het spoor. Moet stabiel blijven tussen positie-updates; ATAK gebruikt de IMEI van het apparaat of een gegenereerde UUID.
type — CoT-typecode (zie hieronder) die affiliatie, dimensie en platformtype codeert.
time / start — tijdstempel van eventgeneratie in ISO 8601 UTC. Klokprecisie hier is kritiek: klokafwijking veroorzaakt stale-rejectie op de ontvangende server.
stale — tijdstempel waarna het event als verlopen geldt. ATAK stelt stale standaard in op time + (update interval × 3), wat drie gemiste updates geeft voordat het spoor wordt geghost.
how — invoermethode voor de positie: m-g (machine GPS), h-g-i-g-o (handmatig ingevoerde GPS), m-g-i (afgeleide GPS).
point — WGS84-coördinaten: lat/lon in decimale graden, hae (hoogte boven WGS84-ellipsoïde) in meters, ce (circular error) en le (linear error) in meters.

CoT-typecodes voor eigen, vijandig en neutraal

CoT-typecodes volgen een hiërarchisch schema: a-[affiliation]-[battle dimension]-[function]. Voor BFT is het affiliatieteken de kritieke discriminator:

Typeprefix	Affiliatie	ATAK-icoonkleur	Voorbeeld
`a-f-`	Eigen	Blauw	`a-f-G-U-C` — eigen grondeenheid, gevecht
`a-h-`	Vijandig	Rood	`a-h-G-U-C` — vijandige grondeenheid, gevecht
`a-n-`	Neutraal	Groen	`a-n-G-E-V-C` — neutraal grondvoertuig, burgerlijk
`a-u-`	Onbekend	Geel	`a-u-G-U` — onbekende grondeenheid

Stale-timeoutbeheer

De stale-tijdstempel is het primaire mechanisme om sporen van de COP te wissen. De standaard stale-vermenigvuldiger van ATAK is 3× het geconfigureerde SA-updateinterval: bij een updatesnelheid van 10 seconden wordt stale 30 seconden in de toekomst ingesteld. Als drie opeenvolgende positie-events verloren gaan (pakketverlies, radiostilte, apparaat uitgeschakeld), gaat het spoor naar stale-status en rendert ATAK het met een vervaagd icoon. Na een door de operator configureerbare respijtperiode (standaard 5 minuten in de meeste implementaties) wordt het stale-spoor volledig van de kaart verwijderd.

Verhoog voor BFT in omgevingen met veel pakketverlies (dicht stedelijk, junglekroon, SATCOM-backhaul) de stale-vermenigvuldiger naar 6–10× om overmatige spooksporen te voorkomen. Dit wordt per apparaat geconfigureerd in ATAK onder Settings → Network → SA Reporting → Stale Timer. Aan de kant van de TAK Server bepaalt de eigen stale-drempel van de server (standaard 600 seconden) hoe lang de server een spoor in zijn database bewaart voordat het verloopt — nieuw verbindende clients ontvangen geen sporen die de server-stale-drempel hebben overschreden.

ATAK als BFT-client

ATAK behandelt BFT volledig via het SA-subsysteem (situational awareness). Voor basis-BFT is geen extra plug-in nodig — de capaciteit is ingebouwd in de kernapplicatie van ATAK. Plug-ins breiden BFT uit met aangepaste gegevensbronnen, weergave-overlays en verzendpaden voorbij de standaard server- en multicast-opties.

SA-configuratie in ATAK

De primaire BFT-configuratiebedieningselementen staan onder Settings → Network → Reporting Preferences:

Reporting Rate (Moving) — CoT-verzendinterval wanneer het apparaat in beweging is. Stel in op 5–10s voor infanterie te voet, 3–5s voor op voertuig met externe voeding.
Reporting Rate (Stationary) — interval wanneer het apparaat zich niet buiten de bewegingsdrempel heeft verplaatst. Stel in op 30–120s om batterij te sparen tijdens statische fasen.
Dynamic SA Reporting — indien ingeschakeld schakelt ATAK automatisch tussen bewegende en stationaire snelheden op basis van de versnellingsmeter. Dit is de aanbevolen modus voor alle operationele BFT-implementaties.
My Team — wijst het apparaat toe aan een groep (Cyan, Magenta, Yellow, enz.), wat de icoonkleur bepaalt die andere eenheden voor dit spoor zien en de groepsfiltering aan serverszijde regelt.
My Role — stelt het functiesubtype in in de CoT-typecode (Team Member, Team Leader, HQ, Medic, Forward Observer, enz.).

Netwerkverbindingstypen

ATAK ondersteunt drie netwerkverbindingstypen voor BFT-gegevenslevering:

TCP/TLS naar TAK Server (poort 8089). Dit is de standaard operationele modus. ATAK legt een permanente TLS-verbinding vast, geauthenticeerd met een PKCS#12-clientcertificaat. De server levert alle geabonneerde sporen aan de client over deze verbinding en ontvangt de positie-events van de client voor distributie. TCP biedt betrouwbare levering en ondersteunt grote berichtpayloads (missiepakketten, datapakketten) naast CoT-events.

UDP-multicast. ATAK kan CoT-events uitzenden en ontvangen op een UDP-multicast-adres (standaard 239.2.3.1:6969). Deze modus werkt zonder serverinfrastructuur — apparaten ontdekken elkaar via de gedeelde multicastgroep. Geschikt voor peer-to-peer BFT op lokale netwerksegmenten (Wi-Fi-hotspot of lokaal IP-bereik van de MANET-radio), maar ondersteunt geen federatie, filtering of persistente spoorhistorie. Pakketverlies in multicast-modus wordt niet opnieuw verzonden: een gemist positie-event verschijnt simpelweg niet.

TCP-streaming (legacy). Een oudere onversleutelde XML-streammodus, nu verouderd ten gunste van TLS. Gebruik dit niet in enige operationele implementatie.

Plug-in-architectuur voor aangepaste BFT-feeds

De plug-in-API van ATAK maakt het mogelijk dat third-party applicaties CoT-events injecteren in de lokale ATAK-kaart zonder via de server te routeren. Een aangepaste BFT-plug-in kan positiegegevens ontvangen uit een propriëtaire radiogolfvorm, een hardwaretracker (via USB-serial) of een door AI afgeleide positieschatting, en die injecteren als een standaard CoT-event dat zichtbaar is op de ATAK-weergave. De plug-in communiceert met de ATAK-kern via de intent-interface CotMapComponent, waarbij broadcast-intents com.atakmap.android.maps.COT_RECEIVER met de CoT XML-payload worden geplaatst. Zie onze gids over ATAK integration field operations voor een gedetailleerde walkthrough van plug-in-ontwikkeling.

TAK Server SA-feedbeheer

De TAK Server is de hub die BFT-positie-events van alle verbonden ATAK-clients aggregeert en distribueert aan abonnees. Correcte serverconfiguratie is even belangrijk als de clientinstellingen voor betrouwbare BFT.

Serverfederatie voor SA over eenheden heen

Wanneer BFT meerdere onafhankelijke TAK Server-instanties moet overspannen — bijvoorbeeld een compagniesserver en een bataljonsserver, of een voorste en achterste echelon — biedt TAK server federation setup de onderlinge verbinding. Federatie stuurt geselecteerde CoT-typen in near-real-time over de servergrens heen. Configureer voor BFT het federatiefilter om a-f- (friendly atom) bidirectioneel door te laten. Laat a-h- (hostile) niet over federatiegrenzen heen gaan, tenzij de classificatieafhandeling aan beide uiteinden is geverifieerd — inlichtingen over vijandige posities zijn vaak gevoeliger dan eigen positiegegevens.

SA-feedabonnement en groepsisolatie

TAK Server beheert welke clients welke sporen ontvangen via het groepssysteem. Wanneer een ATAK-client verbindt met een certificaat dat is toegewezen aan groep "PLATOON-1", ontvangt deze automatisch alle CoT-events van andere clients in dezelfde groep plus eventuele groepen die PLATOON-1 zichtbaar zijn geconfigureerd (bijvoorbeeld "COMPANY-HQ"). Dit op groepen gebaseerde abonnementsmodel elimineert de behoefte aan per-client spoorabonnementsconfiguratie — groepslidmaatschap bepaalt het volledige SA-beeld.

Gebruikersgroepsisolatie is ook het mechanisme voor classificatiescheiding. Wijs ATAK-clients op het SECRET-netwerk toe aan een groep zonder zichtbaarheidsoverlap met UNCLASSIFIED-groepen. De server zal SECRET-sporen nooit routeren naar UNCLASSIFIED-clients, ongeacht CoT-type of inhoud. Voer voor harde classificatiegrenzen volledig gescheiden TAK Server-instanties uit op fysiek gescheiden netwerksegmenten zonder federatielink ertussen.

CloudTAK SA-feedconfiguratie

# 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"]'

Het veld direction bepaalt of de groep een invoergroep is (events stromen IN vanaf deze client), een uitvoergroep (events stromen UIT naar deze client) of BOTH. BOTH instellen is standaard voor BFT — elk apparaat levert zowel als ontvangt sporen binnen zijn toegewezen groepen.

Mesh-radiotransport voor BFT

De radiolink is het element met de meeste operationele beperkingen in de Android BFT-stack. MANET-radio's leveren het peer-to-peer IP-netwerk dat ATAK-apparaten verbindt wanneer Wi-Fi-infrastructuur en mobiele dekking niet beschikbaar zijn. Begrip van hoe ATAK met MANET-hardware integreert is kritiek voor voorspelbare BFT-prestaties bij operaties te voet. Ons artikel over military mesh network MANET behandelt de onderliggende netwerklaag in detail; deze richt zich specifiek op de ATAK-integratie.

MANET-radiointegratie met ATAK

Harris RF-7800W (Falcon III). De RF-7800W verbindt via USB OTG met het Android-apparaat en biedt een RNDIS (USB Ethernet) netwerkinterface. Het IP-adres van de radio op deze interface is doorgaans 192.168.100.1. ATAK behandelt de RNDIS-interface als een standaard netwerkinterface — geen speciale driver of companion-app nodig. Configureer de serververbinding van ATAK zodat die naar het IP-adres van de TAK Server wijst zoals bereikbaar via het mesh-netwerk van de radio. Voor lokale peer-to-peer BFT zonder server configureert u de UDP-multicast-uitvoer van ATAK op het RNDIS-interfaceadres.

Persistent Systems MPU5. De MPU5 werkt als Wi-Fi-accesspoint of als USB RNDIS-apparaat. In accesspointmodus verbindt het Android-apparaat met de Wi-Fi SSID van de MPU5; het beheer-IP van de radio is standaard bereikbaar op 10.168.1.1. Persistent Systems levert een companion Android-applicatie (Wave Relay Mobile) die met ATAK integreert om golfvormstatus, knoopkaart en linkkwaliteitsmetrieken als native ATAK-overlay te tonen. ATAK CoT-events stromen over het standaard TCP- of UDP-pad via het IP-mesh van de MPU5.

Bandbreedtetoewijzing voor SA-verkeer

Het kwantificeren van het BFT-bandbreedtebudget vóór implementatie voorkomt overbelasting van de mesh op het slechtst mogelijke moment. Een enkel CoT-positie-event met volledig detailblok is 800–1200 bytes. Bij een updateinterval van 10 seconden voor een groep van 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

Op compagnieschaal (100+ eenheden met intervallen van 10 seconden) overschrijdt de ruwe BFT-belasting 80 kbps vóór overhead — een betekenisvol deel van elke HF- of SATCOM-backhaul. Verhoog in deze omgevingen de stationaire update-intervallen naar 120+ seconden en vertrouw op door beweging geactiveerde bursts om de totale belasting op de backhaul-link onder 20 kbps te houden.

Positie-updatesnelheid versus batterijduur

De positiesnelheid is de meest impactvolle BFT-configuratieparameter voor batterijduur. GPS-acquisitie en radioverzending zijn de twee grootste energieverbruikers op een ATAK BFT-apparaat; beide schalen rechtstreeks met de updatefrequentie.

Batterijprofielen onder operationele omstandigheden

Op een Samsung Galaxy XCover Pro (4050 mAh-batterij) met ATAK en continue GPS-lock:

Updatesnelheid	GPS-verbruik	Radioverbruik (MPU5-hotspot)	Geschatte BFT-levensduur
5 s (agressief)	~120 mA	~180 mA	~8–9 u
10 s (standaard)	~120 mA	~120 mA	~10–12 u
30 s (patrouille)	~90 mA	~60 mA	~15–18 u
120 s (statisch)	~60 mA	~20 mA	~22–26 u

GPS-verbruik is relatief stabiel ongeacht de updatesnelheid, omdat ATAK de GPS-ontvanger in continue tracking-modus houdt zodat de positie altijd actueel is wanneer een update wordt verstuurd. De variabele is de duty cycle van de radioverzending: bij intervallen van 5 seconden is de radio bijna continu actief; bij intervallen van 120 seconden beslaan transmissiebursts slechts 1–2% van de duty cycle.

Adaptieve updatesnelheidstrategieën

De Dynamic SA Reporting-modus van ATAK implementeert een adaptieve strategie met twee snelheden. Een verfijndere aanpak gebruikt ATAK-plug-ins of push-opdrachten van de serverzijde om updatesnelheden aan te passen op basis van operationele context:

Op beweging gebaseerde snelheidswisseling — versnellingsmetergetriggerd: als het apparaat meer dan 10 m is verplaatst sinds de laatste verzending, direct verzenden ongeacht het geplande interval. ATAK implementeert dit natief in Dynamic SA-modus.
Door geofence geactiveerde updatebursts — wanneer een eenheid een gedefinieerde geofence-grens overschrijdt (binnentreden doelgebied, kruisen faselijn), een updateburst van 5 seconden gedurende 60 seconden triggeren, daarna terug naar achtergrondniveau. Configureer geofence-triggers via ATAK geofencing-plug-ins of de TAK Server geofence-API.
Contactgedreven snelheidsescalatie — wanneer de TAK Server een vijandig spoor detecteert binnen een gedefinieerde straal van een eigen eenheid, stuurt deze een pushmelding naar de ATAK-client van de eigen eenheid via het server-naar-client CoT-kanaal, waardoor de client omschakelt naar zijn snelle updatesnelheid. Dit vereist een aangepaste plug-in aan de serverzijde of een AI-integratielaag.
Verlaging van updatesnelheid bij batterijdrempel — een apparaatbeheeragent (MDM-profiel of ATAK-plug-in) monitort de batterij van het apparaat en verhoogt automatisch het SA-interval wanneer de batterij onder 30% daalt, waarbij actualiteit van de positie wordt ingewisseld voor voortgezette werking door een kritieke fase.

Situatiebewustzijn in disconnected-modus

Geen enkel MANET-radionetwerk werkt perfect over een heel operatiegebied. Terreinmaskering, elektronische oorlogvoering, radiostoring en bewuste emcon (emission control) produceren allemaal perioden van disconnected werking. Een robuust BFT-ontwerp moet precies definiëren wat het systeem doet wanneer de radiolink ontbreekt.

Weergave van laatstbekende positie

Wanneer ATAK de verbinding met de TAK Server verliest (of multicastontvangst in peer-to-peer-modus verliest), blijft het alle sporen tonen op hun laatst ontvangen posities. Het visuele onderscheid tussen actuele en stale sporen wordt geregeld door de CoT stale-tijdstempel: zodra de stale-tijd van een spoor is verstreken, rendert ATAK het met een transparantie-overlay en een tijdstempelannotatie die aangeeft hoe lang geleden de positie voor het laatst is ontvangen. Sporen blijven in deze stale-status tot ze de stale-verwijderdrempel van de ATAK-kaart bereiken (configureerbaar per implementatie; standaard 5 minuten).

Operatoren moeten worden getraind om stale-spoorindicatoren te herkennen en erop te handelen. Een spoorpositie van 3 minuten oud voor een eenheid te voet die zich met infanterietempo verplaatst kan 180–360 meter werkelijke verplaatsing vertegenwoordigen — genoeg om risico op friendly fire te veroorzaken als die als actueel wordt behandeld. De SOP moet vastleggen dat stale sporen alleen worden gebruikt voor algemene gebiedsbekendheid, niet voor deconflictie van vuursteun.

Integratie van dead-reckoning-weergave

ATAK ondersteunt dead-reckoning-spoorprojectie via het track-detail-element in CoT-events, dat snelheid en koers draagt. Wanneer een spoor stale wordt, kan een dead-reckoning-plug-in de geschatte huidige positie van het spoor projecteren vanaf de laatstbekende fix met de gerapporteerde snelheids- en koersvectoren. De geprojecteerde positie wordt getoond met een onderscheidend icoon (doorgaans een open/onderbroken symbool) om die te onderscheiden van een GPS-bevestigde positie.

De nauwkeurigheid van dead reckoning degraderd snel voor infanterie te voet (snelheid en koers veranderen voortdurend) en is betrouwbaarder voor voertuigen op bekende wegennetwerken. Implementeer dead-reckoning-weergave alleen wanneer operatoren de beperkingen begrijpen en de SOP duidelijk onderscheid maakt tussen geprojecteerde en bevestigde posities.

Herverbinden en SA-reconciliatie

Wanneer ATAK na een disconnected periode opnieuw verbindt met de TAK Server, voert de server een volledige SA-statuspush uit: hij levert het actuele (of meest recente) CoT-event voor elk spoor in de geabonneerde groepen van de client. Deze burst-update overschrijft de stale laatstbekende posities op de clientkaart met actuele serverdata. Het reconciliatieproces is binnen 1–3 seconden voltooid voor typische eenheidsgroottes (onder 200 sporen).

# 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

Een edge case om rekening mee te houden: als de disconnected periode de stale-drempel van de server overschrijdt (standaard 600 seconden voor CloudTAK), heeft de server de stale sporen al uit zijn actieve opslag verwijderd. Bij herverbinden verschijnen die sporen niet in de burst-update en komen ze pas terug wanneer de bronapparaten nieuwe positie-events verzenden. Verhoog voor operaties waarbij herverbinden kan volgen op communicatiestiltes van meerdere uren de server-stale-drempel naar de verwachte maximale duur van de stilte.

Implementeer BFT voor uw eenheid of organisatie

Wij ontwerpen en implementeren op ATAK gebaseerde blue force tracking-systemen voor defensie- en overheidsorganisaties — inclusief TAK Server-configuratie, MANET-radiointegratie, TAKpilot AI copilot en missiespecifieke plug-in-ontwikkeling.

TAKpilot AI Copilot → Book a Briefing

Deze analyse is opgesteld door ingenieurs van Corvus Intelligence die missiekritieke software bouwen voor defensie- en overheidsorganisaties. Maak kennis met ons team →

Veelgestelde vragen

Wat is blue force tracking op Android militaire apparaten?

Blue force tracking (BFT) op Android militaire apparaten verwijst naar de realtime weergave en verzending van posities van eigen eenheden op een gedeelde digitale kaart. ATAK (Android Team Awareness Kit) is de primaire BFT-client: het leest de GPS-positie van het apparaat, verpakt die als een Cursor on Target (CoT) XML-event en verzendt dat event naar een TAK Server of direct naar peereenheden via multicast of MANET-radio. De server aggregeert positie-events van alle verbonden eenheden en zendt ze uit naar elke ATAK-client, zodat elke militair tegelijk alle eigen sporen ziet. Updatesnelheden, kaartsymboliek en connectiviteitspaden zijn allemaal configureerbaar in de SA-instellingen van ATAK.

Wat is Cursor on Target en hoe wordt het gebruikt voor BFT?

Cursor on Target (CoT) is een op XML gebaseerd berichtenformaat dat oorspronkelijk door de US Air Force is ontwikkeld om tactische positie- en statusgegevens tussen uiteenlopende systemen te delen. Voor BFT is het belangrijkste CoT-eventtype het 'atom'-event (typeprefix 'a-'), dat een point-element draagt met lat/lon/hae-coördinaten, een stale-tijdstempel die aangeeft wanneer de positie verloopt, en een detailblok met callsign, teamkleur en rol. ATAK genereert deze events automatisch vanuit de GPS van het apparaat met een configureerbaar interval (doorgaans elke 5–30 seconden) en verzendt ze naar de TAK Server, die ze opnieuw uitzendt naar alle geabonneerde clients. De stale-tijdstempel zorgt ervoor dat als een eenheid stopt met verzenden, het spoor automatisch verdwijnt van de weergave van andere eenheden nadat het gedefinieerde verloopvenster is verstreken.

Welke updatesnelheid moet ik instellen voor ATAK BFT in tactische operaties?

De optimale BFT-updatesnelheid hangt af van missietype, radiobandbreedte en batterijbeperkingen. Voor militairen te voet in contact biedt een updatesnelheid van 5–10 seconden voldoende actualiteit van de positie; voor op voertuigen geplaatste eenheden met externe voeding is 3–5 seconden praktisch. Op bandbreedtebeperkte MANET-verbindingen vergroot u het interval naar 30–60 seconden voor niet-manoeuvrerende eenheden en vertrouwt u op door beweging geactiveerde bursts (geo-fence-vertrekgebeurtenissen) voor onmiddellijke updates wanneer een eenheid zich verplaatst. De adaptieve SA-rapportagefunctie van ATAK kan automatisch schakelen tussen een trage achtergrondsnelle en een snelle contactsnelheid op basis van de bewegingssnelheid die door de versnellingsmeter van het apparaat wordt gedetecteerd.

Hoe verbindt ATAK met een TAK Server voor BFT?

ATAK ondersteunt drie primaire verbindingssoorten voor BFT: (1) TCP-streaming — een permanente TCP/TLS-verbinding met TAK Server-poort 8089, gebruikt voor betrouwbare unicast-levering met certificaatgebaseerde authenticatie; (2) UDP-multicast — CoT-events uitgezonden op een multicast-adres binnen een lokaal netwerksegment, geschikt voor LAN- of MANET-omgevingen zonder serverinfrastructuur; en (3) Streaming XML — een verouderde TCP-modus met onversleutelde XML-streams, nu verouderd. Voor operationele implementaties is TCP/TLS naar een TAK Server standaard. De netwerkinstellingen van ATAK accepteren een serverhostnaam, poort en PKCS#12-certificaatbundel voor wederzijdse TLS-authenticatie.

Welke MANET-radio's integreren met ATAK voor BFT?

ATAK integreert met MANET-radio's via Android USB OTG of de bijbehorende Android-applicatie van de radio. Vaak geïntegreerde radio's zijn Harris RF-7800W (Falcon III-serie), Persistent Systems MPU5, Domo Tactical PRC-ACM en Silvus StreamCaster. Elke radio biedt een virtuele netwerkinterface of een CoT-relayservice die ATAK herkent als TAK-datalink. De radio verzorgt IP-routering over de mesh, en ATAK stuurt standaard CoT UDP-multicast- of TCP-pakketten naar het lokale IP-adres van de radio. Sommige radio's bieden ook een waveform-beheer-API die ATAK-plug-ins kunnen bevragen om linkkwaliteit te monitoren en daarop de SA-verzendparameters aan te passen.

Hoe beheert TAK Server SA-feeds voor BFT?

TAK Server houdt een in-memory CoT-eventopslag bij voor alle verbonden clients. Wanneer een nieuw CoT-positie-event binnenkomt: (1) schrijft de server het event naar de persistente database; (2) evalueert hij groeps- en filterregels om te bepalen welke clients het moeten ontvangen; (3) duwt hij het event naar alle geabonneerde clientverbindingen. Specifiek voor BFT volgt de server het meest recente positie-event per UID en levert dat aan nieuw verbindende clients, zodat zij direct bij verbinding een actueel gemeenschappelijk operationeel beeld ontvangen. SA-feedabonnementen worden beheerd via het groepssysteem van de server — clients die aan dezelfde groep zijn toegewezen, delen automatisch BFT-sporen zonder handmatige abonnementsconfiguratie.

Hoe voorkom ik dat BFT-sporen tegelijk op geclassificeerde en ongeclassificeerde ATAK-instanties verschijnen?

Classificatiescheiding in een TAK BFT-omgeving wordt bereikt via een combinatie van groepsisolatie aan serverszijde en fysieke netwerkscheiding. Wijs op TAK Server geclassificeerde eenheden toe aan een groep die niet zichtbaar is voor ongeclassificeerde clients (bijvoorbeeld een 'SECRET'-groep zonder federatie of abonnement op de groep 'UNCLASSIFIED'). Voor harde scheiding voert u twee volledig gescheiden TAK Server-instanties — één op een geclassificeerd netwerksegment en één op een ongeclassificeerd segment — zonder federatielink ertussen. Vertrouw nooit uitsluitend op softwaregroepsfilters voor classificatiescheiding; fysieke of cryptografische netwerkscheiding is vereist om te voldoen aan informatiebeveiligingsnormen.

Wat gebeurt er met BFT-sporen als ATAK de verbinding met de TAK Server verliest?

Wanneer ATAK de serververbinding verliest, schakelt het over naar disconnected-modus. De kaart blijft de laatst ontvangen posities van alle sporen tonen, visueel onderscheiden door een stale-indicator (doorgaans een vervaagd icoon of tijdstempelannotatie) zodra de CoT stale-tijd van het spoor is verstreken. ATAK blijft ook de eigen positie verzenden via elke beschikbare lokale broadcast-pad (UDP-multicast, MANET-radio). Wanneer de verbinding is hersteld, verbindt ATAK automatisch opnieuw en duwt de server de actuele status van alle sporen als burst-update, waarbij de verouderde laatstbekende posities worden overschreven. Beheerders moeten stale-timeouts instellen die passen bij hun tactische tempo — een stale-venster van 10 minuten voorkomt spooksporen in omgevingen met slechte connectiviteit.

Hoeveel bandbreedte verbruikt BFT over ATAK op een MANET-verbinding?

Een enkel ATAK CoT-positie-event (CoT XML met detailblok) is ongeveer 800–1200 bytes. Bij een updateinterval van 10 seconden voor een peloton van 20 eenheden is het totale BFT-verkeer ongeveer 20 × 1000 bytes / 10s = 2 kB/s of ongeveer 16 kbps. Dit ligt ruim binnen de capaciteit van moderne MANET-radio's (MPU5 biedt 1–10 Mbps per knoop), maar stapelt zich snel op in grote formaties. Voor een compagnie van 100 eenheden met intervallen van 10 seconden nadert ruw BFT-verkeer 80 kbps — beheersbaar maar significant op HF- of satelliet-backhaul-verbindingen. CoT-compressie (zlib over de TCP-stream) verkleint de payload doorgaans met 40–60%, en adaptieve updatesnelheden kunnen de belasting met een ordegrootte verminderen tijdens statische fasen.

Welke Android-apparaten zijn gecertificeerd voor militaire BFT met ATAK?

ATAK MIL (de militaire variant die via TAK.gov wordt gedistribueerd) draait op een reeks geharde Android-apparaten. Vaak gebruikte platforms zijn de Samsung Galaxy XCover Pro, Getac PS336, Kyocera DuraForce Pro 2 en Dell Latitude Rugged-tablets. Voor BFT specifiek omvatten de selectiecriteria voor apparaten de gevoeligheid van de GPS-chipset (voor stedelijke canyons en bladbedekking), batterijcapaciteit (of hot-swap-mogelijkheid), bedrijfstemperatuurbereik en MIL-STD-810 schok- en waterbestendigheid. Apparaten met multi-constellatie-GNSS (GPS + GLONASS + Galileo) leveren betrouwbaardere positiefixes in gedegradeerde omgevingen dan GPS-only-chipsets.