LPP » INSTRU » Solar Orbiter LFR » LFR-FSW

Il s'agit de tester la robustesse du FSW LFR lors de déconnection fugitive entre carte et brique.
Les traces obtenues sont:

18:39:41.990076, TM_LFR_HK, HK_LFR_DPU_SPW_PKT_SENT_CNT=4283, HK_LFR_MODE: SBM1 = 3
18:39:42.336518, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:42.339775, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:42.342895, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:42.345961, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:42.349016, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:42.352075, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:42.355105, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:42.358179, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:42.99308, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:42.996336, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:42.999407, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:43.002479, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:43.005525, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:43.008567, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:43.011604, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:43.014636, TM_LFR_SCIENCE_SBM1_CWF_F1, TIME=0x8000082eb855
18:39:43.01665, TM_LFR_HK, TIME=0x8000082ec02a, HK_LFR_DPU_SPW_PKT_SENT_CNT=4299; exp=4300, HK_LFR_MODE: SBM1 = 3 => HK périmé à la reception
18:39:43.648965, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:43.652146, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:43.655165, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:43.658246, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:43.661389, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:43.664402, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:43.667363, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:43.670313, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:43.989433, TM_LFR_HK, HK_LFR_DPU_SPW_PKT_SENT_CNT=4309, HK_LFR_MODE: SBM1 = 3 => Retablissement

Préalablement, on utilise le champ TIME pour reconstituer la chronologie du déroulement des générations de paquets: TM_LFR_HK daté de 18:39:43.01665 est bien postérieur à TM_LFR_SCIENCE_SBM1_CWF_F1 de 18:39:43.014636.

Le pb porte sur HK_LFR_DPU_SPW_PKT_SENT_CNT des TM_LFR_HK.
Les traces montrent que le pb apparait lors qu'il y a coïncidence entre emission de HK et de données SCIENCE:
-l'affectation HK_LFR_DPU_SPW_PKT_SENT_CNT est inférieur à la valeur attendue sur une TM_LFR_HK (cf 18:39:43.01665). La valeur du champ a ainsi été correcte, mais elle est périmée en recoupant avec le champ TIME des TM reçues
-Pour la TM_LFR_HK (de 18:39:43.989433)suivant le défaut , HK_LFR_DPU_SPW_PKT_SENT_CNT est cohérent à la TM_LFR_HK (de 18:39:41.990076) précédant le pb.

nb: pour info, l'écart entre HK_LFR_DPU_SPW_PKT_SENT_CNT attendu et obtenu peut atteindre 7.

A priori, il y aurait deux solutions distinctes:
-Soit, LFR constitue intégralement le TM_LFR_HK pour refléter l'état à un unique instant (stockage de tous les paramètres instantanés puis construction du HK). Quelleque soit ensuite la hierachie des priorités, la date sera cohérente avec les données, même si les données sont dépassées.
-Soit on estime que tous les TM_LFR on le même niveau de priorité. On aura l'état du LFR en live.

Pour info, HK_LFR_DPU_SPW_PKT_SENT_CNT a aussi un pb plus sérieux, tracé par l'issue "TM_LFR_HK: sauts de HK_LFR_DPU_SPW_PKT_SENT_CNT".

Contexte:

LPPMON Version=0.2.2 Branch=default Changeset=835955994d5f
Carte mini-LFR:LFR-172200 dev V1.0; No série III (sans connecteurs sub-click)
Vhdl: mini-lfr_0.0.15
Soft: 1.0.0.1 (variante sur carte finale)
Brique Star-Dundee S/N 46120065.

TEST CASE = SVS_0061

RPW-SYS-IDB-00067-LES_Issue1_Rev8
RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0
RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev1