Odporność PNT UAV — GNSS, inercja, źródła komplementarne i bezpieczna degradacja

Odporność PNT UAV oznacza zdolność do bezpiecznego wykonywania albo kontrolowanego przerwania funkcji, gdy pozycja, nawigacja lub czas są niedostępne, zdegradowane albo zmanipulowane. Nie jest synonimem „anti-jam GPS”. Obejmuje rozpoznanie zależności, różnorodne źródła, detekcję niespójności, integrity monitoring, holdover, ograniczenie funkcji i zweryfikowaną maszynę stanów.

GNSS jest wyjątkowo użyteczny, ale sygnał satelitarny jest słaby na wejściu odbiornika i może zostać zaburzony przypadkowo albo celowo. NIST zaleca risk-informed responsible use, identyfikację zależności, wykrywanie disruption/manipulation i zarządzanie skutkami [1]. USDOT po demonstracjach 11 technologii stwierdził, że żadna pojedyncza technologia nie jest uniwersalnym backupem pozycji i nawigacji; potrzebna jest różnorodność [2].

Spis treści#

P, N i T to różne funkcje
Zależności w UAV
Model zagrożeń i awarii
GNSS nie jest jednym pomiarem
Integrity i quality
Inercja i drift
Air data, barometr i magnetometr
Visual odometry i optical flow
Terrain/map matching
Źródła radiowe i kooperacyjne
Fuzja i residuals
Wykrywanie zakłócenia
Wykrywanie manipulacji
Time resilience
Maszyna stanów PNT
Failsafe zależny od misji
Architektura sprzętu
Software assurance
Testy laboratoryjne i symulacyjne
Metryki
Ograniczenia i common mode
ALIGNMENT
Powiązane tematy
Przypisy

P, N i T to różne funkcje#

Position odpowiada na „gdzie”, navigation obejmuje stan i prowadzenie, timing daje wspólne odniesienie czasu/częstotliwości. System może mieć stabilny czas bez pozycji, albo lokalną odometrię bez absolutnego odniesienia.

Wymagania należy zapisać osobno:

Funkcja	Przykład parametru	Przykład skutku utraty
position	horizontal/vertical accuracy i integrity	geofence/waypoint niepewny
velocity	error per axis, latency	błędne prowadzenie/wiatr
attitude	roll/pitch/yaw error	utrata stabilizacji lub course
time	UTC offset, holdover	złe timestampy/fuzja/link
frequency	drift	utrata synchronizacji protokołu

GNSS dostarcza position, velocity i time. INS dostarcza ciągłą względną dynamikę, ale dryfuje. Barometr daje względną wysokość, nie absolute 3D. Kamera daje motion względem sceny. „Backup GPS” musi więc wskazać, którą funkcję i przez jaki czas podtrzymuje.

Resilience nie oznacza nieprzerwanej pełnej capability. Może oznaczać bezpieczne utrzymanie attitude, wyjście z tłumu, lądowanie w zdefiniowanej strefie albo pozostanie na tether.

Zależności w UAV#

PNT zasila więcej niż nawigację:

EKF state i autopilot;
geofence;
return-to-home;
waypoint mission;
camera geotag i mapping;
timestamp sensor fusion;
TDMA/mesh synchronization;
logs/incident reconstruction;
Remote ID;
payload pointing;
coordination z innymi UAV/GCS.

Dependency inventory powinno mapować source → consumer → consequence. NIST PNT Profile proponuje identyfikację assets, dependencies, risks, detection, response i recovery [1].

Przykład: utrata UTC może nie wpływać natychmiast na inner-loop attitude, ale rozbić korelację między kamerą i pozycją, a po kilku minutach — secure session lub mesh slotting. System raportujący tylko GPS fix=false nie opisuje tych skutków.

Każdy consumer powinien znać quality/age, nie tylko wartość. Stara pozycja z flagą valid jest gorsza od jawnego braku.

Model zagrożeń i awarii#

Kategorie:

zasłonięcie, antenna orientation/body shadow;
multipath i non-line-of-sight;
space weather/constellation geometry;
receiver/antenna/cable/power failure;
software/configuration error;
unintentional interference;
intentional jamming;
spoofing/manipulation;
błędne correction data;
time-source fault;
map/terrain/database error;
wspólna awaria kilku „niezależnych” sources.

Model powinien określać detectability, onset, duration i hazard. Abrupt loss różni się od powolnego plausible drift. Manipulacja zgodna z dynamiką jest trudniejsza do wykrycia niż skok.

