Mottakertillit: vurdering av en virkelig GNSS-mottakerlogg

kshana receiver-trust leser en logg fra en virkelig GNSS-mottaker (global navigation satellite system), kjører tillitsmonitorer over den epoke for epoke, og sier når og hvorfor mottakerens posisjonsbestemmelse sluttet å være pålitelig. Den kan også score loggen mot hendelser og prediksjoner du angir før kjøringen: om hver hendelse ble oppdaget i tide, og om et modellert fall i bærer-til-støy-tetthet (C/N0) stemmer med det mottakeren målte.

Observablene er mottakerens egne; monitorene og terskelverdiene deres er motorens og dine. Hvert resultat bærer den merkingen, SHA-256 for loggen og hver terskelverdi det kjørte med, slik at en kjøring kan gjentas og revideres.

For et fartøy underveis, med en levende score og en valgfri port foran et kartsystem, se MARITIME-TRUST.md.

Kjør den#

kshana receiver-trust examples/receiver-trust/session.toml

Dette skriver session.result.json, session.trust.csv (én rad per epoke) og session.trust.svg (gjennomsnittlig C/N0 over tid med tillitstilstanden under) ved siden av scenarioet, og skriver ut en enlinjers konklusjon. Eksempelloggen er syntetisk, laget for å vise formatet; pek path mot loggen fra din egen mottaker.

Figuren ovenfor er fartøysdemoen fra MARITIME-TRUST.md: en oppdiktet logg, en veiledende score.

Det samme scenarioet kan kjøres fra Python (kshana.receiver_trust(toml)), fra WebAssembly-pakken (receiver_trust(toml), med loggen innebygd) og fra verktøyet assess_receiver_log på Model Context Protocol-serveren (MCP).

Logger den leser#

Detaljer, kilder og begrensninger for disse tre: MACHINE-INPUTS.md.

Hver epoke leserne produserer, har også source_span, [start, end) byteforskyvninger inn i inndataene: det minste sammenhengende området som inneholder postene som bidro til den, slik at den nøyaktige rå delen kan hashes for et hendelsesvindu. NMEA: hver linje som leses mens epoken er gjeldende (en overmengde der en urelatert linje ligger mellom setningene). UBX: epokens rammer. RINEX 3: epokepostene fra hver >-linje til den neste. Android: epokens Raw-rader (en Fix-rad bare for en epoke uten Raw-rader). Mangler for en direkte strøm og overalt der det ikke er veldefinert (RINEX 2).

Filen leveres med path (løst opp mot scenarioets egen mappe), eller innebygd som text eller base64 (de eneste valgene i en nettleser).

En IMU-logg som en andre sensor#

[log.imu] legger til en treghetslogg på den samme klokken:

[log.imu]
format = "csv"          # or "euroc"
path = "imu.csv"        # or text / base64
heading0_deg = 90.0     # heading at the first IMU sample
yaw_axis_down = true    # body z down (NED/FRD); false for z up (ENU/FLU)
time_offset_s = 0.0     # added to the IMU clock to reach the log's t_s

Giringshastigheten integreres fra heading0_deg og fyller ut kursen der mottakerloggen ikke har noen, slik at monitoren heading-course (som trenger heading_sensor = true på plattformen) sammenligner gyrokurs med kurs over grunnen. En gyro driver: kursen er bare så god som integrasjonsvinduet, og hdg_cog_tol_deg avgjør hva som regnes som uenighet. Oppsettet csv er dokumentert i MACHINE-INPUTS.md. IMU-bytene er en del av scenarioets hash og av scenarioets hash i en bevispakke. Innebygd (text/base64) fungerer på alle flater; en path avvises der filer ikke leses.

Plattform: stasjonær eller fartøy#

Monitorene ovenfor forutsetter en fast antenne. Et scenario angir plattformen før kjøringen i en [platform]-tabell på toppnivå; uten en er plattformen static, og ingenting endres.

[platform]
kind = "vessel"            # "static" (default) or "vessel"
max_speed_kn = 30.0        # default 30
max_accel_mps2 = 0.5       # default 0.5
max_turn_rate_dps = 6.0    # default 6
antenna_height_m = 18.0    # no default: without it the sea-level monitor does not run
heading_sensor = false     # true: the stream carries a gyro heading (HDT or THS)

