campaign (type de scénario)

Type de scénario du moteur v0.40.0, famille Campagnes. À titre consultatif : résultat d'analyse d'un outil de recherche et d'ingénierie, et non un équipement de navigation homologué ni un service de sauvegarde de la vie humaine. Chaque étiquette ici est celle du moteur ou de la matrice de vérification ; un type de scénario est MODELLED sauf si la matrice dit le contraire (comment une étiquette s'acquiert : la section Evidence du README).

Ce qu'il fait#

Campagne : des types de scénario existants composés en une seule exécution, chaque nombre étant lu dans une véritable exécution du type de scénario nommé. Quatre sections, en toute combinaison. PHASES : une mission enchaînée sur une chronologie partagée -- chaque phase exécute un ou plusieurs scénarios (par exemple brouillage, puis leurrage, puis une horloge en holdover avec un système de navigation inertielle en roue libre à ses côtés, puis une alarme d'intégrité, puis la récupération), leurs sorties sont lues dans des canaux nommés (erreur de temps d'horloge par rapport à sa garde, rapport porteuse sur densité de bruit par rapport au plancher de poursuite, niveau de protection par rapport à la limite d'alerte, erreur de position, satellites en poursuite, indicateurs d'alarme) par un préréglage propre au type de scénario ou par des chemins de résultat explicites, et rééchantillonnées sur une grille commune par maintien d'ordre zéro, avec les limites de phase et les événements ; l'état est transmis par carry (un canal se poursuit à partir de la valeur de fin de la phase précédente), handoff (un nombre d'une phase précédente écrit dans le scénario de cette phase) et end_at (une phase se termine à un instant qu'une exécution a calculé, tel que le temps de détection d'un moniteur de leurrage). SWEEP : une grille sur une à trois clés pointées de scénario de n'importe quel type de scénario (un segment entier indexe un tableau de tables, comme dans system.2.sisre_m), avec des métriques lues par chemin de résultat et, avec plus d'une exécution, un ensemble Monte Carlo initialisé à chaque nœud. MONTE_CARLO : la réalisation k s'exécute à base_seed + k ; chaque métrique rapporte la moyenne, l'écart type, les percentiles au rang le plus proche 5e/50e/95e et un intervalle de confiance bootstrap à graine fixe de 95 % sur la moyenne. COMPOSE : plusieurs scénarios sous des valeurs partagées (la puissance et la position d'un brouilleur écrites dans un récepteur maritime et un récepteur routier), avec un résumé combiné meilleur/pire cas. Le résultat porte un hachage de campagne, un condensé sur chaque résultat de membre, et une entrée d'unités pour chaque nombre émis ; les exports d'interopérabilité écrivent chaque scénario membre qui a une géométrie comme son propre jeu de fichiers. Les identités de composition sont testées : une campagne à une seule phase reproduit l'exécution autonome bit pour bit, un ensemble à graine fixe est stable à l'octet près, et sur une horloge à bruit blanc de fréquence la moyenne de l'ensemble tombe à l'intérieur de l'intervalle rapporté avec une dispersion correspondant à sqrt(q_wf * tau). MODELLED : le carry additif et le maintien d'ordre zéro sont des choix de modélisation, et chaque phase porte l'étiquette du type de scénario qui l'a exécutée.

Une exécution de scenarios/campaign-sweep-jammer-power.toml se résume ainsi : campaign 46aa07cb58fb | Jammer power sweep: availability and J/S against transmit power | sweep of jamming: 13 nodes over [jammer_power] | 13 member runs (MODELLED)

Entrées#

D'après le schéma (kshana kinds --json) :

• Champs requis : aucun
• Champs facultatifs : title, seed, timeline, phases, sweep, monte_carlo, compose

L'exemple scenarios/campaign-sweep-jammer-power.toml définit, entre autres :

L'exécuter#

kshana scenarios/campaign-sweep-jammer-power.toml

22 scénarios fournis utilisent ce type de scénario ; les autres se trouvent dans scenarios/.

Ce qu'il donne#

Les résultats scalaires de cette exécution, avec les unités que le moteur indique :

Étiquette du résultat (celle du moteur) : composition MODELLED de types de scénario existants. Chaque nombre est lu dans une véritable exécution du type de scénario nommé ; l'enchaînement (report additif d'un canal à travers une limite de phase, maintien d'ordre zéro sur la grille de la chronologie, phase terminée à un instant calculé) est un choix de modélisation, et chaque phase porte l'étiquet

Preuves#

MODELLED : les lignes de la matrice de vérification qui nomment ce type de scénario.

