Sinisen voiman seuranta (BFT, blue force tracking) on yksi merkittävimmistä kyvyistä, joita jalkaväkiyksikkö voi kantaa mukanaan: mahdollisuus nähdä lähes reaaliajassa, missä jokainen oma elementti kartalla on. Vuosia tämä kyky oli kalliiden erikoisvalmisteisten päätteiden yksinoikeus. ATAKia (Android Team Awareness Kit) ajavat Android-alustat ovat muuttaneet yhtälön — varusteltu älypuhelin tai tabletti MANET-radion kanssa toimittaa nyt jatkuvan BFT:n murto-osalla vanhan laitteiston hinnasta, avoimella liitännäisarkkitehtuurilla, joka antaa mukautettujen anturisyötteiden, tekoälykerrosten ja tehtävänsuunnittelutyökalujen toimia seurantakerroksen rinnalla. Tämä artikkeli kattaa koko BFT-pinon: CoT-sijaintitapahtuman skeeman, ATAKin SA-määritykset, TAK Serverin syötteiden hallinnan, MANET-radion siirtointegraation, päivitystaajuuden ja akun profiloinnin sekä järjestelmän käyttäytymisen, kun yhteys katkeaa.
BFT-vaatimukset taktisille yksiköille
Ennen ohjelmistomäärityksiin ryhtymistä BFT-käyttöönotto vaatii eksplisiittisen vaatimusperustan. Parametrit, jotka ohjaavat jokaista myöhemmää päätöstä, ovat sijaintitarkkuus, päivitystaajuus, näyttöviive sekä käytössä olevien laitteiden ja radioiden asettamat rajoitukset.
Sijaintitarkkuus. Jalkaväen BFT tähtää 10 metrin tai parempaan ympyränmuotoiseen todennäköisvirheeseen (CEP) — riittävä tasaisesti rakennetussa maastossa tapahtuvaan törmäyksenestoon, jossa rakennustason erotuskyky merkitsee. Ajoneuvoasennettu BFT hyväksyy tyypillisesti CEP 50 m. Usean satelliittijärjestelmän GNSS-laitteet (GPS + GLONASS + Galileo) saavuttavat 3–5 m CEP:n avoimessa maastossa; tiheä kasvillisuus tai kaupunkilaaksot heikentävät sitä 15–30 m:ään ilman täydennystä. SBAS (WAAS/EGNOS) avustaa ATAK-yhteensopivien laitteiden GNSS-vastaanottimia ja tiukentaa tarkkuutta entisestään tuetuilla maantieteellisillä alueilla.
Päivitystaajuus. Sijainnin päivitystaajuus määrittää, kuinka ajantasaiset viereisten yksiköiden karttojen jäljet ovat. 5–10 sekunnin välit ovat vakiota yksiköille, jotka ovat suorassa kosketuksessa tai toimivat lähekkäin. 30–60 sekunnin välit riittävät tuki- tai reserviyksiköille. Päivitystaajuus kertoo suoraan kanavakuormaa: jokainen yksiköiden määrän kaksinkertaistaminen tai päivitysvälin puolittaminen kaksinkertaistaa kaistanleveyden kulutuksen jaetussa radioverkossa.
Näyttöviive. Päästä päähän -näyttöviiven — sijaintitapahtuman syntymisestä lähtälaitteella jäljen ilmestymiseen kaikissa yhdistetyissä näytöissä — on pysyttävä alle 3 sekunnissa operaatioissa, joissa törmäyksenesto riippuu reaaliaikaisesta sijainnista. Viiveen osasia ovat GPS-paikkaratkaisun aika, CoT-tapahtuman muodostus, radiolähetys, palvelimen käsittely ja asiakkaan renderöinti. Hyvin määritetyssä MANET-verkossa paikallisen TAK Serverin kanssa kokonaisviive on tyypillisesti 500 ms–1.5 s. Satelliittikantaviestinkokoonpanot lisäävät 600 ms–1.2 s yksisuuntaista viivettä.
Laite- ja radiorajoitukset. BFT:ssä käytetyt varustellut Android-laitteet — Samsung XCover Pro, Kyocera DuraForce Pro 2, Getac PS336 — kantavat akut, jotka on mitoitettu 8–16 tunnin vuoroille, mutta GPS ja radiolähetykset kuluttavat kyseistä kapasiteettia voimakkaasti. MANET-radiot yhdistyvät tyypillisesti USB OTG:n tai Wi-Fi-yhteyspisteen kautta; itse yhteyspisteyhteys lisää antenni- ja RF-kuormaa. Lämpörajat kuumissa olosuhteissa alentavat kestävää lähetystehoa sekä Android-laitteella että radiolla, mikä voi lyhentää tehokasta kantamaa ja siksi vaatia lyhyempiä päivitysvälejä kasvanutta pakettihävikkiä kompensoimaan.
Cursor on Target (CoT) -sijaintitapahtumat
CoT-standardi määrittelee XML-tapahtumaskeeman, jota jokainen BFT-verkon elementti puhuu. Skeeman ymmärtäminen on välttämätöntä BFT-häiriöiden diagnosoimiseksi ja mukautettujen liitännäisten kirjoittamiseksi, jotka syöttävät tai kuluttavat sijaintitietoa.
CoT XML -skeema SA-tapahtumille
Minimaalinen oman maavoimien yksikön sijaintitapahtuma näyttää tältä:
<?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>BFT:n avainkentät ovat:
- uid — jäljen yksilöivä tunniste. Sen on pysyttävä vakiona sijaintipäivitysten yli; ATAK käyttää laitteen IMEI:tä tai luotua UUID:tä.
- type — CoT-tyyppikoodi (katso alla), joka koodaa kuuluvuuden, ulottuvuuden ja alustatyypin.
- time / start — tapahtuman luonnin aikaleima ISO 8601 UTC -muodossa. Kellon tarkkuus on tässä kriittistä: kellojen siirtymä aiheuttaa vanhentuneisuuden hylkäämisen vastaanottavalla palvelimella.
- stale — aikaleima, jonka jälkeen tapahtuma katsotaan vanhentuneeksi. ATAK asettaa oletuksena stale-ajan kohdan time + (update interval × 3), mikä sallii kolme ohitettua päivitystä ennen kuin jäljestä tulee haamu.
- how — sijainnin saantitapa:
m-g(koneen GPS),h-g-i-g-o(ihmisen syöttämä GPS),m-g-i(päätelty GPS). - point — WGS84-koordinaatit: lat/lon desimaaliasteina, hae (korkeus WGS84-ellipsoidin yläpuolella) metreinä, ce (ympyrävirhe) ja le (lineaarivirhe) metreinä.
CoT-tyyppikoodit omalle, viholliselle ja neutraalille
CoT-tyyppikoodit noudattavat hierarkkista kaavaa: a-[affiliation]-[battle dimension]-[function]. BFT:ssä kuuluvuusmerkki on kriittinen erottaja:
| Tyyppietuliite | Kuuluvuus | ATAK-kuvakkeen väri | Esimerkki |
|---|---|---|---|
a-f- |
Oma | Sininen | a-f-G-U-C — oman maavoimien yksikkö, taistelu |
a-h- |
Vihollinen | Punainen | a-h-G-U-C — vihollisen maavoimien yksikkö, taistelu |
a-n- |
Neutraali | Vihreä | a-n-G-E-V-C — neutraali maastoajoneuvo, siviili |
a-u- |
Tuntematon | Keltainen | a-u-G-U — tuntematon maavoimien yksikkö |
Vanhentumisaikakatkaisun hallinta
Vanhentumisaikaleima on ensisijainen mekanismi jälkien siivoamiseen yhteisoperaatiokuvasta (COP). ATAKin oletusvanhentumiskerroin on 3× määritetty SA-päivitysväli: 10 sekunnin päivitystaajuudella stale asetetaan 30 sekunnin päähän tulevaisuuteen. Jos kolme peräkkäistä sijaintitapahtumaa katoaa (pakettihävikki, radiohäiriö, laitteen sammutus), jälki siirtyy vanhentuneeseen tilaan ja ATAK piirtää sen haalistuneella kuvakkeella. Operaattorin säädettävän armoajan (oletus 5 minuuttia useimmissa käyttöönotoissa) jälkeen vanhentunut jälki poistetaan kartalta kokonaan.
Korkean pakettihävikin ympäristöjen BFT:ssä (tiheä kaupunkirakenne, viidakon latvusto, SATCOM-kantaviestiset linkit) nosta vanhentumiskerrointa 6–10×:aan liiallisen jälkien haamumisen välttämiseksi. Tämä määritetään laitekohtaisesti ATAKissa kohdasta Settings → Network → SA Reporting → Stale Timer. TAK Serverin puolella palvelimen oma vanhentumiskynnys (oletus 600 sekuntia) ohjaa, kuinka kauan palvelin säilyttää jäljen tietokannassaan ennen sen vanhentumista — äskettäin yhdistävät asiakkaat eivät saa jälkiä, jotka ovat ylittäneet palvelimen vanhentumiskynnyksen.
ATAK BFT-asiakkaana
ATAK hoitaa BFT:n kokonaan SA-alijärjestelmällään (situational awareness, tilannekuva). Perus-BFT:hen ei tarvita lisäliitännäistä — kyky on sisäänrakennettu ATAK-perussovellukseen. Liitännäiset laajentavat BFT:tä mukautetuilla tietolähteillä, näyttökerroksilla ja lähetyspoluilla standardipalvelin- ja multicast-vaihtoehtojen ulkopuolelle.
SA-määritykset ATAKissa
Pääasialliset BFT-määritysasetukset ovat kohdassa Settings → Network → Reporting Preferences:
- Reporting Rate (Moving) — CoT-lähetysväli, kun laite on liikkeessä. Aseta 5–10 s jalkaväelle, 3–5 s ajoneuvoasennukseen ulkoisella virransyötöllä.
- Reporting Rate (Stationary) — väli, kun laite ei ole liikkunut liikekynnyksen yli. Aseta 30–120 s akun säästämiseksi staattisissa vaiheissa.
- Dynamic SA Reporting — kun käytössä, ATAK vaihtaa automaattisesti liikkumis- ja paikallaanolotaajuuden välillä kiihtyvyysanturin perusteella. Tämä on suositeltu tila kaikille operatiivisille BFT-käyttöönotoille.
- My Team — liittää laitteen ryhmään (Cyan, Magenta, Yellow jne.), mikä määrittää kuvakkeen värin, jonka muut yksiköt näkevät tästä jäljestä, ja ohjaa palvelinpuolen ryhmäsuodatusta.
- My Role — asettaa toimintoalatyypin CoT-tyyppikoodiin (Team Member, Team Leader, HQ, Medic, Forward Observer jne.).
Verkkoyhteyden tyypit
ATAK tukee kolmea verkkoyhteyden tyyppiä BFT-datan toimittamiseen:
TCP/TLS TAK Serveriin (portti 8089). Tämä on vakiintunut operatiivinen tila. ATAK muodostaa pysyvän TLS-yhteyden, joka todennetaan PKCS#12-asiakasvarmenteella. Palvelin toimittaa kaikki tilatut jäljet asiakkaalle tämän yhteyden kautta ja vastaanottaa asiakkaan sijaintitapahtumat jaeltavaksi. TCP tarjoaa luotettavan toimituksen ja tukee suuria viestihyötykuormia (tehtäväpaketit, datapaketit) CoT-tapahtumien lisäksi.
UDP-multicast. ATAK voi lähettää ja vastaanottaa CoT-tapahtumia UDP-multicast-osoitteessa (oletus 239.2.3.1:6969). Tämä tila toimii ilman palvelininfrastruktuuria — laitteet löytävät toisensa jaetun multicast-ryhmän kautta. Se sopii vertaisverkon BFT:hen paikallisilla verkkosegmenteillä (Wi-Fi-yhteyspiste tai MANET-radion paikallinen IP-avaruus), mutta ei tue federaatiota, suodatusta tai pysyvää jälkihistoriaa. Pakettihävikkiä multicast-tilassa ei lähetetä uudelleen: ohittanut sijaintitapahtuma ei yksinkertaisesti ilmesty.
TCP-suoratoisto (vanha). Vanhempi salaamaton XML-virratila, nyt poistettu käytöstä TLS:n hyväksi. Älä käytä sitä missään operatiivisessa käyttöönotossa.
Liitännäisarkkitehtuuri mukautettuihin BFT-syötteisiin
ATAKin liitännäisrajapinta antaa kolmansien osapuolten sovellusten syöttää CoT-tapahtumia paikalliselle ATAK-kartalle ilman reititystä palvelimen kautta. Mukautettu BFT-liitännäinen voi vastaanottaa sijaintidataa patentoitua radioaaltomuodosta, laitteistoseurantalaitteesta (USB-sarjaliitännän kautta) tai tekoälyn tuottamasta sijaintiarviosta ja syöttää sen standardina CoT-tapahtumana, joka näkyy ATAK-näytöllä. Liitännäinen kommunikoi ATAK-ytimen kanssa CotMapComponent-intent-rajapinnan kautta lähettämällä com.atakmap.android.maps.COT_RECEIVER-broadcast-intenttejä CoT XML -hyötykuormalla. Yksityiskohtainen läpikäynti liitännäiskehityksestä on oppaassamme ATAK-integraation kenttäoperaatiot.
TAK Serverin SA-syötteiden hallinta
TAK Server on keskus, joka kokoaa BFT-sijaintitapahtumat kaikista yhdistetyistä ATAK-asiakkaista ja jakaa ne tilaajille. Palvelimen oikea määritys on yhtä tärkeää luotettavan BFT:n kannalta kuin asiakkaan asetukset.
Palvelinfederaatio yksiköiden väliseen tilannekuvaan
Kun BFT:n on katettava useita itsenäisiä TAK Server -instansseja — esimerkiksi komppanian palvelin ja pataljoonan palvelin tai eteen ja taakse sijoitetut osat — TAK Server -federaation käyttöönotto tarjoaa kytkennän. Federaatio välittää valitut CoT-tyypit palvelinrajan yli lähes reaaliajassa. BFT:ssä määritä federaatiosuodatin päästämään a-f--tapahtumat (oma atomi) molempiin suuntiin. Älä päästä a-h--tapahtumia (vihollinen) federaatiorajojen yli, ellei luokittelun käsittelyä molemmissä päissä ole varmistettu — vihollisen sijaintitiedustelu on usein arkaluontoisempaa kuin oman osapuolen sijaintidata.
SA-syötteen tilaus ja ryhmäeristys
TAK Server hallitsee ryhmäjärjestelmällään, mitkä asiakkaat saavat mitkä jäljet. Kun ATAK-asiakas yhdistää varmenteella, joka on liitetty ryhmään ”PLATOON-1”, se saa automaattisesti kaikki CoT-tapahtumat muilta saman ryhmän asiakkailta sekä niiltä ryhmiltä, jotka PLATOON-1 on määritetty näkemään (esim. ”COMPANY-HQ”). Tämä ryhmäpohjainen tilausmalli poistaa tarpeen asiakaskohtaisille jälkitilausmäärityksille — ryhmäjäsenyys määrittää koko tilannekuvan.
Käyttäjäryhmien eristys on myös mekanismi luokitteluerotteluun. Liitä SALAISEN verkon ATAK-asiakkaat ryhmään, jonka näkyvyys ei ole päällekkäinen ei-salaisten ryhmien kanssa. Palvelin ei koskaan reititä SALAISIA jälkiä ei-salaisille asiakkaille riippumatta CoT-tyypistä tai sisällöstä. Kovia luokittelurajoja varten aja täysin erillisiä TAK Server -instansseja fyysisesti erillisillä verkkosegmenteillä ilman federaatiolinkkiä niiden välillä.
CloudTAKin SA-syötteen määritys
# 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"]'direction-kenttä ohjaa, onko ryhmä tulosyöteryhmä (tapahtumat virtaavat SISÄÄN tältä asiakkaalta), lähtöryhmä (tapahtumat virtaavat ULOS tälle asiakkaalle) vai MOLEMMAT. MOLEMMAT-asetus on BFT:ssä vakio — jokainen laite sekä tuottaa että vastaanottaa jälkiä sille määritetyissä ryhmissä.
Mesh-radio siirtotienä BFT:lle
Radiolinkki on operatiivisesti rajoitetuin elementti Android-BFT-pinossa. MANET-radiot tarjoavat vertaisverkkomaisen IP-verkon, joka yhdistää ATAK-laitteet, kun Wi-Fi-infrastruktuuria ja matkaviestiverkon kattavuutta ei ole saatavilla. ATAKin ja MANET-laitteiston integraation ymmärtäminen on kriittistä ennustettavan BFT-suorituskyvyn kannalta jalkaisoperaatioissa. Artikkelimme sotilaallisesta MANET-mesh-verkosta käsittelee taustalla olevaa verkkokerrosta yksityiskohtaisesti; tämä osio keskittyy nimenomaan ATAK-integraatioon.
MANET-radion integrointi ATAKiin
Harris RF-7800W (Falcon III). RF-7800W yhdistyy Android-laitteeseen USB OTG:n kautta ja tarjoaa RNDIS-verkkoliitännän (USB-Ethernet). Radion IP-osoite tässä liitännässä on tyypillisesti 192.168.100.1. ATAK käsittelee RNDIS-liitännän tavallisena verkkoliitännänä — erillistä ajuria tai kumppanisovellusta ei tarvita. Määritä ATAKin palvelinyhteys osoittamaan TAK Serverin IP-osoitteeseen sellaisenaan, kuin se on tavoitettavissa radion mesh-verkon kautta. Paikalliseen palvelimettomaan vertaisverkon BFT:hen määritä ATAKin UDP-multicast-lähtö RNDIS-liitännän osoitteeseen.
Persistent Systems MPU5. MPU5 toimii Wi-Fi-tukiasemana tai USB RNDIS -laitteena. Tukiasematilassa Android-laite yhdistyy MPU5:n Wi-Fi-SSID:hen; radion hallinta-IP on oletuksena tavoitettavissa osoitteesta 10.168.1.1. Persistent Systems tarjoaa Android-kumppanisovelluksen (Wave Relay Mobile), joka integroituu ATAKiin ja tuo aaltomuodon tilan, solmukartan ja linkin laadun mittarit natiivina ATAK-kerroksena. ATAK CoT -tapahtumat kulkevat standardia TCP- tai UDP-polkuja MPU5:n IP-meshin läpi.
Kaistanleveyden allokointi SA-liikenteelle
BFT:n kaistanleveysbudjetin kvantifiointi ennen käyttöönottoa estää mesh-verkon ylikuormittumisen pahimpaan mahdolliseen hetkeen. Yksi CoT-sijaintitapahtuma täydellä yksityiskohtaisuuslohkolla on 800–1200 tavua. 10 sekunnin päivitysvälillä 12 hengen ryhmälle:
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% — significantKomppanian mittakaavassa (yli 100 yksikköä 10 sekunnin välein) raaka BFT-kuorma ylittää 80 kbps ennen protokollayleiskustannuksia — merkittävä osuus mistä tahansa HF- tai SATCOM-kantaviestistä. Näissä olosuhteissa nosta paikallaanolopäivitysvälit yli 120 sekuntiin ja nojaa liikkeellä laukaisemiin purskeisiin pitääksesi kokonaiskuorman alle 20 kbps kantaviestilinkissä.
Sijainnin päivitystaajuus vs. akun kesto
Sijainnin päivitystaajuus on yksittäisenä BFT-määritysparametrina merkittäin akun kestolle. GPS-hankinta ja radiolähetys ovat kaksi suurinta virrankuljettajaa ATAK BFT -laitteessa; molemmat skaalautuvat suoraan päivitystaajuuden mukaan.
Akun profilointi operatiivisissa olosuhteissa
Samsung Galaxy XCover Prolla (4050 mAh:n akku), joka ajaa ATAKia jatkuvalla GPS-lukituksella:
| Päivitystaajuus | GPS-kulutus | Radion kulutus (MPU5-yhteyspiste) | Arvioitu BFT-kesto |
|---|---|---|---|
| 5 s (aggressiivinen) | ~120 mA | ~180 mA | ~8–9 h |
| 10 s (vakio) | ~120 mA | ~120 mA | ~10–12 h |
| 30 s (partio) | ~90 mA | ~60 mA | ~15–18 h |
| 120 s (staattinen) | ~60 mA | ~20 mA | ~22–26 h |
GPS-kulutus on suhteellisen vakio päivitystaajuudesta riippumatta, koska ATAK pitää GPS-vastaanottimen jatkuvassa seurantatilassa varmistaakseen, että sijainti on aina ajantasainen, kun päivitys laukeaa. Muuttuja on radion lähetyksen täyttösuhte: 5 sekunnin välein radio on aktiivinen lähes jatkuvasti; 120 sekunnin välein lähetyspurskeet vievät vain 1–2 % täyttösuhteesta.
Mukautuvat päivitystaajuusstrategiat
ATAKin Dynamic SA Reporting -tila toteuttaa kaksitaajuisen mukautuvan strategian. Hienostuneempi lähestymistapa käyttää ATAK-liitännäisiä tai palvelinpuolen työntökomentoja päivitystaajuuksien säätämiseen operatiivisen kontekstin perusteella:
- Liikepohjainen taajuudenvaihto — kiihtyvyysanturin laukaisema: jos laite on liikkunut yli 10 m viimeisen lähetyksen jälkeen, lähetä heti riippumatta aikataulutetusta välistä. ATAK toteuttaa tämän natiivisti Dynamic SA -tilassa.
- Maantieteellisen aidan laukaisemat päivityspurskeet — kun yksikkö ylittää määritetyn geofence-rajan (tavoitealueelle saapuminen, vaihdelinjan ylitys), laukaise 5 sekunnin purskepäivitystaajuus 60 sekunnin ajaksi ja palaa sitten taustataajuuteen. Määritä geofence-laukaisimet ATAK-geofence-liitännäisillä tai TAK Serverin geofence-rajapinnalla.
- Kontaktipohjainen taajuuden korotus — kun TAK Server havaitsee vihollisen jäljen määritetyllä säteellä oman yksikön läheisyydestä, se lähettää työntöilmoituksen oman yksikön ATAK-asiakkaalle palvelimelta asiakkaalle -CoT-kanavan kautta, mikä laukaisee asiakkaan vaihtamaan nopeaan päivitystaajuuteensa. Tämä vaatii mukautetun palvelinpuolen liitännäisen tai tekoälyintegraatiokerroksen.
- Akukynnykseen perustuva taajuuden alennus — laitehallinta-agentti (MDM-profiili tai ATAK-liitännäinen) valvoo laitteen akkua ja nostaa automaattisesti SA-väliä, kun akku putoaa alle 30 %, vaihtaen sijainnin ajantasaisuuden jatkuvaan toimintaan kriittisen vaiheen läpi.
Tilannekuva yhteydettömässä tilassa
Mikään MANET-radioverkko ei toimi täydellisesti koko operatiivisen alueen yli. Maaston peittävyys, elektroninen sodankäynti, radiovika ja tarkoituksellinen emcon (lähetysten rajoitus) tuottavat kaikki yhteydettömiä toimintajaksoja. Kestävän BFT-suunnittelun on määriteltävä tarkasti, mitä järjestelmä tekee, kun radiolinkki puuttuu.
Viimeksi tunnetun sijainnin näyttö
Kun ATAK menettää yhteyden TAK Serveriin (tai multicast-vastaanoton vertaisverkkotilassa), se näyttää edelleen kaikki jäljet viimeksi vastaanotetuissa sijainneissaan. Nykyisten ja vanhentuneiden jälkien visuaalinen erottelu perustuu CoT-vanhentumisaikaleimaan: kun jäljen vanhentumisaika ylittyy, ATAK piirtää sen läpinäkyvyyskerroksella ja aikaleimamerkinnällä, joka näyttää, kuinka kauan sitten sijainti viimeksi vastaanotettiin. Jäljet pysyvät tässä vanhentuneessa tilassa, kunnes ne saavuttavat ATAK-kartan vanhentuneisuuden poistokynnyksen (käyttöönottoittain säädettävä; oletus 5 minuuttia).
Operaattorit on koulutettava tunnistamaan vanhentuneiden jälkien ilmaisimet ja toimimaan niiden mukaan. 3 minuuttia vanha jälkisijainti jalkaiselle yksikölle jalkaväen vauhdissa voi edustaa 180–360 metrin todellista siirtymää — riittävästi aiheuttamaan oman tulen riskin, jos sitä pidetään ajantasaisena. SOP:n tulee määrittää, että vanhentuneita jälkiä käytetään vain yleiseen aluetietoisuuteen, ei tulituen törmäyksenestoon.
Paikanlaskunäytön integraatio
ATAK tukee paikanlaskuun perustuvaa jäljen ekstrapolointia CoT-tapahtumien track-yksityiskohtaelementin kautta, joka kantaa nopeuden ja kurssin. Kun jälki vanhenee, paikanlaskuliitännäinen voi projektoida jäljen arvioidun nykysijainnin eteenpäin viimeksi tunnetusta paikasta ilmoitettuja nopeus- ja kurssivektoreita käyttäen. Projisoitu sijainti näytetään erillisellä kuvakkeella (tyypillisesti avoin tai katkoviivainen symboli), jotta se erottuu GPS-varmistetusta sijainnista.
Paikanlaskun tarkkuus heikkenee nopeasti jalkaiselle jalkaväelle (nopeus ja kurssi muuttuvat jatkuvasti) ja on luotettavampaa ajoneuvoille tunnetuissa tieverkoissa. Ota paikanlaskunäyttö käyttöön vain, kun operaattorit ymmärtävät sen rajoitukset ja SOP erottaa selkeästi projisoidut sijainnit vahvistetuista.
Uudelleenyhdistäminen ja SA-täsmäytys
Kun ATAK yhdistää uudelleen TAK Serveriin yhteydettömän jakson jälkeen, palvelin suorittaa täyden SA-tilatyönnön: se toimittaa nykyisen (tai viimeisimmän) CoT-tapahtuman jokaisesta jäljestä asiakkaan tilaamissa ryhmissä. Tämä purskepäivitys korvaa vanhentuneet viimeksi tunnetut sijainnit asiakkaan kartalla palvelimen nykyisellä datalla. Täsmäytysprosessi valmistuu 1–3 sekunnissa tyypillisille yksikkökokoille (alle 200 jälkeä).
# 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 clientsYksi suunniteltava rajatapaus: jos yhteydetön jakso ylittää palvelimen vanhentumiskynnyksen (CloudTAKissa oletus 600 sekuntia), palvelin on jo poistanut vanhentuneet jäljet aktiivisesta varastostaan. Uudelleenyhdistyksessä nämä jäljet eivät ilmesty purskepäivitykseen, vaan ne palaavat vasta, kun lähdelaitteet lähettävät uusia sijaintitapahtumia. Operaatioissa, joissa uudelleenyhdistykset voivat seurata monituntisia viestintäkatkoja, nosta palvelimen vanhentumiskynnys vastaamaan odotettua suurimman katkon kestoa.