Aplikacje polowe

BFT na wojskowych urządzeniach Android: ATAK, CoT i architektura sieci

Autor: Zespół inżynierów Corvus Intelligence · O zespole →

25 czerwca 2026 11 min czytania

Śledzenie sił własnych (BFT) to jedna z najważniejszych zdolności, jakie może nieść jednostka piesza: możliwość zobaczenia w czasie bliskim rzeczywistemu, gdzie na mapie znajduje się każdy element własny. Przez lata zdolność ta była wyłączną domeną drogich, dedykowanych terminali. Platformy oparte na Androidzie z ATAK (Android Team Awareness Kit) zmieniły tę równowagę — wzmocniony smartfon lub tablet z radiostacją MANET dostarcza teraz stałe BFT ułamek kosztów sprzętu starszej generacji, z otwartą architekturą wtyczek, która pozwala współistnieć warstwie śledzenia z własnymi strumieniami czujników, nakładkami AI i narzędziami planowania misji. Artykuł omawia pełny stos BFT: schemat zdarzeń pozycji CoT, konfigurację SA w ATAK, zarządzanie strumieniami TAK Server, integrację transportu radiostacji MANET, profilowanie kompromisu częstotliwości aktualizacji a baterii oraz zachowanie systemu po utracie łączności.

Wymagania BFT dla jednostek taktycznych

Przed konfiguracją oprogramowania wdrożenie BFT wymaga jawnego zestawu wymagań bazowych. Parametry kierujące każdą późniejszą decyzją to dokładność pozycji, częstotliwość aktualizacji, opóźnienie wyświetlania oraz ograniczenia narzucone przez używane urządzenia i radiostacje.

Dokładność pozycji. BFT piechoty pieszej celuje w błędne prawdopodobne koło (CEP) 10 metrów lub lepiej — wystarczające do rozdzielenia w terenie zurbanizowanym, gdzie liczy się rozdzielczość na poziomie budynku. BFT jednostek zmotoryzowanych zazwyczaj akceptuje CEP 50 m. Urządzenia Android z wielokonstelacyjnym GNSS (GPS + GLONASS + Galileo) osiągają CEP 3–5 m na otwartym terenie; gęsta roślinność lub kaniony miejskie degradują to do 15–30 m bez augmentacji. SBAS (WAAS/EGNOS) wspiera odbiorniki GNSS w urządzeniach zgodnych z ATAK, dodatkowo poprawiając dokładność na obsługiwanych obszarach geograficznych.

Częstotliwość aktualizacji. Częstotliwość aktualizacji pozycji decyduje o tym, jak aktualne są ścieżki na mapach sąsiednich jednostek. Interwały 5–10 sekund są standardem dla jednostek w bezpośrednim kontakcie lub prowadzących działania w bliskim sąsiedztwie. Interwały 30–60 sekund wystarczają dla jednostek na pozycjach wsparcia lub odwodu. Częstotliwość aktualizacji bezpośrednio mnoży obciążenie kanału: każde podwojenie liczby jednostek lub skrócenie interwału aktualizacji o połowę podwaja zużycie przepustowości w wspólnej sieci radiowej.

Opóźnienie wyświetlania. Opóźnienie wyświetlania end-to-end — od wygenerowania zdarzenia pozycji na urządzeniu źródłowym do pojawienia się ścieżki na wszystkich podłączonych wyświetlaczach — musi pozostać poniżej 3 sekund w operacjach, gdzie rozdzielenie zależy od pozycji w czasie rzeczywistym. Składowe opóźnienia to czas ustalenia pozycji GPS, generowanie zdarzenia CoT, transmisja radiowa, przetwarzanie na serwerze i renderowanie u klienta. Na dobrze skonfigurowanej sieci MANET z lokalnym TAK Server całkowite opóźnienie mieści się zwykle w przedziale 500 ms–1,5 s. Konfiguracje z transmisją satelitarną dodają 600 ms–1,2 s opóźnienia w jedną stronę.

Ograniczenia urządzeń i radiostacji. Wzmocnione urządzenia Android używane do BFT — Samsung XCover Pro, Kyocera DuraForce Pro 2, Getac PS336 — mają baterie dobrane do zmian 8–16 godzinnych, ale GPS i transmisje radiowe mocno obciążają tę pojemność. Radiostacje MANET łączą się zwykle przez USB OTG lub punkt dostępowy Wi-Fi; samo połączenie hotspotowe dodaje obciążenie antenowe i RF. Limity termiczne w gorących środowiskach zmniejszają zrównoważoną moc nadawczą zarówno urządzenia Android, jak i radiostacji, potencjalnie skuteczny zasięg, a więc wymagając krótszych interwałów aktualizacji dla kompensacji zwiększonej straty pakietów.

