Bug #79
closed
TM_LFR_HK: mise à jour de HK_LFR_EXE_TC_[CNT|ID|TYPE|SUBTYPE|TIME] après reception de TC_LFR_UPDATE_[TIME|INFO].
0%
Description
Cette issue fait suite au l'issue Bug #708 (TM_LFR_HK: mise à jour de HK_LFR_[EXE|REJ]_TC_[CNT|ID|TYPE|SUBTYPE|TIME] après reception de TC_LFR_UPDATE_[TIME|INFO]) sous pc-instru.
Le pb est partiellement corrigé:
Un TC_LFR_UPDATE_INFO nominal semble entrainer une mise à jour de HK_LFR_EXE_TC_CNT, HK_LFR_LAST_EXE_TC_SUBTYPE, et HK_LFR_LAST_EXE_TC_TIME (le pb pourrait concerner aussi HK_LFR_LAST_EXE_TC_ID, et HK_LFR_LAST_EXE_TC_TYPE car les traces ne sont pas probantes pour ces champs).
Un TC_LFR_UPDATE_INFO corrompu ne semble pas affecter les champs HK_LFR_REJ_TC_[CNT|ID|TYPE|SUBTYPE|TIME].
Un TC_LFR_UPDATE_TIME nominal entraine une mise à jour de HK_LFR_EXE_TC_CNT, HK_LFR_LAST_EXE_TC_SUBTYPE, HK_LFR_LAST_EXE_TC_TYPE, et HK_LFR_LAST_EXE_TC_TIME (le pb pourrait concerner aussi HK_LFR_LAST_EXE_TC_ID car les traces ne sont pas probantes pour ce champ).
Un TC_LFR_UPDATE_TIME corrompu ne semble pas affecter les champs HK_LFR_REJ_TC_[CNT|ID|TYPE|SUBTYPE|TIME].
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
Files
Updated by paul leroy over 10 years ago
- Status changed from New to Resolved
Le bug ne devrait pas se produire avec fsw >= 1.0.0.3.
Updated by paul leroy over 10 years ago
- Assignee changed from paul leroy to bruno katra
Updated by Veronique bouzid over 10 years ago
- Status changed from Resolved to Closed
- Assignee changed from bruno katra to Veronique bouzid
Test (SVS-0003, script loop_tm_lfr_tc_exe.py)
Au vu des SSS suivantes SSS-CP-FS-065 SSS-CP-FS-080 SSS-CP-FS-090 nSS-CP-EQS-140 ne sont pas applicables a UPDATE_TIME et UPDATE_INFO
- TC_LFR_UPDATE_TIME et TC_LFR_UPDATE_INFO ne générent pas de TM_LFR_TC_EXE_xxxx
Dans la SSS-CP-EQS-140,
TC_LFR_UPDATE_TIME et TC_LFR_UPDATE_INFO ne mettent pas à jour dans les TM_LFR_HK, les parametres HK_LFR_EXE_TC_CNT à HK_LFR_LAST_REJ_TC_TIME
Voici une trace qui illustre ceci
Envoi de TC_LFR_UPDATE_TIME et TC_LFR_UPDATE_INFO avec mauvais CRC
13:26:28.291376, TM_LFR_HK,TIME=0x8000000a2ab4,*HK_LFR_UPDATE_TIME_TC_CNT=1,HK_LFR_EXE_TC_CNT=6, HK_LFR_REJ_TC_CNT=13, HK_LFR_LAST_EXE_TC_ID=0x1ccc, HK_LFR_LAST_EXE_TC_TYPE=181, HK_LFR_LAST_EXE_TC_SUBTYPE=31, HK_LFR_LAST_EXE_TC_TIME=0x80000005088e, HK_LFR_LAST_REJ_TC_ID=0x1ccc, HK_LFR_LAST_REJ_TC_TYPE=181, HK_LFR_LAST_REJ_TC_SUBTYPE=63, HK_LFR_LAST_REJ_TC_TIME=0x800000060bec*
13:26:28.749226, TC_LFR_UPDATE_TIME, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TC_PACKET = 1, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0x1ccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=13896, (PACKET_SEQUENCE_CONTROL=0xf648), PACKET_LENGTH=11, CCSDS_SECONDARY_HEADER_FLAG=0, PUS_VERSION = 1, ACK_EXECUTION_COMPLETION=1, ACK_EXECUTION_PROGRESS=0, ACK_EXECUTION_START=0, ACK_ACCEPTANCE=1, SERVICE_TYPE: TIME_MANAGEMENT = 9, SERVICE_SUBTYPE: UPDATE_TIME = 129, SOURCE_ID: MISSION_TIMELINE = 110, CP_RPW_TIME=0x000000010000, /!\CRC = 0xc26e(exp=0xc26f)
13:26:29.291372, TM_LFR_HK,TIME=0x8000000b2ab4,*HK_LFR_UPDATE_TIME_TC_CNT=1, HK_LFR_EXE_TC_CNT=6, HK_LFR_REJ_TC_CNT=13, HK_LFR_LAST_EXE_TC_ID=0x1ccc, HK_LFR_LAST_EXE_TC_TYPE=181, HK_LFR_LAST_EXE_TC_SUBTYPE=31, HK_LFR_LAST_EXE_TC_TIME=0x80000005088e, HK_LFR_LAST_REJ_TC_ID=0x1ccc, HK_LFR_LAST_REJ_TC_TYPE=181, HK_LFR_LAST_REJ_TC_SUBTYPE=63, HK_LFR_LAST_REJ_TC_TIME=0x800000060bec*
On voit bien qu'aucun des parametres n'a été mis à jour ainsi que HK_LFR_UPDATE_TIME_TC_CNT=1.POur ce parametre, le requiremebt SSS-CP-EQS-142
précise que le compteur ne doit etre incrémenté que si le packet est correct et accepté. Comme aucune reponse n'est générée , on va se baser sur l'etat des HK.
Même comportement pour TC_HK_LFR_UPDATE_INFO
13:26:37.291467, TM_LFR_HK,TIME=0x800000132ab9,*HK_LFR_UPDATE_INFO_TC_CNT=1, HK_LFR_UPDATE_TIME_TC_CNT=1, HK_LFR_EXE_TC_CNT=6, HK_LFR_REJ_TC_CNT=13, HK_LFR_LAST_EXE_TC_ID=0x1ccc, HK_LFR_LAST_EXE_TC_TYPE=181, HK_LFR_LAST_EXE_TC_SUBTYPE=31, HK_LFR_LAST_EXE_TC_TIME=0x80000005088e, HK_LFR_LAST_REJ_TC_ID=0x1ccc, HK_LFR_LAST_REJ_TC_TYPE=181, HK_LFR_LAST_REJ_TC_SUBTYPE=63, HK_LFR_LAST_REJ_TC_TIME=0x800000060bec*
13:26:37.550561, TC_LFR_UPDATE_INFO, /!\CRC = 0x52ea(exp=0x52eb)
13:26:38.291354, TM_LFR_HK,TIME=0x800000142ab9, HK_LFR_UPDATE_INFO_TC_CNT=1, HK_LFR_UPDATE_TIME_TC_CNT=1, HK_LFR_EXE_TC_CNT=6, HK_LFR_REJ_TC_CNT=13, HK_LFR_LAST_EXE_TC_ID=0x1ccc, HK_LFR_LAST_EXE_TC_TYPE=181, HK_LFR_LAST_EXE_TC_SUBTYPE=31, HK_LFR_LAST_EXE_TC_TIME=0x80000005088e, HK_LFR_LAST_REJ_TC_ID=0x1ccc, HK_LFR_LAST_REJ_TC_TYPE=181, HK_LFR_LAST_REJ_TC_SUBTYPE=63, HK_LFR_LAST_REJ_TC_TIME=0x800000060bec
Dans ce test, on envoie 10 cdes TC_TC_HK_LFR_UPDATE_TIME dont 5 avec mauvais CRC, et 0 cdes TC_TC_HK_LFR_UPDATE_INFO dont 5 avec mauvais CRC
voici l'etat de la derniere HK recue
13:28:16.291814, TM_LFR_HK, HK_LFR_UPDATE_INFO_TC_CNT=5, HK_LFR_UPDATE_TIME_TC_CNT=5
-----------------------------------------------------------------------
Contexte:
SocExplorerEngine.getSocExplorer: Version = 0.2.2, Branch = default, Changeset = c839740ef520
Carte EM
Vhdl: EM_1.1.23
Brique Star-Dundee S/N <illisible>.
Soft:1.0.0.12 (variante sur carte finale)
TEST CASE = SVS-0003