Warstwowa architektura Counter-UAS — sensory, C2, odporność i procedury

Warstwowa architektura Counter-UAS nie oznacza ustawienia kilku efektorów jeden za drugim. Jest systemem sensorów, dowodzenia, procedur, środków pasywnych i uprawnionych reakcji, które mają różne zasięgi, opóźnienia i failure modes. Warstwy muszą wymieniać dane, zachować odpowiedzialność oraz działać również wtedy, gdy pojedynczy sensor, sieć albo stanowisko przestanie być dostępne.

NATO w polityce Integrated Air and Missile Defence z 2025 r. opisuje layered defence jako połączenie systemów o różnych zasięgach i wysokościach, które wzajemnie ograniczają swoje słabości, a działania aktywne uzupełnia odpornością pasywną, rozproszeniem i redundancją [1]. LCI-X w 2026 r. koncentruje się na interoperacyjności sensorów, C2 i options odpowiedzi oraz powtarzanym testowaniu w realistycznych warunkach [2].

Spis treści#

Od urządzenia do capability
Łańcuch detect–track–identify–decide
Warstwy przestrzenne i funkcjonalne
Sensor diversity
C2 jako kręgosłup
Strefy i chronione funkcje
Identyfikacja kooperacyjna
Passive defence
Response options i authority
Koszt i proporcjonalność
Architektura komórkowa
Interoperacyjność
Resilience i degraded operations
Cyberbezpieczeństwo
Lotnisko i infrastruktura cywilna
Wymagania i procurement
Testy i eksperymentowanie
Metryki systemowe
Utrzymanie i aktualizacja
Typowe antywzorce
ALIGNMENT
Powiązane tematy
Przypisy

Od urządzenia do capability#

Radar katalogowy nie jest capability. Kamera nie jest identyfikacją bez cue, operatora i procedury. Mitigation module bez authority i safety case jest nieużyteczny albo niebezpieczny.

Pełny system:

sensors → fusion/C2 → assessment → authority/decision → response
   ↑          ↓              ↓             ↓             ↓
health    evidence       airspace      procedures     consequence

Do tego dochodzą training, maintenance, spectrum, cyber, legal, logistics i incident review. NSPA w 2026 r. opisała modułowe C-UAS wokół wspólnego C2, łączące radar, DF, EO/IR, acoustic i odpowiednie response subsystems [3]. To aktualny przykład myślenia systemowego.

Capability ma zdefiniowane chronione funkcje: utrzymać bezpieczny ruch lotniczy, ostrzec personel, zabezpieczyć wydarzenie, chronić instalację. „Zestrzelić drona” nie jest pełnym requirement i bywa prawnie niedostępne.

System success może polegać na szybkim potwierdzeniu legalnego lotu i uniknięciu niepotrzebnego zamknięcia lotniska.

Łańcuch detect–track–identify–decide#

Detect#

Pierwsza obserwacja przekraczająca kryterium. Może pochodzić z radaru, RF, acoustic, EO albo człowieka.

Track#

Powiązanie obserwacji w czasie i estymacja kinematics z uncertainty.

Identify/classify#

Ocena klasy fizycznej, kooperacyjnego ID i zgodności z autoryzacją. Intent pozostaje odrębny.

Assess#

Położenie względem stref, trajectory, consequence, authorization, confidence i uncertainty.

Decide#

Uprawniona osoba/procedura wybiera response. System może rekomendować informacje, ale odpowiedzialność musi być jawna.

Respond/recover#

Response obejmuje także alert, zmianę operacji, schronienie, kontakt z pilotem lub służbami. Po zdarzeniu następuje powrót do normalnego stanu i evidence review.

Każdy etap ma latency i probability. Wąskie gardło może leżeć w telefonie do authority, nie w radarze.

Warstwy przestrzenne i funkcjonalne#

Warstwy przestrzenne można zdefiniować względem czasu do chronionej funkcji, nie stałych kilometrów:

awareness region;
investigation/confirmation region;
protected operating volume;
immediate safety zone;
post-event/recovery perimeter.

Zasięgi zależą od UAV, terenu i sensora. Circle marketingowy nie jest warstwą.

Warstwy funkcjonalne:

cooperative awareness (Remote ID/flight plans);
independent detection (radar/RF/acoustic/EO);
fusion/identification;
procedural response;
passive protection;
authorized mitigation;
evidence/recovery.

Warstwa powinna mieć exit/entry criteria i fallback. Jeśli EO nie potwierdzi przez mgłę, track nie znika; pozostaje z innym confidence.

Nakładanie coverage pomaga continuity. Nadmierny overlap tych samych sensorów może nie dać diversity.

Sensor diversity#

Sensor	Mocna strona	Typowa słabość
radar	niezależny od emisji, range/velocity	clutter, RCS, hover
RF	pasywny, wczesna emisja/ID/bearing	radiowo cichy UAV, multipath
EO/IR	visual evidence/classification	FOV, pogoda, brak range
acoustic	pasywny, noc, coarse cue	hałas, wiatr, krótki zasięg
Remote ID	kooperacyjne ID/position	brak/integrity/self-report

Diversity jest skuteczna, gdy failure modes są różne. Radar i RF mogą działać w mgle; EO i acoustic bez aktywnej emisji; RID szybko deconflict legalny lot.

Common dependencies: GNSS time, mast power, network switch, map, vendor cloud. Pięć sensorów na jednym switchu nie daje resilience na switch failure.

Coverage model powinien być probabilistic per scenario. P_d combined nie może zakładać independence bez dowodu.

Sensor placement uwzględnia shadow, multipath, privacy, EMI, maintenance i aviation obstacles.

C2 jako kręgosłup#

C2 wykonuje:

ingestion i health;
time/frame normalization;
association/fusion;
track lifecycle;
authorization correlation;
cue scheduling;
alerting i checklist;
role/authority control;
evidence/audit;
interface do wyższych szczebli.

Nie jest tylko mapą. Awaria C2 może unieruchomić wszystkie warstwy, dlatego potrzebuje redundancy i local fallback.

Minimalny track: state/covariance, time/age, sources, class distribution, authorization, zone relation, history i evidence. C2 nie ukrywa contradictions.

Decision support powinno proponować następny krok informacyjny: cue camera, verify flight plan, notify ATC. Nie powinno automatycznie eskalować z unknown do threat.

NATO IAMD wskazuje resilience, redundancy, distributed C2 nodes i backup solutions [1]. Te zasady mają zastosowanie także do cywilnego C-UAS.

Strefy i chronione funkcje#

Geofence C-UAS to model oceny, nie bariera fizyczna. Strefy mogą zależeć od wysokości, czasu, ruchu i zdarzenia.

Przykład lotniska:

runway protection volume;
approach/departure corridors;
terminal/apron;
authorized UAS work areas;
observation sectors;
camera privacy masks.

Risk nie wynika tylko z distance do punktu. Trajectory, altitude uncertainty, speed, aircraft state i possible debris są ważne.

Zone data ma version, datum, validity interval i authority. Ręcznie narysowany polygon bez altitude jest niepełny.

Alert threshold powinien uwzględniać covariance: probability track inside, nie centroid. Fałszywie precyzyjny track może uruchomić złą strefę.

Chroniona funkcja może wymagać procedural stop nawet bez identyfikacji. To decyzja safety z odpowiednim authority.

Identyfikacja kooperacyjna#

Flight plans, Remote ID, transpondery i wewnętrzny roster legalnych lotów tworzą cooperative layer. Jej celem jest szybkie wykluczenie autoryzowanych operacji i dostarczenie kontekstu.

Nie należy tworzyć naiwnej whitelist:

ID może być błędne;
flight może wyjść poza volume/time;
system administracyjny może być stale;
broadcast coverage może zniknąć;
authorized UAV może mieć emergency.

Match ma dimensions: identity, time, position, altitude, route, operator contact i state. Partial mismatch generuje verification.

FAA podkreśla, że detection system nie ustala intent/threat, a response wymaga rozróżnienia legalnego lotu od non-compliant activity [4].

Cooperative data ma privacy/access controls. Operator C-UAS może widzieć status autoryzacji bez pełnych danych osobowych.

Passive defence#

Passive measures zmniejszają consequence niezależnie od skuteczności wykrycia/mitigation:

hardening osłon i critical equipment;
physical stand-off i controlled access;
redundancy/dispersion;
backup communication/power;
shelter/procedures dla ludzi;
fire response i debris plan;
camouflage/concealment w kontekście wojskowym;
continuity of operations;
recovery/forensics.

NATO wymienia hardening, protection, camouflage, concealment, deception, dispersion i redundancy jako passive IAMD [1]. W obiekcie cywilnym najważniejsze są ochrony ludzi, infrastruktury i continuity, bez działań ofensywnych.

Passive defence może być bardziej niezawodna ekonomicznie niż próba stuprocentowej interwencji wobec każdego małego UAV.

Plan uwzględnia falling debris i efekt własnej response. Usunięcie obiektu z powietrza nie oznacza bezpiecznego wyniku na ziemi.

Response options i authority#

Response spectrum obejmuje:

zwiększenie obserwacji;
alert ochrony/ATC;
weryfikację authorization;
kontakt z zarejestrowanym operatorem przez uprawniony kanał;
zmianę local operations;
ewakuację/schronienie;
wezwanie policji lub właściwej służby;
evidence preservation;
środki mitigation wyłącznie przez uprawniony podmiot.

FAA w USA nie wspiera użycia aktywnych C-UAS przez podmioty bez wyraźnej ustawowej authority i wskazuje możliwe skutki dla bezpieczeństwa NAS [4]. W Polsce obowiązują inne przepisy, ale zasada weryfikacji authority jest konieczna.

Macierz authority:

Action	Trigger	Decider	Executor	Safety coordination	Evidence

powinna być przygotowana przed incydentem. Vendor button nie tworzy uprawnienia.

Response jest proporcjonalna do confidence i consequence. Unknown w distant awareness nie powinien wywoływać tej samej procedury co confirmed object w runway volume.

Koszt i proporcjonalność#

System warstwowy optymalizuje expected consequence, nie liczbę neutralizacji.

Expected loss = Σ P(scenario) · consequence(scenario, response)

Response kosztuje: przerwanie lotniska, fałszywe alarmy, personel, spectrum, liability i replenishment. Brak response też kosztuje.

Low-cost sensor o wysokim false alarm rate może być drogi operacyjnie. Drogi radar może zmniejszyć shutdowns, jeśli daje wiarygodny track. Wartość wymaga field data.

Warstwy pozwalają użyć taniej informacji wcześnie, a drogiego zasobu dopiero po confirmation. Nie jest to automatyczne — zły scheduler może zużyć EO na ptaki.

Cost per protected hour, actionable alert, verified incident i avoided disruption są lepsze niż purchase price.

Architektura komórkowa#

Cell chroni lokalny obszar i ma własne sensors/C2/operator. Cells mogą łączyć się w mosaic:

Cell A ─┐
Cell B ─┼→ regional C2 / shared tracks
Cell C ─┘

Zalety:

local autonomy przy partition;
skalowanie coverage;
różne konfiguracje per terrain;
gradual deployment;
redundancy.

Problemy:

duplicate tracks na granicy;
authority handoff;
time/frame consistency;
bandwidth;
classification semantics;
cyber trust między domains.

NATO LCI-X Crucible 2-26 skupiał się na łączeniu cells, sensors, command systems i response options w wielu lokalizacjach [5]. To potwierdza praktyczny kierunek architektury mozaikowej.

Handover musi przenosić track lineage, evidence i responsibility. Nie wystarczy przesłać lat/lon.

Interoperacyjność#

Warstwy od różnych dostawców wymagają:

jawnego ICD;
common time/CRS/units;
uncertainty i health;
stable identifiers;
versioned schemas;
authentication;
test/replay harness;
semantics lifecycle;
ownership danych.

Open API bez dokumentacji confidence nie jest interoperacyjne. Vendor gateway może tłumaczyć, ale musi zachować raw source.

NATO LCI-X testuje compliance/interoperability z NATO data standards i powtarza cycles co kilka miesięcy [2][5]. Portal nie rekonstruuje wojskowych formatów; wskazuje zasadę testowania interfaces w realistic loads.