Zdarzenia pozycji Cursor on Target (CoT)

Standard CoT definiuje schemat zdarzeń XML, którym posługuje się każdy element w sieci BFT. Zrozumienie schematu jest niezbędne do diagnozowania awarii BFT oraz do pisania własnych wtyczek wstrzykujących lub konsumujących dane pozycji.

Schemat XML CoT dla zdarzeń SA

Minimalne zdarzenie pozycji własnej jednostki lądowej wygląda tak:

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

Kluczowe pola dla BFT to:

uid — unikalny identyfikator ścieżki. Musi pozostawać stabilny między aktualizacjami pozycji; ATAK używa IMEI urządzenia lub wygenerowanego UUID.
type — kod typu CoT (patrz niżej) kodujący przynależność, wymiar i typ platformy.
time / start — znacznik czasu generowania zdarzenia w ISO 8601 UTC. Dokładność zegara jest tu krytyczna: rozbieżność zegara powoduje odrzucanie zdarzeń jako nieaktualnych przez serwer odbierający.
stale — znacznik czasu, po którym zdarzenie uważa się za wygasłe. ATAK domyślnie ustawia „stale” na time + (interwał aktualizacji × 3), dając trzy pominięte aktualizacje, zanim ścieżka stanie się duchem.
how — metoda wprowadzenia pozycji: m-g (maszynowe GPS), h-g-i-g-o (GPS wprowadzony przez człowieka), m-g-i (GPS wywnioskowany).
point — współrzędne WGS84: lat/lon w stopniach dziesiętnych, hae (wysokość ponad elipsoidą WGS84) w metrach, ce (błąd kołowy) i le (błąd liniowy) w metrach.

Kody typów CoT dla sił własnych, wroga i neutralnych

Kody typów CoT podążają za schematem hierarchicznym: a-[przynależność]-[wymiar pola walki]-[funkcja]. Dla BFT znak przynależności jest krytycznym dyskryminatorem:

Prefiks typu	Przynależność	Kolor ikony ATAK	Przykład
`a-f-`	Własna	Niebieski	`a-f-G-U-C` — własna jednostka lądowa, bojowa
`a-h-`	Wroga	Czerwony	`a-h-G-U-C` — wroga jednostka lądowa, bojowa
`a-n-`	Neutralna	Zielony	`a-n-G-E-V-C` — neutralny pojazd lądowy, cywilny
`a-u-`	Nieznana	Żółty	`a-u-G-U` — nieznana jednostka lądowa

Zarządzanie limitem czasu „stale”

Znacznik czasu „stale” to podstawowy mechanizm czyszczenia ścieżek z COP. Domyślny mnożnik „stale” w ATAK to 3× skonfigurowanego interwału aktualizacji SA: przy częstotliwości aktualizacji 10 sekund „stale” ustawiane jest 30 sekund w przyszłości. Jeśli trzy kolejne zdarzenia pozycji zostaną utracone (strata pakietów, zanik łączności radiowej, wyłączenie urządzenia), ścieżka wchodzi w stan nieaktualności i ATAK renderuje ją z wyblakłą ikoną. Po okresie karencji konfigurowalnym przez operatora (domyślnie 5 minut w większości wdrożeń) nieaktualna ścieżka jest całkowicie usuwana z mapy.

Dla BFT w środowiskach o wysokiej stracie pakietów (gęsta zabudowa, korona dżungli, łącza z transmisją satelitarną) zwiększ mnożnik „stale” do 6–10×, aby uniknąć nadmiernego pojawiania się duchów ścieżek. Konfiguruje się to per urządzenie w ATAK w Ustawienia → Sieć → Raportowanie SA → Stale Timer. Po stronie TAK Server własny próg nieaktualności serwera (domyślnie 600 sekund) decyduje, jak długo serwer przechowuje ścieżkę w bazie przed jej wygaśnięciem — nowo łączący się klienci nie otrzymają ścieżek przekraczających próg nieaktualności serwera.

ATAK jako klient BFT

ATAK obsługuje BFT wyłącznie przez swój podsystem SA (świadomość sytuacyjna). Do podstawowego BFT nie jest wymagana żadna dodatkowa wtyczka — zdolność jest wbudowana w rdzeń aplikacji ATAK. Wtyczki rozszerzają BFT o własne źródła danych, nakładki wyświetlania i ścieżki transmisji poza standardowymi opcjami serwera i multicastu.

