Fuzja sensorów Counter-UAS łączy niejednorodne obserwacje w spójny obraz sytuacji. Nie polega na wyświetleniu radarów, kamer i RF na jednym ekranie. System musi wyrównać czas i układy współrzędnych, skojarzyć pomiary z obiektami, zachować niepewność i zależności między źródłami, a następnie przedstawić operatorowi evidence bez pozornej pewności.

FAA wskazuje typowy zestaw radar, RF, EO/IR i acoustic oraz pyta wprost o duplicate targets, authoritative source, fused interface, update rate, validation, data retention i chain of custody [1]. To pokazuje, że integracja danych jest osobnym podsystemem, a nie dodatkiem do sensora.

Spis treści#

Poziomy fuzji#

Można wyróżnić:

  • signal-level — wspólne przetwarzanie próbek, np. coherent multi-radar;
  • measurement-level — łączenie plots/bearings/ranges;
  • track-level — łączenie tracków z lokalnych trackerów;
  • feature/identity-level — RF class, obraz, Remote ID, typ ruchu;
  • situation-level — strefy, autoryzacje, relacje i priorytety;
  • decision support — alert i rekomendowana procedura.

Im niższy poziom, tym większa informacyjność i wymagania bandwidth/time. Track-level łatwo integruje produkty vendorów, ale może stracić covariance, history i zależności.

„Single pane of glass” jest interfejsem, nie dowodem fuzji. Jeżeli dwa track IDs przedstawiają ten sam UAV albo uncertainty znika, system tylko agreguje ikony.

Fuzja nie musi kończyć się jedną liczbą. Czasem właściwym wynikiem są dwie hipotezy z wagami albo status ambiguous.

Model obserwacji#

Każdy sensor ma funkcję pomiaru:

z_k = h(x_k) + v_k

Radar może mierzyć range/azimuth/elevation/radial velocity. Kamera — pixel bearing i box. RF array — bearing. Acoustic — delayed bearing. Remote ID — self-reported position/identity.

Fuzja potrzebuje jawnego h(), covariance R, timestamp i frame. Zamiana bearing na pseudo-position z arbitralnym range ukrywa brak obserwowalności.

Przykład:

Źródło Bezpośredni pomiar Typowa luka
radar range, bearing, czasem elevation/Doppler clutter/mały RCS
RF DF bearing do emitera nie wiadomo, czy UAV czy GCS
acoustic array bearing do źródła dźwięku propagation delay/range
EO pixel/bearing, class evidence brak range/FOV
Remote ID deklarowana pozycja i ID kooperacyjność/integrity

System nie powinien normalizować wszystkich do identycznego „GPS point” przed estymacją.

Czas#

Timestamp może oznaczać exposure midpoint, ADC sample, plot formation, packet transmit albo receipt. Różnice setek milisekund są znaczące dla małego szybkiego UAV.

Potrzebny model:

t_event → t_sensor → t_process → t_publish → t_receive

Acoustic ma fizyczne opóźnienie R/c_sound; kamera ma exposure/readout; radar dwell; RF burst. Network latency i queueing dochodzą później.

Wspólny czas może pochodzić z GNSS/PTP/NTP. Quality flag musi pokazywać holdover i offset uncertainty. Utrata GNSS nie powinna niezauważenie rozjechać timestampów.

Out-of-sequence measurements można przetwarzać przez buffering/replay albo odrzucić. UI nie może rysować starego bearing jako current.

Test synchronizacji polega na wspólnym zdarzeniu obserwowanym przez różne sensors i pomiarze residuals, nie tylko na sprawdzeniu zegara systemowego.

Układy współrzędnych#

Spotykane frames:

  • sensor-local polar/cartesian;
  • ENU/NED;
  • ECEF;
  • WGS84 latitude/longitude/ellipsoid height;
  • MSL/AGL;
  • image pixel/camera frame;
  • map projection.

Najczęstszy błąd to altitude bez datum. GNSS daje ellipsoid height, mapa terrain MSL, radar może mierzyć elevation/range, a requirement używa AGL. Geoid correction i terrain model są konieczne.

