Traduction automatique, non relue par un locuteur natif. L'anglais fait foi.

Validation et preuvesPas encore sur GitHubSource : docs/PARTNER-DATA.md

Données d'un partenaire : quelles données mesurées pourraient promouvoir une ligne MODELLED

Kshana étiquette chaque capacité dans un registre vérifié par machine (matrice de vérification). La plupart des lignes de synchronisation temporelle et de capteurs sont MODELLED : elles reposent sur des modèles déclarés, des fiches techniques publiées et des vérifications internes, et aucun enregistrement mesuré de cette classe d'appareil ne leur a été comparé. Le détenteur d'un tel enregistrement peut changer cela. Cette page dit quelles lignes, quoi envoyer, comment une soumission est vérifiée, comment elle est notée et comment elle est créditée. Elle est écrite pour un laboratoire, un fabricant ou un groupe universitaire ; ce n'est pas une offre de travail et elle ne revendique la caution de personne. À titre consultatif seulement : Kshana est un instrument d'étude, et non un équipement de navigation ou de synchronisation temporelle homologué.

Ce que signifient les étiquettes#

Étiquette Signification
VALIDATED une référence externe indépendante concorde avec la capacité selon un seuil fixé avant la comparaison. Un enregistrement mesuré d'un partenaire peut être cette référence pour la sous-affirmation qu'il couvre ; les invariants de la matrice interdisent l'étiquette sans elle
MODELLED cohérent en interne et dit à voix haute ; aucune référence externe ne couvre l'affirmation. Une ligne MODELLED comparée à des données mesurées et qui n'atteint pas le seuil reste MODELLED, et l'échec est publié
PARTNER une discipline dont l'exécution dépend, qu'un partenaire matériel détient et que Kshana ne fournit pas, par exemple les chiffres qui décrivent l'horloge ou l'interféromètre d'un partenaire. Kshana modélise ce qu'un tel appareil ferait à une chaîne de navigation ou de synchronisation temporelle ; il ne se porte pas garant de l'appareil

Une soumission peut faire passer une ligne à VALIDATED seulement pour l'affirmation que les données testent réellement, et seulement si la comparaison atteint son seuil. Elle ne peut pas faire des chiffres propres d'un appareil des chiffres dont Kshana se porte garant : ils restent ceux du partenaire (PARTNER). Le changement ou non de l'étiquette d'une ligne est la décision du propriétaire, consignée dans le commit qui la change, avec le texte de la référence indépendante disant exactement ce qui a été comparé à quoi.

Lignes que les données d'un partenaire pourraient promouvoir#

Chaque ligne ci-dessous est le texte exact de requirement d'une ligne MODELLED de la matrice (un test garde cette page et la matrice synchronisées). « Pourrait changer » dit ce qu'une comparaison préenregistrée avec des données mesurées permettrait d'affirmer si le seuil est atteint ; ce n'est jamais une promesse.