Konfiguracja SA w ATAK

Podstawowe elementy sterujące konfiguracją BFT znajdują się w Ustawienia → Sieć → Preferencje raportowania:

Częstotliwość raportowania (w ruchu) — interwał transmisji CoT, gdy urządzenie jest w ruchu. Ustaw 5–10 s dla piechoty pieszej, 3–5 s dla jednostek zmotoryzowanych z zasilaniem zewnętrznym.
Częstotliwość raportowania (postój) — interwał, gdy urządzenie nie przekroczyło progu ruchu. Ustaw 30–120 s, aby oszczędzać baterię w fazach statycznych.
Dynamiczne raportowanie SA — po włączeniu ATAK automatycznie przełącza między częstotliwościami ruchu i postoju na podstawie akcelerometru. To zalecany tryb dla wszystkich operacyjnych wdrożeń BFT.
Mój zespół — przypisuje urządzenie do grupy (Cyan, Magenta, Yellow itp.), która decyduje o kolorze ikony widzianym przez inne jednostki dla tej ścieżki i steruje filtrowaniem grupowym po stronie serwera.
Moja rola — ustawia podtyp funkcji w kodzie typu CoT (członek zespołu, lider zespołu, sztab, medyk, obserwator przedni itp.).

Typy połączeń sieciowych

ATAK obsługuje trzy typy połączeń sieciowych do dostarczania danych BFT:

TCP/TLS do TAK Server (port 8089). To standardowy tryb operacyjny. ATAK nawiązuje stałe połączenie TLS uwierzytelnione certyfikatem klienckim PKCS#12. Serwer dostarcza klientowi wszystkie subskrybowane ścieżki przez to połączenie i odbiera zdarzenia pozycji klienta do dystrybucji. TCP zapewnia niezawodną dostawę i obsługuje duże ładunki komunikatów (pakiety misji, pakiety danych) obok zdarzeń CoT.

Multicast UDP. ATAK może nadawać i odbierać zdarzenia CoT na adresie multicast UDP (domyślnie 239.2.3.1:6969). Tryb ten działa bez jakiejkolwiek infrastruktury serwerowej — urządzenia odnajdują się nawzajem przez wspólną grupę multicast. Nadaje się do BFT peer-to-peer na lokalnych segmentach sieci (punkt dostępowy Wi-Fi lub lokalna przestrzeń IP radiostacji MANET), ale nie obsługuje federacji, filtrowania ani trwałej historii ścieżek. Straty pakietów w trybie multicast nie są retransmitowane: pominięte zdarzenie pozycji po prostu się nie pojawia.

Strumieniowanie TCP (starsze). Starszy, niezaszyfrowany tryb strumieni XML, obecnie wycofany na rzecz TLS. Nie używać w żadnym wdrożeniu operacyjnym.

Architektura wtyczek dla własnych strumieni BFT

API wtyczek ATAK pozwala aplikacjom zewnętrznym wstrzykiwać zdarzenia CoT do lokalnej mapy ATAK bez routowania przez serwer. Własna wtyczka BFT może odbierać dane pozycji z zastrzeżonej fali radiowej, sprzętowego urządzenia śledzącego (przez USB serial) lub szacunku pozycji wywnioskowanego przez AI i wstrzykiwać je jako standardowe zdarzenie CoT widoczne na wyświetlaczu ATAK. Wtyczka komunikuje się z rdzeniem ATAK przez interfejs intent CotMapComponent, publikując intencje rozgłoszeniowe com.atakmap.android.maps.COT_RECEIVER z ładunkiem XML CoT. Szczegółowy przewodnik rozwoju wtyczek zawiera nasz artykuł o integracji ATAK w operacjach polowych.

Zarządzanie strumieniami SA na TAK Server

TAK Server to centrum, które agreguje zdarzenia pozycji BFT ze wszystkich podłączonych klientów ATAK i rozdziela je do subskrybentów. Poprawna konfiguracja serwera jest równie ważna jak ustawienia klienta dla niezawodnego BFT.

Federacja serwerów dla SA między jednostkami

Gdy BFT musi obejmować wiele niezależnych instancji TAK Server — na przykład serwer kompanii i serwer batalionu, albo pierwszy i drugi rzut — konfiguracja federacji serwerów TAK zapewnia połączenie. Federacja przekazuje wybrane typy CoT przez granicę serwerów niemal w czasie rzeczywistym. Dla BFT skonfiguruj filtr federacji, aby przepuszczał zdarzenia a-f- (własne atomy) dwukierunkowo. Nie przepuszczaj a-h- (wrogie) przez granice federacji, chyba że obsługa klasyfikacji po obu stronach jest zweryfikowana — wywiad o pozycjach wroga bywa często bardziej wrażliwy niż dane o pozycjach własnych.

