Datos de socios: qué datos medidos podrían promover una fila MODELLED
Kshana etiqueta cada capacidad en un registro verificado por máquina (matriz de verificación). La mayoría de las filas de temporización y de sensores son MODELLED: se apoyan en modelos indicados, hojas de datos publicadas y comprobaciones internas, y ningún registro medido de la clase de dispositivo se ha comparado con ellas. Quien tenga un registro así puede cambiarlo. Esta página dice qué filas, qué enviar, cómo se comprueba un envío, cómo se puntúa y cómo se acredita. Está escrita para un laboratorio, un fabricante o un grupo universitario; no es una oferta de trabajo y no afirma el respaldo de nadie. Solo consultivo: Kshana es un instrumento de estudio, no un equipo de navegación o de temporización homologado.
Qué significan las etiquetas#
| Etiqueta | Significado |
|---|---|
| VALIDATED | una referencia independiente externa coincide con la capacidad bajo un umbral fijado antes de la comparación. Un registro medido de un socio puede ser esa referencia independiente para la subafirmación que cubre; los invariantes de la matriz prohíben la etiqueta sin una |
| MODELLED | internamente consistente, y dicho en voz alta; ninguna referencia independiente externa cubre la afirmación. Una fila MODELLED que se compara con datos medidos y no alcanza el umbral sigue siendo MODELLED, y el fallo se publica |
| PARTNER | una disciplina en la que se apoya la ejecución, de la que es propietario un socio de hardware y que Kshana no proporciona, por ejemplo las cifras que describen el reloj o el interferómetro propios de un socio. Kshana modela lo que un dispositivo así haría a una cadena de navegación o de temporización; no responde por el dispositivo |
Un envío puede mover una fila a VALIDATED solo para la afirmación que los datos realmente prueban, y solo si la comparación alcanza su umbral. No puede hacer que las cifras propias de un dispositivo sean de Kshana para responder de ellas: siguen siendo del socio (PARTNER). Que cambie o no la etiqueta de una fila es decisión del propietario, registrada en la confirmación que la cambia, con el texto de la referencia independiente indicando exactamente qué se comparó con qué.
Filas que los datos de un socio podrían promover#
Cada fila de abajo es el texto exacto de requirement de una fila MODELLED de la matriz (una prueba mantiene esta página y la matriz sincronizadas). «Podría cambiar» dice qué respaldaría una comparación preregistrada con datos medidos si se alcanza el umbral; nunca es una promesa.
| Fila | Datos que la probarían | Podría cambiar |
|---|---|---|
GNSS-denied clock holdover |
un registro de días de un reloj de una clase indicada, en funcionamiento libre tras su última disciplina, comparado con una referencia mejor, a un intervalo de muestreo de un minuto o menos | los pisos de ruido rojo por clase que acotan las cifras de holdover siguen siendo MODELLED hoy; una estabilidad medida a tiempos de promediado largos podría compararse con el piso de esa clase, solo para esa clase |
Quantum-vs-classical PNT trade & GNSS-denied resilience (13503) |
la desviación de Allan medida, como tabla o como registro de fase, del reloj o del interferómetro atómico de un socio | las cifras de compromiso cuantifican (nunca validan) el dispositivo del socio, por lo que se etiquetarían como cifras del socio (PARTNER); la ingesta de datos de Allan medidos en un modelo de ruido ya coincide con un solucionador independiente |
Oscillator holdover presets from public datasheets |
un registro de fase de un oscilador de uno de los cuatro modelos preconfigurados, durante al menos un día | si el modelo de ruido derivado de la hoja de datos del preajuste reproduce la estabilidad de una unidad medida en los propios tiempos de promediado de la hoja de datos |
Measured clock device cards (held-out prediction) |
un registro de fase de una clase de reloj que aún no tiene ficha (un OCXO, un rubidio, un cesio, un máser, un reloj óptico) | una ficha ajustada con el primer tercio y que predice la desviación de Allan del resto dentro del factor preregistrado, como ya se hizo con los relojes de satélites GNSS y un receptor |
Clock-log formats linuxptp (ptp4l, phc2sys, ts2phc) and chrony (tracking, statistics) read to a normalised phase series |
un registro de una instalación real (cualquier versión del daemon) con las propias líneas de resumen del daemon | los lectores se construyeron a partir de formatos de línea públicos y archivos de prueba; un registro real comparado con un lector independiente sería la primera comprobación externa |
Clock-log formats (RINEX clock, TimeLab ASCII, TAPR TICC) read to a normalised phase series |
una exportación de un contador o de un software de análisis reales | lo mismo, para esos formatos |
Holdover test scored from an operator-supplied time-error record |
una prueba de holdover real: el registro, los momentos en que el operador retiró y restableció la referencia, y los propios veredictos de MTIE, TDEV y máscara del laboratorio a partir de su software de análisis | un cálculo independiente de las mismas magnitudes para comparar con el del motor |
IMU log ingest, gyro heading input and Allan fit of hybrid sensor parameters |
un registro estacionario de una unidad inercial cuyos parámetros de ruido publica o mide otra persona | el ajuste recupera los parámetros independientes dentro de un factor indicado |
Quantum inertial dead-reckoning resilience |
un registro estático o los parámetros de ruido del sensor inercial de átomos fríos de un socio | las cifras del dispositivo son del socio (PARTNER); el presupuesto de error de posición que las compone sigue siendo un modelo de Kshana |
Empiece por los dos primeros: deciden si los pisos de holdover por clase y el compromiso entre cuántico y clásico se apoyan en algún dato medido propio.
Qué enviar#
Un envío son dos archivos en una carpeta: los datos y una breve descripción de ellos, un archivo TOML (kshana.partner-submission/1; un ejemplo práctico inventado es examples/partner-submission/submission.toml).
Datos de reloj. Uno de los formatos que lee Kshana (véanse los formatos de registros de reloj): registros TICC de TAPR, fase o frecuencia ASCII al estilo TimeLab, RINEX clock, registros de linuxptp ptp4l, phc2sys y ts2phc, registros de seguimiento y de estadísticas de chrony. Se prefiere la fase a la frecuencia; indique las unidades y el intervalo de muestreo. Aporte el registro ininterrumpido más largo que tenga: la estabilidad a tiempos de promediado largos necesita días, y un registro de menos de un día se acepta pero con una advertencia.
Datos inerciales. Un CSV con columnas con nombre (t_s, gx, gy, gz, ax, ay, az, rad/s y m/s^2) o el formato EuRoC, de un dispositivo estacionario, lo bastante largo para el ajuste (al menos 2000 muestras; mejor con horas).
La descripción indica lo siguiente, y el verificador lo comprueba donde puede:
- el tipo de organización (un tipo como «un laboratorio nacional de temporización», no un nombre; el nombre es opcional y solo para el crédito);
- el dispositivo (tipo, clase y un modelo para la clase
other); - cómo se tomaron los datos: con qué se compararon, la hora de inicio (UTC), el entorno, y si son brutos o procesados (y qué se les hizo);
- el SHA-256 del archivo de datos, para que el archivo puntuado sea el archivo descrito;
- las filas MODELLED frente a las que se ofrece, mediante el texto exacto del requisito de arriba;
- la licencia (un identificador SPDX o palabras) y cómo pueden usarse los datos en el repositorio:
public(confirmados, con atribución),hash-only(solo se publican su hash y las puntuaciones) oprivate(la puntuación se comparte solo con quien envía); - tres declaraciones: es una medición y no una simulación, quien lo envía puede licenciarlo para este uso, y los archivos no contienen datos personales.
Qué no enviar. Nada personal ni con datos de contacto (el verificador rechaza una dirección de correo electrónico o un número de teléfono en la descripción), nada sujeto a control de exportación o restringido por acuerdo, ni ningún dato simulado presentado como medido.
Cómo se comprueba un envío#
Formato y metadatos, por usted o por nosotros, antes de que se ejecute nada.
kshana partner check <submission.toml> # add --json for a machine-readable reportConfirma el esquema, los campos obligatorios, el hash, las reglas de licencia y atribución, que las filas objetivo existen y son MODELLED, que los datos se leen con el lector propio del motor, e informa de lo que leyó (muestras, intervalo, duración, huecos) y advierte de los registros cortos. El estado de salida 0 significa completo y legible; 1 enumera lo que hay que corregir. No puntúa los datos, no valida una fila ni promete que se vayan a usar.
Un preregistro, antes de cualquier ejecución puntuada. Para cada fila, un documento en
xval/<name>/fija, y se confirma antes de ejecutar los datos: la fila, el SHA-256 del archivo de datos, qué parte de los datos se reserva (nada de lo ajustado puede verla), la métrica y el umbral. Para las fichas de reloj, la plantilla existente es la predicción con datos reservados usada para los registros de IGS y de receptores: ajustar con el primer tercio del registro, predecir la desviación de Allan del resto y exigir que la razón entre lo predicho y lo medido esté dentro de un factor indicado en cada tiempo de promediado ajustado. Un umbral nunca se relaja después de una ejecución.Una ejecución puntuada. El resultado, con todos los números y todos los fallos incluidos, se publica con el comando y la confirmación, y una prueba lo fija. Un fallo es un hallazgo, no un fracaso que ocultar: la fila sigue siendo MODELLED y la página lo dice.
La decisión sobre el registro es del propietario, por escrito, en la confirmación que cambia la fila. El texto de la referencia independiente de una fila promovida nombra el conjunto de datos, su licencia y su crédito, qué se comparó y qué no.
Créditos y derechos#
- Los datos siguen siendo suyos bajo la licencia que indique.
hash-onlyyprivatemantienen el archivo fuera del repositorio. - Un envío
publicse acredita con la línea de atribución que usted dé, en el texto de la referencia independiente de la fila y en el archivo de resultados. - No se publica nada con su nombre sin su consentimiento por escrito; una organización nombrada como fuente se cita como fuente, nunca como avalista. Ni un socio ni nadie en su nombre hace ninguna afirmación de aprobación o respaldo, ni se hace ninguna sobre un socio.
- Puede retirar un envío antes de que se publique su resultado. Después, el resultado permanece tal como se registró; si retira la licencia de los datos, el archivo se elimina del repositorio y el hash y las puntuaciones permanecen.
- Kshana no transmite nada y no controla ningún hardware. Un envío son archivos de entrada y un informe de salida.
Contacto con socios#
Se ha redactado para el propietario una nota de una página para un laboratorio en docs/drafts/PARTNER-OUTREACH.md. Es un borrador: no se envía nada y no se contacta con nadie hasta que el propietario lo decida.