aperture-duty-cycle (tipo de escenario)

Tipo de escenario del motor v0.40.0, familia Análisis de misión, enlaces y operaciones espaciales. Consultivo: salida de análisis de una herramienta de investigación e ingeniería, no un equipo de navegación homologado ni un servicio de seguridad de la vida humana. Toda etiqueta de aquí es la del motor o la de la matriz de verificación; un tipo de escenario es MODELLED salvo que la matriz diga otra cosa (cómo se gana una etiqueta: la sección Evidence del README).

Qué hace#

Ciclo de trabajo de apertura: el reparto de tiempo entre navegación y comunicaciones que implica un plan de contactos para un conjunto de aperturas orientables. Toma un plan de contactos (una lista de ventanas aos_s/los_s de [[contacts]], cada una de las cuales solicita navegación o comunicaciones — el mismo vocabulario aos_s/los_s que emite el predictor passes), un número de aperturas y una POLÍTICA DE ARBITRAJE (prioridad de navegación por defecto, o prioridad de comunicaciones, o el primero en llegar sin apropiación), e informa del ciclo de trabajo de navegación, del de comunicaciones, del de inactividad y de la interrupción por sesión — el tiempo de contacto que una sesión solicitó y ninguna apertura atendió. Un barrido exacto de intervalos sobre los límites de las ventanas, de modo que las ventanas contiguas nunca compiten y ningún segundo de apertura se cuenta dos veces; los segundos de apertura de navegación, de comunicaciones y de inactividad se acumulan por separado y cierran frente a apertures*horizon_s. El informe indica la política resuelta, su definición completa y las definiciones de ciclo de trabajo y de interrupción, porque una cifra de ciclo de trabajo citada sin su política de arbitraje no es reproducible. Aritmética de planificación MODELLED: no se cobra ningún tiempo de giro, resintonización o cambio cuando una apertura cambia de servicio o de sesión, no interviene en la decisión ningún volumen de datos, estado de búfer, balance de energía ni cierre de enlace, y las ventanas de contacto son entradas — su geometría es la que las produjo. No es un producto de planificación de segmento terreno.

Una ejecución de scenarios/aperture-duty-cycle.toml se resume así: aperture-duty-cycle: 6 session(s) on 2 aperture(s) under navigation-priority -> navigation duty 0,1167, communications duty 0,2667, idle 0,6167; 0 s of 6900 s requested lost to contention (MODELLED)

Entradas#

Del esquema (kshana kinds --json):

• Campos obligatorios: ninguno
• Campos opcionales: apertures, arbitration, horizon_start_s, horizon_end_s, contacts

El ejemplo scenarios/aperture-duty-cycle.toml establece, entre otros:

Ejecútelo#

kshana scenarios/aperture-duty-cycle.toml

Qué proporciona#

Los resultados escalares de esa ejecución, con las unidades que indica el motor:

Etiqueta del resultado (la del motor): MODELLED — aritmética de planificación de aperturas sobre un plan de contactos suministrado: un barrido exacto de intervalos del reparto de tiempo entre navegación y comunicaciones y de la pérdida por contención por sesión bajo una política de arbitraje con nombre. No se cobra ningún tiempo de giro, resintonización o cambio cuando una apertura cambia de servicio o de sesión,

Evidencias#

MODELLED: las filas de la matriz de verificación que nombran este tipo de escenario.

• MODELLED Una ejecución toma un plan de contactos (una lista de ventanas aos_s/los_s, cada una de las cuales solicita a la apertura navegación o comunicaciones — el mismo vocabulario de ventanas que emite passes::predict_passes, convertido por aperture_duty::windows_from_passes), una apert

Las filas que la propia ejecución puso a prueba, con la referencia independiente que da la matriz a cada una (las fuentes públicas se nombran allí):

• MODELLED Determinista, con hash de escenario, SBOM + barreras golden multiplataforma. Referencia independiente (ExternalDataset): ajuste a la norma del SBOM al esquema JSON oficial de CycloneDX 1,5 (+ identificadores SPDX válidos) — un estándar externo publicado, cero errores de validación en todo el grafo de dependencias; la parte de determinismo de FoM / reproducibilidad byte a byte sigue siendo una comprobación de autoconsistencia fijada, por lo que la fila sigue siendo MODELLED
• MODELLED Una ejecución toma un plan de contactos (una lista de ventanas aos_s/los_s, cada una de las cuales solicita a la apertura navegación o comunicaciones — el mismo vocabulario de ventanas que `passes::pre. Referencia independiente (InternalConsistency): Autoconsistencia interna, a partir de tres magnitudes calculadas con expresiones distintas en el mismo barrido y que luego deben cerrar. Los segundos de apertura de navegación, de comunicaciones y de inactividad se acumulan por separado — la inactividad a partir de (aperturas − |atendidas|) por intervalo elemental, nunca como un resto — y su suma se comprueba frente a aperturas × horizon_s, lo que un límite mal acotado, un doble c

Limitaciones#

Lo que el propio informe de la ejecución dice que no está modelado o no está validado:

• MODELLED — aritmética de planificación de aperturas sobre un plan de contactos suministrado: un barrido exacto de intervalos del reparto de tiempo entre navegación y comunicaciones y de la pérdida por contención por sesión bajo una política de arbitraje con nombre. No se cobra ningún tiempo de giro, resintonización o cambio cuando una apertura cambia de servicio o de sesión, no interviene en la decisión ningún volumen de datos, estado de búfer, balance de energía ni cierre de enlace, y las ventanas de contacto son entradas — su (resultado label)
• Aritmética de planificación MODELLED: no se cobra ningún tiempo de giro, resintonización o cambio cuando una apertura cambia de servicio o de sesión, no interviene en la decisión ningún volumen de datos, estado de búfer, balance de energía ni cierre de enlace, y las ventanas de contacto son entradas — su geometría es la que las produjo. (catálogo de tipos de escenario (kshana kinds --json))
• ALCANCE HONESTO: aritmética de planificación MODELLED sobre las ventanas suministradas. No se cobra ningún tiempo de giro, resintonización o cambio cuando una apertura cambia de servicio o de sesión; no interviene en la decisión ningún volumen de datos, estado de búfer, balance de energía ni cierre de enlace; y las ventanas de contacto son entradas -- su geometría es la que las produjo (el escenario passes emite el mismo vocabulario aos_s / los_s). No es una planificación de segmento terreno (comentario del archivo de escenario, líneas 18 a 24)
• La reproducibilidad y el aseguramiento del software son MODELLED, no están validados: una subafirmación se comprueba externamente, pero la capacidad completa compone piezas modeladas, por lo que la capacidad sigue siendo modelada. (matriz de verificación (docs/MODELLED-RATIONALE.md))
• El ciclo de trabajo de apertura entre navegación y comunicaciones es MODELLED, no está validado: se comprueba frente a su propia identidad analítica o de forma cerrada — detecta errores de transcripción y de coeficientes, pero no es una referencia independiente externa. (matriz de verificación (docs/MODELLED-RATIONALE.md))

Véase también#

• Página de familia: Análisis de misión, enlaces y operaciones espaciales
• Todos los tipos de escenario: KINDS.md