Nie każda misja potrzebuje tego samego poziomu. Laboratoryjny quadrocopter w siatce może zaakceptować natychmiastowe landing. BVLOS fixed-wing wymaga większej continuity, alternatywnych odniesień i airspace plan.

Threat model nie jest instrukcją ataku. Służy wyborowi monitorów i bezpiecznych stanów.

GNSS nie jest jednym pomiarem#

Receiver obserwuje pseudoranges, carrier phase, Doppler, C/N0, satellite geometry i navigation data. High-level API często redukuje to do lat/lon/fix type, tracąc diagnostics.

Przydatne quality indicators:

liczba i geometria satelitów;
C/N0 per satellite;
residuals i RAIM/integrity flags;
solution type: standalone/DGNSS/RTK float/fix;
age of corrections;
receiver clock bias/drift;
Doppler consistency;
multi-constellation/frequency agreement;
antenna current/open-short;
time pulse status.

Więcej konstelacji zwiększa availability, ale nie gwarantuje independence: wspólna antenna/front-end może zostać zakłócona, a różne systems współdzielą podobne pasma i środowisko.

RTK zwiększa accuracy w dobrych warunkach, lecz dodaje correction link i reference integrity. Stary fix bez aktualnych corrections powinien zostać zdegradowany, nie utrzymany etykietą fixed.

Integrity i quality#

Accuracy opisuje typowy błąd; integrity — zdolność ostrzeżenia, że błąd przekracza limit. Availability i continuity są kolejnymi wymiarami.

Protection level powinien być porównywany z alert limit:

jeśli HPL < HAL i VPL < VAL → funkcja może być dostępna
inaczej → degrade/alert

Nie każdy tani receiver publikuje certyfikowane protection levels. Można tworzyć application-level bounds z residuals i cross-checks, ale trzeba uczciwie opisać metodę.

Quality state powinien być wielowymiarowy:

source_quality = {accuracy, integrity, age, continuity,
                  environment, fault_flags, provenance}

Jedna liczba HDOP nie jest integrity. Dobra geometria nie wyklucza wspólnego biasu/manipulation.

Consumer powinien mieć requirement: mapping payload może przestać geotagować, podczas gdy attitude loop nadal działa.

Inercja i drift#

IMU mierzy specific force i angular rate. Integracja biasów powoduje drift. Dla stałego accel bias b_a position error rośnie w uproszczeniu:

e_p ≈ 0,5 · b_a · t²

Gyro bias obraca gravity projection i może dać jeszcze szybszy error poziomy. Jakość INS zależy od kalibracji, temperatury, vibration i observability podczas wcześniejszej fuzji.

IMU jest doskonałym bridge na krótki czas, ale „działa bez GPS” nie mówi, jak długo i z jakim error. Consumer-grade MEMS nie jest strategic-grade INS.

Dual IMU pomaga wykryć hardware fault, ale sensors na tej samej PCB mają common temperature/vibration. Różnorodność mounting i model może zwiększyć independence, kosztem kalibracji.

Estimator powinien publikować covariance rosnące w GNSS-denied. Zamrożenie pozycji albo niezmienne accuracy jest błędem.

Air data, barometr i magnetometr#

Barometr podtrzymuje względną wysokość, ale pressure zmienia się z weather i propwash. Pitot daje airspeed dla fixed-wing, pomagając energy management. Magnetometr wspiera heading, ale jest wrażliwy na currents, motors i local field.

Te sensors nie dają absolutnej pozycji, lecz ograniczają drift poszczególnych states:

baro → vertical channel;
pitot + wind estimate → speed/kinematics;
mag → yaw, gdy środowisko wiarygodne;
rangefinder → height AGL blisko gruntu.

Fuzja musi wykrywać fault. Magnetometer distorted przez payload nie powinien „naprawiać” INS. Airspeed blocked/icing ma własny model awarii.

Redundancja kilku barometrów w tej samej komorze nie chroni przed pressure disturbance. Sensor diversity i installation są równie ważne jak count.

Visual odometry i optical flow#

Optical flow daje motion względem obrazu. Z range/height można przeliczyć na velocity. Visual-inertial odometry estymuje trajectory i map landmarks.

Ograniczenia:

textureless water/snow/sky;
low light, blur i rolling shutter;
moving scene/vehicles/vegetation;
altitude/scale observability;
camera occlusion/contamination;
compute/thermal load;
loop-closure false match.

