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) ouprivate(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#
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 reportConfirma 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.
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.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.
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-onlyeprivatemantê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.