Bug #61
closed
Traitement des PID, CAT, TYPE, et SUB-TYPE pour identifier les TM.
0%
Description
Cette issue reprend l'issue Bug#585 ('Pas de Verification packet "TM_LFR_TC_EXE_CORRUPTED" sur SUB-TYPE erroné') de pc-instru.
Pour chaque TC, si l'on change les PID, CAT, TYPE, et SUB-TYPE en restant dans les valeurs possibles, on n'obtient pas un TM_LFR_TC_EXE_CORRUPTED.
Exemple avec TC_LFR_DUMP_PAR (PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: DUMP_PARAMETERS = 31)
14:27:28.912202, /!\[254, 2, 0, 0, 28, 204, 192, 0, 0, 5, 16, 9, 31, 110, 244, 191](tc unknown) PID=76 CAT=12 TYPE=9 SUB-TYPE=31 Length(ccsds)=12
14:27:28.91512, TM_LFR_PARAMETER_DUMP
14:27:28.915266, TM_LFR_TC_EXE_SUCCESS
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.0.15
LFR FSW: 1.0.0.1 (variante sur carte finale)
Brique Star-Dundee S/N 46120065.
TEST CASE = SVS_0001
RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0
RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev1
Updated by Gerald Saule almost 11 years ago
L'injection volontaire de champ erroné provoque un retour incohérent dans le cas ci-dessous:
14:27:46.594733, [254, 2, 0, 0, 28, 204, 192, 0, 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, 45, 166](tc unknown) PID=76 CAT=12 /!\TYPE=9 SUB-TYPE=51 Length(ccsds)=46
14:27:46.597075, TM_LFR_TC_EXE_SUCCESS
(Pour un TC_LFR_UPDATE_INFO nominal, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: UPDATE_INFO = 51).
La question est de savoir à quoi correspond le TM_LFR_TC_EXE_SUCCESS.
Si le LFR FSW assimile ses valeur reçues comme un TC_LFR_UPDATE_TIME (PID=76 CAT=12 TYPE=9 SUB-TYPE=129); c-à-d que SUB-TYPE n'est pas pris en compte:
-on confirme l'hypothèse d'un pb de traitement sur une combainaison interdite de valeurs autorisées individuellement pour chaque champ.
-on ne s'explique pas la présence d'un acquittement; TC_LFR_UPDATE_TIME étant non acquitté.
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.0.15
LFR FSW: 1.0.0.1 (variante sur carte finale)
Brique Star-Dundee S/N 46120065.
TEST CASE = SVS_0007
RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0
RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev1
Updated by Gerald Saule almost 11 years ago
En compément de #note-1: en dégradant un TC_LFR_UPDATE_TIME (nominalement: PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, SERVICE_TYPE: TIME_MANAGEMENT = 9, SERVICE_SUBTYPE: UPDATE_TIME = 129), on obtient un TM_LFR_TC_EXE_SUCCESS dont l'origine est inconnue.
14:27:54.614184, /!\[254, 2, 0, 0, 28, 204, 192, 0, 0, 11, 16, 181, 129, 110, 0, 0, 0, 1, 0, 0, 24, 20](tc unknown) PID=76 CAT=12 TYPE=181 SUB-TYPE=129 Length(ccsds)=18
14:27:54.61676, TM_LFR_TC_EXE_SUCCESS, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: ACKNOWLEDGE = 1, (PACKET_ID=0xcc1), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=1853, (PACKET_SEQUENCE_CONTROL=0xc73d), PACKET_LENGTH=13, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: TELECOMMAND_VERIFICATION = 1, SERVICE_SUBTYPE: TC_EXECUTION_COMPLETION_SUCCESS = 7, DESTINATION_ID: MISSION_TIMELINE = 110, TIME=0x50313, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xc000.
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.0.15
LFR FSW: 1.0.0.1 (variante sur carte finale)
Brique Star-Dundee S/N 46120065.
TEST CASE = SVS_0007
RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0
RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev1
Updated by paul leroy almost 11 years ago
- Status changed from New to Resolved
fsw >= 1.0.0.2
le bug est identifié et corrigé. Le subtype est maintenant analysé en fonction du type.
Updated by Gerald Saule almost 11 years ago
- Status changed from Resolved to Closed
- revision changed from r98 to r104
=>Cette issue peut être fermée. Il reste un point résiduel tracé par Bug #78 (Pb de TM_LFR_TC_EXE_CORRUPTED sur TC_LFR_UPDATE_INFO/TC_LFR_UPDATE_TIME corrompus)
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