Tradução automática, não revista por um falante nativo. O inglês é a referência.

Validação e evidênciasAinda não está no GitHubFonte: docs/PARTNER-DATA.md

Dados de parceiros: o que os dados medidos poderiam promover numa linha MODELLED

O Kshana etiqueta cada capacidade num registo verificado por máquina (matriz de verificação). A maioria das linhas de temporização e de sensores é MODELLED: apoia-se em modelos declarados, folhas de dados publicadas e verificações internas, e nenhum registo medido da classe de dispositivo foi comparado com elas. Quem tem esse registo pode mudar isso. Esta página diz quais linhas, o que enviar, como um envio é verificado, como é pontuado e como é creditado. Foi escrita para um laboratório, um fabricante ou um grupo universitário; não é uma oferta de trabalho e não alega aval de ninguém. Apenas consultivo: o Kshana é um instrumento de estudo, não um equipamento de navegação ou de temporização homologado.

O que significam as etiquetas#

Etiqueta Significado
VALIDATED uma referência independente externa concorda com a capacidade sob um limiar fixado antes da comparação. Um registo medido de um parceiro pode ser essa referência para a subafirmação que ele cobre; os invariantes da matriz proíbem a etiqueta sem uma
MODELLED internamente consistente e dito em voz alta; nenhuma referência independente externa cobre a afirmação. Uma linha MODELLED que é comparada com dados medidos e não atinge o limiar permanece MODELLED, e a falha é publicada
PARTNER uma disciplina de que a execução depende, que um parceiro de hardware possui e que o Kshana não fornece, por exemplo os valores que descrevem o relógio ou o interferómetro do próprio parceiro. O Kshana modela o que tal dispositivo faria a uma cadeia de navegação ou de temporização; não dá garantias sobre o dispositivo

Um envio pode mover uma linha para VALIDATED apenas para a afirmação que os dados de facto testam, e apenas se a comparação atingir o seu limiar. Não pode tornar os valores próprios de um dispositivo algo de que o Kshana possa dar garantia: esses permanecem do parceiro (PARTNER). Se a etiqueta de uma linha muda é decisão do responsável, registada no commit que a altera, com o texto da referência independente a dizer exatamente o que foi comparado com o quê.

Linhas que os dados de um parceiro poderiam promover#

Cada linha abaixo é o texto requirement exato de uma linha MODELLED da matriz (um teste mantém esta página e a matriz em sincronia). "Poderia mudar" diz o que uma comparação fixada antecipadamente com dados medidos apoiaria se o limiar for atingido; nunca é uma promessa.

Linha Dados que a testariam Poderia mudar
GNSS-denied clock holdover um registo de dias de um relógio de uma classe nomeada, em funcionamento livre após a sua última disciplina, comparado com uma referência melhor, com intervalo de amostragem de um minuto ou menos os pisos de ruído vermelho por classe que limitam os valores de holdover permanecem MODELLED hoje; uma estabilidade medida em tempos de média longos poderia ser comparada com o piso dessa classe, apenas para essa classe
Quantum-vs-classical PNT trade & GNSS-denied resilience (13503) o desvio de Allan medido, como tabela ou como registo de fase, do relógio ou do interferómetro atómico de um parceiro os valores do estudo de compromisso quantificam (nunca validam) o dispositivo do parceiro, de modo que seriam etiquetados como valores do parceiro (PARTNER); a ingestão de dados de Allan medidos num modelo de ruído já está confrontada com um resolvedor independente
Oscillator holdover presets from public datasheets um registo de fase de um oscilador de um dos quatro modelos predefinidos, ao longo de pelo menos um dia se o modelo de ruído derivado da folha de dados da predefinição reproduz a estabilidade de uma unidade medida nos próprios tempos de média da folha de dados
Measured clock device cards (held-out prediction) um registo de fase de uma classe de relógio ainda sem cartão (um OCXO, um rubídio, um césio, um maser, um relógio ótico) um cartão ajustado no primeiro terço e que prevê o desvio de Allan do restante dentro do fator fixado antecipadamente, como já feito para relógios de satélites GNSS e um recetor
Clock-log formats linuxptp (ptp4l, phc2sys, ts2phc) and chrony (tracking, statistics) read to a normalised phase series um registo de uma instalação real (qualquer versão do daemon) com as próprias linhas de resumo do daemon os leitores foram construídos a partir de layouts de linha e ficheiros de teste públicos; um registo real comparado com um leitor independente seria a primeira verificação externa
Clock-log formats (RINEX clock, TimeLab ASCII, TAPR TICC) read to a normalised phase series uma exportação de um contador real ou de um software de análise o mesmo, para esses formatos
Holdover test scored from an operator-supplied time-error record um teste real de holdover: o registo, os momentos em que o operador retirou e restaurou a referência, e os próprios veredictos de MTIE, TDEV e máscara do laboratório a partir do seu software de análise um cálculo independente das mesmas grandezas para comparar com o do motor
IMU log ingest, gyro heading input and Allan fit of hybrid sensor parameters um registo estacionário de uma unidade inercial cujos parâmetros de ruído são publicados ou medidos por outra pessoa o ajuste recuperado dentro de um fator declarado dos parâmetros independentes
Quantum inertial dead-reckoning resilience um registo estático ou os parâmetros de ruído do sensor inercial de átomos frios de um parceiro os valores do dispositivo são do parceiro (PARTNER); o orçamento de erro de posição que os compõe permanece um modelo do Kshana

