Partnerdata: hvilke målte data som kan løfte en MODELLED-rad

Kshana merker hver funksjon i et maskinkontrollert register (verifikasjonsmatrise). De fleste rader for tidssynkronisering og sensorer er MODELLED: de hviler på oppgitte modeller, publiserte databladdata og interne kontroller, og ingen målt registrering av enhetsklassen er sammenlignet med dem. Den som har en slik registrering, kan endre det. Denne siden sier hvilke rader, hva du skal sende, hvordan en innsending kontrolleres, hvordan den skåres og hvordan den krediteres. Den er skrevet for et laboratorium, en produsent eller en universitetsgruppe; den er ikke et tilbud om oppdrag, og den gir ikke inntrykk av at noen støtter den. Kun veiledende: Kshana er et studieinstrument, ikke typegodkjent navigasjons- eller tidsutstyr.

Hva merkelappene betyr#

Etikett	Betydning
VALIDATED	en uavhengig ekstern referanse stemmer med funksjonen under en terskel fastsatt før sammenligningen. En målt registrering fra en partner kan være den referansen for delpåstanden den dekker; matriseinvariantene forbyr merkelappen uten en
MODELLED	internt konsistent og sagt høyt; ingen ekstern uavhengig referanse dekker påstanden. En MODELLED-rad som sammenlignes med målte data og bommer, forblir MODELLED, og bommet publiseres
PARTNER	en disiplin kjøringen støtter seg på, som en maskinvarepartner eier og Kshana ikke leverer, for eksempel tallene som beskriver en partners egen klokke eller interferometer. Kshana modellerer hva en slik enhet ville gjort med en navigasjons- eller tidskjede; den går ikke god for enheten

En innsending kan flytte en rad til VALIDATED bare for den påstanden dataene faktisk tester, og bare hvis sammenligningen når terskelen sin. Den kan ikke gjøre en enhets egne tall til noe Kshana går god for: de forblir partnerens (PARTNER). Om en rads merkelapp endres, er eierens beslutning, registrert i commit-en som endrer den, med referanseteksten som sier nøyaktig hva som ble sammenlignet med hva.

Rader en partners data kan løfte#

Hver rad nedenfor er den nøyaktige requirement-teksten til en MODELLED-rad i matrisen (en test holder denne siden og matrisen i takt). «Kan endre» sier hva en forhåndsregistrert sammenligning med målte data ville understøtte hvis terskelen nås; det er aldri et løfte.

Rad	Data som ville teste den	Kan endre
`GNSS-denied clock holdover`	en registrering over flere dager av en klokke av en navngitt klasse, fritt løpende etter siste styring, sammenlignet med en bedre referanse, med et samplingsintervall på ett minutt eller mindre	gulvene for rødt støy per klasse som begrenser holdover-tallene, forblir MODELLED i dag; en målt stabilitet ved lang midlingstid kunne sammenlignes med gulvet for den klassen, bare for den klassen
`Quantum-vs-classical PNT trade & GNSS-denied resilience (13503)`	den målte Allan-deviasjonen, som tabell eller som faseregistrering, for en partners klokke eller atominterferometer	avveiningstallene kvantifiserer (aldri validerer) partnerenheten, så de ville bli merket som partnerens tall (PARTNER); innlesingen av målte Allan-data i en støymodell er allerede avstemt mot en uavhengig løser
`Oscillator holdover presets from public datasheets`	en faseregistrering av en oscillator av en av de fire forhåndsinnstilte modellene, over minst ett døgn	om forhåndsinnstillingens databladavledede støymodell gjengir stabiliteten til en målt enhet ved databladets egne midlingstider
`Measured clock device cards (held-out prediction)`	en faseregistrering av en klokkeklasse som ennå ikke har kort (en OCXO, en rubidium-, en cesium-, en maser- eller en optisk klokke)	et kort tilpasset på første tredjedel som forutsier Allan-deviasjonen for resten innenfor den forhåndsregistrerte faktoren, slik det allerede er gjort for GNSS-satellittklokker og én mottaker
`Clock-log formats linuxptp (ptp4l, phc2sys, ts2phc) and chrony (tracking, statistics) read to a normalised phase series`	en logg fra en ekte installasjon (en hvilken som helst daemon-versjon) med daemonens egne sammendragslinjer	leserne ble bygget fra offentlige linjeoppsett og fixtures; en ekte logg sammenlignet med en uavhengig leser ville være den første eksterne kontrollen
`Clock-log formats (RINEX clock, TimeLab ASCII, TAPR TICC) read to a normalised phase series`	en ekte eksport fra en teller eller analyseprogramvare	det samme, for de formatene
`Holdover test scored from an operator-supplied time-error record`	en ekte holdover-test: registreringen, tidspunktene operatøren fjernet og gjenopprettet referansen, og laboratoriets egne MTIE-, TDEV- og maskeavgjørelser fra analyseprogramvaren	en uavhengig beregning av de samme størrelsene å sammenligne med motorens
`IMU log ingest, gyro heading input and Allan fit of hybrid sensor parameters`	en stasjonær logg fra en treghetsenhet hvis støyparametere er publisert eller målt av noen andre	tilpasningen gjenvunnet innenfor en oppgitt faktor av de uavhengige parameterne
`Quantum inertial dead-reckoning resilience`	en statisk logg eller støyparametrene til en partners kaldatom-treghetssensor	enhetstallene er partnerens (PARTNER); posisjonsfeilbudsjettet som setter dem sammen, forblir Kshanas modell

