Bug #78
closed
Pb de TM_LFR_TC_EXE_CORRUPTED sur TC_LFR_UPDATE_INFO/TC_LFR_UPDATE_TIME corrompus
0%
Description
Cette issue traite du pb résiduel de l'issue Bug #61 (sous hephaistos).
Il y a en effet un pb de principe sur le traitement des TC corrompues; tantôt, il faut un acquittement explicite en TM_LFR_TC_EXE_CORRUPTED, tantôt il ne faut pas d'acquittement (pour TC_LFR_UPDATE_INFO et TC_LFR_UPDATE_TIME).
Or, à la réception d'octets corrompus, le FSW ne peut déterminer si le rejet doit s'accompagner de TM_LFR_TC_EXE_CORRUPTED, car la corruption des bytes empêche justement de décommuter les données reçues (et donc de déteminer si on a un TC_LFR_UPDATE_INFO ou TC_LFR_UPDATE_TIME).
Un traitement homogène pourrait être proposé au niveau SSS: pour toute TC corrompue, acquitter par un TM_LFR_TC_EXE_CORRUPTED.
On observe parfois une abence d'acquittement nominale sur TC_LFR_UPDATE_INFO/TC_LFR_UPDATE_TIME corrompus.
Mais, actuellement, on a des rejets explicites dans les cas suivants:
TC_LFR_UPDATE_INFO PID=76 CAT=12 TYPE=181 SUB-TYPE=51 Length(ccsds)=46
16:20:26.736804, Tc_unknown/!\[254, 2, 0, 0, 28, 204, 245, 167, 0, 39, 16, 9, 51, 110, 0, 0, 39, 16, 39, 17, 39, 18, 48, 57, 212, 49, 39, 219, 125, 145, 98, 159, 0, 159, 0, 159, 0, 159, 0, 0, 1, 0, 29, 107, 57, 133, 100, 236, 170, 211] PID=76 CAT=12 /!\TYPE=9 SUB-TYPE=51 Length(ccsds)=46
16:20:26.739259, TM_LFR_TC_EXE_CORRUPTED16:20:27.741938, Tc_unknown/!\[254, 2, 0, 0, 28, 204, 250, 14, 0, 39, 16, 181, 8, 110, 0, 0, 39, 16, 39, 17, 39, 18, 48, 57, 212, 49, 39, 219, 125, 145, 98, 159, 0, 159, 0, 159, 0, 159, 0, 0, 1, 0, 29, 107, 57, 133, 100, 236, 221, 76] PID=76 CAT=12 TYPE=181 SUB-TYPE=8 Length(ccsds)=46
16:20:27.744218, TM_LFR_TC_EXE_CORRUPTEDTC_LFR_UPDATE_TIME PID=76 CAT=12 TYPE=9 SUB-TYPE=129 Length(ccsds)=18
16:20:34.751644, Tc_unknown/!\[254, 2, 0, 0, 28, 204, 232, 195, 0, 11, 16, 181, 129, 110, 0, 0, 0, 1, 0, 0, 78, 101] PID=76 CAT=12 TYPE=181 SUB-TYPE=129 Length(ccsds)=18
16:20:34.752947, TM_LFR_TC_EXE_CORRUPTED16:20:35.752501, Tc_unknown/!\[254, 2, 0, 0, 28, 204, 250, 109, 0, 11, 16, 9, 8, 110, 0, 0, 0, 1, 0, 0, 56, 129] PID=76 CAT=12 TYPE=9 SUB-TYPE=8 Length(ccsds)=18
16:20:35.755507, TM_LFR_TC_EXE_CORRUPTED
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_VHDLib206 (Carte mini-LFR)
Soft: 1.0.0.2 (variante sur carte finale) = r104
Brique Brique Star-Dundee S/N 46120065.
RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0
RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev1
Req = SSS-CP-FS-065
TEST CASE = SVS_0007
Files
Updated by paul leroy about 10 years ago
- Status changed from New to Resolved
Voici la façon dont est vérifiée la cohérence des TC:
=> on scrute la TC dans l'ordre en commençant par le premier byte reçu
=> si les types / sous-types sont valides, alors deux cas possibles se présentent:
1) en présence de UPDATE_TIME ou UPDATE_INFO, toute erreur dans la vérification ultérieure de la TC ne produit pas de TM_LFR_TC_EXE_CORRUPTED ni l'incrément des compteurs HK
2) dans les autres cas, une erreur dans la vérification déclenche l'émission de TM_LFR_TC_EXE_CORRUPTED et l'incrément des compteurs HK
Cette stratégie est décrite dans le texte dans la SRS mais pas reprise sous forme d'exigence numérotée.
Updated by paul leroy almost 10 years ago
- Assignee changed from paul leroy to bruno katra
Updated by Veronique bouzid almost 10 years ago
- Status changed from Resolved to Closed
Le document SSS qui décrit ce requirement est SSS-CP-FS-065 précise qu il n'est pas applicable aux paquets
TC_LFR_UPDATE_INFO et TC_LFR_UPDATE_TIME.