Comece pelas duas primeiras: elas decidem se os pisos de holdover por classe e o estudo de compromisso quântico versus clássico assentam em algum dado medido próprio.

O que enviar#

Um envio são dois ficheiros numa pasta: os dados e uma pequena descrição deles, um ficheiro TOML (kshana.partner-submission/1; um exemplo prático, inventado, é examples/partner-submission/submission.toml).

Dados de relógio. Um dos formatos que o Kshana lê (veja os formatos de registo de relógio): registos TICC da TAPR, fase ou frequência ASCII no estilo TimeLab, RINEX clock, registos ptp4l, phc2sys e ts2phc do linuxptp, registos de seguimento e de estatísticas do chrony. A fase é preferida à frequência; declare as unidades e o intervalo de amostragem. Forneça o registo ininterrupto mais longo que tiver: a estabilidade em tempos de média longos precisa de dias, e um registo com menos de um dia é aceito, mas com aviso.

Dados inerciais. Um CSV de colunas nomeadas (t_s, gx, gy, gz, ax, ay, az, rad/s e m/s^2) ou o layout EuRoC, de um dispositivo estacionário, longo o bastante para o ajuste (pelo menos 2000 amostras; horas é melhor).

A descrição diz, e o verificador confere onde pode:

  • o tipo de organização (um tipo como "um laboratório nacional de temporização", não um nome; um nome é opcional e apenas para crédito);
  • o dispositivo (tipo, classe e um modelo para a classe other);
  • como os dados foram obtidos: com o que foram comparados, o instante inicial (UTC), o ambiente, e se são brutos ou processados (e o que foi feito com eles);
  • o SHA-256 do ficheiro de dados, de modo que o ficheiro pontuado é o ficheiro descrito;
  • as linhas MODELLED às quais é oferecido, pelo texto exato do requisito acima;
  • a licença (um identificador SPDX ou palavras) e como os dados podem ser usados no repositório: public (incluídos, com atribuição), hash-only (apenas o hash e as pontuações são publicados) ou private (a pontuação é partilhada somente com quem enviou);
  • três declarações: é uma medição e não uma simulação, quem envia pode licenciá-la para este uso, e os ficheiros não contêm dados pessoais.

O que não enviar. Qualquer coisa pessoal ou com dados de contacto (o verificador recusa um endereço de e-mail ou número de telefone na descrição), qualquer coisa sob controlo de exportação ou restrita por acordo, e qualquer dado simulado apresentado como medido.

Como um envio é verificado#

  1. Formato e metadados, por si ou por nós, antes de qualquer execução.

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

    Confirma o esquema, os campos obrigatórios, o hash, as regras de licença e atribuição, que as linhas de destino existem e são MODELLED, que os dados são lidos pelo leitor do próprio motor, e indica o que leu (amostras, intervalo, duração, lacunas) e avisa sobre registos curtos. O estado de saída 0 significa completo e legível; 1 lista o que corrigir. Não pontua os dados, não valida uma linha nem promete que serão usados.

  2. Um pré-registo, antes de qualquer execução pontuada. Para cada linha, um documento em xval/<name>/ fixa, e é versionado antes de os dados serem executados: a linha, o SHA-256 do ficheiro de dados, qual parte dos dados é reservada (nada ajustado pode vê-la), a métrica e o limiar. Para cartões de relógio, o modelo existente é a predição reservada usada para os registos do IGS e de recetores: ajustar no primeiro terço do registo, prever o desvio de Allan do restante e exigir que a razão entre previsto e medido esteja dentro de um fator declarado em todo tempo de média ajustado. Um limiar nunca é relaxado após uma execução.

  3. Uma execução pontuada. O resultado, com todos os números e todas as falhas, é publicado com o comando e o commit, e um teste fixa-o. Uma falha é uma constatação, não um fracasso a esconder: a linha permanece MODELLED e a página di-lo.

  4. A decisão sobre o registo é do responsável, por escrito, no commit que altera a linha. O texto da referência independente de uma linha promovida nomeia o conjunto de dados, a sua licença e crédito, o que foi comparado e o que não foi.

Crédito e direitos#

  • Os dados continuam a ser seus, sob a licença que declarar. hash-only e private mantêm o ficheiro fora do repositório.
  • Um envio public é creditado pela linha de atribuição que fornecer, no texto da referência independente da linha e no ficheiro de resultado.
  • Nada é publicado em seu nome sem o seu consentimento por escrito; uma organização nomeada como fonte é citada como fonte, nunca como quem dá aval. Nenhuma alegação de aprovação ou de aval é feita por um parceiro ou a seu respeito.
  • Pode retirar um envio antes de o seu resultado ser publicado. Depois disso o resultado permanece como registado; se o utilizador retirar a licença dos dados, o ficheiro é removido do repositório e o hash e as pontuações permanecem.
  • O Kshana não transmite nada e não aciona nenhum hardware. Um envio são ficheiros que entram e um relatório que sai.

Divulgação#

Uma nota de uma página para um laboratório está redigida para o responsável em docs/drafts/PARTNER-OUTREACH.md. É um rascunho: nada é enviado e ninguém é contactado até que o responsável decida.