VIO dryfuje, choć wolniej niż czysta inercja w dobrym środowisku. Nie daje geograficznego absolute position bez map/anchor.

Camera i IMU powinny mieć precyzyjny time sync oraz extrinsic calibration. Błąd milliseconds przy szybkiej rotacji tworzy residual wyglądający jak spoofing.

Optical fallback powinien mieć quality metrics: tracked features, reprojection error, photometric state i estimator consistency.

Terrain/map matching#

Terrain-referenced navigation porównuje height profile, radar/lidar/vision z mapą. Map matching porównuje landmarks lub imagery. Daje absolute correction bez GNSS, ale zależy od mapy i obserwowalności terenu.

Flat terrain, powtarzalne pola, zmiany sezonowe/chmury i nowe budynki pogarszają wynik. Map errors są common bias.

System powinien przechowywać map version, datum, resolution, confidence i area validity. Brak match nie powinien wymuszać nearest plausible location.

Cywilnym, bezpiecznym zastosowaniem jest visual localization inspekcyjnego UAV wewnątrz hali albo względem wcześniej zmapowanej infrastruktury. Te same zasady pokazują ograniczenia bez publikowania tras wojskowych.

Map matching wymaga compute i może mieć relocalization jumps. Filter powinien gate'ować correction według residual i niezależnych sensors.

Źródła radiowe i kooperacyjne#

Możliwe complementary PNT:

UWB anchors;
Wi-Fi/cellular positioning;
terrestrial beacons;
pseudolites w autoryzowanym obiekcie;
ranging między UAV;
radar/lidar względem znanych landmarks;
tether geometry;
optical markers.

Każde ma coverage, infrastructure, spectrum i security assumptions. UWB w magazynie może dać dobry local positioning, ale nie globalną nawigację. Cellular zależy od operatora i network geometry.

USDOT po demonstracjach complementary PNT podkreślił potrzebę multiple technologies, bo żadna sama nie zastępuje globalnie GNSS position/navigation [2].

Kooperacyjne beacon może zostać błędnie skonfigurowane albo spoofed. Authentication zwiększa trust identity, ale nie gwarantuje poprawnej pozycji anteny. Survey i monitoring infrastruktury są konieczne.

Fuzja i residuals#

Estimator porównuje predictions i measurements. Innovation:

y = z - h(x⁻)
NIS = yᵀ S⁻¹ y

Duży NIS sugeruje niespójność, ale nie mówi, który source jest winny. Fault isolation wymaga redundancy i hypothesis tests.

Monitory:

GNSS velocity vs integrated IMU/airspeed;
position delta vs VIO;
clock/time consistency;
multiple receiver/constellation disagreement;
jump/rate/acceleration plausibility;
map/geofence consistency z uncertainty;
RF observables C/N0/AGC.

Threshold musi uwzględniać dynamics i covariance. Zbyt niski daje false alerts przy manewrze; zbyt wysoki przepuszcza gradual fault.

Adaptive covariance może downweight degraded source. Nie wolno jednak używać innovation do dowolnego zwiększania R aż każdy pomiar pasuje; to maskuje fault.

Filter mode i rejected measurements muszą być logowane.

Wykrywanie zakłócenia#

Defensywna detekcja interference może obserwować:

spadek C/N0 wielu satellites;
wzrost AGC/interference indicator;
utratę lock skorelowaną w pasmach;
noise floor z osobnego monitor receiver;
spatial inconsistency między antennas/vehicles;
nagłe przejście solution status.

Naturalne zasłonięcie i awaria anteny mogą wyglądać podobnie. Antenna current, orientation i environment pomagają rozróżnić.

System powinien reagować na quality, nie próbować wskazywać źródła zakłócenia bez wyspecjalizowanej sieci. Dla flight safety wystarczy wiedzieć, że GNSS jest unreliable.

Po wykryciu należy ograniczyć dependence, zachować evidence i wejść w pre-tested mode. Automatyczne agresywne manewry są zwykle gorsze od state-aware contingency.

Portal nie podaje sposobów wytwarzania ani strojenia zakłóceń.

Wykrywanie manipulacji#

Manipulation może zachować wysokie C/N0 i fix, dlatego potrzebne są cross-checks. Red flags:

position/velocity/time niespójne z inercją/air data/vision;
wspólny nietypowy residual satellite set;
clock behavior poza modelem;
abrupt albo gradual divergence od independent source;
niemożliwa kinematyka;
disagreement receivers z różnymi antennas/front-ends.