Subskrypcja strumieni SA i izolacja grupowa

TAK Server zarządza tym, którzy klienci otrzymują które ścieżki, przez system grup. Gdy klient ATAK łączy się z certyfikatem przypisanym do grupy „PLATOON-1”, automatycznie otrzymuje wszystkie zdarzenia CoT od innych klientów w tej samej grupie oraz z grup, które PLATOON-1 ma skonfigurowane do widoczności (np. „COMPANY-HQ”). Ten model subskrypcji oparty na grupach eliminuje potrzebę jakiejkolwiek konfiguracji subskrypcji ścieżek per klient — członkostwo w grupie decyduje o całym obrazie SA.

Izolacja grup użytkowników to również mechanizm separacji klasyfikacji. Przypisz klientów ATAK sieci SECRET do grupy bez nakładania widoczności z grupami UNCLASSIFIED. Serwer nigdy nie skieruje ścieżek SECRET do klientów UNCLASSIFIED, niezależnie od typu czy treści CoT. Dla twardych granic klasyfikacji uruchom całkowicie odrębne instancje TAK Server na fizycznie oddzielnych segmentach sieci bez łącza federacji między nimi.

Konfiguracja strumieni SA w CloudTAK

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

Pole direction decyduje, czy grupa jest grupą wejściową (zdarzenia wpływają OD tego klienta), wyjściową (zdarzenia wychodzą DO tego klienta) czy BOTH. Ustawienie BOTH jest standardem dla BFT — każde urządzenie zarówno wnosi, jak i odbiera ścieżki w swoich przypisanych grupach.

Transport radiowy mesh dla BFT

Łącze radiowe to najbardziej ograniczony operacyjnie element stosu BFT na Androidzie. Radiostacje MANET zapewniają sieć IP peer-to-peer łączącą urządzenia ATAK, gdy infrastruktura Wi-Fi i zasięg sieci komórkowych są niedostępne. Zrozumienie, jak ATAK integruje się ze sprzętem MANET, jest kluczowe dla przewidywalnych osiągów BFT w operacjach pieszych. Nasz artykuł o wojskowej sieci mesh MANET szczegółowo omawia warstwę sieciową; ta sekcja koncentruje się specifically na integracji z ATAK.

Integracja radiostacji MANET z ATAK

Harris RF-7800W (Falcon III). RF-7800W łączy się z urządzeniem Android przez USB OTG, udostępniając interfejs sieciowy RNDIS (USB Ethernet). Adres IP radiostacji na tym interfejsie to zazwyczaj 192.168.100.1. ATAK traktuje interfejs RNDIS jako standardowy interfejs sieciowy — nie jest wymagany żaden specjalny sterownik ani aplikacja towarzysząca. Skonfiguruj połączenie serwerowe ATAK tak, aby wskazywało adres IP TAK Server osiągalny przez sieć mesh radiostacji. Dla lokalnego BFT peer-to-peer bez serwera skonfiguruj wyjście multicast UDP ATAK na adresie interfejsu RNDIS.

Persistent Systems MPU5. MPU5 działa jako punkt dostępowy Wi-Fi lub jako urządzenie USB RNDIS. W trybie punktu dostępowego urządzenie Android łączy się z SSID Wi-Fi MPU5; adres IP zarządzania radiostacją jest domyślnie dostępny pod 10.168.1.1. Persistent Systems dostarcza towarzyszącą aplikację Android (Wave Relay Mobile), która integruje się z ATAK, udostępniając status fali radiowej, mapę węzłów i metryki jakości łącza jako natywną nakładkę ATAK. Zdarzenia CoT ATAK przepływają standardową ścieżką TCP lub UDP przez IP-mesh MPU5.

Przydział przepustowości dla ruchu SA

Ustalenie budżetu przepustowości BFT przed wdrożeniem zapobiega przeciążeniu sieci mesh w najgorszym możliwym momencie. Pojedyncze zdarzenie pozycji CoT z pełnym blokiem szczegółów ma 800–1200 bajtów. Przy interwale aktualizacji 10 sekund dla drużyny 12 osób:

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

W skali kompanii (100+ jednostek przy interwałach 10-sekundowych) surowe obciążenie BFT przekracza 80 kbps przed narzutem — znaczący ułamek każdego łącza HF lub transmisji satelitarnej. W takich środowiskach wydłuż interwały aktualizacji na postój do 120+ sekund i polegaj na wyzwalanych ruchem nagłych aktualizacjach, aby utrzymać łączne obciążenie poniżej 20 kbps na łączu backhaul.

Częstotliwość aktualizacji pozycji a czas pracy baterii

Częstotliwość aktualizacji pozycji to pojedynczy parametr konfiguracji BFT o największym wpływie na żywotność baterii. Ustalanie pozycji GPS i transmisja radiowa to dwa największe pobory mocy w urządzeniu ATAK BFT; oba skalują się wprost z częstotliwością aktualizacji.

Profilowanie baterii w warunkach operacyjnych

Na Samsungu Galaxy XCover Pro (bateria 4050 mAh) z ATAK i ciągłą blokadą GPS:

Częstotliwość aktualizacji	Pobór GPS	Pobór radiostacji (hotspot MPU5)	Szacowany czas pracy BFT
5 s (agresywna)	~120 mA	~180 mA	~8–9 h
10 s (standardowa)	~120 mA	~120 mA	~10–12 h
30 s (patrol)	~90 mA	~60 mA	~15–18 h
120 s (statyczna)	~60 mA	~20 mA	~22–26 h

Pobór GPS jest stosunkowo stabilny niezależnie od częstotliwości aktualizacji, ponieważ ATAK utrzymuje odbiornik GPS w trybie ciągłego śledzenia, aby pozycja była zawsze aktualna w chwili transmisji. Zmienną jest wypełnienie transmisji radiowej: przy interwałach 5-sekundowych radiostacja jest aktywna niemal ciągle; przy interwałach 120-sekundowych bursty transmisji zajmują tylko 1–2% wypełnienia.

Strategie adaptacyjnej częstotliwości aktualizacji

Tryb Dynamic SA Reporting w ATAK realizuje strategię adaptacyjną z dwoma częstotliwościami. Bardziej zaawansowane podejście wykorzystuje wtyczki ATAK lub polecenia push po stronie serwera do dostosowywania częstotliwości aktualizacji do kontekstu operacyjnego:

Przełączanie częstotliwości na podstawie ruchu — wyzwalane akcelerometrem: jeśli urządzenie przesunęło się o więcej niż 10 m od ostatniej transmisji, nadaj natychmiast, niezależnie od zaplanowanego interwału. ATAK realizuje to natywnie w trybie Dynamic SA.
Wyzwalane geostrefą bursty aktualizacji — gdy jednostka przekroczy zdefiniowaną granicę geostrefy (wejście w rejon celu, przekroczenie linii fazowania), wyzwól burstową częstotliwość aktualizacji 5-sekundowych na 60 sekund, następnie wróć do częstotliwości tła. Konfiguruj wyzwalacze geostref przez wtyczki geostref ATAK lub API geostref TAK Server.
Eskalacja częstotliwości przy kontakcie — gdy TAK Server wykryje ścieżkę wrogą w zdefiniowanym promieniu od jednostki własnej, wysyła powiadomienie push do klienta ATAK jednostki własnej kanałem CoT serwer-klient, wyzwalając przełączenie klienta na szybką częstotliwość aktualizacji. Wymaga to własnej wtyczki po stronie serwera lub warstwy integracji AI.
Redukcja częstotliwości przy progu baterii — agent zarządzania urządzeniami (profil MDM lub wtyczka ATAK) monitoruje baterię urządzenia i automatycznie podnosi interwał SA, gdy bateria spadnie poniżej 30%, wymieniając aktualność pozycji na ciągłość działania w krytycznej fazie.

Świadomość sytuacyjna w trybie odłączonym

Żadna sieć radiowa MANET nie działa idealnie w całym obszarze działań. Maskowanie terenu, walka elektroniczna, awaria radiostacji i celowe ograniczanie emisji (emcon) wszystkie powodują okresy działania w trybie odłączonym. Solidna konstrukcja BFT musi jasno definiować, co dokładnie system robi, gdy łącza radiowego brak.

Wyświetlanie ostatnio znanej pozycji

Gdy ATAK traci łączność z TAK Server (lub odbiór multicast w trybie peer-to-peer), nadal wyświetla wszystkie ścieżki na ostatnio odebranych pozycjach. Wizualne odróżnienie ścieżek aktualnych od nieaktualnych kontroluje znacznik czasu „stale” CoT: po upływie czasu „stale” ścieżki ATAK renderuje ją z nakładką przezroczystości i adnotacją znacznika czasu pokazującą, jak dawno odebrano ostatnią pozycję. Ścieżki utrzymują się w tym stanie nieaktualności, aż osiągną próg usuwania nieaktualnych ścieżek mapy ATAK (konfigurowalny per wdrożenie; domyślnie 5 minut).

Operatorzy muszą być przeszkoleni w rozpoznawaniu i reagowaniu na wskaźniki nieaktualnych ścieżek. Pozycja ścieżki sprzed 3 minut dla jednostki pieszej poruszającej się tempem piechoty może odpowiadać 180–360 metrom rzeczywistego przemieszczenia — wystarczająco dużo, by stworzyć ryzyko ognia bratobójczego, jeśli potraktuje się ją jako aktualną. SOP powinien określać, że nieaktualne ścieżki służą wyłącznie do ogólnej orientacji w obszarze, nie do rozdzielenia ognia wsparcia.

Integracja wyświetlania rachuby drogi

ATAK obsługuje ekstrapolację ścieżek rachuby drogi przez element szczegółów track w zdarzeniach CoT, który niesie prędkość i kurs. Gdy ścieżka staje się nieaktualna, wtyczka rachuby drogi może rzutować szacowaną bieżącą pozycję ścieżki naprzód od ostatniego znanego ustalenia, używając zgłoszonych wektorów prędkości i kursu. Pozycja rzutowana wyświetlana jest z odrębną ikoną (zwykle symbolem otwartym/kreskowanym), aby odróżnić ją od pozycji potwierdzonej przez GPS.

Dokładność rachuby drogi szybko degraduje się dla piechoty pieszej (prędkość i kurs zmieniają się stale) i jest bardziej niezawodna dla pojazdów na znanych sieciach drogowych. Wdrażaj wyświetlanie rachuby drogi tylko wtedy, gdy operatorzy rozumieją jej ograniczenia, a SOP jasno odróżnia pozycje rzutowane od potwierdzonych.

Ponowne połączenie i uzgadnianie SA

Gdy ATAK ponownie łączy się z TAK Server po okresie odłączenia, serwer wykonuje pełne wypchnięcie stanu SA: dostarcza aktualne (lub najnowsze) zdarzenie CoT dla każdej ścieżki w subskrybowanych grupach klienta. Ta aktualizacja burst nadpisuje nieaktualne ostatnio znane pozycje na mapie klienta aktualnymi danymi serwera. Proces uzgadniania kończy się w ciągu 1–3 sekund dla typowych rozmiarów jednostek (poniżej 200 ścieżek).

# 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

Jeden przypadek brzegowy do uwzględnienia: jeśli okres odłączenia przekroczy próg nieaktualności serwera (domyślnie 600 sekund dla CloudTAK), serwer już wygasił nieaktualne ścieżki ze swojego magazynu aktywnego. Przy ponownym połączeniu ścieżki te nie pojawią się w aktualizacji burst i wrócą dopiero, gdy urządzenia źródłowe nadadzą nowe zdarzenia pozycji. Dla operacji, w których ponowne połączenia mogą następować po wielogodzinnych zanikach łączności, podnieś próg nieaktualności serwera do oczekiwanego maksymalnego czasu zaniku.

Wdroż BFT dla swojej jednostki lub organizacji

Projektujemy i wdrażamy systemy śledzenia sił własnych oparte na ATAK dla organizacji obronnych i rządowych — w tym konfigurację TAK Server, integrację radiostacji MANET, AI-copilota TAKpilot oraz rozwój wtyczek dedykowanych misji.

TAKpilot AI Copilot → Zarezerwuj odprawę

Analizę przygotowali inżynierowie Corvus Intelligence, którzy budują krytyczne dla misji oprogramowanie dla organizacji obronnych i rządowych. Poznaj nasz zespół →

Często zadawane pytania

Czym jest śledzenie sił własnych na urządzeniach Android?

Śledzenie sił własnych (BFT) na urządzeniach Android to wyświetlanie i transmisja w czasie rzeczywistym pozycji własnych jednostek na wspólnej mapie cyfrowej. ATAK (Android Team Awareness Kit) to podstawowy klient BFT: odczytuje pozycję GPS z urządzenia, pakuje ją jako zdarzenie XML Cursor on Target (CoT) i przesyła to zdarzenie do TAK Server lub bezpośrednio do urządzeń równorzędnych przez multicast lub radiostację MANET. Serwer agreguje zdarzenia pozycji ze wszystkich podłączonych jednostek i rozsyła je do każdego klienta ATAK, dzięki czemu każdy żołnierz widzi jednocześnie wszystkie własne ścieżki. Częstotliwość aktualizacji, symbolika mapy i ścieżki łączności są konfigurowalne w ustawieniach SA w ATAK.

Czym jest Cursor on Target i jak służy do BFT?

Cursor on Target (CoT) to format komunikatów oparty na XML, pierwotnie opracowany przez Siły Powietrzne USA do wymiany taktycznych danych pozycji i statusu między różnymi systemami. Dla BFT kluczowym typem zdarzenia CoT jest zdarzenie „atom” (prefiks typu „a-”), które zawiera element punktowy ze współrzędnymi lat/lon/hae, znacznik czasu „stale” określający wygaśnięcie pozycji oraz blok szczegółów z znakiem wywoławczym, kolorem zespołu i rolą. ATAK generuje te zdarzenia automatycznie z GPS urządzenia w konfigurowalnym interwale (zwykle co 5–30 sekund) i przesyła je do TAK Server, który nadaje je ponownie do wszystkich subskrybujących klientów. Znacznik „stale” zapewnia, że gdy jednostka przestaje nadawać, jej ścieżka automatycznie znika z wyświetlaczy innych jednostek po zdefiniowanym oknie wygaśnięcia.

Jaką częstotliwość aktualizacji skonfigurować dla BFT w ATAK w operacjach taktycznych?

Optymalna częstotliwość aktualizacji BFT zależy od rodzaju misji, przepustowości łącza radiowego i ograniczeń baterii. Dla piechoty pieszej w kontakcie interwał 5–10 sekund zapewnia dostateczną aktualność pozycji; dla jednostek zmotoryzowanych z zasilaniem zewnętrznym praktyczne jest 3–5 sekund. Na łączach MANET o ograniczonej przepustowości wydłuż interwał do 30–60 sekund dla jednostek niewykonujących manewru i polegaj na wyzwalanych ruchem nagłych aktualizacjach (zdarzenia opuszczenia geostrefy) dla natychmiastowych aktualizacji przy poruszaniu się jednostki. Funkcja adaptacyjnego raportowania SA w ATAK potrafi automatycznie przełączać między wolnym tłem a szybkim tempem kontaktu na podstawie prędkości ruchu wykrytej przez akcelerometr urządzenia.

Jak ATAK łączy się z TAK Server w celu BFT?

ATAK obsługuje trzy podstawowe typy połączeń dla BFT: (1) strumieniowanie TCP — stałe połączenie TCP/TLS z TAK Server na porcie 8089, używane do niezawodnej dostawy unicast z uwierzytelnianiem certyfikatowym; (2) multicast UDP — zdarzenia CoT nadawane na adresie multicast wewnątrz lokalnego segmentu sieci, odpowiednie dla środowisk LAN lub MANET bez infrastruktury serwerowej; oraz (3) Streaming XML — starszy tryb TCP używający niezaszyfrowanych strumieni XML, obecnie wycofany. Dla wdrożeń operacyjnych standardem jest TCP/TLS do TAK Server. Ustawienia sieciowe ATAK przyjmują nazwę hosta serwera, port oraz pakiet certyfikatów PKCS#12 do wzajemnego uwierzytelniania TLS.

Jakie radiostacje MANET integrują się z ATAK w celu BFT?

ATAK integruje się z radiostacjami MANET przez Android USB OTG lub towarzyszącą aplikację Android radiostacji. Często integrowane radiostacje to Harris RF-7800W (seria Falcon III), Persistent Systems MPU5, Domo Tactical PRC-ACM oraz Silvus StreamCaster. Każda radiostacja udostępnia wirtualny interfejs sieciowy lub usługę przekaźnika CoT, którą ATAK rozpoznaje jako łącze danych TAK. Radiostacja obsługuje routing IP po sieci mesh, a ATAK wysyła standardowe pakiety CoT UDP multicast lub TCP na lokalny adres IP radiostacji. Niektóre radiostacje udostępniają także API zarządzania falą radiową, o które wtyczki ATAK mogą zapytać w celu monitorowania jakości łącza i odpowiedniego dostosowania parametrów transmisji SA.

Jak TAK Server zarządza strumieniami SA dla BFT?