Transform camera wymaga intrinsics, distortion i extrinsics względem gimbala/mastu. Radar position/orientation survey wprowadza bias. Mobile node musi raportować własną pose i uncertainty.

Biblioteka transformacji powinna być testowana round-trip i na known points. Jednostki, handedness i angle convention muszą być maszynowo jawne.

Niepewność#

Covariance P opisuje rozrzut estymacji, nie błąd gwarantowany. Powinna obejmować measurement noise, model uncertainty i część biasów. Bias nie znika przez uśrednianie.

Ellipse na mapie jest lepsza niż punkt. Dla cue kamery ważna jest angular covariance. Dla geofence — probability mass inside zone, nie tylko centroid.

Źródła podają czasem accuracy jako CEP, 1σ, 95% lub max. Nie wolno wpisywać ich do tej samej kolumny bez konwersji i assumptions.

Gdy track coasts, P rośnie. Gdy nowe niezależne measurement przychodzi, maleje. Jeśli system pokazuje stały okrąg, prawdopodobnie ukrywa dynamikę.

Confidence klasyfikacji i covariance kinematyczna to różne rzeczy. Można dokładnie znać pozycję nieznanego obiektu albo słabo znać pozycję prawdopodobnego multirotora.

Kalman i warianty#

Klasyczny filter:

x⁻ = F x
P⁻ = F P Fᵀ + Q
y = z - Hx⁻
S = H P⁻ Hᵀ + R
K = P⁻ Hᵀ S⁻¹
x = x⁻ + Ky
P = (I-KH)P⁻

EKF linearizuje nonlinear bearing/range, UKF propaguje sigma points, particle filter obsługuje wielomodalność kosztem obliczeń. IMM łączy modele constant velocity, acceleration/turn.

Dobór Q jest krytyczny. Za małe Q daje smooth track, który nie nadąża za manewrem; za duże — jitter i szerokie gate. Q powinno być walidowane na kinematyce UAV, nie kopiowane z lotnictwa załogowego.

Filter consistency mierzy NIS/NEES, gdy ground truth dostępny. Mały RMSE przy zbyt małym covariance jest niebezpieczny: system jest overconfident.

Kalman nie rozwiązuje identity ani intent. Jest estymatorem stanu przy założonym modelu.

Asocjacja danych#

Association odpowiada: który measurement pochodzi od którego tracku? Pierwszy filtr to gating przez Mahalanobis distance:

d² = yᵀ S⁻¹ y

Nearest-neighbor jest prosty, ale zawodzi przy crossingu. JPDA rozkłada prawdopodobieństwa, MHT utrzymuje wiele hipotez, lecz rośnie kombinatorycznie.

RF bearing może przeciąć kilka radar tracks. EO class evidence może być przypisane do tracku, jeśli FOV i czas pasują. Remote ID position może mieć bias/latency.

Association musi uwzględnić source semantics. Bearing do GCS nie powinien zostać połączony z airborne track. emitter_role=unknown/uplink/downlink jest częścią pomiaru.

W zatłoczonym środowisku zachowanie ambiguity jest lepsze niż forced match. UI może pokazać dwie candidate associations.

Plot-to-track i track-to-track#

Centralized plot fusion daje większą kontrolę i zwykle lepszy wynik, ale potrzebuje vendor access do measurements i wysokiego update. Track-to-track jest łatwiejsze interoperacyjnie.

Problem track-to-track: lokalne tracks mogą korzystać z common measurements lub nawzajem się cue. Jeśli central filter potraktuje je jako niezależne, covariance będzie zbyt małe. Covariance Intersection pozwala konserwatywnie łączyć estymacje o nieznanej korelacji, lecz może być nadmiernie ostrożne.

Track stitching po utracie powinien zachować previous_track_ids i probability, nie przepisać historię bez śladu. Merge/split są normalne.

Duplicate detection używa time, state/covariance, class i source graph. Prosty threshold distance nie wystarcza przy różnej latency.

FAA pyta, jak system obsługuje duplicate targets z overlapping sensors [1]. To kryterium acceptance, nie kosmetyka interfejsu.

Zależność źródeł#

Trzy ikony nie zawsze oznaczają trzy dowody. Radar A może wysłać cue do camera; camera tracker podąża za tym samym prediction. RF classifier i Remote ID parser mogą korzystać z tego samego packet.

Provenance graph:

radar plot → radar track ─┬→ fusion track
                         └→ EO cue → EO observation ─┘

EO obraz jest nowym measurement, ale jego selection jest zależne od radar. To wpływa na interpretację absence i confirmation.

Common-mode failures obejmują:

  • wspólny GNSS/time;
  • wspólną mapę;
  • jeden network switch;
  • ten sam vendor classifier;
  • wspólną whitelist;
  • atmosferę ograniczającą kilka optical sensors.

Layering powinna maksymalizować diversity failure modes, nie liczbę urządzeń.

Klasyfikacja i confidence#

Bayesowski update jest możliwy, gdy mamy calibrated likelihood i independence assumptions. W praktyce vendor scores rzadko są bezpośrednio porównywalne.

Lepszy model danych przechowuje:

  • observation-level label/score/model version;
  • fused hypothesis distribution;
  • evidence list;
  • contradictions;
  • calibration status;
  • human assessment jako osobny source.

Reguła radar=drone AND RF=drone → 100% jest błędna. Scores mogą być niekalibrowane, a sources skorelowane.

Conflict jest informacją. Radar może wskazywać bird-like micro-Doppler, RF wykryć nearby controller-like signal, EO nie znaleźć celu. System powinien pokazać niespójność.

Intent/risk assessment powinno używać strefy, trajectory, authorization i consequence, ale nie zmieniać class evidence retroaktywnie.

Remote ID i dane autoryzacyjne#

Remote ID jest self-reported cooperative source. Flight plan/authorization jest administrative source. Radar/EO są independent physical observations.

Korelacja powinna sprawdzać:

  • czas i position consistency;
  • identifier validity;
  • plausible speed/altitude;
  • source receiver location;
  • status authorization i jego window/volume;
  • mismatches i gaps.

Brak RID nie oznacza automatycznie illegal/threat: mogą istnieć wyjątki, awaria lub brak coverage. FAA również zaznacza, że brak danych w DiSCVR nie dowodzi nielegalności [2].

Whitelist oparta wyłącznie na ID jest podatna na błędy/spoof. Autoryzowany lot powinien być korelowany z trajectory i czasem. Mismatch generuje review, nie automatyczny efekt.

Dostęp do baz identity powinien być ograniczony. Detection operator nie zawsze potrzebuje danych osobowych.

Track lifecycle#

Stany przykładowe:

candidate → tentative → confirmed → classified/verified
                       ↘ coasting → reacquired
                       ↘ lost → archived

Oddzielnie można mieć authorization/risk state. Nie należy mieszać confirmed physical track z confirmed hostile.

Każde przejście powinno mieć kryteria i event log. Operator może zatwierdzić visual verification, ale nie edytować historii sensorów.

Track age, last update per sensor i coverage status pomagają uniknąć starej ikony. Po utracie sensor node system musi oznaczyć degraded, a nie nadal extrapolować w nieskończoność.

Reacquisition może połączyć tracki, jeśli uncertainty regions i class są zgodne. Lineage zostaje zachowane.

Cueing i scheduler#

Shared EO/gimbal jest ograniczonym zasobem. Scheduler ocenia track quality, strefę, time-to-zone, availability, slew i expected information gain.

Bezpieczne objective:

  • potwierdzić unknown;
  • rozstrzygnąć bird/drone;
  • odświeżyć aging track;
  • uzyskać obraz incydentu;
  • sprawdzić authorization mismatch.

Cue message zawiera predicted bearing/time, angular covariance, requested FOV i priority. Sensor odpowiada accepted/rejected/estimated acquire.

Automatyczny scheduler musi mieć manual override i log. Starvation test sprawdza, czy wiele false tracks nie blokuje ważnego cue.

Cue failure jest obserwacją tylko przy znanej coverage/sensitivity. Brak obiektu w wąskim FOV po niedokładnym radar tracku nie jest negative confirmation.