Ligne Données qui la testeraient Pourrait changer
GNSS-denied clock holdover un enregistrement de plusieurs jours d'une horloge d'une classe nommée, en marche libre après son dernier asservissement, comparé à une meilleure référence, à un intervalle d'échantillonnage d'une minute ou moins les planchers de bruit rouge par classe qui bornent les chiffres de holdover restent MODELLED aujourd'hui ; une stabilité mesurée aux longs temps de moyennage pourrait être comparée au plancher de cette classe, pour cette classe seulement
Quantum-vs-classical PNT trade & GNSS-denied resilience (13503) la déviation d'Allan mesurée, sous forme de table ou d'enregistrement de phase, de l'horloge ou de l'interféromètre atomique d'un partenaire les chiffres de compromis quantifient (sans jamais valider) l'appareil du partenaire, ils seraient donc étiquetés comme les chiffres du partenaire (PARTNER) ; l'ingestion de données d'Allan mesurées dans un modèle de bruit est déjà confrontée à un solveur indépendant
Oscillator holdover presets from public datasheets un enregistrement de phase d'un oscillateur de l'un des quatre modèles prédéfinis, sur au moins un jour si le modèle de bruit tiré de la fiche technique du modèle prédéfini reproduit la stabilité d'un exemplaire mesuré aux temps de moyennage propres de la fiche technique
Measured clock device cards (held-out prediction) un enregistrement de phase d'une classe d'horloge pas encore dotée d'une fiche (un OCXO, un rubidium, un césium, un maser, une horloge optique) une fiche ajustée sur le premier tiers et prédisant la déviation d'Allan du reste à l'intérieur du facteur préenregistré, comme déjà fait pour les horloges de satellites GNSS et un récepteur
Clock-log formats linuxptp (ptp4l, phc2sys, ts2phc) and chrony (tracking, statistics) read to a normalised phase series un journal d'une installation réelle (n'importe quelle version du démon) avec les propres lignes de synthèse du démon les lecteurs ont été construits à partir de dispositions de lignes publiques et de fixtures ; un journal réel comparé à un lecteur indépendant serait la première vérification externe
Clock-log formats (RINEX clock, TimeLab ASCII, TAPR TICC) read to a normalised phase series une exportation réelle d'un compteur ou d'un logiciel d'analyse la même chose, pour ces formats
Holdover test scored from an operator-supplied time-error record un vrai test de holdover : l'enregistrement, les instants où l'opérateur a retiré et rétabli la référence, et les propres verdicts MTIE, TDEV et de masque du laboratoire issus de son logiciel d'analyse un calcul indépendant des mêmes grandeurs à comparer à celui du moteur
IMU log ingest, gyro heading input and Allan fit of hybrid sensor parameters un journal stationnaire d'une unité inertielle dont les paramètres de bruit sont publiés ou mesurés par quelqu'un d'autre l'ajustement retrouvé à l'intérieur d'un facteur déclaré des paramètres indépendants
Quantum inertial dead-reckoning resilience un journal statique ou les paramètres de bruit du capteur inertiel à atomes froids d'un partenaire les chiffres de l'appareil sont ceux du partenaire (PARTNER) ; le budget d'erreur de position qui les compose reste le modèle de Kshana

Commencez par les deux premières : elles décident si les planchers de holdover par classe et le compromis quantique contre classique reposent sur la moindre donnée mesurée qui leur soit propre.

Quoi envoyer#

Une soumission se compose de deux fichiers dans un même dossier : les données et une petite description, un fichier TOML (kshana.partner-submission/1 ; un exemple travaillé et fictif est examples/partner-submission/submission.toml).