TAK Server prowadzi w pamięci magazyn zdarzeń CoT dla wszystkich podłączonych klientów. Gdy nadejdzie nowe zdarzenie pozycji CoT, serwer: (1) zapisuje zdarzenie w bazie trwałej; (2) ocenia reguły grup i filtrów, aby ustalić, którzy klienci mają je otrzymać; (3) wypycha zdarzenie do wszystkich subskrybujących połączeń klienckich. W przypadku BFT serwer śledzi najnowsze zdarzenie pozycji na UID i udostępnia je nowo łączącym się klientom, aby natychmiast po połączeniu otrzymały aktualny wspólny obraz sytuacji. Subskrypcje strumieni SA są zarządzane przez system grup serwera — klienci przypisani do tej samej grupy automatycznie współdzielą ścieżki BFT bez ręcznej konfiguracji subskrypcji.

Jak zapobiegać pojawianiu się ścieżek BFT jednocześnie na instancjach ATAK klasyfikowanych i nieklasyfikowanych?

Oddzielenie klasyfikacji w środowisku TAK BFT osiąga się przez połączenie izolacji grupowej po stronie serwera i fizycznego oddzielenia sieci. Na TAK Server przypisz jednostki klasyfikowane do grupy niewidocznej dla klientów nieklasyfikowanych (np. grupa „SECRET” bez federacji ani subskrypcji grupy „UNCLASSIFIED”). Dla twardego rozdzielenia uruchom dwie całkowicie odrębne instancje TAK Server — jedna na segmencie sieci klasyfikowanym, druga na nieklasyfikowanym — bez łącza federacji między nimi. Nigdy nie polegaj wyłącznie na programowych filtrach grupowych dla separacji klasyfikacji; wymagane jest fizyczne lub kryptograficzne oddzielenie sieci, aby spełnić standardy bezpieczeństwa informacji.

Co dzieje się ze ścieżkami BFT, gdy ATAK utraci łączność z TAK Server?

Gdy ATAK traci łączność z serwerem, przechodzi w tryb odłączony. Mapa nadal wyświetla ostatnio odebrane pozycje wszystkich ścieżek, wizualnie odróżnione wskaźnikiem nieaktualności (zwykle wyblakłą ikoną lub adnotacją znacznika czasu) po upływie czasu „stale” ścieżki CoT. ATAK nadal również nadaje własną pozycję dowolną dostępną lokalną ścieżką rozgłoszeniową (UDP multicast, radiostacja MANET). Po przywróceniu łączności ATAK automatycznie łączy się ponownie, a serwer wypycha aktualny stan wszystkich ścieżek jako aktualizację burst, nadpisując nieaktualne ostatnio znane pozycje. Administratorzy powinni ustawiać czasy nieaktualności odpowiednie do tempa taktycznego — 10-minutowe okno nieaktualności zapobiega pojawianiu się duchów ścieżek w środowiskach o słabej łączności.

Ile przepustowości zużywa BFT przez ATAK na łączu MANET?

Pojedyncze zdarzenie pozycji CoT w ATAK (XML CoT z blokiem szczegółów) ma około 800–1200 bajtów. Przy interwale aktualizacji 10 sekund dla plutonu 20 jednostek całkowity ruch BFT wynosi około 20 × 1000 bajtów / 10 s = 2 kB/s, czyli około 16 kbps. To znacznie poniżej możliwości nowoczesnych radiostacji MANET (MPU5 zapewnia 1–10 Mbps na węzeł), ale szybko narasta w dużych zgrupowaniach. Dla kompanii 100 jednostek przy interwałach 10-sekundowych surowy ruch BFT zbliża się do 80 kbps — do opanowania, ale znaczący na łączach HF lub transmisji satelitarnej. Kompresja CoT (zlib nad strumieniem TCP) zazwyczaj zmniejsza rozmiar ładunku o 40–60%, a adaptacyjne częstotliwości aktualizacji mogą obniżyć obciążenie o rząd wielkości w fazach statycznych.

Jakie urządzenia Android są certyfikowane do wojskowego BFT z ATAK?

ATAK MIL (wojskowa wariant dystrybuowana przez TAK.gov) działa na szeregu wzmocnionych urządzeń Android. Często używane platformy to Samsung Galaxy XCover Pro, Getac PS336, Kyocera DuraForce Pro 2 oraz tablety Dell Latitude Rugged. Dla BFT kryteria doboru urządzenia obejmują czułość chipsetu GPS (dla kanionów miejskich i przebijania się przez roślinność), pojemność baterii (lub możliwość wymiany na gorąco), zakres temperatur pracy oraz odporność na wstrząsy i wodę wg MIL-STD-810. Urządzenia z wielokonstelacyjnym GNSS (GPS + GLONASS + Galileo) zapewniają bardziej niezawodne pozycjonowanie w środowiskach zdegradowanych w porównaniu z chipsetami wyłącznie GPS.