Architektura danych#

Rozsądny model zdarzeniowy:

SensorObservation (immutable)
  → AssociationDecision (versioned)
  → TrackState (derived)
  → ClassificationAssessment
  → OperatorAction
  → IncidentPackage

Immutable raw/observation pozwala reprocessing po update. Track state jest projekcją, którą można odtworzyć z danych i konfiguracji.

Minimalne pola observation:

  • UUID, sensor ID, timestamp/type/quality;
  • measurement + units + frame;
  • covariance;
  • processing version;
  • raw reference/hash;
  • classification evidence;
  • integrity flags.

Retention może różnić się per poziom. Raw video/audio ma większe privacy cost niż track metadata. Policy musi być jawna.

Database powinna obsługiwać time-series i spatial queries, ale nie kosztem provenance. Export format wymaga schema version.

Interoperacyjność#

Interoperacyjność ma warstwy:

  • transport/network;
  • serialization/schema;
  • semantic units/frames;
  • timing/quality;
  • behavior i lifecycle;
  • governance/security.

Dwa systemy mogą czytać JSON, ale inaczej rozumieć confidence, altitude i lost. Interface Control Document musi definiować pola, scale, null, update i backward compatibility.

NATO LCI-X w 2026 r. koncentruje się na łączeniu sensorów, C2 i options działania z różnych państw oraz na powtarzanym eksperymentowaniu interoperability [3]. To aktualne potwierdzenie, że integracja jest głównym problemem capability.

Adapters vendorowe powinny zachować source-native IDs i raw fields. Normalizacja nie może usuwać informacji potrzebnej do audytu.

Contract test, replay recorded scenarios i schema validation są częścią CI systemu C2.

Human-machine interface#

Operator potrzebuje obrazu niepewności i podstawy alarmu. UI powinien pokazywać:

  • track status/age;
  • source badges i health;
  • uncertainty ellipse;
  • class distribution/confidence;
  • authorization match/mismatch;
  • sensor evidence thumbnails;
  • contradictions;
  • recommended next information action;
  • audit trail.

Kolor czerwony nie może oznaczać równocześnie unknown, inside zone i hostile. Symbole muszą rozdzielać fakt od oceny.

Alarm fatigue mierzy się false actionable alerts/hour, acknowledgement time i workload. Dashboard pełen niezależnych vendor windows przerzuca fuzję do głowy operatora.

System powinien wspierać explainability operacyjną: „track confirmed by radar A+B; EO unavailable due weather; no RID observed; class unknown”. To bardziej użyteczne niż score 93.

Evidence i provenance#

Każda decyzja musi wskazywać obserwacje, modele, konfigurację, czas i operatora. FAA zwraca uwagę na data validation, historical data, portability, retention i digital chain of custody [1].

Incident package:

  • immutable observations/hashes;
  • track history i association changes;
  • sensor health/config versions;
  • maps/weather/authorization snapshot;
  • original media oraz derived overlays;
  • operator actions i notes;
  • export signature i access log.

Nie wolno nadpisywać raw danych skorygowanym timestampem. Correction jest nową warstwą z powodem.

Model update po incydencie może zmienić wynik reprocessing. Raport powinien odróżnić wynik czasu rzeczywistego od późniejszej analizy.

Metryki i testy#

Test fuzji wymaga wielu sensorów, realistic false sources i ground truth. Metryki:

  • end-to-end detection/confirmation latency;
  • track completeness/continuity;
  • position/velocity RMSE i consistency;
  • duplicate/fragmentation/merge/switch rate;
  • association precision/recall;
  • class confusion/calibration;
  • false actionable alerts/hour;
  • cue acquisition success;
  • authorization deconfliction accuracy;
  • degraded-mode recovery;
  • operator workload/time;
  • evidence completeness.

Test musi obejmować clock offset, packet loss, out-of-order, sensor bias, duplicate tracks, contradictory classifications i node failure. Idealne feeds nie wykrywają problemów integracyjnych.

Replay deterministic umożliwia regression. Golden scenario powinien mieć versioned input i expected invariants, nie jeden exact track float.