Start med de to første: de avgjør om gulvene for holdover per klasse og avveiningen mellom kvante og klassisk hviler på noen egne målte data.

Hva du skal sende#

En innsending er to filer i én mappe: dataene og en kort beskrivelse av dem, en TOML-fil (kshana.partner-submission/1; et gjennomarbeidet, oppdiktet eksempel er examples/partner-submission/submission.toml).

Klokkedata. Ett av formatene Kshana leser (se klokkeloggformater): TAPR TICC-logger, TimeLab-lignende ASCII-fase eller -frekvens, RINEX-klokke, linuxptp-loggene ptp4l, phc2sys og ts2phc, samt chrony-sporings- og statistikklogger. Fase foretrekkes framfor frekvens; oppgi enhetene og samplingsintervallet. Gi den lengste uavbrutte registreringen du har: stabilitet ved lang midlingstid krever dager, og en registrering på under ett døgn aksepteres, men det gis en advarsel.

Treghetsdata. En CSV med navngitte kolonner (t_s, gx, gy, gz, ax, ay, az, rad/s og m/s^2) eller EuRoC-oppsettet, fra en stasjonær enhet, lang nok for tilpasningen (minst 2000 sampler; flere timer er bedre).

Beskrivelsen oppgir følgende, og kontrollen verifiserer det der den kan:

organisasjonstypen (en type som «et nasjonalt tidslaboratorium», ikke et navn; et navn er valgfritt og bare for kreditering);
enheten (slag, klasse og en modell for klassen other);
hvordan dataene ble tatt: hva de ble sammenlignet med, starttidspunktet (UTC), miljøet, og om de er rå eller bearbeidet (og hva som er gjort med dem);
SHA-256 for datafilen, slik at filen som skåres, er filen som er beskrevet;
MODELLED-radene den tilbys mot, med den nøyaktige kravteksten ovenfor;
lisensen (en SPDX-identifikator eller ord) og hvordan dataene kan brukes i repositoriet: public (committet, med kreditering), hash-only (bare hashen og skårene publiseres) eller private (skåren deles bare med den som sendte inn);
tre erklæringer: det er en måling og ikke en simulering, innsenderen kan lisensiere den til denne bruken, og filene inneholder ingen personopplysninger.

Ikke send. Alt personlig eller med kontaktopplysninger (kontrollen avviser en e-postadresse eller et telefonnummer i beskrivelsen), alt som er under eksportkontroll eller begrenset av avtale, og alle simulerte data som framstilles som målt.

Hvordan en innsending kontrolleres#

Format og metadata, av deg eller oss, før noe kjøres.
```
kshana partner check <submission.toml>          # add --json for a machine-readable report
```
Den bekrefter skjemaet, de påkrevde feltene, hashen, reglene for lisens og kreditering, at målradene finnes og er MODELLED, at dataene kan leses med motorens egen leser, og den rapporterer hva den leste (sampler, intervall, spenn, hull) og advarer om registreringer som er korte. Avslutningsstatus 0 betyr komplett og lesbar; 1 lister opp hva som må rettes. Den skårer ikke dataene, validerer ingen rad og lover ikke at de blir brukt.
En forhåndsregistrering, før noen skåret kjøring. For hver rad fastsetter et dokument i xval/<name>/ følgende, og det committes før dataene kjøres: raden, SHA-256 for datafilen, hvilken del av dataene som holdes tilbake (ingenting som tilpasses, får se den), metrikken og terskelen. For klokkekort er den eksisterende malen den tilbakeholdte prediksjonen som ble brukt for IGS- og mottakerregistreringene: tilpass på første tredjedel av registreringen, forutsi Allan-deviasjonen for resten, og krev at forholdet mellom predikert og målt ligger innenfor en oppgitt faktor ved hver tilpassede midlingstid. En terskel løsnes aldri etter en kjøring.
Én skåret kjøring. Resultatet, med hvert tall og hvert bom, publiseres med kommandoen og commit-en, og en test fester det. Et bom er et funn, ikke en svikt som skal skjules: raden forblir MODELLED, og siden sier det.
Registerbeslutningen er eierens, skriftlig, i commit-en som endrer raden. Referanseteksten til en løftet rad navngir datasettet, lisensen og krediteringen, hva som ble sammenlignet og hva som ikke ble det.

Kreditering og rettigheter#

Dataene forblir dine under lisensen du oppgir. hash-only og private holder filen utenfor repositoriet.
En public-innsending krediteres med kredittlinjen du oppgir, i radens referansetekst og i resultatfilen.
Ingenting publiseres under ditt navn uten ditt skriftlige samtykke; en organisasjon som er navngitt som kilde, siteres som kilde, aldri som en som støtter arbeidet. Ingen påstand om godkjenning eller støtte framsettes av eller om en partner.
Du kan trekke tilbake en innsending før resultatet er publisert. Etter det står resultatet som registrert; hvis du trekker tilbake datalisensen, fjernes filen fra repositoriet, og hashen og skårene blir stående.
Kshana sender ingenting og styrer ingen maskinvare. En innsending er filer inn, en rapport ut.

Oppsøkende arbeid#

Et ensides notat til et laboratorium er skissert for eieren i docs/drafts/PARTNER-OUTREACH.md. Det er et utkast: ingenting sendes, og ingen kontaktes, før eieren bestemmer det.