Fartøysnøklene avvises under kind = "static". For et fartøy kjører ikke monitoren position-jump, fordi den måler avstand fra kalibreringsmiddelverdien, noe som er galt for en bevegelig antenne; resultatets monitor_config registrerer plattformen og grensene som ble brukt.

De syntetiske NMEA-strømmene fra kshana nmea-scenario, laget for mannskapstrening, godtas av NMEA-leseren og kan kjøres gjennom denne typen som en hvilken som helst NMEA-logg.

Monitorer#

Hver monitor trenger sine data; en monitor hvis data ikke finnes i loggen, kjøres ikke og er ikke oppført i monitors_run. De første calibration_s sekundene (standard 60) setter grunnlinjen og gir aldri alarm.

Kalibrert profil (må velges). [monitors] profile = "jammertest-2024-calibrated" erstatter de tre interferenstersklene med verdier kalibrert på det offentlige JammerTest 2024-datasettet (én u-blox ZED-F9P per scenario; Zenodo 15911589): cn0_drop_db = 1.5, agc_k_sigma = 3.5, jam_ind_threshold = 29. Kalibreringen ble forhåndsregistrert (xval/jammertest-trust/PREREGISTRATION.md), og profilen er MODELLED, tilpasset én offentlig kampanje: terskelen cn0_drop_db bommet på den forhåndsregistrerte terskelen for falske alarmer i det tilbakeholdte datasettet (0,0231 mot 0,02); terskelene for AGC og jamming-indikator og unionsterskelen (falske alarmer 0,033, deteksjon 0,81) ble bestått (xval/jammertest-trust/RESULTS.md). Den gjelder for den mottakertypen ved den hendelsen, mot planlagte angrepsvinduer, og ble kalibrert på CSV-loggene i datasettet (UBX-loggene gir flere falske alarmer i to mapper). Et resultat som er kjørt med profilen, gjentar terskelverdiene som ble brukt og har en profile_note som sier alt dette. Uten profilen gjelder standardverdiene ovenfor, og alle utdata er uendret.

For en plattform av typen vessel kjører også monitorene for bevegelige plattformer (terskelverdier i en [maritime]-tabell på toppnivå, hver standardverdi dokumentert i src/receiver_trust/maritime.rs); hver trenger sine data og er bare oppført i monitors_run når den kom til en avgjørelse:

En epoke er ikke pålitelig når RAIM, klokkemonitoren, en løsningsfeil eller et posisjonshopp gir alarm, eller C/N0-fallet når to ganger terskelen; degradert ved enhver annen alarm; og nominell ellers.

Motorveien (raim, solve-failure, clock) er den samme beregningen som den uavhengige referansen for spoofing i JammerTest 2024 i tests/jammertest_spoof_oracle_support: tests/receiver_trust_jammertest.rs kontrollerer at den første alarmen, for alle åtte publiserte starttidspunkter, faller på samme epoke og er av samme slag.

Tillitsscore (fartøysplattform)#

For et fartøy får hver epoke etter kalibreringen også en score fra 0 til 100 og årsakene til at den ikke er 100. Avbildningen er deterministisk og fastsatt før noen logg scores: ingen læring, ingenting tilpasset hendelser. Hver monitor reduserer sitt belegg til et forhold statistic / threshold (en alarm ved 1 eller mer); et forhold koster scoren

points = weight * clamp((ratio - onset_ratio) / (full_ratio - onset_ratio), 0, 1)
score  = round_to_0.1( clamp(100 - sum of points, 0, 100) )

slik at en monitor ikke koster noe så lenge den er under onset_ratio av terskelen sin (standard 0,5), halvparten av vekten ved terskelen, og hele vekten ved full_ratio ganger terskelen (standard 1,5); scoren er ikke-økende i hver statistikk. En kilde som ikke rapporterer ved en epoke, beholder sin siste statistikk i evidence_hold_s (standard 10 s: to sykluser av en C/N0-setning som sendes hvert 5 s), både som alarm og som fradrag.

Avrundingen er halv opp (floor(x * 10 + 0.5) / 10), båndet er det til den avrundede scoren, og avkortingen kommer før avrundingen. Bare monitorer med poeng over null er oppført i fradragene, med forhold og uavrundede poeng, størst poeng først; fradrag med like poeng er oppført i rekkefølgen til monitornavnene cn0-drop, agc, jam-ind, loss-of-lock, position-jump, raim, clock, solve-failure, kinematic, heading-course, speed-log, sea-level, cn0-spread, cn0-rise, time-consistency, osnma, geometry. En monitor hvis test er bestått eller ikke bestått (en mislykket løsning, en mislykket autentisering) får forholdet 1,5, full vekt. De oppførte poengene er de før avkortingen ved 0.

[score]
nominal_min = 90.0         # score >= 90: nominal
degraded_min = 55.0        # 55 <= score < 90: degraded; below 55: untrusted
onset_ratio = 0.5
full_ratio = 1.5
evidence_hold_s = 10.0
[score.weights]            # overrides; a monitor not listed keeps its default
sea-level = 30.0

Båndgrensene følger av vektene: den letteste monitoren som gir alarm, koster 12,5 poeng ved terskelen, så enhver alarm forlater det nominelle båndet; ingen enkelt monitor under 60 poeng kan alene nå båndet for ikke pålitelig (flere sammen kan). Resultatet registrerer scoremodellen (score_model), og hver epoke har score.deductions: hvilke monitorer som trakk fra, forholdene deres og poengene deres. For et fartøy er epokens tilstand båndet til scoren.

Geometri: naturlig forringelse atskilt fra angrepslignende inkonsistens#

En mottaker ved siden av en kaikran, i en sluse eller under et høyt skrog mister satellitter, og posisjonsbestemmelsen blir dårligere av en grunn som ikke er et angrep. Fra 0,36, etter designnotatet for geometri (docs/design/2026-10-12-geometry-and-skyline-design.md, avsnitt 4), har hver epoke sin satellittgeometri, et fartøys score har en geometrimonitor, og hvert fradrag har en klasse: geometry (himmelen), environment (signalmiljøet) eller inconsistency (angrepslignende belegg).

Hvor geometrien kommer fra. Elevasjonen og azimuten til hver sporede satellitt (NMEA GSV, UBX NAV-SAT), som presisjonsfortynningen (DOP) utledes fra med motorens ene DOP-kjerne (orbit::dop, VALIDATED mot gnss_lib_py): source = derived. Hvis det ikke finnes, de DOP-verdiene og brukte satellittene mottakeren selv oppgir (NMEA GSA): source = reported. Himmelposisjoner og GSA teller for scorens evidence_hold_s (standard 10 s), fordi mange busser sender GSV med noen sekunders mellomrom; et GSV-sett som er ufullstendig i en epoke (slutten av et utdrag, en tapt setning), brukes ikke. En logg med ingen av delene, for eksempel NMEA med bare GGA og RMC, eller Android- og RINEX-logger i dag, får statusen unknown med merknaden "geometry unknown": motoren gjetter ikke en geometri den ikke har fått, og geometrimonitoren kjører ikke.

Statusen er beskrivende, og etiketten (nedenfor) er det som teller for scoren: degraded omfatter det informative tilfellet sky-blocked, som kan forekomme med god eller middels DOP, og bare en poor-etikett scores.

Etiketten (alltid rapportert, aldri scoret). Hver epokes geometry.label er good (HDOP høyst hdop_good 2, PDOP høyst pdop_good 3 og minst used_good 6 satellitter), poor (HDOP over hdop_max 4, PDOP over pdop_max 6 eller færre enn min_used 5 satellitter), fair mellom de to, eller unknown. Epokens merknad åpner alltid med etiketten og tallene, for eksempel "geometry fair: HDOP 1,105, PDOP 1,831, VDOP 1,410, 8 satellites; not scored (the score deducts only above HDOP 4, PDOP 6 or below 5 satellites)", og legger til ", signal loss" når det gjelder.

Geometrimonitoren (fartøysscore). Den trekker fra ingenting med mindre geometrien er dårlig: forholdet er max(hdop / hdop_max, pdop / pdop_max, min_used / n_used), og så lenge det er høyst 1 (god eller middels geometri, inkludert en åpen himmel med 8 satellitter og bare GPS) koster det ingenting, så en slik logg scorer nøyaktig som i 0,35. Over 1 øker fradraget lineært til cap_points (15) ved full_ratio (1,5 ganger terskelverdiene: HDOP 6, PDOP 9, 3 satellitter): 7,5 poeng ved forholdet 1,25 (HDOP 5, eller 4 satellitter), 15 fra 1,5 og oppover (score 85, degradert). Alene kan den aldri ta scoren under floor (standard: scorens degraded_min, 55), så geometri alene når høyst det degraderte båndet og aldri det som ikke er pålitelig: den gjeldende grensen er min(cap_points, 100 - floor), så en [score]-tabell som hever degraded_min (for eksempel en fra 0,35 med degraded_min 90) senker grensen til 100 - degraded_min i stedet for å bli avvist, og et floor satt under degraded_min avvises. Monitoren gir ingen alarm; den er oppført sist i monitors_run når den kom til en avgjørelse ved en epoke (et fartøy der loggen gir geometrien), og den telles ikke i identiteten med 0,35; den er ikke en [score.weights]-oppføring (å sette en avvises), og grensen og gulvet som gjelder, registreres i geometry_model.cap_in_force og geometry_model.floor_in_force. Merknaden for en dårlig epoke sier hvorfor, for eksempel "geometry poor: HDOP 5,200, PDOP 7,900, VDOP 4,100, 7 satellites; degraded by geometry: HDOP 5,200 above 4 (derived from 7 logged satellites); not an inconsistency".

Klasser. Hvert fradrag (score.deductions[].class):

Vernet mot en forfalsket dårlig himmel. En spoofer kunne sende en tynn GSV, eller rapportere en høy HDOP, for å kjøpe toleranse. Motoren merker og tilgir ikke: ingen annen kontroll utvides av en dårlig geometri, og HDOP-en mottakeren oppgir (GSA innenfor holdet, ellers GGA), sammenlignes med HDOP-en utledet fra himmelen den oppgir. Når de avviker med mer enn max(reported_vs_derived_tol, reported_vs_derived_rel × derived HDOP) (1,0, eller 25 % av den utledede HDOP-en, det som er størst), har epoken reported_derived_mismatch: true, og når geometrien er dårlig, klassifiseres fradraget som inconsistency. Med god eller middels geometri rapporteres uenigheten og scores ikke: ingenting trekkes fra med mindre geometrien er dårlig. Dette er et bevisst valg (0,36): «null med mindre dårlig» gjelder for hver epoke, så god og middels geometri scorer nøyaktig som i 0,35, og en forfalsket HDOP er aldri taus. Flagget (reported_derived_mismatch) står på hver epoke i resultatet og hver direktelinje, merknaden sier "…beyond the tolerance: reported, not scored (the geometry is not poor)" eller "…: the geometry deduction is classed an inconsistency", geometry_summary.hdop_mismatch teller epokene, og siden med beleggsoppsummeringen viser tallet, null medregnet. De 25 % er et REPRESENTATIVE ingeniørvalg, ikke et målt eller standardisert tall: en mottaker som løser for én klokke per konstellasjon, eller med en delmengde av satellittene den sporer (en elevasjonsmaske, et C/N0-kutt, en RAIM-utelukkelse), oppgir en HDOP som avviker fra enkeltklokke-HDOP-en for hver sporet satellitt med en størrelse som vokser med HDOP-en, så en fast toleranse alene ville lest naturlig dårlig geometri som en inkonsistens. En større forskjell leses fortsatt som en. Et fradrag klassifisert som geometry er en uttalelse om himmelen, ikke en påvisning av at intet angrep har funnet sted.

Signaltap er ikke himmelen. Når satellitter mottakeren oppgir i sikte (over low_elev_deg) ikke spores, utleder motoren også DOP for hver satellitt i sikte. Hvis denne DOP-en for satellitter i sikte er innenfor terskelverdiene, og enten ingenting spores eller de usporede satellittene er spredt rundt horisonten (ikke begrenset til én halvdel av den), var himmelen der og signalet var det ikke: epoken har signal_loss: true, merknaden "satellites in view but not tracked: signal environment, not geometry", og geometrifradraget klassifiseres som environment. Usporede satellitter begrenset til én halvdel av horisonten leses fortsatt som en blokkert himmel (en vegg, en klippe, en kai). En tosidig hindring (en canyon eller en smal fjord) leses som signaltap helt til en horisontlinje er konfigurert. Mottakerens sentinelverdier for ingen posisjonsbestemmelse er ikke DOP: en oppgitt HDOP eller PDOP på 99 eller mer, GGA-kvalitet 0 og GSA-modus 1 gir ingen oppgitt DOP.

Hva som er endret i utdataene, og hva som ikke er det. Ingen score endres med mindre geometrien er dårlig; etiketten rapporteres alltid. Tillagte nøkler: epochs[].geometry (status, reasons, source, n_used, hdop, pdop, vdop avrundet til 0,001, open_fraction (null helt til en horisontlinje er konfigurert), max_azimuth_gap_deg, age_s, reported_hdop, reported_derived_mismatch, note, in_view (satellitter oppført over low_elev_deg), signal_loss, label), class på hvert fradrag, og til slutt geometry_model (terskelverdier, hold, grensen og gulvet som gjelder, opphav, klasseregler) og geometry_summary (epoker etter status, etter etikett og etter fradragsklasse, og epokene med en uoverensstemmelse i oppgitt HDOP); score_model.weights er som i 0,35. To tester holder dette til bytene i grunnlinjen "0,36 portable" når disse nøklene er fjernet (hashene fra 0.35.0, omgjort da motoren gikk over til portabel matematikk og beholdt i testene som en oversikt over hva 0.35.0 ga ut: docs/revisions/STUDIO15-portable-math-rebaseline.md). tests/geometry_trust_no_change.rs holder hvert utdata fra begge eksempeløktene (resultat-JSON, CSV, SVG, konklusjon, gjenspilte direktelinjer, $PKSHT, Prometheus, CEF, LEEF). tests/geometry_corpus_identity.rs holder batchresultatet, oppsummeringen, direktelinjene og $PKSHT for hvert innsjekket NMEA-korpus for fartøy (demoen og referansetestdataene for sjøfart, hver også som åpen himmel med bare GPS og 8 satellitter, og mannskapstreningsscenarioene generert fra seedene sine); i de to treningsscenarioene der jamming gjør geometrien dårlig, er hver epoke som ikke er dårlig, identisk, og hver dårlig epoke avviker bare med geometrifradraget. En logg med dårlig geometri mister opptil 15 poeng den ikke mistet i 0,35; det er den tilsiktede endringen. På demoen leses drag-av som inconsistency; tests/geometry_trust.rs redigerer loggen for å maskere den vestlige himmelen (middels: merket, ikke scoret), for å maskere den og to østlige satellitter (dårlig: geometrifradrag, tap av lås environment fordi høye satellitter også gikk tapt), for å miste bare satellitter under 15° (tap av lås geometry), og for å oppgi en HDOP himmelen ikke forklarer (fradraget for dårlig geometri blir inconsistency). Terskelverdiene er MODELLED: valgt, ikke tilpasset noen logg; ingenting her hevder hvor ofte naturlig forringelse og angrep kan skilles fra hverandre på virkelige data.

Angi hendelser og prediksjoner#

[[events]]
label = "jammer on"
kind = "jamming"            # jamming, spoofing or other
onset_s = 120.0             # seconds since the first epoch of the log
end_s = 240.0               # optional; otherwise onset_s + compare.horizon_s
predicted_cn0_drop_db = 12.0  # optional, e.g. from a `jamming` scenario's link budget

[compare]
detect_tol_s = 10.0         # an alarm this soon after onset counts as a detection
cn0_tol_db = 3.0            # predicted and observed drops agree within this

For hver hendelse gir resultatet de falske alarmene mellom kalibrering og start, den første alarmen og monitorene bak den, latensen, utfallet (detected, late, missed eller not-evaluable), og det observerte mediane C/N0-fallet mot prediksjonen (agree, disagree, no-prediction eller not-evaluable). Uenighet rapporteres, aldri justert bort: toleransene står i scenarioet, og scenarioet er i resultatets hash.

Hva dette ikke hevder#

Tillitsmonitorene er MODELLED: terskelverdiene deres er inndata, og deteksjonsytelsen deres på virkelig interferens er det hendelsesscoringen måler, ikke noe denne typen hevder. På JammerTest 2024-øktene med spoofing fanger monitorene på motorveien noen starttidspunkter innen 10 s og er sene på andre; se raden "Clock-aided χ², RAIM, AGC, SQM fused per-epoch security FoM" i VERIFICATION-MATRIX.md for tallene. En prediksjon som stemmer med én logg, er ett datapunkt, ikke en validering.