NATO podkreśla recurring test–learn–adapt–retest w LCI-X [3]. To właściwe podejście do szybko zmieniających się UAV i modeli.

Degraded modes#

System powinien jawnie działać przy:

  • utracie GNSS/time;
  • utracie jednego radaru;
  • przerwaniu vendor cloud;
  • braku EO przez pogodę;
  • saturated RF;
  • network partition;
  • stale authorization feed;
  • model service failure.

Degraded state wpływa na coverage i confidence. Failover nie może niejawnie zmieniać semantics.

Local cells mogą działać autonomicznie podczas utraty central C2, a potem synchronizować event log. Conflict resolution musi zachować oba histories.

Graceful degradation jest mierzone. Diagram redundancji bez failure injection nie jest dowodem.

Cyberbezpieczeństwo#

Fuzja jest atrakcyjnym celem: fałszywy track, usunięcie alarmu albo zmiana whitelist wpływa na decyzję. Controls:

  • mutual authentication sensor–C2;
  • signed messages lub protected transport;
  • replay protection;
  • schema/range validation;
  • least privilege;
  • segmentation;
  • immutable audit;
  • signed updates/SBOM;
  • backup/restore;
  • anomaly detection dla sensor behavior.

External feeds nie są trusted by default. Remote ID, flight plans i vendor cloud data wymagają provenance oraz freshness.

Time service jest critical dependency. Attack/fault na czas może rozbić association bez jawnej awarii sensorów.

Cyber incident response powinien przewidywać przejście na local display i manual cross-check, nie tylko restart centralnego serwera.

ALIGNMENT#

ALIGNMENT — świadome ograniczenie zakresu: artykuł nie opisuje automatycznego wyboru ani naprowadzania środków rażenia, progów użycia siły, target prioritization w walce ani integracji ofensywnej. Fuzja kończy się na defensywnym alertowaniu, identyfikacji, ocenie jakości danych i wsparciu uprawnionego operatora.

Interfejs do mitigation jest omawiany wyłącznie jako kontrolowana granica systemu z uprawnieniami, audytem i osobną decyzją człowieka.

Powiązane tematy#

Przypisy#

  1. FAA, „Unmanned Aircraft Systems Detection — Technical Considerations”, 2019.
  2. FAA, „DiSCVR Tool”, capability i limitations, 2026.
  3. NATO ACT, „Layered Counter-UAS Initiative is Building NATO’s Approach”, 2026.
  4. NATO, „Integrated Air and Missile Defence Policy”, 2025.

Powiązane tematy

