Bug #105
closed
Traitement de TC avec PACKET_LENGTH erronné
0%
Description
Pour déterminer la longueur de la TC, le LFR FSW utilise le contenu du champ PACKET_LENGTH.
C'est une implémentation justifiable, mais cela induit des informations fausses.
Prennons l'exemple d'unTC nominale (cf 14:20:43.892998).
14:20:43.892998, 254, 2, 0, 0, 28, 204, 196, 172, 0, 5, 16, 181, 63, 110, 225, 206
14:20:43.892998, TC_LFR_DISABLE_CALIBRATION, 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, , SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=1196, PACKET_LENGTH=5, CCSDS_SECONDARY_HEADER_FLAG=0, PUS_VERSION = 1, ACK_EXECUTION_COMPLETION=0, ACK_EXECUTION_PROGRESS=0, ACK_EXECUTION_START=0, ACK_ACCEPTANCE=0, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: DISABLE_CALIBRATION = 63, SOURCE_ID: MISSION_TIMELINE = 110, CRC = 0xe1ce
Un PACKET_LENGTH faux (trop petit) revient à faire un troncature dans la TC; notamment, le crc pris en compte est 110*256+243=0x6ef3.
LEe FSW detecte bien une incohérence sur PA_RPW_PKT_LEN_RCV_VALUE/PA_RPW_PKT_DATFIELDSIZE_CNT, mais oriente sans raison sur un pb de CRC.
14:20:45.588517, 254, 2, 0, 0, 28, 204, 248, 191, 0, 4, 16, 181, 63, 110, 243, 13
14:20:45.588517, TC_LFR_DISABLE_CALIBRATION, 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, SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=14527, /!\PACKET_LENGTH=4((Number of bytes in Packet Data Field)-1=5), CCSDS_SECONDARY_HEADER_FLAG=0, PUS_VERSION = 1, ACK_EXECUTION_COMPLETION=0, ACK_EXECUTION_PROGRESS=0, ACK_EXECUTION_START=0, ACK_ACCEPTANCE=0, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: DISABLE_CALIBRATION = 63, SOURCE_ID: MISSION_TIMELINE = 110, CRC = 0xf30d
14:20:45.600662, TM_LFR_TC_EXE_CORRUPTED, 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, SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=7, PACKET_LENGTH=25, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: TELECOMMAND_VERIFICATION = 1, SERVICE_SUBTYPE: TC_EXECUTION_COMPLETION_FAILURE = 8, DESTINATION_ID: MISSION_TIMELINE = 110, TIME=0x80001bd7df59, PA_RPW_TC_FAILURE_CODE: CORRUPTED = 42005, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xf8bf, PA_RPW_TC_SERVICE=181, PA_RPW_TC_SUBTYPE=63, PA_RPW_PKT_LEN_RCV_VALUE=4, PA_RPW_PKT_DATFIELDSIZE_CNT=5, PA_RPW_RCV_CRC=0x6ef3, PA_RPW_COMPUTED_CRC=0xc936
Je propose que le traitement soit indépendant du contenu de PACKET_LENGTH.
Si PACKET_LENGTH est trop petit, le comportement permet néanmoins de remonter au pb.
En revanche, si PACKET_LENGTH est trop grand, il y a un risque de comportement imprévisible.
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.1.7 r110
Soft: 1.0.0.4 (variante sur carte finale)
Brique Star-Dundee S/N <blank>.
TEST CASE = SVS-0007/loop_tm_lfr_tc_exe_no_ack.py
RPW-SYS-IDB-00067-LES_Issue2_Rev2
RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev2
RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev2
Updated by 
Updated by