Project

General

Profile

Bug #78

Pb de TM_LFR_TC_EXE_CORRUPTED sur TC_LFR_UPDATE_INFO/TC_LFR_UPDATE_TIME corrompus

Added by Gerald Saule over 7 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
06/03/2014
Due date:
% Done:

0%

Estimated time:
revision:
r104

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_CORRUPTED

16: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_CORRUPTED

TC_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_CORRUPTED

16: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

2014_03_06-16_21_04-lfr_update.txt (56.3 KB) 2014_03_06-16_21_04-lfr_update.txt Gerald Saule, 06/03/2014 05:02 PM

History

#1 Updated by paul leroy over 7 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.

#2 Updated by paul leroy over 7 years ago

  • Assignee changed from paul leroy to bruno katra

#3 Updated by Veronique bouzid over 7 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.

Also available in: Atom PDF