• MODELLED iq::campaign::detect et l'exécuteur de campagne : une table facultative [monitors] exécute les moniteurs IQ sur chaque cellule en un seul passage de l'exécuteur. Tests : iq_campaign.rs.
• MODELLED iq::campaign::detect (windows, roc) et iq::campaign::report::rocs : chaque cellule d'une campagne avec moniteurs conserve, par type d'alarme et par canal, le maximum de la statistique de test propre au moniteur sur chaque fenêtre d'événement indiquée (positif) et sur t
• MODELLED iq::labfit (campaign, cn0, iqfit, iqreport) et [input] campaign sur kshana iq labfit, Python kshana.iq_labfit et l'outil MCP labfit (dossiers de campagne à l'intérieur de son répertoire de travail uniquement) : lit un dossier de sortie kshana iq campaign par son Tests : iq_labfit_followup.rs.
• MODELLED Les phases du type de scénario campaign : chaque phase exécute un ou plusieurs scénarios de types existants via run_toml, lit leurs sorties dans des canaux nommés (erreur de temps d'horloge et garde, rapport porteuse sur densité de bruit effectif moyen et plancher de poursuite, v Tests : campaign_composition_reference.rs.
• et 4 autres dans la matrice.

Les lignes que l'exécution elle-même a exercées, avec la référence indépendante que la matrice donne pour chacune (les sources publiques y sont nommées) :

• MODELLED Bilan de liaison J/S géométrique, C/N₀ anti-brouillage, perte d'accrochage par satellite. Référence indépendante (InternalConsistency) : Équation du bilan de liaison C/N₀ anti-brouillage vérifiée par rapport à une nouvelle dérivation numpy indépendante (partage la même forme fermée → InternalConsistency) plus une caractérisation de la dégradation du C/N₀ de JammerTest-2024 réel. 0,30 tour 2, bloqué (reste MODELLED) : la baisse de C/N0 mesurée de JammerTest 2024 par rapport à une prédiction de bilan de liaison (préenregistrée 6a66994b, à 3 dB près) n'a pas été exécutée parce que la position et le pointage de l'antenne F8.1 à
• MODELLED Déterministe, hachée par scénario, avec des barrières SBOM + références d'or multiplateformes. Référence indépendante (ExternalDataset) : respect du schéma JSON officiel CycloneDX 1,5 par la SBOM (+ identifiants SPDX valides) — une norme publiée externe, zéro erreur de validation sur tout le graphe de dépendances ; la partie déterminisme du FoM / reproductibilité à l'octet près reste un contrôle d'autocohérence figé, de sorte que la ligne reste MODELLED
• PARTNER Non fourni — Kshana modélise la performance du signal, et non le matériel de charge utile ou d'antenne. Référence indépendante (NoneKind) : aucune : une discipline propre au partenaire, sans module ni test par conception
• MODELLED Le balayage du type de scénario campaign (une à trois clés pointées de n'importe quel type de scénario, sur les valeurs d'axe du balayage générique, avec facultativement un ensemble à chaque nœud) et la sec monte_carlo. Référence indépendante (InternalConsistency) : La forme fermée de la marche aléatoire de phase sous bruit blanc de fréquence, variance q_wf tau (NIST Technical Note 1337), pour la machinerie statistique, et l'égalité à l'octet près avec les exécutions autonomes pour l'initialisation. Elle vérifie l'arithmétique d'ensemble sur le modèle d'horloge propre au moteur, et non un jeu de données externe

Limites#

Ce que le rapport propre à l'exécution dit n'être pas modélisé ou pas validé :

• Composition MODELLED de types de scénario existants. Chaque nombre est lu dans une véritable exécution du type de scénario nommé ; l'enchaînement (report additif d'un canal à travers une limite de phase, maintien d'ordre zéro sur la grille de la chronologie, phase terminée à un instant calculé) est un choix de modélisation, et chaque phase porte l'étiquette du type de scénario qui l'a produite. (résultat label)
• MODELLED : le report additif et le maintien d'ordre zéro sont des choix de modélisation, et chaque phase porte l'étiquette du type de scénario qui l'a exécutée. (catalogue des types de scénario (kshana kinds --json))
• MODELLED : comme l'est le type de scénario jamming. (commentaire du fichier de scénario, ligne 14)
• La résilience au brouillage en l'absence de GNSS est MODELLED, et non validée : vérifiée par rapport à sa propre identité analytique en forme fermée — détecte les erreurs de transcription et de coefficients, mais n'est pas une référence indépendante externe. (matrice de vérification (docs/MODELLED-RATIONALE.md))
• La reproductibilité et l'assurance logicielle sont MODELLED, et non validées : une sous-affirmation est vérifiée de l'extérieur, mais la capacité entière compose des éléments modélisés, de sorte qu'elle reste modélisée. (matrice de vérification (docs/MODELLED-RATIONALE.md))
• Les balayages de paramètres et les ensembles Monte Carlo initialisés sur n'importe quel type de scénario sont MODELLED, et non validés : vérifiés par rapport à leur propre identité analytique en forme fermée — détecte les erreurs de transcription et de coefficients, mais n'est pas une référence indépendante externe. (matrice de vérification (docs/MODELLED-RATIONALE.md))

Voir aussi#

• Page de famille : Campagnes
• Tous les types de scénario : KINDS.md
• Page thématique : LEO-PNT.md
• Page thématique : RESILIENCE-CROSSWALK.md