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 paul leroy about 10 years ago
- Status changed from New to Resolved
fsw >= 1.0.0.5
Le traitement est maintenant indépendant du champ PACKET_LENGTH lu dans le paquet.
Le CRC est calculé directement sur le paquet reçu en utilisant la taille réelle du paquet reçu.
Updated by paul leroy almost 10 years ago
- Assignee changed from paul leroy to bruno katra
Updated by Veronique bouzid almost 10 years ago
- Status changed from Resolved to Feedback
- Assignee changed from bruno katra to paul leroy
test SVS-0007 rejoué (scriptloop_tm_lfr_tc_exe_no_ack.py)
en 1.0.0.11
VHDl = 0.1.23
Mauvais PACKET_LENGTH (65535) sur une TC_LFR_*
--> Pour moi ce n'est pas bon, il y a une inversion entre the champ PA_RPW_RCV_CRC et PA_RPW_COMPUTED_CRC
Par contre, le calcul du CRC est bien indépendant du champ PACKET_LENGTH
08:52:59.819767, 254, 2, 0, 0, 28, 204, 200, 47, 255, 255, 16, 181, 63, 110, 174, 69
08:52:59.819767, 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, (PACKET_ID=0x1ccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=2095, (PACKET_SEQUENCE_CONTROL=0xc82f), /!\*PACKET_LENGTH=65535((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 = 0xae45
08:52:59.832492, 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, (PACKET_ID=0xcc1), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=6, (PACKET_SEQUENCE_CONTROL=0xc006), 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=0x800000027830, PA_RPW_TC_FAILURE_CODE: CORRUPTED = 42005, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xc82f, PA_RPW_TC_SERVICE=181, PA_RPW_TC_SUBTYPE=63, PA_RPW_PKT_LEN_RCV_VALUE=65535, PA_RPW_PKT_DATFIELDSIZE_CNT=5, PA_RPW_RCV_CRC=0x5dc3, PA_RPW_COMPUTED_CRC=0xae45
Updated by paul leroy about 9 years ago
- Status changed from Feedback to In Progress
- Assignee changed from paul leroy to Veronique bouzid
rejouer sur FSW >= 2.0.2.1
Updated by Veronique bouzid almost 9 years ago
- Assignee changed from Veronique bouzid to paul leroy
Le script /opt/VALIDATION_R2/lfrverif/LFR_SVS/SVS-0007/loop_tm_lfr_tc_exe_no_ack.py a été rejoué dans le contexte decrit à la fin.
Le résultat ne me parait satisfaisant.
La TC envoyée avec une mauvaise longueur
10:33:22.849021, 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, (PACKET_ID=0x1ccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=11725, (PACKET_SEQUENCE_CONTROL=0xedcd), /!\PACKET_LENGTH=65535((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 = 0xe593
genere la réponse suivante
10:33:22.864046, 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, (PACKET_ID=0xcc1), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=6, (PACKET_SEQUENCE_CONTROL=0xc006), 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=0x8000000cdd16, PA_RPW_TC_FAILURE_CODE: CORRUPTED = 42005, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xedcd, PA_RPW_TC_SERVICE=181, PA_RPW_TC_SUBTYPE=63, PA_RPW_PKT_LEN_RCV_VALUE=65535, PA_RPW_PKT_DATFIELDSIZE_CNT=5, PA_RPW_RCV_CRC=0x0, PA_RPW_COMPUTED_CRC=0xe593
--> on devra avoir la meme valeur dans PA_RPW_RCV_CRC et PA_RPW_COMPUTED_CRC pour montrer que l erreur ne vient pas du CRC mais de la longueur.
Contexte de test
----------------
FSW 2.0.2.3
VHDL 0..1.83
EQM sans Timegen
SocExplorer 0.6.0 Version = 0.6.0, Branch = default, Changeset = 8cf23d8c0b68
StarDundee spacewire
le fichier de logs etant /home/bouzid/LFR/EQM/data/R2-EQM/2.0.2.3/SVS-0007/2015_05_25-10_33_54-Nb.txt
Updated by paul leroy almost 9 years ago
- Status changed from In Progress to Resolved
- Assignee changed from paul leroy to Veronique bouzid
fsw >= 3.0.0.4
Le champ pa_rpw_rcv_crc est maintenant égal aux deux derniers octets reçu dans la télécommande, considérés a priori comme les bits de CRC.
Updated by Veronique bouzid almost 9 years ago
- Status changed from Resolved to Closed
Le bug est corrigé.
Le script rejoué est /opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0007/loop_tm_lfr_tc_exe_no_ack.py
Ici la télécommande avec une mauvaise longueur
13:05:51.028429, 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, (PACKET_ID=0x1ccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=14715, (PACKET_SEQUENCE_CONTROL=0xf97b), /!\PACKET_LENGTH=65535((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 = 0x841b
13:05:51.046012, 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, (PACKET_ID=0xcc1), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=6, (PACKET_SEQUENCE_CONTROL=0xc006), 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=0x8000000b16ea, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xf97b, PA_RPW_TC_FAILURE_CODE: CORRUPTED = 42005, PA_RPW_TC_SERVICE=181, PA_RPW_TC_SUBTYPE=63, PA_RPW_PKT_LEN_RCV_VALUE=65535, PA_RPW_PKT_DATFIELDSIZE_CNT=5, PA_RPW_RCV_CRC=0x841b, PA_RPW_COMPUTED_CRC=0x841b
On voit que le champ en erreur est celui de la longueur et le CRC est bon.
les fichiers de log (2015_06_10-13_06_19-*) se trouvent dans /home/validation/data/R3/3.0.0.4/SVS-0007.
Contexte de test
----------------
FSW 3.0.0.4
VHDL 1.1.83
EM1 sans timegen
SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481
StarDundee