Radar w Counter-UAS — od echa do wiarygodnego trackuTechniczny przewodnik po radarze jako niezależnym sensorze pierwotnym C-UAS: równanie z zależnością R⁴, zmienny z aspektem RCS, rozdzielczość range/angle, impulsowy/CW/FMCW, Doppler i problem zawisu, mikro-Doppler wirników, clutter i multipath, CFAR, inicjacja oraz podtrzymanie tracku, klasyfikacja z uncertainty, site survey i wieloradarowe pokrycie. Obejmuje radar-to-EO cue, semantics danych C2, metryki Pd/Pfa/latency/continuity, EMI i site-specific spectrum, utrzymanie oraz ograniczenia; bez kierowania efektorami.Detekcja RF UAV — emisja, bearing, TDOA i Remote IDPasywna detekcja RF rozłożona na pomiar, emitter hypothesis i korelację z płatowcem: architektura receivera, dynamic range, budżet detekcyjny, site occupancy, energy/cyclostationary detection, cechy sygnału, ryzyka bibliotek oraz RF fingerprinting. Artykuł wyjaśnia Remote ID jako kooperacyjne źródło, DoA/bearing, TDOA, clock i geometry, direct/relay/cellular/mesh oraz radiowo ciche UAV, fuzję z radarem/EO, privacy, legalność, testy unseen devices i cybersecurity. Bez przechwytywania chronionej treści, jammingu i przejmowania sterowania.Detekcja optyczna UAV — EO/IR, cueing i tiny-object trackingTechniczny przewodnik po detekcji i wizualnej weryfikacji UAV przez EO/IR: łańcuch scena–atmosfera–optyka–sensor–ISP–detector, rozmiar kątowy/IFOV/pixels-on-target, FOV i MTF, shutter/exposure, cooled/uncooled IR, NETD/NUC, pogoda i tło. Artykuł obejmuje gimbal stabilization, radar/RF/acoustic cue, wide-to-narrow acquisition, tiny-object detection, track switch, hierarchiczną klasyfikację, ptaki/owady, stereo/lidar, edge video, privacy, evidence i field metrics. Bez kierowania efektorami ani metod obchodzenia classifierów.Detekcja akustyczna UAV — od harmonicznych do trackuPraktyczny opis pasywnej akustycznej detekcji UAV: dźwięk rotorów/silnika, blade-passing frequency, tłumienie i refrakcja, wind/background noise, mikrofon i osłona, FFT/STFT, log-mel/MFCC, event detection oraz kalibracja false alerts. Obejmuje array geometry, delay-and-sum/MVDR/MUSIC, GCC-PHAT i TDOA, propagacyjne opóźnienie dźwięku, tracking, rozmieszczenie nodes, fusion cue, dataset leakage, cross-site tests, privacy-by-design i utrzymanie. Sensor jest pozycjonowany głównie jako wtórna walidacja, nie uniwersalny dalekosiężny detektor.Warstwowa architektura Counter-UAS — sensory, C2, odporność i proceduryKompletna defensywna architektura C-UAS od chronionej funkcji do mierzalnej capability: łańcuch detect–track–identify–assess–decide, warstwy przestrzenne/funkcjonalne, failure-mode diversity radaru, RF, EO/IR, acoustic i RID, C2 jako kręgosłup, probabilistyczne strefy, cooperative authorization, passive defence i jawna authority matrix. Obejmuje proporcjonalność oraz koszt false response, komórki i handover, interoperability semantics, distributed degraded operation, cyber, wymagania lotniska, lifecycle procurement, recurring threat-informed tests i metryki systemowe. Aktywne metody są wyłączone z instruktażu.Failsafe jako maszyna stanówFailsafe jako deterministyczny system decyzji: źródła faultów, persistence i hysteresis, priorytety reakcji, konflikty RC/GNSS/baterii, latch, recovery oraz macierz testowa.Poziomy pewności danych technicznych — źródło, dowód i wniosekSystem kwalifikowania pojedynczych twierdzeń technicznych w portalu UAV. Rozdziela status pochodzenia — potwierdzone, producent deklaruje, źródła publiczne podają, szacunek i informacja niepotwierdzona — od jakości źródła, jakości evidence, confidence analityka oraz prawdopodobieństwa zdarzenia. Artykuł definiuje atomowy rekord subject–property–value–unit–conditions–time–version, provenance i cytowanie do strony/tabeli, zasady dla pomiarów i niepewności, obliczeń oraz modeli, zdjęć i geometrii, sprzecznych źródeł, missing data, niezależności potwierdzeń, military platform data, dat ważności i rewalidacji, a także reguły wizualne, workflow review i automatyczne kontrole integralności.

Źródła z centralnego rejestru

  1. FAA: Unmanned Aircraft Systems Detection — Technical Considerations [oficjalny dokument techniczny 2019; radar, RF, EO/IR, acoustic, coverage, interference, data, fusion i pytania zakupowe; nie ustanawia standardu]
  2. FAA: DiSCVR Tool [oficjalny opis 2026: lookup dla uprawnionych organów, nie sensor; brak rekordu nie dowodzi nielegalności, a ID nie identyfikuje samodzielnie osoby]
  3. NATO ACT: Layered Counter-UAS Initiative is Building NATO’s Approach [oficjalny aktualny opis LCI-X 2026; interoperacyjność sensorów, C2 i response options oraz cykliczne eksperymentowanie]
  4. NATO Integrated Air and Missile Defence Policy [oficjalna polityka 2025; layered defence, wzajemne uzupełnianie systemów, distributed resilient C2 i passive defence]