Authentication sygnału, jeśli dostępne, pomaga weryfikować origin/data, ale nie rozwiązuje multipath, meaconing i lokalnego receiver fault. System architecture nie powinna opierać resilience na jednym mechanizmie.

Gradual drift jest trudny, gdy nie ma independent absolute source. Integrity bound musi wtedy rosnąć, nawet jeśli estimator wydaje gładką trajectory.

„Spoofing detected” powinno być używane tylko przy określonych dowodach. Często bezpieczniejszy status to GNSS inconsistent/untrusted, bez przypisywania przyczyny.

Time resilience#

GNSS 1PPS synchronizuje sensors, logs, radios i cryptographic functions. Utrata position może być widoczna, ale time error narasta po cichu.

Holdover zależy od oscillator:

time_error(t) ≈ initial_offset + frequency_error · t + aging/temperature

TCXO, OCXO i disciplined oscillators mają różne SWaP i stability. UAV może potrzebować tylko millisecond sync dla logów albo microsecond dla TDOA/TDMA — wymagania determinują hardware.

Alternatywy: PTP przez wired/tether, network time, local master, inter-UAV sync, atomic source w bardzo wymagających systemach. Network time ma variable delay i security assumptions.

Time quality powinna mieć source, offset bound, holdover age, sync state. Stempel UTC bez quality jest niepełny.

NIST rozwija GPS-independent time distribution m.in. przez fiber dla infrastruktury; pokazuje to rozdzielenie time od satellite position [1].

Maszyna stanów PNT#

Przykładowe stany:

NOMINAL
  ↓ anomaly
DEGRADED_GNSS (GNSS downweighted, complementary active)
  ↓ bounds exceed function limit
LOCAL_NAV_ONLY
  ↓ local bounds/time exceed
SAFE_TERMINATION / CONTROLLED_LANDING

Przejścia mają hysteresis i timers. Powrót GNSS nie powinien natychmiast resetować state; potrzebny revalidation period.

Stan jest per capability. PNT_POSITION_DEGRADED, TIME_HOLDOVER, ATTITUDE_NOMINAL mogą współistnieć. Jeden globalny GPS_FAIL nie wystarcza.

Commands operatora nie powinny wymuszać funkcji przekraczającej aktualny protection bound bez jawnej procedury. GCS wyświetla mode, źródła, bounds i remaining holdover.

Log zawiera trigger, evidence, rejected sources, actions i recovery.

Failsafe zależny od misji#

Return-to-home opiera się na pozycji i może być złą reakcją na manipulację. Hover wymaga position hold dla multirotora. Kontynuacja waypointów wymaga absolute nav. Nie ma jednego uniwersalnego failsafe.

Przykłady bezpieczne:

indoor UWB drone: utrata anchor geometry → hover VIO, potem land;
mapping fixed-wing: GNSS inconsistency → stop payload geotag, maintain attitude/airspeed, proceed do predefined safe contingency według certyfikowanej logiki;
tethered inspection: utrata GNSS → local attitude + tether constraints, controlled descent;
laboratory rig: cut motor command przez nadzorowany test stand.

Projekt uwzględnia terrain, ludzi, endurance, link i lost-link równocześnie. PNT fallback nie może kolidować z battery failsafe.

Hierarchia hazard analysis, state machine i test określa reakcję. Portal nie podaje taktycznych tras awaryjnych.

Architektura sprzętu#

Odporność może obejmować:

multi-band/multi-constellation receiver;
dwa receivers z niezależnymi antennas/front-ends;
IMU diversity;
baro/air data/mag;
camera/range sensor;
stable oscillator;
monitor RF;
protected power i EMC;
physical antenna separation/ground plane.

Dwa odbiorniki dzielące splitter i antenna nie chronią przed antenna fault/interference. Dwie antennas blisko siebie mogą mieć podobny multipath. Independence trzeba analizować per failure.

Antenna placement z dala od digital noise, transmitters i high-current wiring jest podstawą. Filter/LNA muszą tolerować własne radios. EMI chamber i in-platform test są ważniejsze niż sam datasheet receivera.

Redundant sensors zwiększają complexity i mogą wprowadzić wrong-source selection. Voter/monitor jest safety-critical.

Software assurance#

PNT software obejmuje drivers, estimator, integrity monitors, geofence, mission manager i time service. Configuration parameters są częścią baseline.

Wymagania:

bounded arithmetic i unit/frame checks;
stale/out-of-order rejection;
NaN/overflow handling;
deterministic mode transitions;
watchdog niezależny od estimator;
versioned parameters;
fault injection tests;
logs z raw quality;
secure update i rollback.

Estimator reset podczas flight może stworzyć skok. Reset policy musi preserve attitude/position continuity albo jawnie degrade consumers.

Map/database inputs mają hash/version. Correction streams mają age/authentication. Nieprawidłowy datum powinien zostać wykryty przez schema, nie w locie.

Software requirement powinno używać measurable alert limits i time-to-alert.

Testy laboratoryjne i symulacyjne#

Bezpieczne testy:

SITL z faulted measurements;
recorded GNSS/IMU replay;
hardware-in-the-loop z receiver simulator w ekranowanym laboratorium;
cable disconnect/attenuation bez emisji w eter;
antenna fault i clock drift;
visual degradation/blank frames;
map bias i stale corrections;
network/time-source loss;
tethered/contained flight z safety pilot.

RF interference testing powinno odbywać się wyłącznie w uprawnionym ekranowanym środowisku z właściwym sprzętem i procedurą. Nie opisujemy generowania sygnałów w otwartej przestrzeni.

Test matrix obejmuje onset abrupt/gradual, single/common faults, mission phases i simultaneous battery/link issue. Recovery jest równie ważne jak detection.

Ground truth independent od systemu pod testem. Jeśli reference także używa tego samego GNSS, nie mierzy common manipulation.

Metryki#

time-to-detect disruption/manipulation;
false alarm/missed detection;
position/velocity/time error and protection bound;
continuity of attitude/control;
duration usable local navigation;
mode transition latency/overshoot;
recovery time i false recovery;
mission-function availability;
safe-termination success;
log/evidence completeness;
performance per temperature/vibration/EMI.

Protection bound consistency jest ważniejsza niż sam RMSE. System, który czasem ma duży błąd bez alertu, jest gorszy od mniej dokładnego, ale uczciwego.

USDOT oceniał complementary technologies przez wiele measures of effectiveness, zamiast jednej accuracy [3]. UAV powinien robić podobnie.

Metryki muszą mieć time horizon. INS error 10 m bez „po ilu sekundach i w jakiej dynamice” nie ma sensu.

Ograniczenia i common mode#

Nie istnieje source zawsze dostępne. Vision zawodzi w nocy/mgle/textureless, map matching na zmienionym terenie, RF anchors przy awarii infrastruktury, INS dryfuje, baro zmienia się z pogodą.

Common modes:

wspólny power/clock/bus;
wszystkie sensors na jednej rigid body z vibration;
wspólny GNSS antenna/front-end;
ten sam map/datum;
software defect w jednym estimatorze;
wspólne environment;
błędny ground truth/test.

Resilience pochodzi z diversity, monitoring i controlled degradation. Dodanie sensorów bez hazard analysis może zwiększyć liczbę cichych błędów.

Publiczne claims „GNSS-denied” wymagają pytań: jaka funkcja, czas, environment, error bound, initialization i recovery? Bez nich są marketingowe.

ALIGNMENT#

ALIGNMENT — świadome ograniczenie zakresu: pominięto sposoby wytwarzania jammingu/spoofingu, parametry nadajników, scenariusze obchodzenia konkretnych odbiorników i operacyjne wykorzystanie błędów PNT. Testowanie opisano wyłącznie w symulacji, przez replay, HIL i ekranowane laboratorium. Celem jest odporność oraz bezpieczna degradacja zwykłych UAV.

Nie przedstawiamy także wojskowych algorytmów nawigacji terminalnej ani map tras. Opis dotyczy assurance, monitoring i state machines.

Powiązane tematy#

Przypisy#

Źródła z centralnego rejestru

NIST: Responsible Use of Positioning, Navigation and Timing Services [oficjalny portal i NISTIR 8323 Rev. 1; inventory zależności, risk-informed PNT, detection disruption/manipulation, response i recovery]
U.S. DOT: Results of Complementary PNT and GPS Backup Demonstration [oficjalne podsumowanie 2021; 11 technologii i wniosek, że żadna pojedyncza nie zastępuje uniwersalnie GPS position/navigation]
U.S. DOT: Complementary PNT and GPS Backup Technologies Demonstration Report [oficjalny raport z terenowych demonstracji i wielu measures of effectiveness]
GPS.gov: Resilience Through Responsible Use of PNT [oficjalny zbiór wytycznych i zasada planowania utraty oraz weryfikowania integralności PNT]