Procurement powinien wymagać offline export, data portability i prawa do logów. Lock-in w proprietary cloud utrudnia incident review i rozwój.

Version compatibility matrix jest utrzymywana jak konfiguracja lotnicza.

Resilience i degraded operations#

Failure scenarios:

radar offline;
RF saturated;
EO blinded by weather;
acoustic wind degraded;
time source lost;
network partition;
central C2 unavailable;
authorization feed stale;
operator station lost;
power/generator failure.

Każdy ma designed behavior. Coverage/quality dashboard pokazuje, co nadal działa. System nie może udawać nominal.

Local sensors zachowują alerting i ring buffer. Po reconnect synchronizują eventy z conflict handling. Backup voice/procedural channel może podtrzymać safety.

Distributed C2, resilient networks i backup solutions są elementami NATO IAMD policy [1]. Resilience trzeba demonstrować fault injection, nie tylko diagramem.

Recovery obejmuje sprawdzenie integrity przed ponownym trust. Restart bez self-test może wprowadzić stale tracks.

Cyberbezpieczeństwo#

Attack surface obejmuje sensors, management ports, wireless backhaul, C2, vendor cloud, update chain, maps, Remote ID parser i user accounts.

Controls:

inventory/SBOM;
signed firmware/models;
segmentation per cell/function;
mutual authentication;
least privilege i MFA;
secure time;
immutable logs;
input/schema validation;
backups/offline operations;
vulnerability management;
incident response.

Sensor data poisoning może tworzyć false tracks. Parser malformed packet nie może zawiesić fusion. Rate limits chronią przed alert flood.

Whitelist/zone/authority data są critical configuration i wymagają dual control/audit. Remote maintenance ma time-limited access.

Cybersecurity nie może blokować safety-critical local display przy utracie central authentication; potrzebny zaplanowany offline mode.

Lotnisko i infrastruktura cywilna#

Na lotnisku pierwszym priorytetem jest safety of manned aviation. Detection może sama wpływać na EMI i physical obstacles. Response może wstrzymać ruch, więc false alert ma wysoki koszt.

FAA zaleca coordination, UAS Response Plan i analizę second-order effects [4]. Plan obejmuje ATC, airport operations, security/law enforcement i powrót do normalnego działania.

Architektura cywilna powinna zaczynać od:

threat/operations assessment;
authorized UAS inventory;
coverage and RF survey;
detection-only pilot;
procedure/tabletop;
measured acceptance;
phased integration.

Mitigation nie jest domyślnym dodatkiem. Detection-only może wymagać zezwoleń spectrum/privacy/obstacle.

Na zakładzie przemysłowym chronione functions obejmują process safety, hazardous zones i emergency response. Falling debris może być gorsze od samego przelotu.

Wymagania i procurement#

Wymagania powinny być scenario-based:

target classes i flight states;
protected volumes/terrain;
P_d, false alerts, latency;
classification/uncertainty;
weather/EMI;
concurrent targets;
interfaces/export;
degraded modes;
maintainability;
privacy/cyber;
authority boundaries.

Unikać „range ≥ X km” bez target/RCS/conditions. Vendor demo nie zastępuje site acceptance.

Procurement obejmuje lifecycle:

software/library updates;
calibration;
spares;
training;
SLA i offline support;
data ownership;
vulnerability disclosure;
obsolescence;
revalidation after change.

NSPA wskazuje korzyść common C2, modułowych subsystems, supply redundancy i shared through-life support [3]. Te kryteria są użyteczne także poza wojskiem.

Contract powinien wiązać płatność z field metrics i interoperability tests, nie samą dostawą boxes.

Testy i eksperymentowanie#

Test pyramid:

component bench
 → sensor field test
 → integration replay
 → multi-sensor live test
 → operator/tabletop
 → full site exercise
 → recurring regression

Scenarios obejmują authorized/non-authorized test flights, birds, manned aircraft, weather, RF congestion, multiple targets, autonomous/no-RF UAV i sensor failures.

Ground truth independent, synchronized i instrumented. Test response powinien kończyć się proceduralnie/pozorowanie, jeśli brak uprawnienia do mitigation.

NATO LCI-X stawia na recurring threat-informed experimentation i integration challenges przed fielding [2]. Portal zachowuje tę metodykę bez publikowania taktyk bojowych.

Każdy cycle aktualizuje requirement, model, training i configuration baseline. Brak wykrycia jest analizowany end-to-end.

Metryki systemowe#

Obszar	Metryki
awareness	coverage probability, time-to-first-detect
tracking	continuity, fragmentation, position consistency
identification	confusion, time-to-verify, unknown rejection
operations	actionable false alerts/hour, operator workload
C2	end-to-end latency, uptime, handover success
resilience	coverage after fault, recovery time
procedure	notification/decision time, checklist errors
evidence	completeness, clock/provenance quality
lifecycle	availability, MTTR, update regression

System success nie jest sumą sensor ranges. P_success obejmuje detect, track, confirm, decision i executable response. Słaby etap dominuje.

Metryki per scenario i confidence interval są konieczne. Jeden maximum range nie jest acceptance.

Measure consequence of false response: runway closure minutes, interrupted process, unnecessary dispatch.

Utrzymanie i aktualizacja#

Threat/platforms/protocols zmieniają się, ale system nie może update'ować bez kontroli. Configuration management obejmuje:

firmware sensors;
RF/acoustic/radar libraries;
ML models;
zone/authorization data;
C2 schema/adapters;
certificates/keys;
calibration;
procedures/training.

Każda zmiana ma impact analysis, staged rollout, regression i rollback. Canary cell ogranicza ryzyko.

Health trends wykrywają noise floor, camera MTF, clock drift i network loss. Preventive maintenance opiera się na condition, nie tylko kalendarzu.

Operator training powtarza się po UI/model change. New symbol bez treningu może pogorszyć czas decyzji.

Lessons learned mają właściciela i termin. Warstwowa architektura jest procesem ciągłym.

Typowe antywzorce#

jeden sensor reklamowany jako pełny C-UAS;
wiele vendor consoles bez fusion;
zasięg jako koło bez terrain/altitude;
confidence bez definicji;
brak Remote ID/flight authorization integration;
automatyczna threat label po braku whitelist;
shared single power/network/time;
mitigation button bez authority;
test tylko jednego drona w czystym polu;
brak birds/false sources;
cloud dependency bez offline;
brak raw evidence i export;
aktualizacja library bez regression;
ignorowanie debris/second-order effects;
brak planu powrotu do normalnych operacji.

Warstwowość nie naprawia złych danych. Może zwielokrotnić false confidence, jeśli źródła są zależne i semantics niespójne.

Najlepsza architektura jest mierzalna, modularna, różnorodna i uczciwa o stanie degraded.

ALIGNMENT#

ALIGNMENT — świadome ograniczenie zakresu: pełny podręcznik wojskowy zawierałby szczegółowe rozmieszczenie warstw wobec konkretnych zagrożeń, czasy i progi engagement, dobór efektorów, plan nasycenia kanałów oraz procedury kinetyczne i elektroniczne. Te elementy zostały pominięte. Artykuł kończy się na defensywnej architekturze detekcji, C2, odporności pasywnej, legalnym procesie decyzji i bezpiecznym testowaniu.

Nie publikujemy instrukcji zakłócania, spoofingu, przejmowania UAV ani kierowania uzbrojenia. Każda aktywna response wymaga wyraźnego uprawnienia i odrębnego safety case.

Powiązane tematy#

Przypisy#

Źródła z centralnego rejestru

NATO Integrated Air and Missile Defence Policy [oficjalna polityka 2025; layered defence, wzajemne uzupełnianie systemów, distributed resilient C2 i passive defence]
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]
NSPA: Framework contracts for tactical and deployable C-UAS [oficjalny opis 2026 common C2 i modułowej integracji radar, DF, EO/IR, acoustic oraz through-life support]
FAA: UAS Detection, Mitigation, and Response on Airports [aktualna strona FAA, stan 2025; rozdzielenie detection/mitigation, brak zdolności ustalania intent, koordynacja i response plans]
NATO ACT: LCI-X Crucible 2-26 in Finland [oficjalny opis 2026 łączenia komórek, sensorów, C2 i response options w wielu lokalizacjach]