Données d'horloge. L'un des formats que Kshana lit (voir formats des journaux d'horloge) : journaux TICC de TAPR, phase ou fréquence ASCII de type TimeLab, RINEX clock, journaux linuxptp ptp4l, phc2sys et ts2phc, journaux de suivi et de statistiques de chrony. La phase est préférée à la fréquence ; indiquez les unités et l'intervalle d'échantillonnage. Donnez l'enregistrement ininterrompu le plus long dont vous disposez : la stabilité aux longs temps de moyennage exige des jours, et un enregistrement de moins d'un jour est accepté mais signalé par un avertissement.

Données inertielles. Un CSV à colonnes nommées (t_s, gx, gy, gz, ax, ay, az, rad/s et m/s^2) ou la disposition EuRoC, issu d'un appareil stationnaire, assez long pour l'ajustement (au moins 2000 échantillons ; des heures valent mieux).

La description indique, et le vérificateur contrôle là où il le peut :

  • le type d'organisation (un type tel que « un laboratoire national de synchronisation temporelle », et non un nom ; un nom est facultatif et seulement pour le crédit) ;
  • l'appareil (genre, classe, et un modèle pour la classe other) ;
  • comment les données ont été prises : par rapport à quoi elles ont été comparées, l'heure de début (UTC), l'environnement, et si elles sont brutes ou traitées (et ce qui leur a été fait) ;
  • le SHA-256 du fichier de données, de sorte que le fichier noté soit le fichier décrit ;
  • les lignes MODELLED pour lesquelles il est proposé, par le texte exact de l'exigence ci-dessus ;
  • la licence (un identifiant SPDX ou des mots) et la manière dont les données peuvent être utilisées dans le dépôt : public (versionnées, avec attribution), hash-only (seuls son hachage et les notes sont publiés) ou private (la note est partagée avec le seul auteur de la soumission) ;
  • trois déclarations : c'est une mesure et non une simulation, l'auteur de la soumission peut la placer sous licence pour cet usage, et les fichiers ne contiennent aucune donnée personnelle.

À ne pas envoyer. Tout ce qui est personnel ou comporte des coordonnées (le vérificateur refuse une adresse électronique ou un numéro de téléphone dans la description), tout ce qui est soumis à un contrôle des exportations ou restreint par accord, et toute donnée simulée présentée comme mesurée.

Comment une soumission est vérifiée#

  1. Format et métadonnées, par vous ou par nous, avant que quoi que ce soit s'exécute.

    kshana partner check <submission.toml>          # add --json for a machine-readable report

    Il confirme le schéma, les champs obligatoires, le hachage, les règles de licence et d'attribution, que les lignes visées existent et sont MODELLED, que les données se lisent avec le lecteur propre du moteur, et il rapporte ce qu'il a lu (échantillons, intervalle, durée, lacunes) et avertit des enregistrements courts. Le code de sortie 0 signifie complet et lisible ; 1 énumère ce qu'il faut corriger. Il ne note pas les données, ne valide aucune ligne et ne promet pas qu'elles seront utilisées.

  2. Un préenregistrement, avant toute exécution notée. Pour chaque ligne, un document dans xval/<name>/ fixe, et est versionné avant que les données soient exécutées : la ligne, le SHA-256 du fichier de données, quelle partie des données est mise de côté (rien d'ajusté ne doit la voir), la métrique et le seuil. Pour les fiches d'horloge, le modèle existant est la prédiction sur données mises de côté utilisée pour les enregistrements IGS et de récepteur : ajuster sur le premier tiers de l'enregistrement, prédire la déviation d'Allan du reste, et exiger que le rapport prédit sur mesuré soit à l'intérieur d'un facteur déclaré à chaque temps de moyennage ajusté. Un seuil n'est jamais assoupli après une exécution.

  3. Une seule exécution notée. Le résultat, chaque nombre et chaque échec compris, est publié avec la commande et le commit, et un test l'épingle. Un échec est un constat, et non un échec à cacher : la ligne reste MODELLED et la page le dit.

  4. La décision sur le registre est celle du propriétaire, par écrit, dans le commit qui change la ligne. Le texte de la référence indépendante d'une ligne promue nomme le jeu de données, sa licence et son crédit, ce qui a été comparé et ce qui ne l'a pas été.

Crédits et droits#

  • Les données restent les vôtres selon la licence que vous indiquez. hash-only et private gardent le fichier hors du dépôt.
  • Une soumission public est créditée par la ligne d'attribution que vous donnez, dans le texte de la référence indépendante de la ligne et dans le fichier de résultat.
  • Rien n'est publié sous votre nom sans votre consentement écrit ; une organisation nommée comme source est citée comme source, jamais comme garante. Aucune affirmation d'approbation ou de caution n'est faite par ou à propos d'un partenaire.
  • Vous pouvez retirer une soumission avant la publication de son résultat. Après cela, le résultat reste tel que consigné ; si vous retirez la licence des données, le fichier est supprimé du dépôt et le hachage et les notes demeurent.
  • Kshana n'émet rien et ne pilote aucun matériel. Une soumission, c'est des fichiers en entrée et un rapport en sortie.

Prospection#

Une note d'une page pour un laboratoire est rédigée à l'intention du propriétaire dans docs/drafts/PARTNER-OUTREACH.md. C'est un brouillon : rien n'est envoyé, et personne n'est contacté, tant que le propriétaire n'a pas décidé.