Project

General

Profile

Bug #79

TM_LFR_HK: mise à jour de HK_LFR_EXE_TC_[CNT|ID|TYPE|SUBTYPE|TIME] après reception de TC_LFR_UPDATE_[TIME|INFO].

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

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

0%

Estimated time:
revision:
r104

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

TC_LFR_UPDATE_x.txt (15.5 KB) TC_LFR_UPDATE_x.txt Gerald Saule, 06/03/2014 06:47 PM

History

#1 Updated by paul leroy over 7 years ago

  • Status changed from New to Resolved

Le bug ne devrait pas se produire avec fsw >= 1.0.0.3.

#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
  • 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

Also available in: Atom PDF